SSL /TLS Bedste praksis for 2023

I 2023 sikres dit websted med en SSL /TLS certifikat er ikke længere valgfrit, selv for virksomheder, der ikke har direkte at gøre med følsomme kundeoplysninger på nettet. Søgemaskiner som Google bruger websidesikkerhed som et SEO-rangsignal, og populære webbrowsere som Chrome advarer brugere om websteder, der ikke bruger HTTPS:

Udsigten til at konfigurere dine webservere og applikationer til at bruge SSL /TLS protokol korrekt kan føles skræmmende, da der er mange arcane konfiguration og design valg at tage. Denne vejledning giver en hurtig oversigt over de vigtigste punkter, du skal huske på, når du opretter SSL /TLS til dit websted, mens du fokuserer på både sikkerhed og ydeevne. Der er stadig meget at dække med bare det grundlæggende, så vi har opdelt det i en række trin.

Vælg en pålidelig certifikatmyndighed (CA)

Dine certifikater er kun så pålidelige som den CA, der udsteder dem. Alle offentligt tillidte CA'er er underlagt streng tredjepartsrevision for at opretholde deres position i større operativsystem- og browser rodcertifikatprogrammer, men nogle er bedre til at opretholde denne status end andre. Kig efter en CA, der (som SSL.com):

• Gør det meste af sin virksomhed inden for offentligt tillid PKI. Disse virksomheder har mest at tabe, hvis dårlig sikkerhedspraksis kommer frem, og alt at vinde ved at følge med udviklende industristandarder.
• Reagerer effektivt og effektivt på sårbarhedsopdagelser, der påvirker brugersikkerhed og privatliv, såsom industrien serienummer entropi udgave af begyndelsen af ​​2019. Søg i branchefora som mozilla.dev.sikkerhed.politik kan give dig en god idé om, hvordan en bestemt CA reagerer på modgang.
• Tilbyder nyttige produkter og tjenester, såsom udvidet validering (EV) -certifikater, bulk / automatiseret certifikatudstedelse via en intuitiv API eller ACME-protokol, nem certificering af livscyklusstyrings- og overvågningstjenester og support til integration med en omfattende liste over tredjepartsløsninger.
• Har et ry for stor kundeservice og teknisk support. Det er vigtigt at beskytte din virksomheds hjemmeside 100% af tiden, og du skal være i stand til at få en rigtig ekspert på telefonen, når tingene går galt.

Certifikatautoritetstilladelse (CAA)

Certifikatautoritetstilladelse (CAA) er en standard til beskyttelse af websteder ved at udpege specifikke CA'er, der har tilladelse til at udstede certifikater for et domænenavn. Når du har valgt en CA, skal du overveje konfigurering af CAA-poster at autorisere det.

Generer og sikret dine private nøgler

SSL /TLS protokol bruge til par nøgler til at autentificere identiteter og kryptere oplysninger sendt via Internettet. En af disse (the offentlig nøgle) er beregnet til bred distribution og den anden (the privat nøgle) skal opbevares så sikkert som muligt. Disse taster oprettes sammen, når du genererer en anmodning om underskrivelse af certifikat (CSR). Her er et par tip, som du skal huske på med dine private nøgler:

• Brug stærke private taster: Større taster er sværere at knække, men kræver mere computerkostnader. I øjeblikket anbefales mindst en 2048-bit RSA-nøgle eller 256-bit ECDSA-nøgle, og de fleste websteder kan opnå god sikkerhed, mens de optimerer ydelsen og brugeroplevelsen med disse værdier.
  
  Bemærk: for en oversigt over disse to algoritmer, se SSL.coms artikel, Sammenligning af ECDSA vs RSA.
• Beskyt dine private nøgler:
  • Generer dine egne private nøgler i et sikkert og pålideligt miljø (fortrinsvis på serveren, hvor de vil blive distribueret eller en FIPS eller en fælles kompatibel enhed). Aldrig tillad en CA (eller nogen anden) at generere private nøgler på dine vegne. En velrenommeret offentlig CA, såsom SSL.com, vil aldrig tilbyde at generere eller håndtere dine private nøgler, medmindre de genereres i et sikkert hardwaretoken eller HSM og ikke kan eksporteres.
  • Giv kun adgang til private nøgler efter behov. Generer nye taster og tilbagekalde alle certifikater for de gamle nøgler, når medarbejdere med adgang til privat nøgle forlader virksomheden.
  • Forny certifikater så ofte som praktisk muligt (i det mindste årligt ville være godt), helst ved hjælp af en friskgenereret privat nøgle hver gang. Automatiseringsværktøjer som ACME-protokol er nyttige til planlægning af hyppige fornyelser af certifikater.
  • Hvis en privat nøgle er blevet (eller måske blevet) kompromitteret, tilbagekalde alle certifikater til denne nøgle, generer et nyt nøglepar, og udsted et nyt certifikat til det nye nøglepar.

