SSL /TLS Best practices voor 2023

In 2023 beveiligt u uw website met een SSL /TLS certificaat is niet langer optioneel, zelfs voor bedrijven die niet rechtstreeks omgaan met gevoelige klantinformatie op internet. Zoekmachines zoals Google gebruiken sitebeveiliging als een SEO-rangschikkingssignaal, en populaire webbrowsers zoals Chrome waarschuwen gebruikers voor websites die geen HTTPS gebruiken:

Het vooruitzicht om uw webservers en applicaties in te stellen om de SSL /TLS protocol correct kan ontmoedigend aanvoelen, omdat er veel geheimzinnige configuratie- en ontwerpkeuzes moeten worden gemaakt. Deze handleiding geeft een beknopt overzicht van de belangrijkste punten waarmee u rekening moet houden bij het instellen van SSL /TLS voor uw website, terwijl u zich richt op zowel beveiliging als prestaties. Er is nog veel te doen met alleen de basis, dus we hebben het opgesplitst in een reeks stappen.

Kies een betrouwbare certificeringsinstantie (CA)

Uw certificaten zijn zo betrouwbaar als de CA die ze uitgeeft. Alle publiekelijk vertrouwde CA's worden onderworpen aan strenge audits van derden om hun positie in belangrijke besturingssystemen en rootcertificaatprogramma's van browsers te behouden, maar sommige zijn beter in het behouden van die status dan andere. Zoek naar een CA die (zoals SSL.com):

• Doet het grootste deel van zijn zaken op het gebied van openbaar vertrouwd PKI. Deze bedrijven hebben het meeste te verliezen als slechte beveiligingspraktijken aan het licht komen, en alles te winnen door gelijke tred te houden met de veranderende industriestandaarden.
• Reageert efficiënt en effectief op ontdekkingen van kwetsbaarheden die de veiligheid en privacy van gebruikers aantasten, zoals de hele industrie serienummer entropie uitgave van begin 2019. Doorzoek brancheforums zoals mozilla.dev.beveiligingsbeleid kan u een goed idee geven over hoe een bepaalde CA op tegenspoed reageert.
• Biedt handige producten en diensten, zoals Extended Validation (EV) -certificaten, bulk / geautomatiseerde uitgifte van certificaten via een intuïtieve API of de ACME-protocol, eenvoudig beheer en bewakingsdiensten voor de levenscyclus van certificaten, en ondersteuning voor integratie met een uitgebreide lijst met oplossingen van derden.
• Heeft een reputatie voor geweldige klantenservice en technische ondersteuning. Het is belangrijk om de website van uw bedrijf 100% van de tijd veilig te houden en u moet een echte expert aan de telefoon kunnen krijgen als er iets misgaat.

Autorisatie van certificeringsinstantie (CAA)

Autorisatie van certificeringsinstantie (CAA) is een standaard om websites te beschermen door specifieke CA's aan te wijzen die certificaten voor een domeinnaam mogen uitgeven. Als u eenmaal een CA heeft gekozen, moet u dit overwegen CAA-records configureren om het te autoriseren.

Genereer en beveilig uw privésleutels

De SSL /TLS protocol gebruikt een paar sleutels om identiteiten te verifiëren en informatie te versleutelen die via internet is verzonden. Een van deze (de publieke sleutel) is bedoeld voor brede distributie, en de andere (de privé sleutel) moet zo veilig mogelijk worden bewaard. Deze sleutels worden samen gemaakt wanneer u een aanvraag voor certificaatondertekening (CSR). Hier zijn een paar tips om in gedachten te houden met betrekking tot uw privésleutels:

• Gebruik sterke privésleutels: Grotere sleutels zijn moeilijker te kraken, maar vereisen meer rekenkosten. Momenteel wordt ten minste een 2048-bits RSA-sleutel of 256-bits ECDSA-sleutel aanbevolen, en de meeste websites kunnen een goede beveiliging bereiken en tegelijkertijd de prestaties en gebruikerservaring met deze waarden optimaliseren.
  
  Opmerking: voor een overzicht van deze twee algoritmen, zie het artikel van SSL.com, Vergelijk ECDSA vs RSA.
• Bescherm uw privésleutels:
  • Genereer uw eigen privésleutels op een veilige en vertrouwde omgeving (bij voorkeur op de server waar ze worden geïmplementeerd of een apparaat dat voldoet aan FIPS of Common Criteria). nooit sta een CA (of iemand anders) toe om namens u privésleutels te genereren. Een gerenommeerde openbare CA, zoals SSL.com, zal nooit aanbieden om uw privésleutels te genereren of te verwerken, tenzij ze worden gegenereerd in een beveiligde hardwaretoken of HSM en niet kunnen worden geëxporteerd.
  • Geef alleen toegang tot privésleutels als dat nodig is. Genereer nieuwe sleutels en intrekken alle certificaten voor de oude sleutels wanneer medewerkers met private key-toegang het bedrijf verlaten.
  • Vernieuw certificaten zo vaak als praktisch mogelijk is (minstens jaarlijks zou goed zijn), bij voorkeur met elke keer een vers gegenereerde privésleutel. Automatiseringstools zoals de ACME-protocol zijn handig voor het plannen van regelmatige certificaatvernieuwingen.
  • Als een privésleutel is (of mogelijk is) gecompromitteerd, intrekken genereren alle certificaten voor deze sleutel een nieuw sleutelpaar en geven een nieuw certificaat af voor het nieuwe sleutelpaar.

