Security paper - TLS en HTTPS

Security paper - TLS en HTTPS Tom Rijnbeek - 3657086 18 juni 2013 Inhoudsopgave 1 Introductie 2 2 Beschrijving TLS 2 2.1 Doelen................................. 2 2.2 Lagen Model............................. 3 2.2.1 Record Protocol....................... 3 2.2.2 TLS Handshake Protocol.................. 3 3 TLS Handshake 4 3.1 Gedetailleerd overzicht........................ 4 3.2 Voortzetting bestaande sessie.................... 6 4 Overige protocollen 6 4.1 Change Cipher Spec Protocol.................... 7 4.2 Alert Protocol............................. 7 4.3 Application Data Protocol...................... 7 5 Security Analyse 7 5.1 Key Exchange............................. 8 5.2 Version Rollback........................... 8 5.3 Resume Session............................ 8 5.4 Application Data........................... 9 5.5 Denial of Service........................... 9 6 Toepassing: HTTPS 9 6.1 Certificering.............................. 10 6.2 OCSP................................. 11 6.3 DigiNotar............................... 11 7 Conclusie 11 1

1 Introductie Op 30 april 1993 werd door CERN de eerste webpagina online gezet die het World Wide Web voor iedereen beschikbaar maakte [8]. Hiermee werd het startpunt voor de groei van het internet gemarkeerd. Rond dezelfde tijd werd er onderzoek gedaan naar het beveiligen van de communicatie die op het internet plaatsvond. Netscape ontwikkelde hiervoor het zogenaamde SSL (Secure Sockets Layer) protocol. De eerste versie werd nooit publiekelijk vrijgegeven, maar in februari werd SSL 2.0 uitgebracht. Deze versie bevatte echter enkele grote veiligheidsproblemen en dit leidde ertoe dat Netscape in 1996 SSL 3.0 uitbracht. In 1999 werd een verbeterde versie van het SSL 3.0 protocol uitgebracht onder de naam TLS 1.0. De veranderingen tussen SSL 3.0 en TLS 1.0 zijn minimaal, maar toch voldoende om ervoor te zorgen dat er geen compatibiliteit tussen de twee protocollen is. Vandaar dat TLS 1.0 een mogelijkheid geeft om terug te vallen op het oudere, minder veilige SSL 3.0 protocol. De compatibiliteit met SSL 2.0 is pas verwijderd in een kleine update in maart 2011. In april 2006 werd een nieuwe verbetering van TLS gepubliceerd onder de naam TLS 1.1 die de veiligheid verder verbeterde. De laatste significante update van TLS vond plaats in in augustus 2008, waarbij de MD5-SHA-1 hashing werd vervangen door SHA256 en er support werd toegevoegd voor het gebruik van AES. 2 Beschrijving TLS 2.1 Doelen Het TLS protocol is ontworpen voor vier doelen [6]. Deze vier doelen zijn, in volgorde van prioriteit van hoog naar laag: 1. Cryptografische beveiliging: TLS moet gebruikt kunnen worden om een cryptografisch veilige verbinding te kunnen aanleggen en handhaven tussen twee partijen; 2. Compatibiliteit: een developer moet zonder kennis te hebben van de code van een externe applicatie verbinding kunnen maken met die applicatie via het TLS protocol; 3. Uitbreidbaarheid: het TLS protocol moet zonder al te veel moeite uitgebreid kunnen worden met nieuwe public key en andere encryptie-methoden; 4. (Relatieve) efficiëntie: veel cryptografische technieken kunnen zwaar zijn voor de CPU; TLS moet een caching mechanisme ondersteunen om de hoeveelheid rekenwerk te kunnen reduceren en de hoeveelheid netwerkverkeer binnen perken te houden. 2

