SSL /TLS Bästa metoder för 2023

2023, säkra din webbplats med en SSL /TLS certifikatet är inte längre valfritt, även för företag som inte hanterar känslig kundinformation direkt på webben. Sökmotorer som Google använder webbplatsens säkerhet som en SEO-rankningssignal och populära webbläsare som Chrome varnar användare för webbplatser som inte använder HTTPS:

Möjligheten att ställa in dina webbservrar och applikationer för att använda SSL /TLS protokollet korrekt kan kännas skrämmande, eftersom det finns många arkana konfiguration och designval att göra. Den här guiden ger en snabb översikt över de viktigaste punkterna att tänka på när du ställer in SSL /TLS för din webbplats, medan du fokuserar på både säkerhet och prestanda. Det finns fortfarande mycket att täcka med bara grunderna, så vi har delat upp det i en serie steg.

Välj en tillförlitlig certifikatutfärdare (CA)

Dina certifikat är bara lika pålitliga som CA som utfärdar dem. Alla offentligt betrodda certifikatutfärdare är föremål för rigorösa tredjepartsgranskningar för att behålla sin position i större operativsystem och webbläsares rotcertifikatprogram, men vissa är bättre på att behålla den statusen än andra. Leta efter en CA som (som SSL.com):

• Gör det mesta av sin verksamhet inom allmänhetens förtroende PKI. Dessa företag har mest att förlora om dålig säkerhetspraxis kommer fram och allt att vinna genom att följa utvecklade industristandarder.
• Svarar effektivt och effektivt på sårbarhetsupptäckter som påverkar användarsäkerhet och integritet, som branschomfattande serienummer entropi nummer av början av 2019. Sök i branschforum som mozilla.dev.säkerhet.policy kan ge dig en god uppfattning om hur en viss CA reagerar på motgångar.
• Erbjuder användbara produkter och tjänster, som EV-certifikat (Extended Validation), bulk / automatiskt certifikatutfärdande via ett intuitivt API eller ACME-protokoll, enkla certifikat livscykelhantering och övervakningstjänster, och stödja för integration med en omfattande lista över tredjepartslösningar.
• Har ett rykte för bra kundservice och teknisk support. Att skydda ditt företags webbplats 100% av tiden är viktigt, och du måste kunna få en riktig expert i telefon när saker går fel.

Certifikatutfärdstillstånd (CAA)

Certifikatutfärdstillstånd (CAA) är en standard för att skydda webbplatser genom att utse specifika certifikatutfärdare som får utfärda certifikat för ett domännamn. När du har valt en CA, bör du överväga konfigurera CAA-poster att auktorisera det.

Generera och säkra dina privata nycklar

Smakämnen SSL /TLS protokoll använder a par nycklar för att verifiera identiteter och kryptera information som skickas via Internet. En av dessa (den offentlig nyckel) är avsedd för bred distribution och den andra (den privat nyckel) ska hållas så säkert som möjligt. Dessa nycklar skapas tillsammans när du genererar en certifikatsigneringsbegäran (CSR). Här är några tips att tänka på när det gäller dina privata nycklar:

• Använd starka privata nycklar: Större tangenter är svårare att knäcka, men kräver mer datoromkostnader. För närvarande rekommenderas minst en 2048-bitars RSA-nyckel eller 256-bitars ECDSA-nyckel, och de flesta webbplatser kan uppnå god säkerhet medan de optimerar prestanda och användarupplevelse med dessa värden.
  
  Notera: för en översikt av dessa två algoritmer, se SSL.coms artikel, Jämför ECDSA vs RSA.
• Skydda dina privata nycklar:
  • Skapa dina egna privata nycklar i en säker och pålitlig miljö (helst på servern där de kommer att distribueras eller en FIPS eller Common Criteria-kompatibel enhet). Aldrig tillåt en CA (eller någon annan) att skapa privata nycklar för dina räkning. En ansedd offentlig CA, som SSL.com, kommer aldrig att erbjuda att generera eller hantera dina privata nycklar om de inte genereras i en säker hårdvarutoken eller HSM och inte kan exporteras.
  • Ge bara tillgång till privata nycklar efter behov. Skapa nya nycklar och återkalla alla certifikat för de gamla nycklarna när anställda med privat nyckelåtkomst lämnar företaget.
  • Förnya certifikat så ofta som praktiskt möjligt (åtminstone årligen skulle vara bra), helst med en nygenererad privat nyckel varje gång. Automationsverktyg som ACME-protokoll är till hjälp för att schemalägga frekventa certifikatförnyelser
  • Om en privat nyckel har äventyrats, eller kan ha äventyrats, återkalla alla certifikat för den här nyckeln, generera ett nytt nyckelpar och utfärda ett nytt certifikat för det nya nyckelparet.

