TLS gako-trukea eta bezero-ziurtagiria: zeinek egiten du saio-hasiera?
Bereizi gako-hitzarmena bezeroaren autentifikaziotik eta aplikazioaren identitatetik, eta irakurri zein erabili zuen konexioak benetan erakusten duten agur-mezuak.
Agur batean gako-trukerako balio publikoa eramatea ez da bezero bat saioa hasten ari den gertaera bera. Batek konexiorako egoera kriptografikoa ezartzen du; besteak bezeroa nor den adierazten du, eta soilik gertatzen da zerbitzariak eskatzen duenean eta trukeak onartzen duenean. Lehena bigarrentzat hartzeak ondorio okerretara eramaten du VPN batek zer ezkutatzen duen eta zer ez. Irakurri mezuak, eta gero erabaki zer lau propietatetik behatu duzun benetan.
Harrapaketa batean berdinak diruditen bi objektu
TLS 1.3 bezero batek bere lehen hegaldian gako-trukerako materiala eman dezake ziurtagiriak aurkeztu gabe. Ekarpen hori publikoa da diseinuz, zerbitzariak sekretu partekatua eratortzeko behar duelako. Bezero-ziurtagiria beste mezu bat da, eta zerbitzariak bat eskatu ondoren soilik bidaltzen da. Zerbitzariak gero egiaztatzen duen identitatea eramaten du, eta elkarrekiko autentifikazioa zerbitzariaren erabakia da, ez zifratze-multzoak inplikatzen duen propietatea. Aplikazioaren identitatea erabat hirugarren gauza da: saio-hasierako formularioa, bearer tokena, cookiea. Horietako bat ere ez da agur-ean agertzen, eta guztiek sare-bidearen aldaketari eusten diote.
| 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 |
Lau errenkadak independenteak dira. Konexio batek lehen eta bigarren errenkadak izan ditzake, hirugarrena saltatu, eta laugarrena cookie-izenburuan eraman oraindik.
Erabaki zer froga dezakeen harrapatutako agur batek
Agur hutsetik behatzaileak negoziatutako bertsioa, zifratze-multzoa, zerbitzariaren ziurtagiria eta gako-trukerako balio publikoak ikasten ditu. Hori nahikoa da bezero-inplementazio baten hatza hartzeko eta zein zerbitzarirekin kontaktatu zen ikusteko. Emaiten ez duena konexioa deszifratzeko behar den egoera pribatua da, zeinaren sekretutasuna truke efimeroan oinarritzen baita eta ez zati publikoan. Kontu-identitaterik ere ez du ematen, eta hori ez zegoen agur-ean hasieratik.
Beraz, ondorio zintzoa estua da: truke honetan ez zen bezero-ziurtagiririk aurkeztu. Kontua ez da bezeroak ezer lotugarririk bidali ez zuenik, eta inola ere ez da saioak identifikatzailerik eraman ez zuenik.
Irakurri mezuak, ez zifratzearen izena
Galdetu zerbitzariari zer eskatzen duen, zifratze-multzotik ondorioztatu beharrean. Ziurtagiri-eskaera dakarren TLS 1.3 agur bat transkripzioan ikusgai dago, eta haren eza bezain ikusgai.
openssl s_client -connect app.example.net:443 -tls1_3 -msg < /dev/null 2>&1 | grep -i -E 'key_share|CertificateRequest'
Gero errepikatu bezero-ziurtagiri bat konfiguratuta eta alderatu. Bigarren exekuzioak ziurtagiria bidaltzen eta onartzen dela erakutsi beharko luke; lehenengoak bat ere ez luke erakutsi behar, eta hori da argudioaren benetako aldea.
openssl s_client -connect app.example.net:443 -tls1_3 -cert client.pem -key client.key -quiet
Nabigazio-kasu arrunta soilik behar baduzu, bezeroaren irteera xehea nahikoa da protokoloaren bertsioa, egiaztatzearen emaitza eta bezero-ziurtagiririk eskaini zen ikusteko. Inoiz ziurtagiri-eskaerarik bidaltzen ez duen zerbitzari batek ezin zuen bat jaso.
Non aldatzen duen erantzuna berrekiteak
TLS 1.3 berrekiteak egoera sekretuari lotutako tiketak erabiltzen ditu, beraz geroagoko konexio batek ziurtagiri-truke osoa gabe osa dezake. Horrek behatzaileak ikusten duena murrizten du eta transkripzioak frogatzen duena aldatzen du. Ez du identitaterik sortzen zegoen tokian. Berrekiten den saio bat aplikazio-saio berari dagokio oraindik, eta saio horretako cookie edo token oro garrantzitsua den identifikatzailea izaten jarraitzen du.
Horregatik, "bezero-ziurtagiririk ez" esatean gelditzen den pribatutasun-berrikuspenak zati interesgarria galtzen du. Egin beharreko galdera zein aldek duen identifikatzaile egonkorra da, ez zein mezu falta zen agur batean.
Idatzi lau propietate, ez egiaztapen bakarra
Idatzi gako-hitzarmena, zerbitzariaren egiaztatzea, bezeroaren autentifikazioa eta aplikazioaren identitatea lau lerro bereizitan, bakoitzaren frogarekin. Inbentario horrek protokolo-bertsioaren aldaketei eusten die, eta pribatutasunari buruzko argudioa beste norbaitek egiazta dezan egiten du. Gero gehitu sare-bideak zer ematen duen. VPN batek zerbitzu batek ikusten duen iturburu-helbidea aldatzen du; ez du kentzen aplikazioak dagoeneko duen saio-hasiera, cookie edo gailu-hatzik.
Idatzi elkarrekin konexioaren negoziatutako bertsioa eta ziurtagiri-eskaeraren emaitza, bikote hori behar baitu berrikusleak zure ondorioa berregiteko bere harrapaketarik gabe.