Varianten der HTTPS-Anwahl

Die Entscheidung, ob eine sichere HTTPS- statt einer HTTP-Verbindung genutzt wird, kann unterschiedlich erfolgen:

• Serverseitig wird ausschließlich HTTPS zugelassen, wie meist bei Online-Banking; teils wird dabei eine angewählte http-Adresse automatisch auf https weitergeleitet.
• Der Login wird über HTTPS erzwungen, dann wird ein HTTP-Cookie im Browser gesetzt und, um Rechenzeit zu sparen, der weitere Dienst unverschlüsselt abgewickelt; z. B. bei eBay.
• Clientseitig durch HSTS: Wenn der Server nur HTTPS zulässt (wie oben beschrieben), kann der Browser dies speichern und stellt zukünftig immer eine Verbindung über HTTPS her. Steht der Server zusätzlich auf der HSTS Preload Liste, stellt der Browser auch beim ersten Besuch schon direkt eine HTTPS-Verbindung her.
• Clientseitige Eingabe der HTTPS-Variante oder Browser-Plug-in (z. B. für Firefox und Chrome „HTTPS Everywhere“), welches http-Anfragen durch https-Anfragen ersetzt, bei Diensten, die beide Varianten unterstützen.
• Seit 2020 (Version 83) kann Firefox so eingestellt werden, dass es nur HTTPS verwendet. Falls eine Website nur über das unsichere HTTP erreicht werden kann, erfolgt der Zugriff erst nach expliziter Zustimmung durch den Nutzenden.

Gemäß der ursprünglichen Auslegung soll der Client-Browser nach Anwahl der HTTPS-Adresse dem Anwender zuerst das Zertifikat anzeigen. Dieser entscheidet nun, ob er dem Zertifikat für diese Sitzung vertraut, es evtl. auch permanent speichert, gegebenenfalls nach Prüfung über die angegebenen Links. Andernfalls wird die HTTPS-Verbindung nicht hergestellt („Diese Seite verlassen“ bei Firefox bzw. „Klicken Sie hier um diese Seite zu verlassen.“ beim Internet Explorer).

Vorinstallierte Zertifikate

Um diese für Unkundige eventuell irritierende Abfrage zu vermeiden, wurde mit der Zeit eine Reihe von Root-Zertifikaten von den Browserherstellern akzeptiert, die schon bei der Installation eingetragen werden. Webseiten, die entsprechende Zertifikate haben, werden dann, ebenso wie davon abgeleitete Unter-Zertifikate, bei Aufruf ohne Nachfrage akzeptiert. Ob ein Root-Zertifikat dem Browser bekannt ist, hängt von der Browser-Version ab; zudem wird die Liste der Zertifikate teils auch online im Rahmen der Systemaktualisierung auf den neuesten Stand gebracht, so bei Microsoft Windows.

Mit dem Internet Explorer 7 hat Microsoft, kurz danach auch Mozilla mit dem Firefox 3, die Warnung bei nicht eingetragenen Zertifikaten verschärft: Erschien vorher nur ein Pop-up „Sicherheitshinweis“, das nach Name, Quelle und Laufzeit des Zertifikats differenzierte, so wird nun der Inhalt der Webseite ausgeblendet und eine Warnung angezeigt, mit der Empfehlung, die Seite nicht zu benutzen. Um diese sehen zu können, muss der Anwender dann explizit eine „Ausnahme hinzufügen“. Ein nicht im Browser eingetragenes Zertifikat wird damit für Massenanwendungen zunehmend untauglich.

Die Frage, welche Zertifikate in die Browser aufgenommen werden, hat in der Open-Source-Community fallweise zu längeren Diskussionen geführt, so zwischen CAcert, einem Anbieter kostenloser Zertifikate, und der Mozilla Foundation, siehe CAcert (Vertrauenswürdigkeit).

