Hoe veilig is SSL?

[Verwijderd]

bij alle netwerk applicaties die veilig moeten zijn word tegenwoordig SSL gebruikt om de communicatie te encrypten, maar ik vraag me af hoe veilig dit nou eigenlijk is. Hoe is het mogelijk om zo te communiceren dat een 3e partij (bijv isp of sniffer) hier nix mee kan?
Ik heb het een en ander gegoogled, maar lange documenten met technische specificates kan ik niet zoveel mee. op deze site staat dat de server een digital certificate (=encryptie algoritme neem ik aan) heeft, hij deze aan de client doorstuurt, de client een unieke session key (=weer een encryptie algoritme?) aanmaakt, en deze encrypted met de eerdere session key overstuurt zodat ze deze key gaan gebruiken om de rest van de communicatie te encrypten.
Maar stel dat een hacker de boel loopt te sniffen, dan kan hij toch ook het 'digitale certificaat' sniffen, zodat hij vervolgens zelf ook achter de session key kan komen, en als nog de hele shit af te luisteren? Ik bedoel, als de server en client in staat moeten zijn elkaars encrypted data te decrypten, alleen met behulp van eerder uitgewisselde certificaten/algoritmes/etc dan moet iemand die de volledige communicatie meegeluisterd heeft dat toch ook kunnen?

[Duinkonijn]

als je de public of de privat key via een ander medium verstuurd
zoals post fax telefoon

dan heeft hij niks meer aan die data

verstuur je de sleutel mee in die sessies dan heb je idd kans dat het sneller mis gaat.


http://en.wikipedia.org/wiki/Secure_Sockets_Layer

[ Voor 12% gewijzigd door Duinkonijn op 10-06-2005 20:53 ]

[almar]

Duinkonijn schreef op vrijdag 10 juni 2005 @ 20:51:
als je de public of de privat key via een ander medium verstuurd
zoals post fax telefoon

dan heeft hij niks meer aan die data

verstuur je de sleutel mee in die sessies dan heb je idd kans dat het sneller mis gaat.

En hoe vaak gebeurt dat met een ssl verbinding? Maar ik geloof dat een ssl verbinding helemaal niet zo veilig is, het is alleen veiliger dan een telnet verbinding. Ik dacht dat een ssl verbinding vrij eenvoudig te kraken was.

[Duinkonijn]

denk ook meer de situatie waar in het gebruikt wordt.

als je een server snift die per etmaal 20gig trafic genereerd.

is het nog een klus om alle pakketjes behorende tot 1 persoon te vinden

[LauPro]

TCP-streams zijn anders goed te volgen hor, ze hebben volgnummers bijvoorbeeld.

[leuk_he]

Verwijderd schreef op vrijdag 10 juni 2005 @ 20:38:
Maar stel dat een hacker de boel loopt te sniffen, dan kan hij toch ook het 'digitale certificaat' sniffen, zodat hij vervolgens zelf ook achter de session key kan komen,

Nee zo werkt PK encryptie niet.... maar het is niet simpel uit te leggen.. daarom maar een link:

http://en.wikipedia.org/wiki/Diffie-Hellman

De truuk by PK encrypty is einlijk dat niet de hele sessie key wordt meegegeven. Dus de sessie key wordt op een ingewikkelde manier gecommuniceerd zodat het niet veel zin heeft te sniffen.

Men verkrijgt met sniffen uiteraard wel verkeersgegevens (hoeveel data waarheen)

gewoon sniffen werkt niet... man in the middel attacks echter wel .. kijk maar eens bij "ettercap", daar lukt het ze beveiligde communicatie (soms) af te tappen. En daar zijn ook weer methonden tegen.

[matthijsln]

Verwijderd schreef op vrijdag 10 juni 2005 @ 20:38:
Maar stel dat een hacker de boel loopt te sniffen, dan kan hij toch ook het 'digitale certificaat' sniffen, zodat hij vervolgens zelf ook achter de session key kan komen, en als nog de hele shit af te luisteren? Ik bedoel, als de server en client in staat moeten zijn elkaars encrypted data te decrypten, alleen met behulp van eerder uitgewisselde certificaten/algoritmes/etc dan moet iemand die de volledige communicatie meegeluisterd heeft dat toch ook kunnen?

SSL is gebaseerd op het principe van public key encryptie. Lees er maar eens over op http://en.wikipedia.org/wiki/Public_key_encryption.

De eerste zin geeft meteen het unieke van PKE weer: PKE maakt het mogelijk om gebruikers veilig te laten communiceren zonder dat vooraf een gezamelijke geheime sleutel hoeft te worden afgesproken.

