Delegerte legitimasjon for TLS

Avslutning av a TLS tilkobling krever bruk av et sertifikats private nøkkel. Som et resultat må den private nøkkelen lagres på hver enkelt server som brukes av en tjeneste. Beskyttelsen av denne private nøkkelens hemmelighold er avgjørende for en jevn drift av et offentlig nøkkelinfrastrukturopplegg. En enhet i besittelse av den private nøkkelen kan utføre man-in-the-middle-angrep for resten av sertifikatets gyldighet. Vanligvis, når en angriper kompromitterer en privat nøkkel, tilbakekalles sertifikatet knyttet til denne nøkkelen, og en ny utstedes. Men for bedrifter som bruker flere servere, som Facebook eller Innholdsleveringsnettverk, viktige kompromisser, spesielt i edge-servere, er ikke enkle å oppdage, og setter derfor hele nettverket i fare. Delegert legitimasjon lar servere utføre TLS håndtrykk, mens den private nøkkelen til sertifikatet er lagret på et sikkert sted.

SSL.com tilbyr et bredt utvalg av SSL /TLS serversertifikater for HTTPS-nettsteder.

SAMMENLIGN SSL /TLS SERTIFIKATER

Delegert legitimasjon er digitalt signerte datastrukturer som består av to deler: et gyldighetsintervall og en offentlig nøkkel (sammen med tilhørende signaturalgoritme). De fungerer som en "fullmakt” for serverne som indikerer at de er autorisert til avslutte TLS tilkobling. Prosessen med å utstede delegert legitimasjon er for tiden under standardisering og definert i denne IEFT-utkast. Utkastet definerer bruken av delegert legitimasjon som følger:

"En begrenset delegeringsmekanisme som tillater en TLS peer til å utstede sin egen legitimasjon innenfor rammen av et sertifikat utstedt av en ekstern CA. Disse legitimasjonene gjør det bare mulig for mottakeren av delegasjonen å snakke for navn som CA har autorisert."

Delegert legitimasjon er utformet med det formål å øke sikkerheten. Derfor har de visse egenskaper, som definert i IEFT-utkastet.

• Den maksimale gyldighetsperioden for en delegert legitimasjon er syv (7) dager for å minimere eksponeringen hvis den private nøkkelen kompromitteres. Den korte gyldighetsperioden betyr ikke at sikkerhet for delegert legitimasjon skal tas lett på. Tiltak som er tatt for å beskytte den private nøkkelen til endeenhetssertifikatet bør også gjelde for beskyttelse av DC-er. Disse inkluderer filsystemkontroller, fysisk sikkerhet og maskinvaresikkerhetsmoduler, blant andre. I tillegg skal delegert legitimasjon kun brukes mellom parter som deler et tillitsforhold med hverandre.
• Den delegerte legitimasjonen er kryptografisk bundet til endeenhetssertifikatet. Nærmere bestemt brukes den private nøkkelen til endeenhetssertifikatet til å beregne signaturen til DC via en algoritme spesifisert av legitimasjonen. Signaturen binder effektivt DC til navnene på endeenhetssertifikatet.
• Delegert legitimasjon utstedes av klienten, noe som er mye enklere enn å lage et sertifikat signert av en CA. Klientutstedte sertifikater er også nyttige for å holde tjenesten i gang selv om CA har nedetid. Organisasjoner kan også eksperimentere med algoritmer som ikke offisielt støttes av CA uten å kompromittere sikkerheten til endeenhetssertifikatet. 
• Delegert legitimasjon har per definisjon korte gyldighetsperioder. Når du angir levetiden til delegert legitimasjon, må servere ta hensyn til klientens klokkeskjevhet for å unngå avvisning av sertifikater. Klientklokkeskjevhet er også viktig for det originale sertifikatet, men er avgjørende for den kortvarige delegerte private nøkkelen. Klientklokkeskjevhet bør tas i betraktning både i begynnelsen og slutten av gyldighetsperioden.
• Det er ingen tilbakekallingsmekanisme for delegert legitimasjon. De blir gjort ugyldige når gyldighetsperioden utløper. Tilbakekalling av den private nøkkelen til endeenhetssertifikatet (som brukes til å signere den delegerte legitimasjonen) trekker imidlertid implisitt tilbake den delegerte legitimasjonen. 
• Delegert legitimasjon er designet for å brukes i TLS 1.3 eller senere. Det er en kjent sårbarhet når TLS 1.2-servere støtter RSA-nøkkelutveksling, som tillater smiing av en RSA-signatur over en vilkårlig melding. Anta at en angriper er i stand til å forfalske en signatur. I så fall kan de opprette forfalsket delegert legitimasjon for hele gyldighetsperioden til sluttenhetssertifikatet. Denne sårbarheten er ikke til stede i implementeringer av TLS 1.3 eller senere. Også, sårbarheten påvirker ikke sertifikater med elliptisk kurvekryptografi, som SSL.com gir. 
• Organisasjoner kan bruke eksisterende automatiserte utstedelses-APIer som ACME for å levere delegert legitimasjon. I dette tilfellet er algoritmene som brukes bare de som støttes av CA, men denne praksisen reduserer muligheten for viktige kompromisser. SSL.com støtter denne praksisen. 
• Delegert legitimasjon kan ikke gjenbrukes i flere sammenhenger. Utstedende parter beregner signaturen ved å bruke en kontekststreng som er unik for den tiltenkte rollen (klient eller server), og gjør dermed bruken av den samme delegerte legitimasjonen for klient- og serverautentisering umulig. 

SSL.com støtter bruk av delegert legitimasjon for alle klienter. Utstedelse av sertifikater med delegert legitimasjon kan gjøres ved bruk av APIer for automatisering ved bruk av ACME-protokollen. Siden SSL.com bruker ECDSA for å implementere PKI tilbudt til klienter, delegert legitimasjon utstedt av våre klienter er ikke sårbare for signaturforfalskningsangrep, som beskrevet ovenfor.     

Med SSL.coms implementering av ACME, kan alle våre kunder ta fordel av denne populære protokollen til automatiser enkelt SSL/TLS nettstedssertifikatutstedelse og fornyelse.

Lær mer om ACME SSL/TLS Automatisering

SSL.com tilbyr et bredt utvalg av SSL /TLS serversertifikater for HTTPS-nettsteder.

SAMMENLIGN SSL /TLS SERTIFIKATER