Konfigurer din server

På overfladen, installation af en SSL /TLS certifikat kan virke som en ligetil operation; dog er der stadig mange mange konfigurationsbeslutninger, der skal træffes for at sikre, at din webserver er hurtig og sikker, og at slutbrugere har en glat oplevelse, der er fri for browserfejl og advarsler. Her er nogle konfigurationsmarkører, der hjælper dig med at komme på rette spor, når du opretter SSL /TLS på dine servere:

• Sørg for, at alle værtsnavne er dækket: Dækker dit certifikat dit websteds domænenavn både med og uden www præfiks? er der en Emne alternativt navn (SAN) for hvert domænenavn er certifikatet beregnet til at beskytte?
• Installer komplette certifikatkæder: End-entity SSL /TLS certifikater er generelt underskrevet af mellemliggende certifikater snarere end en CA's rodnøgle. Sørg for, at eventuelle mellemliggende certifikater er installeret på din webserver for at give browsere en komplet certificeringssti og undgå tillidsadvarsler og fejl for slutbrugere. Din CA vil være i stand til at give dig alle nødvendige mellemprodukter; SSL.coms kunder kan bruge vores Mellemcertifikat Download side for at hente mellemliggende bundter til mange serverplatforme.
• Brug nuværende SSL /TLS Protokoller (TLS 1.2 eller 1.3): I slutningen af ​​2018 annoncerede alle større browserudbydere planer om at afskrives TLS 1.0 og 1.1 inden første halvdel af 2020. Google forældet TLS v1.0 og v1.1 i Chrome 72 (udgivet 30. januar 2919). Chrome-versioner 84 (frigivet 14. juli 2020) og nyere præsenterer en mellemliggende advarsel for disse protokoller, og support var planlagt til at være helt fjernet i maj 2021. Udbredt browsersupport til tidligere SSL /TLS versioner, såsom SSL v3, er længe væk. Mens TLS 1.2 er i øjeblikket den mest anvendte version af SSL /TLS protokol, TLS 1.3 (den nyeste version) er allerede understøttet i de aktuelle versioner af de fleste større webbrowsere.
• Brug en kort liste over Secure Cipher Suites: Vælg kun chiffer suiter, der tilbyder mindst 128-bit kryptering eller stærkere, når det er muligt. National Institute of Standards and Technology (NIST) anbefaler også, at det hele TLS implementeringer bevæger sig væk fra krypteringssuiter, der indeholder DES-kryptering (eller dens varianter) til dem, der bruger AES. Endelig minimerer brugen af ​​kun en lille delmængde af potentielt acceptable chifferpakker angrebsoverfladen for endnu uopdagede sårbarheder. Tillægget til SSL.com's Guide til TLS Standarder Overholdelse giver eksempler på konfigurationer til de mest populære webserverplatforme ved hjælp af TLS 1.2.
  
  Bemærk: Brug af usikre, forældede cifre (som RC4) kan forårsage browsersikkerhedsfejl, f.eks ERR_SSL_VERSION_OR_CIPHER_MISMATCH i Google Chrome.
• Brug fremadretthed (FS): Også kendt som perfekt fremadretthed (PFS), FS forsikrer, at en kompromitteret privat nøgle ikke også kommer på kompromis med tidligere sessionstaster. Sådan aktiveres FS:
  • Konfigurer TLS 1.2 til at bruge den Elliptic Curve Diffie-Hellman (EDCHE) nøgleudvekslingsalgoritme (med DHE som et tilbageslag), og undgå RSA-nøgleudveksling fuldstændigt, hvis det er muligt.
  • Brug TLS 1.3. TLS 1.3 giver fremadrettet hemmelighed for alle TLS sessioner via the Ephemeral Diffie-Hellman (EDH eller DHE) nøgleudvekslingsprotokol.