Konfigurera din server

På ytan, installera en SSL /TLS certifikat kan verka som en enkel operation; Det finns dock fortfarande många många konfigurationsbeslut som måste fattas för att säkerställa att din webbserver är snabb och säker och att slutanvändarna har en smidig upplevelse som är fri från webbläsarfel och varningar. Här är några konfigurationspekare som hjälper dig att komma igång när du konfigurerar SSL /TLS på dina servrar:

• Se till att alla värdnamn är täckta: Täcker ditt certifikat din webbplats domännamn både med och utan www prefix? Finns det en Ämnesalternativ (SAN) för varje domännamn certifikatet är avsett att skydda?
• Installera kompletta certifikatkedjor: SSL / slutenhet /TLS certifikat undertecknas vanligtvis av mellanliggande certifikat snarare än en CA: s rotnyckel. Se till att mellanliggande certifikat är installerade på din webbserver för att ge webbläsare en komplett certifieringsväg och undvik förtroendevarningar och fel för slutanvändare. Din CA kommer att kunna förse dig med alla nödvändiga mellanprodukter; SSL.coms kunder kan använda våra Mellanliggande certifikatnedladdning sida för att hämta mellanliggande paket för många serverplattformar.
• Använd aktuell SSL /TLS Protokoll (TLS 1.2 eller 1.3): I slutet av 2018 tillkännagav alla större webbläsarleverantörer planer på att avskrivas TLS 1.0 och 1.1 under första halvåret 2020. Google fasats TLS v1.0 och v1.1 i Chrome 72 (släpptes 30 januari 2919). Chrome-versioner 84 (släpptes 14 juli 2020) och senare presenterar en mellansidesvarning för dessa protokoll, och support var planerad att vara helt borttagen i maj 2021. Utbrett webbläsarsupport av tidigare SSL /TLS versioner, som SSL v3, är för länge borta. Medan TLS 1.2 är för närvarande den mest använda versionen av SSL /TLS protokoll, TLS 1.3 (den senaste versionen) är stöds redan i de aktuella versionerna av de flesta stora webbläsare.
• Använd en kort lista över Secure Cipher Suites: Välj bara chiffersviter som erbjuder minst 128-bitars kryptering eller starkare när det är möjligt. National Institute of Standards and Technology (NIST) rekommenderar också att allt TLS implementeringar flyttar sig bort från chiffersviter som innehåller DES-chiffer (eller dess varianter) till sådana som använder AES. Slutligen minimerar användningen av endast en liten delmängd av potentiellt acceptabla chiffersviter attackytan för ännu oupptäckta sårbarheter. Bilagan till SSL.com Guide till TLS Standards Compliance ger exempelkonfigurationer för de mest populära webbserverplattformarna med TLS 1.2.
  
  Notera: Om du använder osäkra kan utskrivna chiffer (t.ex. RC4) orsaka webbläsarsäkerhetsfel, t.ex. ERR_SSL_VERSION_OR_CIPHER_MISMATCH i Google Chrome.
• Använd Forward Secrecy (FS): Också känd som perfekt framåtriktad sekretess (PFS), FS försäkrar att en kompromissad privat nyckel inte också kommer att äventyra tidigare sessioner. För att aktivera FS:
  • Inställd TLS 1.2 för att använda den Elliptic Curve Diffie-Hellman (EDCHE) nyckelutbytesalgoritm (med DHE som fallback) och undvik RSA-nyckelutbyte helt om möjligt.
  • Använda TLS 1.3. TLS 1.3 ger framåtriktat hemlighet för alla TLS sessioner via the Ephemeral Diffie-Hellman (EDH eller DHE) nyckelutbytesprotokoll.
