Diskussion:Hypertext Transfer Protocol Secure

aus Wikipedia, der freien Enzyklopädie

Inhaltsverzeichnis 1 https ist kein Protokoll 2 Ablauf 3 Copyright-Verletzung?? 4 Ablauf des TLS Handshakes 5 Bitte überarbeiten 6 Allgemeinverständliche Erklärung 6.1 Umgangssprachliche Beschreibung 6.1.1 Zertifikat 6.1.2 Verschlüsselte Verbindung 7 Häufiger Vandalismus 8 Vergleich mit E-Mail

[Bearbeiten] https ist kein Protokoll

Der erste Satz ist mir irreführend bis falsch erschienen. https ist kein eigenes Protokoll sondern ganz einfaches HTTP mit SSL-Verschlüsselung in der Schicht drunter. Das "https" ist nur ein URI-Schema, dass das anzeigen soll (siehe auch die englische Wikipedia).

Eigentlich müsste man den Titel des Artikels auch noch anpassen. Er schreibt sich wohl eher "https" (siehe wieder den englischen Artikel).

--193.81.246.92 10:17, 9. Mai 2006 (CEST)

[Bearbeiten] Ablauf

Ist der Ablauf nicht falsch? Wieso sollte da erst ein Diffi Hellman Schlüsselaustausch geamcht werden? Um danach Zertifkate zu verschicken, das macht doch gar keinen Sinn: ein Zertifikat darf doch jedermann sehen. Und danach die Kommunikation asymmetrisch zu verschlüsseln wäre zu aufwendig.

Ich denke es ist eher so richtig. 1. Server schickt sein Zertifikat an den Browser. 2. Browser überprüft das Zertifkat mittels des CA Zertifkats 3. Wenn es OK ist, generiert der Browser einen symmetrischen Sitzungsschlüssel und verschlüsselt diesen mit dem öffentlichen Schlüssel aus dem Zertifikat. 4. Browser schickt den verschlüsselten Sitzungschlüssel an dern Server, der packt ihn aus. 5. Die Kommunikation ist durch einen symmetrischen Schlüssel gesichert.

[Bearbeiten] Copyright-Verletzung??

Hallo, habe fast den gleichen Text zu HTTPS unter folgender URL gefunden:

http://www.ilexikon.com/HTTPS.html

Einer scheint da abgekupfert zu haben...

Das Übernehmen von Inhalten aus der Wikipedia ist ausdrücklich erlaubt, sofern die Lizenzbestimmungen eingehalten werden. ilexikon.com nennt zumindest die Quelle, verlinkt den Originalartikel und verweist auf die GNU FDL. Siehe auch Projekte, die die Wikipedia als Quelle benutzen. -- molily 22:07, 21. Jun 2005 (CEST)

[Bearbeiten] Ablauf des TLS Handshakes

Der beschriebene Ablauf des TLS Handshakes ist nicht korrekt dargestellt. Im Dokument http://www.ietf.org/rfc/rfc2246.txt ist die richtige Vorgehensweise dargestellt. Wärend den Hello Messages wird im Zertifikat die Schlüssel Spec übertragen. Dort ist entweder mittels RSA ein Secret Key verschlüsselt enthalten oder die DH Parameter.

Gruß, duisentrieb 15:00, 25. Nov 2005 (CEST)

Ich gebe Herrn Duisentrieb Recht. Es wird beschrieben, dass die asymmetrischen Schlüssel zur Verschlüsselung eingesetzt werden. Dies ist falsch. Vielmehr wird aus Performancegründen zur Verschlüsselung der Nutzdaten ein symmetrisches Verfahren bzw. ein symmetrischer Sitzungsschlüssel eingesetzt, welches z.B. mit 128 Bit verschlüsselt. Siehe hierzu auch Transport Layer Security. Ein asymmetrisches Verfahren mit einer Breite von 128 Bit wäre zudem höchst unsicher. Symmetrische Verfahren werden im Allgemeinen vorzugsweise zur Authentifzierung, Signierung und als Transporthülle für performantere Verfahren verwendet. Unter http://www.softed.de/fachthema/Allgemeines/https.asp ist sehr schön dargestellt wie das funktioniert. Ich habe mich aus diesem Grund erdreistet den Artikel an besagter Stelle zu modifizieren.

Gruß Airmann 14:08, 20. Apr 2006 (CEST)

[Bearbeiten] Bitte überarbeiten

Lieber Autor, die vorigen Kommentare sind korrekt. Der Artikel bedarf dringend einer Überarbeitung. ArminGraefe 17:19, 17. Jan 2006 (CET)

Das sehe ich genauso --212.80.239.231 12:46, 5. Mär 2006 (CET) - kritische Punkte sind:

• TLS erlaubt Diffie-Hellman oder auch RSA
• Es herrscht keine Klarheit über den Einsatz von asymm. Krypto und symm. Krypto

Der Ablauf gestaltet sich doch wie folgt (siehe RFC 2246 und RFC 2818):

