Cipher Suites. Rekommendationer om transportkryptering i e-tjänster

Transkript

1 Cipher Suites Rekommendationer om transportkryptering i e-tjänster

2 Innehåll 1. Bakgrund och syfte Revisionshistorik Inledning Cipher suites Protokoll för transportkryptering Övriga parametrar Key Exchange/Authentication Algorithm Nyckellängd (Perfect) Forward Secrecy Encryption Algorithm Message Authentication Code Kända attacker BEAST CRIME/TIME BREACH Lucky Secure Resumption Rekommenderade inställningar Allmänt Cipher Suites Prioriteringsordning för PFS Konfiguration av webbservrar Apache Internet Information Services Referenslista... 9 Sid 1/10

3 1. Bakgrund och syfte Detta dokument är en bilaga till dokumentet Anvisningar e-tjänster [R1] och behandlar tekniska detaljer kring konfigurationen av SSL/TLS-kryptering av kommunikationen mot e- tjänster. Syftet är att beskriva de säkerhetsproblem som kan uppstå genom bristfällig konfiguration av cipher suites, samt Ineras rekommendationer kring dessa inställningar. En gemensam syn på dessa frågor, samt kompatibla inställningar är också en förutsättning för en säker och väl fungerande SSO-miljö. Målgruppen för detta dokument är utvecklings- och förvaltningsteam för e-tjänster inom Inera. 2. Revisionshistorik Revisionshistorik Version Författare Kommentar 0.1 Conny Balazs Grundläggande information. 0.2 Christoffer Johansson Sammanställning och struktur 0.3 Mattias Nordvall Flyttat till Inera-mall. 0.4 Björn Skeppner Smärre justeringar 1.0 Björn Skeppner Uppdaterad 3. Inledning När man väljer att använda transportkryptering för sin e-tjänst finns det vissa saker man bör tänka på. Detta dokument syftar till att ge vissa rekommendationer på området, men respektive tjänst måste ansvara för att inventera behoven/möjligheterna i kundbas och göra ett val som både är säkert och användarvänligt. Målet är att få bort vissa av de mer osäkra kombinationerna av transportkryptering som finns. 3.1 Cipher suites Ett begrepp man bör känna till när man jobbar med transportkryptering är Cipher Suite(s). Detta är ett samlingsbegrepp för de komponenter som ingår när en krypterad session förhandlas inom SSL/TLS. En cipher suite består av följande delkomponenter, där våra rekommendationer (baserade på säkerhet och stöd för SITHS-certifikat) är fetmarkerade: Key Exchange Algorithm - RSA/DH/DHE/ECDHE/ECDH/SRP/PSK Authentication Algorithm - RSA/DSA/ECDSA Sid 2/10

4 Encryption Algorithm - RC4, Triple DES, AES (AES128-CBC el. GCM, AES256- CBC el. GCM), IDEA, DES, Camellia etc. Message Authentication Code (MAC) - SHA-1, SHA-2, MD5 I praktiken fungerar valet av vilken cipher suite som ska användas så här: 1. Klienten skickar en lista över vilka den har stöd för i prioriteringsordning 2. Servern väljer en av dessa, alternativt nekar anslutningen. Rekommendationen för att öka säkerheten är således att man begränsar servern till att bara tillåta ett visst urval av cipher suites för att undvika klienter inte har stöd för eller som vill göra en förhandling som innebär dålig säkerhet. 4. Protokoll för transportkryptering Utöver cipher suites behöver man också välja vilket/vilka protokoll för transportkryptering som e-tjänsten ska stödja. Valet av protokoll påverkar också vilka cipher suites som stöds. Av nedan protokoll rekommenderar vi att TLS 1.0/1.1/1.2 aktiveras om man inte har kontroll på sin klientmiljö. Kan man ställa krav på klienterna är rekommendationen alltid att stänga av så många äldre protokoll som möjligt. SSL 2.0 Rekommenderas INTE, då den har säkerhetsbrister som inte kan åtgärdas genom val av cipher suite och fixar på klienter. SSL 3.0 Rekommenderas INTE, men kan behöva aktiveras i enstaka fall. Vid användning var extra noga att till att klienter och server är patchade mot kända attackar och svagheter. Inte jättestor skillnad mot TLS 1.0. TLS 1.0 Bör aktiveras för att bibehålla nativestöd (behöver inaktiveras på klienten) med äldre klienter, se bild 1 TLS 1.1 Ger egentligen mest utökat nativestöd för lite äldre versioner av Safari och Chrome samt de senaste versionerna av alla webbläsare. Kräver manuellt aktivering på många andra operativsystem/browser, se bild 1 TLS 1.2 Bara nativestöd i de senaste versionerna av alla webbläsare, kan manuellt aktiveras på vissa äldre OS/Webbläsare, se bild 1 Sid 3/10