• aktivera TLS Återupptagande av sessionen: På samma sätt som att använda keepalives för att upprätthålla ihållande TCP-anslutningar, TLS sessionsåterupptagning gör att din webbserver kan hålla koll på nyligen förhandlat SSL /TLS sessioner och återuppta dem genom att kringgå den beräkningsmässiga omkostnaden för förhandlingen om sessionens nyckel.
• Överväg OCSP häftning: OCSP-häftning tillåter webbservrar att leverera cachad återkallningsinformation direkt till klienten, vilket innebär att en webbläsare inte behöver kontakta en OCSP-server för att kontrollera om webbplatsens certifikat har återkallats. Genom att eliminera denna begäran erbjuder OCSP-häftning en verklig prestandaförbättring. För mer information, läs vår artikel, Optimering av sidbelastning: OCSP-häftning.

Använd bästa metoder för webbapplikationsdesign

Att utforma dina webbapplikationer med säkerhet i åtanke är lika viktigt som att konfigurera din server korrekt. Det här är de viktigaste punkterna för att se till att dina användare inte utsätts för Mannen i mitten attacker, och att din ansökan får SEO-fördelarna med god säkerhetspraxis:

• Eliminera blandat innehåll: JavaScript-filer, bilder och CSS-filer bör alla nås med SSL /TLS. Som beskrivs i SSL.coms artikel, HTTPS Allt, servering blandat innehåll är inte längre ett acceptabelt sätt att öka webbplatsens prestanda och kan resultera i webbläsarsäkerhetsvarningar och SEO-problem.
• Använd säkra kakor: Ställa in Secure flagga i kakor kommer att tvinga överföring via säkra kanaler (t.ex. HTTPS). Du kan också hålla JavaScript från klientsidan från att komma åt cookies via HttpOnly flagga och begränsa användning av kakor på flera platser med SameSite flagga.
• Utvärdera tredje parts kod: Se till att du förstår de potentiella riskerna med att använda tredjepartsbibliotek på din webbplats, till exempel möjligheten att oavsiktligt införa sårbarheter eller skadlig kod. Vet alltid tredjeparts tillförlitlighet efter bästa förmåga och länk till all tredjepartskod med HTTPS. Slutligen, se till att din fördel från tredjepartselement på din webbplats är värt risken.

Kontrollera ditt arbete med diagnosverktyg

Efter att ha konfigurerat SSL /TLS på din server och webbplats eller gör några konfigurationsändringar är det viktigt att se till att allt är korrekt inställt och att ditt system är säkert. Många diagnostiska verktyg finns tillgängliga för att kontrollera din webbplats SSL /TLS. Till exempel SSL Shoppers SSL-kontroll kommer att meddela dig om ditt certifikat är korrekt installerat, när det löper ut och visar certifikatets förtroendekedja.

Andra onlineverktyg och applikationer finns tillgängliga som kommer att genomsöka din webbplats och kontrollera om det finns säkerhetsproblem som blandat innehåll. Du kan också leta efter blandat innehåll med en webbläsare med hjälp av dess inbyggda utvecklarverktyg:

Oavsett vilka verktyg du väljer är det också viktigt att ställa in ett schema för att kontrollera din SSL /TLS installation och konfiguration. Din CA kan också hjälpa dig med detta. Till exempel, som en bekvämlighet för våra kunder, tillhandahåller SSL.com automatiserade meddelanden om överhängande certifikats utgång.

Implementera HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security (HSTS) är en säkerhetspolicymekanism som hjälper till att skydda webbplatser mot protokollnedgraderingsattacker och cookie-kapning. Det tillåter webbservrar att deklarera att webbläsare (eller andra överensstämmande användaragenter) endast ska interagera med den med hjälp av säkra HTTPS-anslutningar, och aldrig via det osäkra HTTP-protokollet. Denna policy kommuniceras av servern till användaragenten via ett HTTP-svarshuvudfält med namnet "Strict-Transport-Security".

Att genomföra HTTP strikt transportsäkerhet (HSTS)måste du lägga till en speciell svarshuvud i din webbservers konfiguration.

Här är en steg-för-steg-guide:

1. Se till att din webbplats stöder HTTPS: Innan du aktiverar HSTS måste din webbplats ha en giltig SSL-certifikat och kunna leverera innehåll över HTTPS. Om din webbplats ännu inte är konfigurerad för HTTPS måste du göra det skaffa ett SSL-certifikat och konfigurera din server att använda den.

Header alltid inställd Strict-Transport-Security "max-age=31536000; includeSubDomains"

_{Den här raden talar om för webbläsaren att alltid använda HTTPS för din webbplats under nästa år (31,536,000 XNUMX XNUMX sekunder), inklusive alla underdomäner.}

