Transport Layer Security (TLS) und sein Vorgänger, Secure Sockets Layer (SSL), sind kryptografische Protokolle, die Nachrichtensicherheit über das Internet zur Verfügung stellen. TLS und SSL encrypt die Segmente von Netzverbindungen an der Transportschicht, mit der asymmetrischen Geheimschrift für den Schlüssel symmetrische Austauschverschlüsselung für die Gemütlichkeit und Nachrichtenbeglaubigung codieren für die Nachrichtenintegrität.

Mehrere Versionen der Protokolle sind im weit verbreiteten Gebrauch in Anwendungen wie das Webdurchsuchen, die elektronische Post, Internet faxende, sofortige Nachrichtenübermittlung und voice-over-IP (VoIP).

TLS ist IETF Standards verfolgen Protokoll, letzt aktualisiert in RFC 5246, und basiert auf früher SSL durch Netscape Kommunikationen entwickelte Spezifizierungen.

Beschreibung

Das TLS Protokoll erlaubt Client/Server-Anwendungen, über ein Netz in einem Weg zu kommunizieren, der entworfen ist, um zu verhindern, zu lauschen und herumzubasteln.

Da die meisten Protokolle entweder mit oder ohne TLS verwendet werden können (oder SSL), ist es notwendig, zum Server anzuzeigen, ob der Kunde eine TLS Verbindung macht oder nicht. Es gibt zwei Hauptweisen, das zu erreichen, eine Auswahl ist, eine verschiedene Hafen-Zahl für TLS Verbindungen (zum Beispiel Hafen 443 für HTTPS) zu verwenden. Der andere soll die regelmäßige Hafen-Zahl verwenden und den Kunden dass der Server-Schalter die Verbindung zu TLS das Verwenden eines Protokolls spezifischer Mechanismus (zum Beispiel STARTTLS für die Post und Nachrichtenprotokolle) bitten lassen.

Sobald sich der Kunde und Server dafür entschieden haben, TLS zu verwenden, verhandeln sie eine stateful Verbindung, indem sie ein handshaking Verfahren verwenden. Während dieses Händedrucks einigen sich der Kunde und Server über verschiedene Rahmen, die verwendet sind, um die Sicherheit der Verbindung zu gründen.

• Der Händedruck beginnt, wenn ein Kunde zu einem TLS-ermöglichten Server in Verbindung steht, der um eine sichere Verbindung bittet, und eine Liste von unterstützten Ziffer-Gefolgen (Ziffern und Kuddelmuddel-Funktionen) präsentiert.
• Von dieser Liste pickt der Server eine Ziffer und Kuddelmuddel-Funktion auf, dass es auch unterstützt und den Kunden von der Entscheidung benachrichtigt.
• Der Server sendet seine Identifizierung in der Form eines Digitalzertifikats zurück. Das Zertifikat enthält gewöhnlich den Servernamen, die vertraute Zertifikat-Autorität (CA) und den öffentlichen Verschlüsselungsschlüssel des Servers.
• Der Kunde kann sich mit dem Server in Verbindung setzen, der das Zertifikat ausgegeben hat (der vertraute CA als oben) und bestätigen Sie die Gültigkeit des Zertifikats vor dem Verfahren.
• Um die Sitzungsschlüssel zu erzeugen, die für die sichere Verbindung, der Kunde encrypts eine Zufallszahl mit dem öffentlichen Schlüssel des Servers verwendet sind, und das Ergebnis an den Server sendet. Nur der Server sollte im Stande sein, es mit seinem privaten Schlüssel zu entschlüsseln.
• Von der Zufallszahl erzeugen beide Parteien Schlüsselmaterial für die Verschlüsselung und Dekodierung.

Das schließt den Händedruck und beginnt die gesicherte Verbindung, die encrypted und entschlüsselt mit dem Schlüsselmaterial bis zu den Verbindungsenden ist.

Wenn irgendwelche der obengenannten Schritte scheitern, scheitert der TLS Händedruck, und die Verbindung wird nicht geschaffen.

Geschichte und Entwicklung

Sichere Netzprogrammier-API

Frühe Forschungsanstrengungen zur Transportschicht-Sicherheit haben die Anwendung, Schnittstelle programmierend (API) von Secure Network Programming (SNP) eingeschlossen, die 1993 die Annäherung erforscht hat, eine sichere Transportschicht-API zu haben, die nah Steckdosen von Berkeley ähnelt, Nachinstallation zu erleichtern, die Netzanwendungen mit Sicherheitsmaßnahmen vorher existiert.

SSL 1.0, 2.0 und 3.0

Das SSL Protokoll wurde von Netscape ursprünglich entwickelt. Version 1.0 wurde nie öffentlich veröffentlicht; Version 2.0 wurde im Februar 1995 veröffentlicht, aber "hat mehrere Sicherheitsfehler enthalten, die schließlich zum Design der SSL Version 3.0" geführt haben. SSL Version 3.0, veröffentlicht 1996, war eine ganze Umgestaltung des Protokolls, das von Paul Kocher erzeugt ist, der mit Ingenieuren von Netscape Phil Karlton und Alan Freier arbeitet. Neuere Versionen von SSL/TLS basieren auf SSL 3.0. Der 1996-Entwurf von SSL 3.0 wurde durch IETF als ein historisches Dokument in RFC 6101 veröffentlicht.

TLS 1.0

TLS 1.0 wurde zuerst in RFC 2246 im Januar 1999 als eine Steigung zur SSL Version 3.0 definiert. Wie festgesetzt, im RFC, "sind die Unterschiede zwischen diesem Protokoll und SSL 3.0 nicht dramatisch, aber sind sie bedeutend genug, den TLS 1.0 und SSL 3.0 nicht zwischenbedienen." TLS 1.0 schließt wirklich ein Mittel ein, durch das eine TLS Durchführung die Verbindung zu SSL 3.0 degradieren kann, so Sicherheit schwächend.

Am 23. September 2011 haben Forscher thailändischer Duong und Juliano Rizzo einen "Beweis des Konzepts" genannt das BIEST (Browser-Großtat Gegen SSL/TLS) das Verwenden Javas Applet demonstriert, um dieselben Ursprung-Politikeinschränkungen, für eine lange bekannte Verwundbarkeit des Ziffer-Block-Ankettens (CBC) in TLS 1.0 zu verletzen. Praktische Großtaten waren vorher für diese Verwundbarkeit nicht demonstriert worden, die von Phillip Rogaway 2002 ursprünglich entdeckt wurde.