5 Bild 1 OS/Browser stöd för olika krypteringsprotokoll, källa: 5. Övriga parametrar 5.1 Key Exchange/Authentication Algorithm Eftersom SITHS-certifikat i sig bara använder RSA i sina publika nycklar är vi vid användning av dessa begränsade till att använda algoritmer som stödjer publika RSA nycklar i själva autentiseringssteget. De kombinationer av algoritmer med detta stöd listas nedan i rekommenderad prioriteringsordning: Sid 4/10

6 ECDHE-RSA, DHE-RSA, RSA Övriga alternativ listas nedan men ställer vissa krav på servercertifikatet som inte kan uppfyllas av ett SITHS-certifikat i dagsläget ECDHE-ECDSA, ECDH-ECDSA, DHE-DSS, DH-DSS 5.2 Nyckellängd Om man väljer en algoritm som använder certifikat baserade på RSA (Det som SITHS stödjer) är i dagsläget rekommendationen att man använder minsta asymmetriska nyckelstorlek enligt: RSA 2048 bits Använder man certifikat med nycklar som byggs med hjälp av elliptiska kurvor är rekommendationen att man väljer en minsta asymmetrisk nyckelstorlek. ECC 224 bits 5.3 (Perfect) Forward Secrecy Valet av Key Exchange algoritm påverkar även möjligheten att ha stöd för något som kallas för Forward Secrecy eller Perfect Forward Secrecy (PFS). Enkelt beskrivet så är fördelen med denna funktionalite att varje meddelande mellan server och klient krypteras med egna unika nycklar som är oberoende av servern och klientens primära certifikat och privata nycklar. Rent säkerhetsmässigt innebär detta att även om en attackerare sitter och sparar sessioner under 1 år och så småningom kommer över serverns privata nycklar, så kommer dessa sessioner inte kunna avkrypteras med hjälp av dessa privata nycklar. De algoritmer som stöder PFS är de som använder så kalla ephemerala (kortlivade) Diffie- Hellman nycklar. För SITHS räkning innebär detta ECDHE-RSA, DHE-RSA För vissa andra certifikat kan nämnas: ECDHE-ECDSA, DHE-DSS Nackdelar PFS skyddar inte mot metoder som försöker avkryptera meddelanden utan nyckeln. Dessutom ställer PFS något högre krav på systemresurser hos klient/server, något som dock bör vara försumbart på nyare system. Sid 5/10

7 5.4 Encryption Algorithm Valet av krypteringsalgoritm eller chiffer påverkar till stor del säkerheten i vald cipher suite om man använder ett äldre protokoll. Vi rekommenderar att man använder någon av de symmetriska algoritmerna: AES256, AES128 tillsammans med antingen CBC eller GCM där GCM är att föredra men ställer vissa prestandakrav på både klient och server, samt att den även kräver att man använder TLS Message Authentication Code Används för att skapa en checksumma som indikerar om meddelandet levererats intakt och alltså inte ha manipulerats på vägen från sändare till mottagare. De vanligaste inom kryptografi är MD5 eller SHA och rekommendationen är att man använder SHA eftersom MD5 är komprometterad. SHA är en grupp av HASH algoritmer (SHA-1,SHA-2,SHA-3) som ofta anges med ett tillägg om hur många bitar som används per skapad hash. Ex. SHA-512 som egentligen ingår i SHA-2. Generellt gäller att ju nyare grupp av SHA och ju större antal bitar som används desto säkrare. Dock ökar också prestandakraven på de enheter som ska utföra beräkningar därefter. 6. Kända attacker Några nämnvärda attacker som utnyttjar bristfälliga krypteringsinställningar beskrivs kortfattat nedan med reservation för eventuella felskrivningar. 6.1 BEAST BEAST-attacker är ett hot om man använder TLS 1.0 eller tidigare tillsammans med ett CBC chiffer. Åtgärder har släppts på klientsidan för de TLS-bibliotek som används inom de största Operativsystem/Webbläsare så länge man ser till att hålla klienterna uppdaterade. Enn övergång till nyare version av TLS-protokollet att rekommendera. 6.2 CRIME/TIME CRIME/TIME-attacker utnyttjar svagheter i komprimering av trafik en funktionalitet som används för att förbättra prestanda. Drabbar flera protokoll (SPDY, HTTP), men även TLS. Den säkraste åtgärden är att inaktivera TLS-komprimering serverside, vilket också är vår rekommendation. I övrigt ska flera TLS-biliotek vara patchade för att inte acceptera TLSkompression. Sid 6/10