1. Client möchte einen HTTP-Request starten, dazu wird das darunterliegende TLS-Protokoll abgearbeitet:
   1. Client:
      • ClientHello - Protokollversion, Client-Zufallszahl, SitzungsID, Info zur Chiffrenmenge (CipherSuite), Kompressionsmethoden
   2. Server:
      • ServerHello - Protokollversion, Server-Zufallszahl, SitzungsID, Info zur Chiffrenmenge (CipherSuite), Kompressionsmethoden
      • (optional) ServerCertificate - enthält schon Kryptoinfo, wie RSA Public Key bis 512Bits, DH/DSS Keys
      • (optional) ServerKeyExchange - weiter Kryptoinfo falls notwendig
      • (optional) CertificateRequest - fordert vom Client ein Zert.
      • ServerHelloDone - der Server ist mit ServerHello fertig
   3. Client:
      • (falls Server dies verlangte/optional) ClientCertificate - zur ClientAuthentifizierung
      • ClientKeyExchange - bei Diffie-Hellmann der Clientteil zum Erzeugen des gemeinsamen Geheimnises oder bei RSA ein mit dem PublicKey des Servers verschlüsseltes Geheimnis (z.B. eine Zufallszahl); beide haben nun ein gemein. Geheimnis, das pre_master_secret (bis hier ist der Einsatz von asymmetrischer Krypto, ich zähle DH mal dazu, notwendig)
      • (optional) CertificateVerify - keine Ahnung was das macht; mir gibt die RFC 2246 in Absatz 7.4.8 wenig Aufschluß
      • ChangeCipherSpec - Minisubprotokoll: eine verschlüsselte Nachricht wird übertragen, die Änderungen bezüglich der Chiffrierung enthält
      • Finish - wird direkt nach ChangeCipherSpec übertragen, laut RFC 2246 Absatz 7.4.9 ist dies die erste mit der ausgehandelten Chiffrierung verschlüsselte Nachricht; ich nehme daher an, dass ChangeCipherSpec noch mit dem pre_master_secret verschlüsselt wird, Finish dann mit dem in ChangeCipherSpec gewählten Algorithmus (z.B. AES) und dem mastersecret = pseudorandomfunction(pre_master_secret, "mastersecret", clientRandom + serverRandom) verschlüsselt wird (ab hier wird aus Effizienzgründen sicher mit symmetrischer Krypto, z.B. DES/AES, weitergerechnet - prinzipiell kann mit ChangeCipherSpec aber auch asymmetrische vereinbart werden, da das Protokoll meiner Meinung nach keine Einschränkungen trifft?!)
   4. Server:
      • ChangeCipherSpec - siehe Client
      • Finish - siehe Client
2. TLS Handshake ist beendet - Client und Server können verschlüsselt kommunizieren:
3. Client
   • Encrypt(HTTP GET)
4. Server
   • Decrypt(Encrypt(HTTP GET)) = HTTP GET
   • Encrypt(HTTP 200 OK content)
5. Client
   • Decrypt(Encrypt(HTTP 200 OK content)) = HTTP 200 OK content
6. usw.

die Kennzeichnung "optional" ist eigentlich nicht 100prozentig korrekt - RFC 2246: optionale oder situationsbedingte Nachrichten, die nicht immer gesendet werden (z.B. wenn der Server keinen Public Key sendet oder seinen Teil des DH-Schlüsselaustausch nicht erfüllt kann der Client nicht für den Server verschlüsseln bzw. beide besitzen kein gemeinsames Geheimnis)

[Bearbeiten] Allgemeinverständliche Erklärung

Hallo,

Ich habe den Edit von 84.19.199.87 aus dem Artikel hierher verschoben, da die Form leider noch nicht in eine Enzyklopädie passt. Bitte hier fertigstellen, kommt nach Abschluss der ARbeiten wieder in den Artikel. --jha 16:42, 4. Mär 2006 (CET)

• Re: *dumm gefragt* in welcher Form passt er dann ins Wiki - ich bin der Meinung, dass der fachliche background wichtig ist, aber es sollte auch mal für jedermann verständlich erklärt werden (mit Analogien kann man da viel tun - muss natürlich hervorgehoben werden) PS: onlineverfügbare quelle ist das Skript von Andreas Pfitzmann: Sicherheit in Rechnernetzen

[Bearbeiten] Umgangssprachliche Beschreibung

Der Ablauf beginnt damit, dass ein "Zertifikat" übermittelt und anschließend eine verschlüsselte Verbindung eingerichtet wird.

[Bearbeiten] Zertifikat