2. Testa din konfiguration: När du har lagt till HSTS-huvudet bör du testa din webbplats för att säkerställa att den fungerar korrekt. Du kan göra detta genom att besöka din webbplats och använda webbläsarens utvecklarverktyg för att kontrollera svarsrubriker. Du bör se rubriken Strict-Transport-Security med det värde du ställt in.
3. Överväg att lägga till din webbplats i HSTS-förladdningslistan: HSTS-förladdningslistan är en lista över webbplatser som är hårdkodade i webbläsare som HSTS-aktiverade. Detta ger en extra skyddsnivå, eftersom det säkerställer att den första anslutningen till din webbplats är säker, även innan HSTS-huvudet tas emot. Du kan skicka in din webbplats till HSTS preload list på hstspreload.org.

Användningsfall: En nyhetswebbplats vill säkerställa att dess användare alltid ansluter till den på ett säkert sätt, även om de av misstag skriver "http" istället för "https" i webbadressen. Webbplatsen använder HSTS genom att lägga till Strict-Transport-Security-huvudet till sin serverkonfiguration, ställa in en lång maxålder och inkludera alla underdomäner. Detta säger åt användaragenter att alltid ansluta till den med HTTPS, vilket skyddar användare från attacker som försöker nedgradera anslutningen till HTTP och stjäla deras cookies. Webbplatsen skickar sig också till HSTS-förladdningslistan för extra skydd.

Implementera HTTP Public Key Pinning (HPKP)

HTTP Public Key Pinning (HPKP) var en säkerhetsfunktion som gjorde det möjligt för en webbserver att associera en specifik kryptografisk offentlig nyckel med sig själv för att förhindra man-i-mitt-attacker (MITM) med förfalskade certifikat.

Här är en kort översikt över hur den användes:

1. Generera fästinformation: Det första steget i implementeringen av HPKP var att generera pinningsinformationen. Detta innebar att skapa en kryptografisk hash för certifikatets publika nyckel eller den offentliga nyckeln för mellan- eller rotcertifikatet.
2. Konfigurera webbservern: Nästa steg var att konfigurera webbservern att inkludera Public-Key-Pins HTTP rubrik i svaren. Den här rubriken inkluderade hasharna för de publika nycklarna ("nålarna"), en tid att leva (hur länge webbläsaren ska komma ihåg informationen) och eventuellt en rapport-URI (där webbläsaren skulle skicka rapporter om pin-valideringsfel).
3. Hantera pinvalideringsfel: Om en webbläsare som stödde HPKP fick en certifikatkedja som inte innehöll minst en av de fästa offentliga nycklarna, skulle den betrakta anslutningen som otillförlitlig. Om en rapport-URI angavs skulle webbläsaren också skicka en rapport om felet till den URI:n.

Men på grund av risken för missbruk och risken för att orsaka överbelastning av tjänster har HPKP fasat ut av de flesta webbläsare och är inte längre en rekommenderad praxis. Felkonfiguration av HPKP kan leda till en situation där en webbplats blir otillgänglig.

Användningsfall: Tidigare använde ett teknikföretag HPKP för att fästa sina publika nycklar till sina servrar. Detta säkerställde att om en certifikatutfärdare (CA) kompromettades och ett certifikat av misstag utfärdades för deras domän, skulle webbläsare inte lita på den om den inte också hade en offentlig nyckel som matchade en av de fästa nycklarna. De var dock tvungna att vara mycket försiktiga för att undvika att tappa åtkomsten till de fästa nycklarna, vilket skulle göra deras hemsida otillgänglig. De var också tvungna att se till att de hade en process på plats för att rotera stiften innan de gick ut, för att undvika att göra deras webbplats otillgänglig för användare med cachad pinningsinformation.

Använda TLS Reserv SCSV för att förhindra attacker mot protokollnedgradering

TLS Reserv SCSV (Signalering av Cipher Suite-värde) är en mekanism som introducerades för att förhindra protokollnedgraderingsattacker. Dessa attacker inträffar när en angripare stör anslutningsprocessen och lurar klienten och servern att använda en mindre säker version av protokollet än vad de båda faktiskt stöder.

Så här kan du implementera TLS Reserv SCSV:

1. Uppdatera din servers SSL/TLS Bibliotek: Det första steget är att se till att din servers SSL/TLS biblioteket stöder TLS Reserv SCSV. Denna funktion introducerades i OpenSSL 1.0.1j, 1.0.0o och 0.9.8zc. Om du använder en annan SSL/TLS biblioteket, kontrollera dess dokumentation eller kontakta dess utvecklare.
2. Konfigurera din server: När din server har SSL/TLS biblioteket stöder TLS Reserv SCSV, du kan behöva konfigurera din server för att använda den. De exakta stegen beror på din serverprogramvara. Till exempel, i Apache kan du behöva lägga till eller ändra en rad i din konfigurationsfil så här:

SSLProtocol All -SSLv2 -SSLv3

Den här raden talar om för servern att använda alla protokollversioner utom SSLv2 och SSLv3. Om både klienten och servern stöder TLS 1.2, men klienten försöker använda TLS 1.1 (kanske på grund av en angripares störning), kommer servern att känna igen detta som ett reservförsök och avvisa anslutningen.

3. Testa din server: När du har konfigurerat din server bör du testa den för att säkerställa att den implementeras korrekt TLS Reserv SCSV. Det finns olika onlineverktyg som kan hjälpa dig med detta, till exempel SSL Labs Server Test.

Användningsfall: Ett globalt företag använder TLS Reserv SCSV för att skydda sin interna kommunikation. Detta säkerställer att om en angripare försöker tvinga fram en protokollnedgradering kommer servern att känna igen detta och avvisa anslutningen, vilket skyddar företagets känsliga data. Företagets IT-team uppdaterar regelbundet sina servrars SSL/TLS bibliotek och konfigurationer för att säkerställa att de använder de senaste säkerhetsfunktionerna, och de använder onlineverktyg för att testa sina servrar och bekräfta att de implementerar korrekt TLS Reserv SCSV.

Undvik problem med blandat innehåll

Blandat innehåll är en säkerhetsrisk som uppstår när en webbsida som laddas över en säker HTTPS-anslutning inkluderar resurser, såsom bilder, videor, stilmallar eller skript, som laddas över en osäker HTTP-anslutning. Webbläsare kan blockera detta blandade innehåll eller visa en varning till användaren, vilket kan skada användarens uppfattning om webbplatsens säkerhet.

Så här kan du undvika problem med blandat innehåll:

1. Använd HTTPS för alla resurser: Det enklaste sättet att undvika blandat innehåll är att se till att alla resurser på din webbplats laddas över HTTPS. Detta inkluderar bilder, skript, stilmallar, iframes, AJAX-förfrågningar och alla andra resurser som din webbplats använder.
2. Uppdatera din webbplats kod: Om din webbplats kod innehåller hårdkodade HTTP-URL:er för resurser måste du uppdatera dessa för att använda HTTPS istället. Om resursen finns på en server som inte stöder HTTPS kan du behöva vara värd för resursen på din egen server eller hitta en alternativ resurs som kan laddas över HTTPS.
3. Konfigurera din server för att skicka ett innehåll-säkerhets-policyhuvud: HTTP-huvudet Content-Security-Policy (CSP) låter dig styra vilka resurser som din webbplats får ladda. Genom att ställa in en CSP-rubrik som endast tillåter HTTPS-resurser kan du säkerställa att din webbplats inte av misstag inkluderar blandat innehåll.

Användningsfall: En onlinetidning säkerställer att allt innehåll, inklusive bilder och skript, laddas över HTTPS. Detta förhindrar angripare från att manipulera dessa resurser och potentiellt injicera skadligt innehåll. Tidningens webbutvecklare granskar regelbundet webbplatsens kod för att säkerställa att alla resurser laddas över HTTPS, och de konfigurerar sin server för att skicka en strikt Content-Security-Policy-header. De använder också onlineverktyg för att skanna sin webbplats efter problem med blandat innehåll och fixa allt de hittar.

Använd Server Name Indication (SNI) för att vara värd för flera webbplatser

Servernamnindikering (SNI) är en förlängning av TLS protokoll som tillåter en server att presentera flera certifikat på samma IP-adress och portnummer. Detta är särskilt användbart för webbhotellleverantörer som behöver vara värd för flera säkra webbplatser, var och en med sitt eget SSL-certifikat, på samma server.

Så här kan du använda SNI:

1. Se till att din serverprogramvara stöder SNI: Det första steget är att se till att din serverprogramvara stöder SNI. De flesta moderna webbservrar, inklusive Apache, Nginx och IIS, stöder SNI.
2. Konfigurera din server: Nästa steg är att konfigurera din server för att använda SNI. Detta innebär vanligtvis att man lägger till ett separat konfigurationsblock för varje plats som du vill vara värd för på servern och specificerar SSL-certifikat att använda för varje webbplats. De exakta stegen beror på din serverprogramvara.
3. Testa din konfiguration: När du har konfigurerat din server bör du testa den för att säkerställa att den använder SNI korrekt. Du kan göra detta genom att besöka varje webbplats som du är värd på servern och kontrollera att rätt SSL-certifikat används.