• Aktiver TLS Genoptagelse af session: På samme måde som at bruge keepalives til at opretholde vedvarende TCP-forbindelser, TLS genoptagelse af session tillader din webserver at holde styr på nyligt forhandlet SSL /TLS sessioner og genoptag dem ved at omgå den beregningsmæssige omkostning ved forhandling af sessionnøgler.
• Overvej OCSP hæftning: OCSP hæftning tillader webservere at levere cachelagrede tilbagekaldelsesoplysninger direkte til klienten, hvilket betyder, at en browser ikke behøver at kontakte en OCSP-server for at kontrollere, om et websteds certifikat er tilbagekaldt. Ved at fjerne denne anmodning tilbyder OCSP hæftning et ægte ydeevne boost. For mere information, læs vores artikel, Optimering af sideindlæsning: OCSP hæftning.

Brug bedste praksis til design af webapplikationer

At designe dine webapplikationer med sikkerhed i tankerne er lige så vigtigt som at konfigurere din server korrekt. Dette er de vigtigste punkter for at sikre, at dine brugere ikke udsættes for mand i midten angreb, og at din ansøgning får de SEO-fordele, der følger med god sikkerhedspraksis:

• Fjern blandet indhold: JavaScript-filer, billeder og CSS-filer skal alle få adgang til med SSL /TLS. Som beskrevet i SSL.coms artikel, HTTPS Everywhere, betjener blandet indhold er ikke længere en acceptabel måde at øge hjemmesidens ydelse og kan resultere i browsersikkerhedsadvarsler og SEO-problemer.
• Brug sikre cookies: Indstilling af Secure flag i cookies vil håndhæve transmission over sikre kanaler (f.eks. HTTPS). Du kan også forhindre JavaScript fra klientsiden i at få adgang til cookies via HttpOnly markere og begrænse brug af cookies på tværs af websteder med SameSite flag.
• Evaluer tredjeparts kode: Sørg for at forstå de potentielle risici ved at bruge tredjepartsbiblioteker på dit websted, såsom muligheden for utilsigtet at indføre sårbarheder eller ondsindet kode. Dyrlæge altid tredjeparts troværdighed efter bedste evne og link til al tredjepartskode med HTTPS. Endelig skal du sørge for, at din fordel af tredjepartselementer på dit websted er risikoen værd.

Kontroller dit arbejde med diagnoseværktøjer

Efter opsætning af SSL /TLS på din server og dit websted eller foretager konfigurationsændringer, er det vigtigt at sikre dig, at alt er konfigureret korrekt, og at dit system er sikkert. Talrige diagnostiske værktøjer er tilgængelige til kontrol af dit websteds SSL /TLS. For eksempel SSL-shoppers SSL-kontrol vil fortælle dig, om dit certifikat er korrekt installeret, hvornår det udløber, og viser certifikatets kæde af tillid.

Andre online værktøjer og applikationer er tilgængelige, der gennemsøger dit websteds kontrol for sikkerhedsproblemer som blandet indhold. Du kan også kontrollere for blandet indhold med en webbrowser ved hjælp af dets indbyggede udviklerværktøjer:

Uanset hvilket værktøj du vælger, er det også vigtigt at indstille en tidsplan for kontrol af din SSL /TLS installation og konfiguration. Din CA kan muligvis også hjælpe dig med dette; For eksempel, som en bekvemmelighed for vores kunder, leverer SSL.com automatiske meddelelser om forestående certifikatudløb.

Implementer HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security (HSTS) er en sikkerhedspolitikmekanisme, der hjælper med at beskytte websteder mod protokolnedgraderingsangreb og cookiekapring. Det giver webservere mulighed for at erklære, at webbrowsere (eller andre overholdende brugeragenter) kun bør interagere med den ved hjælp af sikre HTTPS-forbindelser og aldrig via den usikre HTTP-protokol. Denne politik kommunikeres af serveren til brugeragenten via et HTTP-svar-headerfelt med navnet "Strict-Transport-Security".

At implementere HTTP Strict Transport Security (HSTS), skal du tilføje en speciel svarheader til din webservers konfiguration.

Her er en trin-for-trin guide:

1. Sørg for, at dit websted understøtter HTTPS: Før du aktiverer HSTS, skal dit websted have en gyldig SSL-certifikat og være i stand til at servere indhold over HTTPS. Hvis dit websted endnu ikke er konfigureret til HTTPS, skal du gøre det få et SSL-certifikat og konfigurer din server til at bruge den.

Header indstilles altid Strict-Transport-Security "max-age=31536000; includeSubDomains"

_{Denne linje fortæller browseren, at den altid skal bruge HTTPS til dit websted i det næste år (31,536,000 sekunder), inklusive alle underdomæner.}

