You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@httpd.apache.org by Jobst Giesecke <JG...@t-online.de> on 2004/01/14 13:29:19 UTC
Greman translation SSL-Intro
Re: Greman translation SSL-Intro
Posted by Sascha Kersken <sk...@lingoworld.de>.
Starke SSL/TLS-Verschlüsselung: Eine EinführungHi,
these are just some remarks/proposals concerning the translation of the SSL Intro. I will review the rest of the SSL translations during the next few days.
Is there anything else that has not found it's reviewer yet?
Regards,
Sascha
================
> <p>Das Schöne an den Standards ist, dass man unter so vielen auswählen
[Better to leave that indefinite:] "Das Schöne an Standards ..."
[instead of "DEN Standards ...";
or is this the 'official' translation from the German edition?]
> nur ein weiteres Jahr warten bis der passende herausgegeben wird.</p>
[comma]
nur ein weiteres Jahr warten, bis ...
> <p>Dieses Kapitel ist ale Einführung für dielenigen gedacht, die zwar mit dem
[typo]
dielenigen -> diejenigen
> Web, HTTP, und Apache vertraut sind, aber keine Sichetheitsexperten sind. Es
[typo]
Sichetheitsexperten -> Sicherheitsexperten
> ist nicht als umfassendes Handbuch zum SSL-Protokoll gedacht und behandelt
> auch keine speziellen Techniken für die Verwaltung von Zertifikaten innerhalb
[more literally]
ist weder als ... gedacht, noch behandelt es
spezielle Techniken für ...
> Ein- und Ausfuhrbestimmungen. Es soll vielmehr
> <code>mod_ssl</code>-Benutzern einen allgemeinen Hintergrund
[word order]
... Es soll <code>mod_ssl</code>-Benutzern vielmehr ...
> vermitteln, indem die unterschiedlichen Konzepte, Definitionen und Beispielse
[typo]
Beispielse -> Beispiele
> Algorithmen, Message Digest-Funktionen (auch bekannt als Hashfunktionen)
[original: "(aka. one-way or hash functions)"]
(auch bekannt als Einweg- oder Hashfunktionen)
> ganzer Bücher (siehe zum Beispiel [<a href="#AC96">AC96</a>]) und dienen
> der Privacy, Integrität und Authentifizierung.</p>
... und bilden die Grundlage für Datenschutz, Integrität und
Authentifizierung.</p>
> austauschen. Die Entscheidung für einen privaten Schlüssel vor der
... Die Auswahl eines privaten Schlüssels
> schützen, es ist aber immer noch mögich, dass irgend jemand die
[typo]
irgend jemand -> irgendjemand
> so beispielsweise zu erreichen, dass das Geld seinem eigenen Konto zu
> Gute geschrieben wird. Um die Integrität einer Nachricht zu gewährleisten,
zu Gute geschrieben -> gutgeschrieben
> wird. Stimmen beide über ein, wurde die Nachricht nicht verändert.</p>
[typo]
über ein -> überein
> 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.
[a few typos, and some proposals]
Mit Hilfe von Message Digests werden aus langen Nachrichten mit variabler
Länge kurze Darstellungen mit fester Länge erstellt. Digest-Algorithmen
sollen aus unterschiedlichen Nachrichten [jeweils] eindeutige Zusammenfassungen
erzeugen.
> Sie sollen es unmöglich machen, die Nachricht anhand
unmöglich -> so schwer wie möglich (original: "too difficult")
> des Message Digest zu entschlüsseln oder zwei unterschiedliche Nachrichten
[change this corresponding to the previous note]
... entschlüsseln; und es soll unmöglich sein, zwei unterschiedliche ...
> Eindringling in das System kommt. Eine vom Kunden erzeugte
> <em>digitale Signatur</em>, die vom Kunden mit der Nachricht verschickt wird,
[avoid using "vom Kunden" twice]
... Eine <em>digitale Signatur</em>, die vom Kunden erzeugt und
mit der Nachricht verschickt wird,
> 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
... So gewährleistet sie auch die Unversehrtheit der Nachricht, ...
> <td>Nicht vorm (Datum), Nicht nach dem (Datum).</td></tr>
vorm -> vor dem
> gilt. Ein Netscape Browser verlangt beispielsweise, dass der Common
Netscape Browser -> Netscape-Browser
> Verschlüsselungsregeln definieren, wie diese Informationen in binäres Form
[typo]
binäres Form -> die binäre Form
> durch die Distinguished Encoding Rules (DER) definiert, die allgemeineren
> Basic Encoding Rules (BER) basieren. Bei Übertragungen, wo kein binäres
[missing words]
... die auf den allgemeineren Basic Encoding Rules (BER) basieren.
> anegeben wird.</p>
[typo]
anegeben -> angegeben
> ein Zertifikat ausstellen. Bei der Überprüfung eines Zertifikats kann muss
kann muss -> muss
> denn es bliebe nicht lange verborgen, wenn jemand anderes unter Vorgabe diese
> Certificate Authority zu sein, einen öffentlichen Schlüssel verbreiten würde. Die
... wenn jemand anders unter dem Vorwand, diese Certificate Authority zu sein, einen ...
> Browsers sind bereits so konfiguriert, dass sie bekannten Certificate Authorities
Browsers -> Browser
> verwalten sie auch, d.h. sie legen die Gültigkeitsdauer vin Zertifikaten fest, sie
[typo]
vin -> von
> erneuern sie und führen bereits ausgestellter Zertifikate, die ihre Gültigkeit bereits
> verloren haben (Certificate Revocation Lists, oder CRLs). Angenommen,
["Listen" was missing; avoid using "bereits" twice]
erneuern sie und füren Listen bereits ausgestellter Zertifikate, die ihre
Gültigkeit verloren haben ...
> <p>Wenn Sie eine Certificate Authority verwenden, die normalerweise nicht
> nicht standardmäßig für die Browser konfiguriert ist, dann muss das Zertifikat
> Certificate Authority in den Browser geladen werden, damit er die von der
nicht nicht -> nicht
... dann muss das Zertifikat der Certificate Authority ...
> <p>Das Protokoll zur Unterstützung vieler spezieller kryptografischer Algorithmen,
[missing word]
Das Protokoll wurde zur Unterstützung ...
> exportrechtlicher oder anderer Aspekte ausgewählt werden. Darüber hinaus
> das Protokoll auch die Vorteile neuerer Algorithmen nutzen. Die getroffene
[missing word]
... Darüber hinaus kann das Protokoll ...
> <td>Vorgeschlagener Internet Standard (IETF) [<a href="#TLS1"
Internet Standard -> Internet-Standard
> Nachrichtenreihenfolge sowie und weitere Alarmmeldungen.</td>
sowie und -> sowie | und [choose one]
> das Laden Zertifikatketten unterstützt. Das bietet dem Server die Möglichkeit,
[missing word]
das Laden von Zertifikatketten ...
> [<a href="#TLS1">TLS</a>]-Protokollstandard (Transport Layer Security)
> der zur Zeit von der Internet Engineering Task Force (IETF) entwickelt wird.</p>
[missing comma; new orthography: "zurzeit"]
(Transport Layer Security), der zurzeit ...
> Signaturen sind zu verwenden. Das Signieren mit einem privater Schlüssel
[use '?'; typo]
Signaturen sind zu verwenden? Das Signieren mit einem privaten ...
> bietet Sicherheit gegen Angriffe aus den eigenen Reihen während des
[man-in-the-middle attacks are not "Angriffe aus den eigenen Reihen"
(attacks from within your own network), but attacks from a location
BETWEEN the two endpoints of a network connection]
bietet Sicherheit gegen "Man in the Middle"-Angriffe während des
> <p>"CBC" steht heir für Cipher Block Chaining, was bedeutet, dass
[typo]
heir -> hier
> <p>Mit der Auswahl der Digest-Funktion wird fest gelegt, wie ein Digest
[typo]
fest gelegt -> festgelegt
> <p>Diese Protokolle sowie die Applikationsprotokolldaten werden vom
[I prefer this one; it might simply be a matter of taste]
Applikationsprotokolldaten -> Anwendungsprotokolldaten
> <a href="#figure2">Abbildung 2</a>). Bei einem eingekapseltes Protokoll
eingekapseltes -> eingekapselten
> Einrichtung der Session unverschlüsselt und werden ogne ohne Digest
ogne ohne -> ohne
> verschlüsselt werden. (Hinwei.: Zur Zeit unterstützen die wichtigen
Hinwei. -> Hinweis
> <p>Eine weitere Verwendungsmöglichkeit von SSL ist die Sicherung
> HTTP-Kommunikation zwischen Browser und Webserver. Das schließt die
[missing word]
... die Sicherung der HTTP-Kommunikation ...
> benutzt werden. Das waren die wesentlichen Eigenschaften, die
Das waren -> Das sind
> <dd>Bruce Schneier, <q>Applied Kryptografie</q>, 2nd Edition, Wiley,
[ used search/replace? ;-) ]
Kryptografie -> Cryptography
> <dd>Kipp E.B. Hickman, <q>The SSL Protocol </q>, 1995. See <a
See -> Siehe
----- Original Message -----
From: Jobst Giesecke
To: docs@httpd.apache.org
Sent: Wednesday, January 14, 2004 1:29 PM
Subject: Greman translation SSL-Intro
------------------------------------------------------------------------------
SSL/TLS
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 mod_ssl).
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-----Die Certificate Authority überprüft die Identität des Eigentümers eines privaten Schlüssels eines Schlüsselpaares vor der Ausstellung des Zertifikats anhand der Informationen aus der Zertifikatsanforderung. Fordert jemand ein persönliches Zertifikat an, dann muss die Certificate Authority zuerst sicherstellen, dass der Antragsteller tatsächlich mit der Person übereinstimmt, die im Zertifikat anegeben wird.
Eine Certificate Authority kann auch für eine andere Certificate Authority ein Zertifikat ausstellen. Bei der Überprüfung eines Zertifikats kann muss ein Bankkunde beispielsweise das Zertifikat des Ausstellers für jede übergeordnete Certificate Authority in Betracht ziehen, bis er zu dem Zertifikat gelangt, welchem er vertraut. Er kann sich dazu entschließen, nur Zertifikaten mit einer begrenzten Kette von Ausstellern zu vertrauen, um das Risiko eines nicht vertrauenswürdigen Zertifikats in der Kette zu reduzieren.
Wie bereits erwähnt wurde, benötigt jedes Zertifikat einen Aussteller, der die Gültigkeit der Identität des Zertifikatsubjekts bis zur obersten Certificate Authority (CA) bestätigt. Was ist jedoch mit der obersten Certificate Authority, für die es keinen Aussteller gibt? In diesem einzigen Fall ist das Zertifikat "selbstsigniert", der Aussteller des Zertifikats also mit dem Subjekt identisch. Das erfordert zusätzliche Vorsicht, wenn einem selbstsignierten Zertifikat vertraut werden soll. Die weite Verbreitung eines öffentlichen Schlüssels durch die oberste Autorität verringert das Risiko beim Vertrauen auf diesen Schlüssel, denn es bliebe nicht lange verborgen, wenn jemand anderes unter Vorgabe diese Certificate Authority zu sein, einen öffentlichen Schlüssel verbreiten würde. Die Browsers sind bereits so konfiguriert, dass sie bekannten Certificate Authorities vertrauen.
Eine Reihe von Firmen wie Thawte und VeriSign haben sich als Certificate Authorities etabliert. Diese Firmen bieten folgende Dienste an:
a.. Überprüfung von Zertifikatanforderungen
b.. Verarbeitung von Zertifikatanforderungen
c.. Austellen und Verwalten von Zertifikaten
Sie können sich auch eine eigene Certificate Authority einrichten. Das mag für das Internet zwar riskant sein, für ein Intranet, bei dem die Identität von Personen und Servern leicht zu überprüfen ist, kann das jedoch sinnvoll sein.
Für eine verantwortliche Einrichtung einer Certificate Authority ist ein solider administrativer, technischer und verwaltungstechnischer Rahmen erforderlich. Certificate Authorities stellen nicht nur Zertifikate aus, sie verwalten sie auch, d.h. sie legen die Gültigkeitsdauer vin Zertifikaten fest, sie erneuern sie und führen bereits ausgestellter Zertifikate, die ihre Gültigkeit bereits verloren haben (Certificate Revocation Lists, oder CRLs). Angenommen, ein Firmenangestellter besitzt ein Zertifikat, dessen Gültigkeit widerrufen werden muss, wenn der Angestellte die Firma verlässt. Da Zertifikate Objekte sind, die herumgereicht werden, ist am Zertifikat allein nicht zu erkennen, dass es widerrufen wurde. Bei der Überprüfung der Zertifikate auf Gültigkeit muss daher die ausstellende Certificate Authority kontaktiert werden, damit die CRLs überprüft werden können, was normalerweise nicht automatisch im Ablauf vorgesehen ist.
Wenn Sie eine Certificate Authority verwenden, die normalerweise nicht nicht standardmäßig für die Browser konfiguriert ist, dann muss das Zertifikat Certificate Authority in den Browser geladen werden, damit er die von der Certificate Authority gezeichneten Serverzertifikate überprüfen kann. Das kann gefährlich werden, denn einmal geladen, akzeptiert der Browser alle von dieser Certificate Authority gezeichneten Zertifikate.
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:
1.. Aushandlung der für die Datenübertragung zu benutzenden Algorithmen
2.. Einrichtung und gemeinsame Nutzung eines Session-Schlüssels für Client und Server
3.. Optionale Authentifizierung des Servers gegenüber dem Client
4.. 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:
a.. Schlüsselaustauschmethode
b.. Algorhitmus für die Datenübertragung
c.. 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:
a.. Keine Verschlüsselung
b.. Stream-Algorithmen
a.. RC4 mit 40-Bit-Schlüssel
b.. RC4 mit 128-Bit-Schlüssel
c.. CBC-Blockalgorithmen
a.. RC2 mit 40 Bit-Schlüssel
b.. DES mit 40 Bit-Schlüssel
c.. DES mit 56 Bit-Schlüssel
d.. Triple-DES mit 168 Bit-Schlüssel
e.. Idea (128 Bit-Schlüssel)
f.. 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:
a.. Kein Digest (keine Auswahl)
b.. MD5, ein 128-Bit-Hashalgorithmus
c.. 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:
a.. Das SSL-Handshake-Protokoll zur Einrichtung der Client- und Server-SSL-Session.
b.. Das SSL Change Cipher Spec-Protokoll für die Festlegung der Algorithmen für die Session.
c.. 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 mod_ssl für den Apache-Webserver zu bieten hat...
[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: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org