SSL /TLS Beste praksis for 2023

I 2023, sikre nettstedet ditt med en SSL /TLS sertifikat er ikke lenger valgfritt, selv for bedrifter som ikke håndterer sensitiv kundeinformasjon på nettet direkte. Søkemotorer som Google bruker nettstedssikkerhet som et SEO-rangeringssignal, og populære nettlesere som Chrome varsler brukere om nettsteder som ikke bruker HTTPS:

Utsiktene til å konfigurere webservere og applikasjoner for å bruke SSL /TLS protokollen riktig kan føles skremmende, da det er mange arkane konfigurasjons- og designvalg å gjøre. Denne guiden gir en rask oversikt over hovedpoengene du må huske på når du setter opp SSL /TLS for nettstedet ditt, mens du fokuserer på både sikkerhet og ytelse. Det er fortsatt mye å dekke med bare det grunnleggende, så vi har delt det opp i en serie trinn.

Velg en pålitelig sertifikatmyndighet (CA)

Sertifikatene dine er bare like pålitelige som CA som utsteder dem. Alle offentlig pålitelige CA-er er underlagt strenge tredjepartsrevisjoner for å opprettholde sin posisjon i store operativsystem- og nettlesersertifikatprogrammer, men noen er bedre til å opprettholde den statusen enn andre. Se etter en CA som (som SSL.com):

• Gjør det meste av sin virksomhet innen offentlig tillit PKI. Disse virksomhetene har mest å tape hvis dårlig sikkerhetspraksis kommer fram, og alt å tjene ved å følge med utviklende industristandarder.
• Reagerer effektivt og effektivt på sårbarhetsfunn som påvirker brukersikkerhet og personvern, for eksempel industrien serienummer entropi utgave av begynnelsen av 2019. Søker i bransjeforum som mozilla.dev.sikkerhet.policy kan gi deg en god ide om hvordan en bestemt CA reagerer på motgang.
• Tilbyr nyttige produkter og tjenester, for eksempel utvidet validering (EV) sertifikater, bulk / automatisert sertifikatutstedelse via en intuitiv API eller ACME-protokoll, enkle sertifikat livssyklusadministrasjons- og overvåkingstjenester, og støtte for integrering med en omfattende liste over tredjepartsløsninger.
• Har et rykte for god kundeservice og teknisk support. Det er viktig å holde selskapets nettside 100% av tiden, og du må kunne få en ekte ekspert på telefonen når ting går galt.

Autorisasjon av sertifikatutsteder (CAA)

Autorisasjon av sertifikatutsteder (CAA) er en standard for å beskytte nettsteder ved å utpeke spesifikke CA-er som har lov til å utstede sertifikater for et domenenavn. Når du har valgt en CA, bør du vurdere konfigurere CAA-poster å autorisere det.

Generer og sikr dine private nøkler

De SSL /TLS protokollen bruker a par nøkler for å autentisere identiteter og kryptere informasjon sendt over Internett. En av disse (the offentlig nøkkel) er beregnet for bred distribusjon, og den andre (den privat nøkkel) bør holdes så sikkert som mulig. Disse tastene opprettes sammen når du genererer en sertifikatsigneringsforespørsel (CSR). Her er noen tips du må huske på når det gjelder private nøkler:

• Bruk sterke private nøkler: Større taster er vanskeligere å sprekke, men krever mer databehandlingskostnader. For øyeblikket anbefales minst en 2048-biters RSA-nøkkel eller 256-biters ECDSA-nøkkel, og de fleste nettsteder kan oppnå god sikkerhet mens de optimaliserer ytelsen og brukeropplevelsen med disse verdiene.
  
  OBS: for en oversikt over disse to algoritmene, se SSL.coms artikkel, Sammenligning av ECDSA vs RSA.
• Beskytt dine private nøkler:
  • Generer dine egne private nøkler på et sikkert og pålitelig miljø (helst på serveren der de vil bli distribuert eller en FIPS- eller Common Criteria-kompatibel enhet). aldri la en CA (eller noen andre) generere private nøkler på dine vegne. En anerkjent offentlig CA, som SSL.com, vil aldri tilby å generere eller håndtere dine private nøkler med mindre de genereres i et sikkert maskinvaretoken eller HSM og ikke kan eksporteres.
  • Gi bare tilgang til private nøkler etter behov. Generer nye nøkler og tilbakekalle alle sertifikater for de gamle nøklene når ansatte med tilgang til privat nøkkel forlater selskapet.
  • Forny sertifikater så ofte som praktisk mulig (minst hvert år ville være bra), helst ved å bruke en nygenerert privat nøkkel hver gang. Automatiseringsverktøy som ACME-protokoll er nyttige for planlegging av hyppige sertifikatfornyelser.
  • Hvis en privat nøkkel er blitt kompromittert, tilbakekalle alle sertifikatene for denne nøkkelen, generer et nytt nøkkelpar og utsted et nytt sertifikat for det nye nøkkelparet.