2. Test din konfiguration: Når du har tilføjet HSTS-headeren, bør du teste dit websted for at sikre, at det fungerer korrekt. Du kan gøre dette ved at besøge dit websted og bruge din browsers udviklerværktøjer til at tjekke svaroverskrifterne. Du bør se overskriften Strict-Transport-Security med den værdi, du har angivet.
3. Overvej at tilføje dit websted til HSTS-forudindlæsningslisten: HSTS-preload-listen er en liste over websteder, der er hardkodet i browsere som HSTS-aktiverede. Dette giver et ekstra niveau af beskyttelse, da det sikrer, at den første forbindelse til dit websted er sikker, selv før HSTS-headeren modtages. Du kan indsende dit websted til HSTS preload-listen på hstspreload.org.

Use Case: Et nyhedswebsted ønsker at sikre, at dets brugere altid forbinder til det sikkert, selvom de ved et uheld skriver "http" i stedet for "https" i URL'en. Hjemmesiden bruger HSTS ved at tilføje Strict-Transport-Security-headeren til sin serverkonfiguration, indstille en lang max-alder og inkludere alle underdomæner. Dette fortæller brugeragenter, at de altid skal oprette forbindelse til den ved hjælp af HTTPS, hvilket beskytter brugere mod angreb, der forsøger at nedgradere forbindelsen til HTTP og stjæle deres cookies. Hjemmesiden underkaster sig også HSTS preload-listen for ekstra beskyttelse.

Implementer HTTP Public Key Pinning (HPKP)

HTTP Public Key Pinning (HPKP) var en sikkerhedsfunktion, der gjorde det muligt for en webserver at knytte en bestemt kryptografisk offentlig nøgle til sig selv for at forhindre mand-i-midten-angreb (MITM) angreb med forfalskede certifikater.

Her er en kort oversigt over, hvordan det blev brugt:

1. Generer pinningsoplysninger: Det første trin i implementeringen af ​​HPKP var at generere pinningsoplysningerne. Dette involverede oprettelse af en kryptografisk hash af certifikatets offentlige nøgle eller den offentlige nøgle til mellem- eller rodcertifikatet.
2. Konfigurer webserveren: Det næste trin var at konfigurere webserveren til at inkludere Public-Key-Pins HTTP header i svar. Denne header inkluderede hasherne for de offentlige nøgler ("pins"), en tid at leve (hvor længe browseren skal huske oplysningerne), og eventuelt en rapport-URI (hvor browseren ville sende rapporter om pin-valideringsfejl).
3. Håndtag pin-valideringsfejl: Hvis en browser, der understøttede HPKP, modtog en certifikatkæde, der ikke indeholdt mindst én af de fastgjorte offentlige nøgler, ville den betragte forbindelsen som upålidelig. Hvis en rapport-URI blev angivet, ville browseren også sende en rapport om fejlen til denne URI.

Men på grund af risikoen for misbrug og potentialet for at forårsage lammelsesangreb, er HPKP blevet forældet af de fleste browsere og er ikke længere en anbefalet praksis. Fejlkonfiguration af HPKP kan føre til en situation, hvor et websted bliver utilgængeligt.

Use Case: Tidligere brugte et teknologifirma HPKP til at fastgøre deres offentlige nøgler til deres servere. Dette sikrede, at hvis en certifikatmyndighed (CA) blev kompromitteret, og et certifikat ved en fejl blev udstedt for deres domæne, ville browsere ikke stole på det, medmindre det også havde en offentlig nøgle, der matchede en af ​​de fastgjorte nøgler. De skulle dog være meget forsigtige med at undgå at miste adgangen til de fastgjorte nøgler, hvilket ville gøre deres hjemmeside utilgængelig. De skulle også sikre, at de havde en proces på plads til at rotere stifterne, før de udløb, for at undgå at gøre deres websted utilgængeligt for brugere med cachelagrede pinningsoplysninger.

Brug TLS Fallback SCSV for at forhindre protokolnedgraderingsangreb

TLS Fallback SCSV (Signalering af Cipher Suite-værdi) er en mekanisme, der blev introduceret for at forhindre protokolnedgraderingsangreb. Disse angreb opstår, når en angriber griber ind i forbindelsesopsætningsprocessen og narrer klienten og serveren til at bruge en mindre sikker version af protokollen, end de begge rent faktisk understøtter.

Her er hvordan du kan implementere TLS Alternativ SCSV:

1. Opdater din servers SSL/TLS Bibliotek: Det første trin er at sikre, at din servers SSL/TLS biblioteket understøtter TLS Fallback SCSV. Denne funktion blev introduceret i OpenSSL 1.0.1j, 1.0.0o og 0.9.8zc. Hvis du bruger en anden SSL/TLS biblioteket, tjek dets dokumentation eller kontakt dets udviklere.
2. Konfigurer din server: Når din servers SSL/TLS biblioteket understøtter TLS Fallback SCSV, du skal muligvis konfigurere din server til at bruge den. De nøjagtige trin afhænger af din serversoftware. For eksempel, i Apache skal du muligvis tilføje eller ændre en linje i din konfigurationsfil som denne:

SSLProtocol Alle -SSLv2 -SSLv3

Denne linje fortæller serveren at bruge alle protokolversioner undtagen SSLv2 og SSLv3. Hvis klienten og serveren begge understøtter TLS 1.2, men klienten forsøger at bruge TLS 1.1 (måske på grund af en hackers interferens), vil serveren genkende dette som et fallback-forsøg og afvise forbindelsen.

3. Test din server: Efter at have konfigureret din server, bør du teste den for at sikre, at den implementeres korrekt TLS Fallback SCSV. Der er forskellige online værktøjer, der kan hjælpe dig med dette, såsom SSL Labs Server Test.

Use Case: En global virksomhed bruger TLS Fallback SCSV for at beskytte sin interne kommunikation. Dette sikrer, at hvis en hacker forsøger at tvinge en protokolnedgradering, vil serveren genkende dette og afvise forbindelsen, hvilket beskytter virksomhedens følsomme data. Virksomhedens IT-team opdaterer regelmæssigt deres serveres SSL/TLS biblioteker og konfigurationer for at sikre, at de bruger de nyeste sikkerhedsfunktioner, og de bruger onlineværktøjer til at teste deres servere og bekræfte, at de implementerer korrekt TLS Fallback SCSV.

Undgå problemer med blandet indhold

Blandet indhold er en sikkerhedsrisiko, der opstår, når en webside indlæst via en sikker HTTPS-forbindelse inkluderer ressourcer, såsom billeder, videoer, stylesheets eller scripts, der indlæses via en usikker HTTP-forbindelse. Browsere kan blokere dette blandede indhold eller vise en advarsel til brugeren, hvilket kan skade brugerens opfattelse af webstedets sikkerhed.

Sådan undgår du problemer med blandet indhold:

1. Brug HTTPS til alle ressourcer: Den mest ligetil måde at undgå blandet indhold på er at sikre, at alle ressourcer på dit websted indlæses via HTTPS. Dette inkluderer billeder, scripts, stylesheets, iframes, AJAX-anmodninger og alle andre ressourcer, som dit websted bruger.
2. Opdater dit websteds kode: Hvis dit websteds kode indeholder hårdkodede HTTP-URL'er til ressourcer, skal du opdatere disse for at bruge HTTPS i stedet. Hvis ressourcen er hostet på en server, der ikke understøtter HTTPS, skal du muligvis hoste ressourcen på din egen server eller finde en alternativ ressource, der kan indlæses over HTTPS.
3. Konfigurer din server til at sende en Content-Security-Policy Header: Content-Security-Policy (CSP) HTTP-headeren giver dig mulighed for at kontrollere, hvilke ressourcer dit websted må indlæse. Ved at indstille en CSP-header, der kun tillader HTTPS-ressourcer, kan du sikre, at dit websted ikke ved et uheld inkluderer blandet indhold.

Use Case: Et onlinemagasin sikrer, at alt indhold, inklusive billeder og scripts, indlæses over HTTPS. Dette forhindrer angribere i at manipulere med disse ressourcer og potentielt injicere skadeligt indhold. Magasinets webudviklere gennemgår jævnligt webstedets kode for at sikre, at alle ressourcer indlæses over HTTPS, og de konfigurerer deres server til at sende en streng Content-Security-Policy-header. De bruger også onlineværktøjer til at scanne deres websted for problemer med blandet indhold og rette alt, hvad de finder.

Brug servernavnindikation (SNI) til hosting af flere websteder

Servernavn indikation (SNI) er en udvidelse til TLS protokol, der tillader en server at præsentere flere certifikater på samme IP-adresse og portnummer. Dette er især nyttigt for webhostingudbydere, der skal hoste flere sikre websteder, hver med deres eget SSL-certifikat, på den samme server.

Sådan kan du bruge SNI:

1. Sørg for, at din serversoftware understøtter SNI: Det første trin er at sikre, at din serversoftware understøtter SNI. De fleste moderne webservere, inklusive Apache, Nginx og IIS, understøtter SNI.
2. Konfigurer din server: Det næste trin er at konfigurere din server til at bruge SNI. Dette involverer typisk tilføjelse af en separat konfigurationsblok for hvert websted, som du vil være vært for på serveren, og specificering af SSL-certifikat at bruge for hvert websted. De nøjagtige trin afhænger af din serversoftware.
3. Test din konfiguration: Efter at have konfigureret din server, bør du teste den for at sikre, at den bruger SNI korrekt. Du kan gøre dette ved at besøge hvert websted, du hoster på serveren, og kontrollere, at det korrekte SSL-certifikat bliver brugt.

Use Case: En hostingudbyder bruger SNI til at betjene flere websteder fra den samme IP-adresse. Dette giver dem mulighed for effektivt at bruge deres IP-adresserum og forenkle deres netværkskonfiguration. De konfigurerer deres server til at bruge et andet SSL-certifikat for hvert websted, og de tester regelmæssigt deres konfiguration for at sikre, at det korrekte certifikat bruges til hvert websted. Dette sikrer, at hvert websted har en sikker, pålidelig forbindelse, selvom de alle betjenes fra den samme IP-adresse.

Optimer ydeevnen med genoptagelse af session

Genoptagelse af session er et træk ved TLS protokol, der tillader en klient og server at bruge de samme krypteringsnøgler på tværs af flere sessioner, hvilket reducerer omkostningerne ved at etablere en ny sikker forbindelse hver gang. Dette kan forbedre ydeevnen markant, især for applikationer, hvor klienten ofte afbryder og genopretter forbindelsen.

 Sådan kan du bruge genoptagelse af session:

1. Sørg for, at din serversoftware understøtter genoptagelse af session: Det første trin er at sikre, at din serversoftware understøtter genoptagelse af session. De fleste moderne webservere, inklusive Apache, Nginx og IIS, understøtter denne funktion.
2. Konfigurer din server: Det næste trin er at konfigurere din server til at bruge sessionsgenoptagelse. Dette involverer typisk aktivering af sessionscachen og indstilling af en timeoutværdi for cachen. De nøjagtige trin afhænger af din serversoftware.
3. Test din konfiguration: Efter at have konfigureret din server, bør du teste den for at sikre, at den bruger sessiongenoptagelse korrekt. Det kan du gøre ved at oprette en TLS forbindelse til din server, afbryde forbindelsen og derefter genoprette forbindelsen. Hvis genoptagelse af sessionen fungerer korrekt, bør den anden forbindelse være hurtigere at etablere end den første.

Use Case: En mobilapp bruger genoptagelse af sessioner til at opretholde hurtige og sikre forbindelser. Dette er især nyttigt, når appen bruges i områder med plettet netværksdækning, da det giver appen mulighed for hurtigt at genetablere en sikker forbindelse efter et frafald. Appens udviklere konfigurerer deres server til at bruge sessionsgenoptagelse, og de tester regelmæssigt funktionen for at sikre, at den fungerer korrekt. Dette sikrer, at appen kan give brugerne en hurtig, problemfri oplevelse, selv under udfordrende netværksforhold.

Sikre certifikatets gyldighed med OCSP-hæftning

Online Certificate Status Protocol (OCSP) hæftning er en metode til at forbedre ydeevnen af ​​SSL/TLS samtidig med at forbindelsens sikkerhed bevares. Det giver serveren mulighed for at hente den aktuelle status for sine egne certifikater fra Certificate Authority (CA) og derefter levere denne status til klienter under TLS håndtryk.

Sådan kan du implementere OCSP-hæftning:

1. Sørg for, at din serversoftware understøtter OCSP-hæftning: Det første trin er at sikre, at din serversoftware understøtter OCSP-hæftning. De fleste moderne webservere, inklusive Apache, Nginx og IIS, understøtter denne funktion.
2. Konfigurer din server: Det næste trin er at konfigurere din server til at bruge OCSP-hæftning. Dette involverer typisk at aktivere funktionen i din servers SSL/TLS konfiguration og angivelse af en placering for serveren til at gemme OCSP-svarene. De nøjagtige trin afhænger af din serversoftware.
3. Test din konfiguration: Når du har konfigureret din server, bør du teste den for at sikre, at den bruger OCSP-hæftning korrekt. Det kan du gøre ved at oprette en TLS forbindelse til din server og kontrollere, at serveren indeholder et OCSP-svar i TLS håndtryk.

Use Case: En online forhandler bruger OCSP-hæftning til hurtigt at bekræfte status for sit SSL-certifikat. Dette sikrer, at kunderne altid har en sikker forbindelse og kan stole på, at deres data er sikre. Forhandlerens it-team konfigurerer deres server til at bruge OCSP-hæftning, og de tester regelmæssigt funktionen for at sikre, at den fungerer korrekt. Dette hjælper med at bevare deres kunders tillid og beskytte deres følsomme data.

