SSL. Kristoffer Silverhav Robin Silverhav

Transkript

1 SSL Kristoffer Silverhav Robin Silverhav TDTS09 Datornät och internetprotokoll Linköpings universitet

2 Sammanfattning Denna rapport handlar om SSL, det vanligaste sättet att säkra information som skall skickas över internet. Det vi kommer att ta upp är hur denna standard fungerar mer ingående. Vi kollar på hur det arbetar mellan de olika lagrena och lite på hur krypteringen som används fungerar. Vi kommer även ta upp säkerhetsbrister som finns i denna standard. Då talar vi lite om de olika attackerna som kan användas för att komma åt och även modifiera informationen som någon annan skickar. Trots att SSL är en gammal standard så gör det ett bra jobb. Det uppdateras relativt fort och de säkerhetsbrister som hittas lagas. Vi nämner lite om vad framtiden kan ha att komma med.

3 Innehållsförteckning 1. Inledning Syfte Metod och källor Avgränsningar Beskrivning av SSL Vad är SSL? Kryptering Hur fungerar SSL Anvädningsområden Säkerhetsbrister Framtiden Diskussion och slutsatser... 8 Referenser... 9

4 1. Inledning Dagens internet är en farlig plats för känslig information. Det finns många som bara är ute efter denna information och med all teknik som ligger bakom så är det inte många som vet hur lätt det kan vara att få tag på den. Det kan vara information som t.ex. bankkortsnummer, lösenord och personlig data. Men som tur är så finns det folk som har tänkt på detta och utvecklat SSL (Secure Sockets Layer) som håller informationen säker. SSL är en säkerhetsmekanism som krypterar kommunikationen mellan två enheter, så informationen däremellan blir oläsbar. 1.1 Syfte Rapportens syfte är att förklara hur SSL fungerar och kolla på olika användningsområden, vilka sidor som främst använder sig av SSL för att skydda information från utomstående. Vi ska även ta reda på tekniken bakom SSL, hur det gör det möjligt att hålla känslig information säker. Med hjälp av att ta reda på detta ska vi utreda vilka för- och nackdelar det finns att använda sig av SSL. Vi ska även ta reda på vilka lösningar man kan använda sig av för att förbättra nackdelarna. 1.2 Metod och källor Vi kommer att använda oss av främst av David Wagners och Bruce Schneiers analys av SSL 3.0. David Wagner är professor i datavetenskap vid University of California, Berkley och Bruce Schneiers är specialist på datorsäkerhet och författare, han har skrivit flera böcker om datorsäkerhet. Vi kommer även att använda oss av Wikipedia för att ta reda på olika begrepp vi stöter på. Då Wikipedia anses ofta vara lite av en osäker källa men vi tycker att det är en väldigt bra källa att få uppdaterad information inom ämnet, då de ofta uppdateras jämfört med böcker. 1.3 Avgränsningar Eftersom SSL använder sig av allt från hashfunktioner till olika krypteringsalgoritmer så har vi begränsat vårat projekt till SSLs utveckling och dess nuvarande för- och nackdelar. Vi har valt att inte gå in i djupare detalj på alla dessa olika krypteringsmetoder. 1

5 2. Beskrivning av SSL 2.1 Vad är SSL? SSL är en säkerhetsmekanism som uppfanns till Netscape och används för att kryptera trafik i en server/client-connection. SSL 1.0 släpptes aldrig men version 2.0 kom år Denna version innehöll några säkerhetsbrister vilket ledde till utvecklingen av SSL 3.0 som släpptes Den jobbar mellan transport- och applikationslagret i TCP-IP modellen. Tanken med denna kryptering är att ingen ska kunna avlyssna eller manipulera informationen inom nätverket (detta oftast internet). Bild 1 visar hur SSL ligger mellan applikationslagret och transportlagret 2.2 Kryptering SSL använder sig av symmetrisk kryptering för att kryptera information. Symmetrisk kryptering använder en identisk krypterings- och dekrypteringsnyckel, eller så finns det en simpel transformation att gå mellan dem. Efter krypteringen ser det bara ut som massa slumpmässiga tecken, men man kan använda samma algoritm som användes för att kryptera informationen till att dekryptera den. Därför kallas symmetrisk kryptering även för deladnyckel-kryptering. Bild 2 illustrerar konceptet med kryptering. 2

