Mythos: HTTPS ist viel zu langsam

In den meisten Fällen sind die kryptographischen Operationen von HTTPS in Sachen Performance nahezu vernachlässigbar. Laut einer älteren Aussage von Google-Entwickler Adam Langley musste Google keinerlei zusätzliche Hardware anschaffen, um den Betrieb von Gmail vollständig auf HTTPS umzustellen.

Praktisch irrelevant für die Performance ist die symmetrische Verschlüsselung. Geringe Performancekosten hat man bei den asymmetrischen Operationen, also bei der Verifikation von Signaturen und beim Schlüsselaustausch. Doch auch die bewegt sich nur im Millisekundenbereich. Das einzige wirkliche Performanceproblem von HTTPS sind zusätzliche Round-Trips beim Verbindungsaufbau. Doch die sind kein grundsätzliches Problem, sie treten nur bei nicht optimalen Serverkonfigurationen auf.

Ilya Grigorik, bei Google als Experte für Webperformance angestellt, betreibt eine Webseite mit dem Namen istlsfastyet.com, auf der er erläutert, welche Performanceprobleme bei TLS-Verbindungen auftreten können und wie man diese vermeidet. So sollten Serverbetreiber etwa die Funktion OCSP-Stapling anschalten und gewährleisten, dass die Browser die Funktion TLS False Start einsetzen können. Wenn man HTTPS in Kombination mit SPDY oder HTTP/2 einsetzt, kann man sogar in Sachen Performance gewinnen.

Google-Entwickler Chris Palmer argumentiert, dass HTTPS zwar sehr geringe Kosten in Sachen Performance hat, aber die wenigsten Webseiten reizen bislang andere Möglichkeiten der Optimierung voll aus. Dazu gehören etwa die komprimierte Übertragung von HTML, CSS und Javascript, die Optimierung von Bildern und vieles mehr. Insofern ist es in den meisten Fällen so, dass man durch einfache Optimierungen an anderer Stelle die Verluste durch HTTPS kompensieren kann.

Mythos: Bei HTTPS benötigt man eine eigene IP für jeden Domainnamen

Ursprünglich wurde HTTPS so entwickelt, dass der Server das Zertifikat übertragen hatte, bevor er wusste, auf welchen Domainnamen sich eine Verbindung bezieht. Das führte dazu, dass man mit HTTPS keine virtuellen Hosts einsetzen konnte und für jeden Hostnamen eine eigene IP benötigte. Doch diese Zeiten sind längst vorbei.

2003 wurde die TLS-Erweiterung Server Name Indication (SNI) definiert. Mit SNI ist es möglich, beliebig viele HTTPS-Webseiten mit eigenen Zertifikaten auf einer einzigen IP zu hosten. Das wird heute auch von allen Browsern unterstützt. Selbst mit älteren Browsern sind Probleme extrem selten. Der Internet Explorer 7 unter Windows Vista unterstützte bereits SNI, Firefox kann das Protokoll seit Version 2.0. Die einzigen Browser, die Probleme mit SNI haben, sind der Internet Explorer unter Windows XP und der interne Browser von alten Android-2-Systemen.