Mozilla hat die Entwicklungsversionen ihrer NSS Bibliotheken aktualisiert, um EINEM Biest ähnliche Angriffe zu lindern. NSS wird von Mozilla Firefox und Google Chrome verwendet, um SSL durchzuführen. Einige Webserver, die eine gebrochene Durchführung der SSL Spezifizierung haben, können aufhören, infolgedessen zu arbeiten.

Microsoft hat Sicherheitsmeldung MS12-006 am 10. Januar 2012 befreit, der die BIEST-Verwundbarkeit durch das Ändern der Weise befestigt hat, wie Windows Sicherer Kanal (SChannel) Bestandteil encrypted Netzpakete übersendet.

Als eine Arbeit - ringsherum kann der BIEST-Angriff auch durch das Entfernen aller CBC Ziffern von jemandes Liste von erlaubten Ziffern — das Verlassen nur der RC4 Ziffer verhindert werden, die noch auf den meisten Websites weit unterstützt wird. Benutzer von Windows 7 und Windows-Server-2008-R2 können Gebrauch von TLS 1.1 und 1.2 ermöglichen, aber diese Arbeit - wird ringsherum scheitern, wenn es bis zum anderen Ende der Verbindung nicht unterstützt wird und auf einen Rückgriff zu TLS 1.0 hinauslaufen wird.

TLS 1.1

TLS 1.1 wurde in RFC 4346 im April 2006 definiert. Es ist eine Aktualisierung von der TLS Version 1.0. Bedeutende Unterschiede in dieser Version schließen ein:

• Zusätzlicher Schutz gegen Angriffe des Ziffer-Block-Ankettens (CBC).
• Der implizite Initialisierungsvektor (IV) wurde durch einen ausführlichen IV ersetzt.
• Änderung im Berühren, Fehler auszupolstern.
• Unterstützung für die IANA Registrierung von Rahmen.

TLS 1.2

TLS 1.2 wurde in RFC 5246 im August 2008 definiert. Es basiert auf früher TLS 1.1 Spezifizierung. Hauptunterschiede schließen ein:

• Die MD5-SHA-1 Kombination in der pseudozufälligen Funktion (PRF) wurde durch SHA-256 ersetzt, durch eine Auswahl, Ziffer-Gefolge zu verwenden, hat PRFs angegeben.
• Die MD5-SHA-1 Kombination im Beendeten Nachrichtenkuddelmuddel wurde durch SHA-256 durch eine Auswahl ersetzt, Ziffer-Gefolge spezifische Kuddelmuddel-Algorithmen zu verwenden. Jedoch ist die Größe des Kuddelmuddels in der beendeten Nachricht noch zu 96 Bit gestutzt.
• Die MD5-SHA-1 Kombination im digital unterzeichneten Element wurde durch ein einzelnes Kuddelmuddel ersetzt, das während des Händedrucks, Verzugs zu SHA-1 verhandelt ist.
• Erhöhung in der Fähigkeit des Kunden und Servers, der Kuddelmuddel und Unterschrift-Algorithmen anzugeben, werden sie akzeptieren.
• Vergrößerung der Unterstützung für beglaubigte Verschlüsselungsziffern, verwendet hauptsächlich für die Galois/Counter Weise (GCM) und CCM Weise der Fortgeschrittenen Verschlüsselungsstandardverschlüsselung.
• TLS Erweiterungsdefinition und Fortgeschrittener Verschlüsselungsstandard CipherSuites wurden hinzugefügt.

TLS 1.2 wurde weiter in RFC 6176 raffiniert, im März 2011 seine rückwärts gerichtete Vereinbarkeit mit solchem SSL redigierend, dass TLS Sitzungen den Gebrauch der Version 2.0 von Secure Sockets Layer (SSL) nie verhandeln werden.

Anwendungen

Im Anwendungsdesign wird TLS gewöhnlich oben auf einigen der Transportschicht-Protokolle durchgeführt, die anwendungsspezifischen Protokolle wie HTTP, FTP, SMTP, NNTP und XMPP kurz zusammenfassend. Historisch ist es in erster Linie mit zuverlässigen Transportprotokollen wie Transmission Control Protocol (TCP) verwendet worden. Jedoch ist es auch mit Datenpaket-orientierten Transportprotokollen, wie User Datagram Protocol (UDP) und Datagram Congestion Control Protocol (DCCP), Gebrauch durchgeführt worden, der unabhängig standardisiert worden ist, den Begriff Datagram Transport Layer Security (DTLS) gebrauchend.

Ein prominenter Gebrauch von TLS ist, um durch HTTP getragenen Verkehr des World Wide Web zu sichern, um HTTPS zu bilden. Bemerkenswerte Anwendungen sind elektronischer Handel und Anlagenmanagement. Zunehmend wird Simple Mail Transfer Protocol (SMTP) auch durch TLS geschützt. Diese Anwendungen verwenden öffentliche Schlüsselzertifikate, um die Identität von Endpunkten nachzuprüfen.

TLS kann auch an den Tunnel ein kompletter Netzstapel gewöhnt sein, um einen VPN zu schaffen, wie mit OpenVPN der Fall ist. Viele Verkäufer heiraten jetzt die Verschlüsselung von TLS und Beglaubigungsfähigkeiten mit der Genehmigung. Es hat auch wesentliche Entwicklung seit dem Ende der 1990er Jahre im Schaffen der Kundentechnologie außerhalb des Browsers gegeben, um Unterstützung für Anwendungen des Kunden/Servers zu ermöglichen. Wenn verglichen, gegen traditionellen IPsec VPN Technologien hat TLS einige innewohnende Vorteile in der Brandmauer und dem NAT Traversal, die es leichter machen, für große Bevölkerungen des entfernten Zugangs als Verwalter zu fungieren.

TLS ist auch eine Standardmethode, Anwendungsnachrichtenübermittlung von Session Initiation Protocol (SIP) zu schützen. TLS kann verwendet werden, um Beglaubigung und Verschlüsselung der NIPPEN-Nachrichtenübermittlung zur Verfügung zu stellen, die mit VoIP und anderen Nippen-basierten Anwendungen vereinigt ist.

Sicherheit

TLS hat eine Vielfalt von Sicherheitsmaßnahmen:

• Schutz gegen ein Gefälle des Protokolls zu einer vorherigen (weniger sicheren) Version oder einem schwächeren Ziffer-Gefolge.
• Das Numerieren nachfolgender Anwendung registriert mit einer Folge-Zahl und dem Verwenden dieser Folge-Zahl in den Nachrichtenbeglaubigungscodes (MACs).
• Das Verwenden einer mit einem Schlüssel erhöhten Nachrichtenauswahl (kann so nur ein Schlüsselhalter den MAC überprüfen). Der HMAC durch die meisten TLS Ziffer-Gefolge verwendete Aufbau wird in RFC 2104 angegeben (SSL 3.0 hat einen verschiedenen Kuddelmuddel-basierten MAC verwendet).
• Die Nachricht, die den ("Beendeten") Händedruck beendet, sendet ein Kuddelmuddel aller ausgetauschten von beiden Parteien gesehenen Händedruck-Nachrichten.
• Die pseudozufällige Funktion spaltet die Eingangsdaten entzwei und bearbeitet jeden mit einem verschiedenen hashing Algorithmus (MD5 und SHA-1), dann XORs sie zusammen, um den MAC zu schaffen. Das stellt Schutz zur Verfügung, selbst wenn, wie man findet, einer dieser Algorithmen verwundbar ist. TLS nur.
• SSL 3.0 hat SSL 2.0 durch das Hinzufügen übertroffen, dass SHA-1 Ziffern und Unterstützung für die Zertifikat-Beglaubigung gestützt hat.

Von einer Sicherheitseinstellung sollte SSL 3.0 weniger wünschenswert betrachtet werden als TLS 1.0. Die SSL 3.0 Ziffer-Gefolge haben einen schwächeren Schlüsselabstammungsprozess; die Hälfte des Hauptschlüssels, der gegründet wird, ist von der MD5 Kuddelmuddel-Funktion völlig abhängig, die gegen Kollisionen nicht widerstandsfähig ist und deshalb sicher nicht betrachtet wird.

Unter TLS 1.0 hängt der Hauptschlüssel, der gegründet wird, sowohl von MD5 als auch von SHA-1 ab, so wird sein Abstammungsprozess schwach nicht zurzeit betrachtet.

Es ist aus diesem Grund, dass SSL 3.0 Durchführungen unter FIPS 140-2 nicht gültig gemacht werden kann.

Eine Verwundbarkeit des Neuverhandlungsverfahrens wurde im August 2009 entdeckt, der zu plaintext Spritzenangriffen gegen SSL 3.0 und alle jetzigen Versionen von TLS führen kann. Zum Beispiel erlaubt es einem Angreifer, der eine https Verbindung entführen kann, um ihre eigenen Bitten in den Anfang des Gespräches zu spleißen, das der Kunde mit dem Webserver hat. Der Angreifer kann die Client/Server-Kommunikation nicht wirklich entschlüsseln, so ist es von einem typischen Mann im mittleren Angriff verschieden. Eine kurzfristige üble Lage ist für Webserver, um aufzuhören, Neuverhandlung zu erlauben, die normalerweise andere Änderungen nicht verlangen wird, wenn Kundenzertifikat-Beglaubigung nicht verwendet wird. Um die Verwundbarkeit zu befestigen, wurde eine Neuverhandlungsanzeige-Erweiterung für TLS vorgeschlagen. Es wird verlangen, dass der Kunde und Server einschließt und Information über vorherige Händedrücke in irgendwelchen Neuverhandlungshändedrücken nachprüft. Diese Erweiterung ist ein vorgeschlagener Standard geworden und ist die Zahl RFC 5746 zugeteilt worden. Der RFC ist in neuem OpenSSL und anderen Bibliotheken durchgeführt worden.

Es gibt einige Angriffe gegen die Durchführung aber nicht das Protokoll selbst:

• In den früheren Durchführungen hat ein CAs basicConstraints CA=FALSE für Blatt-Knoten nicht ausführlich gesetzt. Infolgedessen konnten diese Blatt-Knoten Schelm-Zertifikate unterzeichnen. Außerdem hat eine frühe Software (einschließlich IE6 und Konqueror) dieses Feld zusammen nicht überprüft. Das kann für den Mann im mittleren Angriff auf SSL alle potenziellen Verbindungen ausgenutzt werden.
• Einige Durchführungen (einschließlich älterer Versionen von Microsoft Cryptographic API, Network Security Services und GnuTLS) hören auf, irgendwelche Charaktere zu lesen, die dem ungültigen Charakter im Namenfeld des Zertifikats folgen, das ausgenutzt werden kann, um den Kunden ins Lesen des Zertifikats zum Narren zu halten, als ob es dasjenige war, das aus der authentischen Seite z.B gekommen ist. paypal.com würde \0.badguy.com als die Seite paypal.com aber nicht badguy.com falsch sein.
• Browser haben SSL/TLS Protokoll-Versionsrückgriff-Mechanismen aus Vereinbarkeitsgründen durchgeführt. Der Schutz, der durch die SSL/TLS Protokolle gegen ein Gefälle zu einer vorherigen Version durch einen aktiven MITM-Angriff angeboten ist, kann nutzlos durch solche Mechanismen gemacht werden.

SSL 2.0 wird in einer Vielfalt von Wegen rissig gemacht:

• Identische kryptografische Schlüssel werden für die Nachrichtenbeglaubigung und Verschlüsselung verwendet.
• SSL 2.0 hat einen schwachen MAC Aufbau, der die MD5 Kuddelmuddel-Funktion mit einem heimlichen Präfix verwendet, ihn verwundbar für Länge-Erweiterungsangriffe machend.
• SSL 2.0 hat keinen Schutz für den Händedruck, bedeutend, dass ein Mann im mittleren Gefälle-Angriff unentdeckt gehen kann.
• SSL 2.0 Gebrauch die TCP Verbindung in der Nähe davon zeigen das Ende von Daten an. Das bedeutet, dass Stutzungsangriffe möglich sind: Der Angreifer schmiedet einfach eine TCP FLOSSE, den Empfänger unbewusst eines rechtswidrigen Endes der Datennachricht (SSL 3.0 üble Lagen dieses Problem verlassend, indem er ein ausführliches Verschluss-Alarmsignal hat).
• SSL 2.0 nimmt einen einzelnen Dienst und ein festes Bereichszertifikat an, das sich mit der Standardeigenschaft der virtuellen Bewirtung in Webservern streitet. Das bedeutet, dass die meisten Websites davon praktisch verschlechtert werden, SSL zu verwenden.

SSL 2.0 ist standardmäßig in Internet Explorer 7, Mozilla Firefox 2, Mozilla Firefox 3, Mozilla Firefox 4 Oper und Safari arbeitsunfähig. Nachdem es TLS ClientHello sendet, wenn Mozilla Firefox findet, dass der Server unfähig ist, den Händedruck zu vollenden, wird es versuchen, zum Verwenden von SSL 3.0 mit einem SSL 3.0 ClientHello in SSL 2.0 Format zurückzuweichen, um die Wahrscheinlichkeit erfolgreich handshaking mit älteren Servern zu maximieren. Die Unterstützung für SSL 2.0 (und schwache 40-bit- und 56-Bit-Ziffern) ist völlig von der Oper bezüglich der Version 9.5 entfernt worden.