Konfigurer serveren din

På overflaten, installere en SSL /TLS sertifikat kan virke som en grei operasjon; Det er imidlertid fortsatt mange mange konfigurasjonsbeslutninger som må tas for å sikre at webserveren din er rask og sikker, og at sluttbrukere har en jevn opplevelse som er fri for nettleserfeil og advarsler. Her er noen konfigurasjonspekere som hjelper deg med å komme deg på sporet når du setter opp SSL /TLS på serverne dine:

• Forsikre deg om at alle vertsnavn er dekket: Dekker sertifikatet nettstedets domenenavn både med og uten www prefiks? er det en Fagalternativnavn (SAN) for hvert domenenavn sertifikatet er ment å beskytte?
• Installer komplette sertifikatkjeder: Slutt-enhet SSL /TLS sertifikater er vanligvis signert av mellomliggende sertifikater i stedet for en CAs rotnøkkel. Sørg for at eventuelle mellomsertifikater er installert på webserveren din for å gi nettlesere en komplett sertifiseringsvei og unngå tillitsadvarsler og feil for sluttbrukere. CAen din vil kunne gi deg nødvendige mellomprodukter; SSL.coms kunder kan bruke våre Nedlasting av mellomliggende sertifikat side for å hente mellomliggende pakker for mange serverplattformer.
• Bruk gjeldende SSL /TLS Protokoller (TLS 1.2 eller 1.3): På slutten av 2018 kunngjorde alle større nettleser leverandører planer om å bli utskrevet TLS 1.0 og 1.1 innen første halvdel av 2020. Google foreldet TLS v1.0 og v1.1 i Chrome 72 (utgitt 30. januar 2919). Chrome-versjon 84 (utgitt 14. juli 2020) og nyere presenterer en interstitial advarsel for disse protokollene, og støtten var planlagt å være helt fjernet i mai 2021. Utbredt nettleserstøtte av tidligere SSL /TLS versjoner, for eksempel SSL v3, er borte. Samtidig som TLS 1.2 er for tiden den mest brukte versjonen av SSL /TLS protokollen, TLS 1.3 (den nyeste versjonen) er allerede støttet i de gjeldende versjonene av de fleste større nettlesere.
• Bruk en kort liste over Secure Cipher Suites: Velg bare chiffer-suiter som tilbyr minst 128-bits kryptering, eller sterkere når det er mulig. Nasjonalt institutt for standarder og teknologi (NIST) anbefaler også at alle TLS implementeringer beveger seg bort fra krypteringssuiter som inneholder DES-kryptering (eller dens varianter) til de som bruker AES. Til slutt, ved å bruke bare en liten delmengde av potensielt akseptable krypteringssuiter, minimeres angrepsoverflaten for uoppdagede sårbarheter. Vedlegget til SSL.com Veiledning til TLS Standards Compliance gir eksempelkonfigurasjoner for de mest populære webserverplattformene ved bruk av TLS 1.2.
  
  OBS: Hvis du bruker usikre, kan utdaterte sifre (for eksempel RC4) forårsake sikkerhetsfeil i nettleseren, som ERR_SSL_VERSION_OR_CIPHER_MISMATCH i Google Chrome.
• Bruk fremoverhemmelighet (FS): Også kjent som perfekt fremtidshemmelighet (PFS), FS forsikrer at en kompromittert privat nøkkel ikke også vil kompromittere tidligere sesjonsnøkler. Slik aktiverer FS:
  • Konfigurer TLS 1.2 for å bruke den Elliptic Curve Diffie-Hellman (EDCHE) nøkkelutvekslingsalgoritmen (med DHE som et tilbakeblikk), og unngå RSA nøkkelutveksling fullstendig hvis mulig.
  • Bruk TLS 1.3. TLS 1.3 gir taushetsplikt for alle TLS økter via the Ephemeral Diffie-Hellman (EDH eller DHE) nøkkelutvekslingsprotokoll.
• aktiver TLS Sesjons gjenopptak: På samme måte som å bruke keepalives for å opprettholde vedvarende TCP-tilkoblinger, TLS økt gjenopptakelse gjør at webserveren din kan holde oversikt over nylig forhandlet SSL /TLS økter og gjenoppta dem, ved å omgå den beregningsmessige kostnaden for forhandlinger om økten.
• Vurder OCSP stifting: OCSP-stifting tillater webservere å levere hurtigbufret tilbakekallingsinformasjon direkte til klienten, noe som betyr at en nettleser ikke trenger å kontakte en OCSP-server for å kontrollere om sertifikatet til et nettsted er tilbakekalt. Ved å eliminere denne forespørselen, tilbyr OCSP-stifting et reelt ytelsesløft. For mer informasjon, vennligst les vår artikkel, Optimalisering av sidebelastning: OCSP-stifting.

