Robert Heaton

HTTPS is gewoon je standaard HTTP protocol overgoten met een flinke laag heerlijke SSL/TLS encryptie goodness. Tenzij er iets vreselijk mis gaat (en dat kan), voorkomt het dat mensen zoals de beruchte Eve de verzoeken bekijken of wijzigen die je surfervaring vormen; het is wat je wachtwoorden, communicatie en creditcardgegevens veilig houdt op het draadje tussen je computer en de servers waar je deze gegevens naartoe wilt sturen. Hoewel het groene hangslotje en de letters “https” in uw adresbalk niet betekenen dat u en de website die u bekijkt niet meer genoeg touw hebben om zich aan op te hangen, helpen ze u in ieder geval om veilig te communiceren terwijl u dat doet.

Wat is HTTPS en wat doet het?

HTTPS neemt het bekende en begrepen HTTP-protocol, en legt er gewoon een SSL/TLS (hierna gewoon “SSL” genoemd) encryptielaag overheen. Servers en clients spreken nog steeds exact dezelfde HTTP tegen elkaar, maar over een beveiligde SSL verbinding die hun verzoeken en antwoorden versleutelt en ontsleutelt. De SSL laag heeft 2 hoofddoelen:

• Verifiëren dat u rechtstreeks praat met de server waarmee u denkt te praten
• Verzekeren dat alleen de server kan lezen wat u hem stuurt en alleen u kunt lezen wat hij terugstuurt

Het echt, echt slimme deel is dat iedereen elk van de berichten die u uitwisselt met een server kan onderscheppen, inclusief degenen waar u het eens bent over de sleutel en de encryptiestrategie om te gebruiken, en nog steeds niet in staat zijn om een van de werkelijke gegevens te lezen die u verzendt.

Hoe een SSL-verbinding tot stand komt

Een SSL-verbinding tussen een client en een server wordt tot stand gebracht door een handshake, waarvan de doelen zijn:

• De cliënt ervan overtuigen dat hij met de juiste server praat (en optioneel visa versa)
• Dat de partijen het eens zijn geworden over een “cipher suite”, waarin staat welk versleutelingsalgoritme zij zullen gebruiken om gegevens uit te wisselen
• Opdat de partijen het eens zijn geworden over de benodigde sleutels voor dit algoritme

Als de verbinding eenmaal tot stand is gebracht, kunnen beide partijen het overeengekomen algoritme en de sleutels gebruiken om veilig berichten naar elkaar te sturen. We splitsen de handshake op in 3 hoofdfasen – Hello, Certificate Exchange en Key Exchange.

1. Hello – De handshake begint met het verzenden door de client van een ClientHello bericht. Dit bevat alle informatie die de server nodig heeft om via SSL verbinding te maken met de client, inclusief de verschillende cipher suites en de maximale SSL-versie die hij ondersteunt. De server antwoordt met een ServerHello, dat soortgelijke informatie bevat als de client nodig heeft, waaronder een beslissing op basis van de voorkeuren van de client over welke cipher suite en versie van SSL zullen worden gebruikt.

2. Certificate Exchange – Nu het contact tot stand is gebracht, moet de server zijn identiteit aan de client bewijzen. Dit wordt gedaan met behulp van zijn SSL-certificaat, dat een heel klein beetje lijkt op zijn paspoort. Een SSL-certificaat bevat verschillende gegevens, waaronder de naam van de eigenaar, het eigendom (bv. domein) waaraan het is gekoppeld, de openbare sleutel van het certificaat, de digitale handtekening en informatie over de geldigheidsdata van het certificaat. De client controleert of hij het certificaat ofwel impliciet vertrouwt, ofwel dat het geverifieerd en vertrouwd wordt door een van de verschillende Certificate Authorities (CA’s) die hij ook impliciet vertrouwt. Hierover binnenkort meer. Merk op dat de server ook een certificaat mag eisen om de identiteit van de client te bewijzen, maar dit gebeurt gewoonlijk alleen in zeer gevoelige toepassingen.

3. Key Exchange – De encryptie van de eigenlijke berichtgegevens die door de client en de server worden uitgewisseld, gebeurt met een symmetrisch algoritme, waarvan de precieze aard al tijdens de Hello fase is overeengekomen. Een symmetrisch algoritme gebruikt één enkele sleutel voor zowel encryptie als decryptie, in tegenstelling tot asymmetrische algoritmen die een publiek/privaat sleutelpaar vereisen. Beide partijen moeten het eens worden over deze enkele, symmetrische sleutel, een proces dat veilig wordt uitgevoerd met behulp van asymmetrische encryptie en de publieke/private sleutels van de server.