Configureer uw server

Op het oppervlak, een SSL /TLS certificaat lijkt misschien een eenvoudige operatie; er zijn echter nog veel configuratiebeslissingen die moeten worden genomen om ervoor te zorgen dat uw webserver snel en veilig is en dat eindgebruikers een vlotte ervaring hebben zonder browserfouten en waarschuwingen. Hier zijn enkele configuratie-instructies om u op weg te helpen bij het instellen van SSL /TLS op uw servers:

• Zorg ervoor dat alle hostnamen bedekt zijn: Dekt uw certificaat de domeinnaam van uw site zowel met als zonder de www voorvoegsel? is er een Alternatieve naam voor onderwerp (SAN) voor elke domeinnaam die het certificaat moet beschermen?
• Installeer complete certificaatketens: Eindentiteit SSL /TLS certificaten worden over het algemeen ondertekend door tussenliggende certificaten in plaats van de root key van een CA. Zorg ervoor dat eventuele tussenliggende certificaten op uw webserver zijn geïnstalleerd om browsers een compleet certificeringspad en vermijd vertrouwenswaarschuwingen en fouten voor eindgebruikers. Uw CA kan u voorzien van alle noodzakelijke tussenproducten; Klanten van SSL.com kunnen onze Tussentijdse certificaatdownload pagina om tussenliggende bundels voor veel serverplatforms op te halen.
• Gebruik huidige SSL /TLS Protocollen (TLS 1.2 of 1.3): Eind 2018 kondigden alle grote browserleveranciers plannen aan om deze te beëindigen TLS 1.0 en 1.1 tegen de eerste helft van 2020. Google deprecated TLS v1.0 en v1.1 in Chrome 72 (uitgebracht op 30 januari 2919). Chrome-versies 84 (uitgebracht op 14 juli 2020) en hoger presenteren een interstitiële waarschuwing voor deze protocollen, en ondersteuning zou worden volledig verwijderd in mei 2021. Brede browserondersteuning van eerdere SSL /TLS versies, zoals SSL v3, zijn allang verdwenen. Terwijl TLS 1.2 is momenteel de meest gebruikte versie van de SSL /TLS protocol, TLS 1.3 (de nieuwste versie) is al ondersteund in de huidige versies van de meeste grote webbrowsers.
• Gebruik een korte lijst met veilige coderingssuites: Kies alleen coderingssuites die ten minste 128-bits codering bieden of, indien mogelijk, sterker. Het National Institute of Standards and Technology (NIST) beveelt dat ook allemaal aan TLS implementaties gaan weg van coderingssuites die de DES-codering (of zijn varianten) bevatten naar degenen die AES gebruiken. Ten slotte minimaliseert het gebruik van slechts een kleine subset van potentieel aanvaardbare coderingssuites het aanvalsoppervlak voor nog niet ontdekte kwetsbaarheden. De bijlage van SSL.com's Gids voor TLS Normen Compliance biedt voorbeeldconfiguraties voor de meest populaire webserverplatforms met TLS 1.2.
  
  Opmerking: Het gebruik van onveilige, verouderde codes (zoals RC4) kan browserbeveiligingsfouten veroorzaken, zoals ERR_SSL_VERSION_OR_CIPHER_MISMATCH in GoogleChrome.
• Gebruik Forward Secrecy (FS): Ook gekend als perfecte voorwaartse geheimhouding (PFS), FS verzekert dat een gecompromitteerde privésleutel niet ook de eerdere sessiesleutels in gevaar zal brengen. Om FS in te schakelen:
  • Configure TLS 1.2 om het sleuteluitwisselingsalgoritme Elliptic Curve Diffie-Hellman (EDCHE) te gebruiken (met DHE als terugval), en vermijd RSA-sleuteluitwisseling indien mogelijk volledig.
  • Te gebruiken TLS 1.3. TLS 1.3 biedt voorwaarts geheimhouding voor iedereen TLS sessies via de Kortstondige Diffie-Hellman (EDH of DHE) protocol voor sleuteluitwisseling.