Bruk beste praksis for design av webapplikasjoner

Å designe webapplikasjonene dine med sikkerhet er like viktig som å konfigurere serveren riktig. Dette er de viktigste punktene for å sikre at brukerne ikke blir utsatt for Mannen i midten angrep, og at søknaden din får SEO-fordelene som følger med god sikkerhetspraksis:

• Fjern blandet innhold: JavaScript-filer, bilder og CSS-filer skal alle få tilgang til med SSL /TLS. Som beskrevet i SSL.coms artikkel, HTTPS Everywhere, servering blandet innhold er ikke lenger en akseptabel måte å øke nettstedets ytelse, og kan resultere i nettleserens advarsler og SEO-problemer.
• Bruk sikre informasjonskapsler: Innstilling av Secure flagg i informasjonskapsler vil håndheve overføring over sikre kanaler (f.eks. HTTPS). Du kan også forhindre JavaScript på klientsiden fra å få tilgang til informasjonskapsler via HttpOnly flagg, og begrense bruk av cookies på tvers av nettstedet med SameSite flagg.
• Evaluer tredjepartskode: Forsikre deg om at du forstår de potensielle risikoene ved bruk av tredjepartsbiblioteker på nettstedet ditt, for eksempel muligheten for utilsiktet å innføre sårbarheter eller ondsinnet kode. Alltid veterinær pålitelighet fra tredjepart etter beste evne og lenke til all tredjepartskode med HTTPS. Til slutt må du sørge for at fordelen din fra tredjepartselementer på nettstedet ditt er verdt risikoen.

Kontroller arbeidet ditt med diagnoseverktøy

Etter å ha satt opp SSL /TLS på serveren din og nettstedet ditt eller foretar konfigurasjonsendringer, er det viktig å sørge for at alt er riktig konfigurert og systemet ditt er sikkert. Mange diagnostiske verktøy er tilgjengelige for å sjekke nettstedets SSL /TLS. For eksempel SSL Shoppers SSL-kontroller vil fortelle deg om sertifikatet ditt er riktig installert, når det utløper, og viser sertifikatets kjede av tillit.

Andre online verktøy og applikasjoner er tilgjengelige som vil gjennomsøke nettstedet ditt for å se etter sikkerhetsproblemer som blandet innhold. Du kan også se etter blandet innhold med en nettleser ved å bruke det innebygde utviklerverktøyet:

Uansett verktøy du velger, er det også viktig å sette en tidsplan for å sjekke SSL /TLS installasjon og konfigurasjon. CA kan også være i stand til å hjelpe deg med dette; For eksempel, som en bekvemmelighet for våre kunder, gir SSL.com automatiske varsler om forestående sertifikatutløp.

Implementer HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security (HSTS) er en sikkerhetspolitisk mekanisme som bidrar til å beskytte nettsteder mot protokollnedgraderingsangrep og kapring av informasjonskapsler. Den lar webservere erklære at nettlesere (eller andre samsvarende brukeragenter) bare skal samhandle med den ved å bruke sikre HTTPS-tilkoblinger, og aldri via den usikre HTTP-protokollen. Denne policyen kommuniseres av serveren til brukeragenten via et HTTP-svarhodefelt kalt "Strict-Transport-Security".

Å implementere HTTP Strict Transport Security (HSTS), må du legge til en spesiell svaroverskrift i nettserverens konfigurasjon.

Her er en steg-for-steg guide:

1. Sørg for at nettstedet ditt støtter HTTPS: Før du aktiverer HSTS, må nettstedet ditt ha en gyldig SSL-sertifikat og kunne levere innhold over HTTPS. Hvis nettstedet ditt ennå ikke er konfigurert for HTTPS, må du det få et SSL-sertifikat og konfigurer serveren din til å bruke den.

Header sett alltid Strict-Transport-Security "max-age=31536000; includeSubDomains"

_{Denne linjen forteller nettleseren å alltid bruke HTTPS for nettstedet ditt det neste året (31,536,000 XNUMX XNUMX sekunder), inkludert alle underdomener.}

