2-Way SSL Implementatie, veilig?

[Kelfox]

Ik zit enige tijd met het volgende vraagstuk.

Bij het implementeren van SSL is mij duidelijk dat er server certificaten worden gebruikt om de SSL encrryptie op te zeggen op basis van PKI en validatie van de server.

Maar bij de implementatie van 2-WAY SSL, begrijp ik iets niet.

2-WAY SSL zie ik als volgt: De client stuurt een certificaat mee in het request, de server checkt of dit certificaat nog geldig is (niet expired en door een trusted CA uitgegeven en evt de thumbprint).

De vraag is: Welk certificaat zou de client moeten gebruiken in het request? Door wie is dat certificaat uitgegeven? Ik zie heel vaak dat hiervoor het server certificaat wordt gebruikt. Maar dit certificaat kan door iedereen gedownload worden, en dus ook gebruikt worden in het request.

[MainframeX]

Kelfox schreef op zaterdag 1 februari 2020 @ 02:28:

De vraag is: Welk certificaat zou de client moeten gebruiken in het request? Door wie is dat certificaat uitgegeven? Ik zie heel vaak dat hiervoor het server certificaat wordt gebruikt. Maar dit certificaat kan door iedereen gedownload worden, en dus ook gebruikt worden in het request.

De client gebruikt een certificaat welke uitgegeven is door een CA die vertrouwd is door de server. De client en server certificaten hoeven overigens niet door dezelfde CA uitgegeven te zijn. Zo lang de server en client elkaars certificaten en diens CA vertrouwen, werkt het.

Ik zie heel vaak dat hiervoor het server certificaat wordt gebruikt. Maar dit certificaat kan door iedereen gedownload worden, en dus ook gebruikt worden in het request.

Met alleen het publieke deel kan je niet namens een ander systeem met het certificaat een verzoek doen. Daarvoor zou je ook een private key nodig moeten hebben. Deze staan vaak enkel op het systeem waar het certificaat oorspronkelijk gebruikt wordt.

In traditionele one way SSL opzetten werkt het aanvragen en ingebruikname van een certificaat als volgt:

• Je genereert op de client een private key
• Vanuit deze key genereer je een CSR, oftewel een certificate signing request
• Je dient de CSR in bij de CA voor een gesigneerd certificaat. Afhankelijk van het doel en mate van veiligheid wordt getoetst of je wel of niet een certificaat namens dat CA mag hebben. Bij bijvoorbeeld Let's Encrypt kan je o.a. met een sleutel vertifieren of het aangevraagde domain wel van jou is
• Als alles goed is gegaan heb je nu een certificaat, private key en in sommige gevallen een intermediate CA cert om de chain volledig te maken. Je maakt nu deel uit van een pki

Voor 2-way SSL opzetten wijkt bovenstaande niet af. Daar zit enkel een extra verificatie stap in om te checken of de client een certificaat gebruikt uit een CA die de server vertrouwd. De werking van pki en SSL an sich blijft ongewijzigd.

[ Voor 6% gewijzigd door MainframeX op 01-02-2020 03:09 ]

[Room42]

Wat ook kan is dat de server zelf het client-certificaat uitgeeft, zodat de server 100% zeker weet dat jij (de client) een geldig certificaat hebt. De server is dan de CA.

Overigens met een snelle DDG naar 2-WAY SSL kom je al direct net zo duidelijke reacties, zoals die van @MainframeX tegen: https://stackoverflow.com...two-way-ssl-clarification

[Kelfox]

Ok, ik denk dat ik het begrijp.
Mijn missing link was denk ik: Bij het opzetten van 2-way-ssl maakt de client ALTIJD een nieuw certificaat (nieuw keypair, CSR en dan wordt dit certificaat gesigned door een CA). Het is dus niet het certificaat wat gebruikt wordt om bijvoorbeeld HTTPS te serveren. Klopt dat?


Kan dit nieuw gemaakte client-certificaat gewoon via mail uitgewisseld worden, of dient het als een wachtwoord behandeld te worden?
Als een MITM het certificaat onderschept (via email oid), dan kan dat certificaat gewoon gebruikt worden bij het opzetten van een HTTP request.

[Kelfox]

Room42 schreef op zaterdag 1 februari 2020 @ 03:41:
Wat ook kan is dat de server zelf het client-certificaat uitgeeft, zodat de server 100% zeker weet dat jij (de client) een geldig certificaat hebt. De server is dan de CA.

Ja, inderdaad. Deze manier van implementeren was me al bekend. Je dient dan wel ook een private key te krijgen van de server CA?

