SSL-Certificaten

Door Daniël Mostertman



Je kunt deze presentatie online vinden op:

https://www.mostertman.com/p/certificaten




Eigenlijk zijn het “Public Key Certificaten”.

Vertrouwensketen

Je kunt wel zeggen dat jij “Daniël Mostertman” bent, maar hoe weet ik dat zeker?


Hiervoor wordt een vertrouwensketen (ofwel “trust chain”) gebruikt.

Immers:

Als iemand anders die je al vertrouwd een goed woordje voor iemand anders doet, ben je eerder geneigd ook met die nieuwe persoon in zee te gaan.

De browser

Je browser of besturingssysteem heeft een zogenaamde “trust store”.
Hierin komt een lijst van instanties voor die jouw browser impliciet vertrouwd.


Deze uitgevende instanties worden Certification Authorities (ofwel “CA”s) genoemd.



In je browser uit dit zich vaak als een lijst van bedrijven met meerdere uitgevende certificaten.
Één zo’n certificaat van zo’n bedrijf wordt eigenlijk al los een CA genoemd.

Root & Intermediary CA’s

Het is zéér lastig om als instantie in een “trust store” van een browser te komen, maar ook om daar weer uit te komen.

Het is daarom van groot belang dat wanneer je een CA opereert, deze veilig te stellen.



Oplossing? Je kunt weer een andere CA machtigen om deze om namens jou te laten handelen.

  • De CA in de browser die een ander machtigt wordt de “Root CA” genoemd.
  • De CA die door de “Root CA” gemachtigd is, wordt een “Intermediary CA” genoemd.


Nu een andere partij de daadwerkelijke uitgifte kan doen, kun je je “Root CA” in de kluis gooien.

Voorbeeld uit de echte wereld

Trouwen in het buitenland.

Stel je voor dat een geboorteakte een certificaat is. Als je die in het buitenland wil gaan gebruiken, dien je:

  1. Eerst bij de Gemeente een gelegaliseerde kopie te laten maken.
  2. Deze door een beëdigd vertaler te laten vertalen.
  3. De bevoegdheden te laten controleren:
    • Die van de gemeente en vertaler van het regionale kantongerecht.
    • Die van het kantongerecht bij het Ministerie van Justitie.
    • Die van Het Ministerie van Justitie bij het Ministerie van Buitenlandse Zaken.
  4. Het document naar de Ambassade van het land te brengen waarna alle voorgaande instanties nogmaals nagelopen en gecontroleerd worden.

Wie is wat in dit voorbeeld?

  1. De gelegaliseerde kopie van de geboorteakte is het certificaat.
  2. De gelegaliseerde vertaling is extra aan het certificaat toegevoegde informatie.

  3. “Intermediary CA”s:
    • De gemeente, want die heeft de gelegaliseerde kopie uitgegeven.
    • De rechtbank (die controleert de bevoegdheid van de gemeente).
    • Het Ministerie van Justitie (die controleert de rechtbank).
    • Het Ministerie van Buitenlandse Zaken (die controleert Ministerie van Justitie).
    • De Ambassade van Brazilië (die controleert het Ministerie van Buitenlandse Zaken).

  4. De “Root CA”: De overheid van Brazilië.
  5. De “Browser”: De overheidsinstantie in Brazilië die de overheid daar impliciet vertrouwd.

Wist je dat? ..

  1. XS4ALL eigenlijk vrijwel alleen maar Let’s Encrypt gebruikte?
  2. XS4ALL van oktober 2016 tot het einde volledig automatisch certificaten aangevraagd heeft?
    Bij Let’s Encrypt. 110.000 op jaarbasis (ofwel 300 per dag, ofwel 1 per 5 minuten).
  3. Ze daarmee Nederland in de top bij Let’s Encrypt gekregen hebben?
  4. Dat Let’s Encrypt vaak juist veiliger is dan partijen waar je moet betalen?

Let’s Encrypt

  • XS4ALL-achtige cultuur en zeer gedreven mensen.
  • Het is een collaborative project van de Linux Foundation.
  • Non-profit organisatie (Internet Security Research Group, ofwel ISRG).
  • Alle software is open-source op Github, en daarmee publiek auditbaar.
  • Volledig transparant en uitgebreide communicatie wanneer er iets speelt.
  • Board members van o.a. Akamai, Cisco, Mozilla, EFF, CoreOS en OVH.
  • Technical board van o.a. Akamai, EFF, Mozilla, Google, Facebook.

Hoe het niet moet…

  • DigiNotar (Root CA uitgelekt)
  • GlobalSign (OCSP-fuckup)
  • StartCom/StartSSL (was op zich goed, tot overname door WoSign hieronder)
  • Symantec (zeer slechte controles, wantrouwen door Google uitgesproken)
    • Equifax
    • GeoTrust
    • Thawte
    • VeriSign
  • WoSign (eigen audit-bureau, microsoft.com/google.com aan hoogste bieder)

