TLS-avaintenvaihto vai asiakasvarmenne: kumpi kirjautuu sisään?
Erota avainsopimus asiakkaan todentamisesta ja sovelluksen identiteetistä ja lue kättelyn viestit, jotka näyttävät, mitä yhteys todella käytti.
Julkisen avaintenvaihtoarvon kuljettaminen kättelyssä ei ole sama tapahtuma kuin asiakkaan sisäänkirjautuminen. Toinen luo yhteydelle salakirjoituksellisen tilan; toinen kertoo, kuka asiakas on, ja se tapahtuu vain, kun palvelin pyytää sitä ja vaihto tukee sitä. Ensimmäisen pitäminen toisena johtaa vääriin johtopäätöksiin siitä, mitä VPN kätkee ja mitä ei. Lue viestit ja päätä sitten, mitä neljästä ominaisuudesta todella havaitsit.
Kaksi objektia, jotka näyttävät kaappauksessa samalta
TLS 1.3 -asiakas voi antaa avaintenvaihtomateriaalia ensimmäisellä lennollaan esittämättä mitään varmennetta. Tämä panos on suunnittelultaan julkinen, koska palvelin tarvitsee sitä yhteisen salaisuuden johtamiseen. Asiakasvarmenne on eri viesti, ja se lähetetään vasta, kun palvelin pyytää sellaista. Se kantaa identiteetin, jonka palvelin sitten tarkistaa, ja molemminpuolinen todentaminen on palvelimen päätös, ei salausohjelmiston pakottama ominaisuus. Sovelluksen identiteetti on täysin kolmas asia: kirjautumislomake, bearer-tunniste, eväste. Mikään niistä ei esiinny kättelyssä, ja kaikki ne kestävät verkkopolun muutoksen.
| Object in play | What it establishes |
|---|---|
| Key-exchange share | Cryptographic state for this connection |
| Server certificate | Which server the client reached |
| Client certificate | Client authentication, when requested |
| Application session | Account identity inside the application |
Neljä riviä ovat toisistaan riippumattomia. Yhteydellä voi olla rivit yksi ja kaksi, se voi ohittaa rivin kolme ja kantaa silti riviä neljä evästeotsakkeessa.
Päätä, mitä kaapattu kättely voi todistaa
Pelkästä kättelystä tarkkailija oppii neuvotellun version, salausohjelmiston, palvelimen varmenteen ja julkiset avaintenvaihtoarvot. Se riittää asiakastoteutuksen sormenjälkeen ja siihen, minkä palvelimen kanssa oltiin yhteydessä. Se mitä se ei anna, on yhteyden purkamiseen tarvittava yksityinen tila, jonka salaisuus nojaa efemeeriseen vaihtoon eikä julkiseen osaan. Se ei anna myöskään tilin identiteettiä, jota ei alun perinkään ollut kättelyssä.
Niinpä rehellinen johtopäätös on kapea: tässä vaihdossa ei esitetty asiakasvarmennetta. Ei ole kyse siitä, ettei asiakas lähettänyt mitään yhdistettävää, eikä varmasti siitä, ettei istunto kantanut tunnistetta.
Lue viestejä, älä salauksen nimeä
Kysy palvelimelta, mitä se pyytää, sen sijaan että päättelet salausohjelmistosta. TLS 1.3 -kättely, joka sisältää varmenteen pyynnön, näkyy litteraatissa, ja sen puuttuminen on yhtä näkyvää.
openssl s_client -connect app.example.net:443 -tls1_3 -msg < /dev/null 2>&1 | grep -i -E 'key_share|CertificateRequest'
Toista sitten määritetyllä asiakasvarmenteella ja vertaa. Toisen ajon pitäisi näyttää, että varmenne lähetetään ja hyväksytään; ensimmäisen ei pitäisi näyttää yhtään, ja juuri siitä konkreettisesta erosta argumentissa on kyse.
openssl s_client -connect app.example.net:443 -tls1_3 -cert client.pem -key client.key -quiet
Jos tarvitset vain tavallisen selailutapauksen, asiakkaan yksityiskohtainen tuloste riittää protokollaversion, varmennuksen tuloksen ja sen näkemiseen, tarjottiinko asiakasvarmennetta. Palvelin, joka ei koskaan lähetä varmenteen pyyntöä, ei ole voinut vastaanottaa sellaista.
Missä uudelleenaloitus muuttaa vastauksen
TLS 1.3:n uudelleenaloitus käyttää salaisen tilan sidottuja lippuja, joten myöhempi yhteys voi valmistua ilman täyttä varmennevaihtoa. Se vähentää sitä, mitä tarkkailija näkee, ja muuttaa sitä, mitä litteraatti todistaa. Se ei luo identiteettiä sinne, missä sitä ei ollut. Uudelleenaloitettu istunto kuuluu yhä samaan sovellusistuntoon, ja mikä tahansa eväste tai tunniste siinä istunnossa pysyy merkityksellisenä tunnisteena.
Siksi yksityisyyden tarkastelu, joka pysähtyy kohtaan "ei asiakasvarmennetta", jättää kiinnostavan osan huomaamatta. Kysymys on, kummalla osapuolella on vakaa tunniste, ei se, mikä viesti yhdestä kättelystä puuttui.
Kirjaa neljä ominaisuutta, ei yhtä tuomiota
Kirjaa avainsopimus, palvelimen varmennus, asiakkaan todentaminen ja sovelluksen identiteetti neljälle erilliselle riville, kunkin todiste mukanaan. Tämä luettelo kestää protokollaversion muutokset, ja se tekee yksityisyyttä koskevan argumentin toisen tarkistettavaksi. Lisää sitten, mitä verkkopolku tuo. VPN muuttaa lähdeosoitetta, jonka palvelu näkee; se ei poista kirjautumista, evästettä tai laitteen sormenjälkeä, joka sovelluksella jo on.
Kirjaa yhteyden neuvoteltu versio ja varmenteen pyynnön tulos yhdessä, koska juuri sitä paria arvioija tarvitsee toistaakseen johtopäätöksesi ilman omaa kaappaustaan.