Att använda SSL eller ej
I min senaste krönika i ComputerSweden - "säkerhetsfrågan" så besvaras frågan "Jag tänkte sätta upp en ny webbserver och funderar på att använda SSL. Finns det något jag bör tänka på? Prestanda är en sak som oroar mig.".
Problemet med den typen av skrivelser i kolumnformat i en papperstidning är att man har max 3000 nedslag för att uttrycka sig, något som alltid känns lite väl klaustrofobiskt och för lite. Saker redigeras bort när man trimmar sin text, tankar poppar upp och läggs på hög någonstans i bakhuvudet "jag lägger till det om en stund", etc. Det finns helt enkelt mer man vill ha sagt än det finns textspalt. Så här kommer lite tillägg som kan vara av intresse om man läst originalinlägget i CS 2011-06-17
Till att börja med så kan det vara bra att ge lite pekare till bakgrundsinformation, såsom specifikationen till senaste versionen av SSL (TLS) protokollet, version 1.2. Det kan också vara på sin plats att påminna att inga säkerhetsmekanismer är felfria eller inte går att angripa eller manipulera. Man kan ju också klanta sig kungligt också och exponera sin känsliga privata nyckel också.....
Kommentarer som kunde funnits i artikeln härrör givetvis till kryptoegenskaper såsom nyckellängder och val av algoritmer. De klassiska avvägningarna gäller givetvis även i det här sammanhanget - desto längre nyckellängd, desto mer CPU-kraft. En annan sak som måste påpekas är skillnaden mellan symmetriska och asymmetriska krypteringsalgoritmer, där den sistnämnda används återhållsamt och enbart för att föra över en sessionsnyckel till det symmetriska kryptot.
En sak kan sägas direkt: symmetriska algoritmer såsom RC4 och DES med nyckellängder på 40-bitar (RC4) eller 56-bitar (DES) skall absolut undvikas. De erbjuder inte det skydd man behöver mot kryptoanalys som nyttjar modern hårdvara. 40-bitarsnycklarna är en nedskalad exportvariant av RC4 64-bitarskryptonycklar som togs fram och nyttjades under 1990-talet då export av krypteringsteknologi var likställt med krigsmaterielexport. 64-bitars nyckellängd kan också, rent allmänt anses erbjuda för dåligt skydd.
Vilken krypteringsalgoritm anväds då i SSL? Svaret är - det beror på. Det sker en initial förhandling mellan servern och klienten (såkallad handskakning) där man bestämmer vilken kryptosvit - vilket är en kombination av asymmetriskt, symmetriskt och signaturalgoritm samt vilken nyckellängd som skall användas.
Exempel på kryptosviter inkluderar:
TLS_RSA_WITH_AES_256_CBC_SHA256 - RSA-baserad nyckelutbyte med 256-bitars AES-kryptering och SHA256 som signeringsalgoritm TLS_RSA_WITH_RC4_128_MD5 - RSA-baserat nyckelutbyte med 128-bitars RC4 symmetriskt bulkkrypto och MD5 som signeringsalgoritm TLS_RSA_WITH_NULL_MD5 - Null-krypto där data skickas i klartext.
Ett sätt att filosofera runt detta ämne är att titta på vad som är i spridd användning idag. Electronic Frontier Foundation, EFF, skapade projektet "SSL Observatory" där de scannade hela adressrymden för IPv4 efter HTTPS-aktiverade webbservrar pÅ port 443/TCP. Resultatet sparades i en gigantisk databas, vilken man kan kolla vissa värden och certifikategenskaper mot.
En intressant fråga är att se vilken är den vanligaste signeringsalgoritmen som används. En SQL-sökning i EFF-databasen ger snabbt lite fakta. Se tabellen nedan
+--------------------------+----------+
| Signature Algorithm | count(*) |
+--------------------------+----------+
| sha512WithRSAEncryption | 1 |
| sha1WithRSA | 1 |
| md2WithRSAEncryption | 4 |
| sha256WithRSAEncryption | 62 |
| md5WithRSAEncryption | 29958 |
| sha1WithRSAEncryption | 1503333 |
+--------------------------+----------+
Motsvarande sökning i EFF's databas över de förekommande nyckellängderna för asymmetriska kryptot RSA ger nedanstående intressanta fördelning:
+------------------+----------+ | RSA_Modulus_Bits | count(*) | +------------------+----------+ | NULL | 25 | | 511 | 3 | | 512 | 4165 | | 730 | 1 | | 767 | 1 | | 768 | 38 | | 1023 | 977 | | 1024 | 869402 | | 1025 | 14 | | 1026 | 1 | | 1027 | 2 | | 1028 | 10 | | 1032 | 1 | | 1034 | 7 | | 1042 | 2 | | 1048 | 14 | | 1080 | 1 | | 1152 | 1 | | 1204 | 5 | | 1212 | 9 | | 1234 | 8 | | 1280 | 11 | | 1369 | 4 | | 1536 | 144 | | 1538 | 1 | | 1543 | 1 | | 1548 | 1 | | 1800 | 7 | | 1825 | 1 | | 1924 | 3 | | 2009 | 1 | | 2010 | 1 | | 2014 | 1 | | 2023 | 1 | | 2024 | 22 | | 2025 | 1 | | 2028 | 4 | | 2038 | 3 | | 2040 | 8 | | 2043 | 1 | | 2045 | 2 | | 2046 | 5 | | 2047 | 145 | | 2048 | 564514 | | 2049 | 5 | | 2052 | 1 | | 2056 | 11 | | 2058 | 5 | | 2066 | 1 | | 2080 | 2 | | 2084 | 9 | | 2096 | 2 | | 2176 | 1 | | 2345 | 1 | | 2408 | 1 | | 2560 | 1 | | 3000 | 3 | | 3048 | 11 | | 3071 | 1 | | 3072 | 119 | | 3333 | 1 | | 3584 | 3 | | 3889 | 1 | | 4000 | 2 | | 4028 | 1 | | 4069 | 18 | | 4092 | 2 | | 4096 | 15574 | | 4192 | 1 | | 4196 | 2 | | 5120 | 2 | | 6095 | 2 | | 8192 | 38 | | 16384 | 1 | +------------------+----------+
Där man lätt ser att 1024 bitars RSA-nyckel är överlägset vanligast (~60%), följt av 2048-bitars (~39%) och sedan 4092-bitars (~1%).
EFF-databasen ger underlag till vad som används idag, men det man vill veta om man står i begrepp att skaffa SSL/TLS till sin webb vill man ju snarareveta vad som är bra imorgon och dagen därpå. På Som ett exempel har vi på ROMAB har vi använtt oss av ett 4096-bitars RSA certifikat.
512-bitars RSA-nycklar erbjuder sedan länge ett alltför dåligt skydd och skall inte användas.
Ett annat sätt att fundera över nyckellängder är att se vilka som kravställs i olika sammanhang. Exempelvis kan krav på SSL/TLS-version vara ställt om man hanterar kontokortsinformation, och att inte svaga kryptonyckellängder används.
EV-certifikat som rivs av ganska snabbt och enkelt i texten kan man motivera lite bättre - EV = Extended Validation, en de facto standard baserad på krav ställda mot certifikatutfärdarna, som beskriver på policynivå vilka krav som ställs vid singering av någons certifikat. EV-cert kan för vissa typer av webbplatser vara nägot som påvisar en högre grad av seriösitet hos webbplatsinnehavaren, då denne ansträngt sig extra för att på Internet kunna bevisa sin identitet.
Bilden nedan visar ett vanligt URL-fält från webbläsaren Firefox när SSL används. I vänstra delen av fältet visas domännamnet utskrivet på blå bakgrund.
Bilden nedan visar ett URL-fält från webbläsaren Firefox när s.k. EV-certifikat för skapande av SSL används. I vänstra delen av fältet visas företagsnamnet utskrivet på grön bakgrund istället för domännamnet.
En annan sak att tänka på är vad man sätter för namn på certifikatet, vilket "common name" som används, samt om man vill använda några "alternative names". Common name är ofta www.domän.se. En bra ide kan vara att sätta alternative name till att vara domän.se, sä att SSL fungerar för bägge varianterna, speciellt om ens webbserver faktist servar sidor om man ansluter med http://domän.se (och sedemera även skall fungera för httpS-varianten).
Artikeltexten om HSTS - http strict transport security känns också lite väl kort för min smak. Moderna browsers (i detta sammahang: Chrome, Firefox4) och vissa tillägg (noscript för firefox äldre än 4) har stöd för HSTS - vilket i dessa sammahang innebär att de tolkar rätt http-header och sparar state om HTTPS-tillgänglighet mellan besöken.
Men den mer relevanta och mer intressanta delen av HSTS-hanteringen sker på serversidan. Servern måste skicka en http-svarsheader enligt formen
Strict-Transport-Security: max-age=15768000 ; includeSubDomains
som sedan tolkas av webbläsaren. Efter kolon-tecknet anges hur länge som webbläsaren skall komma ihäg att äteransluta via HTTPS, samt i detta exempel att även alla subdomäner (inte bara www.romab.com, utan sånt som www.labb.romab.com) skall också omfattas av regeln av att enbart ansluta via HTTPS.
Wikipediasidan om HSTS har mycket information om hur man får HSTS aktiverat i en mängd olika webbservrar, eller hur man skriver egen programkod php, javascript, mm som sätter http-svarskodsfälten.
Prestandadiskussionen blev också onödigt kort. Min kollega Andreas har gjort ett antal lysande prestandatester av vanliga webbservrar med olika uppmättningar av SSL som han presenterade i ett par tidigare bloggposter - och på konferensen optimera Stockholm. De bloggartiklarna (bloggpost #1 och bloggpost #2) förtjänar att puffas på lite extra i dessa sammahang.
Med väl webbservern uppe och snurrande med ett x.509-certifikat och SSL aktiverat, så är ett avslutande tips att använda Ivan Ristic:s utsökta on-linetest som finns tillgängligt från SSLlabs för att se hur väl ens SSL-kapabla webbserver är uppsatt.
----
Written by Robban @ 2011-06-18