Wie man

berichtet hat, haben Modifizierungen zu den ursprünglichen Protokollen, wie Fehlstart (angenommen und hat durch Google Chrom ermöglicht), oder Schnellanfang, beschränkte TLS Protokoll-Version rollback Angriffe eingeführt, oder Modifizierungen der Ziffer-Gefolge-Liste zu erlauben, die vom Kunden an den Server gesandt ist (kann ein Angreifer fähig sein beeinflussen die Ziffer-Gefolge-Auswahl in einem Versuch, die Ziffer-Gefolge-Kraft zu degradieren, entweder einen schwächeren symmetrischen Verschlüsselungsalgorithmus oder einen schwächeren Schlüsselaustausch zu verwenden).

TLS Händedruck im Detail

Das TLS Protokoll tauscht Aufzeichnungen aus, die die auszutauschenden Daten kurz zusammenfassen. Jede Aufzeichnung kann zusammengepresst, ausgepolstert, mit einem Nachrichtenbeglaubigungscode (MAC) oder encrypted, alle abhängig vom Staat der Verbindung angehangen werden. Jede Aufzeichnung hat ein zufriedenes Typ-Feld, das die Aufzeichnung, ein Länge-Feld und ein TLS Versionsfeld angibt.

Wenn die Verbindung anfängt, fasst die Aufzeichnung ein anderes Protokoll — das Händedruck-Nachrichtenübermittlungsprotokoll kurz zusammen — der zufriedenen Typ 22 hat.

Einfacher TLS Händedruck

Ein einfaches Verbindungsbeispiel folgt, einen Händedruck illustrierend, wo der Server (aber nicht der Kunde) durch sein Zertifikat beglaubigt wird:

1. Verhandlungsphase:
2. * sendet Ein Kunde eine Nachricht von ClientHello, die die höchste TLS Protokoll-Version angibt, die sie, eine Zufallszahl, eine Liste von angedeutetem CipherSuites und angedeuteten Kompressionsmethoden unterstützt. Wenn der Kunde versucht, einen fortgesetzten Händedruck durchzuführen, kann er einen Sitzungspersonalausweis senden.
3. * erwidert Der Server mit einer Nachricht von ServerHello, die gewählte Protokoll-Version, eine Zufallszahl, CipherSuite und Kompressionsmethode von den vom Kunden angebotenen Wahlen enthaltend. Um fortgesetzte Händedrücke zu bestätigen oder zu erlauben, kann der Server einen Sitzungspersonalausweis senden. Die gewählte Protokoll-Version sollte am höchsten sein, den sowohl der Kunde als auch Server unterstützen. Zum Beispiel, wenn der Kunde TLS1.1 unterstützt und der Server TLS1.2 unterstützt, sollte TLS1.1 ausgewählt werden; SSL 3.0 sollte nicht ausgewählt werden.
4. * sendet Der Server seine Zertifikat-Nachricht (je nachdem das ausgewählte Ziffer-Gefolge, das durch den Server weggelassen werden kann).
5. * sendet Der Server eine Nachricht von ServerHelloDone, anzeigend, dass er mit der Händedruck-Verhandlung getan wird.
6. * erwidert Der Kunde mit einer Nachricht von ClientKeyExchange, die PreMasterSecret, öffentlichen Schlüssel oder nichts enthalten kann. (Wieder hängt das von der ausgewählten Ziffer ab.) Dieser PreMasterSecret ist encrypted das Verwenden des öffentlichen Schlüssels des Server-Zertifikats.
7. * verwenden Der Kunde und Server dann die Zufallszahlen und PreMasterSecret, um ein allgemeines Geheimnis, genannt das "Master-Geheimnis" zu schätzen. Alle anderen Schlüsseldaten für diese Verbindung werden aus diesem Master-Geheimnis abgeleitet (und der Kunde - und Server-erzeugte zufällige Werte), der durch eine sorgfältig bestimmte pseudozufällige Funktion passiert wird.
8. Der Kunde sendet jetzt eine Aufzeichnung von ChangeCipherSpec, im Wesentlichen den Server erzählend, "Alles ich sage, dass Sie zukünftig beglaubigt werden (und encrypted, wenn Verschlüsselungsrahmen im Server-Zertifikat da gewesen sind)." ChangeCipherSpec ist selbst ein Rekordniveau-Protokoll mit dem zufriedenen Typ 20.
9. * Schließlich sendet der Kunde einem beglaubigten und encrypted Beendete Nachricht, ein Kuddelmuddel und MAC über die vorherigen Händedruck-Nachrichten enthaltend.
10. * wird Der Server versuchen, die Beendete Nachricht des Kunden zu entschlüsseln und das Kuddelmuddel und MAC nachzuprüfen. Wenn die Dekodierung oder Überprüfung scheitern, wie man betrachtet, hat der Händedruck gescheitert, und die Verbindung sollte niedergerissen werden.
11. Schließlich sendet der Server ChangeCipherSpec, dem Kunden erzählend, "Alles ich sage, dass Sie zukünftig beglaubigt werden (und encrypted, wenn Verschlüsselung verhandelt wurde)."
12. * sendet Der Server seinem beglaubigten und encrypted Beendete Nachricht.
13. * führt Der Kunde dieselbe Dekodierung und Überprüfung durch.
14. Anwendungsphase: An diesem Punkt ist der "Händedruck" abgeschlossen, und das Anwendungsprotokoll, wird mit dem zufriedenen Typ 23 ermöglicht. Anwendungsnachrichten, die zwischen Kunden und Server ausgetauscht sind, werden auch beglaubigt und fakultativ encrypted genau wie in ihrer Beendeten Nachricht. Sonst wird der zufriedene Typ 25 zurückkehren, und der Kunde wird nicht beglaubigen.

Kundenbeglaubigter TLS Händedruck

Das folgende volle Beispiel zeigt einem Kunden, der (zusätzlich zum Server wie obengenannter) über TLS das Verwenden von zwischen beiden Gleichen ausgetauschten Zertifikaten wird beglaubigt.

1. Verhandlungsphase:
2. * sendet Ein Kunde eine Nachricht von ClientHello, die die höchste TLS Protokoll-Version angibt, die sie, eine Zufallszahl, eine Liste von angedeuteten Ziffer-Gefolgen und Kompressionsmethoden unterstützt.
3. * erwidert Der Server mit einer Nachricht von ServerHello, die gewählte Protokoll-Version, eine Zufallszahl, das Ziffer-Gefolge und die Kompressionsmethode von den vom Kunden angebotenen Wahlen enthaltend. Der Server kann auch eine Sitzung id als ein Teil der Nachricht senden, um einen fortgesetzten Händedruck durchzuführen.

