Porti publikan valoron de ŝlosilinterŝanĝo en manpremo ne estas la sama okazaĵo kiel kliento ensalutanta. Unu starigas kriptografian staton por la konekto; la alia diras kiu estas la kliento, kaj ĝi okazas nur kiam la servilo petas ĝin kaj la interŝanĝo subtenas ĝin. Trakti la unuan kiel la duan kondukas al malbonaj konkludoj pri tio, kion VPN kaŝas kaj kion ne. Legu la mesaĝojn, poste decidu kiun el kvar ecoj vi efektive observis.

Du objektoj kiuj aspektas samaj en kaptaĵo

TLS 1.3-kliento povas kontribui ŝlosilinterŝanĝan materialon en sia unua flugo sen prezenti iun ajn atestilon. Tiu kontribuo estas publika laŭdezajne, ĉar la servilo bezonas ĝin por derivi la komunan sekreton. Klienta atestilo estas alia mesaĝo, sendata nur post kiam la servilo petas unu. Ĝi portas identecon, kiun la servilo poste kontrolas, kaj reciproka aŭtentikigo estas decido de la servilo, ne eco implicata de la ĉifra kompleto. Aplikaĵa identeco estas tute tria afero: ensaluta formularo, portanto-ĵetono, kuketo. Neniu el tiuj aperas en la manpremo, kaj ĉiuj postvivas ŝanĝon de reteja vojo.

Object in playWhat it establishes
Key-exchange shareCryptographic state for this connection
Server certificateWhich server the client reached
Client certificateClient authentication, when requested
Application sessionAccount identity inside the application

La kvar vicoj estas sendependaj. Konekto povas havi vicojn unu kaj du, preterpasi vicon tri, kaj ankoraŭ porti vicon kvar en kuketa kaplinio.

Decidu kion kaptita manpremo povas pruvi

Nur el la manpremo observanto lernas la intertraktitan version, la ĉifran kompleton, la atestilon de la servilo kaj la publikajn valorojn de ŝlosilinterŝanĝo. Tio sufiĉas por preni fingrospuron de klienta efektivigo kaj por vidi kiun servilon oni kontaktis. Kion ĝi ne donas estas la privata stato necesa por malĉifri la konekton, kies sekreteco apogas sur la efemera interŝanĝo anstataŭ sur la publika parto. Ĝi ankaŭ ne donas kontan identecon, kiu tute ne estis en la manpremo dekomence.

Do la honesta konkludo estas mallarĝa: neniu klienta atestilo estis prezentita en tiu ĉi interŝanĝo. Ne temas pri tio, ke la kliento sendis nenion kunligeblan, kaj certe ne pri tio, ke la sesio portis neniun identigilon.

Legu la mesaĝojn anstataŭ la ĉifran nomon

Demandu la servilon kion ĝi petas, anstataŭ konkludi el la ĉifra kompleto. TLS 1.3-manpremo kiu inkluzivas atestilan peton videblas en la transskribo, kaj ĝia foresto estas same videbla.

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

Poste ripetu kun agordita klienta atestilo, kaj komparu. La dua rulo devus montri la atestilon sendata kaj akceptata; la unua devus montri neniun, kaj tio estas la konkreta diferenco pri kiu temas la argumento.

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

Se vi bezonas nur la ordinaran retuman kazon, la detala klienta eligo sufiĉas por vidi la protokolan version, la kontrolrezulton kaj ĉu klienta atestilo estis proponita. Servilo kiu neniam sendas atestilan peton ne povas esti ricevinta unu.

Kie daŭrigo ŝanĝas la respondon

Daŭrigo en TLS 1.3 uzas biletojn ligitajn al sekreta stato, do posta konekto povas kompletiĝi sen plena atestila interŝanĝo. Tio malpliigas kion observanto vidas kaj ŝanĝas kion la transskribo pruvas. Ĝi ne kreas identecon tie, kie neniu estis. Daŭrigita sesio ankoraŭ apartenas al la sama aplikaĵa sesio, kaj ajna kuketo aŭ ĵetono en tiu sesio restas la identigilo kiu gravas.

Tial privateca revizio kiu haltas ĉe "neniu klienta atestilo" maltrafas la interesan parton. La demando estas kiu partio tenas stabilan identigilon, ne kiu mesaĝo mankis el unu manpremo.

Notu kvar ecojn, ne unu verdikton

Skribu ŝlosilinterkonsenton, servilan kontrolon, klientan aŭtentikigon kaj aplikaĵan identecon kiel kvar apartajn liniojn, kun la pruvaro por ĉiu. Tiu inventaro postvivas ŝanĝojn de protokola versio, kaj ĝi igas argumenton pri privateco kontrolebla de iu alia. Poste aldonu kion kontribuas la reteja vojo. VPN ŝanĝas la fontan adreson kiun servo vidas; ĝi ne forigas ensaluton, kuketon aŭ aparatan fingrospuron kiun la aplikaĵo jam tenas.

Notu kune la intertraktitan version de la konekto kaj la rezulton de la atestila peto, ĉar ĝuste tiu paro estas kion recenzanto bezonas por reprodukti vian konkludon sen propra kaptaĵo.

Rilataj artikoloj