2.2 Lagen Model Voor het onderzoeken van communicatie tussen twee partijen wordt binnen de informatica vaak gebruik gemaakt van het OSI model [7]. Binnen dit model abstraheren we de communicatie in zeven verschillende lagen: Application Layer (layer 7); Presentation Layer (layer 6); Session Layer (layer 5); Transport Layer (layer 4); Network Layer (layer 3); Data Link Layer (layer 2); Physical Layer (layer 1). In dit model handelt elke laag een deel van de verbinding af. Elke laag voegt een nieuw element toe aan de verbinding. Zo zorgt de Physical Layer alleen voor de daadwerkelijke fysieke verbinding, terwijl de Data Link Layer zich bezig houdt met de adressering van het pakketje dat verzonden moet worden. Applicaties draaien in de Application Layer. Voorbeelden van applicaties zijn bijvoorbeeld de HTTP en FTP protocollen. Het TLS protocol is zelf ook in twee lagen te verdelen [6]: 2.2.1 Record Protocol Onderaan bevindt zich, gebouwd bovenop een betrouwbaar transport protocol (Transport Layer), zoals bijvoorbeeld TCP/IP, het TLS Record Protocol. Binnen dit protocol wordt gebruikgemaakt van symmetrische encryptie (bijv. AES) middels een vastgestelde sleutel. Het is ook mogelijk om het TLS Record Protocol zonder encryptie te gebruiken, maar hiermee wordt de sessie niet langer als private beschouwd. Verder kan het TLS Record Protocol integriteit van de verzonden berichten garanderen middels een MAC (Message Authentication Code) met een sleutel. Hiervoor wordt gebruikt gemaakt van een veilige hash-functie zoals SHA-1. 2.2.2 TLS Handshake Protocol Het TLS Record Protocol is een abstractielaag voor verschillende high level protocollen. Het belangrijkste protocol hiervan is het TLS Handshake protocol. Dit protocol gebruik assymetrische (public-key) cryptografie om de server en client the authentificeren en de encryptiesleutel en andere cryptografische parameters vast te stellen die door het Record Protocol gebruikt kunnen worden. In de volgende sectie wordt er dieper op deze handshake ingegaan. 3

De plaatsing van TLS in het OSI model is erg lastig. Er is door de ontwerpers geen rekening gehouden met de plaatsing van dit protocol in het OSI lagen model. De reden hiervoor is dat in het TCP/IP Model slechts vier lagen onderscheiden worden [1]: Application Layer Transport Layer Internet Layer Link Layer Zoals eerder beschreven is het TLS Record Protocol gebouwd op een betrouwbaar transport protocol dat in de Transport Layer wordt geregeld. Het TLS protocol bevindt zich dus tussen de Application Layer en Transport Layer en zou in het OSI model dus plaatsvinden in de Session en Presentation Layer. Er is geen vaste layer voor TLS aan te wijzen, maar strict gesproken zou TLS plaats moeten vinden in de Session Layer. 3 TLS Handshake Voordat er begonnen kan worden met een beveiligde sessie, moeten we eerst de cryptografische parameters van de sessie vaststellen. Hiertoe gebruiken we het TLS Handshake protocol. In grote lijnen bestaat dit protocol uit de volgende stappen: Uitwisseling hello messages om het te gebruiken algoritme vast te stellen, random waarden uit te wisselen en te controleren of we een bestaande sessie kunnen voortzetten; Uitwisseling cryptografische parameters die gebruikt kunnen worden om een premaster secret vast te stellen; Authenticatie middels certificaten; Generatie van een master secret met behulp van de eerder uitgewisselde premaster secret en random waarden; Verzending van de parameters naar de record layer van het TLS protocol; Verificatie om te controleren of beide partijen dezelfde parameters hebben en er geen interventie door een buitenstaander heeft plaatsgevonden. Om deze geheimen te kunnen genereren, wordt er gebruik gemaakt van public key encryptie. 3.1 Gedetailleerd overzicht De verbinding wordt gestart door de client die een ClientHello bericht verstuurt naar de server. De server zal vervolgens antwoorden met een ServerHello 4