• Enable TLS Hervatting van sessie: Vergelijkbaar met het gebruik van keepalives om persistente TCP-verbindingen te onderhouden, TLS sessie hervatten stelt uw webserver in staat om recent onderhandelde SSL /TLS sessies en hervat ze, waarbij de computationele overhead van sessiesleutelonderhandelingen wordt omzeild.
• Overweeg OCSP-nieten: OCSP-nieten stelt webservers in staat om gecachte intrekkingsinformatie rechtstreeks aan de client af te leveren, wat betekent dat een browser geen verbinding hoeft te maken met een OCSP-server om te controleren of het certificaat van een website is ingetrokken. Door dit verzoek weg te nemen, biedt OCSP-nieten een echte prestatieverbetering. Lees ons artikel voor meer informatie, Optimalisatie van pagina laden: OCSP-nieten.

Gebruik best practices voor het ontwerpen van webapplicaties

Het ontwerpen van uw webapplicaties met het oog op veiligheid is net zo belangrijk als het correct configureren van uw server. Dit zijn de belangrijkste punten om ervoor te zorgen dat uw gebruikers niet worden blootgesteld aan man in the middle aanvallen, en dat uw applicatie de SEO-voordelen krijgt die gepaard gaan met goede beveiligingspraktijken:

• Verwijder gemengde inhoud: JavaScript-bestanden, afbeeldingen en CSS-bestanden zouden moeten allen toegankelijk zijn met SSL /TLS. Zoals uiteengezet in het artikel van SSL.com, HTTPS Everywhere, serveren gemengde inhoud is niet langer een acceptabele manier om de websiteprestaties te verbeteren en kan leiden tot browserbeveiligingswaarschuwingen en SEO-problemen.
• Gebruik beveiligde cookies: Het instellen van Secure vlag in cookies zorgt voor verzending via beveiligde kanalen (bijv. HTTPS). U kunt ook voorkomen dat JavaScript aan de clientzijde toegang krijgt tot cookies via de HttpOnly markeren en cross-site gebruik van cookies beperken met de SameSite vlag.
• Evalueer code van derden: Zorg ervoor dat u de mogelijke risico's begrijpt van het gebruik van bibliotheken van derden op uw website, zoals de mogelijkheid dat u per ongeluk kwetsbaarheden of schadelijke code introduceert. Onderzoek de betrouwbaarheid van derden altijd zo goed mogelijk en koppel met HTTPS naar alle code van derden. Zorg er ten slotte voor dat uw voordeel van elementen van derden op uw website het risico waard is.

Controleer uw werk met diagnostische hulpmiddelen

Na het instellen van SSL /TLS op uw server en website of als u configuratiewijzigingen aanbrengt, is het belangrijk om ervoor te zorgen dat alles correct is ingesteld en dat uw systeem veilig is. Er zijn tal van diagnostische tools beschikbaar om de SSL /TLS. Bijvoorbeeld SSL Shopper's SSL-checker zal u laten weten of uw certificaat correct is geïnstalleerd, wanneer het verloopt, en zal de certificaten weergeven keten van vertrouwen.

Er zijn andere online tools en applicaties beschikbaar die uw site crawlen en controleren op beveiligingsproblemen zoals gemengde inhoud. U kunt ook controleren op gemengde inhoud met een webbrowser met behulp van de ingebouwde tools voor ontwikkelaars:

Welke tools u ook kiest, het is ook belangrijk om een ​​schema op te stellen voor het controleren van uw SSL /TLS installatie en configuratie. Uw CA kan u hierbij wellicht ook helpen; Bijvoorbeeld, voor het gemak voor onze klanten, biedt SSL.com geautomatiseerde kennisgevingen van de naderende vervaldatum van certificaten.

Implementeer HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security (HSTS) is een beveiligingsbeleidsmechanisme dat websites helpt beschermen tegen protocol-downgrade-aanvallen en het kapen van cookies. Het stelt webservers in staat te verklaren dat webbrowsers (of andere gebruikersagenten die hieraan voldoen) er alleen mee mogen communiceren via beveiligde HTTPS-verbindingen en nooit via het onveilige HTTP-protocol. Dit beleid wordt door de server aan de user-agent gecommuniceerd via een HTTP-antwoordheaderveld met de naam "Strict-Transport-Security".

Implementeren HTTP strikte transportbeveiliging (HSTS), moet u een speciale antwoordkop toevoegen aan de configuratie van uw webserver.

Hier is een stapsgewijze handleiding:

1. Zorg ervoor dat uw site HTTPS ondersteunt: Voordat u HSTS inschakelt, moet uw site een geldig SSL-certificaat en inhoud via HTTPS kunnen aanbieden. Als uw site nog niet is geconfigureerd voor HTTPS, moet u dit doen een SSL-certificaat verkrijgen en configureer uw server om deze te gebruiken.

Header altijd ingesteld op Strict-Transport-Security "max-age=31536000; includeSubDomains"

_{Deze regel vertelt de browser om het komende jaar (31,536,000 seconden) altijd HTTPS voor uw site te gebruiken, inclusief alle subdomeinen.}