8 6.3 BREACH BREACH-attacker utnyttjar en liknande teknik som CRIME men som fokuserar på HTTPkomprimering istället. Alla OS/Webbläsare/Servrar är sårbara oavsett vilken cipher suite/tlsbibliotek eller protokollversion som används. Åtgärder är antingen att avaktivera HTTPkomprimering, vilket har negativa effekter på prestanda. Eller att vidta åtgärder för att detektera och hantera Cross Site Request Forgery (CSRF) där man lurar användaren att göra en åtgärd på den sida som den besöker för tillfället, men som egentligen initierar en process på en annan komprometterad sida. 6.4 Lucky13 Lucky13-attacker är en attackmetod som är ifrågasatt gällande dess effektivitet och som baserar sig på att man gör en attack mot MAC-kontrollen i de cipher suites som använder ett CBCchiffer. Attacken förutsätter att attackeraren sitter som en Man in the Middle och kan lyssna på trafik mellan klient och server. Attacken går snabbare ju lägre version av SHA som används. Åtgärder för att förhindra denna är kort att använda uppdaterade versioner av de TLS-bibliotek som används, det vill säga att se till att hålla klienter och servrar uppdaterade, eller att gå över till GCM-chiffer och således TLS Secure Resumption Secure Resumption är den senaste i raden attacker det bästa kortsiktiga skyddet är att se till att uppdatera till senaste versionerna av det TLS-bibliotek som används, dvs. hålla systemen uppdaterad. Dock är det mest täckande åtgärden en rättning i TLS-protokollet som sådant. 7. Rekommenderade inställningar 7.1 Allmänt Avaktivera Client-Initiated Renegotiation Avaktivera TLS-kompression - mot CRIME och TIME-attacker Avaktivera HTTP-kompression eller vidta åtgärder mot CSRF - om man ska vara helt säker från BREACH-attack Avaktivera cachning av HTTP-respons som innehåller känslig info Undvik att tillåta mixed-content på en webbsida. Det vill säga att man försöker köra hela sessionen över TLS när man använder TLS och blandar inte krypterad och okrypterad dataaktivera HTTP Strict Transport Security Aktivera forward secrecy (PFS) då ECDHE och DHE används vid förhandling av sessionsnycklar. Sker automatiskt på de flesta webbservrar vid rätt val av cipher suite. Sid 7/10

9 Använd alltid senaste versionen av OS/Servermjukvarans TLS-bibliotek. TLS_FALLBACK_SCSV bör aktiveras för att säkerställa att ingen omförhandling av kommunikationen till lägre cipher protokollversioner Maximal TLS-sessionslängd utan omförhandling är 24h Maximal inaktiv TLS-sessionslängd är 30 minuter HCC Funktion utfärdad av SITHS type 3 CA V1 ska föredras framför funktion utfärdad av SITHS type 2 CA V1 7.2 Cipher Suites Rekommenderade cipher suites i prioriteringsordning som de ska föredras av servrar: Stöds bara i TLS TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 6. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 7. TLS_DHE_RSA_WITH_AES_256_GCM_SHA TLS_DHE_RSA_WITH_AES_128_GCM_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA 12. TLS_DHE_RSA_WITH_AES_128_CBC_SHA Stöds itls 1.0 och senare 13. TLS_RSA_WITH_AES_256_GCM_SHA TLS_RSA_WITH_AES_128_GCM_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA 18. TLS_RSA_WITH_AES_128_CBC_SHA 7.3 Prioriteringsordning för PFS Om man använder en Key Exchange Algoritm som stödjer PFS finns det också ett antal standarder för nyckellängden gällande nycklarna för dessa. Dessa brukar anges som tillägg bakom vald cipher suite och baseras på nyckellängden som används i Diffie-Hellman handskakningen inom själva TLS-sessionen. De gällande rekommendationerna är att man använder dem enligt följande i prioriteringsordning: 1. Cipher_Suite_P Cipher_Suite_P Cipher_Suite_P256 Sid 8/10

10 8. Konfiguration av webbservrar Här följer några exempel på hur cipher suites konfigureras i de vanligaste webbservrarna. Observera att de parametervärden som anges endast ska ses som exempel. 8.1 Apache Cipher suites i Apache konfigureras i httpd.conf: Exempel: SSLProtocol -ALL +SSLv3 +TLSv1 SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXPORT:!MD5 SSLCompression off 8.2 Internet Information Services Cipher suites i Microsoft IIS konfigureras via Windows-registret. Observera att inställningarna påverkar all mjukvara som använder Microsofts inbyggda SSL-implementation: Exempel: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\ SCHANNEL\Protocols\SSL 2.0\Server DWORD = 0 HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\ SCHANNEL\Protocols\SSL 3.0\Server DWORD = 1 HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\ SCHANNEL\Protocols\TLS 1.0\Server DWORD = 1 9. Referenslista Ref Dokumentnamn Dokument R1 Anvisningar e-tjänster akerhetstjanster/anvisningar_single_sign_on/anvisningar_ e_tjanster_v_2_1.pdf Sid 9/10