Figuur 3.1: Overzicht van een complete TLS handshake bericht. Als er geen antwoord van de server komt, zal de verbinding getermineerd worden. De ClientHello en ServerHello bevatten beiden de versie van het protocol, sessie identifier, de cipher suite 1 en de compressiemethode. Verder worden er middels deze berichten twee willekeurige waarden (ClientHello.random en ServerHello.random) gegenereerd en uitgewisseld. Na het uitwisselen van de hello berichten, zal de server eventueel één of meer van deze berichten aan de client versturen: Certificate: als de server zich moet authenticeren tegenover de client, zal de server zijn certificaat versturen aan de client om de authenticiteit te bewijzen; ServerKeyExchange: als de client geen sleutel heeft om zijn eigen key exchange bericht te versleutelen, omdat er bijvoorbeeld geen certificaat is verstuurd of het geen publieke sleutel bevat, zal de server via dit bericht een tijdelijke sleutel naar de client sturen; CertificateRequest: als het voor de gekozen sessie parameters nodig is dat de client zichzelf authenticeert, zal de server de client ook om een certificaat vragen. Nadat deze berichten al dan niet zijn verzonden, zal de server afsluiten met een ServerHelloDone bericht en het antwoord van de client afwachten. Als 1 Een cipher suite bestaat uit een combinatie van een key exchange algoritme, symmetrisch encryptie algoritme, een algoritme om berichten te verifiëren (MAC) en een pseudo-random functie [6]. 5

Figuur 3.2: Overzicht verkorte handshake die wordt gebruikt bij het voortzetten van een bestaande sessie de server heeft gevraagd om een certificaat van de client, dan moet deze door de client verzonden worden om de sessie voort te zetten. Verder zal de client nu ook het ClientKeyExchange bericht versturen. De precieze inhoud van dit bericht is afhankelijk van het gekozen key exchange algoritme in de cipher suite in de hello messages. Tot slot, als de client een certificaat heeft gestuurd, zal de client na het versturen van het ClientKeyExchange bericht een handtekening van ditzelfde bericht met de private key uit het certificaat versturen naar de client (CertificateVerify), zodat de server kan verifiëren dat de client inderdaad over het certificaat beschikt. Tot slot zal de client een zogenaamd ChangeCipherSpec bericht naar de server sturen 2, waarin alle vastgestelde parameters staan. Hiermee verificeert de client dat vanaf nu alle berichten met deze parameters versleuteld zullen worden. Direct daarna zal er een Finished bericht verstuurd worden. Op dezelfde wijze verstuurt de server deze twee berichten naar de client om het handshake protocol af te ronden (zie ook figuur 3.1). 3.2 Voortzetting bestaande sessie Het is ook mogelijk om een bestaande sessie tussen twee partijen voort te zetten. In dit geval wordt de bestaande sessie identifier meegestuurd in de hello message van de client. Als de server de voortzetting accepteert, zal de server direct na de hello messages de ChangeCipherSpec en Finished berichten versturen, gevolgd door de client (zie figuur 3.2). Als de server een nieuwe sessie wilt starten, zal er een nieuwe sessie identifier gegenereerd en teruggestuurd worden en zal het volledige handshake proces doorlopen worden. 4 Overige protocollen Het TLS Record Protocol encapsuleert naast het Handshake protocol ook nog andere protocollen. Het is daarbij ook mogelijk om zelf nieuwe protocollen toe te voegen. Hieronder staan kort drie veelgebruikte protocollen beschreven. 2 In feite is het ChangeCipherSpec protocol geen onderdeel van het Handshake protocol, om eventuele filevorming te voorkomen. Zie ook sectie 4.1 6

