Shkëmbimi i çelësit TLS kundrejt certifikatës së klientit: cili bën hyrjen?
Ndani marrëveshjen e çelësit nga vërtetimi i klientit dhe identiteti i aplikacionit, dhe lexoni mesazhet e shtrëngimit të duarve që tregojnë se cilën përdori në të vërtetë një lidhje.
Bartja e një vlere publike të shkëmbimit të çelësit në një shtrëngim duarsh nuk është i njëjti ngjarje si hyrja e një klienti. Njëra vendos gjendjen kriptografike për lidhjen; tjetra tregon kush është klienti, dhe ndodh vetëm kur serveri e kërkon dhe shkëmbimi e mbështet. Trajtimi i së parës si e dyta çon në përfundime të gabuara për atë që fsheh një VPN dhe çfarë nuk fsheh. Lexoni mesazhet dhe më pas vendosni cilën nga katër vetitë vëzhguat vërtet.
Dy objekte që duken njësoj në një regjistrim
Një klient TLS 1.3 mund të kontribuojë me material shkëmbimi çelësi në fluturimin e tij të parë pa paraqitur asnjë certifikatë. Ky kontribut është publik sipas dizajnit, sepse serveri ka nevojë për të për të nxjerrë sekretin e përbashkët. Certifikata e klientit është një mesazh tjetër dhe dërgohet vetëm pasi serveri kërkon një të tillë. Ajo mbart një identitet që serveri më pas verifikon, dhe vërtetimi i ndërsjellë është vendim i serverit, jo veti që nënkuptohet nga grupi i shifrave. Identiteti i aplikacionit është gjë krejt e tretë: një formular hyrjeje, një token bartës, një cookie. Asnjë prej tyre nuk shfaqet në shtrëngimin e duarve, dhe të gjitha i mbijetojnë një ndryshimi të rrugës së rrjetit.
| 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 |
Katër rreshtat janë të pavarur. Një lidhje mund të ketë rreshtin e parë dhe të dytë, të kapërcejë të tretin dhe gjithsesi të mbajë të katërtin në një kokë cookie.
Vendosni çfarë mund të provojë një shtrëngim duarsh i regjistruar
Vetëm nga shtrëngimi i duarve, një vëzhgues mëson versionin e negociuar, grupin e shifrave, certifikatën e serverit dhe vlerat publike të shkëmbimit të çelësit. Kjo mjafton për të marrë një gjurmë të një zbatimi klienti dhe për të parë cili server u kontaktua. Ajo që nuk jep është gjendja private e nevojshme për të deshifruar lidhjen, fshehtësia e së cilës mbështetet në shkëmbimin efemer dhe jo në pjesën publike. Nuk jep asnjë identitet llogarie, i cili nuk ishte fare në shtrëngimin e duarve që në fillim.
Prandaj përfundimi i ndershëm është i ngushtë: në këtë shkëmbim nuk u paraqit asnjë certifikatë klienti. Nuk bëhet fjalë se klienti nuk dërgoi asgjë të lidhshme, dhe sigurisht jo se sesioni nuk mbante asnjë identifikues.
Lexoni mesazhet, jo emrin e shifrës
Pyetni serverin çfarë kërkon, në vend që të nxirrni përfundime nga grupi i shifrave. Një shtrëngim duarsh TLS 1.3 që përfshin një kërkesë certifikate është i dukshëm në transkript, dhe mungesa e tij është po aq e dukshme.
openssl s_client -connect app.example.net:443 -tls1_3 -msg < /dev/null 2>&1 | grep -i -E 'key_share|CertificateRequest'
Më pas përsëritni me një certifikatë klienti të konfiguruar dhe krahasoni. Ekzekutimi i dytë duhet të tregojë certifikatën e dërguar dhe të pranuar; i pari nuk duhet të tregojë asnjë, dhe ky është ndryshimi konkret për të cilin bëhet fjalë.
openssl s_client -connect app.example.net:443 -tls1_3 -cert client.pem -key client.key -quiet
Nëse ju duhet vetëm rasti i zakonshëm i shfletimit, dalja e detajuar e klientit mjafton për të parë versionin e protokollit, rezultatin e verifikimit dhe nëse u ofrua një certifikatë klienti. Një server që nuk dërgon kurrë një kërkesë certifikate nuk mund të ketë marrë një.
Ku rifillimi ndryshon përgjigjen
Rifillimi në TLS 1.3 përdor bileta të lidhura me gjendje sekrete, kështu që një lidhje e mëvonshme mund të përfundojë pa një shkëmbim të plotë certifikatash. Kjo zvogëlon atë që sheh një vëzhgues dhe ndryshon atë që provon transkripti. Nuk krijon një identitet aty ku nuk kishte. Një sesion i rifilluar vazhdon t’i përkasë të njëjtit sesion aplikacioni, dhe çdo cookie ose token në atë sesion mbetet identifikuesi që ka rëndësi.
Kjo është arsyeja pse një rishikim i privatësisë që ndalet te "asnjë certifikatë klienti" humbet pjesën interesante. Pyetja është cila palë mban një identifikues të qëndrueshëm, jo cili mesazh mungonte në një shtrëngim duarsh.
Shënoni katër veti, jo një verdikt
Shënoni marrëveshjen e çelësit, verifikimin e serverit, vërtetimin e klientit dhe identitetin e aplikacionit si katër rreshta të veçantë, me provën për secilin. Ky inventar i mbijeton ndryshimeve të versionit të protokollit, dhe e bën një argument për privatësinë të verifikueshëm nga dikush tjetër. Më pas shtoni çfarë kontribuon rruga e rrjetit. Një VPN ndryshon adresën burimore që sheh një shërbim; ai nuk heq një hyrje, një cookie ose një gjurmë pajisjeje që aplikacioni tashmë ka.
Shënoni së bashku versionin e negociuar të lidhjes dhe rezultatin e kërkesës për certifikatë, sepse pikërisht ky çift i nevojitet një recensuesi për të riprodhuar përfundimin tuaj pa një regjistrim të vetin.