2. Test uw configuratie: Nadat u de HSTS-header hebt toegevoegd, moet u uw site testen om er zeker van te zijn dat deze correct werkt. U kunt dit doen door uw site te bezoeken en de ontwikkelaarstools van uw browser te gebruiken om de antwoordkoppen te controleren. U zou de koptekst Strict-Transport-Security moeten zien met de waarde die u hebt ingesteld.
3. Overweeg om uw site toe te voegen aan de HSTS-preloadlijst: De HSTS-preloadlijst is een lijst met sites die in browsers hard zijn gecodeerd als HSTS-enabled. Dit biedt een extra beschermingsniveau, omdat het ervoor zorgt dat de eerste verbinding met uw site veilig is, zelfs voordat de HSTS-header is ontvangen. U kunt uw site aanmelden bij de HSTS-preloadlijst op hstspreload.org.

Use Case: Een nieuwswebsite wil ervoor zorgen dat zijn gebruikers er altijd veilig verbinding mee maken, zelfs als ze per ongeluk 'http' in plaats van 'https' in de URL typen. De website gebruikt HSTS door de Strict-Transport-Security-header toe te voegen aan de serverconfiguratie, een lange maximale leeftijd in te stellen en alle subdomeinen op te nemen. Dit vertelt user-agents om er altijd verbinding mee te maken via HTTPS, waardoor gebruikers worden beschermd tegen aanvallen die proberen de verbinding naar HTTP te downgraden en hun cookies te stelen. De website onderwerpt zich ook aan de HSTS-preloadlijst voor extra bescherming.

Implementeer HTTP Public Key Pinning (HPKP)

HTTP Public Key Pinning (HPKP) was een beveiligingsfunctie waarmee een webserver een specifieke cryptografische openbare sleutel aan zichzelf kon koppelen om te voorkomen dat man-in-the-middle (MITM) -aanvallen met vervalste certificaten.

Hier is een kort overzicht van hoe het werd gebruikt:

1. Pinning-informatie genereren: De eerste stap bij het implementeren van HPKP was het genereren van de pinning-informatie. Dit omvatte het maken van een cryptografische hash van de openbare sleutel van het certificaat of de openbare sleutel van het intermediate- of rootcertificaat.
2. Configureer de webserver: De volgende stap was het configureren van de webserver om de HTTP met openbare sleutelpins koptekst in reacties. Deze header omvatte de hashes van de openbare sleutels (de "pins"), een tijd tot leven (hoe lang de browser de informatie moet onthouden) en optioneel een rapport-URI (waar de browser rapporten over mislukte pin-validatie naartoe zou sturen).
3. Omgaan met pinvalidatiefouten: Als een browser die HPKP ondersteunt een certificaatketen ontvangt die niet ten minste één van de vastgezette openbare sleutels bevat, wordt de verbinding als niet-vertrouwd beschouwd. Als er een rapport-URI was opgegeven, zou de browser ook een rapport van de fout naar die URI sturen.

Vanwege het risico op misbruik en de mogelijkheid om denial of service te veroorzaken, is HPKP echter door de meeste browsers verouderd en wordt het niet langer aanbevolen. Verkeerde configuratie van HPKP kan leiden tot een situatie waarin een website ontoegankelijk wordt.

Use Case: In het verleden gebruikte een technologiebedrijf HPKP om hun openbare sleutels vast te pinnen op hun servers. Dit zorgde ervoor dat als een certificeringsinstantie (CA) werd gecompromitteerd en er per ongeluk een certificaat voor hun domein werd uitgegeven, browsers het niet zouden vertrouwen tenzij het ook een openbare sleutel had die overeenkwam met een van de vastgezette sleutels. Ze moesten echter heel voorzichtig zijn om te voorkomen dat ze de toegang tot de vastgezette sleutels zouden verliezen, waardoor hun website ontoegankelijk zou worden. Ze moesten er ook voor zorgen dat ze een proces hadden om de pinnen te roteren voordat ze verliepen, om te voorkomen dat hun site ontoegankelijk zou worden voor gebruikers met in de cache opgeslagen pingegevens.

Te gebruiken TLS Fallback SCSV om protocoldowngrade-aanvallen te voorkomen

TLS Terugval SCSV (Signalering Cipher Suite-waarde) is een mechanisme dat is geïntroduceerd om protocoldowngrade-aanvallen te voorkomen. Deze aanvallen vinden plaats wanneer een aanvaller het verbindingsconfiguratieproces verstoort en de client en server misleidt om een ​​minder veilige versie van het protocol te gebruiken dan ze beide daadwerkelijk ondersteunen.

Hier ziet u hoe u kunt implementeren TLS Terugval SCSV:

1. Update de SSL/TLS Bibliotheek: De eerste stap is ervoor te zorgen dat de SSL/TLS bibliotheek ondersteunt TLS Terugval SCSV. Deze functie is geïntroduceerd in OpenSSL 1.0.1j, 1.0.0o en 0.9.8zc. Als u een andere SSL/TLS bibliotheek, controleer de documentatie of neem contact op met de ontwikkelaars.
2. Configureer uw server: Zodra de SSL/TLS bibliotheek ondersteunt TLS Fallback SCSV, moet u mogelijk uw server configureren om deze te gebruiken. De exacte stappen zijn afhankelijk van uw serversoftware. In Apache moet u bijvoorbeeld een regel in uw configuratiebestand als volgt toevoegen of wijzigen:

SSLProtocol Alle -SSLv2 -SSLv3

Deze regel vertelt de server om alle protocolversies te gebruiken behalve SSLv2 en SSLv3. Als de client en server beide ondersteunen TLS 1.2, maar de client probeert te gebruiken TLS 1.1 (misschien vanwege inmenging van een aanvaller), zal de server dit herkennen als een fallback-poging en de verbinding afwijzen.

3. Test uw server: Na het configureren van uw server, moet u deze testen om er zeker van te zijn dat deze correct wordt geïmplementeerd TLS Terugval SCSV. Er zijn verschillende online tools die je hierbij kunnen helpen, zoals de SSL Labs Server Test.

Use Case: Een wereldwijd bedrijf gebruikt TLS Fallback SCSV om de interne communicatie te beschermen. Dit zorgt ervoor dat als een aanvaller een protocoldowngrade probeert te forceren, de server dit zal herkennen en de verbinding zal weigeren, waardoor de gevoelige gegevens van het bedrijf worden beschermd. Het IT-team van het bedrijf werkt regelmatig de SSL/TLS bibliotheken en configuraties om ervoor te zorgen dat ze de nieuwste beveiligingsfuncties gebruiken, en ze gebruiken online tools om hun servers te testen en te bevestigen dat ze correct implementeren TLS Terugval SCSV.

Vermijd problemen met gemengde inhoud

Gemengde inhoud is een beveiligingsrisico dat optreedt wanneer een webpagina die via een beveiligde HTTPS-verbinding wordt geladen, bronnen bevat, zoals afbeeldingen, video's, stylesheets of scripts, die via een onveilige HTTP-verbinding worden geladen. Browsers kunnen deze gemengde inhoud blokkeren of een waarschuwing aan de gebruiker tonen, wat de perceptie van de gebruiker van de veiligheid van de site kan schaden.

Zo kunt u problemen met gemengde inhoud voorkomen:

1. Gebruik HTTPS voor alle bronnen: De eenvoudigste manier om gemengde inhoud te vermijden, is ervoor te zorgen dat alle bronnen op uw site via HTTPS worden geladen. Dit omvat afbeeldingen, scripts, stylesheets, iframes, AJAX-verzoeken en alle andere bronnen die uw site gebruikt.
2. Werk de code van uw site bij: Als de code van uw site hard-coded HTTP-URL's voor bronnen bevat, moet u deze bijwerken om in plaats daarvan HTTPS te gebruiken. Als de bron wordt gehost op een server die HTTPS niet ondersteunt, moet u de bron mogelijk op uw eigen server hosten of een alternatieve bron zoeken die via HTTPS kan worden geladen.
3. Configureer uw server om een ​​koptekst voor inhoud-beveiligingsbeleid te verzenden: Met de HTTP-header Content-Security-Policy (CSP) kunt u bepalen welke bronnen uw site mag laden. Door een CSP-header in te stellen die alleen HTTPS-bronnen toestaat, kunt u ervoor zorgen dat uw site niet per ongeluk gemengde inhoud bevat.

Use Case: Een online magazine zorgt ervoor dat alle inhoud, inclusief afbeeldingen en scripts, via HTTPS wordt geladen. Dit voorkomt dat aanvallers met deze bronnen knoeien en mogelijk schadelijke inhoud injecteren. De webontwikkelaars van het tijdschrift bekijken regelmatig de code van de site om ervoor te zorgen dat alle bronnen via HTTPS worden geladen, en ze configureren hun server om een ​​strikte Content-Security-Policy-header te verzenden. Ze gebruiken ook online tools om hun site te scannen op problemen met gemengde inhoud en eventuele problemen op te lossen.

Gebruik Server Name Indication (SNI) voor het hosten van meerdere sites

Servernaamindicatie (SNI) is een uitbreiding op de TLS protocol waarmee een server meerdere certificaten op hetzelfde IP-adres en poortnummer kan presenteren. Dit is met name handig voor webhostingproviders die meerdere beveiligde websites moeten hosten, elk met hun eigen SSL-certificaat, op dezelfde server.

Zo kunt u SNI gebruiken:

1. Zorg ervoor dat uw serversoftware SNI ondersteunt: De eerste stap is ervoor te zorgen dat uw serversoftware SNI ondersteunt. De meeste moderne webservers, waaronder Apache, Nginx en IIS, ondersteunen SNI.
2. Configureer uw server: De volgende stap is het configureren van uw server om SNI te gebruiken. Dit omvat meestal het toevoegen van een afzonderlijk configuratieblok voor elke site die u op de server wilt hosten en het specificeren van de SSL-certificaat te gebruiken voor elke site. De exacte stappen zijn afhankelijk van uw serversoftware.
3. Test uw configuratie: Na het configureren van uw server, moet u deze testen om er zeker van te zijn dat deze SNI correct gebruikt. U kunt dit doen door elke site die u op de server host te bezoeken en te controleren of het juiste SSL-certificaat wordt gebruikt.

