Werking van SSL verbinding (tussen client & server)

[Verwijderd]

Ik ben momenteel bezig met een project naar online beveiliging. Mijn opdrachtgever is van plan een extranet via de portal te koppelen, waarbij klanten dmv portal inkijk hebben in hun pensioen opbouw (er is dus ook een koppeling tussen de portal & het datawarehouse).

Mijn onderdeel is puur de beveiliging van Klant naar de portal. Ik heb redelijk wat onderzoek gedaan en ben tot een aantal mogelijke oplossingen gekomen. Een van deze oplossingen (wat naar mijn idee in iedergeval nodig is) is een SSL tunnel (certificaat).

Ik heb hier op tweakers redelijk wat gezocht naar informatie hierover maar toch kwam hier niet veel over naar voren. Met name niet over de manier hoe SSL precies eruit ziet (technisch). Vandaar dat ik dit topic met 3 redenen gemaakt heb:

1. Controleren of mijn idee over een ssl connectie klopt.
2. Achter eventuele nadelen van een ssl verbinding komen.
3. De kennis met anderen delen omdat er toch redelijk weinig op tweakers te vinden is.

Naar mijn idee wordt een ssl verbinding op de volgende manier gestart:

code:

Klant                                                 Communicatie                   Server                 TTP
Klant maakt verbinding met website -->  
                                                        Hello?     -->                         
                                                                                <--   Reageert dmv versturen (public) ID
                                                         <-- id server
Leest id+vraagt id op bij TTP-->
                                                         vraagt id van server-->  
                                                                                                             <--stuurt id van server
                                                         <-- antwoord TTP
controleerd id van server+TTP
Kloppen deze 2 id's --> SSL tunnel is tot stand gekomen. (1-way ssl authentication)

Deze manier is volgens het asymetrische encrypty. Dat wil zeggen dat de server een public key heeft en een privat key. De berichten worden door de klant verstuurd dmv de public key. De server kan dit als enige lezen door gebruik te maken van zijn privat key. De server verstuurd berichten naar de klant dmv zijn privat key, die alleen gelezen kunnen worden door de public key. Door deze methode heeft de klant de server geauthenticeerd (de server is daadwerkelijk ook echt de server, hierbij moet wel opgemerkt worden dat de klant ook het certificaat CONTROLEERD).

Een nadeel die ik hierboven heb is dat data die de server verstuurd aan de klant gelezen kan worden door iedereen die de public key heeft. Of klopt dit niet omdat er een end-to-end verbinding is tussen de server en de client, waar niemand iets van kan lezen. Daar ben ik nog niet helemaal uit.

De volgende stap is het authenticeren van de klant. Dit gebeurt volgens de symetrice methoden. Dat wil zeggen dat er 1 publieke sleutel afgesproken wordt die zowel de klant als de server gebruikt om een bericht te versturen. Het tot stand komen van deze SSL-sessie (2-way ssl authentication) gebeurd op de volgende manier:

code:

Klant                                   Communicatie                   Server
stuurt (over ssl-tunnel) een sessie key -->  
                                                  Sessie key klant -->                         
                                                                        <-- Controleerd sessie key dmv public key
                                                                        Klopt sessie key, dan is sessie
                                                                        gestart, klant geautoriseerd en
                                                                        veilige communicatie tussen klant & 
                                                                        server vind plaats.

Uiteindelijk vind er dus over een SSL-tunnel een SSL-sessie plaats. Hiermee weet de klant zeker dat hij communiceerd met de server en de server weet zeker dat hij communiceerd met de klant.

[Equator]

Ik doe even een poging

Ten eerste onderscheiden we 3 soorten encryptie

- symmetrische
- asymmetrische
- One way hasshing

Symmetrische encryptie is het versleutelen van een stukje data met een sleutel. Met dezelfde sleutel kan je de versluetelde data ook weer ontsleutelen. DES, 3DES, AES, Blowfish zijn symmetrische encryptie algoritmen

Asymmetrische Encryptie is het versleutelen van een stukje data met een bepaalde sleutel, maar deze versleutelde data is alleen te ontsleutelen met een andere sleutel. Denk hierbij aan een private sleutel en en publieke sleutel. Iets wat met de private sleutel is versleuteld kan alleen worden ontsleuteld met de publieke sleutel. Dit gebeurt er bij PKI.

