TLS Protocol, Veilig?

[Verwijderd]

Hallo,

Ik ben het TLS protocol aan het doornemen omdat ik een email-client aan het maken ben die TLS moet gaan ondersteunen. Nu weet ik ongeveer hoe verschillende codeer-algoritmes werken, verder niet in verdiept. Maar nu lees ik in de RFC dat er een sleutel voor het coderen wordt verstuurd van de server naar de client voor het coderen van de tekst. Logisch natuurlijk om de tekst te coderen. Maar dit zorgt er toch voor dat het hele 'veiligheid' idee in het water valt? Een 'man-in-the-middle' attack zou ook de sleutel krijgen en moeiteloos de tekst kunnen decoderen? Niet? Dit zal wel niet , maar zo denk ik er over... hoe wordt er dan voor gezorgd dat enkel de client en de server leesbare gegevens van de data kunnen maken die verstuurt wordt?

Alvast bedankt,

Peter

[Soultaker]

Wordt er geen certificate gebruikt om dat te voorkomen?

[DrClaw]

google is your friend.
http://www.cgisecurity.com/owasp/html/ch07s04.html

het interessante uit het bovenste plaatje is dan stap 5, waarbij een nieuwe key en een protocol worden gekozen om het vervolg van het gesprek mee te encoderen. de private gedeeltes van de keys altijd private, de public keys worden uitgewisseld.

dus, helemal aan het begin kan een man in the middle nog meeluisteren.
als de client om een keychange heeft gevraagd met zn eigen encryptieding, dan kan de man in te middle nog maar 1 helft van de conversatie volgen.
en als dan ook de server de keychange doorvoert en weer terugantwoordt, dan zijn beide zijden van de conversatie niet meer te volgen.

[Verwijderd]

Thanks voor de hulp. Snap het alleen nog niet helemaal, maar begin wel een idee te krijgen. Als er bijv. een certificate wordt verzonden van smtp.gmail.com en als ik het ontvang blijkt het in eens van smtp.gmaillll.com te komen dan zou het dus onderschept kunnen zijn.

Maar wat ik dus nog niet helemaal snap is de 'Client Handshake Response'. De client maakt een random key die de server moet gebruiken voor encryptie, deze codeerd hij eerst met de server zijn public-key en stuurt hem dan terug. Als ik het goed begrijp is dit enkel te decoderen met de server zijn private key wat er voor zorgt dat niemand anders het kan lezen. Het is dus niet mogelijk om dit te decoderen met de server zijn public key?

[Voutloos]

Iedereen kan de server z'n public key weten en iets coderen. Slechts de server weet ook de private key en kan ook decoderen.

[Verwijderd]

Aah, ok. Dat had ik eerst niet door . Maar nu snap ik het, thanks!

[The - DDD]

Het staat of valt bij het eerste certificaat wat door de server wordt verstuurd naar de client.

Een man in the middle kan wel dit certificaat versturen aan de client. Echter de client gaat met behulp van dit certificaat middels een public key (het certificaat) een encryptie uitvoeren op zijn berichten naar de server. De man in the middel zou dit bericht kunnen ontvangen, maar niet kunnen decoderen. Immers hij heeft de private key van het certificaat niet.

De client verstuurd naar de server een cypher in versleutelde vorm. De server reageert door de respons aan de client te versleutelen met dit cypher. Aangezien de man in the middle dit cypher niet kan decoderen is vanaf dat moment alles op de lijn abracadabra voor de man in the middle.

Uiteraard kan het een en ander gebruteforced worden doordat een cleartext achterhaald kan worden door zelf te connecten naar de server en de cleartext en de crypted text te loggen en als input te gebruiken voor je bruteforce algoritme. Maar dan nog steeds zou het aldoor verlopen van certificaten voldoende moeten zijn om te voorkomen dat nuttige EN!! actuele data onthuld wordt. Want meestal is enkel actuele data waardevol.