În primul rând, nu am văzut nicio informație specifică cu privire la conținutul câmpului ssl_version în jurnalele ELB, care ar fi locul corect pentru a răspunde cu autoritate la ceea ce înseamnă jurnalele ELB.
Acestea fiind spuse, în acest gen de context șirul TLSv1
ar trebui interpretat în mod rezonabil ca însemnând TLS versiunea 1.0.
În cazul dvs. particular, acest lucru ar implica faptul că acei clienți nu par să accepte versiuni superioare (deoarece ar fi de așteptat să le prefere și să le folosească ori de câte ori este posibil).
Este de remarcat faptul că șiruri ca SSLv2
, SSLv3
, TLSv1
, TLSv1.1
, TLSv1.2
, TLSv1.3
mai ales atunci când sunt scrise așa (și uneori variații minore ale temei, în funcție de software-ul implicat) de multe ori nu sunt text în formă liberă creat cu exact contextul actual în minte, ci mai degrabă identificatori de protocol utilizați în software-ul de bază.
Cât despre potenţialul confuz TLSv1
identificator utilizat pe scară largă pentru versiunea TLS 1.0, cred că ceea ce putem citi în aceasta este pur și simplu că implementările populare (cum ar fi openssl) au fost oarecum surprinse de schimbarea politicii de versiuni care a devenit clară doar când TLS 1.1 și următoarele versiuni au fost introduse mult. mai tarziu.
Adică, SSL fusese versiunile 1.0, 2.0, 3.0, dar de când protocolul a schimbat numele în TLS, versiunile au urmat în schimb modelul 1.0, 1.1, 1.2, 1.3. La momentul în care TLS 1.0 a fost introdus pentru prima dată, presupun că presupunerea era pur și simplu că următoarea versiune va fi 2.0 și că continuarea aceluiași model de identificatori simplificați ca înainte ar continua să aibă sens.
Notă marginală:
Este corect ca răsuci
are opțiuni de linie de comandă care utilizează inteligent --tlsv1
însemnând ceva diferit de --tlsv1.0
, dar întrebarea nu este despre cum să instruiți răsuci
cum este permis să se conecteze, ci mai degrabă să analizeze ceea ce o intrare de jurnal specifică ca versiune exactă utilizată de o anumită conexiune.