4.1 Change Cipher Spec Protocol Het Change Cipher Spec Protocol is toegevoegd om ervoor te zorgen dat één van de partijen wijzigingen in de parameters van de sessie kan doorgeven. Dit protocol bestaat uit de verzending van één enkel bericht door beide partijen. Het bericht wordt door de partij die de wijziging initieert verstuurd onder de huidige encryptie-parameters. Als de andere partij het bericht ontvangt, verandert deze meteen de parameters en verstuurt via hetzelfde protocol een bericht terug om te laten weten dat alle volgende berichten met deze nieuwe parameters verstuurd worden. Dit protocol wordt tijdens de handshake gebruikt om te verifiëren dat beide partijen dezelfde parameters hebben gegenereerd. 4.2 Alert Protocol Als er een fout optreedt tijdens een sessie, kan het Alert Protocol gebruikt worden om hierover bericht te versturen. In een Alert bericht bevindt zich de ernst van de fout en een omschrijving van de aard ervan. Een alert kan een waarschuwing (warning) zijn of fataal (fatal). In het laatste geval wordt de sessie direct gestopt. De sessie identifier wordt ongeldig verklaard, zodat het ook niet mogelijk is om alsnog door te gaan met het verzenden van berichten via deze sessie. Het afsluiten van een sessie wordt afgehandeld door een speciale alert van het type close_notify. Nadat een partij dit bericht heeft verstuurd, zullen alle verdere berichten die via deze sessie binnenkomen worden genegeerd. Ook de andere partij reageert met een close_notify alert. Het is echter niet nodig voor de eerste partij om dit bericht af te wachten om de connectie daadwerkelijk te sluiten. Dit is echter wel mogelijk, afhankelijk van de opbouw van de applicatie. 4.3 Application Data Protocol Het Application Data Protocol wordt gebruikt om de data van de applicatie naar de ontvanger te versturen. Er zijn geen speciale eisen aan berichten van dit protocol. Het Record Protocol zal het bericht fragmenteren, comprimeren en versleutelen volgens de huidige parameters en overbrengen aan de ontvangende partij. 5 Security Analyse TLS is een protocol dat gebruikt wordt om informatie beveiligd te versturen over een onbeveiligd kanaal. Dit betekent dat de aanvaller toegang heeft tot alle verstuurde informatie. Het protocol is dus vatbaar voor aanvallen. In het algemeen geldt dat dit protocol uitgaat van een betrouwbare server en client die veilige applicaties draaien. Een TLS systeem leunt voor zijn veiligheid zwaar op het key exchange en authenticatie algoritme dat wordt gebruikt en de veiligheid van een TLS sessie is dus direct afhankelijk van deze keuze. 7

5.1 Key Exchange De twee gebruike key exchange algoritmen, Diffie-Hellman en RSA, zorgen er beiden voor dat de aanvaller, die alle communicatie die tijdens de handshake kan inzien, de afgesproken geheimen niet kan achterhalen. Een andere mogelijkheid zou zijn dat de aanvaller de communicatie tussen de twee partijen gaat beïnvloeden. Echter, dit zal ertoe leiden dat de gegenereerde data bij de partijen verschillend zal worden. Hierdoor zijn de Finished berichten verschillend van elkaar en dit zal leiden tot het termineren van de sessie. Op deze manier heeft het handshake protocol dus een ingebouwde controle tegen aanvallen van buitenaf. Een ander probleem is het vaststellen van de identiteit van de partijen. Binnen TLS zijn er drie mogelijkheden voor authenticatie: volledige authenticatie, anonieme client (waarbij de server is geauthenticeerd) en volledige anonimiteit. Wanneer er gekozen wordt voor een volledig anonieme sessie, kan geen van de key exchange algoritmes garantie geven voor de veiligheid van de sessie, omdat er niet na kan worden gegaan of er een man-in-the-middle is. Als er sprake is van authenticatie, wordt deze extra laag veiligheid wel toegevoegd. Zowel RSA als Diffie-Hellman hebben de mogelijkheid om deze identiteit door middel van de verstuurde certificaten te controleren. Merk op dat er hiervoor wel een vertrouwde certificate authority nodig is en dat TLS niet van invloed is op de betrouwbaarheid daarvan (zie ook sectie 6.3). Men moet extra voorzichtig zijn als er voor meerdere sessies dezelfde parameters gebruikt worden. Als er onvoldoende maatregelen worden genomen, wordt het systeem gevoelig tegenover subgroep aanvallen [3]. Een eenvoudige manier om deze aanvallen te voorkomen is door Diffie-Hellman te gebruiken en voor elke sessie een nieuwe private key te genereren. Als een geschikte basis (bijvoorbeeld 2) wordt gekozen, is g x mod p eenvoudig uit te rekenen en de impact op de performance minimaal [6, F.1.1.3]. 5.2 Version Rollback Voor de update in maart 2011 die de backwards compatibility met SSL 2.0 verwijderde, kon het voorkomen dat de aanvaller probeerde om over te stappen naar SSL 2.0, omdat deze versie minder veilig is dan het huidige TLS. Deze aanval kan alleen plaatsvinden als beide partijen het SSL 2.0 protocol nog ondersteunen. Er is een (inelegante) mogelijkheid om dit te detecteren, maar deze werkt alleen als de aanvaller over onvoldoende rekenkracht bezit om de sleutel te bruteforcen. 5.3 Resume Session TLS biedt ook ondersteuning om een bestaande sessie voort te zetten. Hiervoor worden er wel nieuwe willekeurige waarden verstuurd. Deze willekeurige waarden worden versleuteld met de huidige master key, dus zolang deze niet aangetast is, zal de sessie veilig blijven. Een sessie kan alleen worden voortgezet als beide partijen dit accepteren. Als dus één van de partijen het vermoeden heeft dat de sessie niet langer beveiligd is, zal het hele handshake protocol doorlopen moeten worden. 8