2. Test konfigurasjonen din: Etter å ha lagt til HSTS-overskriften, bør du teste nettstedet ditt for å sikre at det fungerer som det skal. Du kan gjøre dette ved å besøke nettstedet ditt og bruke nettleserens utviklerverktøy for å sjekke svarhodene. Du bør se overskriften Strict-Transport-Security med verdien du angir.
3. Vurder å legge til nettstedet ditt i HSTS forhåndsinnlastningslisten: HSTS forhåndsinnlastningslisten er en liste over nettsteder som er hardkodet inn i nettlesere som HSTS-aktiverte. Dette gir et ekstra beskyttelsesnivå, siden det sikrer at den første tilkoblingen til nettstedet ditt er sikker, selv før HSTS-headeren er mottatt. Du kan sende inn nettstedet ditt til HSTS forhåndsinnlastningslisten på hstspreload.org.

Bruk sak: Et nyhetsnettsted ønsker å sikre at brukerne alltid kobler til det på en sikker måte, selv om de ved et uhell skriver «http» i stedet for «https» i URL-en. Nettstedet bruker HSTS ved å legge til Strict-Transport-Security-overskriften til serverkonfigurasjonen, angi en lang maks-alder og inkludere alle underdomener. Dette forteller brukeragenter å alltid koble til den ved hjelp av HTTPS, og beskytte brukere mot angrep som prøver å nedgradere tilkoblingen til HTTP og stjele informasjonskapslene deres. Nettstedet sender seg også til HSTS forhåndslastliste for ekstra beskyttelse.

Implementer HTTP Public Key Pinning (HPKP)

HTTP Public Key Pinning (HPKP) var en sikkerhetsfunksjon som tillot en webserver å knytte en bestemt kryptografisk offentlig nøkkel til seg selv for å forhindre mann-i-midten-angrep (MITM) med forfalskede sertifikater.

Her er en kort oversikt over hvordan den ble brukt:

1. Generer pinningsinformasjon: Det første trinnet i implementeringen av HPKP var å generere pinningsinformasjonen. Dette innebar å lage en kryptografisk hash av den offentlige nøkkelen til sertifikatet eller den offentlige nøkkelen til mellom- eller rotsertifikatet.
2. Konfigurer webserveren: Neste trinn var å konfigurere webserveren til å inkludere Public-Key-Pins HTTP overskrift i svar. Denne overskriften inkluderte hashen til de offentlige nøklene ("pinnene"), en tid å leve (hvor lenge nettleseren skal huske informasjonen), og eventuelt en rapport-URI (hvor nettleseren ville sende rapporter om pin-valideringsfeil).
3. Håndter PIN-valideringsfeil: Hvis en nettleser som støttet HPKP mottok en sertifikatkjede som ikke inkluderte minst én av de festede offentlige nøklene, ville den anse tilkoblingen som uklarert. Hvis en rapport-URI ble spesifisert, vil nettleseren også sende en rapport om feilen til denne URI.

På grunn av risikoen for misbruk og muligheten for å forårsake tjenestenekt, har imidlertid HPKP blitt avviklet av de fleste nettlesere og er ikke lenger en anbefalt praksis. Feilkonfigurering av HPKP kan føre til en situasjon der et nettsted blir utilgjengelig.

Bruk sak: Tidligere brukte et teknologiselskap HPKP til å feste sine offentlige nøkler til serverne deres. Dette sikret at hvis en sertifiseringsinstans (CA) ble kompromittert og et sertifikat ved en feiltakelse ble utstedt for domenet deres, ville ikke nettlesere stole på det med mindre det også hadde en offentlig nøkkel som samsvarte med en av de festede nøklene. De måtte imidlertid være svært forsiktige for å unngå å miste tilgangen til de festede nøklene, noe som ville gjøre nettsiden deres utilgjengelig. De måtte også sørge for at de hadde en prosess på plass for å rotere pinnene før de utløp, for å unngå å gjøre nettstedet utilgjengelig for brukere med bufret pinningsinformasjon.

Bruk TLS Reserve-SCSV for å forhindre protokollnedgraderingsangrep

TLS Reserve SCSV (Signaling Cipher Suite-verdi) er en mekanisme som ble introdusert for å forhindre protokollnedgraderingsangrep. Disse angrepene skjer når en angriper forstyrrer tilkoblingsoppsettprosessen og lurer klienten og serveren til å bruke en mindre sikker versjon av protokollen enn de begge faktisk støtter.

Her er hvordan du kan implementere TLS Reserve SCSV:

1. Oppdater serverens SSL/TLS Bibliotek: Det første trinnet er å sikre at serverens SSL/TLS bibliotek støtter TLS Reserve SCSV. Denne funksjonen ble introdusert i OpenSSL 1.0.1j, 1.0.0o og 0.9.8zc. Hvis du bruker en annen SSL/TLS biblioteket, sjekk dokumentasjonen eller kontakt utviklerne.
2. Konfigurer serveren din: Når serverens SSL/TLS bibliotek støtter TLS Reserve SCSV, du må kanskje konfigurere serveren din for å bruke den. De nøyaktige trinnene vil avhenge av serverprogramvaren din. For eksempel, i Apache, må du kanskje legge til eller endre en linje i konfigurasjonsfilen din slik:

SSLProtocol All -SSLv2 -SSLv3

Denne linjen forteller serveren å bruke alle protokollversjoner unntatt SSLv2 og SSLv3. Hvis klienten og serveren begge støtter TLS 1.2, men klienten forsøker å bruke TLS 1.1 (kanskje på grunn av en angripers interferens), vil serveren gjenkjenne dette som et reserveforsøk og avvise tilkoblingen.

3. Test serveren din: Etter å ha konfigurert serveren din, bør du teste den for å sikre at den implementeres riktig TLS Reserve SCSV. Det finnes ulike nettbaserte verktøy som kan hjelpe deg med dette, for eksempel SSL Labs Server Test.

Bruk sak: Et globalt selskap bruker TLS Reserve SCSV for å beskytte intern kommunikasjon. Dette sikrer at hvis en angriper prøver å tvinge en protokollnedgradering, vil serveren gjenkjenne dette og avvise tilkoblingen, og beskytte selskapets sensitive data. Selskapets IT-team oppdaterer regelmessig servernes SSL/TLS biblioteker og konfigurasjoner for å sikre at de bruker de nyeste sikkerhetsfunksjonene, og de bruker nettbaserte verktøy for å teste serverne sine og bekrefte at de implementerer riktig TLS Reserve SCSV.

Unngå problemer med blandet innhold

Blandet innhold er en sikkerhetsrisiko som oppstår når en nettside lastet over en sikker HTTPS-tilkobling inkluderer ressurser, for eksempel bilder, videoer, stilark eller skript, som lastes over en usikker HTTP-tilkobling. Nettlesere kan blokkere dette blandede innholdet eller vise en advarsel til brukeren, noe som kan skade brukerens oppfatning av nettstedets sikkerhet.

Slik kan du unngå problemer med blandet innhold:

1. Bruk HTTPS for alle ressurser: Den enkleste måten å unngå blandet innhold på er å sikre at alle ressurser på nettstedet ditt lastes over HTTPS. Dette inkluderer bilder, skript, stilark, iframes, AJAX-forespørsler og andre ressurser som nettstedet ditt bruker.
2. Oppdater nettstedets kode: Hvis nettstedets kode inkluderer hardkodede HTTP-URL-er for ressurser, må du oppdatere disse for å bruke HTTPS i stedet. Hvis ressursen ligger på en server som ikke støtter HTTPS, må du kanskje være vert for ressursen på din egen server eller finne en alternativ ressurs som kan lastes over HTTPS.
3. Konfigurer serveren din til å sende en innhold-sikkerhetspolicy-overskrift: Content-Security-Policy (CSP) HTTP-header lar deg kontrollere hvilke ressurser nettstedet ditt har lov til å laste. Ved å angi en CSP-overskrift som bare tillater HTTPS-ressurser, kan du sikre at nettstedet ditt ikke ved et uhell inkluderer blandet innhold.

Bruk sak: Et nettmagasin sørger for at alt innhold, inkludert bilder og skript, lastes over HTTPS. Dette forhindrer angripere i å tukle med disse ressursene og potensielt injisere skadelig innhold. Magasinets nettutviklere gjennomgår regelmessig nettstedets kode for å sikre at alle ressurser lastes over HTTPS, og de konfigurerer serveren sin til å sende en streng Content-Security-Policy-header. De bruker også nettbaserte verktøy for å skanne nettstedet for problemer med blandet innhold og fikse alt de finner.

Bruk servernavnindikasjon (SNI) for å være vert for flere nettsteder

Servernavnindikasjon (SNI) er en utvidelse av TLS protokoll som lar en server presentere flere sertifikater på samme IP-adresse og portnummer. Dette er spesielt nyttig for webhotellleverandører som trenger å være vert for flere sikre nettsteder, hver med sitt eget SSL-sertifikat, på samme server.

Slik kan du bruke SNI:

1. Sørg for at serverprogramvaren din støtter SNI: Det første trinnet er å sikre at serverprogramvaren din støtter SNI. De fleste moderne webservere, inkludert Apache, Nginx og IIS, støtter SNI.
2. Konfigurer serveren din: Neste trinn er å konfigurere serveren din til å bruke SNI. Dette innebærer vanligvis å legge til en separat konfigurasjonsblokk for hvert nettsted du vil være vert for på serveren, og spesifisere SSL-sertifikat å bruke for hvert nettsted. De nøyaktige trinnene vil avhenge av serverprogramvaren din.
3. Test konfigurasjonen din: Etter å ha konfigurert serveren din, bør du teste den for å sikre at den bruker SNI riktig. Du kan gjøre dette ved å besøke hvert nettsted du er vert for på serveren og sjekke at riktig SSL-sertifikat brukes.