* sendet Der Server seine Zertifikat-Nachricht (je nachdem das ausgewählte Ziffer-Gefolge, das durch den Server weggelassen werden kann).

1. * bittet Der Server um ein Zertifikat vom Kunden, so dass die Verbindung mit einer Nachricht von CertificateRequest gegenseitig beglaubigt werden kann.

* sendet Der Server eine Nachricht von ServerHelloDone, anzeigend, dass er mit der Händedruck-Verhandlung getan wird.

1. * erwidert Der Kunde mit einer Zertifikat-Nachricht, die das Zertifikat des Kunden enthält.
2. * sendet Der Kunde eine Nachricht von ClientKeyExchange, die PreMasterSecret, öffentlichen Schlüssel oder nichts enthalten kann. (Wieder hängt das von der ausgewählten Ziffer ab.) Dieser PreMasterSecret ist encrypted das Verwenden des öffentlichen Schlüssels des Server-Zertifikats.
3. * sendet Der Kunde eine Nachricht von CertificateVerify, die eine Unterschrift über die vorherigen Händedruck-Nachrichten mit dem privaten Schlüssel des Zertifikats des Kunden ist. Diese Unterschrift kann durch das Verwenden des öffentlichen Schlüssels des Zertifikats des Kunden nachgeprüft werden. Das lässt den Server wissen, dass der Kunde Zugang zum privaten Schlüssel des Zertifikats hat und so das Zertifikat besitzt.
4. * verwenden Der Kunde und Server dann die Zufallszahlen und PreMasterSecret, um ein allgemeines Geheimnis, genannt das "Master-Geheimnis" zu schätzen. Alle anderen Schlüsseldaten für diese Verbindung werden aus diesem Master-Geheimnis abgeleitet (und der Kunde - und Server-erzeugte zufällige Werte), der durch eine sorgfältig bestimmte pseudozufällige Funktion passiert wird.
5. Der Kunde sendet jetzt eine Aufzeichnung von ChangeCipherSpec, im Wesentlichen den Server erzählend, "Alles ich sage, dass Sie zukünftig beglaubigt werden (und encrypted, wenn Verschlüsselung verhandelt wurde)." ChangeCipherSpec ist selbst ein Rekordniveau-Protokoll und hat Typ 20 und nicht 22.
6. * Schließlich sendet der Kunde einem encrypted Beendete Nachricht, ein Kuddelmuddel und MAC über die vorherigen Händedruck-Nachrichten enthaltend.

* wird Der Server versuchen, die Beendete Nachricht des Kunden zu entschlüsseln und das Kuddelmuddel und MAC nachzuprüfen. Wenn die Dekodierung oder Überprüfung scheitern, wie man betrachtet, hat der Händedruck gescheitert, und die Verbindung sollte niedergerissen werden.

1. Schließlich sendet der Server ChangeCipherSpec, dem Kunden erzählend, "Alles ich sage, dass Sie zukünftig beglaubigt werden (und encrypted, wenn Verschlüsselung verhandelt wurde)."
2. * sendet Der Server seinem eigenen encrypted Beendete Nachricht.

* führt Der Kunde dieselbe Dekodierung und Überprüfung durch.

1. Anwendungsphase: An diesem Punkt ist der "Händedruck" abgeschlossen, und das Anwendungsprotokoll, wird mit dem zufriedenen Typ 23 ermöglicht. Anwendungsnachrichten, die zwischen Kunden und Server ausgetauscht sind, werden auch encrypted genau wie in ihrer Beendeten Nachricht sein. Die Anwendung wird nie wieder TLS Verschlüsselungsinformation ohne eine Entschuldigung des Typs 32 zurückgeben.

Fortgesetzter TLS Händedruck

Öffentliche Schlüsseloperationen (z.B, RSA) sind in Bezug auf die rechenbetonte Macht relativ teuer. TLS stellt eine sichere Abkürzung im Händedruck-Mechanismus zur Verfügung, diese Operationen zu vermeiden. In einem gewöhnlichen vollen Händedruck sendet der Server eine Sitzung id als ein Teil der Nachricht von ServerHello. Der Kunde vereinigt diese Sitzung id mit der IP-Adresse des Servers und TCP Hafen, so dass, wenn der Kunde wieder zu diesem Server in Verbindung steht, es die Sitzung id an der Abkürzung der Händedruck verwenden kann. Im Server hat die Sitzung id Karten zu den kryptografischen Rahmen vorher, spezifisch das "Master-Geheimnis" verhandelt. Beide Seiten müssen dasselbe "Master-Geheimnis" haben, oder der fortgesetzte Händedruck wird scheitern (das hält einen Lauscher davon ab, eine Sitzung id zu verwenden). Die zufälligen Daten in den Nachrichten von ClientHello und ServerHello versichern eigentlich, dass die erzeugten Verbindungsschlüssel verschieden sein werden als in der vorherigen Verbindung. Im RFCs wird dieser Typ des Händedrucks einen abgekürzten Händedruck genannt. Es wird auch in der Literatur als ein Wiederanfang-Händedruck beschrieben.

Verhandlungsphase:

1. * sendet Ein Kunde eine Nachricht von ClientHello, die die höchste TLS Protokoll-Version angibt, die sie, eine Zufallszahl, eine Liste von angedeuteten Ziffer-Gefolgen und Kompressionsmethoden unterstützt. Eingeschlossen in die Nachricht ist die Sitzung id von der vorherigen TLS Verbindung.
2. * erwidert Der Server mit einer Nachricht von ServerHello, die gewählte Protokoll-Version, eine Zufallszahl, das Ziffer-Gefolge und die Kompressionsmethode von den vom Kunden angebotenen Wahlen enthaltend. Wenn der Server die Sitzung id gesandt vom Kunden anerkennt, erwidert es mit derselben Sitzung id. Der Kunde verwendet das, um anzuerkennen, dass ein fortgesetzter Händedruck durchgeführt wird. Wenn der Server die Sitzung id gesandt vom Kunden nicht anerkennt, sendet es einen verschiedenen Wert für seine Sitzung id. Das sagt dem Kunden, dass ein fortgesetzter Händedruck nicht durchgeführt wird. An diesem Punkt haben sowohl der Kunde als auch Server das "Master-Geheimnis" und die zufälligen Daten, um die für diese Verbindung zu verwendenden Schlüsseldaten zu erzeugen.
3. Der Server sendet jetzt eine Aufzeichnung von ChangeCipherSpec, im Wesentlichen dem Kunden erzählend, "Alles ich sage, dass Sie zukünftig encrypted sein werden." ChangeCipherSpec ist selbst ein Rekordniveau-Protokoll und hat Typ 20 und nicht 22.
4. * Schließlich sendet der Server einem encrypted Beendete Nachricht, ein Kuddelmuddel und MAC über die vorherigen Händedruck-Nachrichten enthaltend.
5. * wird Der Kunde versuchen, die Beendete Nachricht des Servers zu entschlüsseln und das Kuddelmuddel und MAC nachzuprüfen. Wenn die Dekodierung oder Überprüfung scheitern, wie man betrachtet, hat der Händedruck gescheitert, und die Verbindung sollte niedergerissen werden.
6. Schließlich sendet der Kunde ChangeCipherSpec, den Server erzählend, "Alles ich sage, dass Sie zukünftig encrypted sein werden."
7. * sendet Der Kunde seinem eigenen encrypted Beendete Nachricht.
8. * führt Der Server dieselbe Dekodierung und Überprüfung durch.
9. Anwendungsphase: An diesem Punkt ist der "Händedruck" abgeschlossen, und das Anwendungsprotokoll, wird mit dem zufriedenen Typ 23 ermöglicht. Anwendungsnachrichten, die zwischen Kunden und Server ausgetauscht sind, werden auch encrypted genau wie in ihrer Beendeten Nachricht sein.