Användningsfall: En värdleverantör använder SNI för att betjäna flera webbplatser från samma IP-adress. Detta tillåter dem att effektivt använda sitt IP-adressutrymme och förenkla sin nätverkskonfiguration. De konfigurerar sin server att använda ett annat SSL-certifikat för varje webbplats, och de testar regelbundet sin konfiguration för att säkerställa att rätt certifikat används för varje webbplats. Detta säkerställer att varje webbplats har en säker, pålitlig anslutning, även om de alla betjänas från samma IP-adress.

Optimera prestanda med återupptagande av session

Att återuppta sessionen är en funktion av TLS protokoll som tillåter en klient och server att använda samma krypteringsnycklar över flera sessioner, vilket minskar kostnaden för att upprätta en ny säker anslutning varje gång. Detta kan förbättra prestandan avsevärt, särskilt för applikationer där klienten ofta kopplar från och återansluter.

 Så här kan du använda återupptagande av session:

1. Se till att din serverprogramvara stöder återupptagande av sessioner: Det första steget är att se till att din serverprogramvara stöder återupptagande av session. De flesta moderna webbservrar, inklusive Apache, Nginx och IIS, stöder den här funktionen.
2. Konfigurera din server: Nästa steg är att konfigurera din server för att använda sessionsåterupptagning. Detta innebär vanligtvis att man aktiverar sessionscachen och ställer in ett timeoutvärde för cachen. De exakta stegen beror på din serverprogramvara.
3. Testa din konfiguration: När du har konfigurerat din server bör du testa den för att säkerställa att den fungerar korrekt med hjälp av återupptagande av session. Du kan göra detta genom att upprätta en TLS ansluta till din server, koppla från och sedan återansluta. Om återupptagandet av sessionen fungerar korrekt bör den andra anslutningen vara snabbare att upprätta än den första.

Användningsfall: En mobilapp använder återupptagande av sessioner för att upprätthålla snabba och säkra anslutningar. Detta är särskilt användbart när appen används i områden med ojämn nätverkstäckning, eftersom det gör att appen snabbt kan återupprätta en säker anslutning efter ett avhopp. Appens utvecklare konfigurerar sin server för att använda sessionsåterupptagning och de testar regelbundet funktionen för att säkerställa att den fungerar korrekt. Detta säkerställer att appen kan ge en snabb, sömlös upplevelse för användare, även i utmanande nätverksförhållanden.

Säkerställ certifikatets giltighet med OCSP-häftning

Online Certificate Status Protocol (OCSP) häftning är en metod för att förbättra prestanda för SSL/TLS samtidigt som säkerheten för anslutningen bibehålls. Det tillåter servern att hämta den aktuella statusen för sina egna certifikat från certifikatutfärdaren (CA) och sedan leverera den statusen till klienter under TLS handslag.

Så här kan du implementera OCSP-häftning:

1. Se till att din serverprogramvara stöder OCSP-häftning: Det första steget är att se till att din serverprogramvara stöder OCSP-häftning. De flesta moderna webbservrar, inklusive Apache, Nginx och IIS, stöder den här funktionen.
2. Konfigurera din server: Nästa steg är att konfigurera din server att använda OCSP-häftning. Detta innebär vanligtvis att du aktiverar funktionen i din servers SSL/TLS konfigurera och ange en plats för servern för att lagra OCSP-svaren. De exakta stegen beror på din serverprogramvara.
3. Testa din konfiguration: När du har konfigurerat din server bör du testa den för att säkerställa att den använder OCSP-häftning korrekt. Du kan göra detta genom att upprätta en TLS anslutning till din server och kontrollera att servern inkluderar ett OCSP-svar i TLS handslag.

Användningsfall: En onlineåterförsäljare använder OCSP-häftning för att snabbt verifiera statusen för sitt SSL-certifikat. Detta säkerställer att kunder alltid har en säker anslutning och kan lita på att deras data är säker. Återförsäljarens IT-team konfigurerar sin server för att använda OCSP-häftning, och de testar regelbundet funktionen för att säkerställa att den fungerar korrekt. Detta hjälper till att behålla kundernas förtroende och skydda deras känsliga data.

