Dark ITSec

HTTPS und SHTTP
HTTPS (HTTP über SSL)
ist ein Computerprotokoll, das eine gesicherte HTTP-Verbindung zwischen Rechnern ermöglicht.

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

Technologisch gesehen ist HTTPS über TCP gleich HTTP über SSL über TCP.

Hierbei findet unter Verwendung des Diffie-Hellman-Algorithmus (benannt nach Whitfield Diffie und Martin Hellman) zunächst ein Austausch von Secret Keys statt, um danach in einer weiteren Stufe die jeweiligen Public Keys 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 sog. "man in the middle"-Angriff. Leider werden oft nicht signierte Zertifikate benutzt, wodurch die Sicherheit, die HTTPS bietet, weitestgehend verloren geht.

HTTPS im TCP/IP-Protokollstapel

Anwendung HTTP
Transport SSL
TCP
Netzwerk IP
Netzzugang Ethernet Token
Ring
FDDI ...

SHTTP(Secure HTTP)
Einen alternativen Ansatz zu SSL bietet Secure HTTP (S-HTTP), das von einer Kooperation zwischen RSA Data Security Inc. und EIT Enterprise Integration Technologies entwickelt worden ist.

S-HTTP ist eine Erweiterung von HTTP und ist somit im Gegensatz zu SSL in der Anwendungsschicht angesiedelt. Es ermöglicht eine Aushandlung zwischen Client und Server von verschiedenen Sicherheitsmechanismen, die unabhängig voneinander sind.

Der Vorteil von Secure-HTTP gegenüber SSL liegt in der wesentlich breiteren Vielfalt von Anwendungsmöglichkeiten. Da S-HTTP in der Anwendungsebene verankert ist, ist es dem Benutzer, also Informationsanbieter und Informationsnutzer, zugänglicher als SSL. Es ist also nicht nur möglich vertrauliche Daten untereinander auszutauschen, sondern dem Benutzer stehen auch Möglichkeiten, wie digitale Unterschriften zur Verfügung. Damit können Kommunikationspartner Verträge abschließen, verbindliche öffentliche Mitteilung machen und so weiter. Es ist also mächtiger als SSL, konnte sich aber gerade aufgrund seiner Komplexität nicht gegenüber SSL durchsetzen.

Basic Authentification
ist eine Möglichkeit der Authentifizierung, die HTTP bietet. Der Zugriff läuft in vier Schritten ab:

  1. Der Client stellt eine normale Anfrage für das gewünschte Dokument.
  2. Der Server verweigert die Auslieferung des Dokumentes, indem es den Statuscode "401 Unauthorized" zurücksendet und gibt dabei an, um welches Authentifizierungsverfahren es sich handelt, hier: Basic Authentification. Damit ist HTTP auch für beliebig andere Authentifizierungsverfahren offen.
  3. Wenn der Client das angeforderte Authentifizierungsverfahren kennt und beherrscht, kann der Benutzer meist in einem Dialog-Box User-ID und Passwort angeben. Der Client schickt erneut eine Anfrage, diesmal mit der eingegebenen Authentifizierung
  4. Der Server überprüft Passwort und User-ID. Falls diese korrekt sind, wird das gewünschte Dokument ausgeliefert.

Das Verfahren erfüllt nur Autorisierung und Authenzität. Und da Basic Authentication keine krytographische Lösung ist, sind selbst diese Anforderungen nicht sicher gelöst.

Der Nachteil an diesem Verfahren ist, dass die User-ID und das Passwort vom Client zum Server im Header der Anfrage im Klartext verschickt werden. Hacker ist es ein leichtes durch mitschneiden des Headers das Passwort und die User-ID herauszufinden. Solange aber die "geschützten" Dokumente keine hochsensiblen Informationen enthalten, kann diese Verfahren dennoch genutzt werden.

Digest Access Authentication (DAA)
DAA dient ebenfalls nur zur Authentifikation. Der Zugriff läuft wiederum in vie Schritten ab:

  1. Der Client stellt eine normale Anfrage für das gewünschte Dokument.
  2. Der Server verweigert die Auslieferung des Dokumentes, indem es den Statuscode "401 Unauthorized" zurücksendet und gibt dabei an, um welches Authentifizierungsverfahren es sich handelt, hier: Digest Access Authentication. Nebenbei wird noch ein sogenannter "Nonce"-Wert (Integer-Zahl), der bei jeder Anforderung neu erstellt wird.
  3. Die User-ID und das Passwort, welche der Benutzer angegeben hat, werden mit dem Nonce-Wert zusammen durch eine MD5-Hashfunktion als 128 Bit-Zahl kodiert werden. Nun stellt der Client nochmals die Anfrage, aber mit dieser Authentifizieung.
  4. Der Server überprüft User-ID und Passwort und übermittelt bei Richtigkeit das gewünschte Dokument. Zur Überprüfung muss nicht einmal die User-ID und das Passwort auf dem Server gespeichert sein, es reicht einfach nur die 128-Bit-Zahl zu speichern

Der Vorteil gegenüber Basic Authentication liegt klar auf der Hand: Es werden das Passwort und die User-ID niemals im Klartext über das Netz verschickt.

Mediated Digest Authentication (MDA)
MDA ist ein Erweiterungsvorschlag zu DAA. Da bei DAA zwischen jedem Server und jedem Client ein Gemeinsamer Schlüssel vereinbart werden muss, wird dieses Verfahren bei hoher Teilnehmerzahl sehr unpraktikabel. MDA sieht hier die Zusammenarbeit mit einer vertrauenswürdigen dritten Partei vor, welche die Schlüsselverwaltung übernimmt. Somit braucht sowohl Client und Server sich nur den Zugang zu einem sogenannten Authentifizierungserver (authentification server) zu merken. Jeder braucht also nur einen einzigen Schlüssel.

Versucht also ein Client auf ein mit MDA geschütztes Dokument auf einem Web-Server zuzugreifen, so sendet der Web-Server nach diesem ersten Zugriffsversuch, neben den nach DAA nötigen Authentifizierungsangaben, auch noch eine Liste von Authentifizierungsservern, denen er vertraut. Besitzt der Client ein Passwort für den geforderten Gültigkeitsbereich, kann er sich nach dem DAA-Modell gegenüber den Server authentifizieren. Ansonsten kann nun der Client aus der übertragenen Liste ebenfalls einen Authentifizierungsserver aussuchen, dem er vertraut und von diesem einen Sitzungsschlüssel anfordern.