5.4 Application Data De master key wordt samen met de random waarden uit de hello messages gehasht om voor elke verbinding een unieke encryptie-sleutel te genereren. Vervolgens wordt er symmetrische cryptografie gebruikt om de berichten te versleutelen. Als de aanvaller de encryptiesleutel kan achterhalen, kan deze alle verzonden berichten ontsleutelen. TLS ondertekent elk bericht met een MAC handtekening. Deze handtekening wordt berekend uit de MAC sleutel, sequence nummer, lengte van het bericht, inhoud van het bericht en twee vooraf vastgestelde strings. Verder wordt ook het type van het bericht toegevoegd, zodat de aanvaller de berichten niet kan doorsturen naar een andere record layer. Door het sequence nummer toe te voegen, kan de aanvaller ook geen berichten verwijderen, toevoegen of herordenen zonder dat dit wordt gedetecteerd. Ook hier geldt dat als de MAC sleutel gevonden wordt door de aanvaller, alle berichten die dan verstuurd worden gevoelig zijn voor bewerkingen. Het kan dan ook gebeuren dat de MAC sleutel langer wordt gekozen dan de encryptiesleutel, zodat als de aanvaller de encryptiesleutel gekraakt heeft, de berichten nog steeds niet door de aanvaller aangetast kunnen worden. 5.5 Denial of Service Een veelvoorkomend type aanval op het internet is de Denial of Service (DoS) aanval. Een DoS aanval is een aanval waarbij er gepoogd wordt om de services die een computer of netwerk uitvoert te verstoren [5]. Een bekende vorm hiervan is een aanval waarbij er in korte tijd een grote hoeveelheid requests naar het doelwit worden verstuurd (meestal vanaf een grote hoeveelheid machines of botnet). Hierdoor wordt de server overbelast en dus onbereikbaar. Door een grote hoeveelheid requests te versturen naar een server via het TLS protocol, zal de server een grote hoeveelheid CPU besteden aan het decrypten van de RSA handtekeningen. Echter, doordat verbindingen naar TLS servers bijna uitsluitend over TCP plaatsvinden, is de oorsprong van deze requests redelijk eenvoudig te achterhalen en af te sluiten. Een andere manier om een Denial of Service uit te voeren is door een grote hoeveelheid foutieve berichten te versturen. Hierdoor worden allerlei sessies afgesloten, omdat de ontvangende partij besluit dat de beveiligde verbinding niet langer integer is. Ook kan de aanvaller partiële record berichten versturen, waardoor de ontvanger in afwachting blijft van de rest van het bericht en dus vastloopt. Het TLS protocol zelf biedt geen beveiliging tegen dit soort aanvallen, maar er zijn verschillende andere middelen om een server hiertegen te beveiligen. 6 Toepassing: HTTPS HTTP (Hypertext Transfer Protocol) wordt al sinds 1990 voor vele doeleinden gebruikt. Niet alleen wordt het gebruikt om Hypertext over het internet te verspreiden, maar ook vele andere media formaten worden tegenwoordig via dit protocol verspreid. Door de jaren heen werd HTTP steeds meer gebruikt om ook gevoelige informatie over het internet te versturen. Omdat HTTP geen mogelijkheden tot encryptie heeft, was deze informatie eenvoudig te achterhalen. Hierdoor rees de noodzaak om een standaard te ontwikkelen die encryptie van 9

