TLS-kaaidieling fersus kliïntsertifikaat: hokker ien logt yn?

In iepenbiere kaai-útwikselingswearde yn in hânskod meinimme is net deselde barren as in kliïnt dy't ynlogt. It iene set kryptografyske steat foar de ferbining del; it oare seit wa't de kliïnt is, en dat bart allinnich as de tsjinner derom freget en de útwikseling it stipet. It earste as it twadde behannelje liedt ta ferkearde konklúzjes oer wat in VPN wol en net ferbergt. Lês de berjochten en beslút dan hokker fan fjouwer eigenskippen jo eins waarnommen hawwe.

Twa objekten dy't yn in opname allyksa lykje

In TLS 1.3-kliïnt kin kaai-útwikselingsmateriaal yn syn earste flecht bydrage sûnder in sertifikaat sjen te litten. Dy bydrage is fan ûntwerp iepenbier, om't de tsjinner it nedich hat om it dielde geheim ôf te lieden. In kliïntsertifikaat is in oar berjocht, en wurdt pas stjoerd neidat de tsjinner om ien frege hat. It draacht in identiteit dy't de tsjinner dêrnei ferifiearret, en wjerssidige autentikaasje is in beslút fan de tsjinner, net in eigenskip dy't de syfersuite ymplisearret. Applikaasje-identiteit is hielendal in tredde ding: in ynlogformulier, in bearer-token, in cookie. Net ien fan dy ferskynt yn it hânskod, en allegear oerlibje se in feroaring fan netwurkpaad.

De fjouwer rigen binne ûnôfhinklik. In ferbining kin rige ien en twa hawwe, rige trije oerslaan en dochs rige fjouwer yn in cookie-kop drage.

Beslút wat in opnommen hânskod bewize kin

Allinnich út it hânskod leart in waarnimmer de ûnderhannele ferzje, de syfersuite, it sertifikaat fan de tsjinner en de iepenbiere kaai-útwikselingswearden. Dat is genôch om in kliïntimplementaasje te fingerprinten en om te sjen hokker tsjinner benadere waard. Wat it net jout, is de partikuliere steat dy't nedich is om de ferbining te ûntsiferjen; de geheimhâlding dêrfan rêst op 'e efemêre útwikseling en net op it iepenbiere oanpart. It jout ek gjin akkountidentiteit, dy't fan it begjin ôf nea yn it hânskod wie.

Dat de earlike konklúzje is smel: yn dizze útwikseling is gjin kliïntsertifikaat sjen litten. It is net dat de kliïnt neat keppelbers stjoerd hat, en grif net dat de sesje gjin identifikaasje droech.

Lês de berjochten ynstee fan 'e syfernamme

Freegje de tsjinner wat er oanfreget, ynstee fan út 'e syfersuite ôf te lieden. In TLS 1.3-hânskod mei in sertifikaatoanfraach is sichtber yn it transkript, en it ûntbrekken dêrfan is like sichtber.

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

Werhelje dan mei in konfigurearre kliïntsertifikaat, en fergelykje. De twadde run heart te sjen te jaan dat it sertifikaat stjoerd en akseptearre wurdt; de earste heart neat sjen te litten, en dat is it konkrete ferskil dêr't it argumint oer giet.

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

As jo allinnich de gewoane browsesaak nedich hawwe, is de ferboaze kliïntútfier genôch om de protokolferzje, it ferifikaasjeresultaat en oft in kliïntsertifikaat oanbean waard te sjen. In tsjinner dy't nea in sertifikaatoanfraach stjoert, kin der gjin ien ûntfongen hawwe.

Wêr't it ferfetsjen it antwurd feroaret

Ferfetsjen yn TLS 1.3 brûkt tickets dy't oan geheime steat keppele binne, sadat in lettere ferbining foltôgje kin sûnder folsleine sertifikaatútwikseling. Dat ferminderet wat in waarnimmer sjocht en feroaret wat it transkript bewurdet. It makket gjin identiteit wêr't dy der net wie. In ferfette sesje heart noch altiten by deselde applikaasjesesje, en elk cookie of token yn dy sesje bliuwt de identifikaasje dy't fan belang is.

Dêrom mist in privacyresinsje dy't by "gjin kliïntsertifikaat" ophâldt it nijsgjirrige part. De fraach is wa't in stabile identifikaasje hat, net hokker berjocht út ien hânskod miste.

Skriuw fjouwer eigenskippen op, net ien oardiel

Skriuw kaai-oerienkomst, tsjinnerferifikaasje, kliïntautentikaasje en applikaasje-identiteit as fjouwer aparte rigels op, mei it bewiis foar elk. Dat ynventaris oerlibbet feroarings fan protokolferzje, en it makket in argumint oer privacy troch immen oars neigeanber. Foegje dan ta wat it netwurkpaad bydraacht. In VPN feroaret it boarne-adres dat in tsjinst sjocht; it ferwideret gjin ynlog, cookie of apparaatfingerprint dy't de applikaasje al hat.

Skriuw de ûnderhannele ferzje fan 'e ferbining en de útslach fan 'e sertifikaatoanfraach tegearre op, want dat pear hat in resinsint nedich om jo konklúzje sûnder eigen opname te reprodusearjen.