Guide till TLS Standards Compliance

Transportlagerens säkerhet (TLS) är det främsta sättet att skydda nätverkskommunikation över Internet. Den här artikeln är en kort guide som hjälper dig att konfigurera en säker server för att möta aktuell TLS standarder.

Beskrivning

Smakämnen Transportlager säkerhet (TLS) protokollet är det primära sättet att skydda nätverkskommunikation över Internet. Det (och dess föregångare, Secure Sockets Layer eller SSL) har använts i årtionden i många applikationer, men framför allt i webbläsare när de besöker HTTPS webbplatser. TLS fungerar vanligtvis tyst i bakgrunden, men i motsats till vad man kan tänka, TLS är inte en svart låda som bara fungerar. Snarare säkerheten TLS ger upphov till från samarbete mellan olika kryptografiska algoritmer. Dessutom, TLS, precis som SSL innan det, utvecklas ständigt med säkerhetsindustrin - ny teknik och affärskrav måste uppfyllas, medan de senaste säkerhetshoten måste mildras. Algoritmer kan bli föråldrade med tiden, eller metoder kan överges, med varje förändring som påverkar den övergripande säkerheten för a TLS instans (som den som skyddar din anslutning just nu).

Denna volatilitet har motiverat olika standardorganisationer att publicera riktlinjedokument, så att en lägsta baslinje för TLS säkerhet kan etableras på en viss marknad, sektor eller tjänst. Tyvärr finns det många sådana standarder, med olika sektorer som kräver överensstämmelse med olika tillämpliga dokument, medan standarderna själva också utvecklas över tid och tillgodoser förändringar i den sektor de utformades för att skydda.

Förståeligtvis, navigera genom detta hav av standarder för att skapa en modern TLS instans kan vara en riktig huvudvärk för administratörer. Den här artikeln är en kort guide som hjälper dig att konfigurera en säker server för att möta förväntat TLS standarder 2021. (För ytterligare hjälp har vi också gett exempel på konfigurationer av de mest populära webbserverlösningarna i bilaga.)

Standarderna

Det finns flera enheter som upprätthåller riktlinjer för TLS med avseende på nätverkssäkerhet, såsom United States Department of Health and Human Services (HHS) eller National Institute of Standards and Technology (NIST). För korthetens skull kommer denna artikel endast att studera de tre mest antagna dokumenten:

1. Smakämnen Sjukförsäkringsportabilitet och ansvarsskyldighet (HIPAA)
2. NIST: s Riktlinjer för SP 800-52r2
3. Smakämnen Standard för säkerhet för betalningskortsindustri (PCI-DSS)

HIPAA

HIPAA är en förordning som antogs av den amerikanska regeringen 1996 om säker hantering av Skyddad hälsoinformation (PHI). PHI avser all digital patientinformation, såsom testresultat eller diagnoser. En HIPAA vägledande dokument som publicerades 2013 anges följande:

Giltiga krypteringsprocesser för data i rörelse är de som, i förekommande fall, överensstämmer med NIST Special Publications 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementeringar; 800-77, guide till IPsec VPN: er; eller 800-113, Guide till SSL VPN eller andra som är Federal Information Processing Standards (FIPS) 140-2 validerade.

NIST-standarder

2005 publicerade NIST Special Public (SP) 800-52 och beskrev de korrekta operationella procedurerna för att säkert konfigurera en TLS exempel för statliga servrar. SP 800-52 har sedan dess ersatts av versionerna SP 800-52r1 (2014) och SP 80052r2 (2019). Den här artikeln följer riktlinjerna i SP 800-52r2, som för närvarande är stabil.

PCI DSS

PCI-DSS är en efterlevnadsstandard som upprätthålls av Payment Card Industry (PCI) Standards Security Council (SSC) som fastställer hur betalnings- och kortinformation hanteras av e-handelswebbplatser. Beträffande korrekt konfiguration av TLS fall, PCI-DSS anger:

"Se branschstandarder och bästa praxis för information om stark kryptografi och säkra protokoll (t.ex. NIST SP 800-52 och SP 800-57, OWASP, etc.)"

TLS standarder: att sätta ihop allt

Det bör noteras nu att varje standard påverkar olika system, baserat på deras funktion och de data de hanterar. Till exempel kan en e-postserver på sjukhus falla under HIPAA-riktlinjer eftersom utbytta meddelanden kan innehålla patientinformation, medan sjukhusets CRM-system kan falla under PCI-DSS eftersom det kan innehålla kreditkorts- och annan kundinformation. Att följa alla tre standarderna skulle kräva användning av gemensamt TLS parametrar som finns i alla dokument.

Lyckligtvis är det uppenbart att alla standarder följer NIST: s riktlinjer för val av TLS parametrar. Detta innebär att när detta skrivande är kompatibelt med SP 800-52r2, bör en server också vara kompatibel med HIPAA och PCI-DSS. (Okej, det är det inte exakt sant, men saker kommer att bli tydligare i nästa avsnitt.)

konfigurerbar TLS parametrar

Nivån av säkerhet som TLS ger påverkas mest av protokollversion (dvs. 1.0, 1.1, etc.) och tillåtna chiffer-sviter. Chiprar är algoritmer som utför kryptering och dekryptering. Emellertid a chiffer-svit är en uppsättning algoritmer, inklusive en chiffer, en nyckelutbytesalgoritm och en hashningsalgoritm, som används tillsammans för att upprätta en säker TLS förbindelse. Mest TLS klienter och servrar stöder flera alternativ, så de måste förhandla när de skapar en säker anslutning för att välja en gemensam TLS version och chiffer-svit.

TLS protokollversion

Beträffande TLS versionstöd, NIST SP 800-52r2 anger följande:

Servrar som stöder applikationer som endast är statliga skall konfigureras för användning TLS 1.2 och skall konfigureras för användning TLS 1.3 också. Dessa servrar borde inte konfigureras för användning TLS 1.1 och skall inte användning TLS 1.0, SSL 3.0 eller SSL 2.0.

.

Servrar som stöder medborgar- eller affärsinriktade applikationer (dvs. klienten kanske inte ingår i ett statligt IT-system) skall konfigureras för att förhandla TLS 1.2 och skall konfigureras för att förhandla TLS 1.3. Användningen av TLS version 1.1 och 1.0 är vanligtvis avskräckt, men dessa versioner kan konfigureras vid behov för att möjliggöra interaktion med medborgare och företag ... Dessa servrar skall inte tillåta användning av SSL 2.0 eller SSL 3.0.

Myndigheter skall stödja TLS 1.3 senast den 1 januari 2024. Efter detta datum, servrar skall stödja TLS 1.3 för både statliga applikationer och applikationer som riktar sig till medborgare eller företag I allmänhet servrar som stöder TLS 1.3 skall konfigureras för användning TLS 1.2 också. I alla fall, TLS 1.2 kan inaktiveras på servrar som stöder TLS 1.3 om det har fastställts att TLS 1.2 behövs inte för driftskompatibilitet.

Medan TLS 1.0 är förbjudet och TLS 1.1 avskrivs för statliga webbplatser, i NIST-riktlinjerna anges att för kompatibilitet med tredje parts tjänster, regeringsstyrda servrar Maj genomföra TLS 1.0 och 1.1 vid behov. Under PCI-DSS 3.2.1 (den nuvarande versionen), kompatibla servrar måste släppa stöd för TLS 1.0 och “migrera till ett minimum av TLS 1.1, företrädesvis TLS 1.2. ” HIPAA tillåter tekniskt att alla versioner av TLS. Således det minsta vanliga stödet TLS version är 1.1; dock föreslår PCI-DSS och NIST starkt att det säkrare används TLS 1.2 (och, som sett ovan, rekommenderar NIST antagande av TLS 1.3 och planerar att kräva stöd till 2024).

Cipher sviter

TLS 1.2 och tidigare

SP 800-52r2 specificerar en mängd acceptabla chiffersviter för TLS 1.2 och tidigare. Standarden kräver inte stöd för några specifika krypteringssviter, men ger vägledning för att välja starkare:

1. Föredra kortvariga nycklar framför statiska nycklar (dvs föredra DHE framför DH och föredra ECDHE framför ECDH). Kortvariga nycklar ger perfekt sekretess framåt.
2. Föredra GCM- eller CCM-lägen framför CBC-läget. Användningen av ett autentiserat krypteringsläge förhindrar flera attacker (se avsnitt 3.3.2 [i SP 800-52r2] för mer information). Observera att dessa inte finns i versioner före TLS 1.2.
3. Föredra CCM framför CCM_8. Den senare innehåller en kortare autentiseringstagg, som ger en lägre autentiseringsstyrka.

Dessutom, även om dessa är de tillåten chiffer sviter, om din TLS server hanterar inte stora variationer av olika plattformar och klienter, det rekommenderas att endast en liten delmängd av dessa algoritmer används. Att tillåta fler chiffersviter kan bara bredda attackytan till din server om (eller när) ett nytt protokollsårbarhet upptäcks.

TLS 1.3

TLS 1.3 har en mycket kortare lista över chiffersviter:

• 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)

Slutsats

Vi hoppas att den här korta guiden hjälper dig att förstå mer om TLS, och hjälper dig när du konfigurerar TLS på din egen server. När det gäller de standarder och rekommendationer som vi har diskuterat innehåller följande avsnitt ett exempel på en konfiguration som du bör kunna använda på de mest populära webbserverlösningarna. Om du har några frågor om hur du kan upprätthålla din online-överensstämmelse, kontakta oss gärna via e-post Support@SSL.com eller klicka på livechattknappen längst ner på den här skärmen.

Bilaga: Exempel TLS konfigurationer

Genom att samla reglerna som anges i de tre specifikationsdokumenten bör en modern säker server implementera TLS 1.2 och / eller TLS 1.3, med en kort men mångsidig lista över utvalda krypteringssviter. Som en snabb referens visas exempelkonfigurationer för de mest populära webbservrarna på marknaden nedan. Dessa är ”mellanliggande” (allmänna) konfigurationer som genereras med Mozillas SSL-konfigurationsgenerator:

... SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-RSA-AES256-GCM-SHA384: ECDH POLY20: ECDHE-RSA-CHACHA1305-POLY20: DHE-RSA-AES1305-GCM-SHA128: DHE-RSA-AES256-GCM-SHA256 SSLHonorCipherBeställ av SSLSessionBiljetter av

... ssl_protokoll 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 = ("Protocol" => "ALL, -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 nej-tlsv11 nej-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-standard-server-alternativ no-sslv3 no-tlsv10 nej-tlsv11 nej-tls-biljetter

... Policy: - PolicyName: Mozilla-intermediate-v5-0 PolicyType: SSLNegotiationPolicyType Attribut: - Namn: Protocol-TLSv1.2 Värde: true - Namn: Server-Defined-Cipher-Order Value: false - Namn: ECDHE-ECDSA-AES128-GCM-SHA256 Värde: true - Namn: ECDHE-RSA-AES128-GCM-SHA256 Värde: true - Namn: ECDHE-ECDSA-AES256-GCM-SHA384 Värde: true - Namn: ECDHE-RSA-AES256-GCM-SHA384 Värde: true - Namn: DHE-RSA-AES128-GCM-SHA256 Värde: true - Namn: DHE-RSA -AES256-GCM-SHA384 Värde: sant