6 Ju större en krypteringsnyckel är, desto svårare är det i praktiken att forcera kryptot. Och eftersom antalet olika kombinationer ökar exponentiellt med hur många byte krypteringsnyckeln är, så med nog stor nyckel blir det inprincip omöjligt att forcera den. För att beräkna hur många olika kombinationer det finns för att forcera ett krypto kan man använda formeln: kombinationer. 2.3 Hur fungerar SSL SSL är uppdelad i två lager som båda använder sig av tjänster från de lägre lagrena och ger funktionalitet till de högre. SSL record protocol ger en förtrolig och autentiserad anslutning över ett pålitligt transport protokoll som Transmission Control Protocol (TCP). * Ovanför record protocol finns SSL handshake protocol. När en klient ansluter till en server som använder sig av SSL så svarar servern med en lista på olika CipherSuites (algoritmer och hash-funktioner) som den den stödjer. Från denna lista så väljer sedan servern den algoritmen som är säkrast som båda har stöd för och berättar för klienten vilken CipherSuite som skall användas. Serven skickar sedan sin identifikation i form av ett digitalt certifikat och den publika krypteringsnyckeln. Klienten får ansluta till servern skickade certifikatet och bekräfta att certifikatet är giltigt. För att sedan generera fram en sessionsnyckel som kan avändas för att få en säker anslutning så krypterar klienten en slumpmässigt siffra tillsammans med serverns publika nyckel och skickar detta till servern. Bara servern ska kunna dekryptera detta med sin privata nyckel. Både klient och server genererar material för kryptering och dekryptering med hjälp av den slumpmässiga siffran. Efter detta så kan den känsliga applikations datan börja skickas via SSL record protocol. Det SSL record protocol gör är att den tar applikationsdatan som ska skickas och fragmenterar den i delar, kapslar in dem med headers och skapar ett object som kallas för bara record. Detta krypteras sen och kan vidareskickas till TCP protokollet som skickar till mottagaren. I det första steget av förberedelserna inför skickandet av datan fragmenteras den, det vill säga bryter upp dataströmmen som ska skickas till 16Kb, eller mindre, fragment. Efter detta börjar skapandet av recorden för varje del av datan genom att lägga till en header på den, möjligen information för att nå rätt storlek och en Message Authentication Code (MAC). MAC förklaras i stycket nedan. Headern som läggs till innehåller two delar med information, längden av recorden och längden av datablocket som lades till på original datan. Det som recorden innhåller nu är: 3

7 Datan Utfyllnad för att nå rätt storlek MAC värde MAC är till för att verifiera att datan som skickades är samma som tas emot. Det är resultatet av en hash-funktion som följer en viss algoritm, till exempel SHA-1. MAC skapas med hashfunktionen som tar emot följande data: MAC = Hash-funktion [hemlig nyckel, datan, sekvensnummer]. Den hemliga nyckeln som skapas i samband med MAC är antingen skapad av klienten eller servern, beroende på vem som skickar den. Efter att någon tagit emot ett paket så räknar de ut värdet av sin MAC och jämför med den som togs emot. Om de matchar så betyder det att datan är intakt och har inte modifierats på vägen. Efter detta så krypteras datan plus MAC:en med hjälp av den valda symmetriska krypterings algoritmen, till exempel DES eller tripple DES. På denna förberedda data läggs en header till. Denna header består av: Innehållets typ: används för att avgöra vilka högre protokoll som skall användas för att processera datan som har inkluderats i paketet. De olika värden som detta kan anta är change_cipher_spec, alert, handshake och application_data. Sistnämnda refererar till det passande protokollet. Huvuddels version: säger viken version som huvuddelen av protokollet är. För SSL 3.0 är värdet 3. Mindredels version: säger vilken version som resten av delen av protokollet är. För SSL 3.0 så är värdet 0. Efter detta så skickas recorden till mottagaren. Hela processen att förbereda och skicka recorden illustreras i bilden nedan 4

8 Bild 3 illustrerar skapandet av paket under SSL record protocol Bild 4 visar hur början av en session kan se ut mellan klient och server när SSL används 5