Hoe het wél moet…

  • Buypass
  • COMODO (Sectigo)
    • InstantSSL
  • DigiCert
    • RapidSSL
    • Voormalige Symantec-groep (Equifax, GeoTrust, Thawte & VeriSign)
  • IdenTrust
  • GlobalSign (wanneer ze niet met OCSP gaan spelen)
  • Let’s Encrypt
  • Staat der Nederlanden
    • KPN

Een greep uit crypto: Keys

Keys (sleutels) worden o.a. gebruikt voor versleuteling (encryption) en ondertekening (signatures) van data. Ze worden vaak in paren gemaakt. Vaak wordt er gebruik gemaakt van “asymmetric keys”.

Asymmetrisch houdt in dat:

  • Data beveiligd met de private key, kan worden uitgelezen m.b.v. de public key.
  • Data beveiligd met de public key, kan worden uitgelezen m.b.v. de private key.

De tegenpool, symmetrisch:

  • Data kan worden beveiligd middels elke willekeurige key.
  • Data kan worden uitgelezen middels elke willekeurige key.

Symmetrisch heeft een bepaald nut, maar asymmetrisch biedt veel meer belangrijke voordelen.
Asymmetrisch wordt gebruikt voor o.a. SSL-certificaten, PGP en DNSSEC.

Type keys

Je kunt op verschillende manieren een key maken. De meest bekende standaarden die op dit moment actief gebruikt worden zijn RSA en Elliptic Curve.

  • RSA is vrij oud en robuust. Iedereen ondersteund het.
  • Elliptic Curve (EC) is vrij nieuw en modern. Het biedt veel voordelen t.o.v. RSA, maar wordt nog niet door alles ondersteund.

Digitaal ondertekenen

Bij ondertekening (signatures) wordt in de simpelste vorm een tekstuele waarde bepaald van de te versturen informatie. Deze waarde is vrijwel onmogelijk om na te bootsen. Als er ook maar één karakter in de originele informatie veranderd wordt, veranderd deze waarde al.

Deze waardes noemen we hashes. Deze worden berekend middels algoritmen zoals:

  • MD5
  • SHA-1
  • SHA-256
  • etc.

Zo’n zogenaamde “checksum” encrypt je vervolgens met je private key. Deze stuur je vervolgens met de informatie mee naar de ontvanger.

Ondertekening valideren

De ontvanger:

  • Gebruikt de public key om de checksum in de signature te decrypten.
  • Gebruikt hetzelfde hashing-algoritme om zelf een berekening op de informatie te doen.
  • Vergelijkt de ontvangen waarde met de zelfberekende waarde.

Komen deze overeen, dan bewijs je daarmee dat:

  1. De informatie die ontvangen is niet veranderd sinds de ondertekening met de private key.
  2. Degene die jou de informatie verstuurd heeft, controle heeft over de private key.

Bij PGP

  • Waar de public key te vinden valt:
    • Geüpload naar een keyserver waar de verzender deze kan vinden.
    • Direct van de ontvanger verkregen.
  • Wat voor soort informatie beveilig je zoal:
    • E-mail
    • Bestand
  • Transport:
    • Elk willekeurig medium.

Bij DNSSEC

  • Waar de public key te vinden valt:
    • In de DNS bij de hoger gelegen instantie (b.v. SIDN voor finalx.nl).
  • Wat voor soort informatie beveilig je zoal:
    • Signatures van DNS-records.
  • Transport:
    • DNS.

Bij SSL-certificaten

  • Waar de public key te vinden valt:
    • In het certificaat.
  • Wat voor soort informatie beveilig je zoal:
    • Alle informatie in het certificaat.
  • Transport:
    • HTTP
    • E-mail (SMTP, IMAP)
    • Meer.

Zorgen dat het werkt

Benodigdheden

  • De private key die gebruikt is voor het server-certificaat.
  • Het server-certificaat zelf.
  • Alle “Intermediary CA”-certificaten tussen het server-certificaat en het “Root CA”-certificaat.
  • Het “Root CA”-certificaat heb je nooit nodig! Deze zit in de browser.

“chain”, “fullchain”, “privkey” …

Bij Let’s Encrypt en andere partijen krijg je vaak meerdere bestanden aangeleverd:

  • cert.pem (het server-certificaat)
  • chain.pem (de intermediary certificaten)
  • fullchain.pem (een samengevoegde variant van de twee bovenstaanden, deze heb je nodig!)
  • privkey.pem (de private key die gebruikt is voor het server-certificaat)

Je gebruikt over het algemeen fullchain.pem en privkey.pem.

De intermediaries kunnen ook als bestanden aangeleverd worden wiens naam lijkt op dat van de CA, kijk in dat geval op de website van de uitgever.

Als je geen fullchain.pem hebt …

“Concat” dan het server-certificaat en alle intermediaries:

cat cert.pem chain.pem > fullchain.pem

Reload?