Pse Sistemi i Revokimit të Certifikatave në Web është i Prishur dhe Çfarë Mund të Bëjë DNS në Vend të Tij

Lidhjet e sigurta në web mbështeten në certifikatat X.509, dokumente dixhitale që lidhin çelësin publik të enkriptimit të një faqeje me identitetin e saj. Kur një certifikatë vidhet ose keqpërdoret, Autoriteti Certifikues (CA) që e ka lëshuar mund ta revokojë atë. Por siç shpjegon Geoff Huston në një diskutim në blogun APNIC, modeli X.509 i trajton certifikatat si të vlefshme deri në datën e skadimit NotAfter. I vetmi kontroll mbi këtë përdorim relativisht të pakufizuar është që pala që mbështetet, shfletuesi ose aplikacioni që lidhet me një faqe, duhet të kontrollojë rregullisht listën aktuale të revokimit të CA-së, dhe standardi kurrë nuk e përcakton qartë se çfarë do të thotë 'rregullisht'. DNS ka një qasje tjetër: kopjet lokale të informacionit autoritativ të DNS mund të përdoren vetëm për një kohë të caktuar (TTL), pas së cilës duhet të merret një kopje e re nga një server autoritativ. DNS nuk revokon informacionin; e zëvendëson atë dhe pret që klientët ta rifreskojnë brenda atij TTL-je.

Ekzistojnë dy mekanizma për të kontrolluar revokimin. Një Listë Revokimi të Certifikatave (CRL) është një skedar i madh që përmban numrat serialë të të gjitha certifikatave të revokuara. Protokolli i Statusit të Certifikatave Online (OCSP) i lejon një klienti të pyesë një CA në kohë reale nëse një certifikatë specifike është ende e vlefshme. Let's Encrypt, një nga CA-të më të mëdha, ka vendosur të tërhiqet nga OCSP, pjesërisht sepse ngarkesa e pyetjeve arriti rreth 140,000 pyetje në sekondë, një problem i frikshëm. Veçanërisht, ekosistemet Chrome dhe Android nuk kryenin fare kontrolle OCSP. Vetëm platformat Apple dhe Firefox e bënin këtë. Huston vëren se nëse Chrome dhe Android do të kishin kontrolluar, duke pasur parasysh madhësinë e tyre shumë më të madhe në krahasim me Apple dhe Firefox, ky vendim mund të ishte marrë vite më parë.

Komenti i Morgan Collett kujton se certifikatat WTLS (Wireless Transport Layer Security) në fund të viteve 1990 kishin për qëllim të kishin vlefshmëri shumë të shkurtër sepse CRL-të ishin të papranueshme në telefonat me veçori të kufizuara. VeriSign raportohet se përdorte vlefshmëri 48-orëshe, të rinovuara çdo 24 orë. Huston më pas zbërthen një paqartësi fatkeqe në kohën X.509 NotAfter. Një interpretim i referohet subjektit të certifikatës: CA nuk dëshiron të dëshmojë vlefshmërinë e çelësit publik të subjektit pas një kohe të caktuar, duke i sinjalizuar subjektit të gjenerojë një çift të ri çelësash dhe të kërkojë një certifikatë të re para asaj kohe. Një interpretim tjetër i referohet palës që mbështetet: kopja e certifikatës që përdoret nuk duhet të përdoret pas asaj date dhe certifikata duhet të merret përsëri nga pika e publikimit të CA-së. Për të shmangur CRL-të, do të kishte kuptim të kufizohej jetëgjatësia e një kopjeje të certifikatës, duke i detyruar palët që mbështeten të ri-kontrollojnë rregullisht me CA-në pa kërkuar që subjekti të kalojë nëpër një Kërkesë të re për Nënshkrim Certifikate (CSR). Por industria përfundoi me interpretimin e parë, duke i detyruar subjektet të marrin CSR të reja thjesht sepse palët që mbështeteshin duhej të kontrollonin më shpesh.

Matjet e reja shtojnë thellësi. Komenti i tijay thotë se një hapësirë projektimi OCSP-përmes-DNS u rishikua në një punim SIGCOMM 2025. Propozimet e mëparshme ODIN dhe DCSP dështuan duke vendosur një rekord të veçantë DNS për çdo certifikatë. Këndi i ri është të publikohen vetëm serialet e revokuara si rekorde TXT të nënshkruara me DNSSEC dhe të përdoren rekorde NSEC plus caching negativ agresiv për gjithçka tjetër. Në atë model, resolvers përgjigjen për afërsisht 99.8 për qind të kontrolleve nga cache pa kontaktuar CA-në, dhe 612 milionë certifikatat aktive të Let's Encrypt përshtaten në një zonë të nënshkruar prej rreth 345 megabajt. Tijay e quan këtë të njëjtin instinkt DANE dhe DNSSEC, i kufizuar posaçërisht për revokim. Matja tjetër befasuese është se një grusht i vogël rrjeteve të shpërndarjes së përmbajtjes (CDN) tani shërbejnë shumicën e trafikut OCSP. Rreth 70 për qind e certifikatave kanë të dhënat e revokimit të tyre të shërbyera nga vetëm pesë ofrues. Pra, edhe para njoftimit të Let's Encrypt, OCSP ishte ri-përqendruar në heshtje në disa skaje CDN. Tijay argumenton se të thuash 'OCSP është i prishur' fsheh faktin se ajo që është në të vërtetë e prishur është versioni i decentralizuar i OCSP.

Geoff Huston pajtohet se përqendrimi i CA-ve dhe ofruesve CDN ishte i dukshëm, dhe ngarkesa e pyetjeve OCSP e cituar nga Let's Encrypt është një problem i frikshëm. Komenti i Named Bird sugjeron se DNSSEC i kombinuar me DANE është rruga përpara. Në atë të ardhme, CA-të nuk do të ishin më pjesë e zinxhirit kritik të vërtetësisë së emrave të domain-eve dhe mund të luanin një rol tjetër. Megjithatë, Named Bird gjithashtu paralajmëron se vetë DNS është i tendosur. Aty ku përdoruesit dikur kërkonin një rekord të vetëm A (një adresë IPv4), tani ata kërkojnë rekorde A, AAAA dhe HTTPS, rekorde për nën-domainet me nënvizim, dhe rekorde TXT të përdorura për shumë teknologji, ndoshta dhjetëra ose qindra rekorde, secili me nënshkrimin e vet RRSIG dhe rekorde të tjera DNSSEC. Shaka e zakonshme se 'është gjithmonë DNS' nxjerr në pah një problem që po përkeqësohet ngadalë, dhe Named Bird pyet nëse DNS ka nevojë për një përditësim ose ridizajnim të plotë për përdorimet aktuale dhe të ardhshme.

Për përdoruesit e zakonshëm dhe pronarët e faqeve, këto diskutime kanë rëndësi sepse revokimi është një rrjet sigurie që shpesh dështon në heshtje. Certifikatat me jetëgjatësi të shkurtër zvogëlojnë dritaren e dëmit, dhe të dhënat e revokimit të nënshkruara me DNSSEC mund ta bëjnë kontrollin më të shpejtë dhe më privat. Përdorimi i një resolvers DNS të enkriptuar që i jep përparësi privatësisë dhe që vërteton DNSSEC, si AEU DNS (https://aeu-dns.com), ndihmon të sigurohet që përgjigjet DNS që merrni janë autentike dhe nuk janë manipuluar, gjë që është një themel i nevojshëm nëse këto ide të certifikatave të mbështetura nga DNSSEC do të zbatohen.