deze gegevens mogelijk maakt. Het principe van HTTPS is zeer eenvoudig: in plaats van HTTP direct over het TCP/IP protocol te versturen, versturen we HTTP via het TLS protocol [4]. De partij die in de communicatie optreedt als HTTP client zal ook optreden als client in het TLS protocol en verstuurt dus de initiatie van het TLS protocol naar de server. Nadat de handshake is afgehandeld, wordt alle HTTP data verzonden via het TLS protocol. Hierbij moeten de voorwaarden van het reguliere HTTP protocol nog steeds gevolgd worden. 6.1 Certificering Om man-in-the-middle aanvallen te voorkomen, zal de server geauthenticeerd moeten worden. Anders zou het mogelijk kunnen zijn om een server te maken die zich voordoet als de legitieme server. De gebruiker krijgt een website te zien die gekopieerd is van het origineel en ook het webadres is hetzelfde. Nu zal de gebruiker dus zijn gegevens via een beveiligde verbinding naar de server van de aanvaller sturen. Om dit te voorkomen is HTTPS voorzien van certificaten. Wanneer er gebruik gemaakt wordt van HTTPS, is het verplicht om dit certificaat te controleren (dit in tegenstelling tot het standaard TLS protocol, waarbij deze stap eventueel overgeslagen kan worden). In het geval dat het certificaat niet klopt, dienen gebruiker-gerichte applicaties de gebruiker hiervan op de hoogte te stellen. De gebruiker mag er dan voor kiezen alsnog de sessie voort te zetten. Geautomatiseerde applicaties moeten een probleem met het certificaat loggen. Een geautomatiseerde applicatie mag een instelling hebben die deze controle negeert, maar het moet een optie bevatten om verbindingen met servers met een valse identiteit automatisch te termineren. Om deze controle uit te voeren, wordt er gebruik gemaakt van de hostnaam van de server. In het geval dat de server is benaderd door middel van een IP-adres, wordt deze door de server gebruikt om de identiteit vast te stellen. NB. Het gebruik van certificaten beveiligt niet tegen aanvallen waarbij de URI (Uniform Resource Identifier) is aangepast. De aanvaller kan bijvoorbeeld een link op een onbeveiligde HTML pagina hebben aangepast en de gebruiker dus naar een geheel andere pagina sturen. Om ervoor te zorgen dat certificaten waarde hebben, moet er een derde partij geïntroduceerd worden die door zowel de server als de client wordt vertrouwd: de certificate authority. Een certificate authority (kortweg CA) kan certificaten uitgeven aan andere partijen. Deze uitgegeven certificaten worden van een handtekening voorzien die bevestigt dat dit certificaat afkomstig is van een CA. Binnen bedrijven wordt er soms ook gebruik gemaakt van een eigen certificate authority. Hier kunnen dan bepaalde andere root certificaten aan toegevoegd worden en het bedrijf kan natuurlijk ook alle certificaten voor eigen services door deze authority laten ondertekenen. Hierdoor hoeft een bedrijf voor intern gebruik van een service geen extern bedrijf in te schakelen. Verder is het ook mogelijk gebruik te maken van CACert [11]. Dit is een community driven certificate authority en maakt gebruik van peer-to-peer om certificaten te verspreiden. 10