SSL maakt van PKE gebruik om juist wel een geheime sleutel over te sturen (de zogenaamde session key). Met deze sleutel wordt de echte inhoud van de sessie (bijvoorbeeld een HTML pagina die de server verstuurd of het wachtwoord dat je hebt ingevuld op een formulier op een webpagina) versleuteld. Dit gebeurt bijvoorbeeld met een algoritme zoals Rijndael, waarvoor dezelfde sleutel wordt gebruikt voor encryptie en decryptie. Deze sleutel is echter niet af te luisteren omdat public key encryptie is gebruikt om deze uit te wisselen. Dit wordt gedaan omdat het veel minder processorkracht kost om het hele bericht met een symmetrisch encryptiealgoritme (zoals Rijndael, DES, etc.) te versleutelen dan het hele bericht met public key encryptie zoals RSA te versleutelen.

Dus om je vraag te beantwoorden, ja SSL is veilig. Het kan ook niet zomaar even gekraakt worden. Wel moet je er voor zorgen dat de public key die wordt gebruikt echt van degene is met wie je wilt communiceren. Hiervoor is een public key infrastructure opgezet: http://en.wikipedia.org/wiki/PKI

[serkoon]

Sjah, SSL is in theorie wel veilig, maar in de praktijk heeft het eigenlijk weinig nut: een MITM-attack is vrij simpel uit te voeren, met bijv. de dsniff tools.

Wat een MITM-attack inhoudt, is dat de SSL-sessie tussen jou en de bank verandert in tussen jou en de MITM en de MITM en de bank. SSL werkt met certificaten die niet zomaar 123 volledig te vervalsen zijn: een bank zal certificaten hebben die gesigned zijn met een root certificate van een of andere certificaten-verkoop-partij zoals bijv. Verisign. Je browser kan (omdat info over die root certificates in je browser ingebakken is) het certificaat van de bank checken op correctheid.

Maar.. een aanvaller kan simpelweg zelf een certificaat genereren met correct lijkende gegevens (naam van bedrijf enzo). Het certificaat zal dan niet gesigned zijn met een Verisign-certificaat en heeft natuurlijk ook een andere keyprint dan het origineel, maar lijkt wel correct. Je browser zal, indien het echte certificaat gecached is, wel een waarschuwing geven dat het valse certificaat niet geldig is. Klinkt veilig, dus

Nu waarom ik SSL in de praktijk toch niet veilig vind. Het grootste gedeelte van de gebruikers hebben geen idee van hoe SSL-certificaten werken en weten dus ook totaal niet dat een pop-up over een 'ongeldig' certificaat boeit en zullen dus in veel gevallen gewoon op 'Ok' klikken. Iets bedrevener gebruikers zullen misschien het certificaat nog ff checken (die vrij echt lijkt) en klikken ook op 'Ok'. Zolang er geen reverse-check op het gebruikte certificaat zit, dus dat de banksite kan checken of de gebruiker inderdaad het juiste certificaat gebruikt bij de communicatie, kun je haast net zo goed geen SSL doen. Uiteraard helpt het wel tegen simpelweg afluisteren.Maarja, als je kunt afluisteren kun je meestal ook gewoon traffic aanpassen en dus een MITM-attack uitvoeren..

[leuk_he]

serkoon schreef op zaterdag 11 juni 2005 @ 14:47:

Maar.. een aanvaller kan simpelweg zelf een certificaat genereren met correct lijkende gegevens (naam van bedrijf enzo). Het certificaat zal dan niet gesigned zijn met een Verisign-certificaat en heeft natuurlijk ook een andere keyprint dan het origineel, maar lijkt wel correct. Je browser zal, indien het echte certificaat gecached is, wel een waarschuwing geven dat het valse certificaat niet geldig is. Klinkt veilig, dus

Och... ook correcte gesignde documenten moet je met een korreltje zout nemen:
http://www.eweek.com/article2/0,1759,1767871,00.asp

verisign maakt zich er soms ook wel vanaf. en je kunt ze er niet op aanspreken. Neem nu ook de fout uitgegeven microsoft certificaten. wie weet hoe vaak zoiets vaker is gebeurt.

[Verwijderd]

Move NT > BV

[frickY]

Verisign is behoorlijk strict met het uitgeven van haar certificaten hoor.
Je dient je uitvoerig als eigenaar van een domein te identificeren om een certificaat op naam van dat domein te krijgen. Heb het helaas zelf mogen meemaken hoe stug die procedure is.

Natuurlijk kun je zelf een certificaat maken op je domeinnaam. Browsers zien het ondertekenende resultaat echter niet als trusted, en zullen waarschuwen voor de betrouwbaarheid van het certificaat.

[Dennis]