Abgesondert vom Leistungsvorteil können fortgesetzte Sitzungen auch für das einzelne Zeichen - darauf verwendet werden, weil es versichert wird, dass beide die ursprüngliche Sitzung sowie jede fortgesetzte Sitzung aus demselben Kunden entstehen. Das ist von besonderer Wichtigkeit für den FTP über das TLS/SSL Protokoll, das unter einem Mann im mittleren Angriff sonst leiden würde, in dem ein Angreifer den Inhalt der sekundären Datenverbindungen abfangen konnte.

TLS registrieren Protokoll

Das ist das allgemeine Format aller TLS-Aufzeichnungen.

Zufriedener Typ

: Dieses Feld identifiziert den in dieser Aufzeichnung enthaltenen Rekordschicht-Protokoll-Typ.

:

Version

: Dieses Feld identifiziert die größere und geringe Version von TLS für die enthaltene Nachricht. Für eine Nachricht von ClientHello braucht das nicht die höchste vom Kunden unterstützte Version zu sein.

:

Länge

: Die Länge der Protokoll-Nachricht (En), um um 2 Bytes (16 KiB) nicht zu weit zu gehen.

Protokoll-Nachricht (s)

: Eine oder mehr Nachrichten haben sich durch das Protokoll-Feld identifiziert. Bemerken Sie, dass dieses Feld encrypted abhängig vom Staat der Verbindung sein kann.

MAC und auspolsternd

: Ein Nachrichtenbeglaubigungscode hat über die Protokoll-Nachricht mit dem zusätzlichen eingeschlossenen Schlüsselmaterial gerechnet. Bemerken Sie, dass dieses Feld encrypted, oder nicht eingeschlossen völlig abhängig vom Staat der Verbindung sein kann.

: Kein MAC oder Polstern können am Ende von TLS-Aufzeichnungen vor allen Ziffer-Algorithmen da sein, und Rahmen sind verhandelt und handshaked und dann durch das Senden einer Aufzeichnung von CipherStateChange (sieh unten) bestätigt worden, um Zeichen zu geben, dass diese Rahmen in allen weiteren von demselben Gleichen gesandten Aufzeichnungen wirken werden.

Händedruck-Protokoll

Die meisten während der Einstellung der TLS Sitzung ausgetauschten Nachrichten basieren auf dieser Aufzeichnung, wenn ein Fehler oder Warnung nicht vorkommen und durch eine Wachsame Protokoll-Aufzeichnung (sieh unten) Zeichen gegeben werden müssen, oder die Verschlüsselungsweise der Sitzung durch eine andere Aufzeichnung modifiziert wird (sieh Protokoll von ChangeCipherSpec unten).

Nachrichtentyp: Dieses Feld identifiziert den Händedruck-Nachrichtentyp.

:

Händedruck-Nachrichtendatenlänge

: Das ist ein 3-Byte-Feld, das die Länge der Händedruck-Daten anzeigt, nicht einschließlich des Kopfballs.

Bemerken Sie, dass vielfache Händedruck-Nachrichten innerhalb einer Aufzeichnung verbunden werden können.

Wachsames Protokoll

Diese Aufzeichnung sollte normalerweise während normalen handshaking oder Anwendungsaustausches nicht gesandt werden. Jedoch kann diese Nachricht jederzeit während des Händedrucks und bis zum Verschluss der Sitzung gesandt werden. Wenn das verwendet wird, um einem tödlichen Fehler Zeichen zu geben, wird die Sitzung sofort nach dem Senden dieser Aufzeichnung geschlossen, so wird diese Aufzeichnung verwendet, um einen Grund für diesen Verschluss zu geben. Wenn das wachsame Niveau als eine Warnung beflaggt wird, kann sich das entfernte dafür entscheiden, die Sitzung zu schließen, wenn es entscheidet, dass die Sitzung für seine Bedürfnisse nicht zuverlässig genug ist (bevor, so tuend, das entfernte auch sein eigenes Signal senden kann).

Niveau

: Dieses Feld identifiziert das Niveau des Alarmsignals. Wenn das Niveau tödlich ist, sollte der Absender die Sitzung sofort schließen. Sonst kann sich der Empfänger dafür entscheiden, die Sitzung selbst zu begrenzen, indem er sein eigenes tödliches Alarmsignal sendet und die Sitzung selbst sofort nach dem Senden davon schließt. Der Gebrauch von Wachsamen Aufzeichnungen ist jedoch fakultativ, wenn es vermisst wird, bevor der Sitzungsverschluss, die Sitzung automatisch (mit seinen Händedrücken) fortgesetzt werden kann.

: Der normale Verschluss einer Sitzung nach der Beendigung der transportierten Anwendung sollte vorzugsweise mit mindestens dem Ende alarmiert werden geben Typ Alert (mit einem einfachen Warnniveau) bekannt, um solche automatische Zusammenfassung einer neuen Sitzung zu verhindern. Die Nachrichtenübermittlung ausführlich dem normalen Verschluss einer sicheren Sitzung vor dem wirksamen Schließen seiner Transportschicht ist nützlich, um Angriffe zu verhindern oder zu entdecken (wie Versuche, die sicher transportierten Daten zu stutzen, wenn es wirklich keine vorher bestimmte Länge oder Dauer hat, die der Empfänger der gesicherten Daten erwarten kann).

:

Beschreibung

