Sertifiseringsinstanser (CAer) er organisasjoner som er forlovet kryptografisk sertifikat SSL-sertifikater. De setter sin elektroniske signatur på dem, og bekrefter deres autentisitet. Noen ganger oppstår det imidlertid situasjoner når sertifikater utstedes med brudd. For eksempel satte Google i fjor i gang en "detrust-prosedyre" for Symantec-sertifikater på grunn av deres kompromittering (vi dekket denne historien i detalj i bloggen vår - tid и два).
For å unngå slike situasjoner, for flere år siden IETF begynte å utvikle seg DANE-teknologi (men den er ikke mye brukt i nettlesere - vi snakker om hvorfor dette skjedde senere).
DANE (DNS-basert autentisering av navngitte enheter) er et sett med spesifikasjoner som lar deg bruke DNSSEC (Name System Security Extensions) for å kontrollere gyldigheten til SSL-sertifikater. DNSSEC er en utvidelse til Domain Name System som minimerer adresseforfalskningsangrep. Ved å bruke disse to teknologiene kan en webmaster eller klient kontakte en av DNS-soneoperatørene og bekrefte gyldigheten til sertifikatet som brukes.
I hovedsak fungerer DANE som et selvsignert sertifikat (garantisten for påliteligheten er DNSSEC) og utfyller funksjonene til en CA.
Hvordan fungerer det
DANE-spesifikasjonen er beskrevet i RFC6698. I følge dokumentet, i DNS-ressursposter en ny type ble lagt til - TLSA. Den inneholder informasjon om sertifikatet som overføres, størrelse og type data som overføres, samt selve dataene. Webmasteren lager et digitalt tommelfingeravtrykk av sertifikatet, signerer det med DNSSEC og plasserer det i TLSA.
Klienten kobler seg til et nettsted på Internett og sammenligner sertifikatet med "kopi" mottatt fra DNS-operatøren. Hvis de samsvarer, anses ressursen som klarert.
DANE-wikisiden gir følgende eksempel på en DNS-forespørsel til example.org på TCP-port 443:
IN TLSA _443._tcp.example.org
Svaret ser slik ut:
_443._tcp.example.com. IN TLSA (
3 0 0 30820307308201efa003020102020... )
DANE har flere utvidelser som fungerer med andre DNS-poster enn TLSA. Den første er SSHFP DNS-posten for validering av nøkler på SSH-tilkoblinger. Det er beskrevet i RFC4255, RFC6594 и RFC7479. Den andre er OPENPGPKEY-oppføringen for nøkkelutveksling ved bruk av PGP (RFC7929). Til slutt, den tredje er SMIMEA-posten (standarden er ikke formalisert i RFC, det er bare et utkast av det) for kryptografisk nøkkelutveksling via S/MIME.
Hva er problemet med DANE
I midten av mai ble DNS-OARC-konferansen avholdt (dette er en ideell organisasjon som driver med sikkerhet, stabilitet og utvikling av domenenavnsystemet). Eksperter på et av panelene kom til konklusjonenat DANE-teknologi i nettlesere har feilet (i hvert fall i den nåværende implementeringen). Til stede på konferansen Geoff Huston, Leading Research Scientist APNIC, en av fem regionale Internett-registratorer, svarte om DANE som en «død teknologi».
Populære nettlesere støtter ikke sertifikatautentisering ved bruk av DANE. På markedet det er spesielle plugins, som avslører funksjonaliteten til TLSA-poster, men også deres støtte gradvis stoppe.
Problemer med DANE-distribusjon i nettlesere er knyttet til lengden på DNSSEC-valideringsprosessen. Systemet er tvunget til å foreta kryptografiske beregninger for å bekrefte autentisiteten til SSL-sertifikatet og gå gjennom hele kjeden av DNS-servere (fra rotsonen til vertsdomenet) når det først kobles til en ressurs.
Mozilla prøvde å eliminere denne ulempen ved å bruke mekanismen DNSSEC kjedeforlengelse for TLS. Det var ment å redusere antall DNS-poster som klienten måtte slå opp under autentisering. Det oppsto imidlertid uenigheter innad i utviklingsgruppen som ikke lot seg løse. Som et resultat ble prosjektet forlatt, selv om det ble godkjent av IETF i mars 2018.
En annen grunn til den lave populariteten til DANE er den lave forekomsten av DNSSEC i verden - bare 19 % av ressursene jobber med det. Eksperter mente at dette ikke var nok til å aktivt promotere DANE.
Mest sannsynlig vil næringen utvikle seg i en annen retning. I stedet for å bruke DNS for å verifisere SSL/TLS-sertifikater, vil markedsaktører i stedet fremme DNS-over-TLS (DoT) og DNS-over-HTTPS (DoH) protokoller. Vi nevnte sistnevnte i en av våre tidligere materialer på Habré. De krypterer og verifiserer brukerforespørsler til DNS-serveren, og forhindrer angripere i å forfalske data. På begynnelsen av året var DoT allerede implementert til Google for sin offentlige DNS. Når det gjelder DANE, gjenstår det å se i fremtiden om teknologien vil være i stand til å "komme tilbake i salen" og fortsatt bli utbredt.