frickY schreef op zaterdag 11 juni 2005 @ 17:16:
Verisign is behoorlijk strict met het uitgeven van haar certificaten hoor.
Je dient je uitvoerig als eigenaar van een domein te identificeren om een certificaat op naam van dat domein te krijgen. Heb het helaas zelf mogen meemaken hoe stug die procedure is.

Natuurlijk kun je zelf een certificaat maken op je domeinnaam. Browsers zien het ondertekenende resultaat echter niet als trusted, en zullen waarschuwen voor de betrouwbaarheid van het certificaat.

Tja het maakt natuurlijk ook uit waar je het voor gebruikt . Voor sommige dingen hoeft SSL alleen maar als extraatje te dienen. Overigens, als je de certificaten van elkaar weet en je hebt aan beide zijden een certificaat lijkt een MITM-attack me erg lastig.

offtopic:
Hallo frickY!

[Verwijderd]

oke oke met die certificaten zal het allemaal wel, ik vind die ict-beeldspraak altijd maar beetje vaag (geef gewoon de technische term, wat moet ik me in godsnaam voorstellen met een gesigneerd certificaat ) maar wat ik me dus vooral afvroeg is hoe het mogelijk is encrypted te communiceren zonder dat je van te voren een key hebt afgesproken. En nog steeds snap ik dit niet helemaal Met dat a-symetric-public-key verhaal:

Here's a more general description of the protocol:

Alice and Bob agree on a finite cyclic group G and a generating element g in G. (This is usually done long before the rest of the protocol; g is assumed to be known by all attackers.) We will write the group G multiplicatively.
Alice picks a random natural number a and sends g^a to Bob.
Bob picks a random natural number b and sends g^b to Alice.
Alice computes (g^b)^a.
Bob computes (g^a)^b.

maar als G 'bekend' is, en g^a word gesnift, dan is a toch ook terug te rekenen?

[ Voor 6% gewijzigd door Verwijderd op 11-06-2005 23:24 ]

[Bor]

Verwijderd schreef op zaterdag 11 juni 2005 @ 23:19:
oke oke met die certificaten zal het allemaal wel, ik vind die ict-beeldspraak altijd maar beetje vaag (geef gewoon de technische term, wat moet ik me in godsnaam voorstellen met een gesigneerd certificaat ) maar wat ik me dus vooral afvroeg is hoe het mogelijk is encrypted te communiceren zonder dat je van te voren een key hebt afgesproken. En nog steeds snap ik dit niet helemaal Met dat a-symetric-public-key verhaal:

maar als G 'bekend' is, en g^a word gesnift, dan is a toch ook terug te rekenen?

Nee, dat komt omdat je met gigantisch grote priemgetallen werkt. Er is geen wiskundige methode die dat efficient kan doen.

[Verwijderd]

Bor de Wollef schreef op zaterdag 11 juni 2005 @ 23:22:
[...]
Nee, dat komt omdat je met gigantisch grote priemgetallen werkt. Er is geen wiskundige methode die dat efficient kan doen.

mijn rekenmachientje is daar anders verdomt goed in... Maar stel dat er een algoritme gebruikt wordt dat idd niet terug te rekenen is... dan heeft de andere partij er toch ook nix aan?

[ Voor 18% gewijzigd door Verwijderd op 11-06-2005 23:26 ]

[Verwijderd]

Verwijderd schreef op zaterdag 11 juni 2005 @ 23:25:
mijn rekenmachientje is daar anders verdomt goed in... Maar stel dat er een algoritme gebruikt wordt dat idd niet terug te rekenen is... dan heeft de andere partij er toch ook nix aan?

Je rekenmachinetje kan dat ook niet hoor. Die kan het alleen omdat je met kleine getallen werkt

Dit soort functies die men gebruikt noemt men in de wiskunde eenwegsfuncties (one-way functions): functies die snel uit te rekenen zijn maar waarvan men aanneemt dat de inversie bewerking heel moeilijk is. Discrete logaritme (zoals in het stukje in jouw post) en ontbinden in priemfactoren worden als one-way functions beschouwd.
Als ik je bvb de twee priemgetallen 53 en 61 geef, dan kun jij hoogst waarschijnlijk heel snel het product maken op een klein stukje papier en kom je al snel met 3233 voor de dag. Maar als ik je 3233 geef en vraag van welke priemgetallen dat het product is zal je wel even mogen rekenen vrees ik. En bedenk dan dat computers ongeveer hetzelfde moeten doen. Alleen is een computer natuurlijk veel sneller dan een mens, vandaar dat ze dan met priemgetallen van tientallen en zelfs honderden cijfers spelen...

En de andere partij heeft er wel iets aan. Dat is juist het leuke:

Alice picks a random natural number a and sends g^a to Bob.
Bob picks a random natural number b and sends g^b to Alice.
Alice computes (g^b)^a.
Bob computes (g^a)^b.

Alice krijgt g^b en berekent (g^b)^a = g^(a*b) maar kent eigenlijk alleen g en a; Bob krijgt g^a en berekent (g^a)^b = g^(a*b) maar kent eigenlijk alleen g en b. Dus wat je hebt is dat zowel Alice als Bob iets hebben wat gelijk is (en dus kan dat worden gebruikt om info door te sturen), namelijk g^(a*b), zonder dat ze alle info daarvoor moeten vrijgeven. En zij zijn - hopelijk - ook de enigen die dat kunnen berekenen, want noch a noch b worden ooit doorgestuurd. Die blijven netjes geheim.
In theorie kun je natuurlijk altijd a of b gaan bereken uit g^a of g^b want die kan een sniffer zien. Maar dat is juist de grote moeilijkheid want da's een one-way functie inverteren...

Maar zoals ik al zei en nog eens wil benadrukken: dit alles staat of valt met de one-way functions. Als jij morgen een manier vindt om heel snel getallen te ontbinden in priemfactoren en/of discrete logaritmes door te rekenen dan heb je dé manier gevonden om zowat iedere beveiling te kraken. Als je ooit een Turing award wou...

[kris_112]

Verwijderd schreef op zaterdag 11 juni 2005 @ 23:19:
oke oke met die certificaten zal het allemaal wel, ik vind die ict-beeldspraak altijd maar beetje vaag (geef gewoon de technische term, wat moet ik me in godsnaam voorstellen met een gesigneerd certificaat ) maar wat ik me dus vooral afvroeg is hoe het mogelijk is encrypted te communiceren zonder dat je van te voren een key hebt afgesproken. En nog steeds snap ik dit niet helemaal Met dat a-symetric-public-key verhaal:

Here's a more general description of the protocol:

Alice and Bob agree on a finite cyclic group G and a generating element g in G. (This is usually done long before the rest of the protocol; g is assumed to be known by all attackers.) We will write the group G multiplicatively.
Alice picks a random natural number a and sends g^a to Bob.
Bob picks a random natural number b and sends g^b to Alice.
Alice computes (g^b)^a.
Bob computes (g^a)^b.

maar als G 'bekend' is, en g^a word gesnift, dan is a toch ook terug te rekenen?

Belangrijk detail in het stuk dat jij quote is "Alice and Bob agree on a finit cyclic group". dat wil (onder andere) zeggen dat elke berekening modulo een (bekend) getal Z wordt gedaan. Je hebt gelijk dat uit de getallen g^a en g vrij eenvoudig weer a terugberekend kan worden. Het is echter een stuk minder eenvoudig om uit g^a mod Z weer a terug te rekenen.

Verder maakt SSL volgens mij nooit gebruik van Diffie-Hellman key exchange (i.e. het door jou gequote algoritme), maar enkel van certificates. Als een bank wil dat klanten veilig met hem kunnen communiceren, doet deze hetvolgende:

1) De bank creert een public en private key.
2) De public key samen met de naam van de bank vormen het certificate
3) Verisign (i.e. een "onafhankelijke en betrouwbare" partij) ondertekent het certificate. dwz: neemt het certificate, creeert hieruit een getal waarvan iedereen kan controleren dat enkel en alleen verisign dit getal heeft kunnen maken, maar niemand anders kan het getal zelf maken.
4) de klant pakt het ondetekende certificate van de bank (via een website, een andvertentie in de telegraaf, of whatever).
5) de klant ziet dat verisign er een krabbel onder gezet heeft. Verisign is heilig, maakt nooit fouten en heeft altijd gelijk, dus de klant kan nu de key uit het certificate gebruiken om veilig met de bank te communiceren.

Zoals uit mijn poging sarcastisch te klinken over verisign misschien al blijkt: er bestaat uiteraard geen partij die iedereen blind vertrouwt als het om echt belangrijke zaken gaat. Dat is dan ook een balangrijk probleem bij dit soort dingen.

[Bor]

Verwijderd schreef op zaterdag 11 juni 2005 @ 23:25:
[...]

mijn rekenmachientje is daar anders verdomt goed in... Maar stel dat er een algoritme gebruikt wordt dat idd niet terug te rekenen is... dan heeft de andere partij er toch ook nix aan?

We hebben het over enorm grote priemgetallen. Dat kan de krachtigste mainframe hier op aarde (of gooi ze allemaal op een bult) niet. Jouw rekenmachine dus ook niet (slechts alleen met kleine getallen).