httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sascha Kersken" ...@lingoworld.de>
Subject Re: Greman translation SSL-Intro
Date Mon, 19 Jan 2004 23:02:08 GMT
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&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">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="#TLS1"

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="#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&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="#figure2">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:

    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
Mime
View raw message