Deaktiver TLS Kompression for at afbøde CRIME-angreb

TLS komprimering er en funktion, der kan forbedre ydeevnen af ​​SSL/TLS ved at reducere mængden af ​​data, der skal sendes over netværket. Det kan dog også gøre forbindelsen sårbar over for CRIME (Compression Ratio Info-leak Made Easy) angrebet, som kan give en angriber mulighed for at udlede indholdet af krypteret trafik.

Sådan kan du deaktivere TLS komprimering: 

1. Sørg for, at din serversoftware understøtter deaktivering TLS Compression: Det første trin er at sikre, at din serversoftware understøtter deaktivering TLS kompression. De fleste moderne webservere, inklusive Apache, Nginx og IIS, understøtter denne funktion.
2. Konfigurer din server: Det næste trin er at konfigurere din server til at deaktivere TLS kompression. De nøjagtige trin afhænger af din serversoftware. For eksempel kan du i Apache tilføje en linje som denne til din konfigurationsfil:

SSLCompression slået fra

Denne linje fortæller serveren ikke at bruge komprimering til SSL/TLS forbindelser.

3. Test din konfiguration: Efter at have konfigureret din server, bør du teste den for at sikre, at den deaktiverer korrekt TLS kompression. Det kan du gøre ved at oprette en TLS forbindelse til din server og kontrollere, at forbindelsen ikke bruger komprimering.

Use Case: En finansiel institution deaktiverer TLS komprimering på sine servere for at beskytte mod CRIME-angrebet. Dette er med til at sikre fortroligheden af ​​følsomme finansielle data, såsom kontonumre og transaktionsoplysninger. Institutionens it-team konfigurerer deres servere til at deaktivere TLS komprimering, og de tester regelmæssigt serverne for at sikre, at de implementerer denne sikkerhedsforanstaltning korrekt. Dette er med til at beskytte institutionens kunder og bevare deres tillid.

Implement TLS Sessionsbilletter korrekt

TLS session billetter er en funktion af TLS protokol, der kan forbedre ydeevnen ved at tillade en klient og server at genoptage en tidligere session uden at skulle udføre et fuldt håndtryk. De skal dog implementeres korrekt for at undgå potentielle sikkerhedsproblemer.

Her er, hvordan du kan implementere korrekt TLS session billetter:

1. Sørg for, at din serversoftware understøtter TLS Sessionsbilletter: Det første trin er at sikre, at din serversoftware understøtter TLS session billetter. De fleste moderne webservere, inklusive Apache, Nginx og IIS, understøtter denne funktion.
2. Konfigurer din server: Det næste trin er at konfigurere din server til brug TLS session billetter. Dette involverer typisk at aktivere funktionen i din servers SSL/TLS konfiguration. De nøjagtige trin afhænger af din serversoftware.
3. Brug unikke sessionsbilletnøgler: For at forhindre potentielle sikkerhedsproblemer skal hver server bruge en unik sessionsbilletnøgle. Hvis du bruger en belastningsbalancer, bør du konfigurere den til at distribuere klienter baseret på deres sessionsbillet i stedet for at tillade klienter at bruge en sessionsbillet udstedt af én server til at etablere en session med en anden server.
4. Roter Session Ticket Keys regelmæssigt: For yderligere at øge sikkerheden bør du regelmæssigt rotere dine sessionsbilletnøgler. Dette kan ofte automatiseres ved hjælp af din serversoftware eller et separat nøglestyringssystem.

Use Case: Et stort teknologifirma med flere servere sikrer, at hver server bruger en unik sessionsbilletnøgle. Dette forhindrer en angriber i at kunne bruge en sessionsbillet fra én server til at efterligne en bruger på en anden server. Virksomhedens IT-team konfigurerer deres servere til brug TLS sessionsbilletter, og de sætter et system op til regelmæssigt at rotere sessionsbilletnøglerne. De konfigurerer også deres load balancer til at distribuere klienter baseret på deres sessionsbillet, hvilket yderligere forbedrer sikkerheden i deres system.

Aktiver sikker genforhandling

Sikker genforhandling er en funktion af SSL/TLS protokoller, der tillader klienten eller serveren at anmode om en ny TLS håndtryk midt i en session. Dette kan være nyttigt af en række forskellige årsager, såsom at opdatere krypteringsnøgler eller ændre krypteringsniveauet. Men hvis den ikke håndteres sikkert, kan den blive udnyttet af en angriber til at injicere almindelig tekst i den krypterede kommunikation.