One way hashing is een methode om een stukje text/data te versleutelen zonder dat dit terug te halen is. (zie reactie van Bor De Wollef hier beneden) MD5, SHA1 zijn One Way Hashing methodes.


SSL:
SSL is een manier om data veilig naar de andere kant te krijgen. Hier komt PKI om de hoek kijken.

Mogelijkheid 1:
De server heeft een server certificaat, de client geen.
De client vraagt een pagina op. De server stuurt als eerste zijn publieke sleutel op naar de client. Wanneer de client deze vertrouwd genereert de client zelf on_the_fly een sleutelpaar, en stuurt zijn eigen publieke deel naar de server.
De server genereert een SESSION_KEY en versleuteld deze met het publieke deel van de client. (let op, asymmetrische encryptie, alleen de client kan deze ontsleutelen met zijn eigen private sleutel.)
Alle data wordt verder symmetrisch versleuteld met de SESSION_KEY.

Mogelijkheid 2:
De server heeft een certificaat, en vereist dat de client deze ook heeft.
De client vraagt een pagina op. De server stuurt als eerste zijn publieke sleutel op naar de client. Wanneer de client deze vertrouwd stuurt hij zelf zijn eigen publieke sleutel op naar de server.
Wanneer de server deze vertrouwd wordt er door de server weer een session_key gegenereert.
Verder werkt het dan het zelfde als hierboven.

De private en publieke sleutels worden alleen gebruikt voor veilige sesson_key overdracht.

Wanneer ik zeg vertrouwen dan bedoel ik dit:
Een client accepteerd het publiek deel van de server wanneer deze is ondertekend door een Certificate Authority die de client vertrouwd. Denk hierbij aan verisign enzo. Het kan ook zijn dat het publieke deel is ondertekend door een eigen CA, dan krijgt de client een popup box met de vraag of hij dit certificaat wil accepteren.

Hiermee stopt deze PKI in een notedop voorlopig. Nog meer vragen

[Verwijderd]

Bedankt voor je reactie. Het is iig een duidelijke uitleg.

Als ik het goed begrijp ziet de ssl connectie er dus als volgt uit:

code:

Klant                                                 Communicatie                   Server                 TTP
Klant maakt verbinding met website -->  
                                                        Hello?     -->                         
                                                                                <--   Reageert dmv versturen (public) ID
                                                         <-- id server
Leest id+vraagt id op bij TTP-->
                                                         vraagt id van server-->  
                                                                                                             <--stuurt id van server
                                                         <-- antwoord TTP
controleerd id van server+TTP
Kloppen deze 2 id's:
dan stuurt de Client zijn public key
(encrypted via server public id) -->                  
                                                         client public id-->
                                                                                   decrypt client public id dmv eigen privat key
                                                                                   verstuurd een Session ID naar client dmv
                                                                                   <--eigen private key+client public key
                                                         <--Session key
Client decrypt de data.
Client & server communiceren
dmv afgesproken public key (symetrisch).

Het komt er dus op neer dat de client & de server alle 2 (voordat een sessie key afgesproken is) communiceren dmv hun eigen private & public key. Data wordt eerst versleuteld door de client dmv eigen Private key, vervolgens versleuteld dmv server Public key. De server decrypt de data eerst met eigen private key, en vervolgens met de clients public key.

[Equator]

Pin me er niet op vast, ik zou het even uit moeten zoeken, maar volgens mij worden de public key's un-encrypted over de lijn verstuurd.
Alleen de session_key wordt versleuteld overgestuurd.

Overigens is er nog een mogelijkheid:
En dat is dat zowel de server als de client per sessie een dynamisch keypair genereren. Echter is dit wat onveilig doordat je als "man in the middle" de public key's kan afvangen en vervangen met je eigen public key. Alle data wordt door deze man in the middle afgevangen, ontsleuteld bekeken, weer versleuteld en doorgestuurd.

Dit is mogelijk doordat er geen controle op betrouwbaarheid plaats kan vinden. Zo'n aanval heet overigens een man in the middle attack.

[webfreakz.nl]

Misschien dat je dit al gelezen hebt maar het kan natuurlijk altijd zijn dat er nog wat nuttigs tussen staat:

http://nl.wikipedia.org/wiki/SSL
http://en.wikipedia.org/wiki/SSL

[Bor]

Alsjeblieft: de RFC waarin SSL voor het grootste deel beschreven staat. Succes met je zoektocht:

http://www.llnl.gov/atp/papers/HRM/references/ssl.html

