Manfred Kloiber: Es ist ein seltsames Spiel unter Ingenieurinnen und Ingenieuren: Quasi im Halbjahrestakt versucht die Internet Engineering Task Force (IETF) auf Ihren regelmäßigen Konferenzen Konsens zu schaffen. Im Plenum werden die "Requests for Comments", die RFCs geeint - de facto Normen für die Technik des Internets. Und ganz offen in diesen Diskussionen machen nicht nur die Verfechter eines offenen und sicheren Internets mit, sondern auch Geheimdienstler und Lobbyisten.

Das konnte und kann man gut am Beispiel der technischen Normung des neuen Internet-Transportprotokoll TLS 1.3 verfolgen. Bereits auf der Konferenz im März in London hat sich gezeigt, dass Vertreter der Sicherheitsbehörden und amerikanischer Unternehmen weitergehende Verschlüsselung der Datenkommunikation im Internet verhindern wollen. Und jetzt, auf der 102. Konferenz der IETF diese Woche in Montreal ging das Spiel munter weiter. Um Servernamen wurde gestritten. Worum genau, Peter Welchering?
Peter Welchering: In erster Linie ging es dabei um die Anzeige des Servernamens in Version 1.3 des Sicherheitsprotokolls TLS. Der Wechsel auf TLS-Version 1.3 ist ja im vergangenen März in London beschlossen worden. Dagegen sind ja vor allen Dingen Vertreter von Sicherheitsbehörden und der Finanzindustrie Sturm gelaufen. Dennoch wurde der Wechsel auf TLS-Version 1.3 in London beschlossen. Und in Montreal ging es dann in dieser Woche um eine Erweiterung dieses Standards Transport Layer Security. Also, es ging ganz konkret um die Anzeige des Servernamens beim Verbindungsaufbau. Die Preisfrage dabei lautete: Soll der Servername beim Verbindungsaufbau verschlüsselt werden oder weiterhin in Klartext übermittelt werden?

Kloiber: Wozu brauchen wir denn die Anzeige des Servernamens, wenn eine Verbindung aufgebaut wird? Eigentlich sollte doch die IP-Adresse reichen, oder?
Peter Welchering: Die IP-Adresse hat ausgereicht, solange eine Website einer Domain darüber eindeutig zu identifizieren war. Jetzt teilen sich aber immer häufiger verschiedene Websites von ganz unterschiedlichen Domains einen Server, der nur eine IP-Adresse besitzt. Beim Aufbau einer verschlüsselten TLS-Verbindung fordert nun der Klient, also der Rechner, der die Verbindung aufgebaut hat, vom Server ein Verschlüsselungszertifikat an. Das war bisher üblicherweise das mit der IP-Adresse des Servers verbundene Zertifikat. Das klappt aber nicht mehr, wenn ein Server mit einer IP-Adresse von verschiedenen Hosts genutzt wird, also auch verschiedene Dienste unterschiedlicher Hosts anbietet. Dann muss der Host, wenn er angesprochen werden soll, das Zertifikat für die Verschlüsselung übermitteln. Und diese Information, welcher Host wird da angesprochen, die steht in der Server Name Indication, der Anzeige des Servernamens. Das läuft bisher unverschlüsselt. Und da denken die Internet-Ingenieure schon einige Zeit darüber nach, diese Information zu verschlüsseln. Denn über die Anzeige des Servernamens lässt sich sehr schön nachverfolgen, wer da mit wem kommuniziert, wer da Verbindungen zu welchem Host aufbaut.

Manfred Kloiber: Was haben die Sicherheitsbehörden und die Unternehmensvertreter gegen die Verschlüsselung des Servernamens denn einzuwenden?

Peter Welchering: Zum einen argumentieren sie, dass mit einer solchen Erweiterung des TLS-Protokolls zur Verschlüsselung des Servernamens das gesamte Protokoll noch einmal komplexer würde. Aber dahinter steckt natürlich die Überlegung, dass dann die bisher so einfach auszuwertenden Metadaten der Kommunikationsverbindungen von Gerät zum Server nicht mehr so einfach, das heißt, unverschlüsselt zur Verfügung stehen würden. Und deshalb haben sie in Montreal lautstark darüber geklagt, dass die IETF zu großen Wert auf Datenschutz lege und dadurch Dienste unnötig verkompliziert würden.

Manfred Kloiber: Gab es in Montreal denn eine Entscheidung zur Verschlüsselung des Servernamens?

Peter Welchering: Eine Entscheidung gab es noch nicht, aber es ist ein alternativer Vorschlag diskutiert worden, der aus der Mozilla-Stiftung stammt. Die Verschlüsselung des Servernamens soll dabei vom Provider ausgehen, das heißt, der verschlüsselte Servername würde den Provider identifizieren. Dabei wird der öffentliche Schlüssel des Providers im Domain Name System veröffentlicht, sodass die Verbindung vom Klienten zum Host des Providers von vornherein über diesen Schlüssel kryptiert werden kann. Ist der verschlüsselte Servername übermittelt, werden die Verschlüsselungszertifikate ausgetauscht und die ganz normale Verschlüsselung nach TLS 1.3 findet statt. Dieses Verfahren wäre deutlich weniger komplex. Aber es geht dabei auch letztlich nicht um Komplexität, sondern darum, dass Behörden und Unternehmen des Sicherheitsbereichs weiterhin auf unverschlüsselte Metadaten der Kommunikation im Netz zugreifen wollen. Und diese Diskussion wird noch lange geführt werden.