Sådan kan du aktivere sikker genforhandling:

2. Sørg for, at din serversoftware understøtter sikker genforhandling: Det første skridt er at sikre, at din serversoftware understøtter sikker genforhandling. De fleste moderne webservere, inklusive Apache, Nginx og IIS, understøtter denne funktion.
3. Konfigurer din server: Det næste trin er at konfigurere din server til at bruge sikker genforhandling. Dette involverer typisk at aktivere funktionen i din servers SSL/TLS konfiguration. De nøjagtige trin afhænger af din serversoftware.
4. Test din konfiguration: Når du har konfigureret din server, bør du teste den for at sikre, at den bruger sikker genforhandling korrekt. Det kan du gøre ved at oprette en TLS forbindelse til din server og derefter forsøge at genforhandle forbindelsen.

Use Case: En social medieplatform muliggør sikker genforhandling for at beskytte brugerdata. Dette forhindrer en angriber i at kunne injicere ondsindet indhold i den krypterede kommunikation mellem brugeren og serveren. Platformens it-team konfigurerer deres servere til at bruge sikker genforhandling, og de tester regelmæssigt serverne for at sikre, at de implementerer denne sikkerhedsforanstaltning korrekt. Dette er med til at beskytte platformens brugere og bevare deres tillid.

Deaktiver klient-initieret genforhandling for at forhindre DoS-angreb

Klientinitieret genforhandling er en funktion af SSL/TLS protokoller, der giver klienten mulighed for at anmode om en ny TLS håndtryk midt i en session. Men hvis en angriber kan tvinge en server til løbende at genforhandle sessioner, kan den forbruge for store ressourcer og potentielt føre til et denial-of-service (DoS) angreb.

Sådan kan du deaktivere klientinitieret genforhandling:

1. Sørg for, at din serversoftware understøtter deaktivering af klient-initieret genforhandling: Det første trin er at sikre, at din serversoftware understøtter deaktivering af klient-initieret genforhandling. De fleste moderne webservere, inklusive Apache, Nginx og IIS, understøtter denne funktion.
2. Konfigurer din server: Det næste trin er at konfigurere din server til at deaktivere klient-initieret genforhandling. Dette involverer typisk tilføjelse af et direktiv til din servers SSL/TLS konfiguration. De nøjagtige trin afhænger af din serversoftware.
3. Test din konfiguration: Efter at have konfigureret din server, bør du teste den for at sikre, at den korrekt deaktiverer klient-initieret genforhandling. Det kan du gøre ved at oprette en TLS forbindelse til din server og derefter forsøge at genforhandle forbindelsen. Hvis serveren korrekt afviser genforhandlingsanmodningen, er den korrekt konfigureret.

Use Case: En online spilleplatform deaktiverer klientinitieret genforhandling for at beskytte mod potentielle DoS-angreb. Dette er med til at sikre, at platformen forbliver tilgængelig for brugere at nyde, selv i lyset af potentielle angreb. Platformens it-team konfigurerer deres servere til at deaktivere klient-initieret genforhandling, og de tester regelmæssigt serverne for at sikre, at de implementerer denne sikkerhedsforanstaltning korrekt. Dette er med til at beskytte platformens brugere og bevare deres tillid.

Vær opmærksom på nye sårbarheder

Websikkerhed er et mål, der bevæger sig konstant, og du skal altid være på udkig efter det næste angreb og straks anvende sikkerhedsrettelser på din server. Dette betyder at læse og holde kontakten med, hvad der er i horisonten, når det kommer til informationssikkerhed samt holde styr på softwareopdateringer - især de kritiske. SSL.com's websted (hvor du læser dette lige nu) er en god kilde til at holde dig opdateret om SSL /TLS og informationssikkerhed.

Men hvad med ...?

Hvis du gerne vil vide mere om et af emnerne i denne vejledning og lære om nye problemer og teknologier, når de opstår, kan du starte med at gennemse og søge i SSL.com's Vidensdatabase, som vi holder opdateret ugentligt med nye udviklinger inden for SSL /TLS , PKI. Du kan også være velkommen til at kontakte vores supportpersonale når som helst via e-mail på Support@SSL.com, i telefonen kl 1-877-SSL-Secureeller ved at klikke på chatlinket nederst til højre på denne side.

Få ekspertrådgivning om SSL-certifikater.
Udfyld formularen for en konsultation.