Title: Starke SSL/TLS-Verschlüsselung: Eine Einführung
SSL/TLS Das Schöne an 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 diejenigen gedacht, die zwar mit dem Web, HTTP, und Apache vertraut sind, aber keine Sicherheitsexperten 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
mod_ssl-Benutzern vielmehr einen allgemeinen Hintergrund vermitteln, indem die unterschiedlichen Konzepte, Definitionen und Beispiele 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
mod_ssl ).Kryptografische Techniken 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 bilden die Grundlage für Datenschutz, Integrität und Authentifizierung.
Kryptografische Algorithmen 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.
Message Digests 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 gutgeschrieben 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 überein, wurde die Nachricht nicht verändert.
Eine solche Summenberechnung wird als Message Digest, als Einwegfunktion oder Hashfunktion bezeichnet. Mit Hilfe der Message Digests werden aus langen Nachrichten mit variabler Länge kurze Darstellungen in fester Länge erstellt. Digest-Algorithmen sollen aus unterschiedlichen Nachrichten jeweils eindeutige Kurzzusammenfassungen erzeugen. Sie sollen es so schwer wie mö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.
Digitale Signaturen 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 erzeugt und mit der Nachricht verschickte digitale Signatur 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 gewährleistet auch 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.
Zertifikate 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.
Der Inhalt von Zertifikaten 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).
Tabelle 1: Informationen in Zertifikaten
Subjekt Distinguished Name, öffentlicher Schlüssel Aussteller Distinguished Name, Signatur Gültigkeitsdauer Nicht vor dem (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).
Tabelle 2: Angaben zum Distinguished Name
DN-Feld Abkürz. Beschreibung Beispiel Common Name CN Der zu zertifizierende Name CN=Joe Average Organization or Company O Name der dazugehörigen
OrganisationO=Snake Oil, Ltd. Organizational Unit OU Name der
UnterabteilungOU=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ärer Form umgewandelt werden. Die binäre Verschlüsselung des Zertifikats wird durch die Distinguished Encoding Rules (DER) definiert, die auf 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:
Beispiel für ein PEM-verschlüsseltes Zertifikat (snakeoil.crt) -----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-----Secure Sockets Layer (SSL) 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 wurde 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 kann das Protokoll auch die Vorteile neuerer Algorithmen nutzen. Die getroffene Auswahl wird zu Beginn der Protokollsession zwischen Client und Server ausgehandelt.
Tabelle 4: Versionen des SSL-Protokolls
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+OpenSSLSSL 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+OpenSSLTLS 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 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 von 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 zurzeit von der Internet Engineering Task Force (IETF) entwickelt wird.
Einrichtung der Session 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).
Hinweis 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-FolgeFolgende 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.
Schlüsselaustauschmethode 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 "Man in Middle"-Angriffe aus den eigenen Reihen während des Informationsaustauschs bei Erzeugen des gemeinsamen Schlüssels [AC96, p516].
Der Algorhitmus für die Datenübertragung 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 hier 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].
Digest-Funktion Mit der Auswahl der Digest-Funktion wird festgelegt, 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.
Das Handshake-Folgeprotokoll 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 Anwendungsprotokolldaten werden vom SSL Record-Protokoll eingekapselt (siehe Abbildung 2). Bei einem eingekapselten 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-StackDie 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 ohne Digest gesendet.
Datenübertragung 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. (Hinweis: Zur Zeit unterstützen die wichtigen SSL-Implementatierungen keine Komprimierung).
Abbildung 3: Das SSL Record-ProtokollDie HTTP-Kommunikation sichern Eine weitere Verwendungsmöglichkeit von SSL ist die Sicherung der 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
httpsan Stelle vonhttpsowie ein anderer Server-Port (standardmäßig 443) benutzt werden. Das sind die wesentlichen Eigenschaften, diemod_ssl für den Apache-Webserver zu bieten hat...Literaturhinweise
- [AC96]
- Bruce Schneier,
Applied Cryptography, 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]
- [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. Siehe 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]
