SSL (certificaat makkelijk te kopieren)

[maxjuh]

Ik weet de basis van encryptie en hoe SSL ongeveer werkt maar ik zit met een brandende vraag waar ik nergens het antwoord op kan vinden.

Stel voor dat de website x.com is en https gebruikt. Op een gegeven moment dan verstuurd x.com zijn certificaat en controleer je deze. Nu is he zo dat niemand anders zich voor kan doen als zijnde x.com omdat de server een certificaat gebruikt. Naar mijn weten wordt dit certificaat gecontroleerd door zelf de hash waarde van het certificaat te berekenen, vervolgens deze berekende hash waarde te vergelijken met de al aanwezige hash waarde in het certificaat. Daarvoor moet eerst de al aanwezige hash waarde gedecrypt worden met de public key van de CA (Certificate authority, zoals VeriSign).

Nou zou ik zeggen dat het nog steeds mogelijk is om je voor te doen als x.com. Omdat je het certificaat van x.com krijgt als je een connectie legt met die website kan je die dus misbruiken. Als je dan een fake x.com website opzet en iemand maakt een connectie stuur je keurig het certificaat mee dat je eerder van de officiële x.com gekregen hebt.

Het enigste waar ik nog aan zou kunnen denken als check is dat er gekeken wordt naar het Common Name (CN) veld en het ip-adres dat hieruit volgt via DNS te vergelijken met het daadwerkelijke ip-adres van de TCP connectie. Ook dat kan natuurlijk weer omzeild worden door een DNS server te vervuilen, maargoed gaat het nu niet om.

Ik zie vast iets over het hoofd, maar wat?

[LuckY]

offtopic:
Maak naar mij even 10% over als je een postbank site vervalst

[ Voor 7% gewijzigd door LuckY op 01-05-2008 16:29 ]

[Voutloos]

maxjuh schreef op donderdag 01 mei 2008 @ 16:26:
Als je dan een fake x.com website opzet en iemand maakt een connectie stuur je keurig het certificaat mee dat je eerder van de officiële x.com gekregen hebt.

Daar schiet je dus niets mee op (als je uberhaupt al zo ver komt)
Want wat gebeurd er dan? Clients sturen hun requests geëncrypt met de public key uit dat certificaat. En de private key heb jij nog steeds niet, dus je kan er alsnog niets mee.

[ Voor 3% gewijzigd door Voutloos op 01-05-2008 16:35 ]

[Verwijderd]

Je ziet over het hoofd dat de client de requests versleutelt met de public key (het certificaat) van x.com. Alleen als de server over de private key beschikt kan hij het versleutelde bericht ontcijferen.

Het is wel makkelijk om een domeinnaam te registreren dat erg op een bestaande domeinnaam lijkt, en dan een certificaat aan te vragen bij een partij waarvan de CA root certificate standaard wijd verspreid is. Een verisign certificaat kan daarvoor voldoen.

De meeste klanten zien wel "een" beveiligde verbinding, maar kijken niet waarmee ze verbinden.

[CyBeR]

maxjuh schreef op donderdag 01 mei 2008 @ 16:26:
Ik zie vast iets over het hoofd, maar wat?

Even zeer versimpeld, met een SSL-certificaat stuur je alleen een public key op. Dus inderdaad: die kan ik rustig van x.com kopieren en me dan voordoen als x.com. Maar daar blijft het ook bij: zodra de client data naar me wil sturen (dwz, een session key wil negotiaten) loopt 't geheel spaak want om dat de decrypten heb ik de private key nodig, en die heb ik niet want die wordt absoluut niet meegestuurd. Dat is het basisprincipe achter asymmetrische encryptie. Mocht ik nu echter die server van x.com haxx0ren, dan kon ik wellicht de private key ook kopieren (99 uit 100 keer is die niet voorzien van een wachtwoord) en dan kan ik me echt voordoen als x.com. (Totdat dat certificaat gerevoked wordt.)

Oh, en dat certificaat is op zich gewoon een unencrypted stukje data volgens een bepaald formaat (X509) waar in o.a. staat dat ik x.com ben, welke persoon of organisatie daarachter zit en wat de public key is. Dat stukje data is vervolgens gesigned met de private key van een Certificate Authority (CA), waarvan de public key in je OS of browser zit zodat jij weet dat dat stukje data niet aangepast is en ik dus echt x.com ben. Hoe dat signen gaat is implementatiespecifiek, maar meestal wordt er een hash gemaakt van de data, die wordt ge-encrypt met een private key en iedereen die dat wil verifieren kan aan de hand van de public key die hash decrypten, de eigenlijke data zelf ook hashen en vervolgens bezien of die hashes overeen komen.

[ Voor 30% gewijzigd door CyBeR op 01-05-2008 17:38 ]

[Equator]

Het antwoord van CyBeR en Cheatah kom je al heel ver mee.

Ik heb er zelf enige tijd geleden nog een blog over gepost.. Dat is dan basis PKI/asymmetrische/symmetrische encryptie, dus niet heel erg diep. (http://equator.tweakblogs.net/blog/109/pki-(deel-1).html)

Verder is dit meer iets voor B&V

[maxjuh]

Het is mij ook zeker duidelijk geworden . thx all!. Met asymmetrische en symmetrische ben ik wel bekend maar het gene wat ik dus nog miste was dat de public key van het certificaat gebruikt wordt in het proces.

Erger me daar dan wel is aan als je dingen worden uitgelegd in een hoor college of boek dat ze teveel aan de oppervlakte blijven en ik me dus gelijk ga afvragen waarom het dan bijvoorbeeld zo makkelijk is te omzeilen (met dan meestal wel de aanname dat ik vast iets mis van het plaatje maar wil dan wel weten wat). Natuurlijk kan je niet altijd alles uitvoerig gaan behandelen, zou ik zelf ook niet echt vrolijk van worden (to much information).