Bruk sak: En vertsleverandør bruker SNI til å betjene flere nettsteder fra samme IP-adresse. Dette lar dem effektivt bruke IP-adresseområdet og forenkle nettverkskonfigurasjonen. De konfigurerer serveren til å bruke et annet SSL-sertifikat for hvert nettsted, og de tester regelmessig konfigurasjonen for å sikre at det riktige sertifikatet brukes for hvert nettsted. Dette sikrer at hvert nettsted har en sikker, pålitelig tilkobling, selv om de alle blir servert fra samme IP-adresse.

Optimaliser ytelsen med gjenopptakelse av økter

Gjenopptakelse av økten er et trekk ved TLS protokoll som lar en klient og server bruke de samme krypteringsnøklene over flere økter, noe som reduserer kostnadene ved å etablere en ny sikker tilkobling hver gang. Dette kan forbedre ytelsen betydelig, spesielt for applikasjoner der klienten ofte kobler fra og kobler til på nytt.

 Slik kan du bruke gjenopptagelse av økter:

1. Sørg for at serverprogramvaren din støtter gjenopptakelse av økter: Det første trinnet er å sikre at serverprogramvaren din støtter gjenopptakelse av økter. De fleste moderne webservere, inkludert Apache, Nginx og IIS, støtter denne funksjonen.
2. Konfigurer serveren din: Det neste trinnet er å konfigurere serveren din til å bruke gjenopptakelse av økten. Dette innebærer vanligvis å aktivere øktbufferen og angi en tidsavbruddsverdi for hurtigbufferen. De nøyaktige trinnene vil avhenge av serverprogramvaren din.
3. Test konfigurasjonen din: Etter å ha konfigurert serveren din, bør du teste den for å sikre at den bruker gjenopptagelse av økten riktig. Du kan gjøre dette ved å etablere en TLS koble til serveren din, koble fra og deretter koble til igjen. Hvis gjenopptakelse av økten fungerer som den skal, bør den andre tilkoblingen være raskere å opprette enn den første.

Bruk sak: En mobilapp bruker gjenopptakelse av økter for å opprettholde raske og sikre tilkoblinger. Dette er spesielt nyttig når appen brukes i områder med ujevn nettverksdekning, da den lar appen raskt gjenopprette en sikker forbindelse etter et frafall. Appens utviklere konfigurerer serveren sin til å bruke gjenopptakelse av økter, og de tester funksjonen regelmessig for å sikre at den fungerer som den skal. Dette sikrer at appen kan gi en rask, sømløs opplevelse for brukere, selv under utfordrende nettverksforhold.

Sørg for at sertifikatet er gyldig med OCSP-stifting

Online Certificate Status Protocol (OCSP) stifting er en metode for å forbedre ytelsen til SSL/TLS samtidig som sikkerheten til forbindelsen opprettholdes. Den lar serveren hente gjeldende status for sine egne sertifikater fra Certificate Authority (CA) og deretter levere den statusen til klienter i løpet av TLS håndtrykk.

Slik kan du implementere OCSP-stifting:

1. Sørg for at serverprogramvaren din støtter OCSP-stifting: Det første trinnet er å sikre at serverprogramvaren støtter OCSP-stifting. De fleste moderne webservere, inkludert Apache, Nginx og IIS, støtter denne funksjonen.
2. Konfigurer serveren din: Neste trinn er å konfigurere serveren til å bruke OCSP-stifting. Dette innebærer vanligvis å aktivere funksjonen i serverens SSL/TLS konfigurere og spesifisere en plassering for serveren for å lagre OCSP-svarene. De nøyaktige trinnene vil avhenge av serverprogramvaren din.
3. Test konfigurasjonen din: Etter å ha konfigurert serveren, bør du teste den for å sikre at den bruker OCSP-stifting på riktig måte. Du kan gjøre dette ved å etablere en TLS tilkobling til serveren din og sjekke at serveren inkluderer et OCSP-svar i TLS håndtrykk.

Bruk sak: En nettforhandler bruker OCSP-stifting for raskt å bekrefte statusen til SSL-sertifikatet. Dette sikrer at kundene alltid har en sikker tilkobling og kan stole på at dataene deres er trygge. Forhandlerens IT-team konfigurerer serveren sin til å bruke OCSP-stifting, og de tester regelmessig funksjonen for å sikre at den fungerer som den skal. Dette bidrar til å opprettholde tilliten til kundene deres og beskytte deres sensitive data.