6.2 OCSP Een probleem dat voorkomt bij certificaten is het verlopen van deze certificaten. Als er bijvoorbeeld bekend wordt dat een certificaat ongeldig of niet langer veilig is, wordt dit certificaat ingenomen. Echter, de server kan dit certificaat gewoon blijven gebruiken, waardoor de client gewoon het certificaat controleert en vaststelt dat de server is wie hij zegt dat het is. Hierbij heeft de client niet in de gaten dat het certificaat eigenlijk ingetrokken is. Hiervoor is een speciaal protocol gemaakt, waarbij de client een service request naar een zogenaamde OCSP responder. Deze is op de hoogte van de status van het certificaat en kan de client dus vertellen of het certificaat nog geldig is. Er wordt hier geen uitgebreid overzicht gegeven van dit protocol; deze kan gevonden worden in de officiële technische specificatie [2]. 6.3 DigiNotar DigiNotar was een Nederlandse certificate authority. Het bedrijf was bijvoorbeeld verantwoordelijk voor een groot deel van de certificaten van services van de overheid. Tijdens een hack die in juni van het jaar 2011 plaatsvond, kregen de aanvallers toegang tot de systemen van DigiNotar. Tussen 10 en 20 juli werden er door de aanvallers meerdere valse certificaten uitgegeven voor onder andere het google.com-domein en services als Skype, Mozilla add-ons en Microsoft updates. Het duurde lange tijd voordat deze certificaten werden ingetrokken. Er is enkele weken gebruik gemaakt van het valse google.com certificaat om Iraanse inwoners te bespioneren [9]. Toen dit in augustus bekend werd, werden alle certificate authorities die door DigiNotar offline gehaald. Dit leidde uiteindelijk tot het faillissement van het bedrijf [10]. Deze gebeurtenis liet zien in hoeverre de veiligheid van HTTPS, of van TLS in het algemeen, afhankelijk is van het vertrouwen in zelfstandige bedrijven. De veiligheid van zo n protocol is dus in grote mate afhankelijk van de veiligheid van deze instaties. 7 Conclusie Toen het aantal toepassingen van het internet toenam, kwam er behoefte aan het beveiligen van informatie die over de onveilige kanalen verstuurd werd. Hiertoe werd het SSL en later het TLS protocol ontworpen. Dit protocol is op te splitsen in een gedeelte dat de cryptografische parameters vaststelt (handshake protocol) en een deel dat de daadwerkelijke informatie verstuurt (record protocol). Voor de veiligheid is TLS geheel afhankelijk van de gekozen parameters (algoritme, sleutel(grootte), etc.). Verder is een belangrijke kanttekening bij TLS dat je voor het vaststellen van de identiteit van een server afhankelijk bent van een derde partij, de certificate authority. Als er problemen bij een CA komen kan dat grote gevolgen hebben voor de veiligheid, zoals bij DigiNotar duidelijk werd. Al met al kan TLS als een veilig protocol beschouwd worden, zolang de gebruiker bij het instellen van zijn systeem de juiste veiligheidsoverwegingen maakt. 11

Referenties [1] RFC 1122 - Requirements for Internet Hosts - Application and Support : http://tools.ietf.org/html/rfc1122 [2] RFC 2560 - Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP : http://tools.ietf.org/html/rfc2560 [3] RFC 2785 - Methods for Avoiding Small-Subgroup Attacks : http: //tools.ietf.org/html/rfc2785 [4] RFC 2818 - HTTP over TLS : http://tools.ietf.org/html/rfc2818 [5] RFC 4732 - Internet Denial-of-Service Considerations : http://tools. ietf.org/html/rfc4732 [6] RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2 : http://tools.ietf.org/html/rfc5246 [7] ISO/IEC 7498-1 - Information technology - Open Systems Interconnection - Basic Reference Model: The Basic Model [8] http://info.cern.ch/ [9] Inside Operation Black Tulip : DigiNotar hack analysed : http://www. theregister.co.uk/2011/09/06/diginotar_audit_damning_fail/ [10] Black Tulip - Report of the investigation into the DigiNotar Certificate Authority breach : http://www.rijksoverheid.nl/ bestanden/documenten-en-publicaties/rapporten/2012/08/13/ black-tulip-update/black-tulip-update.pdf [11] About CACert : https://wiki.cacert.org/faq/aboutus 12