„Hypertext Transfer Protocol Secure“ – Versionsunterschied

Versionsgeschichte interaktiv durchsuchen

[ungesichtete Version]

← Zum vorherigen Versionsunterschied Zum nächsten Versionsunterschied →

Inhalt gelöscht Inhalt hinzugefügt

Inline

Version vom 4. März 2006, 17:09 Uhr

**HTTPS im TCP/IP-Protokollstapel**
Anwendung	HTTPS
Transport	SSL
	TCP
Netzwerk	IP
Netzzugang	Ethernet	Token Ring	FDDI	...

HTTPS steht für Hypertext transfer protocol secure und ist ein Netzwerkprotokoll, das eine gesicherte HTTP-Verbindung zwischen Rechnern ermöglicht.

Hierbei werden die Daten über SSL/TLS verschlüsselt, damit sie abhörsicher sind. HTTPS-Verbindungen laufen über TCP. Der Standard-Port für HTTPS-Verbindungen ist 443.

Umgangssprachliche Beschreibung

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

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).

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.

Weitere Details

Hierbei findet unter Verwendung des Diffie-Hellman-Schlüsselaustausches (benannt nach Whitfield Diffie und Martin Hellman) zunächst ein Austausch geheimer Schlüssel statt, um danach in einer weiteren Stufe die jeweiligen öffentlichen Schlüssel in Form digitaler Zertifikate sicher austauschen zu können, die danach zur Verschlüsselung der Nutzdaten genutzt werden, um abhörsichere Kommunikation zu gewährleisten.

Die größte Schwachstelle des HTTPS-Protokolls ist die Abhängigkeit von signierten Zertifikaten. Ohne ein signiertes Zertifikat ist das Protokoll verwundbar gegenüber dem sogenannten Man-In-The-Middle-Angriff. In der Praxis werden oft nicht signierte Zertifikate benutzt, wodurch die Sicherheit, die HTTPS bietet, weitestgehend verloren geht.

Neben den Server-Zertifikaten können auch signierte Client-Zertifikate nach X.509.3 erstellt werden. Dieses ermöglicht eine Authentifizierung der Clients gegenüber dem Server.

Siehe auch: Elektronische Unterschrift

Weblinks

RFC 2818 – HTTP Over TLS (englisch)
http://serversniff.de/do_sslcheck.php Serversniff.de prüft HTTPS-Server auf Zertifikatsinfos, Protokolle und angebotene Verschlüsselungsmethoden

@@ Zeile 22: / Zeile 22: @@
 Hierbei werden die Daten über [[Secure Sockets Layer|SSL/TLS]] verschlüsselt, damit sie abhörsicher sind. HTTPS-Verbindungen laufen über [[TCP/IP|TCP]]. Der Standard-[[Port (Protokoll)|Port]] für HTTPS-Verbindungen ist 443.
+== Umgangssprachliche Beschreibung ==
+Der Ablauf beginnt damit, dass ein "Zertifikat" übermittelt und anschließend eine verschlüsselte Verbindung eingerichtet wird.
+=== 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).
+=== 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.
+== Weitere Details ==
 Hierbei findet unter Verwendung des [[Diffie-Hellman-Schlüsselaustausch]]es (benannt nach [[Whitfield Diffie]] und [[Martin Hellman]]) zunächst ein Austausch [[geheimer Schlüssel]] statt, um danach in einer weiteren Stufe die jeweiligen [[öffentlicher Schlüssel|öffentlichen Schlüssel]] in Form [[digitales Zertifikat|digitaler Zertifikate]] sicher austauschen zu können, die danach zur Verschlüsselung der [[Nutzdaten]] genutzt werden, um abhörsichere Kommunikation zu gewährleisten.