De client genereert een willekeurige sleutel die wordt gebruikt voor het symmetrische algoritme. Hij versleutelt deze met een algoritme waarover ook tijdens de Hello-fase overeenstemming is bereikt, en de openbare sleutel van de server (te vinden op zijn SSL-certificaat). Hij zendt deze versleutelde sleutel naar de server, waar hij wordt ontsleuteld met de privésleutel van de server, en de interessante delen van de handshake zijn voltooid. De partijen zijn voldoende tevreden dat zij met de juiste persoon praten, en hebben in het geheim overeenstemming bereikt over een sleutel om de gegevens die zij op het punt staan elkaar te sturen symmetrisch te versleutelen. HTTP-verzoeken en -antwoorden kunnen nu worden verzonden door een bericht in klare tekst te vormen en dit vervolgens te versleutelen en te verzenden. De andere partij is de enige die weet hoe dit bericht moet worden ontcijferd, en dus zijn Man In The Middle-aanvallers niet in staat verzoeken te lezen of te wijzigen die ze kunnen onderscheppen.

Certificaten

Op het meest basale niveau is een SSL-certificaat gewoon een tekstbestand, en iedereen met een teksteditor kan er een maken. U kunt in feite op triviale wijze een certificaat maken dat beweert dat u Google Inc. bent en dat u het domein gmail.com beheert. Als dit het hele verhaal zou zijn, zou SSL een lachertje zijn; identiteitscontrole zou er in wezen op neerkomen dat de client aan de server vraagt “bent u Google?”, de server antwoordt “eh, ja zeker, hier is een stuk papier met ‘ik ben Google’ erop geschreven” en de client zegt “OK geweldig, hier zijn al mijn gegevens.” De magie die deze farce voorkomt zit in de digitale handtekening, die een partij in staat stelt te verifiëren dat het stuk papier van een andere partij echt legitiem is.

Er zijn 2 zinnige redenen waarom u een certificaat zou kunnen vertrouwen:

• Als het op een lijst staat van certificaten die u impliciet vertrouwt
• Als het in staat is te bewijzen dat het wordt vertrouwd door de beheerder van een van de certificaten op de bovenstaande lijst

Het eerste criterium is gemakkelijk te controleren. Uw browser heeft een vooraf geïnstalleerde lijst van vertrouwde SSL-certificaten van certificeringsautoriteiten (CA’s) die u kunt bekijken, toevoegen en verwijderen. Deze certificaten worden gecontroleerd door een gecentraliseerde groep van (in theorie, en over het algemeen in de praktijk) extreem veilige, betrouwbare organisaties zoals Symantec, Comodo en GoDaddy. Als een server een certificaat uit die lijst laat zien, weet je dat je ze kunt vertrouwen.

Het tweede criterium is veel moeilijker. Het is gemakkelijk voor een server om te zeggen “eh ja, mijn naam is eh, Microsoft, u vertrouwt Symantec en eh, ze vertrouwen me helemaal, dus het is allemaal cool.” Een enigszins slimme klant zou dan aan Symantec kunnen vragen: “Ik heb hier een Microsoft die zegt dat u hen vertrouwt, is dat waar?” Maar zelfs als Symantec zegt “ja, we kennen ze, Microsoft is legitiem”, dan weet je nog steeds niet of de server die beweert Microsoft te zijn ook werkelijk Microsoft is of iets veel ergers. Dit is waar digitale handtekeningen om de hoek komen kijken.

3.2 Digitale handtekeningen

Zoals reeds opgemerkt, hebben SSL certificaten een bijbehorend publiek/privaat sleutelpaar. De openbare sleutel wordt verspreid als onderdeel van het certificaat, en de particuliere sleutel wordt ongelooflijk veilig bewaard. Dit asymmetrische sleutelpaar wordt gebruikt in de SSL-handdruk om een verdere sleutel uit te wisselen voor beide partijen om gegevens symmetrisch te coderen en te decoderen. De cliënt gebruikt de openbare sleutel van de server om de symmetrische sleutel te versleutelen en veilig naar de server te zenden, en de server gebruikt zijn particuliere sleutel om deze te ontsleutelen. Iedereen kan coderen met de publieke sleutel, maar alleen de server kan decoderen met de private sleutel.

Het omgekeerde geldt voor een digitale handtekening. Een certificaat kan door een andere autoriteit worden “ondertekend”, waarbij de autoriteit in feite verklaart: “wij hebben geverifieerd dat de beheerder van dit certificaat ook het eigendom (domein) controleert dat op het certificaat wordt vermeld”. In dit geval gebruikt de autoriteit haar private sleutel om (in grote lijnen) de inhoud van het certificaat te versleutelen, en deze versleutelde tekst wordt aan het certificaat gehecht als de digitale handtekening. Iedereen kan deze handtekening ontcijferen met de openbare sleutel van de autoriteit, en nagaan of dit de verwachte ontcijferde waarde oplevert. Maar alleen de autoriteit kan inhoud coderen met de private sleutel, en dus kan alleen de autoriteit een geldige handtekening maken.

