Re: Greman translation SSL-Intro

[Sascha Kersken]

Title: Starke SSL/TLS-Verschl�sselung: Eine Einf�hrung

Hi,   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&ouml;ne an den Standards ist, dass man unter so vielen ausw&auml;hlen   [Better to leave that indefinite:] "Das Sch&ouml;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&uuml;hrung f&uuml;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&uuml;r die Verwaltung von Zertifikaten innerhalb   [more literally] ist weder als ... gedacht, noch behandelt es spezielle Techniken f&uuml;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&uuml;cher (siehe zum Beispiel [<a href="">AC96</a>]) und dienen >  der Privacy, Integrit&auml;t und Authentifizierung.</p>   ... und bilden die Grundlage f&uuml;r Datenschutz, Integrit&auml;t und Authentifizierung.</p>   >      austauschen. Die Entscheidung f&uuml;r einen privaten Schl&uuml;ssel vor der   ... Die Auswahl eines privaten Schl&uuml;ssels   >      sch&uuml;tzen, es ist aber immer noch m&ouml;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&auml;t einer Nachricht zu gew&auml;hrleisten,   zu Gute geschrieben -> gutgeschrieben   >      wird. Stimmen beide &uuml;ber ein, wurde die Nachricht nicht ver&auml;ndert.</p>   [typo] &uuml;ber ein -> &uuml;berein   >  Mit Hilfe der Message Digests werden kurze Darstellungen in fester L&auml;nge >  von langen Nachrichten variableer L&auml;nge erzeugt. Digest Algorithmen >  sollen eine eindeutige Kurzzusammenfassung f&uuml;r unterschiedliche >  Nachrichten liefern.   [a few typos, and some proposals] Mit Hilfe von Message Digests werden aus langen Nachrichten mit variabler L&auml;nge kurze Darstellungen mit fester L&auml;nge erstellt. Digest-Algorithmen sollen aus unterschiedlichen Nachrichten [jeweils] eindeutige Zusammenfassungen erzeugen.   >  Sie sollen es unm&ouml;glich machen, die Nachricht anhand   unm&ouml;glich -> so schwer wie m&ouml;glich (original: "too difficult")   >  des Message Digest zu entschl&uuml;sseln oder zwei unterschiedliche Nachrichten   [change this corresponding to the previous note] ... entschl&uuml;sseln; und es soll unm&ouml;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&uuml;r diese Nachricht eignet. Sie sorgt ferner f&uuml;r die >  Unversehrtheit der Nachricht, weil niemand den Digest &auml;ndern und   ... So gew&auml;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&uuml;sselungsregeln definieren, wie diese Informationen in bin&auml;res Form   [typo] bin&auml;res Form -> die bin&auml;re Form   >      durch die Distinguished Encoding Rules (DER) definiert, die allgemeineren >      Basic Encoding Rules (BER) basieren. Bei &Uuml;bertragungen, wo kein bin&auml;res   [missing words] ... die auf den allgemeineren Basic Encoding Rules (BER) basieren.   >  anegeben wird.</p>   [typo] anegeben -> angegeben   >  ein Zertifikat ausstellen. Bei der &Uuml;berpr&uuml;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 &ouml;ffentlichen Schl&uuml;ssel verbreiten w&uuml;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&uuml;ltigkeitsdauer vin Zertifikaten fest, sie   [typo] vin -> von   >  erneuern sie und f&uuml;hren bereits ausgestellter Zertifikate, die ihre G&uuml;ltigkeit bereits >  verloren haben (Certificate Revocation Lists, oder CRLs). Angenommen,   ["Listen" was missing; avoid using "bereits" twice] erneuern sie und f&uuml;ren Listen bereits ausgestellter Zertifikate, die ihre G&uuml;ltigkeit verloren haben ...   >  <p>Wenn Sie eine Certificate Authority verwenden, die normalerweise nicht >  nicht standardm&auml;&szlig;ig  f&uuml;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&uuml;tzung vieler spezieller kryptografischer Algorithmen,   [missing word] Das Protokoll wurde zur Unterst&uuml;tzung ...   >  exportrechtlicher oder anderer Aspekte ausgew&auml;hlt werden. Dar&uuml;ber hinaus >  das Protokoll auch die Vorteile neuerer Algorithmen nutzen. Die getroffene   [missing word] ... Dar&uuml;ber hinaus kann das Protokoll ...   >          <td>Vorgeschlagener Internet Standard (IETF) [<a href=""   Internet Standard -> Internet-Standard   >          Nachrichtenreihenfolge sowie und weitere Alarmmeldungen.</td>   sowie und -> sowie | und [choose one]   >  das Laden Zertifikatketten unterst&uuml;tzt. Das bietet dem Server die M&ouml;glichkeit,   [missing word] das Laden von Zertifikatketten ...   >  [<a href="">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&uuml;ssel   [use '?'; typo] Signaturen sind zu verwenden? Das Signieren mit einem privaten ...   >   bietet Sicherheit gegen Angriffe aus den eigenen Reihen w&auml;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&auml;hrend des   >      <p>"CBC" steht heir f&uuml;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="">Abbildung 2</a>). Bei einem eingekapseltes Protokoll   eingekapseltes -> eingekapselten   >      Einrichtung der Session unverschl&uuml;sselt und werden ogne ohne Digest   ogne ohne -> ohne   >      verschl&uuml;sselt werden. (Hinwei.: Zur Zeit unterst&uuml;tzen die wichtigen   Hinwei. -> Hinweis   >      <p>Eine weitere Verwendungsm&ouml;glichkeit von SSL ist die Sicherung >      HTTP-Kommunikation zwischen Browser und Webserver. Das schlie&szlig;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: �berpr�fung von Zertifikatanforderungen Verarbeitung von Zertifikatanforderungen 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: 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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]