"das Zerstören von TLS günstiger umzusetzen sei"

[Frotty]

Sagt eigentlich alles. Die Lobbyarbeit zu betreiben ist günstiger und einfacher. Wäre traurig wenn dadurch die extension durchgedrückt wird. Dass undurchdachte extensions Sicherheitsrisiken mit sich bringen hat sich ja selbst in der TLS Vergangenheit schon gezeigt.

[Bigfoo29]

Spannend ist das insbesondere für CISCO und Co. Denn DIE verlieren damit die Kontrolle über die Inhalte, die sie derzeit mittels DPI (noch) bekommen. Ich sehe durchaus das Problem, auf Load-Balancern und Co. Aber dann muss man halt einen Schritt zurück machen und auf Grund der Traffic-Gestaltung Rückschlüsse ziehen und das Routing entsprechend umsetzen. Non-Discriminatory muss es ja eh sein. Daher ist eigentlich auch egal, was drin ist.

Für den Bankensektor (Ich weiß, dass die recht strenge Vorgaben haben) ist das zwar ein mögliches Problem, aber eigentlich auch nur sehr begrenzt. Traffic kann man nach den SSL-Offloadern mitschneiden. Und persönlich verschlüsselte Emails gabs auch früher schon. Das musste man also auch früher schon anders lösen. Aber ja, dazu müssen sich halt ein paar "Großkopferte" mal mit ein paar (System- und Software-)Ingeneuren zusammensetzen und die rechtlichen Grundlagen anders abbilden. Es gibt IMMER einen anderen Weg. Aber wie andere schon schrieben: Das kostet halt Geld. Und im Gegensatz dazu sind die Lobbyisten halt "EhDa"-Kosten...

Regards.

[tingelchen]

Gerade bei Banken und anderen Unternehmen sehe ich da eigentlich gar kein Problem. TLS ist eine Transportverschlüsselung. Das heißt an den jeweiligen Endpunkten wird das ganze eh entschlüsselt. Sonst funktioniert ja die Kommunikation auf Anwendungsebene nicht.

Muss man also an die Daten ran, kann man dies eben an den Endpunkten machen. Hat man das also vorher auf Transportwegen gemacht, muss man das ganze halt verschieben.

Was Load Balancing angeht. Die meisten Techniken dahin gehend arbeiten überhaupt nicht mit DPI. Sondern mit Auslastungsfaktoren. Denen ist es egal welche Daten sich in einem Protokoll befinden. Hier wird die Last möglichst gleichmäßig verteilt. Was mehr gemeint ist, wenn man von CISCO & Co. redet ist nicht Load Balancing, sondern Quality of Service (QoS). Welches stark auf DPI setzt um entsprechende Entscheidungen treffen zu können. Was aber wiederum lösbar ist. Denn die TCP/UDP Header selbst ist nicht verschlüsselt. Hier können entsprechende Informationen abgelegt werden. Was auch gemacht wird und QoS unter anderem nutzt.

[chefin]

Naja...loadbalancing ist nicht ganz so einfach, wenn der Angreifer weis das auch seine Angriffe verteilt durchgreicht werden. Wenn du stattdessen am Loadbalancer schon mögliche Syn-flood Angriffe blockierst, bevor sie zum Server kommen, kann der um Welten mehr aushalten.

Auch andere Angriffsformen sind nicht ohne Kenntniss des Inhaltes zu lokalisieren. Natürlich, bestimmte Angriffe erkennt man auch ohne die Verschlüsselung anzulangen. Aber nicht alle. Das Problem ist halt, wenn Angreifer um die Schwachstelle wissen, nutzen sie diese auch aus.

Und da es hier um spezielle Bereiche geht, sollte die Entscheidung beim Dienstbetreiber liegen dürfen. Die Bank entschlüsselt ja eh die Daten und weis dann was drin steht. Also kann es auch der bankeigene Loadbalancer. Ich wüsste jetzt auch keinen Dienst der mit Loadbalancer arbeitet, aber hinterher nicht auch die Daten sammelt um davon zu profitieren.

[tingelchen]

Angriffe über SYN-Pakete sind jetzt kein gutes Pro Beispiel. Da die Information im TCP Header steckt

https://de.wikipedia.org/wiki/Transmission_Control_Protocol#/media/File:TCP_Header.svg

Da dieser nicht verschlüsselt ist und auch weiter führende Informationen im TCP Header stecken kann man Angriffe auch ohne Kenntnisse des Inhaltes erkennen. Eine DoS Attacke (egal in welcher Variation) kommt immer mit einer Überflutung einher. Man versucht den Dienst daran zu hindern reguläre Verbindungsversuche nicht mehr annehmen zu können. Im Idealfall (aus Sicht des Angreifers) schmiert der Service oder gar der komplette Netzwerk Stack ab.

Dahin gehend gibt es einige Produkte die das erkennen. Seit einiger Zeit steckt ein Teil schon in jeder Firewall. Kenntnis über den Inhalt ist dafür gar nicht nötig. Ob der Aufbau nun auf ein HTTP Request, IPsec Request oder was auch immer abzielt ist Jacke wie Hose. Der Ziel Port (Der Dienstanbieter sollte diese Zwangsweise kennen) sagt schon alles darüber aus, welcher Service das eigentliche Ziel ist.

Für alle anderen Angriffe, bzgl. Eindringen in die Server, sieht das natürlich anders aus. Hier geht es tatsächlich um den Inhalt der Pakete selbst. Da man versucht dem Service ein faules Paket unter zu schieben um ihn dazu zu bringen Code aus zu führen, der nicht ausgeführt werden soll. An dieser Stelle kann man natürlich dann jegliche Produkte vergessen, welche dies auf Protokoll Ebene erkennen, bevor diese den Dienst erreichen. Zumindest in der Transparenten Art. Lösen kann man dieses Problem aber dennoch. Denn derartige "Services" stehen meist innerhalb des Netzwerkes. Der Endpunkt des TLS Kanals muss dann eben dieser sein, statt der eigentliche Dienst.

[Bigfoo29]

"Und da es hier um spezielle Bereiche geht, sollte die Entscheidung beim Dienstbetreiber liegen dürfen"
Äääh, nein, wenn die Dienstanbieter damit ein sicheres Netz kompromittieren, weil sie dafür sorgen, dass die Standards nicht mehr sicher sind, ist das keine Entscheidung der Dienstanbieter sondern ein egoistischer Eingriff ins Netz. Genauso gut könnte - ich übertreibe jetzt bewusst - die Ansage über die NSA kommen, dass ab sofort alle verschlüsselten Verbindungen nicht schneller als 256kbit/s sein dürfen, weil man sonst global gesehen mit dem Speichern (und späteren Entschlüsseln) nicht mehr hinterher kommt.

Die Leute müssen tatsächlich damit leben, dass manches mit einer funktionierenden Verschlüsselung schlechter zu überwachen ist. Alles, was dokumentiert werden muss, kann man nach den SSL-Offloadern machen. Und alles, was halbwegs illegal aussieht, kriegt man eben entweder über ihre unverschlüsselten Transport-Header oder dann erst in der Backend-Analyse.

Regards.