: Dieses Feld identifiziert sich, welcher Typ des Alarmsignals gesandt wird.

:

Protokoll von ChangeCipherSpec

CCS Protokoll-Typ

: Zurzeit nur 1.

Anwendungsprotokoll

Länge

: Länge von Anwendungsdaten (des Protokoll-Kopfballs und einschließlich des MAC ausschließend und Trailer auspolsternd)

,

MAC

: 20 Bytes für den SHA-1-based HMAC, 16 Bytes für den MD5-basierten HMAC.

Polstern

: Variable Länge; letztes Byte enthält die Polstern-Länge.

Unterstützung für namenbasierte virtuelle Server

Aus dem Anwendungsprotokoll-Gesichtspunkt gehört TLS einer niedrigeren Schicht, obwohl der

TCP/IP Modell ist zu rau, um es zu zeigen. Das bedeutet, dass der TLS Händedruck gewöhnlich ist

(außer im STARTTLS Fall) durchgeführt bevor kann das Anwendungsprotokoll anfangen.

Die namenbasierte virtuelle Server-Eigenschaft, die durch den zur Verfügung wird stellt

Anwendungsschicht, alle co-hosted virtuellen Server teilen dasselbe Zertifikat weil

der Server muss auswählen und ein Zertifikat sofort nach der Nachricht von ClientHello senden.

Das ist ein großes Problem in der Bewirtung von Umgebungen, weil es jedes Teilen des bedeutet

dasselbe Zertifikat unter allen Kunden oder dem Verwenden eines verschiedenen IP richtet für jeden von ihnen.

Es gibt zwei bekannte durch X.509 zur Verfügung gestellte workarounds:

• Wenn alle virtuellen Server demselben Gebiet gehören, kann ein Wildcard-Zertifikat verwendet werden. Außer der losen Hostname-Auswahl, die ein Problem sein könnte oder nicht, gibt es keine allgemeine Abmachung darüber, wie man Wildcard-Zertifikate vergleicht. Verschiedene Regeln werden abhängig vom Anwendungsprotokoll oder der verwendeten Software angewandt.
• Fügen Sie jeden virtuellen Hostnamen in der subjectAltName Erweiterung hinzu. Das Hauptproblem, das ist, dass das Zertifikat neu aufgelegt werden muss, wann auch immer ein neuer virtueller Server hinzugefügt wird.

Um den Servernamen, RFC zur Verfügung zu stellen, erlauben 4366 Erweiterungen von Transport Layer Security (TLS) Kunden, eine Servername-Anzeige-Erweiterung (SNI) in die verlängerte Nachricht von ClientHello einzuschließen.

Diese Erweiterung deutet der Server sofort an, die die Kundenwünsche nennen, zu, so der Server in Verbindung zu stehen

kann das passende Zertifikat auswählen, um an den Kunden zu senden.

Durchführungen

SSL und TLS sind in mehreren freien und offenen Quellsoftwareprojekten weit durchgeführt worden. Programmierer können PolarSSL, CyaSSL, OpenSSL, NSS oder Bibliotheken von GnuTLS für die SSL/TLS Funktionalität verwenden. Windows von Microsoft schließt eine Durchführung von SSL und TLS als ein Teil seines Sicheren Kanalpakets ein. Programmierer von Delphi können eine Bibliothek genannt Indy verwenden. Der Vergleich von TLS Durchführungen stellt einen kurzen Vergleich von Eigenschaften von verschiedenen Durchführungen zur Verfügung.

Browser-Durchführungen

Alle neusten WWW-Browser unterstützen TLS:

• Die Safari des Apfels unterstützt TLS, aber es wird der Version nicht offiziell angegeben. Auf Betriebssystemen (Verwendet Safari die TLS Durchführung des zu Grunde liegenden OS), wie Mac OS X 10.5.8, Mac OS X 10.6.6, Windows, wie man berichtet hat, haben XP, Windows-Aussicht oder Windows 7, Safari 5 TLS 1.0 unterstützt.
• Mozilla Firefox, Versionen 2 und oben, unterstützen TLS 1.0. Firefox unterstützt TLS 1.1 oder 1.2 nicht.
• Microsoft Internet Explorer verwendet immer die TLS Durchführung des zu Grunde liegenden Windows-Betriebssystems von Microsoft, eines Dienstes genannt der SChannel Sicherheitsdienstleister. Internet Explorer 8 in Windows 7 und Windows-Server 2008 R2 unterstützt TLS 1.2. Windows 7 und Windows-Server 2008 R2 verwenden denselben Code (Windows-Version 6.1 von Microsoft (bauen 7600)) ähnlich dem, wie Windows-Aussicht SP1 denselben Code wie Server des Windows 2008 verwendet.
• Bezüglich Presto 2.2, gezeigt in der Oper 10, unterstützt Oper TLS 1.2.
• Der Chrombrowser von Google unterstützt TLS 1.0, aber nicht TLS 1.1 oder 1.2.

Standards

Der Strom hat genehmigt, dass die Version von TLS Version 1.2 ist, die angegeben wird in:

• RFC 5246: "Die Protokoll-Version 1.2" von Transport Layer Security (TLS).

Der aktuelle Standard ersetzt diese ehemaligen Versionen, die jetzt veraltet betrachtet werden:

• RFC 2246: "Die TLS Protokoll-Version 1.0".
• RFC 4346: "Die Protokoll-Version 1.1" von Transport Layer Security (TLS).

sowie der nie standardisierte SSL 3.0:

• RFC 6101: "Die Protokoll-Version 3.0" von Secure Sockets Layer (SSL).

Anderer RFCs hat nachher TLS erweitert.

Erweiterungen auf TLS 1.0 schließen ein:

• RFC 2595: "Mit TLS mit IMAP, POP3 und ACAP". Gibt eine Erweiterung auf den IMAP, den POP3 und die ACAP Dienstleistungen an, die dem Server und Kunden erlauben, Transportschicht-Sicherheit zu verwenden, um private, beglaubigte Kommunikation über das Internet zur Verfügung zu stellen.
• RFC 2712: "Hinzufügung von Kerberos Ziffer-Gefolgen zu Transport Layer Security (TLS)". Die in diesem Merkzettel definierten 40-Bit-Ziffer-Gefolge erscheinen nur zum Zweck, die Tatsache zu dokumentieren, dass jene Ziffer-Gefolge-Codes bereits zugeteilt worden sind.
• RFC 2817: "Zu TLS Innerhalb von HTTP/1.1 befördernd" erklärt, wie man den Steigungsmechanismus in HTTP/1.1 verwendet, um Transport Layer Security (TLS) über eine vorhandene TCP Verbindung zu beginnen. Das erlaubt ungesichertem und gesichertem HTTP Verkehr, denselben weithin bekannten Hafen zu teilen (in diesem Fall, http: an 80 aber nicht https: an 443).
• RFC 2818: "HTTP Über TLS" unterscheidet gesicherter Verkehr vom unsicheren Verkehr durch den Gebrauch eines verschiedenen 'Server-Hafens'.
• RFC 3207: "SMTP Diensterweiterung für Sicheren SMTP über die Transportschicht-Sicherheit". Gibt eine Erweiterung auf den SMTP Dienst an, der einem SMTP Server und Kunden erlaubt, Transportschicht-Sicherheit zu verwenden, um private, beglaubigte Kommunikation über das Internet zur Verfügung zu stellen.
• RFC 3268: "AES Ciphersuites für TLS". Tragen Ziffer-Gefolge von Advanced Encryption Standard (AES) zu den vorher vorhandenen symmetrischen Ziffern bei.
• RFC 3546: "Erweiterungen von Transport Layer Security (TLS)" trägt ein Mechanismus bei, um Protokoll-Erweiterungen während der Sitzung initialisation zu verhandeln, und definiert einige Erweiterungen. Gemacht veraltet durch RFC 4366.
• RFC 3749: "Transportschicht-Sicherheitsprotokoll-Kompressionsmethoden" gibt das Fachwerk für Kompressionsmethoden und die DEFLATIONIEREN Kompressionsmethode an.
• RFC 3943: "Das Protokoll-Kompressionsverwenden von Transport Layer Security (TLS) Lempel-Ziv-Stac (LZS)".
• RFC 4132: "Hinzufügung von Kamelie-Ziffer-Gefolgen zu Transport Layer Security (TLS)".
• RFC 4162: "Hinzufügung von SAMEN-Ziffer-Gefolgen zu Transport Layer Security (TLS)".
• RFC 4217: "FTP mit TLS sichernd".
• RFC 4279: "Vorgeteilter Schlüssel Ciphersuites für Transport Layer Security (TLS)" fügt drei Sätze von neuen Ziffer-Gefolgen für das TLS Protokoll hinzu, um auf vorgeteilten Schlüsseln gestützte Beglaubigung zu unterstützen.

Erweiterungen auf TLS 1.1 schließen ein:

• RFC 4347: "Datenpaket-Transportschicht-Sicherheit" gibt eine TLS Variante an, die über Datenpaket-Protokolle (wie UDP) arbeitet.
• RFC 4366: "Erweiterungen von Transport Layer Security (TLS)" beschreiben sowohl eine Reihe spezifischer Erweiterungen als auch einen allgemeinen Erweiterungsmechanismus.
• RFC 4492: "Ziffer-Gefolge von Elliptic Curve Cryptography (ECC) für Transport Layer Security (TLS)".
• RFC 4507: "Sitzungswiederaufnahme von Transport Layer Security (TLS) ohne Staat der Server-Seite".
• RFC 4680: "TLS Händedruck-Nachricht für Ergänzende Daten".
• RFC 4681: "TLS Benutzer, der Erweiterung Kartografisch darstellt".
• RFC 4785: "Pre-Shared Key (PSK) Ciphersuites mit der UNGÜLTIGEN Verschlüsselung für Transport Layer Security (TLS)".
• RFC 5054: "Mit dem Protokoll von Secure Remote Password (SRP) für die TLS Beglaubigung". Definiert den TLS-SRP ciphersuites.
• RFC 5081: "Mit Schlüsseln von OpenPGP für die Beglaubigung von Transport Layer Security (TLS)", obsoleted durch RFC 6091.

Erweiterungen auf TLS 1.2 schließen ein:

• RFC 5746: "Neuverhandlungsanzeige-Erweiterung von Transport Layer Security (TLS)".
• RFC 5878: "Genehmigungserweiterungen von Transport Layer Security (TLS)".
• RFC 6091: "Mit Schlüsseln von OpenPGP für die Beglaubigung von Transport Layer Security (TLS)".
• RFC 6176: "Das Verbieten der Version 2.0" von Secure Sockets Layer (SSL).
• RFC 6209: "Hinzufügung der ARIE-Ziffer-Gefolge zu Transport Layer Security (TLS)".

Siehe auch

• Virtuelles privates Netz
• Vergleich von TLS Durchführungen
• Datenpaket-Transportschicht-Sicherheit
• Gleichzeitig gesandte Transportschicht-Sicherheit
• X.509
• Zertifikat-Autorität
• Öffentliches Schlüsselzertifikat
• Verlängertes Validierungszertifikat
• SAMEN
• SSL Beschleunigung
• Verfinsterter TCP
• Server gated Geheimschrift
• tcpcrypt
• Servername-Anzeige
• Transportschicht-Sicherheit - Ursprung Bestimmte Zertifikate - Eine vorgeschlagene Protokoll-Erweiterung, die WWW-Browser-Sicherheit über selbstunterzeichnete Browser-Zertifikate verbessert

Software

• OpenSSL: Eine freie Durchführung (lizenzieren BSD mit einigen Erweiterungen)
• GnuTLS: eine freie Durchführung (LGPL lizenziert)
• cryptlib: Eine tragbare offene Quellgeheimschrift-Bibliothek (schließt TLS/SSL Durchführung ein)
• JSSE: Eine javanische Durchführung, die in die javanische Laufzeitumgebung eingeschlossen ist
• Network Security Services (NSS): FIPS 140 hat offene Quellbibliothek gültig gemacht
• PolarSSL: Eine winzige SSL/TLS Durchführung für eingebettete Geräte, die für die Bequemlichkeit des Gebrauches entworfen wird.
• CyaSSL: Eingebettete SSL/TLS Bibliothek mit einem starken Fokus auf der Geschwindigkeit und Größe.

Verweisungen und Kommentare

Weiterführende Literatur

• Das Schaffen von VPNs mit IPsec und SSL/TLS Linux Zeitschriftenartikel von Rami Rosen

Links

• SSL 2 Spezifizierung (veröffentlichter 1994)
• Frühe Entwürfe von SSL 3.0 Spezifizierung (veröffentlichter 1995)
• Die Protokoll-Version 3.0 (2011) von Secure Sockets Layer (SSL)
• Der IETF (Internettechnikeinsatzgruppe) TLS Workgroup
• SSL Tutorenkurs
• Sichere ECMAScript verwandeln Sich (Web 2 Sichere Gestalten Methode Um)
• OWASP: Transportschicht-Schutzpfuschzettel
• Ein Gespräch auf SSL/TLS, der versucht, Dinge in Begriffen zu erklären, die Leute verstehen könnten.
• SSL: Fundament für die Websicherheit