Ende 2015 ging Let’s Encrypt online, gegründet u. a. von Mozilla und der Electronic Frontier Foundation. Hier werden kostenlose Zertifikate für jedermann angeboten mit dem Ziel, die Verbreitung von HTTPS insgesamt zu fördern. Für die Installation und laufende Aktualisierung der Zertifikate ist jedoch eine eigene Software auf dem Server notwendig.

Zertifikat

Das digitale Zertifikat für SSL, das die Authentifizierung ermöglicht, ist vom Server bereitzustellen: Ein Binärdokument, das im Allgemeinen von einer – selbst wiederum zertifizierten – Zertifizierungsstelle (CA von englisch certificate authority) ausgestellt wird, das den Server und die Domain eindeutig identifiziert. Bei der Beantragung werden dazu etwa die Adressdaten und der Firmenname des Antragstellers geprüft.

In gängigen Browsern eingetragene Zertifikate werden typischerweise zu Preisen zwischen 15 und 600 € pro Jahr angeboten, wobei fallweise weitere Dienste, Siegel oder Versicherungen enthalten sind. Eine Reihe von Zertifizierungsstellen gibt kostenlos Zertifikate aus. Die etwa von Let’s Encrypt ausgestellten Zertifikate werden dabei von fast allen modernen Browsern ohne Fehlermeldung akzeptiert. Ebenfalls kostenlose Zertifikate erstellt CAcert, wo es bisher jedoch nicht gelang, in die Liste der vom Browser automatisch akzeptierten Zertifikate aufgenommen zu werden; siehe oben. Ein solches Zertifikat muss daher bei der Client-Verarbeitung vom Anwender manuell importiert werden; dieses Verhalten kann aber auch erwünscht sein.

Um veraltete oder unsicher gewordene Zertifikate für ungültig zu erklären, sind Zertifikatsperrlisten (englisch certificate revocation list, CRL) vorgesehen. Das Verfahren sieht vor, dass diese Listen regelmäßig von Browsern geprüft und darin gesperrte Zertifikate ab sofort abgewiesen werden.

Mit dem OCSP (Online Certificate Status Protocol) kann, ergänzt um SCVP (Server-based Certificate Validation Protocol), serverseitig die Unterstützung für Zertifikats-Prüfungen umgesetzt werden.

Zu Angriffen auf das Zertifikatsystem, siehe unten.

IP-Adressen bei mehreren Domains

Zum Betrieb eines HTTPS-Webservers war lange Zeit eine eigene IP-Adresse pro Hostname notwendig.

Bei unverschlüsseltem HTTP ist das nicht erforderlich: Seitdem Browser den Hostnamen im HTTP-Header mitsenden, können mehrere virtuelle Webserver mit je eigenem Hostnamen auf einer IP-Adresse bedient werden, zum Beispiel bei Apache über den NameVirtualHost-Mechanismus. Dieses Verfahren wird inzwischen bei der weit überwiegenden Zahl der Domains benutzt, da hier der Domain-Eigner selbst keinen Server betreibt.

Da bei HTTPS jedoch der Webserver für jeden Hostnamen ein eigenes Zertifikat ausliefern muss, der Hostname aber erst nach erfolgtem SSL-Handshake in der höheren HTTP-Schicht übertragen wird, ist das Deklarieren des Hostnamens im HTTP-Header hier nicht anwendbar. Dadurch war eine Unterscheidung nur anhand der IP/Port-Kombination möglich; ein anderer Port als 443 wird wiederum von vielen Proxys nicht akzeptiert.

Vor diesem Hintergrund nutzten einige Provider einen Workaround, um ihren Kunden auch HTTPS ohne eigene IP-Adresse zu ermöglichen, etwa „shared SSL“. Sie nutzten Wildcard-Zertifikate, die für alle Subdomains einer Domain gültig sind, in Verbindung mit kundenspezifischen Subdomains. Andere Provider nutzten einen „SSL Proxy“, der die Anfragen über eine von mehreren Kunden genutzte Domain leitete.