Pin me er niet op vast, ik zou het even uit moeten zoeken, maar volgens mij worden de public key's un-encrypted over de lijn verstuurd.

Dat klopt gezien de public key is ondertekend door de uitgever (CA). Elke wijziging die je hier in aanmaakt zorgt er voor dat de handtekening van de CA niet meer succesvol uit de check komt. Daarbij is het juist de bedoeling van een Public key dat je deze kunt sturen naar iemand waar je nog geen beveiligd kanaal mee hebt. Had je dat namelijk wel dan had je beter voor secret key encryptie kunnen gaan wat in veel gevallen sneller en veiliger is met dezelfde keylengte (hoewel je dit laatste eigenlijk moeilijk kunt vergelijken).

Ten eerste onderscheiden we 3 soorten encryptie

- symmetrische
- asymmetrische
- One way hasshing

One way hashing is geen encryptievorm op zich maar een techniek dat word gebruikt om een hash te verkrijgen van een groter bericht zodat het mogelijk is een kleinere hoeveelheid data te ondertekenen dan je anders moet doen (het ondertekenen van een bericht levert in veel gevallen minimaal een 2x zo grote hoeveelheid data).

[ Voor 22% gewijzigd door Bor op 15-05-2006 19:45 ]

[Equator]

Je hebt gelijk
Ik zat te twijfelen of ik hem zou noemen maar goed.

En fijn om te zien dat ik ook goed zat met mijn publieke sleutel verhaal. En de reden die je aanhaalt is natuurlijk volledig sluitend

[serkoon]

Waar met betrekking tot SSL wel rekening mee gehouden dient te worden, is dat het toch wel een paar fundamentele problemen kent:

1) Een probleem met het certificaat, zij het self-signed zijn, verkeerde hostname hebben of verlopen zijn, zal bij browsers een pop-up veroorzaken. Die pop-up wordt door de meeste mensen gewoon weggeklikt zonder dat men enig idee heeft wat het betekent. SSL-certificaten zijn dan ook voor het doeleinde van authenticatie voor de meeste mensen zinloos.
2) Wanneer een iets wantrouwender iemand het certificaat wil controleren, is er simpelweg geen goede methode dat te doen. Een self-signed certificaat hoeft niet per se vals te zijn; er zijn genoeg sites die geen fatsoenlijk certificaat hebben voor 'belangrijke' diensten. Het ontbreken van een certificate chain zegt dus weinig. De informatie in het certificaat zegt verder ook helemaal niks, dat is gewoon door de maker in te vullen. Het enige wat iets zegt is de fingerprint, maar die is niet te verifieren via een veilige, out-of-band-methode. Uiteraard is er een certificate cache, zodat wanneer een nieuw certificaat wordt aangeboden voor een hostname van een al gecachetet certificaat er ook een foutmelding volgt. Zie punt 1..
3) Browsers hebben behoorlijk uitgebreide lijsten van CA's. Deze hebben allerlei beveiligingsmaatregelen genomen om ervoor te zorgen dat er geen valse certificaten worden uitgegeven. Maar werken deze maatregelen? En, worden ze gecontroleerd? Dit blijft echter een minor issue, de eerste twee issues zijn al dermate groot dat dit punt er nauwelijks meer toe doet..

Dat gezegd hebbende, SSL voegt wel zeker iets toe: gegevens kunnen niet zo makkelijk afgeluisterd worden, en het geeft in ieder geval de mogelijkheid iets aan authenticatie van de server te doen..

[ Voor 7% gewijzigd door serkoon op 15-05-2006 20:27 ]

[Bor]

serkoon schreef op maandag 15 mei 2006 @ 20:25:

3) Browsers hebben behoorlijk uitgebreide lijsten van CA's. Deze hebben allerlei beveiligingsmaatregelen genomen om ervoor te zorgen dat er geen valse certificaten worden uitgegeven. Maar werken deze maatregelen? En, worden ze gecontroleerd? Dit blijft echter een minor issue, de eerste twee issues zijn al dermate groot dat dit punt er nauwelijks meer toe doet..

Daarvoor hebben we een certificate practice statement etc.

Wat betreft SSL een interessant artikel over SSL en het risico van - man in the middle - attacks.

[ Voor 10% gewijzigd door Bor op 15-05-2006 20:34 ]

[Verwijderd]