Wichtig ist dabei, dass der Server (z.B. www.XYZ.de) dem Browser und damit dem Benutzer zunächst ein Zertifikat vorweist. Dieses sollte der Benutzer prüfen! Es handelt sich hierbei vergleichsweise um ein Dokument auf dem steht, dass der Server www.XYZ.de tatsächlich der Organisation XYZ zugehört. Dieses Dokument kann zunächst jeder beliebig erzeugen. Damit dieses auch vertrauenswürdig ist wird es von jemanden (z.B. Signierer) digital signiert/unterschrieben. Beispielsweise ist die Firma Verisign jemand, der solche digitalen Unterschriften leistet. Die Unterschift muss nicht zwangsweise von einer großen Firma geleistet werden, sondern kann durch eine beliebige "Instanz" (Person oder Computer) erfolgen.

Ein Zertifikat ist also ein Dokument mit einer Unterschrift (informell gesprochen).

D.h. der Benutzer bekommt mit dem Zertifikat angezeigt WEN (z.B. XYZ) er kontaktiert hat und WER (z.B. Signierer) bestätigt, dass dies auch wirklich so ist (Signierer bestätigt, das XYZ tatsächlich XYZ ist). Der Knackpunkt ist also: "Ist Signierer vertrauenswürdig" - sprich hat Signierer geprüft ob XYZ auch wirklich XYZ ist. Dies sollte in Zweifel gezogen werden, wenn Signierer unbekannt oder gar XYZ selbst ist (man kann sich selbst immer bescheinigen, dass man derjenige ist, der man vorgibt zu sein).

[Bearbeiten] Verschlüsselte Verbindung

Vertraut man darauf, dass www.XYZ.de zu XYZ gehört, dann schickt der Server dem Browser einen Kasten mit einem offenem Schnappschloß (z.B. Schloß1) zu dem nur der Server den Schlüssel (z.B. Schlüssel1) besitzt (das Schnappschloß repräsentiert sogenannte asymmetrische Kryptographie/Algorithmen; z.B. RSA). In diesen Kasten legt der Browser einen Schlüssel (z.B. Schlüssel2), den zunächst nur der Browser besitzt, und ein passendes Schloß (z.B. Schloß2) und schließt das Schnappschloß. Diesen verschlossenen Kasten überträgt er zurück an den Server, denn nur dieser kann das Schnappschloß (Schloß1) mit seinem Schlüssel (Schlüssel1) öffnen und an den Inhalt des Kasten gelangen. Nun haben Browser und Server ein gemeinsames Schloß (Schloß2) und beide den passenden Schlüssel (Schlüssel2); (das gemeinsame Schloß repräsentiert sogenannte symmetrische Kryptographie/Algorithmen; z.B. AES oder DES). Der Browser kann nun seine Daten in einen Kasten packen und mit dem Schloß (wenn beide das Schloß haben können sie es beliebig oft kopieren) verschließen und verschicken. Dabei kann nur er oder der Server den Kasten öffnen. Ebenso kann der Server mit seinen Daten verfahren.

Alternativ könnten beide auch mit (dann jeweils verschiedenen) Schnappschlössern arbeiten, allerdings sind diese nicht sehr schnell (die Mathematik, die den asymmetrischen Verfahren zugrunde liegt, ist wesentlich aufwändiger!) und daher wird das Schnappschloß nur zum Austausch der (schnellen) gleichen Schlüssel und Schlösser verwendet. Dieses Verwenden von symmetrischer und asymmetrischer Kryptographie wird auch Hybride Kryptographie genannt.

[Bearbeiten] Häufiger Vandalismus

Wegen des - im Verhältnis zu den relativ seltenen Änderungen am Artikel - häufigen Vandalismus habe ich einen Antrag auf Halbsperrung gestellt, der aber erstmal nicht fruchtete: Wikipedia:Vandalensperrung#Hypertext_Transfer_Protocol_Secure --Bernd vdB 21:47, 21. Nov. 2006 (CET)

Link-Update: Wikipedia:Vandalensperrung/Archiv/2006/11/16–30#Hypertext_Transfer_Protocol_Secure --Bernd vdB 14:03, 24. Nov. 2006 (CET)

[Bearbeiten] Vergleich mit E-Mail

Im Artikel steht der Satz:

Damit ist, anders als etwa bei eMail (S/MIME oder PGP), SSH oder SFTP, die Installation gesonderter Software durch den Anwender nicht notwendig.

Ich finde den Vergleich irreführend. Bei HTTPS wird wie bei SMTP over SSL der Transportweg zwischen Client (Webbrowser bzw. Mail-Client) und Server (Webserver, MTA) verschlüsselt. In beiden Fällen ist keine Zusatzsoftware notwendig, da SSL in die üblichen Clients bereits integriert ist. Allerdings kann ein MTA eine E-Mail unverschlüsselt an einen weiteren MTA weiterleiten. Ebenso kann ein HTTPS-Webserver eine Anfrage unverschlüsselt von einem anderen Webserver oder einer Datenbank herholen. Die Ende-zu-Ende-Absicherung ist somit Betrachtungsweise. --Fomafix 10:15, 27. Nov. 2006 (CET)

Wenn keine Einsprüche kommen werde ich den Satz entfernen. --Fomafix 21:24, 4. Dez. 2006 (CET)