9 2.4 Anvädningsområden Det är väldigt vanligt för hemsidor som kräver personliga uppgifter även sidor som kräver lösenord att dessa använder sig av SSL. Alla webbutiker använder sig av SSL för att skydda personlig data från att läcka ut så andra kan få tag i dessa, så som personuppgifter och även bankkortsnummer. Även vissa forum använder sig av det för att bland annat skydda lösenord och identitet. Till exempel så använder sig Flashback av det för att alla användare ska vara helt anonyma. Alla internet banker använder sig också av SSL för att skydda känslig information, till exempel kontouppgifter och lösenord. 2.5 Säkerhetsbrister Det är väldigt vanligt att när man sätter upp en hemsida som använder SSL, alltså en Hypertext Transfer Protocol Secure (https) adress, och att man litar på att det är säker lagring av lösenord och annan känslig information. Bara för att man använder sig av SSL så betyder det inte att det är säker lagring. Det är viktigt att tänka på att även databasen lagrar den krypterande informationen, för SSL krypterar bara trafiken mellan browsern och server. När man skriver in ett lösenord på en hemsida som använder https adress så krypteras lösenordet, men när lösenordet lagras i databasen så dekrypteras den och sparas som original lösenordet såg ut. Detta är ett vanligt misstag och det lurar besökarna på sidan som tror att informationen är säker eftersom det är en https adress och inte en Hypertext Transfer Protocol (http) adress. Därför är det viktigt att man implementerar in på databasen att den sparar den krypterade datan. Ett sätt som kan användas för att komma över känslig information är en Man-In-The-Middle attack (MITM). Denna attack går ut på att man genskjuter trafiken mellan två klienter eller klient/server och får dem att tro att de talar med varandra när all deras trafik går via dig som kan läsa den, till och med modifiera den innan du skickar vidare den. Ett exempel på en MITM Låt oss säga att Alice vill kommunicera med Bob. Samtidigt vill Mallory kunna lyssna av konversationen och kunna modifiera den. Först och främst så frågar Alice Bob om hans publika nyckel. Om Bob skickar nyckeln till Alice och Mallory plockar upp den innan den kommer fram till Alice så kan en MITM attack börja. Detta genom att Mallory skickar ett förfalskat meddelande till Alice som hon tror är från Bob. Men detta medelande inkluderar istället Mallorys publika nyckel. Alice tror nu att denna nyckel är Bobs, hon krypterar sitt meddelande med denna nyckel och skickar det till Bob. Mallory plockar upp meddelandet, dekrypterar det med hennes nyckel. Efter detta kan hon, om hon vill, modifiera meddelandet innan hon krypterar det med Bobs nyckel och skickar vidare det till han. Han kommer att tro att meddelandet som han tar emot egentligen är Alice meddelande. Robert McMillan skrev 30 juli 2009 i en artikel för computerworld.com att säkerhetsforskare 6

10 har hittat ett säkerhetshål i mjukvaran som använder sig av SSL. Vi Black Hat conference i Las Vegas samma år visade forskarna upp olika attacker som kan kompromissera säker trafik mellan webbservrar och klienter. Denna typ av attack kan låta någon komma över lösenord, kapa en pågående bank session eller till och med påtvinga en Firefix update som innehåller skadlig kod. Problemet är att många webbläsare har implementerat SSL och X.509 public key infrastruktur systemet också. Sistnämnda används för att avgöra om en hemsida är pålitlig eller inte. En säkerhetsforskare som kallar sig själv Moxie Marlinspike visade ett sätt att genskjuta SSLtrafik genom att använda något som han kallar för "null-terminition certificate". För att lyckas med detta så måste han få sin mjukvara installerad inom ett LAN. När den har installerats så hittar den SSL-trafik och presenterar hans null-terminition certificate för att kuna genskjuta kommunicationen mellan klienten och servern. Denna typ av MITM är inte möjlig att upptäcka säger han. Denna attack är väldigt lik annan attack som kallas SQL injection attack som går ut på att man skickar in data i ett program i hopp om att programmet ska göra något som det normalt inte gör. Marlinspike hittade att om han skapade ett certifikat till sin egna domän som innehåller "null characters", som oftast representeras med \0, så misstolkar vissa program certifikatet. Detta för att program slutar läsa text när de ser en null character. Så ett certifikat skickat till t.ex. kan läsas som om det tillhörde Framtiden År 1996 började Internet Engineering Task Force (IETF) utveckla en standard för säker kommunikation över internet. De hade SSL 3.0 som utgångspunk och 1999 släpptes RFC 2246 som definierade det nya Transport Layer Security (TLS) protokollet version 1.0. Målet med detta var liknande SSL:s mål, att ge säkerhet och dataintegritet vid transportlagret mellan två webbapplikationer. Skillnaden mellan SSL 3.0 och TLS 1.0 är inte stor men fortfarande stor nog för göra att de inte ska kunna kommunicera med varandra. TLS 1.1 definierades i RFC 4346 i april 2006 och den senaste versionen är 1.2. Denna definierades augusti Idag är det SSL som används mest för att säkra information som transporteras över internet men man tror att TLS kommer att ta över och bli den nya standarden inom säkerhet och dataintegritet för webbkommunikation. 7

