abfangen

HTTPS und S-HTTP
Sichere Datenübertragung im
Internet
Problematik: ungesicherte
Internetverbindungen

Besonders im lokalen Netz: leichter
Empfang von Paketen durch „Man in the
Middle-Angriff“
• Durch Kontrolle über Router
• In Netzen mit BUS-Struktur
• Vortäuschen falscher Access-Points oder DHCPServer etc.


Passive Datenbeschaffung durch Abfangen
der Pakete
Aktive Datenbeschaffung durch
Herausfiltern von Passwörtern etc.
Problematik: ungesicherte
Internetverbindungen




Kommunikation
Server – Client muss
gesichert werden
Server muss sich
authentifizieren
Client muss sich
authentifizieren
Klar definierte
Möglichkeiten für
Client, Prozesse auf
dem Server zu
starten
HTTPS: Geschichte




Juli 1994: SSL 1.0 von Netscape
Communications
Januar 1995: SSL 2.0 (zeitgleich mit
neuer Netscape Navigator Version)
Ende 1995: Internet Explorer von
Microsoft & PCT 1.0 (Private
Communication Technology). Vorteile von
PCT 1.0 in SSL 3.0 aufgenommen
Januar 1999: SSL von IETF (Internet
Engineering Task Force) im RFC 2246 als
Standard festgelegt; Umbenennung zu
Transport Layer Security (TLS)
HTTPS: Geschichte

Erweiterungen von TLS durch weitere
RFCs:
• RFC 2712 - Addition of Kerberos Cipher Suites to
Transport Layer Security (TLS).
• RFC 2817 - Upgrading to TLS Within HTTP/1.1,
Initialisierung von TLS über bestehende TCP/IPVerbindung (Port 80 / 443)
• RFC 2818 - HTTP Over TLS, trennt sicheren von
unsicherem Verkehr durch Benutzung eines eigenen
Server TCP Ports.
• RFC 3268 - Advanced Encryption Standard (AES)
Ciphersuites for Transport Layer Security (TLS), fügt TLS
zu den unterstützen Verschlüsselungsalgorithmen (RC2,
RC4, International Data Encryption Algorithm (IDEA),
Data Encryption Standard (DES) und Triple DES) den
Advanced Encryption Standard (AES) hinzu.
HTTPS




Einordnung im Schichtenmodell
Hypertext Transfer Protocol Secure
Zwischen
Transportschicht
(TCP/IP)
HTTP
FTP
SMTP
usw… HTTP)
und Anwendungsschicht (z.B.
SSL erkennbar
An URL (https://...)
Eigentlich zwei Protokolle (RecordTCP / IP
und Handshake-Protokoll
HTTPS: Record-Protokoll




Direkt über TCP/IP-Transportschicht
Kapselung der Daten in Blöcke
Eigentliche Verschlüsselung der
Daten
Jeder Block: Header
• Informationen zur Entschlüsselung
• Message Authentication Code (DatenIntegrität durch kryptographische
Prüfsumme)
HTTPS: Handshake-Protokoll

Festlegen der Verschlüsselung und
Austausch von Zertifikaten
ClientHello
Certificate*
ClientKeyExchange
CertificateVerify*
ChangeCipherSpec
Finished
Application Data
ServerHello
Certificate*
CertificateRequest*
ServerKeyExchange*
ServerHelloDone
ChangeCipherSpec
Finished
Application Data
S-HTTP



Secure Hypertext Transfer Protocol
Februar 1994 von Terisa Systems für
CNK entwickelt
Juli 1995:
• erste Implementierung (Secure Mosaik
Browser)
• Secure NCSA-Dämon von EIT
S-HTTP




Einordnung im Schichtenmodell
Erweitert HTTP-Protokoll um
Sicherheitsfunktionalität
S-HTTP
Kompatibel zu Clients ohne S-HTTP
(dann ohne Verschlüsselung)
TCP / IP
Nachteil: auf HTTP als Anwendung
beschränkt
Erkennbar an URL (shttp://…)
S-HTTP

Protokoll sehr allgemein gehalten
+ hohe Flexibilität der kryptographischen
Verfahren
- Probleme bei der Kompatibilität
zwischen Browser und Client
S-HTTP: Kommunikationsablauf

HTTP-Nachricht bekommt S-HTTPHeader
• Format der Nachricht
• „Options Negotation“:





Kryptographischer Algorithmus
Digitale Signatur
Haschverfahren
Zertifikatstypen
Schlüsselaustausch-Mechanismen
S-HTTP: neue Sprachelemente

Im Hyperlink-Tag: Informationen
über Verschlüsselung der
Serverdaten:
• Sicherheitsmechanismen
• Identifizierung von Zertifikaten
+ Für jede Übermittlung: neue Parameter
aushandelbar
S-HTTP: neue HTML-Elemente
<A HREF=”shttp://www.beispiel.de/dokument.html”
DN=”CN=Name, OU=Organisation, C=US”
CRYPTOPS=
”SHTTP-Privacy-Domains:
orig-required=PKCS-7;
recv-required=PKCS-7;
SHTTP-Key-Exchange-Algorithms:
orig-optional=RSA;
recv-required=RSA;
SHTTP-Privacy-Enhancements:
orig-optional=sign,encrypt;
recv-required=sign,encrypt;>
Hyperlinkname </A>
Der Vergleich (Vorteile)

HTTPS
•
•
•
•

Port: 443
HTTP over SSL
Vielseitig einsetzbar
Einfache
Implementierung
• Von nahezu allen
Browsern
unterstützt
S-HTTP
• Port: 80
• Eigenständiges Protokoll
• Optimal an WWW
angepasst (Anfrage –
Antwort Paar)
• Ressourcen sparender
• Individuell

Jeder Link enthält
Informationen über
Verschlüsselung
• Flexibler
Der Vergleich (Nachteile)

HTTPS

• Aufwändiger
Verbindungsaufbau
via SSL


Viele Anfragen
mittels HTTP nötig
-> Langsam
• Kein Einfluss auf
Sicherheitsparamet
er bei Laufzeit
S-HTTP
• Andere
Sicherheitseinstellungen
-> Andere Links
• Komplexe Konfiguration
des Systems

Sicherheitslücken
• Administrationsaufwand!
• Wird von vielen
Browsern nicht
unterstützt
Fazit

HTTPS hat sich durchgesetzt
• Für breite Masse
• Sicher

S-HTTP nur vereinzelt
Übung: Zertifikat erstellen



req -config openssl.cnf -new -out
test-zertifikat.csr
rsa -in privkey.pem -out testzertifikat.key
x509 -in test-zertifikat.csr -out testzertifikat.crt -req -signkey testzertifikat.key -days 365