Deaktiver TLS Komprimering for å redusere CRIME Attack

TLS komprimering er en funksjon som kan forbedre ytelsen til SSL/TLS ved å redusere mengden data som må sendes over nettverket. Det kan imidlertid også gjøre forbindelsen sårbar for CRIME-angrepet (Compression Ratio Info-leak Made Easy), som kan tillate en angriper å utlede innholdet i kryptert trafikk.

Slik kan du deaktivere TLS komprimering: 

1. Sørg for at serverprogramvaren din støtter deaktivering TLS Komprimering: Det første trinnet er å sikre at serverprogramvaren din støtter deaktivering TLS kompresjon. De fleste moderne webservere, inkludert Apache, Nginx og IIS, støtter denne funksjonen.
2. Konfigurer serveren din: Neste trinn er å konfigurere serveren til å deaktivere TLS kompresjon. De nøyaktige trinnene vil avhenge av serverprogramvaren din. For eksempel, i Apache, kan du legge til en linje som denne i konfigurasjonsfilen din:

SSLCompression av

Denne linjen forteller serveren om ikke å bruke komprimering for SSL/TLS tilkoblinger.

3. Test konfigurasjonen din: Etter å ha konfigurert serveren din, bør du teste den for å sikre at den deaktiveres på riktig måte TLS kompresjon. Du kan gjøre dette ved å etablere en TLS tilkobling til serveren din og sjekke at tilkoblingen ikke bruker komprimering.

Bruk sak: En finansinstitusjon deaktiverer TLS komprimering på sine servere for å beskytte mot CRIME-angrepet. Dette bidrar til å sikre konfidensialiteten til sensitive økonomiske data, som kontonumre og transaksjonsdetaljer. Institusjonens IT-team konfigurerer sine servere til å deaktivere TLS komprimering, og de tester regelmessig serverne for å sikre at de implementerer dette sikkerhetstiltaket på riktig måte. Dette er med på å beskytte institusjonens kunder og opprettholde deres tillit.

Implementere TLS Øktbilletter riktig

TLS øktbilletter er en funksjon i TLS protokoll som kan forbedre ytelsen ved å la en klient og server gjenoppta en tidligere økt uten å måtte utføre et fullstendig håndtrykk. Imidlertid må de implementeres riktig for å unngå potensielle sikkerhetsproblemer.

Her er hvordan du kan implementere riktig TLS øktbilletter:

1. Sørg for at serverprogramvaren din støtter TLS Øktbilletter: Det første trinnet er å sikre at serverprogramvaren din støtter TLS øktbilletter. De fleste moderne webservere, inkludert Apache, Nginx og IIS, støtter denne funksjonen.
2. Konfigurer serveren din: Neste trinn er å konfigurere serveren til bruk TLS øktbilletter. Dette innebærer vanligvis å aktivere funksjonen i serverens SSL/TLS konfigurasjon. De nøyaktige trinnene vil avhenge av serverprogramvaren din.
3. Bruk unike sesjonsbillettnøkler: For å forhindre potensielle sikkerhetsproblemer, bør hver server bruke en unik sesjonsbillettnøkkel. Hvis du bruker en belastningsbalanser, bør du konfigurere den til å distribuere klienter basert på øktbilletten deres, i stedet for å la klienter bruke en øktbillett utstedt av én server for å etablere en økt med en annen server.
4. Roter øktbillettnøkler regelmessig: For å øke sikkerheten ytterligere, bør du regelmessig rotere øktbillettnøklene. Dette kan ofte automatiseres ved hjelp av serverprogramvaren eller et separat nøkkelstyringssystem.

Bruk sak: Et stort teknologiselskap med flere servere sikrer at hver server bruker en unik sesjonsbillettnøkkel. Dette forhindrer en angriper fra å kunne bruke en sesjonsbillett fra én server til å etterligne en bruker på en annen server. Selskapets IT-team konfigurerer serverne de skal bruke TLS øktbilletter, og de satte opp et system for regelmessig å rotere sesjonsbillettnøklene. De konfigurerer også lastbalanseren til å distribuere klienter basert på øktbilletten deres, noe som ytterligere forbedrer sikkerheten til systemet deres.

Aktiver sikker reforhandling

Sikker reforhandling er en funksjon i SSL/TLS protokoller som lar klienten eller serveren be om en ny TLS håndtrykk midt i en økt. Dette kan være nyttig av en rekke årsaker, for eksempel å oppdatere krypteringsnøkler eller endre krypteringsnivået. Men hvis den ikke håndteres sikkert, kan den utnyttes av en angriper til å injisere klartekst i den krypterte kommunikasjonen.