Dus als er een server langskomt die beweert een certificaat voor Microsoft.com te hebben dat is ondertekend door Symantec (of een andere CA), dan hoeft je browser hem niet op zijn woord te geloven. Als het legitiem is, zal Symantec hun (ultrageheime) private sleutel gebruikt hebben om de digitale handtekening van het SSL-certificaat van de server te genereren, en dus kan uw browser hun (ultrapublieke) publieke sleutel gebruiken om te controleren of deze handtekening geldig is. Symantec zal stappen hebben ondernomen om er zeker van te zijn dat de organisatie waarvoor ze ondertekenen werkelijk eigenaar is van Microsoft.com, en aangezien uw klant Symantec vertrouwt, kan hij er dus zeker van zijn dat hij werkelijk met Microsoft Inc. praat.

3.3 Zelfondertekening

Merk op dat alle root-CA-certificaten “zelfondertekend” zijn, wat betekent dat de digitale handtekening wordt gegenereerd met de eigen privésleutel van het certificaat. Er is niets intrinsiek speciaals aan het certificaat van een root CA – u kunt uw eigen zelfondertekend certificaat genereren en dit gebruiken om andere certificaten te ondertekenen als u dat wilt. Maar aangezien uw willekeurig certificaat in geen enkele browser ergens als CA vooraf is geladen, zal geen enkele browser u vertrouwen om uw eigen of andere certificaten te tekenen. U zegt in feite “eh ja, ik ben helemaal Microsoft, hier is een officieel certificaat van identiteit uitgegeven en ondertekend door mijzelf,” en alle goed functionerende browsers zullen een zeer enge foutmelding geven als reactie op uw onbetrouwbare geloofsbrieven.

Dit legt een enorme last op alle browser- en OS-uitgevers om alleen brandschone root-CA’s te vertrouwen, omdat dit de organisaties zijn waarop hun gebruikers uiteindelijk vertrouwen om websites te controleren en certificaten veilig te houden. Dit is geen gemakkelijke taak.

3.4 Wat vertrouwt u?

Het is interessant om op te merken dat uw client technisch gezien niet probeert te verifiëren of hij de partij die hem een certificaat heeft gestuurd wel of niet moet vertrouwen, maar of hij de openbare sleutel in het certificaat wel of niet moet vertrouwen. SSL-certificaten zijn volledig open en openbaar, dus elke aanvaller zou het certificaat van Microsoft kunnen pakken, het verzoek van een klant aan Microsoft.com kunnen onderscheppen en het legitieme certificaat aan de klant kunnen voorleggen. De cliënt zou dit accepteren en vrolijk de handdruk beginnen. Wanneer de cliënt echter de sleutel versleutelt die zal worden gebruikt voor de feitelijke gegevensversleuteling, zal hij dit doen met de echte openbare sleutel van Microsoft uit dit echte certificaat. Aangezien de aanvaller niet beschikt over de private sleutel van Microsoft om deze te ontcijferen, zit hij nu vast. Zelfs als de handshake is voltooid, kunnen zij de sleutel nog steeds niet ontcijferen, en kunnen zij dus ook geen van de gegevens ontcijferen die de client naar hen stuurt. De orde blijft gehandhaafd zolang de aanvaller de privésleutel van een vertrouwd certificaat niet in handen heeft. Als de cliënt op een of andere manier wordt misleid tot het vertrouwen in een certificaat en publieke sleutel waarvan de aanvaller de private sleutel controleert, beginnen de problemen.

4.1 Kan een coffeeshop mijn HTTPS verkeer over hun netwerk controleren?

Nee. De magie van cryptografie met openbare sleutels betekent dat een aanvaller elke byte kan bekijken van de gegevens die worden uitgewisseld tussen uw client en de server en nog steeds geen idee heeft wat u tegen elkaar zegt, behalve ongeveer hoeveel gegevens u uitwisselt. Je normale HTTP verkeer is echter nog steeds erg kwetsbaar op een onveilig wi-fi netwerk, en een zwakke website kan het slachtoffer worden van een willekeurig aantal workarounds die je op de een of andere manier misleiden om HTTPS verkeer over gewone HTTP te sturen of gewoon helemaal naar de verkeerde plaats. Zelfs als een inlogformulier bijvoorbeeld een combinatie van gebruikersnaam en wachtwoord via HTTPS verstuurt, als het formulier zelf onveilig via HTTP wordt geladen, kan een aanvaller de HTML van het formulier op weg naar uw machine onderscheppen en wijzigen om de inloggegevens naar zijn eigen eindpunt te sturen.

