Gerade ist bekannt geworden, dass Apple, Cloudflare, Fastly und Mozilla beim IETF 102 Hackathon zusammengearbeitet haben, um die Verschlüsselung des Mechanismus zur Identifizierung von Servernamen von HTTPS zu verbessern, wie aus einem Tweet von Nick Sullivan von Cloudflare hervorgeht. Der Tweet gratulierte dem Mix-Team der vier Technologiegiganten, indem er „Awesome work“ sagte und dort unter Links zu den Arbeitsservern von teilte esni.examp1e.net und cloudflare-esni.com .
Tolle Arbeit beim IETF 102-Hackathon durch das verschlüsselte SNI-Team, bestehend aus Leuten aus @ Cloudflare @ schnell @mozilla und @Apfel . Es gibt jetzt Implementierungen in BoringSSL, NSS und Picotls.
Arbeitsserver sind live bei https://t.co/sLI9xLRjlK und https://t.co/AoC2SIlJ7N .
- Nick Sullivan (@grittygrease) 15. Juli 2018
Der IETF-Hackathon ist eine Plattform, die junge Entwickler und Technikbegeisterte dazu einlädt, gemeinsam Lösungen für technologische Probleme zu entwickeln, mit denen der normale Benutzer heute konfrontiert ist. Die Veranstaltungen sind kostenlos, offen für alle und fördern die Teamarbeit im Gegensatz zum Wettbewerb. Der diesjährige IETF Hackathon fand am 14. in Montreal stattthund 15thdes Julis. Die bedeutendste Errungenschaft ist anscheinend die Verschlüsselung der SNS (Server Layer Security) für Transport Layer Security (TLS), ein Problem, das Entwickler in den letzten zehn Jahren geplagt hat und das Mitglieder von Apple, Cloudflare, Fastly und Mozilla haben nun eine Lösung für vorgeschlagen.
IETF Hackathon Event. IETF
In den letzten anderthalb Jahrzehnten gab es eine deutliche globale Verschiebung von HTTP (Hyper Text Transfer Protocol) zu TLS SNI HTTPS (Hyper Text Transfer Protocol Secure). Das Problem Das Ergebnis der Optimierung des TLS-SNI-HTTPS-Systems war die Fähigkeit des Hackers, SNI gegen seinen Zweck zu verwenden, um die Datenübertragung für die spätere Entschlüsselung abzugleichen.
Vor der Entwicklung von SNI war es schwierig, mit demselben ersten Client-Handshake sichere Verbindungen zu mehreren virtuellen Servern herzustellen. Wenn eine IP-Adresse mit einem Server interagierte, tauschten die beiden 'Hallo' aus, der Server sendete seine Zertifikate, der Computer sendete seinen Client-Schlüssel, die beiden tauschten 'ChangeCipherSpec' -Befehle aus und dann wurde die Interaktion beendet, als eine Verbindung hergestellt wurde. Dies mag so einfach klingen, wie es gerade gesagt wurde, aber der Prozess umfasste mehrere Austausche und Antworten, die leicht problematisch wurden, da die Anzahl der Server, mit denen kommuniziert wurde, zunahm. Wenn alle Sites dieselben Zertifikate verwendeten, war dies kein großes Problem, aber leider war dies selten der Fall. Wenn mehrere Standorte verschiedene Zertifikate hin und her sendeten, war es für den Server schwierig zu bestimmen, nach welchem Zertifikat der Computer suchte, und in dem komplexen Netz von Börsen wurde es schwierig zu identifizieren, wer was und wann gesendet hatte, wodurch die gesamte Aktivität beendet wurde mit einer Warnmeldung insgesamt.
TLS SNI wurde dann im Juni 2003 im Rahmen eines IETF-Gipfels eingeführt. Der Zweck bestand gewissermaßen darin, Namensschilder für die Computer und Dienste zu erstellen, die am Austauschnetz beteiligt sind. Dies machte den Hallo-Austausch-Prozess zwischen Server und Client viel einfacher, da der Server in der Lage war, genau die erforderlichen Zertifikate bereitzustellen, und die beiden in die Lage versetzt wurden, ihren eigenen Konversationsaustausch zu führen, ohne sich darüber zu wundern, wer was gesagt hat. Es ist ein bisschen so, als hätten Sie Kontaktnamen für Chats und werden nicht verwirrt, woher die Nachrichten kommen. Außerdem können Sie auf jede Anfrage angemessen antworten und die richtigen Dokumente für jeden Computer bereitstellen, der sie benötigt. Diese SNI-Definition hat genau das größte Problem bei dieser Methode zur Optimierung des Austauschprozesses ausgelöst.
Der Kampf vieler Unternehmen bei der Umstellung auf HTTPS bestand in der Anpassung vieler Zertifikate an das SNI-Format mit individuellen IP-Adressen, um Anforderungen für jedes Zertifikat auszuführen. Was TLS für sie tat, war, es einfacher zu machen, Zertifikate zu generieren, um auf solche Anfragen zu antworten, und was SNI noch weiter tat, war die Notwendigkeit individueller dedizierter Zertifikat-IP-Adressen zu beseitigen, indem ein ganzes Identifikationssystem über das gesamte Internet-Netzwerk eingebaut wurde. Was mit dem Upgrade des Jahrhunderts einherging, war die Tatsache, dass Hacker die etablierten „Kontaktnamen“ verwenden konnten, um die Datenübertragung zu überwachen und zu beschatten und die Informationen zu extrahieren, die sie zu einem späteren Zeitpunkt zum Entschlüsseln benötigen.
Obwohl TLS es ermöglichte, Daten in einem verschlüsselten Kanal hin und her zu senden, wobei SNI sicherstellte, dass sie das richtige Ziel erreichen, bot letzteres Hackern auch die Möglichkeit, Online-Aktivitäten zu überwachen und sie durch Befolgen von DNS-Anforderungen und IP-Adressen mit ihrer Quelle abzugleichen und Datenströme. Obwohl strengere SNI-Codierungsrichtlinien implementiert wurden, indem DNS-Informationen auch über den TLS-Kanal übertragen wurden, bleibt ein kleines Fenster für Hacker, um diese als Identifikationsmittel verwenden zu können, um den Informationen zu folgen, für die sie sie extrahieren und isolieren möchten Entschlüsselung. Komplexe Server, die mit einem größeren Datenverkehr von TLS-verschlüsselten Daten umgehen, verwenden Klartext-SNI, um die Kommunikation auf ihren Servern zu übertragen. Dies erleichtert Hackern die Identifizierung der Kanäle und Informationsströme, denen sie folgen möchten. Sobald ein Hacker in der Lage ist, die SNI-Informationen der interessierenden Daten zu extrahieren, kann er eine falsche Wiedergabe des Befehls in einer separaten TLS-Verbindung mit dem Server einrichten, die gestohlenen SNI-Informationen senden und die Informationen abrufen, die war damit verbunden. In der Vergangenheit gab es mehrere Versuche, dieses SNI-Problem zu lösen, aber die meisten haben gegen das Einfachheitsprinzip verstoßen, nach dem SNI arbeitet, um es zu einer bequemen Identifikationsmethode für Server zu machen.
Zurück zu dem Gipfel, auf dem diese Methode erstmals etabliert wurde, sind Teilnehmer von vier Technologiegiganten zur Konferenz nach Montreal zurückgekehrt, um eine Verschlüsselung für das TLS-SNI zu entwickeln, da die Sicherheit trotz der größeren Effizienz des angrenzenden Multi-HTTPS-Systems weiterhin ein Problem darstellt so viel wie vorher.
Um die SNI in TLS zu verbergen, muss ein 'versteckter Dienst' unter der Anzeige eines 'Fronting Service' gehalten werden, den der Hacker möglicherweise sieht. Ohne den versteckten Dienst direkt beobachten zu können, wird der Hacker durch die Fronting-Verkleidung, unter der er sich im Klartext versteckt, irregeführt, ohne die zugrunde liegenden Geheimdienstparameter identifizieren zu können, die zum Weiterleiten der verschlüsselten Daten verwendet werden. Wenn der Beobachter der Spur des Fronting-Dienstes folgt, werden die Daten aus dem beobachteten Kanal entfernt, wenn er zu seinem beabsichtigten versteckten Dienst umgeleitet wird. An diesem Punkt hat der Hacker seine Spur verloren. Da der Server auch dem Fronting-Dienst ausgesetzt ist, während die Daten dorthin gelangen, wird ein zweites paralleles SNI-Signal an den Fronting-Dienst gesendet, um die Daten in Richtung des versteckten Dienstes umzuleiten, und in dieser Richtung ändert sich der Hacker im Web des Servers verloren gehen. Dieser Mechanismus von Doppeltickets wird unter demselben SNI zu einem kombinierten Ticket weiterentwickelt. Wenn ein Datenelement an den Server gesendet wird, erzeugen die Daten einen kooperierenden SNI-Re-Director, und die beiden arbeiten zusammen, um die TLS-verschlüsselten Daten dorthin zu bringen, wo sie benötigt werden. Ohne den zufälligen Fronting-Service, der beide SNI-Spuren abdeckt, knacken zu können, kann der Hacker den Spuren der Daten nicht folgen, aber der Server kann die beiden weiterhin verbinden und den versteckten Dienst als endgültigen Speicherort der Daten entschlüsseln. Auf diese Weise können Server weiterhin SNI verwenden, um ihre Datenübertragung bei der TLS-Verschlüsselung zu optimieren und gleichzeitig sicherzustellen, dass Hacker den SNI-Mechanismus nicht nutzen können.