Use Case: Een hostingprovider gebruikt SNI om meerdere websites vanaf hetzelfde IP-adres te bedienen. Hierdoor kunnen ze hun IP-adresruimte efficiënt gebruiken en hun netwerkconfiguratie vereenvoudigen. Ze configureren hun server om voor elke site een ander SSL-certificaat te gebruiken en testen regelmatig hun configuratie om er zeker van te zijn dat voor elke site het juiste certificaat wordt gebruikt. Dit zorgt ervoor dat elke site een veilige, vertrouwde verbinding heeft, ook al worden ze allemaal bediend vanaf hetzelfde IP-adres.

Optimaliseer de prestaties met sessiehervatting

Sessiehervatting is een kenmerk van de TLS protocol waarmee een client en server dezelfde coderingssleutels kunnen gebruiken voor meerdere sessies, waardoor de overhead van het telkens opzetten van een nieuwe veilige verbinding wordt verminderd. Dit kan de prestaties aanzienlijk verbeteren, met name voor toepassingen waarbij de client vaak de verbinding verbreekt en opnieuw verbindt.

 Zo kunt u sessiehervatting gebruiken:

1. Zorg ervoor dat uw serversoftware sessiehervatting ondersteunt: De eerste stap is ervoor te zorgen dat uw serversoftware het hervatten van sessies ondersteunt. De meeste moderne webservers, waaronder Apache, Nginx en IIS, ondersteunen deze functie.
2. Configureer uw server: De volgende stap is het configureren van uw server om sessiehervatting te gebruiken. Dit omvat meestal het inschakelen van de sessiecache en het instellen van een time-outwaarde voor de cache. De exacte stappen zijn afhankelijk van uw serversoftware.
3. Test uw configuratie: Na het configureren van uw server, moet u deze testen om er zeker van te zijn dat de sessiehervatting correct wordt gebruikt. Dit doe je door een TLS verbinding maken met uw server, de verbinding verbreken en opnieuw verbinden. Als het hervatten van de sessie correct werkt, zou de tweede verbinding sneller tot stand moeten komen dan de eerste.

Use Case: Een mobiele app gebruikt sessiehervatting om snelle en veilige verbindingen te onderhouden. Dit is met name handig wanneer de app wordt gebruikt in gebieden met een slechte netwerkdekking, omdat de app hierdoor snel een veilige verbinding kan herstellen na een uitval. De ontwikkelaars van de app configureren hun server om sessiehervatting te gebruiken en ze testen de functie regelmatig om er zeker van te zijn dat deze correct werkt. Dit zorgt ervoor dat de app gebruikers een snelle, naadloze ervaring kan bieden, zelfs in uitdagende netwerkomstandigheden.

Garandeer de geldigheid van het certificaat met OCSP-nieten

Online Certificate Status Protocol (OCSP) nieten is een methode om de prestaties van SSL/TLS met behoud van de veiligheid van de verbinding. Hiermee kan de server de huidige status van zijn eigen certificaten ophalen bij de certificeringsinstantie (CA) en die status vervolgens afleveren aan clients tijdens de TLS handdruk.

Zo kunt u OCSP-nieten implementeren:

1. Zorg ervoor dat uw serversoftware OCSP-nieten ondersteunt: De eerste stap is ervoor te zorgen dat uw serversoftware OCSP-nieten ondersteunt. De meeste moderne webservers, waaronder Apache, Nginx en IIS, ondersteunen deze functie.
2. Configureer uw server: De volgende stap is het configureren van uw server om OCSP-nieten te gebruiken. Meestal gaat het om het inschakelen van de functie in de SSL/TLS configuratie en het specificeren van een locatie voor de server om de OCSP-antwoorden op te slaan. De exacte stappen zijn afhankelijk van uw serversoftware.
3. Test uw configuratie: Nadat u uw server hebt geconfigureerd, moet u deze testen om er zeker van te zijn dat deze correct OCSP-nieten gebruikt. Dit doe je door een TLS verbinding maken met uw server en controleren of de server een OCSP-antwoord bevat in het TLS handdruk.

Use Case: Een online retailer gebruikt OCSP-nieten om snel de status van zijn SSL-certificaat te verifiëren. Dit zorgt ervoor dat klanten altijd een veilige verbinding hebben en erop kunnen vertrouwen dat hun gegevens veilig zijn. Het IT-team van de detailhandelaar configureert hun server om OCSP-nieten te gebruiken en ze testen de functie regelmatig om er zeker van te zijn dat deze correct werkt. Dit helpt om het vertrouwen van hun klanten te behouden en hun gevoelige gegevens te beschermen.