Slik kan du aktivere sikker reforhandling:

2. Sørg for at serverprogramvaren din støtter sikker reforhandling: Det første trinnet er å sikre at serverprogramvaren din støtter sikker reforhandling. De fleste moderne webservere, inkludert Apache, Nginx og IIS, støtter denne funksjonen.
3. Konfigurer serveren din: Neste trinn er å konfigurere serveren din til å bruke sikker reforhandling. Dette innebærer vanligvis å aktivere funksjonen i serverens SSL/TLS konfigurasjon. De nøyaktige trinnene vil avhenge av serverprogramvaren din.
4. Test konfigurasjonen din: Etter å ha konfigurert serveren din, bør du teste den for å sikre at den bruker sikker reforhandling på riktig måte. Du kan gjøre dette ved å etablere en TLS tilkobling til serveren din og deretter forsøke å reforhandle tilkoblingen.

Bruk sak: En sosial medieplattform muliggjør sikker reforhandling for å beskytte brukerdata. Dette hindrer en angriper fra å kunne injisere skadelig innhold i den krypterte kommunikasjonen mellom brukeren og serveren. Plattformens IT-team konfigurerer serverne sine til å bruke sikker reforhandling, og de tester serverne regelmessig for å sikre at de implementerer dette sikkerhetstiltaket riktig. Dette bidrar til å beskytte plattformens brukere og opprettholde deres tillit.

Deaktiver klientinitiert reforhandling for å forhindre DoS-angrep

Klientinitiert reforhandling er en funksjon i SSL/TLS protokoller som lar klienten be om en ny TLS håndtrykk midt i en økt. Men hvis en angriper kan tvinge en server til kontinuerlig å reforhandle økter, kan den forbruke for store ressurser og potensielt føre til et tjenestenektangrep (DoS).

Slik kan du deaktivere klientinitiert reforhandling:

1. Sørg for at serverprogramvaren din støtter deaktivering av klientinitiert reforhandling: Det første trinnet er å sikre at serverprogramvaren din støtter deaktivering av klientinitiert reforhandling. De fleste moderne webservere, inkludert Apache, Nginx og IIS, støtter denne funksjonen.
2. Konfigurer serveren din: Det neste trinnet er å konfigurere serveren til å deaktivere klientinitiert reforhandling. Dette innebærer vanligvis å legge til et direktiv til serverens SSL/TLS konfigurasjon. De nøyaktige trinnene vil avhenge av serverprogramvaren din.
3. Test konfigurasjonen din: Etter å ha konfigurert serveren din, bør du teste den for å sikre at den deaktiverer klientinitiert reforhandling på riktig måte. Du kan gjøre dette ved å etablere en TLS tilkobling til serveren din og deretter forsøke å reforhandle tilkoblingen. Hvis serveren avslår reforhandlingsforespørselen på riktig måte, er den riktig konfigurert.

Bruk sak: En online spillplattform deaktiverer klientinitiert reforhandling for å beskytte mot potensielle DoS-angrep. Dette bidrar til å sikre at plattformen forblir tilgjengelig for brukere, selv i møte med potensielle angrep. Plattformens IT-team konfigurerer serverne sine for å deaktivere klientinitiert reforhandling, og de tester serverne regelmessig for å sikre at de implementerer dette sikkerhetstiltaket på riktig måte. Dette bidrar til å beskytte plattformens brukere og opprettholde deres tillit.

Hold varsel om nye sårbarheter

Nettsikkerhet er et mål som stadig beveger seg, og du bør alltid være på utkikk etter neste angrep og raskt bruke sikkerhetsoppdateringer på serveren din. Dette betyr å lese og holde kontakten med det som er i horisonten når det gjelder informasjonssikkerhet, samt holde oversikt over programvareoppdateringer - spesielt de kritiske. SSL.coms nettsted (der du leser dette akkurat nå) er en flott kilde for å holde deg oppdatert på SSL /TLS og informasjonssikkerhet.

Men hva med…?

Hvis du vil vite mer om noen av emnene som dekkes i denne veiledningen og lære om nye problemer og teknologier når de oppstår, kan du starte med å bla gjennom og søke i SSL.com Kunnskapsbase, som vi holder oss oppdatert hver uke med ny utvikling innen SSL /TLS og PKI. Du kan også gjerne kontakte vår supportpersonell når som helst via e-post på Support@SSL.com, på telefonen kl 1-877-SSL-Secure, eller ved å klikke chat-lenken nederst til høyre på denne siden.

Få ekspertråd om SSL-sertifikater.
Fyll ut skjemaet for en konsultasjon.