IETF: Streit um sicheres HTTP 2.0 neu entbrannt
Den HTTP-Verkehr grundsätzlich zu verschlüsseln, dazu mag sich die IETF nicht durchringen. Zweifler meinen, der Schuss könnte nach hinten losgehen und die Verbreitung der Verschlüsselung bremsen. Einzig die Entwickler einer Chat-Software sind da unbeirrt.
Vor den Enthüllungen über die massenhafte Ausspähung des Internetverkehrs durch US-Behörden war sich die Internet Engineering Task Force fast einig: Das Nachfolgeprotokoll für HTTP, HTTP 2.0 sollte nicht zwangsläufig an die Absicherung mittels Transport Layer Security (TLS) geknüpft werden. Aber angesichts der neuen Angriffsszenarien wollen nun einige Entwickler die Diskussion zu diesem Thema neu aufrollen. Insbesondere warnten sie bei Treffen der HTTPBis-Arbeitsgruppe in Vancouver davor, dass opportunistische Verschlüsselung oder eine neu vorgestellte TLS-Relax-Lösung anstelle der bisherigen harten Zertifikatslösungen Angreifer ermutigen würden.
Sich damit zu beruhigen, dass Angreifer bei einfacher Verschlüsselung aufwändige aktive Attacken auf Webkommunikation starten müssen und Schlüssel mit zu sniffen, reiche angesichts der in den vergangenen Monaten bekannt gewordenen Informationen nicht mehr aus, warnte Keith Moore, Ko-Autor verschiedener RFCs zum Mailversandprotokoll SMTP. "Wenn eine passive Attacke möglich ist, ist auch eine aktive möglich und wenn vielleicht nicht heute, dann morgen auf jeden Fall", sagte Moore. Das größte Problem sei dabei, dass IDs und persönliche Identifikationsmerkmale über Cookies ungewollt in die Hände von Dritten geraten können. Ähnlich schwerwiegend sind Implementierungsschwachstellen. Die ursprüngliche Entscheidung, das HTTP-Nachfolgeprotokoll an die Verwendung von TLS zu binden, würde im Licht der jüngsten Abhörereignisse möglicherweise anders ausfallen, sagte Ex-IAB-Mitglied Ted Hardie.
Nicht perfekt, aber immerhin brauchbar
Der Vorsitzende der HTTPBis-Arbeitsgruppe, Mark Nottingham, hat einen Vorschlag für die opportunistische Verschlüsselung vorgelegt, die die für TLS klassische Überprüfung des Serverzertifikats freistellt. Der anfragende Client, so heißt es im Entwurf, könne die Serverantworten auch anders auf dessen Vertrauenswürdigkeit prüfen. Nottinghams Vorschlag macht dabei aber auch auf den Nachteil aufmerksam: So wären nach aktuellem Entwurf auch Downgrade-Attacken möglich, also Manipulationen des Verbindungsaufbaus, mit dem Ziel, eine Kommunikation im Klartext zu erzwingen. Dennoch hält Nottingham die Methode für brauchbar. In vielen Szenarien seien aktive Attacken technisch gar nicht möglich oder viel zu aufwendig. Außerdem können aktive Attacken oft entdeckt werden, weil sie Protokoll-Interaktionen ändern. Deshalb riskiert der Angreifer, entdeckt zu werden.
Viele Teilnehmer der Arbeitsgruppe sehen trotz der Vorbehalte mehr Vor- als Nachteile durch die opportunistische Verschlüsselung, vor allem, weil sie wesentlich einfacher umzusetzen ist und sich Verschlüsselungen somit überhaupt besser verbreiten würden. Ein TLS-Mandat, das jedem Serverbetreiber weltweit ein Zertifikat aufzwingen will, könnte hingegen die Migration zu HTTP 2.0 hemmen, warnten mehrere Experten. Richard Barnes von BBN meint, dass das Zertifikatssystem durch einen solchen Massenbetrieb noch weiter an Qualität verlieren würde. Aber eine nutzerfreundliche Alternative scheint nicht in Sicht, auch die Nutzung von per DNSSEC abgesicherten DNS-Zertifikaten nach dem neuen DANE-Standard scheint keine Abhilfe zu bringen.
Uneinig hinsichtlich des Ziels
Noch ist die HTTPBis-Arbeitsgruppe gespalten hinsichtlich des richtigen Wegs zu Steigerung der Sicherheit im WWW. Ein Teil der Mitglieder glaubt, es kann reichen, dass immer mehr große Anbieter sämtlichen Verkehr nur noch per SSL-Verschlüsselung abwickeln (also per HTTPS); der Sog könnte alle übrigen Mitspieler mitziehen. Eine andere Gruppe sieht in der opportunistischen Verschlüsselung den richtigen Weg und die dritte erhofft sich das von einem verpflichtenden Einsatz der TLS-Technik. Ähnlich zögerlich hatten sich Vertreter aus den Stammarbeitsgruppen für SIP (also die VoIP-Telefonie) und SMTP gezeigt (Mailauslieferung).
Unbeirrt
Die TLS-Fahne ausdrücklich hochhalten will dagegen die Jabber-Community. Ab 19. Mai kommenden Jahres soll alle XMPP-Kommunikation per TLS abgesichert sein. Das kündigte Jabber-Ko-Autor Peter St. Andre in Vancouver an. Man sei den Nutzern, selbst wenn diese davon nichts mitbekämen, das Mehr an Sicherheit jetzt dringend schuldig, sagte St. Andre. Dabei nehmen die Entwickler auch Einschränkungen in Kauf: Verbindungen mit Google Talk funktionierten dann nicht mehr. Mitgliedern der Arbeitsgruppe Application Area riet St. Andre bei einem Brainstorming zum Thema "TLS over everything" pragmatisch dazu, die Effekte des Umstiegs für XMPP zu beobachten und je nach Ergebnis zu entscheiden, ob sie die Übertragungen ihrer Anwendungen ebenfalls per TLS härten wollen. (dz)