4.2 Kan mijn bedrijf mijn HTTPS-verkeer via hun netwerk controleren?

Als u ook een machine gebruikt die door uw bedrijf wordt beheerd, dan ja. Vergeet niet dat aan de basis van elke vertrouwensketen een impliciet vertrouwde CA staat, en dat een lijst van deze autoriteiten in uw browser is opgeslagen. Uw bedrijf zou hun toegang tot uw machine kunnen gebruiken om hun eigen zelfondertekende certificaat aan deze lijst van CA’s toe te voegen. Ze zouden dan al uw HTTPS-verzoeken kunnen onderscheppen en certificaten kunnen presenteren die beweren de juiste website te vertegenwoordigen, ondertekend door hun nep-CA en daarom onbetwistbaar vertrouwd door uw browser. Aangezien u al uw HTTPS-verzoeken zou versleutelen met de publieke sleutel van hun onbetrouwbare certificaat, zouden zij de overeenkomstige private sleutel kunnen gebruiken om uw verzoek te ontsleutelen en te inspecteren (zelfs te wijzigen), en het dan naar de beoogde locatie te sturen. Waarschijnlijk doen ze dat niet. Maar ze zouden het kunnen.

Incidentally, dit is ook hoe je een proxy gebruikt om de anders ontoegankelijke HTTPS-verzoeken van een iPhone-app te inspecteren en te wijzigen.

4.3 Dus wat is er gebeurd met Lavabit en de FBI?

Lavabit was de superveilige e-mailprovider van Edward Snowden tijdens de NSA-lekken waanzin van 2013. Zoals we hebben gezien, kon de FBI met geen enkele standaardhack de gegevens zien die onderweg waren tussen Lavabit en zijn klanten. Zonder de private sleutel voor het Lavabit SSL-certificaat was het agentschap de pineut. Een behulpzame Amerikaanse rechter vertelde de oprichter van Lavabit, Ladar Levison, echter dat hij deze sleutel moest overhandigen, waardoor de FBI in feite vrij spel kreeg om naar hartelust in het verkeer te snuffelen. Levison deed een dappere poging om tijd te rekken door de 2.560 karaktersleutel te overhandigen in 11 gedrukte pagina’s van 4-punts letter, maar hij kreeg een bevel dat hem verplichtte om de sleutel in een bruikbaar formaat te overhandigen of een boete van $5.000 per dag tot hij dat deed.

Toen hij eenmaal voldeed, trok GoDaddy, de CA van Lavabit, het certificaat in, nadat het (terecht) als gecompromitteerd werd beschouwd. Dit voegde het Lavabit-certificaat toe aan een Certificate Revocation List (CRL), een lijst van in diskrediet gebrachte certificaten die klanten niet langer mogen vertrouwen om een veilige verbinding tot stand te brengen. Gecompromitteerde, zelfondertekende of anderszins onbetrouwbare certificaten zorgen ervoor dat browsers een grote rode foutmelding tonen en verdere handelingen van de gebruiker ontmoedigen of zelfs helemaal verbieden. Helaas zullen browsers een kapot certificaat blijven vertrouwen totdat ze de nieuwste updates van de CRL hebben opgehaald, een proces dat in de praktijk blijkbaar onvolmaakt is.

Conclusie

HTTPS is niet onbreekbaar, en het SSL-protocol moet voortdurend evolueren naarmate nieuwe aanvallen ertegen worden ontdekt en onderdrukt. Maar het is nog steeds een indrukwekkend robuuste manier om geheime gegevens over te brengen zonder je zorgen te maken over wie je berichten ziet. Er zijn natuurlijk vele implementatiedetails die hier niet vermeld worden, zoals het exacte formaat en de volgorde van de handshake berichten, verkorte handshakes om recente sessies op te pikken zonder opnieuw te moeten onderhandelen over sleutels en cipher suites, en de talrijke verschillende encryptie opties die in elke fase beschikbaar zijn. Het belangrijkste om te onthouden is dat HTTPS weliswaar gegevens veilig houdt op weg naar hun bestemming, maar dat het je (als gebruiker of ontwikkelaar) op geen enkele manier beschermt tegen XSS of database lekken of andere dingen die ’s nachts gebeuren. Wees blij dat het je rug dekt, maar blijf waakzaam. In de onsterfelijke woorden van Will Smith: “Walk in shadow, move in silence, guard against extra-terrestrial violence.”

Als je dit leuk vond, zul je waarschijnlijk genieten van mijn post waarin de details van 2015’s FREAK kwetsbaarheid in SSL worden uitgelegd.