inaktivera TLS Komprimering för att mildra CRIME Attack

TLS komprimering är en funktion som kan förbättra prestandan för SSL/TLS genom att minska mängden data som behöver skickas över nätverket. Det kan dock också göra anslutningen sårbar för CRIME (Compression Ratio Info-leak Made Easy)-attacken, vilket kan göra det möjligt för en angripare att sluta sig till innehållet i krypterad trafik.

Så här kan du inaktivera TLS kompression: 

1. Se till att din serverprogramvara stöder inaktivering TLS kompression: Det första steget är att se till att din serverprogramvara stöder inaktivering TLS kompression. De flesta moderna webbservrar, inklusive Apache, Nginx och IIS, stöder den här funktionen.
2. Konfigurera din server: Nästa steg är att konfigurera din server så att den inaktiveras TLS kompression. De exakta stegen beror på din serverprogramvara. Till exempel, i Apache kan du lägga till en rad så här i din konfigurationsfil:

SSLCompression av

Den här raden talar om för servern att inte använda komprimering för SSL/TLS anslutningar.

3. Testa din konfiguration: När du har konfigurerat din server bör du testa den för att säkerställa att den inaktiveras korrekt TLS kompression. Du kan göra detta genom att upprätta en TLS anslutning till din server och kontrollera att anslutningen inte använder komprimering.

Användningsfall: En finansiell institution inaktiverar TLS komprimering på sina servrar för att skydda mot CRIME-attacken. Detta hjälper till att säkerställa sekretessen för känsliga finansiella uppgifter, såsom kontonummer och transaktionsdetaljer. Institutionens IT-team konfigurerar sina servrar för att inaktivera TLS komprimering, och de testar regelbundet servrarna för att säkerställa att de implementerar denna säkerhetsåtgärd korrekt. Detta hjälper till att skydda institutionens kunder och behålla deras förtroende.

Implementera TLS Sessionsbiljetter korrekt

TLS sessionsbiljetter är en del av TLS protokoll som kan förbättra prestandan genom att tillåta en klient och server att återuppta en tidigare session utan att behöva utföra en fullständig handskakning. De måste dock implementeras korrekt för att undvika potentiella säkerhetsproblem.

Så här kan du implementera på rätt sätt TLS sessionsbiljetter:

1. Se till att din serverprogramvara stöder TLS Sessionsbiljetter: Det första steget är att se till att din serverprogramvara stöder TLS sessionsbiljetter. De flesta moderna webbservrar, inklusive Apache, Nginx och IIS, stöder den här funktionen.
2. Konfigurera din server: Nästa steg är att konfigurera din server att använda TLS sessionsbiljetter. Detta innebär vanligtvis att du aktiverar funktionen i din servers SSL/TLS konfiguration. De exakta stegen beror på din serverprogramvara.
3. Använd unika sessionsbiljettnycklar: För att förhindra potentiella säkerhetsproblem bör varje server använda en unik sessionsbiljettnyckel. Om du använder en lastbalanserare bör du konfigurera den för att distribuera klienter baserat på deras sessionsbiljett, snarare än att låta klienter använda en sessionsbiljett utfärdad av en server för att upprätta en session med en annan server.
4. Rotera sessionsbiljettnycklar regelbundet: För att ytterligare förbättra säkerheten bör du regelbundet rotera dina sessionsbiljettnycklar. Detta kan ofta automatiseras med hjälp av din serverprogramvara eller ett separat nyckelhanteringssystem.

Användningsfall: Ett stort teknikföretag med flera servrar ser till att varje server använder en unik sessionsbiljettnyckel. Detta förhindrar att en angripare kan använda en sessionsbiljett från en server för att imitera en användare på en annan server. Företagets IT-team konfigurerar sina servrar att använda TLS sessionsbiljetter, och de sätter upp ett system för att regelbundet rotera sessionsbiljettnycklarna. De konfigurerar också sin lastbalanserare för att distribuera klienter baserat på deras sessionsbiljett, vilket ytterligare förbättrar säkerheten för deras system.

Aktivera säker omförhandling

Säker omförhandling är en funktion i SSL/TLS protokoll som gör att klienten eller servern kan begära en ny TLS handslag mitt under en session. Detta kan vara användbart av en mängd olika anledningar, som att uppdatera krypteringsnycklar eller ändra krypteringsnivån. Men om den inte hanteras säkert kan den utnyttjas av en angripare för att injicera klartext i den krypterade kommunikationen.

