Stark vereinfacht funktioniert der HTTPS-Datenaustausch zwischen Browser und Server folgendermassen:

1. Ein Nutzer versucht, mit seinem Browser eine Verbindung zu einem mit HTTPS gesicherten Internet-Auftritt herzustellen. Für jede HTTP-Verbindung benötigt man bei HTTP/1.1 jedoch noch eine separate TCP-Verbindung, die erst ausgehandelt werden muss. Dazu sind in der Startphase bereits mindesten zwei Kontakte erforderlich. Diese Roundtrip-Time (RTT) kann man mit Ping messen.
2. Dann fordert der Browser für SSL / TLS die Identität des Servers an.
3. Der Server sendet daraufhin eine Kopie seines Zertifikats an den Browser.
4. Der Browser überprüft, ob das Zertifikat laut seinen eigenen (intern gespeicherten) Regeln korrekt ist. Um die Gültigkeit des Zertifikats zu überprüfen, nimmt der Browser jedoch meist Kontakt mit dem Verzeichnisdienst der angegebenen Zertifizierungsstelle auf, die eine Liste der ausgegebenen, gültigen digitalen Zertifikate sowie eine Sperrliste der verfallenen, ungültigen Zertifikate vorhält.
5. Bei kleinsten Fehlern muss alles neu erfolgen. D.h. nicht selten kommt es zu mehreren Zyklen der Kontaktaufnahme.
6. Falls alles korrekt ist, sendet die Zertifizierungsstelle eine Nachricht an den Browser zurück.
7. Dann erzeugt der Browser (Client) einen eigenen symmetrischen Schlüssel, verschlüsselt ihn mit dem öffentlichen Schlüssel des Servers (Anbieters, besuchten Internet-Auftritts) und schickt diesen an den Server.
8. Daraufhin entschlüsselt der Server mit seinem privaten Schlüssel den ihm zugesandten neuen symmetrischen Schlüssel des Browsers (Client, Nutzers) und verwendet ihn für seine Verschlüsselung aller weiteren Kommunikation.
9. Erst danach beginnen Browser und Server damit, symmetrisch verschlüsselte Daten auszutauschen. Denn nur mit der symmetrischen Verschlüsselung lassen sich halbwegs erträgliche Lasten und Zeitverzögerungen erzielen.

Zeitverzögerung und Lastprobleme = Generelle Nachteile für den Betreiber und Anwender

• Das alles kostet Zeit, in welcher der Nutzer wartet. Je schlechter seine Internet-Anbindung ist (z.B. Smartphone oder sonstige langsamen Funknetze) desto länger dauert es.
• Dies alles geht jedoch von optimal konfigurierten Servern beim Anbieter und optimal eingestellten modernsten Betriebssystemen und Browsern beim Nutzer aus. Ansonsten erhöht sich der Zeitaufwand nochmals spürbar.
• Ferner befinden sich viele der versprochenen Last-/Zeitverkürzungstechniken noch immer in der Einführungsphase oder sind noch nicht in allen Server-Produkten verfügbar.
• Es wird u.a. ein zusätzliches eigenes Programm auf dem Server benötigt, das eine höhere Server-Last erzeugt.
• Dies produziert zwangsläufig eine längere Wartezeit, bis die Antwort vom Server an den Anfrager gegeben wird, da jede Anfrage entschlüsselt und die Antwort erst wieder verschlüsselt werden muss.
• Früher fielen die beiden Punkte Entschlüsselung der Anfrage und Verschlüsselung der Antwort extrem ins Gewicht und fielen jedem Nutzer sofort auf. Dank leistungsfähigerer Server relativiert sich das Problem langsam.
• Hinzu kam oft ein längerer Download der verschlüsselten Inhalte, da die meisten Server keine SSL/TLS-Kompression durchführen. Dank schnellerer Netzwerkanschlüsse relativiert sich dieses Problem langsam.
• Ergänzt wurde dies durch eine längere Dauer bis zur Anzeige der kompletten Datei auf dem Kunden-Endgerät, da erst alles entschlüsselt werden muss. Dank schnellerer PCs bei den Anwendern relativiert sich dieses Problem langsam.

Die Nachteile relativieren sich langsam. Aber sie entfallen nicht - nie! Ganz im Gegenteil nimmt der Aufwand mit jeder noch besseren Verschlüsselungsmethode deutlich zu.

• Die immer wieder angegebenen Zitate von Google von nur 1% höherer Last bei E-Mail-Testprogrammen sind für die meisten Firmen unzutreffend. Da seit Jahren für HTTPS zusätzliche sündhaft teure Hardware angeboten wird, welche nur die Verschlüsselung beschleunigt, und diese Geräte sich einer bis heute regen Nachfrage erfreuen, sollte man es auf jeden Fall selbst nachrechnen und in der Praxis nachprüfen.
• Die überall auffindbaren und technisch gesehen korrekten Behauptungen, dass man alle Lastprobleme lösen kann, kommen erstaunlicher Weise sehr oft von solchen Persönlichkeiten, welche für vierstellige Tagessätze Ihnen gerne diese Arbeiten erledigen. Selbstverständlich sind alle Probleme lösbar. Aber unterschätzen Sie hierzu nicht den finanziellen und zeitlichen Aufwand. Im Zweifel benötigen Sie einen neuen Provider, einen neuen Server und einen neuen Internet-Anschluss und neben neuer Software sowieso neue Hardware. Dass Sie dann auch die gesamte Software neu aufsetzen müssen, dürfte klar sein.
• Grundsätzlich gilt, dass HTTPS noch relativ geringe zusätzliche Last bei kleinen Datenmengen erzeugt (typische E-Mails, Kurznachrichten, kurze Seitentexte etc.), dass das Verfahren jedoch wenig geeignet ist für die Verschlüsselung großer Datenmengen. So kann die Zeit zum Ver- und Entschlüsseln großer Bilddateien deutlich ansteigen. Dies ist relevant, da seit einigen Jahren Internet-Aufritte zunehmend mit teilweise riesigen Fotos (nicht selten mit mehreren tausend Pixeln in der Länge und der Breite sowie 24 oder mehr Bit Farbtiefe) ausgestattet werden.
• Exakt aus diesen Gründen gab es früher auch die Möglichkeit, nur die datenschutzrelevanten Dinge wie Bestelldaten im Shop und Kontaktformulare zu schützen, jedoch nicht die reinen Inhaltsseiten. Heute machen es sich jedoch die meisten Programmierer einfach und verschlüsseln alles. Das Lastproblem bleibt beim Anbieter und die Zeitverzögerung hat der Kunde / Nutzer zu tragen.