Room42 schreef op zaterdag 1 februari 2020 @ 03:41:
Overigens met een snelle DDG naar 2-WAY SSL kom je al direct net zo duidelijke reacties, zoals die van @MainframeX tegen: https://stackoverflow.com...two-way-ssl-clarification

Theoretisch vind ik veel voorbeelden op basis van self-signed certificaten. Ik kon echter de link nog niet goed leggen naar de praktijk.

Ik mis nog wel praktische antwoorden:

Voorbeeldje op basis van kennis die ik nu heb:

Als ik nu.nl ben als client, en wil connecteren met een webservice gehost op google.nl op basis van 2-way SSL. We gaan er even van uit dat SSL om de tunnel te maken al werkt en dat google.nl de Amazon CA en intermediates trust.

1. Nu.nl maakt eerst een keypair, en een certificaat op basis van CN=nu.nl. Nu.nl maakt een CSR en stuurt deze naar de Amazon intermediate om deze te signen?



2. google.nl krijgt het bovenstaande certificaat (zonder private key) en slaat dit op in een keystore oid om de validatie te doen van HTTP requests van nu.nl op de google.nl webservice.

Extra vraag:
Als nu.nl een nieuwe webservice gaat connecteren op basis van 2-way-ssl met tweakers.net. Kan nu.nl hetzelfde certificaat gebruiken, of moet er een nieuw certificaat gemaakt (en weer gesigned door Amazon) worden?

[Thralas]

Kelfox schreef op zaterdag 1 februari 2020 @ 10:03:
Het is dus niet het certificaat wat gebruikt wordt om bijvoorbeeld HTTPS te serveren. Klopt dat?

Meestal niet nee, hoewel het meestal theoretisch wel mogelijk is, is het niet wenselijk.

Kan dit nieuw gemaakte client-certificaat gewoon via mail uitgewisseld worden, of dient het als een wachtwoord behandeld te worden?

Het certificaat bevat enkel publieke informatie.

Als een MITM het certificaat onderschept (via email oid), dan kan dat certificaat gewoon gebruikt worden bij het opzetten van een HTTP request.

Nee, want zonder de bijbehorende sleutel kun je niet bewijzen dat het jouw certificaat is.

Kelfox schreef op zaterdag 1 februari 2020 @ 10:17:
Ja, inderdaad. Deze manier van implementeren was me al bekend. Je dient dan wel ook een private key te krijgen van de server CA?

Sleutels genereer je zelf en geef je nooit uit handen. De CA ondertekent enkel de gegevens die op je certificaat terecht komen en heeft daar jouw sleutel expliciet niet bij nodig.

Als nu.nl een nieuwe webservice gaat connecteren op basis van 2-way-ssl met tweakers.net. Kan nu.nl hetzelfde certificaat gebruiken, of moet er een nieuw certificaat gemaakt (en weer gesigned door Amazon) worden?

De grote aannamefout die je hier maakt is dat clientvalidatie in de praktijk niet op dezelfde manier als servervalidatie werkt.

Als je een server benadert heb je een domeinnaam; je controleert vervolgens of de CN van het certificaat het gebruikte domein dekt. Welke CA het certificaat uitgeeft maakt niet bijzonder veel uit, je vetrouwt erop dat de CA al heeft gevalideerd of de gebruiker van het certificaat ook eigenaar is van het domein.

Als je een client certificaat gebruikt is er echter geen CN die overeenkomt met een domeinnaam (want die heb je als client niet).

De server zal dus expliciet moeten configureren welke certificaten (en: welke CA) hij vertrouwt. Dat is hoe men TLS client authentication dus vrijwel altijd inricht: met een CA in eigen beheer, zodat je zelf controle hebt over welke certificaten er worden uitgegeven en geldig zijn.

Samengevat: in je voorbeeld vetrouwt Google dus géén Amazon CA, maar enkel een eigen specifieke CA. Het certificaat dat men daarvoor uitgeeft kunnen ze CN=nu.nl meegeven, maar dat hoeft niet - een Google-accountnaam is waarschijnlijk een betere CN.

Kun je er als server voor kiezen om een certificaat te vetrouwen dat voor 'serverdoeleinden' is uitgegven? Zeker, maar meestal kleven daar een hoop nadelen aan. Je zult ieder certificaat apart moeten vertrouwen ipv. alles onder één CA.

En het certificaat moet gemarkeerd zijn als geschikt voor client auth - zie het EKU-attribuut, maar dat is meestal zo