11 3. Diskussion och slutsatser SSL är, enligt oss, ett bra sätt att skicka känslig information över internet utan att andra ska kunna läsa eller modifiera den. Trots att det är 15 år sedan som SSL 3.0 släpptes så är det fortfarande standarden för säker trafik över internet idag. Detta säger mycket om hur bra det egentligen är. Något som håller dem i toppen är att de fixar säkerhetsbristerna som folk hittar inom en relativt kort tid. Detta är en väldigt viktig del av just säkerhet på internet då det alltid finns folk som försöker hitta sätt att komma åt informationen som skickas. Eftersom det finns så väldigt mycket folk som är kompetenta på internet så finns det alltid ett seriöst hot mot standarder. Som det ser ut nu så är Man-In-The-Middle attacker det vanligaste hotet mot SSL-trafik. Det finns till och med färdiga program och många guider om hur man använder dem. Så som vi ser det så är SSL rätt så säkert, men det är allt runt som gör det osäkert. Till exempel finns det ett program som heter sslstrip. Detta är ett väldigt smart program och fungerar så att det "arp spoofar" din adress så att datorerna på nätverket tror att du är routern och kommer då skicka sin trafik via dig. När de gör detta så letar sslstrip efter SSL trafik. Låt oss säga att en klient skall logga in på programmet ser detta och ger klienten en likadan hemsida men som bara är http. Han loggar in och märker ingen skillnad då programmet bara redirectar han till vanliga gmail.com med den informationen som han skickade till den "arp spoofade" användaren som kallar sig router. Detta går endast att göra om man är på samma nätverk, därför ska man passa sig för om man är på ett publikt nätverk t.ex. skola, internetcafé eller biblotek. På sitt hemnätverk kan man vara i princip säker från dessa MITM attacker om man t.ex. använder ett 64 tecken långt lösenord med blandade versaler, gemener och siffror. Detta tillsammans med WPA2 kryptering på nätverket gör det näst intill omöjligt att knäcka. Så som vi ser på saken så är SSL säkert till största del, men det är säkerheten runt allt annat som kan göra SSL osäkert. Allt från osäkra nätverk till dåligt designade databaser. 8

12 Referenser Burnett, Steve & Paine, Stephen (2001). RSA Security's Official Guide to Cryptography. McGraw-Hill Professional Publishing. Wagner, David & Schneier, Bruce. Analysis of the SSL 3.0 protocol. Tillgänglig på ( ). Onyszko, Tomasz. Secure Socket Layer. Tillgänglig på ( ). McMillan, Robert (2009). More holes found in Web s SSL security protocol. Tillgänglig på urity_protocol ( ). Burkholder, Peter (2002). SSL Man-in-the-Middle Attacks. Tillgänglig på ( ). Philbin, Stephen (2011). How to Avoid Common SSL Usage Mistakes. Tillgänglig på ( ). IETF (2008). The Transport Layer Security (TLS) Protocol, RFC 5246, Internet Engineering Task Force (IETF), Augusti (2008). Tillgänglig på ( ). Bild på framsida: ( ). Bild 1: ( ). Bild 2: ( ). Bild 3: ( ). Bild 4: ( ). 9