msdn.Microsoft.com. Abgerufen am 10. 06 2013 von http://msdn.microsoft.com/en-us/library/windows/desktop/aa380513%28v=vs.85%29.aspx
TLS Handshake Protocol
24 out of 32 rated this helpful - Rate this topic
The Transport Layer Security (TLS) Handshake Protocol is responsible for the authentication and key exchange necessary to establish or resume secure sessions. When establishing a secure session, the Handshake Protocol manages the following:
• Cipher suite negotiation
• Authentication of the server and optionally, the client
• Session key information exchange.
Cipher Suite Negotiation
The client and server make contact and choose the cipher suite that will be used throughout their message exchange.
Authentication
In TLS, a server proves its identity to the client. The client might also need to prove its identity to the server. PKI, the use of public/private key pairs, is the basis of this
authentication. The exact method used for authentication is determined by the cipher suite negotiated.
Key Exchange
The client and server exchange random numbers and a special number called the Pre-Master Secret. These numbers are combined with additional data permitting client and server to create their shared secret, called the Master Secret. The Master Secret is used by client and server to generate the write MAC secret, which is the session key used for hashing, and the write key, which is the session key used for encryption.
Establishing a Secure Session by Using TLS
The TLS Handshake Protocol involves the following steps:
1. The client sends a "Client hello" message to the server, along with the client's random value and supported cipher suites.
2. The server responds by sending a "Server hello" message to the client, along with the server's random value.
3. The server sends its certificate to the client for authentication and may request a certificate from the client. The server sends the "Server hello done" message.
4. If the server has requested a certificate from the client, the client sends it.
5. The client creates a random Pre-Master Secret and encrypts it with the public key from the server's certificate, sending the encrypted Pre-Master Secret to the server.
6. The server receives the Pre-Master Secret. The server and client each generate the Master Secret and session keys based on the Pre-Master Secret.
7. The client sends "Change cipher spec" notification to server to indicate that the client will start using the new session keys for hashing and encrypting messages. Client also sends
"Client finished" message.
8. Server receives "Change cipher spec" and switches its record layer security state to
symmetric encryption using the session keys. Server sends "Server finished" message to the client.
9. Client and server can now exchange application data over the secured channel they have established. All messages sent from client to server and from server to client are encrypted using session key.
Resuming a Secure Session by Using TLS
1. The client sends a "Client hello" message using the Session ID of the session to be resumed.
2. The server checks its session cache for a matching Session ID. If a match is found, and the server is able to resume the session, it sends a "Server hello" message with the Session ID.
Note If a session ID match is not found, the server generates a new session ID and the TLS client and server perform a full handshake.
3. Client and server must exchange "Change cipher spec" messages and send "Client finished"
and "Server finished" messages.
4. Client and server can now resume application data exchange over the secure channel.
SSL
SSL.de. Abgerufen am 10. 06 2013 von https://www.ssl.de/ssl.html
W i e f u n k t i o n i e r t S S L
TCP/IP:
Sicher und unsicher zugleich
SSL ist die Abkürzung für Secure Socket Layer.
Mit Layer sind die Transportschichten angesprochen, mit denen der Datenaustausch zwischen zwei Rechner bildhaft dargestellt wird. Auf der obersten Ebene sind die Anwendungen angeordnet. Ganz unten befindet sich in dem Modell die Hardware.
Im Idealfall lassen sich sieben Schichten definieren, denen sich wiederum im Idealfall jeweils ein Protokoll oder Programm zuordnen läßt. Alle Schichten tragen dazu bei, den Datenfluß zwischen den beiden Rechnern sicherzustellen.
Im wirklichen Leben paßt das Modell nicht immer so ideal. Das Übertragungsprotokoll TCP/IP deckt mit seinen zwei Komponenten (TCP und IP) mindestens vier Schichten ab. Das Protokoll ist eine Art Esperanto in der Rechnerwelt. Mit Ausnahme der Zuse-Rechner unterstützen wohl alle Rechner und Betriebssysteme TCP/IP (findige Tüftler haben sogar dem ZX81 TCP/IP beigebracht).
Es ist einfach zu implementieren, robust und sicher -- betriebssicher.
Als TCP/IP vor fast 30 Jahren erfunden wurde, stand vor allem die Absicht im Vordergrund, eine ausfallsichere und stabile Verbindung mit hoher Betriebssicherheit zu schaffen. Die Sicherheit und Authenzität der übermittelten Daten spielte eine untergeordnete Rolle.
Neue Schichten Mit TCP/IP war der Wunsch nach sicheren Verbindungen im Sinne von Datensicherheit nicht zu verwirklichen. Ohne TCP/IP gibt es kein Internet.
Die Firma Netscape löste das Problem auf folgende elegante Weise:
Die Entwickler erweiterten TCP/IP um zwei weitere Schichten.
SSL Record Protokoll SSL Handshake Protocol
Das erklärt auch die Bezeichnung »Layer«; Sie liegen funktional zwischen dem Aufgabenbereich von TCP/IP und den Anwendungen.
Diese beiden Schichten liegen bildlich betrachtet unmittelbar aufeinander und werden darum von einigen Autoren auch als eine einzige Schicht angesprochen. Obgleich sich in diesen beiden
Schichten während einer sicheren Verbindung allerlei
Software-Know-How austobt, ist sie für die angrenzenden Schichten transparent:
Weder die Anwendung (der Browser, noch die unter der dem Protokoll liegende Transportschicht bemerken das Wirken des SLL-Protokoll. Im Klartext: SSL erfordert weder Änderungen vorhandener Anwendungen noch neue Transportprotokolle.
Während einer sicheren Verbindung kommunizieren die beteiligten Rechner ausschließlich über den Mechanismus, der von SSL bereit gestellt wird. Steht die sichere Verbindung nicht zur Verfügung, schaltet sich das SSL-Protokoll aus.
Sicherheit durch SSL Das SSL-Protokoll schafft unter drei Gesichtspunkten sichere Verbindungen:
1. Die Verbindung ist im besten Sinne privat, weil ihr Inhalt nur verschlüsselt über das Netz geht.
2. Die Identität des Servers steht fest.
3. Wirkungungsvolle Algorithmen prüfen, ob die Daten vollständig und unverändert ihren jeweiligen Empfänger erreichen.
Das SSL-Protokoll wird dadurch initiiert, daß dem bekannten http ein s angehängt wird: https://www.ssl.de.
Das ist für den Browser der Anlaß, vom angesprochenen Server ein Zertifikat und seinen öffentlichen Schlüssel abzufordern. Dieser Schlüssel wird zusammen mit einer Prüfsumme und einer ID an den Browser zurückgemeldet. Diese Informationen werden von einigen wenigen Zertifizierungsfirmen errechnet. Die bekannteste ist VeriSign.
Die Firma Thawte in Südafrika gehört zu Versign.
Der Browser prüft anhand der übermittelten Daten, ob er wirklich mit dem Server verbunden ist, der in der URL angegeben ist. Ist das der Fall, gibt der Browser dem Anwender eine entsprechende
Information: Beim Internet Explorer schließt sich das Bügelschloß, der Navigator/Communicator signalisiert eine sichere Seite durch den intakten Schlüssel. Beim Firefox ist zusätzlich die ganze URL im Adress-Feld gelb unterlegt.
In der folgenden Phase verständigen sich die beiden Rechner auf einen symmetrischen Schlüssel (Session Key). Da diese Absprache in asymmetrischer Verschlüsselung vollzogen wird, ist die Sicherheit gegeben. Der Browser schickt dem Server vor dem Beginn des
eigentlichen Datenaustausches einige Testnachrichten, die der Server nur beantworten kann, wenn es wirklich der Server ist, der er zu sein vorgibt.
Zertifizierung Im Zentrum des SSL-Protokoll steht das digitale Schüsselpaar aus
öffentlichem und privaten Schlüssel des Servers sowie die ID der Zertifizierungsstelle. Jeder virtuelle Webserver benötigt ein eigenes Schlüsselpaar, weil bei der ID unter anderem der Domain-Namen einfließt.
Jede SSL-geschützte Homepage benötigt eine eigene IP-Adresse.
Provider, die auf ihren Servern tausende und abertausende Präsenzen auf einer einzigen Maschine und unter einer einzigen IP-Adresse betreiben, müssen darum beim Bereitstellen eines SSL-Zertifikates passen oder zu technischen Hilfsmittel greifen.
So funktioniert der Trick:
Der Browser des Besuchers verbindet sich nicht mit der eigentlichen Bestellseite, sondern mit einem Spezialserver (SSL-Proxy) des
Providers. Nur bis dahin ist die Verbindung dann gesichert. Der Proxy-Server leitet die Informationen des Besuchers dann auf das eigentliche Ziel, zum Beispiel eine Bestellseite, weiter. Die Weiterleitung von dem SSL-Proxy zur Bestellseite ist dann nicht mehr gesichert. Das kann schon eine Einbuße an Sicherheit bedeuten, wenn im Netz des Providers viele Kundenserver untergebracht werden, die gegebenfalls den nunmehr ungeschützen Datenstrom abhören können.
Was nicht gesichert ist: Das SSL-Protokoll sichert die Übertragung zwischen einer Domain auf einem Webserver und dem Besucher dieser Domain. Der On-Line-Kunde (Besucher) kann sich ziemlich sicher sein, daß seine
Kreditkartennummer auf dem Weg von seinem Rechner zum Server des Shop-Betreiber gegen Ausforschung geschützt ist. Was dann mit den gesichert übertragenen Daten weiter passiert, ist jenseits dessen, was durch das SSL-Protokoll geregelt ist. Für den Kunden, der im Vertrauen auf die SSL-Sicherung seine Kontoinformationen kundgibt, ist nicht erkennbar, wie der Shop-Betreiber diese Informationen weiterverarbeitet. Es sind Fälle bekannt geworden, bei denen der Datenverarbeiter die gesichert übertagenen Daten anschließend ungesichert auf dem Server gespeichert hat. Nach einem
erfolgreichen Hacker-Angriff waren die sensiblen Daten plötzlich in falschen Händen. Wir lernen daraus: SSL-Schützt nicht vor
Schlamperei und Leichtsinn.
Online per SSL
Sicher ist es, wenn der Empfänger die Daten über eine gleichfalls SSL-gesicherte Verbindung über den Browser oder per SSL-gesichertem POP3-Abruf abruft und anschließend auf dem Server löscht. Ob der Empfänger Ihrer
Kreditkartennummer das auch wirklich tut, kann er Ihnen nur selber sagen. Das SSL-Protokoll ist nur für die Anlieferung der Daten zum Server zuständig, nicht für das Ausliefern.
Das bedeutet allerdings, daß der Shop-Betreiber regelmäßig
manuell tätig werden muß. Das ist natürlich etwas unpraktisch und lästig.
Bequemer ist es, wenn die Bestellung mit den
Bezahlinformationen in einem Abwasch per eMail ins Büro kommt. Viele Shop-Betreiber und andere Nutzer von SSL-gesicherter Datenübertragung fassen die übermittelten Daten mit den anderen Bestelldaten zu einer handlichen Textdatei zusammen, die als eMail den Empfänger erreicht.
Das ist ungefähr so, als ob man seine wertvolle Fracht mit großem Aufwand durch alle Fährnisse dieser Welt geschafft hätte, um sie dann unbewacht im Wartesaal des
Hauptbahnhofes abzustellen.
PGP-verschlüsselt
Besser ist es, die gesammelten Informationen vor dem Versenden als eMail auf dem Server per PGP zu verschlüsseln.
Die so gesicherte Datei kann man getrost versenden.
Niemand, mit Ausnahme des Empfängers, kann die
Informationen lesen. Das erfordert seitens des Shop-Anbieters beziehungsweise seitens des Providers einen gewissen
Mehraufwand. Allerdings handelt es sich um einen einmaligen Vorgang. Der laufende Betrieb ist so einfach wie eMails abholen.
Wer für vertrauliche Informationen eine SSL-gesicherte Übertragung nutzt, kann leider nicht erkennen, ob dem Empfänger diese Daten solchen Mehraufwand wert sind. Wenn Shop-Betreiber die Sicherheit der Kundendaten mehr wert ist, sollten sie dieses auf der Homepage deutlich hervorheben.
Denn das SSL-Protokoll ist nur die halbe Sicherheit.
Folgende Faustregeln bieten einen ersten Anhalt, welche Sicherheit der Betreiber einer Webseite bieten kann.
Websites, die auf den Servern bekannter Massenhostern liegen, bieten wegen der dort üblichen Mehrfachnutzung der IP-Adressen nur die Nutzung eines SSL-Proxy.
Das ist ein SSL-Server, der vor alle anderen Webpräsenzen geschaltet ist. Die Daten werden nur bis zu diesem Server gesichert übertragen und dann ungesichert an die
Webpräsenz weitergereicht.
Die Fertig-Shops der Massenhoster bieten im Regelfall die Möglichkeit, die Daten per SSL-gesicherten Web-Interface abzufragen oder sich die Informationen per SSL-gesicherter eMail zusenden zu lassen.
Informationen, die auf www.ssl.de gesammelt werden, gehen dem Empfänger standardmäßig PGP-verschlüsselt zu.