Title: Starke SSL/TLS-Verschlüsselung: Eine Einführung
Das Schöne an den Standards ist, dass man unter so vielen auswählen kann. Und wenn Ihnen keiner der Standards zusagt, dann müssen Sie nur ein weiteres Jahr warten bis der passende herausgegeben wird.
-- A. Tanenbaum, "Introduction to Computer Networks"
Dieses Kapitel ist ale Einführung für dielenigen gedacht, die zwar mit dem
Web, HTTP, und Apache vertraut sind, aber keine Sichetheitsexperten sind. Es
ist nicht als umfassendes Handbuch zum SSL-Protokoll gedacht und behandelt
auch keine speziellen Techniken für die Verwaltung von Zertifikaten innerhalb
eines Unternehmens oder wichtige juristische Aspekte zu Patenten oder den
Ein- und Ausfuhrbestimmungen. Es soll vielmehr
mod_ssl-Benutzern einen allgemeinen Hintergrund
vermitteln, indem die unterschiedlichen Konzepte, Definitionen und Beispielse
als Ausgangspunkt für die weitere Beschäftigung zusammengestellt werden.
Der Inhalt wurde mit Genehmigung des Autors anhand des Aufsatzes
Introducing
SSL und Certificates using SSLeay von Frederick J. Hirsch vom
Open Group Research Institute zusammengestellt, der in Web Security: A Matter of
Trust, World Wide Web Journal, Volume 2, Issue 3, Summer 1997,
veröffentlicht wurde. Positive Rückmeldungen senden Sie bitte an Frederick Hirsch (den Autor
des Aufsatzes) und negative Rückmeldungen an Ralf S. Engelschall (dem Entwickler
von
Zum Verständnis von SSL sind Kenntnisse über kryptographische Algorithmen, Message Digest-Funktionen (auch bekannt als Hashfunktionen) sowie über digitale Signaturen Voraussetzung. Diese Verfahren sind Thema ganzer Bücher (siehe zum Beispiel [AC96]) und dienen der Privacy, Integrität und Authentifizierung.
Wenn jemand einen Überweisungsauftrag an seine Bank sendet, dann handelt es sich um einen privaten Auftrag mit schützenswerten Angaben wie zum Beispiel der Kontonummer und dem Betrag. Eine Möglichkeit ist die Verwendung eines kryptographischen Algorithmus, ein Verfahren, bei dem die Nachricht so verschlüsselt wird, dass sie nur vom gewünschten Empfänger gelesen werden kann. Einmal in diese Form umgewandelt, kann diese Nachricht nur mit einem Schlüssel entziffert werden. Ohne diesen Schlüssel ist die Nachricht wertlos: Gute kryptografische Algorithmen machen Unbefugten eine Entschlüsselung so schwierig, dass der erforderliche Aufwand in keinem Verhältnis zum Nutzen mehr steht.
Es gibt zwei Kategorien kryptografischer Algorithmen: Konventionelle und öffentliche Schlüssel.
- Beim konventionellen Schlüssel
- oder symmetrischer Kryptografie besitzen Sender und Empfänger den gleichen Schlüssel: geheime Informationen, mit deren Hilfe eine Nachricht ver- oder entschlüsselt werden kann. Ist der Schlüssel geheim, dann können nur der Sender und der Empfänger die Nachricht lesen. Teilen Bank und Kunde einen geheimen Schlüssel, dann können sie private Nachrichten miteinander austauschen. Die Entscheidung für einen privaten Schlüssel vor der Kommunikation kann aber problematisch sein.
- Bei öffentlichen Schlüsseln
- oder asymmetrischer Kryptografie wird das Problem des Schlüsselaustauschs durch die Definition eines Algorithmus gelöst, der zwei Schlüssel verwendet, mit denen die Nachricht verschlüsselt werden kann. Wird die Nachricht mit dem einen Schlüssel verschlüsselt, muss sie mit dem anderen entschlüsselt werden. Auf diese Weise ist durch Veröffentlichung eines Schlüssels (des öffentlichen Schlüssels) und Geheimhaltung des anderen Schlüssels (des privaten Schlüssels) ein gesicherter Datenaustausch möglich.
Jeder kann mit dem öffentlichen Schlüssel eine Nachricht verschlüsseln, aber nur der Besitzer des privaten Schlüssels ist in der Lage, die Nachricht zu lesen. So können private Nachrichten an den Besitzer eines Schlüsselpaares (z.B die Bank) gesendet werden, indem die Nachricht mit dem öffentliche Schlüssel verschlüsselt wird. Nur die Bank kann die Nachricht entschlüsseln.
Der Bankkunde kann zwar die Nachricht verschlüsseln, um sie zu schützen, es ist aber immer noch mögich, dass irgend jemand die ursprüngliche Nachricht verändert oder sie durch eine andere ersetzt, um so beispielsweise zu erreichen, dass das Geld seinem eigenen Konto zu Gute geschrieben wird. Um die Integrität einer Nachricht zu gewährleisten, kann eine Art Quersumme der Nachricht gesendet werden, die dann beim Eingang mit der von der Bank selbst errechneten Quersumme verglichen wird. Stimmen beide über ein, wurde die Nachricht nicht verändert.
Eine solche Summenberechnung wird als Message Digest, als Einwegfunktion oder Hashfunktion bezeichnet. Mit Hilfe der Message Digests werden kurze Darstellungen in fester Länge von langen Nachrichten variableer Länge erzeugt. Digest Algorithmen sollen eine eindeutige Kurzzusammenfassung für unterschiedliche Nachrichten liefern. Sie sollen es unmöglich machen, die Nachricht anhand des Message Digest zu entschlüsseln oder zwei unterschiedliche Nachrichten erzeugen zu können, die den gleichen Digest liefern. Dadurch soll verhindert werden, dass eine Nachricht durch eine andere ersetzt werden kann, während der Digest unverändert bleibt.
Darüber hinaus muss noch ein sicherer Weg gefunden werden, wie der Digest sicher an die Bank gesendet werden kann. Erst wenn das möglich ist, ist die Unversehrtheit der dazugehörigen Nachricht gesichert. Dies kann durch Übernahme des Digest in eine digitale Signatur geschehen.
Wenn ein Überweisungsauftrag bei der Bank eingeht, muss gesichert sein, dass dieser tatsächlich von einem bestimmten Kunden und nicht von einem Eindringling in das System kommt. Eine vom Kunden erzeugte digitale Signatur, die vom Kunden mit der Nachricht verschickt wird, stellt dies sicher.
Digitale Signaturen werden erzeugt, indem ein Digest der Nachricht sowie weitere Informationen (beispielsweise eine Folgenummer) mit dem privaten Schlüssel des Senders verschlüsselt werden. Dann kann zwar die Signatur mit dem öffentlichen Schlüssel entschlüsselt werden, aber nur der Unterzeichner kennt den privaten Schlüssel. Das bedeutet, dass die Signatur nur von ihm stammen kann. Die Übernahme des Digest in die Signatur führt dazu, dass sie sich nur für diese Nachricht eignet. Sie sorgt ferner für die Unversehrtheit der Nachricht, weil niemand den Digest ändern und signieren kann.
Um ein Abfangen und eine Wiederverwendung der Signatur durch Angreifer zu einem späteren Zeitpunkt zu verhindern, enthält sie eine eindeutige Folgenummer. Dies schützt die Bank vor einer Täuschung durch den Kunden, der einfach vorgibt, die die Nachricht, die nur von ihm signiert sein kann, nicht gesendet zu haben.
Auch wenn der Kunde eine private Nachricht mit Signatur an die Bank gesendet hat, muss immer noch dafür gesorgt werden, dass der Kommunikationsaustausch tatsächlich mit der Bank stattfindet. Das bedeutet, dass er sicher sein muss, dass der von ihm verwendete öffentliche Schlüssel dem privaten Schlüssel der Bank entspricht. Umgegkehrt muss die Bank überprüfen, ob die Signatur des Kunden korrekt ist.
Jede Seite besitzt ein Zertifikat, das die Identität der anderen Seite überprüft, den öffentlichen Schlüssel bestätigt und von einer autorisierten Agentur gezeichnet ist, so dass beide sicher sein können, auch tatsächlich miteinander zu kommunizieren. Eine solche autorisierte Institution wird als Certificate Authority (CA) bezeichnet. Die von ihr ausgestellten Zertifikate werden für die Authentifizierung benutzt.
Ein Zertifikat verknüpft einen öffentlichen Schlüssel mit der tatsächlichen Identität eines Individuums, eines Servers oder einer anderen Entität, die als Subjekt bezeichnet wird. Wie aus Tabelle 1 hervorgeht, gehören zu den Informationen über das Subjekt Angaben zu Identifizierung (Distinguished Name) und der öffentliche Schlüssel. Außerdem gehören die Identifikation und die Signatur der ausstellenden Certificate Authority sowie die Gültigkeitsdauer für das Zertifikat dazu. Desweiteren können noch zusätzliche Informationen (oder Ergänzungen) sowie administrative Informationen für die Certificate Authority enthalten sein (z.B. eine Seriennummer).
| Subjekt | Distinguished Name, öffentlicher Schlüssel |
|---|---|
| Aussteller | Distinguished Name, Signatur |
| Gültigkeitsdauer | Nicht vorm (Datum), Nicht nach dem (Datum). |
| Administrative Informationen | Version, Seriennummer |
| Ergänzende Informationen | Einschränkungen, Netscape Flags usw. |
Mit dem Distinguished Name wird eine Identität für einen bestimmten Kontext angegeben -- eine Person kann beispielsweise einen Personalausweis und einen Dienstausweis besitzen. Distinguished Names werden vom X.509-Standard beschrieben [X509], der die Felder, Feldbezeichnungen und Abkürzungen für den Verweis auf diese Felder definiert (siehe Tabelle 2).
| DN-Feld | Abkürz. | Beschreibung | Beispiel |
|---|---|---|---|
| Common Name | CN | Der zu zertifizierende Name | CN=Joe Average |
| Organization or Company | O | Name der dazugehörigen Organisation |
O=Snake Oil, Ltd. |
| Organizational Unit | OU | Name der Unterabteilung |
OU=Research Institute |
| City/Locality | L | Name stammt aus dieser Stadt | L=Snake City |
| State/Province | ST | Name stammt aus Staat/Land | ST=Desert |
| Country | C | Name stammt aus Land (ISO-Code) | C=XZ |
Eine Certificate Authority kann festlegen, welche Felder des Distinguished
Name optional und welche erforderlich sind. Sie kann auch Anforderungen
an den Inhalt von Feldern stellen, was auch für die Benutzer der Zertifikate
gilt. Ein Netscape Browser verlangt beispielsweise, dass der Common
Name für ein Serverzertifikat einen Namen enthält, der mit einem Muster mit
Jokerzeichen für den Domänennamen dieses Servers übereinstimmt, zum
Beispiel *.snakeoil.com.
Das binäre Format eines Zertifikats wird mit Hilfe der ASN.1-Notation [X208] [PKCS] definiert. Diese Notation legt fest, wie Inhalte angegeben werden. Verschlüsselungsregeln definieren, wie diese Informationen in binäres Form umgewandelt werden. Die binäre Verschlüsselung des Zertifikats wird durch die Distinguished Encoding Rules (DER) definiert, die allgemeineren Basic Encoding Rules (BER) basieren. Bei Übertragungen, wo kein binäres Format verwendet werden kann, kann die binäre Fassung mit der Base64-Verschlüsselung in ASCII-Darstellung [MIME] umgewandelt werden. Diese zwischen ein Anfangs- und ein End-Tag gesetzte verschlüsselte Version heißt PEM-Format (von engl. Privacy Enhanced Mail). Ein Beispiel:
-----BEGIN Certificate----- MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt 2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7 dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ== -----END Certificate-----
Das Secure Sockets-Layer Protokoll ist eine Protokollschicht, die zwischen einem zuverlässigem verbindungsorientierten Netzwerkprotokoll (z.B. TCP/IP) und der Anwendungsprotokollschicht (z.B. HTTP) liegen kann. SSL ermöglicht eine sichere Kommunikation zwischen Client und Server mit Hilfe einer gegenseitigen Authentifizierung, der Verwendung digitaler Signaturen sowie einer Verschlüsselung zum Schutz der Privatsphäre.
Das Protokoll zur Unterstützung vieler spezieller kryptografischer Algorithmen, Message Digests und Signaturen entwickelt. Auf diese Weise können Algorithmen für bestimmte Server unter Berücksichtigung juristischer, exportrechtlicher oder anderer Aspekte ausgewählt werden. Darüber hinaus das Protokoll auch die Vorteile neuerer Algorithmen nutzen. Die getroffene Auswahl wird zu Beginn der Protokollsession zwischen Client und Server ausgehandelt.
| Version | Herkunft | Beschreibung | Unterstützte Browser |
|---|---|---|---|
| SSL v2.0 | Herstellerstandard (Netscape Corp.) [SSL2] | Erstes SSL-Protokoll, das implementiert wurde. | - NS Navigator 1.x/2.x - MS IE 3.x - Lynx/2.8+OpenSSL |
| SSL v3.0 | Überholter Internet-Entwurf (Netscape Corp.) [SSL3] | Revisionen zur Verhinderung bestimmter Angriffe auf die Sicherheit, neue nicht auf RSA basierende Algorithmen und Unterstützung von Zertifikatketten | - NS Navigator 2.x/3.x/4.x - MS IE 3.x/4.x - Lynx/2.8+OpenSSL |
| TLS v1.0 | Vorgeschlagener Internet Standard (IETF) [TLS1] | Revision von SSL 3.0 zur Anpassung der MAC-Schicht an HMAC, Blockauffüllung für Blockalgorithmen, Standardisierung der Nachrichtenreihenfolge sowie und weitere Alarmmeldungen. | - Lynx/2.8+OpenSSL |
Wie aus Tabelle 4 hervorgeht, gibt es mehrere Versionen des SSL-Protokolls. Die SSL-Version 3.0 hat den Vorteil, dass sie das Laden Zertifikatketten unterstützt. Das bietet dem Server die Möglichkeit, ein Serverzertifikat zusammen mit den Ausstellerzertifikaten an den Browser weiterzureichen. Das Laden von Ketten erlaubt dem Browser die Überprüfung des Serverzertifikats, selbst wenn die Zertifikate der Certificate Authority für einen dazwischenliegenden Aussteller nicht installiert sind, weil sie in der Zertifikatkette enthalten sind. SSL 3.0 ist die Basis für den [TLS]-Protokollstandard (Transport Layer Security) der zur Zeit von der Internet Engineering Task Force (IETF) entwickelt wird.
Die SSL-Session wird über eine Handshake-Sequenz zwischen Client und Server eingerichtet (siehe Abbildung 1. Diese Sequenz kann unterschiedlich ausfallen, je nach dem, ob der Server ein Serverzertifikat bereitstellt oder ein Zertifikat vom Client anfordert. In manchen Situationen sind zwar weitere Handshakes für den Umgang mit den Informationen zu den Verschlüsselungsalgorithmen erforderlich, hier soll aber nur ein allgemeines Szenario beschrieben werden (eine Beschreibung aller Möglichkeiten finden Sie in der SSL-Spezifikation).
Eine einmal eingerichtete SSL-Session kann wieder benutzt werden, was einen Leistungsverlust durch Wiederholung der für die Einrichtung einer Session erforderlichen Schritte vermeidet. Hierfür weist der Server jeder SSL-Session einen eindeutigen Session-Bezeichner zu, der im Server bis zu dessen Erlöschen zwischengespeichert wird und den der Client für spätere Verbindungen nutzen kann, um den Aufwand für die Handshakes zu reduzieren.
Abbildung 1: Vereinfachte
SSL-Handshake-Folge
Folgende Elemente werden in der Handshake-Folge von Client und Server benutzt:
- Aushandlung der für die Datenübertragung zu benutzenden Algorithmen
- Einrichtung und gemeinsame Nutzung eines Session-Schlüssels für Client und Server
- Optionale Authentifizierung des Servers gegenüber dem Client
- Optionale Authentifizierung des Clients gegenüber dem Server
Bei der Aushandlung der Algorithmenreihe legen Client und Server fest, welche Algorithmen von beiden unterstützt werden. Die SSL 3.0-Spezifikation definiert 31 Algorithmen. Die Definition der Algorithmenfolge enthält folgende Komponenten:
- Schlüsselaustauschmethode
- Algorhitmus für die Datenübertragung
- Message Digest für den Message Authentification Code (MAC)
Diese drei Elemente werden in den folgenden Abschnitten beschrieben.
Die Schlüsselaustauschmethode legt fest, welcher gemeinsam genutzte geheime symmetrische Schlüssel für die Datenübertragung zwischen Client und Server zu verwenden ist. SSL 2.0 verwendet nur RSA-Schlüssel, während SSL 3.0 eine Reihe von Algorithmen einschließlich dem RSA-Schlüsselaustausch bei Verwendung von Zertifikaten und dem Diffie-Hellman-Schlüsselaustausch zum Austausch von Schlüsseln ohne Zertifikate und ohne vorherige Kommunikation zwischen Client und Server zulässt.
Eine Variable bei der Auswahl der Schlüsselaustauschmethoden sind die digitalen Signaturen: Werden sie benutzt oder nicht? Und wenn ja, welche Signaturen sind zu verwenden. Das Signieren mit einem privater Schlüssel bietet Sicherheit gegen Angriffe aus den eigenen Reihen während des Informationsaustauschs bei Erzeugen des gemeinsamen Schlüssels [AC96, p516].
SSL verwendet die konventionelle Kryptografie (symmetrische Kryptografie), wie sie bereits im Zusammenhang mit der Verschlüsselung der Nachrichten einer Session beschrieben wurde. Neun Auswahlmöglichkeiten (einschließlich der Möglichkeit, auf eine Verschlüsselung zu verzichten) stehen zur Verfügung:
- Keine Verschlüsselung
- Stream-Algorithmen
- RC4 mit 40-Bit-Schlüssel
- RC4 mit 128-Bit-Schlüssel
- CBC-Blockalgorithmen
- RC2 mit 40 Bit-Schlüssel
- DES mit 40 Bit-Schlüssel
- DES mit 56 Bit-Schlüssel
- Triple-DES mit 168 Bit-Schlüssel
- Idea (128 Bit-Schlüssel)
- Fortezza (96 Bit-Schlüssel)
"CBC" steht heir für Cipher Block Chaining, was bedeutet, dass ein Teil des zuvor verschlüsselten Textes für die Verschlüsselung des aktuellen Blocks benutzt wird. "DES" steht für Data Encryption Standard [AC96, ch12], für den es mehrere Varianten gibt (einschließlich DES40 und 3DES_EDE). "Idea" ist einer der besten und stärksten kryptografischen Algorithmen und "RC2" ist ein proprietärer Algorithmus von RSA DSI [AC96, ch13].
Mit der Auswahl der Digest-Funktion wird fest gelegt, wie ein Digest erzeugt wird. SSL unterstützt folgende Möglichkeiten:
- Kein Digest (keine Auswahl)
- MD5, ein 128-Bit-Hashalgorithmus
- Secure Hash Algorithm (SHA-1), ein 160-Bit-Hashalgorithmus
Mit dem Message Digest-Algorithmus wird ein Message Authentification Code (MAC) erzeugt, der mit der Nachricht verschlüsselt wird, um die Unversehrtheit einer Nachricht überprüfen sowie ein Überschreiben mit anderen Inhalten verhindern zu können.
Für die Handshake-Folge werden drei Protokolle benutzt:
- Das SSL-Handshake-Protokoll zur Einrichtung der Client- und Server-SSL-Session.
- Das SSL Change Cipher Spec-Protokoll für die Festlegung der Algorithmen für die Session.
- Das SSL Alert-Protokoll zur Übermittlung von SSL-Fehlermeldungen zwischen Client und Server.
Diese Protokolle sowie die Applikationsprotokolldaten werden vom SSL Record-Protokoll eingekapselt (siehe Abbildung 2). Bei einem eingekapseltes Protokoll werden die Daten zwischen der darunterliegenden Protokollschicht übertragen, die die Daten nicht untersucht. Das eingekapselte Protokoll weiß nichts über das zugrunde liegende Protokoll.
Abbildung 2: Der
SSL-Protokoll-Stack
Die Einkapselung der SSL-Kontrollprotokolle durch das Record-Protokoll führt dazu, dass bei einer erneuten Aushandlung einer aktiven Session die Kontrollprotokolle sicher übertragen werden. Gab es zuvor keine Session, wird keine Verschlüsselung verwendet und die Nachrichten bleiben bis zur Einrichtung der Session unverschlüsselt und werden ogne ohne Digest gesendet.
Mit dem in Abbildung 3 gezeigten SSL Record-Protokoll werden Anwendungungs- und SSL-Kontrolldaten zwischen Client und Server übertragen, wobei diese Daten möglicherweise in kleinere Pakete unterteilt oder mehrere Nachrichten von Protokollen höherer Ebenen zu Einheiten zusammengefasst werden. Diese Einheiten können vor der Übertragung mit dem zugrundeliegenden sicheren Transportprotokoll komprimiert, mit Digest-Signaturen versehen und verschlüsselt werden. (Hinwei.: Zur Zeit unterstützen die wichtigen SSL-Implementatierungen keine Komprimierung).
Abbildung 3: Das
SSL Record-Protokoll
Eine weitere Verwendungsmöglichkeit von SSL ist die Sicherung
HTTP-Kommunikation zwischen Browser und Webserver. Das schließt die
Verwendung von unsicherem HTTP nicht aus. Die sichere Version ist
im Wesentlichen HTTP über SSL (HTTPS), allerdings mit dem
Hauptunterschied, dass das URL-Schema https an Stelle
von http sowie ein anderer Server-Port (standardmäßig 443)
benutzt werden. Das waren die wesentlichen Eigenschaften, die
- [AC96]
- Bruce Schneier,
Applied Kryptografie
, 2nd Edition, Wiley, 1996. Siehe http://www.counterpane.com/ für weitere Beiträge von Bruce Schneier. - [X208]
- ITU-T Recommendation X.208,
Specification of Abstract Syntax Notation One (ASN.1)
, 1988. Siehe beispielsweise http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.208-198811-I. - [X509]
- ITU-T Recommendation X.509,
The Directory - Authentification Framework
. Siehe beispielsweise http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509. - [PKCS]
Public Key Cryptography Standards (PKCS)
, RSA Laboratories Technical Notes, Siehe http://www.rsasecurity.com/rsalabs/pkcs/.- [MIME]
- N. Freed, N. Borenstein,
Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
, RFC2045. Siehe beispielsweise http://ietf.org/rfc/rfc2045.txt. - [SSL2]
- Kipp E.B. Hickman,
The SSL Protocol
, 1995. See http://www.netscape.com/eng/security/SSL_2.html. - [SSL3]
- Alan O. Freier, Philip Karlton, Paul C. Kocher,
The SSL Protocol Version 3.0
, 1996. Siehe http://www.netscape.com/eng/ssl3/draft302.txt. - [TLS1]
- Tim Dierks, Christopher Allen,
The TLS Protocol Version 1.0
, 1999. Siehe http://ietf.org/rfc/rfc2246.txt.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