Ik ben vandaag bezig geweest met jullie verbeteringen. Misschien is het verstandig om mijn gemaakte activitie diagram te laten zien. Ik heb het op een website van een vriend van me gezet:
http://www.geocities.com/hamidonline83/ssl.jpg

Waar ik op dit moment nog niet helemaal uit ben is de manier waarop een tokenkey in dit proces zit. Dit zal, naar mijn idee, op de plek na de authenticatie van de server en voor het maken van een sessie key komen te staan.

In iedergeval bedankt voor alle informatie. Het is in iedergeval een stuk duidelijker geworden.

[JackBol]

Equator schreef op maandag 15 mei 2006 @ 19:27:
Pin me er niet op vast, ik zou het even uit moeten zoeken, maar volgens mij worden de public key's un-encrypted over de lijn verstuurd.

De session key wordt versleuteld met de pubkey van de server.
Deze pubkey zit in het certificaat dat je accepteert als je een ssl verbinding opzet.

[ Voor 4% gewijzigd door JackBol op 16-05-2006 15:33 ]

[Equator]

_DH schreef op dinsdag 16 mei 2006 @ 15:32:
[...]


De session key wordt versleuteld met de pubkey van de server.
Deze pubkey zit in het certificaat dat je accepteert als je een ssl verbinding opzet.

I know
Nope, met de public key van de client.. zie mijn volgende bericht..

Maar dit ging over iets anders.. Nl. de publieke sleutels die onversleuteld over de lijn gaan.
Dat de session key versleuteld wordt snap ik..

[ Voor 9% gewijzigd door Equator op 16-05-2006 16:11 ]

[Verwijderd]

_DH schreef op dinsdag 16 mei 2006 @ 15:32:
[...]


De session key wordt versleuteld met de pubkey van de server.
Deze pubkey zit in het certificaat dat je accepteert als je een ssl verbinding opzet.

Volgens mij is het zo dat:

De session key wordt versleuteld door de server, met de pubkey van de client. (server genereerd de sessie, niet client) De client kan deze sessiekey ontsleutelen dmv zijn eigen Privatekey.

[Verwijderd]

.

[ Voor 100% gewijzigd door Verwijderd op 16-05-2006 16:20 ]

[Equator]

the_dragon:
Zou je je bericht willen editten i.p.v. 2 x achter alkaar reageren.

Btw: de sesiso_key wordt gegenereerd door de server, en verzonden naar de client. Hij wordt dus versleuteld met de public key van de cleint zodat alleen de client hem kan decrypten met zijn eigen private key.

[Bor]

Misschien is dit artikel iets makkelijker / duidelijker voor je: http://eventhelix.com/RealtimeMantra/Networking/SSL.pdf

[Verwijderd]

Bor de Wollef schreef op dinsdag 16 mei 2006 @ 16:32:
Misschien is dit artikel iets makkelijker / duidelijker voor je: http://eventhelix.com/RealtimeMantra/Networking/SSL.pdf

Bedankt voor je post. Dit onderdeel is voor mij wel duidelijk. Als het goed is staat dat ook op ongeveer dezelfde manier in mijn plaatje. Of doe ik in dat plaatje toch echt iets verkeerd?

[JackBol]

Verwijderd schreef op dinsdag 16 mei 2006 @ 15:59:
[...]


Volgens mij is het zo dat:

De session key wordt versleuteld door de server, met de pubkey van de client. (server genereerd de sessie, niet client) De client kan deze sessiekey ontsleutelen dmv zijn eigen Privatekey.

Equator schreef op dinsdag 16 mei 2006 @ 16:10:

Btw: de sesiso_key wordt gegenereerd door de server, en verzonden naar de client. Hij wordt dus versleuteld met de public key van de cleint zodat alleen de client hem kan decrypten met zijn eigen private key.

nope, zo werkt het niet, sorry... hoe moet de server aan een pubkey van de client komen? De client wisselt nooit een pubkey uit. Je krijgt de pubkey van de server die je gebruikt om de symmetrische key terug te sturen naar de server. Alleen de server kan deze vervolgens decrypten.

zelfs de laatste regel van je pdfje zegt het al:

At this point, the client can send the symmetric secret key to the server after encrypting it with the public key received in the server's SSL
certificate. This encrypted secret key can only be decrypted using the private key. Thus only the server is able to decrypt the message

voor meer over SSL: sheet 74

[ Voor 24% gewijzigd door JackBol op 16-05-2006 19:08 ]