Tidligere utløp ofte sertifikater fordi de måtte fornyes manuelt. Folk glemte rett og slett å gjøre det. Med bruken av Let's Encrypt og den automatiske oppdateringsprosedyren, ser det ut til at problemet burde være løst. Men nylig viser at det faktisk fortsatt er aktuelt. Dessverre fortsetter sertifikatene å utløpe.
I tilfelle du gikk glipp av historien, ved midnatt 4. mai 2019, sluttet plutselig nesten alle Firefox-utvidelser å fungere.
Som det viste seg, skjedde den massive feilen på grunn av det faktum at Mozilla , som ble brukt til å signere utvidelser. Derfor ble de merket som "ugyldige" og ble ikke bekreftet (). På forumene, som en løsning, ble det anbefalt å deaktivere utvidelsesignaturverifisering i about: config eller endre systemklokken.
Mozilla ga raskt ut Firefox 66.0.4-oppdateringen, som løser problemet med et ugyldig sertifikat, og alle utvidelser går tilbake til det normale. Utviklerne anbefaler å installere den og ingen løsninger for å omgå signaturverifisering fordi de kan komme i konflikt med oppdateringen.
Imidlertid viser denne historien nok en gang at utløp av sertifikat fortsatt er et presserende problem i dag.
I denne forbindelse er det interessant å se på en ganske original måte hvordan protokollutviklerne taklet denne oppgaven . Deres løsning kan deles i to deler. For det første er dette kortsiktige sertifikater. For det andre advarer brukere om utløpet av langsiktige.
DNSCrypt
DNSCrypt er en DNS-trafikkrypteringsprotokoll. Den beskytter DNS-kommunikasjon mot avlytting og MiTM, og lar deg også omgå blokkering på DNS-spørringsnivå.
Protokollen pakker inn DNS-trafikk mellom klient og server i en kryptografisk konstruksjon, som opererer over UDP- og TCP-transportprotokollene. For å bruke det, må både klienten og DNS-løseren støtte DNSCrypt. For eksempel, siden mars 2016, har den vært aktivert på DNS-serverne og i Yandex-nettleseren. Flere andre leverandører har også annonsert støtte, inkludert Google og Cloudflare. Dessverre er det ikke mange av dem (152 offentlige DNS-servere er oppført på den offisielle nettsiden). Men programmet kan installeres manuelt på Linux-, Windows- og MacOS-klienter. Det er også .
Hvordan fungerer DNSCrypt? Kort sagt tar klienten den offentlige nøkkelen til den valgte leverandøren og bruker den til å bekrefte sertifikatene. De kortsiktige offentlige nøklene for økten og chifferpakkeidentifikatoren er der allerede. Klienter oppfordres til å generere en ny nøkkel for hver forespørsel, og servere oppfordres til å endre nøkler hver 24. time. Ved utveksling av nøkler brukes X25519-algoritmen, for signering - EdDSA, for blokkkryptering - XSalsa20-Poly1305 eller XChaCha20-Poly1305.
En av protokollutviklerne Frank Denis at automatisk utskifting hver 24. time løste problemet med utløpte sertifikater. I prinsippet godtar dnscrypt-proxy-referanseklienten sertifikater med en hvilken som helst gyldighetsperiode, men advarer "Dnscrypt-proxy-nøkkelperioden for denne serveren er for lang" hvis den er gyldig i mer enn 24 timer. Samtidig ble et Docker-bilde utgitt, der en rask endring av nøkler (og sertifikater) ble implementert.
For det første er det ekstremt nyttig for sikkerheten: hvis serveren er kompromittert eller nøkkelen lekket, kan gårsdagens trafikk ikke dekrypteres. Nøkkelen er allerede endret. Dette vil sannsynligvis utgjøre et problem for implementeringen av Yarovaya-loven, som tvinger leverandører til å lagre all trafikk, inkludert kryptert trafikk. Implikasjonen er at den senere kan dekrypteres om nødvendig ved å be om nøkkelen fra nettstedet. Men i dette tilfellet kan nettstedet ganske enkelt ikke gi det, fordi det bruker kortsiktige nøkler og sletter gamle.
Men viktigst av alt, skriver Denis, tvinger kortsiktige nøkler servere til å sette opp automatisering fra dag én. Hvis serveren kobles til nettverket og nøkkelendringer-skriptene ikke er konfigurert eller ikke fungerer, vil dette bli oppdaget umiddelbart.
Når automatisering endrer nøkler med noen års mellomrom, kan man ikke stole på det, og folk kan glemme sertifikatutløp. Hvis du endrer nøklene daglig, vil dette bli oppdaget umiddelbart.
På samme tid, hvis automatisering er konfigurert normalt, spiller det ingen rolle hvor ofte nøklene endres: hvert år, hvert kvartal eller tre ganger om dagen. Hvis alt fungerer i mer enn 24 timer, vil det fungere for alltid, skriver Frank Denis. Ifølge ham reduserte anbefalingen om daglig nøkkelrotasjon i den andre versjonen av protokollen, sammen med et ferdig Docker-bilde som implementerer det, antallet servere med utløpte sertifikater, samtidig som sikkerheten ble forbedret.
Noen tilbydere bestemte seg imidlertid av noen tekniske årsaker for å sette sertifikatets gyldighetsperiode til mer enn 24 timer. Dette problemet ble stort sett løst med noen få linjer med kode i dnscrypt-proxy: brukere mottar en informativ advarsel 30 dager før sertifikatet utløper, en annen melding med et høyere alvorlighetsnivå 7 dager før utløp, og en kritisk melding hvis sertifikatet har noe gjenværende gyldighet mindre enn 24 timer. Dette gjelder kun sertifikater som i utgangspunktet har lang gyldighetstid.
Disse meldingene gir brukerne muligheten til å varsle DNS-operatører om forestående sertifikatutløp før det er for sent.
Kanskje hvis alle Firefox-brukere mottok en slik melding, ville nok noen informert utviklerne og de ville ikke tillate at sertifikatet utløper. "Jeg husker ikke en eneste DNSCrypt-server på listen over offentlige DNS-servere som har fått sertifikatet sitt utløpt i løpet av de siste to eller tre årene," skriver Frank Denis. I alle fall er det sannsynligvis bedre å advare brukere først i stedet for å deaktivere utvidelser uten forvarsel.
Kilde: www.habr.com