Guide til TLS Standarder Overholdelse

Transportlagets sikkerhed (TLS) protokol er det primære middel til at beskytte netværkskommunikation over Internettet. Denne artikel er en kort vejledning, der hjælper dig med at konfigurere en sikker server til at imødekomme den aktuelle TLS standarder.

Introduktion

Transportlagsikkerhed (TLS) protokol er det primære middel til at beskytte netværkskommunikation via Internettet. Det (og dets forgænger, Secure Sockets Layer eller SSL) har været brugt i årtier i mange applikationer, men især i browsere, når de besøger HTTPS websteder. TLS fungerer normalt stille i baggrunden, men i modsætning til hvad man måske tror, TLS er ikke en sort boks, der bare fungerer. Snarere sikkerheden TLS tilvejebringer opstår fra samarbejde med forskellige kryptografiske algoritmer. I øvrigt, TLSSom SSL før udvikler det sig konstant med sikkerhedsbranchen - ny teknologi og forretningskrav skal opfyldes, mens de nyeste sikkerhedstrusler skal afhjælpes. Algoritmer kan blive forældede over tid, eller praksis kan opgives, idet hver ændring påvirker den generelle sikkerhed for en TLS forekomst (som den, der beskytter din forbindelse lige nu).

Denne volatilitet har motiveret forskellige standardiseringsorganisationer til at offentliggøre retningslinjedokumenter, så der er et minimumsgrundlag for TLS sikkerhed kunne etableres i et bestemt marked, sektor eller tjenesteydelse. Desværre er der adskillige sådanne standarder, hvor forskellige sektorer kræver overholdelse af forskellige, gældende dokumenter, mens standarderne selv også udvikle sig over tid og imødekomme ændringer i den sektor, de var designet til at beskytte.

Forståeligt nok at navigere gennem dette hav af standarder for at oprette et moderne TLS eksempel kan være en reel hovedpine for administratorer. Denne artikel er en kort vejledning, der hjælper dig med at konfigurere en sikker server, så den lever op til forventet TLS standarder i 2021. (For yderligere hjælp har vi også givet eksempler på konfigurationer af de mest populære webserverløsninger i bilag.)

Standarderne

Der er flere enheder, som opretholder retningslinjer for TLS med hensyn til netværkssikkerhed, såsom det amerikanske Department of Health and Human Services (HHS) eller National Institute of Standards and Technology (NIST). Af kortheds skyld vil denne artikel kun studere de tre mest vedtagne dokumenter:

1. Sundhedsforsikring Portabilitet og ansvarlighed lov (HIPAA)
2. NIST s SP 800-52r2 retningslinjer
3. Betalingskort Branche for datasikkerhed (PCI-DSS)

HIPAA

HIPAA er en forordning vedtaget af den amerikanske regering i 1996 vedrørende sikker håndtering af Beskyttet sundhedsinformation (PHI). PHI henviser til enhver digital patientinformation, såsom testresultater eller diagnoser. En HIPAA vejledningsdokument offentliggjort i 2013 hedder følgende:

Gyldige krypteringsprocesser for data i bevægelse er dem, der efter behov overholder NIST Special Publications 800-52, Retningslinjer for udvælgelse og brug af transportlagssikkerhed (TLS) Implementeringer 800-77, Guide til IPsec VPN'er; eller 800-113, Guide til SSL VPN'er eller andre, der er Federal Information Processing Standards (FIPS) 140-2 valideret.

NIST standarder

I 2005 offentliggjorde NIST specialpublikation (SP) 800-52, der beskriver de korrekte operationelle procedurer til sikker konfigurering af en TLS eksempel for offentlige servere. SP 800-52 er siden blevet erstattet af versioner SP 800-52r1 (2014) og SP 80052r2 (2019). Denne artikel følger retningslinjerne i SP 800-52r2, som i øjeblikket er stabil.

PCI DSS

PCI-DSS er en overholdelsesstandard vedligeholdt af Payment Card Industry (PCI) Standards Security Council (SSC), der fastlægger, hvordan betaling og kortinformation håndteres af e-handelswebsteder. Med hensyn til den korrekte konfiguration af TLS tilfælde, angiver PCI-DSS:

"Se industristandarder og bedste praksis for information om stærk kryptografi og sikre protokoller (f.eks. NIST SP 800-52 og SP 800-57, OWASP osv.)"

TLS standarder: at sætte alt sammen

Det skal bemærkes nu, at hver standard påvirker forskellige systemer, baseret på deres funktion og de data, de håndterer. For eksempel kan en hospitals-e-mail-server falde ind under HIPAA-retningslinjerne, fordi udvekslede meddelelser muligvis indeholder patientoplysninger, mens hospitalets CRM-system muligvis falder ind under PCI-DSS, fordi det kan indeholde kreditkort- og andre kundedata. At være i overensstemmelse med alle tre standarder kræver brug af fælles TLS parametre, der findes i alle dokumenter.

Heldigvis er det åbenlyst, at alle standarder følger NISTs retningslinjer for valg af TLS parametre. Dette betyder, at i overensstemmelse med SP 800-52r2, skal en server også være kompatibel med HIPAA og PCI-DSS. (Okay, det er det ikke præcist nok sandt, men tingene bliver klarere i det næste afsnit.)

Konfigurerbar TLS parametre

Sikkerhedsniveauet der TLS giver påvirkes mest af protokolversion (dvs. 1.0, 1.1 osv.) og det tilladte chiffer suiter. Cifere er algoritmer, der udfører kryptering og dekryptering. Dog a chiffer suite er et sæt algoritmer, herunder en chiffer, en nøgleudvekslingsalgoritme og en hashingsalgoritme, der bruges sammen til at etablere en sikker TLS forbindelse. Mest TLS klienter og servere understøtter flere alternativer, så de er nødt til at forhandle, når der oprettes en sikker forbindelse for at vælge en fælles TLS version og chiffer-pakke.

TLS protokolversion

Vedrørende TLS versionstøtte, NIST SP 800-52r2 angiver følgende:

Servere, der understøtter applikationer, der kun er offentlige skal være konfigureret til at bruge TLS 1.2 og bør være konfigureret til at bruge TLS 1.3 også. Disse servere burde ikke være konfigureret til at bruge TLS 1.1 og skal ikke brug TLS 1.0, SSL 3.0 eller SSL 2.0.

...

Servere, der understøtter borger- eller forretningsapplikationer (dvs. klienten er muligvis ikke en del af et offentligt it-system) skal være konfigureret til at forhandle TLS 1.2 og bør være konfigureret til at forhandle TLS 1.3. Brugen af TLS version 1.1 og 1.0 frarådes generelt, men disse versioner kan konfigureres, når det er nødvendigt for at muliggøre interaktion med borgere og virksomheder ... Disse servere skal ikke tillad brug af SSL 2.0 eller SSL 3.0.

Agenturer skal support TLS 1.3 inden 1. januar 2024. Efter denne dato servere skal support TLS 1.3 til både offentlige myndigheder og borger- eller forretningsapplikationer. Generelt servere, der understøtter TLS 1.3 bør være konfigureret til at bruge TLS 1.2 også. Imidlertid, TLS 1.2 kan deaktiveres på servere, der understøtter TLS 1.3, hvis det er bestemt, at TLS 1.2 er ikke nødvendig for interoperabilitet.

Mens TLS 1.0 er forbudt og TLS 1.1 udskrives for statslige websteder, NIST-retningslinjer angiver, at for kompatibilitet med tredjeparts tjenester, regeringskontrollerede servere kan gennemføre TLS 1.0 og 1.1, når det er nødvendigt. Under PCI-DSS 3.2.1 (den nuværende version), kompatible servere skal droppe støtte forum TLS 1.0 og “migrere til et minimum af TLS 1.1, fortrinsvis TLS 1.2. ” HIPAA tillader teknisk brug af alle versioner af TLS. Således det minimum, der ofte understøttes TLS version er 1.1; dog foreslår PCI-DSS og NIST kraftigt brugen af ​​de mere sikre TLS 1.2 (og som set ovenfor anbefaler NIST vedtagelse af TLS 1.3 og planlægger at kræve støtte inden 2024).

Cipher-suiter

TLS 1.2 og tidligere

SP 800-52r2 specificerer en række acceptable krypteringssuiter til TLS 1.2 og tidligere. Standarden kræver ikke understøttelse af bestemte chifferpakker, men giver vejledning i valg af stærkere:

1. Foretrækker kortvarige taster frem for statiske nøgler (dvs. foretrækker DHE frem for DH og foretrækker ECDHE frem for ECDH). Flygtige nøgler giver perfekt hemmeligholdelse fremad.
2. Foretrækker GCM eller CCM tilstande frem for CBC tilstand. Brugen af ​​en godkendt krypteringstilstand forhindrer flere angreb (se afsnit 3.3.2 [i SP 800-52r2] for at få flere oplysninger). Bemærk, at disse ikke er tilgængelige i versioner før TLS 1.2.
3. Foretrækker CCM frem for CCM_8. Sidstnævnte indeholder et kortere godkendelsesmærke, som giver en lavere godkendelsesstyrke.

Desuden, selv om disse er de tilladt chiffer suiter, hvis din TLS server beskæftiger sig ikke med en lang række forskellige platforme og klienter, det anbefales, at kun en lille undergruppe af disse algoritmer bruges. Tilladelse af flere chiffer-suiter kan kun udvide angrebsoverfladen til din server, hvis (eller når) en ny protokolsårbarhed opdages.

TLS 1.3

TLS 1.3 har en meget kortere liste over chifferpakker:

• TLS_AES_128_GCM_SHA256 (0x13, 0x01)
• TLS_AES_256_GCM_SHA384 (0x13, 0x02)
• TLS_AES_128_CCM_SHA256 (0x13, 0x04)
• TLS_AES_128_CCM_8_SHA256 (0x13, 0x05)

Konklusion

Vi håber, at denne korte guide hjælper dig med at forstå mere om TLS, og hjælpe dig, når du konfigurerer TLS på din egen server. Med hensyn til de standarder og anbefalinger, vi har diskuteret, indeholder følgende afsnit et eksempel på en konfiguration, som du skal kunne anvende på de mest populære webserverløsninger. Hvis du har spørgsmål om, hvordan du opretholder din online overholdelse, er du velkommen til at kontakte os via e-mail Support@SSL.com eller klikke på live chat-knappen nederst på denne skærm.

Tillæg: Eksempel TLS konfigurationer

Ved at indsamle reglerne, der er anført i de tre specifikationsdokumenter, bør en moderne sikker server implementere TLS 1.2 og / eller TLS 1.3, med en kort, men forskelligartet liste over udvalgte krypteringssuiter. Som en hurtig reference vises eksempelkonfigurationer for de mest populære webservere på markedet nedenfor. Disse er "mellemliggende" (generelle) konfigurationer genereret med Mozillas SSL-konfigurationsgenerator:

... SSLProtocol alle -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-RSA-AES256-GCM-SHA384D: ECDH POLY20: ECDHE-RSA-CHACHA1305-POLY20: DHE-RSA-AES1305-GCM-SHA128: DHE-RSA-AES256-GCM-SHA256 SSLHonorCipherBestil fra SSLSessionBilletter fra

... ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

... ssl.openssl.ssl-conf-cmd = ("Protokol" => "ALLE, -SSLv2, -SSLv3, -TLSv1, -TLSv1.1 ") ssl.cipher-list =" ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-RSA-AES256-GCM- SHA384: ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-RSA-CHACHA20-POLY1305: DHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-GCM-SHA384 "ssl.honor-cipher-order ="

...

ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
ssl-default-bind-options prefer-client-ciphers no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets

ssl-default-server-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
ssl-default-server-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets

... Politikker: - PolicyName: Mozilla-intermediate-v5-0 PolicyType: SSLNegotiationPolicyType Attributter: - Navn: Protocol-TLSv1.2 Værdi: sand - Navn: Server-Defined-Cipher-Order Value: false - Navn: ECDHE-ECDSA-AES128-GCM-SHA256 Værdi: true - Navn: ECDHE-RSA-AES128-GCM-SHA256 Værdi: true - Navn: ECDHE-ECDSA-AES256-GCM-SHA384 Værdi: true - Navn: ECDHE-RSA-AES256-GCM-SHA384 Værdi: true - Navn: DHE-RSA-AES128-GCM-SHA256 Værdi: true - Navn: DHE-RSA -AES256-GCM-SHA384 Værdi: sand