Så här kan du aktivera säker omförhandling:

2. Se till att din serverprogramvara stöder säker omförhandling: Det första steget är att se till att din serverprogramvara stöder säker omförhandling. De flesta moderna webbservrar, inklusive Apache, Nginx och IIS, stöder den här funktionen.
3. Konfigurera din server: Nästa steg är att konfigurera din server att använda säker omförhandling. Detta innebär vanligtvis att du aktiverar funktionen i din servers SSL/TLS konfiguration. De exakta stegen beror på din serverprogramvara.
4. Testa din konfiguration: När du har konfigurerat din server bör du testa den för att säkerställa att den fungerar korrekt med säker omförhandling. Du kan göra detta genom att upprätta en TLS anslutning till din server och sedan försöka omförhandla anslutningen.

Användningsfall: En social medieplattform möjliggör säker omförhandling för att skydda användardata. Detta förhindrar en angripare från att kunna injicera skadligt innehåll i den krypterade kommunikationen mellan användaren och servern. Plattformens IT-team konfigurerar sina servrar för att använda säker omförhandling, och de testar regelbundet servrarna för att säkerställa att de implementerar denna säkerhetsåtgärd korrekt. Detta hjälper till att skydda plattformens användare och behålla deras förtroende.

Inaktivera klientinitierad omförhandling för att förhindra DoS-attacker

Klientinitierad omförhandling är en funktion i SSL/TLS protokoll som gör att klienten kan begära en ny TLS handslag mitt i en session. Men om en angripare kan tvinga en server att kontinuerligt omförhandla sessioner, kan den förbruka överdrivna resurser och potentiellt leda till en DoS-attack (denial-of-service).

Så här kan du inaktivera klientinitierad omförhandling:

1. Se till att din serverprogramvara stöder inaktivering av klientinitierad omförhandling: Det första steget är att se till att din serverprogramvara stöder inaktivering av klientinitierad omförhandling. De flesta moderna webbservrar, inklusive Apache, Nginx och IIS, stöder den här funktionen.
2. Konfigurera din server: Nästa steg är att konfigurera din server för att inaktivera klientinitierad omförhandling. Detta innebär vanligtvis att du lägger till ett direktiv till din servers SSL/TLS konfiguration. De exakta stegen beror på din serverprogramvara.
3. Testa din konfiguration: När du har konfigurerat din server bör du testa den för att säkerställa att den korrekt inaktiverar klientinitierad omförhandling. Du kan göra detta genom att upprätta en TLS anslutning till din server och sedan försöka omförhandla anslutningen. Om servern korrekt vägrar omförhandlingsbegäran är den korrekt konfigurerad.

Användningsfall: En onlinespelplattform inaktiverar klientinitierad omförhandling för att skydda mot potentiella DoS-attacker. Detta hjälper till att säkerställa att plattformen förblir tillgänglig för användare att njuta av, även inför potentiella attacker. Plattformens IT-team konfigurerar sina servrar för att inaktivera klientinitierad omförhandling, och de testar regelbundet servrarna för att säkerställa att de implementerar denna säkerhetsåtgärd korrekt. Detta hjälper till att skydda plattformens användare och behålla deras förtroende.

Var uppmärksam på nya sårbarheter

Webbsäkerhet är ett ständigt rörande mål, och du bör alltid vara på jakt efter nästa attack och omedelbart tillämpa säkerhetsuppdateringar på din server. Detta innebär att du läser och håller kontakten med vad som är i horisonten när det gäller informationssäkerhet samt att hålla koll på programuppdateringar - särskilt de kritiska. SSL.coms webbplats (där du läser detta just nu) är en utmärkt källa för att hålla dig uppdaterad om SSL /TLS och informationssäkerhet.

Men hur är det med ...?

Om du vill veta mer om något av ämnena i den här guiden och lära dig om nya problem och tekniker när de uppstår, kan du börja med att bläddra och söka i SSL.coms Kunskapsbas, som vi uppdaterar varje vecka med ny utveckling inom SSL /TLS och PKI. Du kan också gärna kontakta vår supportpersonal när som helst via e-post på Support@SSL.com, i telefon kl 1-877-SSL-Secureeller genom att klicka på chattlänken längst ned till höger på den här sidan.

Få expertråd om SSL-certifikat.
Fyll i formuläret för en konsultation.