TLS-sleutelaandeel teenoor kliëntsertifikaat: watter een teken in?

Om 'n publieke sleuteluitruilwaarde in 'n handdruk te dra is nie dieselfde gebeurtenis as dat 'n kliënt inteken nie. Die een vestig kriptografiese toestand vir die verbinding; die ander sê wie die kliënt is, en dit gebeur net wanneer die bediener daarom vra en die uitruiling dit ondersteun. Om die eerste as die tweede te behandel lei tot slegte gevolgtrekkings oor wat 'n VPN wel en nie verberg nie. Lees die boodskappe en besluit dan watter van vier eienskappe jy werklik waargeneem het.

Twee objekte wat in 'n opname dieselfde lyk

'n TLS 1.3-kliënt kan sleuteluitruilmateriaal in sy eerste vlug bydra sonder om enige sertifikaat voor te lê. Daardie bydrae is per ontwerp publiek, want die bediener het dit nodig om die gedeelde geheim af te lei. 'n Kliëntsertifikaat is 'n ander boodskap, wat eers gestuur word nadat die bediener een versoek het. Dit dra 'n identiteit wat die bediener dan verifieer, en wedersydse verifikasie is 'n besluit wat die bediener neem eerder as 'n eienskap wat die syferpakket impliseer. Toepassingsidentiteit is 'n heeltemal derde ding: 'n intekenvorm, 'n draertoken, 'n koekie. Nie een daarvan verskyn in die handdruk nie, en almal oorleef 'n verandering van netwerkpad.

Die vier rye is onafhanklik. 'n Verbinding kan rye een en twee hê, ry drie oorslaan en steeds ry vier in 'n koekie-opskrif dra.

Besluit wat 'n opgeneemde handdruk kan bewys

Uit die handdruk alleen leer 'n waarnemer die onderhandelde weergawe, die syferpakket, die bediener se sertifikaat en die publieke sleuteluitruilwaardes. Dit is genoeg om 'n kliëntimplementering te vingerafdruk en om te sien watter bediener gekontak is. Wat dit nie lewer nie, is die private toestand wat nodig is om die verbinding te ontsleutel, want die geheimhouding daarvan berus op die efemere uitruiling eerder as op die publieke aandeel. Dit lewer ook nie 'n rekeningidentiteit nie, wat van die begin af nooit in die handdruk was nie.

Die eerlike gevolgtrekking is dus smal: geen kliëntsertifikaat is in hierdie uitruiling voorgelê nie. Dit is nie dat die kliënt niks koppelbaars gestuur het nie, en dit is beslis nie dat die sessie geen identifiseerder gedra het nie.

Lees die boodskappe in plaas van die syfernaam

Vra die bediener wat hy versoek, in plaas daarvan om uit die syferpakket af te lei. 'n TLS 1.3-handdruk wat 'n sertifikaatversoek insluit, is in die transkripsie sigbaar, en die afwesigheid daarvan is ewe sigbaar.

openssl s_client -connect app.example.net:443 -tls1_3 -msg < /dev/null 2>&1 | grep -i -E 'key_share|CertificateRequest'

Herhaal dan met 'n kliëntsertifikaat opgestel, en vergelyk. Die tweede lopie behoort te wys dat die sertifikaat gestuur en aanvaar word; die eerste behoort niks te wys nie, en dit is die konkrete verskil waaroor die argument gaan.

openssl s_client -connect app.example.net:443 -tls1_3 -cert client.pem -key client.key -quiet

As jy net die gewone blaaiersaak nodig het, is die verbose kliëntuitset genoeg om die protokolweergawe, die verifikasieresultaat en of 'n kliëntsertifikaat aangebied is, te sien. 'n Bediener wat nooit 'n sertifikaatversoek stuur nie, kon nie een ontvang het nie.

Waar hervatting die antwoord verander

TLS 1.3-hervatting gebruik kaartjies wat aan geheime toestand gekoppel is, sodat 'n latere verbinding sonder 'n volledige sertifikaatuitruiling kan voltooi. Dit verminder wat 'n waarnemer sien en verander wat die transkripsie bewys. Dit skep nie 'n identiteit waar daar nie een was nie. 'n Hervatte sessie behoort steeds aan dieselfde toepassingsessie, en enige koekie of token in daardie sessie bly die identifiseerder wat saak maak.

Dit is waarom 'n privaatheidsoorsig wat by "geen kliëntsertifikaat" stop, die interessante deel mis. Die vraag om te vra is watter party 'n stabiele identifiseerder hou, nie watter boodskap uit een handdruk afwesig was nie.

Teken vier eienskappe aan, nie een uitspraak nie

Skryf sleutelooreenkoms, bedienerverifikasie, kliënteverifikasie en toepassingsidentiteit as vier afsonderlike reëls neer, met die bewyse vir elkeen. Daardie inventaris oorleef veranderinge van protokolweergawe, en dit maak 'n argument oor privaatheid deur iemand anders natrekbaar. Voeg dan by wat die netwerkpad bydra. 'n VPN verander die bronadres wat 'n diens sien; dit verwyder nie 'n intekening, 'n koekie of 'n toestelvingerafdruk wat die toepassing reeds hou nie.

Teken die verbinding se onderhandelde weergawe en die uitkoms van die sertifikaatversoek saam aan, want daardie paar is wat 'n resensent nodig het om jou gevolgtrekking te reproduseer sonder 'n opname van sy eie.