Die Lösung dieses Problems kam durch Server Name Indication (SNI), auf Basis von Transport Layer Security 1.2, da hier der vom Browser gewünschte Hostname bereits beim SSL-Handshake übermittelt werden kann. Damit sind die oben genannten anderen Techniken bedeutungslos geworden. Das Verfahren bedarf entsprechend aktueller Software auf Seiten des Servers und des Browsers und wurde von diesen ab 2006 unterstützt.

Im Falle des Apache-Servers wird die SNI-Verarbeitung z. B. durch eine nur leicht modifizierte Konfigurations-Anweisung gesteuert:
<VirtualHost _default_:443>

Einbindung

Die Einbindung von HTTPS in eine Website oder -anwendung erfolgt analog zu den oben genannten Varianten der HTTPS-Anwahl:

• Wenn ausschließlich HTTPS zulässig ist, kann das umgesetzt werden durch:
  • Weiterleitung (HTML-refresh) oder auch ein rewrite der URL
  • Konfiguration von HTML-Seiten oder Skripten als Muss-SSL, bei Apache etwa durch die Anweisung SSLRequireSSL in der .htaccess. Wird eine solche Seite per HTTP aufgerufen, erzeugt der Server einen '403 – Forbidden' HTTP-Fehlercode.
• Der Anwender wird auf die Möglichkeit der SSL-Nutzung durch einen entsprechenden Link hingewiesen.
  • Teilweise wird, vor allem während der Einführung von HTTPS, auf eine Bewerbung durch einen Link verzichtet. Der Anwender kann nur manuell auf HTTPS umschalten, indem er in der URL selbstständig das „s“ hinter „http“ hinzufügt.
• Skriptgesteuerte Erzeugung von HTTPS-Links, um den Anwender bei bestimmten Arbeitsschritten oder Ausgaben auf eine HTTPS-Seite zu lenken. Anschließend kann im Skript geprüft werden, ob dieses per HTTPS aufgerufen wurde, bei PHP etwa durch die Bedingung: $_SERVER['HTTPS']=='on'

Umstellung

Mit zunehmender CPU-Leistung sowie Sicherheitsbewusstsein tritt regelmäßig die Anforderung auf, eine bisher auf HTTP basierende Website auf HTTPS umzustellen. Im Falle der Website Stack Overflow mit einer Vielzahl von Usern und Services zieht sich dieser Prozess über einige Jahre hin und ist Stand März 2017 nicht abgeschlossen. Dabei wurden u. a. folgende Themen bearbeitet:

• Vermeidung von Einbindungen von unverschlüsselten Daten (Mediadaten, Stylesheets etc.) in eine verschlüsselte Seite (sogenannter Mixed Content). Andernfalls werden Browserwarnungen wie 'Part of this page is not secure' ausgegeben oder Daten nicht geladen.
• Gesamte Infrastruktur ist auf SSL umzustellen, darunter Loadbalancer und Proxies
• Organisation der Zertifikate, ggf. für eine Vielzahl von Subdomains
• Umstellung von Code der eigenen Webanwendung, worin HTTP hart codiert ist
• Umstellung von altem und Prüfung von neuem User-Code, der ggf. HTTP verwendet
• Qualitätsprüfung
• Umsetzung laufender Sessions, ohne deren Inhalte zu verlieren (24/7 Betrieb)

Leistung

Beim Verbindungsaufbau legt der Server einen Verschlüsselungsalgorithmus fest. In der Theorie soll sich der Server dabei an den Wünschen des Clients orientieren. Um Rechenzeit zu sparen, werden jedoch auf Servern mit hohem Datenverkehr bevorzugt Strom-Chiffren eingesetzt, da diese weniger rechenintensiv sind als Block-Chiffren wie AES oder Camellia. Viele der dabei lange Zeit genutzten Verfahren wie RC4 gelten als unsicher und werden daher seit 2016 von den großen Webbrowsern nicht mehr unterstützt.

