Pagpapalitan ng susi ng TLS kumpara sa sertipiko ng kliyente: alin ang nagla-log in?

Ang pagdadala ng pampublikong halaga ng pagpapalitan ng susi sa isang handshake ay hindi ang parehong pangyayari ng isang kliyenteng nagla-log in. Ang isa ay nagtatatag ng kriptograpikong kalagayan para sa koneksyon; ang isa ay nagsasabi kung sino ang kliyente, at nangyayari lamang ito kapag hiniling ng server at sinusuportahan ng palitan. Ang pagtrato sa una bilang pangalawa ay humahantong sa maling mga konklusyon tungkol sa kung ano ang itinatago ng VPN at hindi. Basahin ang mga mensahe, pagkatapos ay magpasya kung alin sa apat na katangian ang talagang naobserbahan mo.

Dalawang bagay na magkamukha sa isang pagkuha

Ang kliyente ng TLS 1.3 ay maaaring mag-ambag ng materyal sa pagpapalitan ng susi sa unang lipad nito nang walang ipinakikitang anumang sertipiko. Ang ambag na iyon ay pampubliko ayon sa disenyo, dahil kailangan ito ng server upang makuha ang pinagsamang lihim. Ang sertipiko ng kliyente ay ibang mensahe at ipinapadala lamang pagkatapos humiling ng server ng isa. Nagdadala ito ng pagkakakilanlan na pagkatapos ay bineberipika ng server, at ang pagpapatunay ng isa't isa ay desisyon ng server, hindi katangiang ipinapahiwatig ng cipher suite. Ang pagkakakilanlan ng aplikasyon ay ganap na ikatlong bagay: isang form ng pag-log in, isang bearer token, isang cookie. Wala sa mga iyon ang lumilitaw sa handshake, at lahat ng iyon ay nakakaligtas sa pagbabago ng landas ng network.

Ang apat na hilera ay malaya. Ang koneksyon ay maaaring may hilera uno at dos, laktawan ang hilera tres, at dalhin pa rin ang hilera kwatro sa isang header ng cookie.

Magpasya kung ano ang maaaring patunayan ng nakuhang handshake

Mula sa handshake lamang, natututuhan ng tagamasid ang napagkasunduang bersyon, ang cipher suite, ang sertipiko ng server at ang pampublikong halaga ng pagpapalitan ng susi. Sapat na iyon upang kumuha ng fingerprint ng isang implementasyon ng kliyente at upang makita kung aling server ang kinontak. Ang hindi nito ibinibigay ay ang pribadong kalagayan na kailangan upang i-decrypt ang koneksyon, na ang pagiging lihim ay nakasalalay sa ephemeral na palitan at hindi sa pampublikong bahagi. Hindi rin ito nagbibigay ng pagkakakilanlan ng account, na hindi kailanman nasa handshake mula pa noong una.

Kaya ang tapat na konklusyon ay makitid: walang sertipiko ng kliyente na iniharap sa palitang ito. Hindi ito ang kaso na walang ipinadala ang kliyente na maaaring iugnay, at tiyak na hindi ang kaso na walang dala ang sesyon na anumang identifier.

Basahin ang mga mensahe, hindi ang pangalan ng cipher

Tanungin ang server kung ano ang hinihiling nito, sa halip na maghinuha mula sa cipher suite. Ang handshake ng TLS 1.3 na may kasamang kahilingan ng sertipiko ay nakikita sa transcript, at ang kawalan nito ay kasing halata.

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

Pagkatapos ay ulitin na may naka-configure na sertipiko ng kliyente, at ihambing. Dapat ipakita ng ikalawang pagtakbo na ipinapadala at tinatanggap ang sertipiko; hindi dapat magpakita ng anuman ang una, at iyon ang konkretong pagkakaiba na pinag-uusapan.

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

Kung kailangan mo lamang ang ordinaryong kaso ng pag-browse, sapat na ang detalyadong output ng kliyente upang makita ang bersyon ng protocol, ang resulta ng beripikasyon at kung inalok ang isang sertipiko ng kliyente. Ang server na hindi kailanman nagpapadala ng kahilingan ng sertipiko ay hindi maaaring nakatanggap ng isa.

Kung saan binabago ng pagpapatuloy ang sagot

Ang pagpapatuloy sa TLS 1.3 ay gumagamit ng mga tiket na nakatali sa lihim na kalagayan, kaya ang susunod na koneksyon ay makakumpleto nang walang buong pagpapalitan ng sertipiko. Binabawasan nito ang nakikita ng tagamasid at binabago kung ano ang pinatutunayan ng transcript. Hindi ito lumilikha ng pagkakakilanlan kung saan wala. Ang naipagpatuloy na sesyon ay kabilang pa rin sa parehong sesyon ng aplikasyon, at anumang cookie o token sa sesyong iyon ay nananatiling identifier na mahalaga.

Iyon ang dahilan kung bakit ang pagsusuri ng privacy na humihinto sa "walang sertipiko ng kliyente" ay napapalampas ang kawili-wiling bahagi. Ang tanong ay kung aling panig ang may matatag na identifier, hindi kung aling mensahe ang nawala sa isang handshake.

Itala ang apat na katangian, hindi isang hatol

Isulat ang kasunduan sa susi, beripikasyon ng server, pagpapatunay ng kliyente at pagkakakilanlan ng aplikasyon bilang apat na hiwalay na hilera, kasama ang ebidensya para sa bawat isa. Ang imbentaryong iyon ay nakakaligtas sa mga pagbabago ng bersyon ng protocol, at ginagawa nitong maaaring suriin ng iba ang isang argumento tungkol sa privacy. Pagkatapos ay idagdag kung ano ang ambag ng landas ng network. Binabago ng VPN ang pinagmulang address na nakikita ng isang serbisyo; hindi nito tinatanggal ang isang pag-log in, isang cookie o isang fingerprint ng aparato na taglay na ng aplikasyon.

Itala nang magkasama ang napagkasunduang bersyon ng koneksyon at ang resulta ng kahilingan ng sertipiko, dahil ang pares na iyon ang kailangan ng isang tagasuri upang muling gawin ang iyong konklusyon nang walang sariling pagkuha.