Zusätzliche Sicherheit durch SSL-Login/verschlüsselte Kommunikation?

[TotalEclipse]

Hi zusammen,

auch wenn man das als internetaffiner Nutzer definitiv wissen sollte, hab ich mir gerade paar Gedanken zu SSL-Logins (vs. nichtverschlüsselte Logins) gemacht, und bei den eigentlich zentralen Frage bin ich unsicher:

Ein SSL-Login schützt mich nur davor, dass jemand, der NICHT Zugriff auf alle von mir und zu mir gesendeten Pakete hat, die Kommunikation ab meinem Netzwerkport bis zum Servernetzwerkport mitliest, richtig? Denn wer den Handshake am Anfang mitliest, der hat ja alles zur Verfügung, was zur Entschlüsselung benötigt wird...

Im Gegenzug ist meine Kommunikation mit dem Server nicht mehr einfach zu entschlüsseln, wenn der Handshake nicht mitgelesen wurde und sich keine Schadsoftware auf dem Server oder auf meinem Rechner befindet, richtig?

In Bezug auf PRISM & Co:
Allgemein ist jede Art der Kommunikation einfach mitzulesen, solange die Handshake-Pakete mitgelesen werden, richtig? D.h. selbst surfen über TOR z.B. ist nur dann sicher, wenn keine Daten auf dem Weg zum ersten Server abgegriffen werden (und dieser erste Server natürlich nicht kompromittiert ist), oder?

Was ist dann überhaupt noch ein Szenario, in dem verschlüsselt kommuniziert/gesurft werden kann?

 

[marcol1979]

Da die private Keys nicht übermittelt werden sollte das abfangen der Handshake Pakete nichts nützen.
Sonst wäre jeder Verschlüsslung, SSL/TLS, die ganzen VPN Verschlüsslungen nutzlos.
Aber unsere Stasi 2.0 Wächter halten ja Terroristen auch für dämlich, die werden wohl unverschlüsselt sich eMails schicken.

 

[TotalEclipse]

Laut dem Schaubild wird der eigentliche Key aus den beiden (im Klartext übermittelten) Zufallszahlen RN_S und RN_C, sowie dem premaster secret key PMS (per Server public-key verschlüsselt übermittelt). Edit: Ach Moment: Das ist genau die Stelle, an der eben nicht jeder mitlesen kann, weil sich das der Server nur mit seinem private-Key entschlüsseln kann, oder? Edit Ende.
Lese ich all diese Informationen mit, kann ich mir doch MS auch ausrechnen, oder nicht?

Die private-Keys dienen doch hier nur der Authentifizierung.

Edit: Nö, die wären schon sinnvoll, der Rest der Kommunikation ist doch sicher verschlüsselt (sofern das Verfahren nicht gebrochen wird). Außerdem können beide Kommunikationspartner sicher sein, mit dem Richtigen zu kommunizieren.

D.h. aber, dass theoretisch jegliche SSL-verschlüsselte Kommunikation sicher ist, sofern es das verwendete Verschlüsselungsverfahren ist, oder?

 

[Krik]

Ja, SSL ist schon ziemlich sicher. Die Stärke der Verschlüsselung hängt von der Schlüssellänge und der Stärke des Verfahrens ab.
Da Man-in-the-middle-Angriffe hier aussichtslos sind, versucht man mittlerweile die Endpunkte der Verbindung (Client & Server) zu knacken.

TL;DR
Die Schlüssellängen bei Zertifikaten bewegen sich normalerweise im Bereich 1024 bis 4096 Bits, was quasi einem Passwort mit 128 bis 512 Zeichen Länge entspricht. Schon bei 128 Zeichen gibt es 10^308 mögliche Kombinationen. Das schaffen selbst Supercomputer per Bruteforce nicht innerhalb einer Dekade zu knacken.
Bis jetzt ist keine Schwachstelle im Verfahren bekannt geworden. Durch diverse mathematische Besonderheiten werden im Verfahren Primzahlen verwendet. Da es die nicht so häufig gibt, versucht man da rüber ranzukommen. Allerdings haben diese Primzahlen mal eben 100 Stellen. Auch hier brauchen Computer mehrere Jahre, wenn nicht gar Jahrzehnte, um sie 1. auszurechnen und 2. die verschlüsselten Nachrichten damit zu bruteforcen.

 

[Toecutter]

Verschlüsselung zu knacken ist immer ein Wettrennen, siehe z.B. http://www.heise.de/security/meldung/Google-erneuert-SSL-Zertifikate-1869150.html. Letzlich geht es halt darum den Aufwand für Brute-Force-Attacken unattraktiv hoch zu machen.

Bei der Liste der Primzahlen kann ich mir gut vorstellen, daß man die auch einfach irgendwo passend runterladen kann.

 

[Daaron]

Eine Liste aller Primzahlen bis zur x-wievielten Stelle würde dir nichts nutzen. Ein Beispiel, wie asymmetrische Verschlüsselung funktioniert: http://de.wikipedia.org/wiki/Elgamal-Verschlüsselungsverfahren