onbruikbaar maken TLS Compressie om CRIME Attack te verminderen

TLS compressie is een functie die de prestaties van SSL/TLS door de hoeveelheid gegevens te verminderen die via het netwerk moet worden verzonden. Het kan de verbinding echter ook kwetsbaar maken voor de CRIME-aanval (Compression Ratio Info-leak Made Easy), waardoor een aanvaller de inhoud van versleuteld verkeer kan afleiden.

Hier leest u hoe u kunt uitschakelen TLS compressie: 

1. Zorg ervoor dat uw serversoftware uitschakelen ondersteunt TLS Samendrukking: De eerste stap is ervoor te zorgen dat uw serversoftware uitschakelen ondersteunt TLS compressie. De meeste moderne webservers, waaronder Apache, Nginx en IIS, ondersteunen deze functie.
2. Configureer uw server: De volgende stap is het configureren van uw server om uit te schakelen TLS compressie. De exacte stappen zijn afhankelijk van uw serversoftware. In Apache zou u bijvoorbeeld een regel als deze aan uw configuratiebestand kunnen toevoegen:

SSLCompressie uit

Deze regel vertelt de server om geen compressie te gebruiken voor SSL/TLS verbindingen.

3. Test uw configuratie: Na het configureren van uw server, moet u deze testen om er zeker van te zijn dat deze correct wordt uitgeschakeld TLS compressie. Dit doe je door een TLS verbinding maken met uw server en controleren of de verbinding geen compressie gebruikt.

Use Case: Een financiële instelling schakelt uit TLS compressie op zijn servers ter bescherming tegen de CRIME-aanval. Dit helpt om de vertrouwelijkheid van gevoelige financiële gegevens, zoals rekeningnummers en transactiegegevens, te waarborgen. Het IT-team van de instelling configureert hun servers om uit te schakelen TLS compressie, en ze testen regelmatig de servers om er zeker van te zijn dat ze deze beveiligingsmaatregel correct implementeren. Dit helpt de klanten van de instelling te beschermen en hun vertrouwen te behouden.

Implementeren TLS Sessietickets correct

TLS sessietickets zijn een kenmerk van de TLS protocol dat de prestaties kan verbeteren door een client en server een eerdere sessie te laten hervatten zonder een volledige handshake uit te voeren. Ze moeten echter correct worden geïmplementeerd om mogelijke beveiligingsproblemen te voorkomen.

Hier leest u hoe u correct kunt implementeren TLS sessie tickets:

1. Zorg ervoor dat uw serversoftware dit ondersteunt TLS Sessie Tickets: De eerste stap is ervoor te zorgen dat uw serversoftware dit ondersteunt TLS sessie kaartjes. De meeste moderne webservers, waaronder Apache, Nginx en IIS, ondersteunen deze functie.
2. Configureer uw server: De volgende stap is het configureren van uw server om te gebruiken TLS sessie kaartjes. Meestal gaat het om het inschakelen van de functie in de SSL/TLS configuratie. De exacte stappen zijn afhankelijk van uw serversoftware.
3. Gebruik unieke sessieticketsleutels: Om mogelijke beveiligingsproblemen te voorkomen, moet elke server een unieke sessieticketsleutel gebruiken. Als u een load balancer gebruikt, moet u deze zo configureren dat clients worden gedistribueerd op basis van hun sessieticket, in plaats van dat clients een sessieticket mogen gebruiken dat door de ene server is uitgegeven om een ​​sessie met een andere server tot stand te brengen.
4. Draai sessieticketsleutels regelmatig om: Om de beveiliging verder te verbeteren, dient u uw sessieticketsleutels regelmatig te rouleren. Dit kan vaak worden geautomatiseerd met behulp van uw serversoftware of een apart sleutelbeheersysteem.

Use Case: Een groot technologiebedrijf met meerdere servers zorgt ervoor dat elke server een unieke sessieticketsleutel gebruikt. Dit voorkomt dat een aanvaller een sessieticket van de ene server kan gebruiken om zich voor te doen als een gebruiker op een andere server. Het IT-team van het bedrijf configureert hun servers voor gebruik TLS sessietickets, en ze hebben een systeem opgezet om de sessieticketsleutels regelmatig te rouleren. Ze configureren ook hun load balancer om clients te verdelen op basis van hun sessieticket, waardoor de beveiliging van hun systeem verder wordt verbeterd.

Veilig heronderhandelen inschakelen

Veilig heronderhandelen is een kenmerk van de SSL/TLS protocollen waarmee de client of server een nieuwe kan aanvragen TLS handdruk tijdens een sessie. Dit kan om verschillende redenen nuttig zijn, zoals het vernieuwen van coderingssleutels of het wijzigen van het coderingsniveau. Als het echter niet veilig wordt behandeld, kan het door een aanvaller worden misbruikt om leesbare tekst in de versleutelde communicatie te injecteren.

Zo kunt u veilig opnieuw onderhandelen inschakelen:

2. Zorg ervoor dat uw serversoftware veilige heronderhandeling ondersteunt: De eerste stap is ervoor te zorgen dat uw serversoftware veilige heronderhandeling ondersteunt. De meeste moderne webservers, waaronder Apache, Nginx en IIS, ondersteunen deze functie.
3. Configureer uw server: De volgende stap is het configureren van uw server om veilig opnieuw onderhandelen te gebruiken. Meestal gaat het om het inschakelen van de functie in de SSL/TLS configuratie. De exacte stappen zijn afhankelijk van uw serversoftware.
4. Test uw configuratie: Nadat u uw server heeft geconfigureerd, moet u deze testen om er zeker van te zijn dat deze correct werkt met veilige heronderhandeling. Dit doe je door een TLS verbinding maken met uw server en vervolgens proberen de verbinding opnieuw tot stand te brengen.

Use Case: Een social media-platform maakt veilige heronderhandeling mogelijk om gebruikersgegevens te beschermen. Dit voorkomt dat een aanvaller schadelijke inhoud kan injecteren in de versleutelde communicatie tussen de gebruiker en de server. Het IT-team van het platform configureert hun servers om veilige heronderhandeling te gebruiken en ze testen de servers regelmatig om er zeker van te zijn dat ze deze beveiligingsmaatregel correct implementeren. Dit helpt de gebruikers van het platform te beschermen en hun vertrouwen te behouden.

Schakel door de klant geïnitieerde heronderhandeling uit om DoS-aanvallen te voorkomen

Door de klant geïnitieerde heronderhandeling is een kenmerk van de SSL/TLS protocollen waarmee de klant een nieuwe kan aanvragen TLS handdruk tijdens een sessie. Als een aanvaller een server echter kan dwingen om continu opnieuw te onderhandelen over sessies, kan dit buitensporige bronnen verbruiken en mogelijk leiden tot een denial-of-service (DoS)-aanval.

Zo kunt u door de klant geïnitieerde heronderhandeling uitschakelen:

1. Zorg ervoor dat uw serversoftware het uitschakelen van door de client geïnitieerde heronderhandeling ondersteunt: De eerste stap is ervoor te zorgen dat uw serversoftware het uitschakelen van door de client geïnitieerde heronderhandeling ondersteunt. De meeste moderne webservers, waaronder Apache, Nginx en IIS, ondersteunen deze functie.
2. Configureer uw server: De volgende stap is het configureren van uw server om door de client geïnitieerde heronderhandeling uit te schakelen. Dit omvat meestal het toevoegen van een richtlijn aan de SSL/TLS configuratie. De exacte stappen zijn afhankelijk van uw serversoftware.
3. Test uw configuratie: Nadat u uw server hebt geconfigureerd, moet u deze testen om er zeker van te zijn dat door de client geïnitieerde heronderhandeling correct wordt uitgeschakeld. Dit doe je door een TLS verbinding maken met uw server en vervolgens proberen de verbinding opnieuw tot stand te brengen. Als de server het heronderhandelingsverzoek correct weigert, is het correct geconfigureerd.

Use Case: Een online gamingplatform schakelt door de klant geïnitieerde heronderhandeling uit om bescherming te bieden tegen mogelijke DoS-aanvallen. Dit helpt ervoor te zorgen dat het platform beschikbaar blijft voor gebruikers, zelfs bij mogelijke aanvallen. Het IT-team van het platform configureert hun servers om door de klant geïnitieerde heronderhandeling uit te schakelen en ze testen de servers regelmatig om er zeker van te zijn dat ze deze beveiligingsmaatregel correct implementeren. Dit helpt de gebruikers van het platform te beschermen en hun vertrouwen te behouden.

Blijf alert voor nieuwe kwetsbaarheden

Webbeveiliging is een constant bewegend doelwit en u moet altijd uitkijken naar de volgende aanval en onmiddellijk beveiligingspatches op uw server toepassen. Dit betekent lezen en in contact blijven met wat er aan de horizon komt als het gaat om informatiebeveiliging, evenals het bijhouden van software-updates - vooral de kritieke. SSL.com's website (waar u dit nu leest) is een geweldige bron om op de hoogte te blijven van SSL /TLS en informatiebeveiliging.

Maar hoe zit het met…?

Als u meer wilt weten over een van de onderwerpen die in deze handleiding worden behandeld en meer wilt weten over nieuwe problemen en technologieën wanneer deze zich voordoen, kunt u beginnen door te bladeren en te zoeken in SSL.com's Kennisbank, die we wekelijks op de hoogte houden van nieuwe ontwikkelingen op het gebied van SSL /TLS en PKI. U kunt ook altijd contact opnemen met onze ondersteuningsmedewerkers via e-mail op Support@SSL.com, aan de telefoon op 1-877-SSL-Secure, of door op de chatlink rechtsonder op deze pagina te klikken.

Krijg deskundig advies over SSL-certificaten.
Vul het formulier in voor een consult.