Zur Entlastung der Server-CPU werden auch Hardware-SSL-Beschleuniger (SSL accelerators) angeboten: PCI-Steckkarten mit speziellen, optimierten Prozessoren, die aus der SSL-Bibliothek angesprochen werden. Daneben gibt es auch eigenständige Geräte, meist in Rack-Bauweise, die Teile des HTTP-Datenstroms automatisch verschlüsseln. Weiterhin werden Server mit programmierbaren Recheneinheiten angeboten, die mit entsprechenden SSL-Bibliotheken höhere Leistung als vergleichbar aufwendige Universal-CPUs erreichen, so die MAU (Modular Arithmetic Unit) von Sun. Diese spezielle Hardware steht aber im engen Wettbewerb mit der stetigen Entwicklung der Multiprozessor- und Multi-Core-Systeme der großen CPU-Hersteller Intel und AMD.

2010 verursachte die Verschlüsselung beispielsweise bei Gmail weniger als 1 % der Prozessor-Last, weniger als 10 KB Arbeitsspeicherbedarf pro Verbindung und weniger als 2 % des Netzwerk-Datenverkehrs. 10 Jahre vorher belastete der Rechenaufwand der Verschlüsselung die Server noch stark.

Verschlüsselung

Die bei SSL eingesetzten Verschlüsselungsverfahren werden unabhängig von ihrem Einsatzzweck regelmäßig überprüft und gelten als mathematisch sicher, d. h., sie lassen sich theoretisch mit den heute bekannten Techniken nicht brechen. Die Zuverlässigkeit der Algorithmen wird regelmäßig etwa durch Wettbewerbe unter Kryptologen überprüft. Regelmäßig werden in den Spezifikationen und den Implementierungen die Unterstützung veralteter Verschlüsselungsverfahren, die nach dem aktuellen Stand der Technik als nicht mehr sicher gelten, gestrichen und neue Verfahren aufgenommen.

Probleme entstanden in der Vergangenheit mehrfach durch fehlerhafte Implementierung der Kryptologie. Insbesondere Schwachstellen in der weit verbreiten OpenSSL-Bibliothek wie Heartbleed haben dabei große öffentliche Aufmerksamkeit erfahren.

Da in der Regel Benutzer nicht explizit eine verschlüsselte Verbindung durch Spezifizierung des HTTPS-Protokolls (https://) beim Aufruf einer Webseite anfordern, kann ein Angreifer eine Verschlüsselung der Verbindung bereits vor Initialisierung unterbinden und einen Man-in-the-Middle-Angriff ausführen.

Speziell zur Abwehr von Downgrade-Attacken gegen die Verschlüsselung sowie von Session Hijacking wurde 2012 das Verfahren HTTP Strict Transport Security oder HSTS vorgestellt. Es wird durch einen HSTS-Header seitens des Servers aktiviert, worauf im Browser u. a. http- in https-URLs umgewandelt werden.

Zertifikatsystem

SSL-Verbindungen sind grundsätzlich gefährdet durch Man-in-the-Middle-Angriffe, bei denen der Angreifer den Datenverkehr zwischen Client und Server abfängt, indem dieser sich beispielsweise als Zwischenstelle ausgibt. Eine Reihe von Angriffsverfahren setzen voraus, dass sich der Angreifer im Netzwerk des Opfers befindet. Beim DNS-Spoofing wiederum bestehen diese Voraussetzungen nicht.

Um sich als (anderer) Server auszugeben, muss der Angreifer auch ein Zertifikat vorweisen. Das ist ihm beispielsweise dann möglich, wenn es ihm gelingt, in das System einer Zertifizierungsstelle einzudringen, oder er anderweitig in den Besitz eines Zertifikats kommt, mit dem sich beliebige andere Zertifikate ausstellen lassen. Insbesondere bei einflussreichen Angreifern, wie etwa Regierungsbehörden, können solche Möglichkeiten bestehen, da mitunter auch staatliche Zertifizierungsstellen existieren. HTTP Public Key Pinning und Certificate Transparency sollen solche Angriffe erschweren.