1. Foren
  2. Kommentare
  3. Security-Forum
  4. Alle Kommentare zum Artikel
  5. › IETF: TLS 1.3 ist zu sicher für…

Middleboxen können auch TLS1.3

  1. Thema

Neues Thema


  1. Middleboxen können auch TLS1.3

    Autor: chefin 02.11.17 - 15:40

    Allerdings nur, wenn der Endclient dem zustimmt und einem Zertifikat der Middlebox traut bzw der Middlebox das Recht dazu gibt.

    Technisch ist das einfach umzusetzen. Aber nicht, wenn der Nutzer nichts davon weis oder wissen darf.

    Aber auch der Server könnte aktiv werden und der Middlebox seinerseits Infos zukommen lassen, die Verschlüsselung aufzubrechen. Der Server kann es schliesslich auch entschlüsseln. TLS1.3 wird also nur dann zum Problem, wenn es heimlich ohne Wissen des Anbieters UND Nutzers passieren soll. Und damit wird auch irgendwie klar, wieso das ein Problem ist.

  2. Re: Middleboxen können auch TLS1.3

    Autor: Anonymer Nutzer 02.11.17 - 15:42

    siehe bitte meinen kommentar dazu.

    was du beschreibst, gilt nicht nur für tls 1.3 sondern für alle versionen davor auch schon. solange der client nicht mitmacht (absichtlich mit CA der middle box oder unabsichtlich durch fehlerhafte tls implementierung), klappt das auch bei tls 1.0 bis 1.2 nicht.

  3. Re: Middleboxen können auch TLS1.3

    Autor: gaym0r 02.11.17 - 16:55

    Im Artikel steht doch, dass TLS1.3 solche MITM-"Angriffe" verhindern kann. War das gelogen?

  4. Re: Middleboxen können auch TLS1.3

    Autor: Anonymer Nutzer 02.11.17 - 16:58

    verhindern können diese angriffe nicht werden. sie können komplizierter werden und es entsteht eben die notwendigkeit, _alle_ tls verbindungen aufzubrauchen. das wiederum aber kann gegen die policy des unternehmens und/oder gesetze verstoßen. das ist das große problem. alles andere ist kein problem.

  5. Re: Middleboxen können auch TLS1.3

    Autor: Anonymer Nutzer 02.11.17 - 18:28

    Genau das soll eben mit 1.3 nicht mehr möglich sein.

  6. Re: Middleboxen können auch TLS1.3

    Autor: chuck0r 02.11.17 - 20:51

    Dazu muss man die Änderungen zwischen TLS 1.x und TLS 1.3 kennen und verstehen.

    Hierzu würde ich folgenden Cisco Artikel empfehlen:

    https://blogs.cisco.com/security/the-impact-on-network-security-through-encrypted-protocols-tls-1-3

    tldr:
    TLS 1.3 lässt beim Verbindungsaufbau einen Schritt weg und die Middlebox (transparenter Proxy) ist nicht mehr in der Lage, die Domains, für welche das vom Server zur Verfügung gestellte Zertifikat ausgestellt wurde, auszulesen. Daher kann die Middlebox kein Zertifikat on-the-fly generieren und dem Client vorlegen (Auf dem Client ist die CA der Middlebox "trusted").
    Bei explizit hinterlegten Proxies funktioniert TLS 1.3 und das Lesen der Daten in der Verbindung weiterhin, da der Proxy vom Client beauftragt wird, mit Ziel google.de eine Verbindung zu öffnen - hierbei managt also der Proxy die Verbindung und muss die Verbindung nicht "aufbrechen".



    1 mal bearbeitet, zuletzt am 02.11.17 20:52 durch chuck0r.

  7. Re: Middleboxen können auch TLS1.3

    Autor: Anonymer Nutzer 03.11.17 - 00:28

    so wie ich es verstanden habe, geht es bei tls 1.3 auch noch. es wird nur erschwert, sodass es nötig ist, alle tls verbindungen aufzubrechen. selbst jene, die man eigentlich nicht aufbrechen will oder darf.

    vor sni war es so, dass auf einer kombination aus ip-addresse und tcp port nur ein zertifikat auftauchen konnte. namensbasierte virtual hosts gab es nicht, weil der server nicht erkennen konnte, für welchen namen er das zertifikat auswählen soll. für eine middlebox war es also einfach: sie erkennt, zu welchem server der client eine verbindung aufbauen will, unterbricht dies, hält die verbindung zum client an, baut selbst eine verbindung zum server auf und erkennt durch das vom server geschickte zertifikat, für welche hostnames es verfügbar ist. daraufhin wurde ein temporäres auf der middlebox erzeugt, das genau die gleichen hostname enthielt, und die tls verbindung zum cilent fortgesetzt. danach wurde der traffic von client durch die middlebox zum server durchgeleitet. alles gut so weit.

    dann kam sni. sni ermöglicht der middlebox das zertifikat sofort zu erzeugen, da der client ja sagt, mit welchem hostname er kommunizieren will. sni hilft also.

    jetzt kommt tls 1.3. gehen wir mal davon aus, dass alles gleich ist. es gibt nur zwei unterschiede. der server schickt das zertifikat nicht mehr im klartext wie früher sondern verschlüsselt (ja, mir ist noch nicht ganz klar wie genau, aber dazu müsste man das tls 1.3 rfc lesen). ohne also die verschlüsselung aufzubrechen, kann die middlebox nicht mehr wissen, für welchen hostname es das temporäre zertifikat ausstellen soll. jetzt haben wir aber noch sni. wäre also kein problem, solange das sni im klartext bleibt. allerdings gibt es dazu auch schon eine idee, es zu verschlüsseln. die middlebox hat jetzt _ohne_ die tls verbindung aufzubrechen, keine chance mehr, den hostname zu erkennen, für den das temopärer zertifikat erstellt werden muss.

    damit ergibt sich also: ohne aufbrechen _aller_ tls verbindungen, ist es nicht mehr möglich, den passenden hostname für das temporärer zertifikat zu finden. damit ist es nicht mehr möglich, tls verbindungen (zb für online banking) ungebrochen zuzulassen.

  8. Re: Middleboxen können auch TLS1.3

    Autor: Anonymer Nutzer 03.11.17 - 01:48

    wozu genau sollte noch einmal überhaupt irgendwas unterwegs aufgebrochen werden, vielleicht ist das einfach ein grundsätzliches ziel, dass von niemandem außer dem eigentlichem adressaten auch nur irgendetwas entslüsselt werden soll?

  9. Re: Middleboxen können auch TLS1.3

    Autor: zacha 03.11.17 - 09:18

    Ganz einfach, weil die Compliance- Anforderungen in Unternehmen das erfordern können. Weil eben z.B. sichergestellt werden soll, dass bestimmte Webseiten oder Server nicht erreicht werden können oder weil eingehender und ausgehender Traffic auf Viren/Malware/Spam/Attacken usw. untersucht werden soll (so kann z.B. Unternehmenspolitik sein, dass Mails nur über einen zentralen Server verschickt oder empfangen werden dürfen- um sicher zu stellen, dass die Aufbewahrungspflichten nach HGB und AO eingehalten werden und dass kein Spamversand erfolgt oder Vireninfektionen über Email möglich sein. Effektiv geht das nicht mehr, ohne TLS zu brechen, zumindest nicht, wenn man die Kommunikation nicht auf eine kleine Whiteliste von Gegenstellen beschränken kann- was in der Praxis nicht realisierbar ist. TLS macht Firewalls zunehmends dumm und nutzlos. Die Firewall kann nicht mehr erkennen, um was für Traffic es sich handelt. In einem TLS- Kanal kann der Abruf einer harmlosen Webseite stecken aber genausogut kann darin auch ein nichtautorisierte VPN-Tunnel in das Konkurrenzunternehmen stecken, Die Middleboxen bzw. TLS- Interception- Proxies stellen also nicht nur sicher, dass der Traffic, welcher in dem Kanal läuft auch tatsächlich HTTP ist, sondern auch, dass dieser den Compliance-Anforderungen des Unternehmens entspricht. Dass man das natürlich genausogut missbrauchen kann ist klar und an der Stelle ist die generelle Abwägung- soll es in Zukunft noch möglich sein, Netzwerktraffic zu managen oder sollte jede Firma gezwungen sein, entsprechenden Bemühungen aufzugeben im Hinblick auf die Privatsphäre der Mitarbeiter?

  10. Re: Middleboxen können auch TLS1.3

    Autor: Anonymer Nutzer 03.11.17 - 10:42

    ob man sollte oder nicht sollte, ist eine andere frage. mir geht es nur um den technischen teil und den grund, warum cisco ein problem damit hat.

  11. Re: Middleboxen können auch TLS1.3

    Autor: bombinho 03.11.17 - 11:19

    Jetzt bin ich aber erstaunt. Es geht nicht mehr, der Client-Firewall zu sagen, dass z.B. Kommunikation ueber Exchange/IMAP/POP etc. nur mit einer bestimmten Domain/IP zulaessig ist?

    Und nicht einmal so sehr TLS macht externe Firewalls zunehmend nutzlos, IPv6 ueberfordert solche Loesungen ebenfalls zunehmend.

    Was das Ableiten von Daten angeht, da muesste man erst einmal generell Skriptausfuehrung auf Webseiten per se unterbinden, ansonsten implementiert genanntes interessiertes Konkurrenzunternehmen schlicht ein Skript, welches Daten einfach noch einmal z.B. mit RC4* codiert, bevor sie zum eigens eingerichteten Server mit einer anonym registrierten Domain geschickt werden, da hilft die Inhaltsanalyse so glatt kein bisschen, solange der frisch abgeworbene Mitarbeiter in seinem alten Unternehmen keine moralischen Skrupel hat und kein Whitelisting vorher schon die Verbindung gestoppt hat. Fuer den Echtzeit-Schluesselaustausch muesste auch das private Handy des abgeworbenen Mitarbeiters blockiert/ueberwacht werden.

    Wohingegen eine Verhaltensanalyse des Clienten entsprechende Warnzeichen auch ohne Aufbrechen liefern koennte. Schliesslich muessen die Datenpakete ja noch irgendwie zugestellt werden koennen.

    *RC4 als simple und schnelle, einfach zu erstellende Loesung, die den Firmenadmin vom Mitlesen auf einige Jahrzehnte abhalten duerfte.

  12. Re: Middleboxen können auch TLS1.3

    Autor: bombinho 03.11.17 - 11:21

    Bist du sicher, dass mit TLS1.3 keine Verbindungen ueber clientseitig eingestellte Proxys mehr moeglich sind?

  13. Re: Middleboxen können auch TLS1.3

    Autor: gaym0r 03.11.17 - 11:42

    bombinho schrieb:
    --------------------------------------------------------------------------------
    > Jetzt bin ich aber erstaunt. Es geht nicht mehr, der Client-Firewall zu
    > sagen, dass z.B. Kommunikation ueber Exchange/IMAP/POP etc. nur mit einer
    > bestimmten Domain/IP zulaessig ist?

    Doch, aber was soll das bringen?

    > Und nicht einmal so sehr TLS macht externe Firewalls zunehmend nutzlos,
    > IPv6 ueberfordert solche Loesungen ebenfalls zunehmend.

    Echt? Welche z.B.?

  14. Re: Middleboxen können auch TLS1.3

    Autor: bombinho 03.11.17 - 11:56

    gaym0r schrieb:
    --------------------------------------------------------------------------------
    > bombinho schrieb:
    > ---------------------------------------------------------------------------
    > > Jetzt bin ich aber erstaunt. Es geht nicht mehr, der Client-Firewall zu
    > > sagen, dass z.B. Kommunikation ueber Exchange/IMAP/POP etc. nur mit
    > > einer bestimmten Domain/IP zulaessig ist?
    >
    > Doch, aber was soll das bringen?

    Vermutlich wird folgendes Zitat dich erhellen:
    "Weil eben z.B. sichergestellt werden soll, dass bestimmte Webseiten oder Server nicht erreicht werden können oder weil eingehender und ausgehender Traffic auf Viren/Malware/Spam/Attacken usw. untersucht werden soll (so kann z.B. Unternehmenspolitik sein, dass Mails nur über einen zentralen Server verschickt oder empfangen werden dürfen- um sicher zu stellen, dass die Aufbewahrungspflichten nach HGB und AO eingehalten werden und dass kein Spamversand erfolgt oder Vireninfektionen über Email möglich sein."

    >
    > > Und nicht einmal so sehr TLS macht externe Firewalls zunehmend nutzlos,
    > > IPv6 ueberfordert solche Loesungen ebenfalls zunehmend.
    >
    > Echt? Welche z.B.?
    Google mal die SOHO-Loesungen der letzten 10 Jahre.

  15. Re: Middleboxen können auch TLS1.3

    Autor: Lachser 10.11.17 - 16:54

    Das ist doch quatsch.
    Der Sinn von TLS als End-to-End Verschlüsselung ist es ja gerade, dass keiner die Verbindung aufbrechen soll. Und damit ist auch der Arbeitgeber gemeint.
    Es darf auch keinenfalls eine Zweiklassenverschlüsselung geben a la Onlinebanking ist gut und muss unknackbar sein, Youtube ist böse und muss aufgebrochen werden.
    Das ist schon per se quatsch. Verschlüsselt ist verschlüsselt.

    Für Banken und Ähnliches gibt es dennoch Lösungen. Als Server muss halt eben das System Loggen, dass berechtigter Empfänger der Daten ist.
    Und für die Clients & deren Sicherheit gibt es die Möglichkeit dass ein Filterproxy dazwischen ist, der die eigentliche TLS Verbindung zum Ziel aufbaut, das Resultat inspiziert und dann neu verschlüsselt (mit einem on-the-fly Zertifikat) an den Client zurück gibt.
    Da die Browser unter der Kontrolle des Unternehmens liegen, muss dazu eben das entsprechende CA Zertifikat vom Proxy ausgerollt werden. Kein Problem.

  16. Re: Middleboxen können auch TLS1.3

    Autor: bombinho 11.11.17 - 18:41

    +1

  1. Thema

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. (Senior) Solution Architect - Dynamics 365 / Power Platform (*)
    ista SE, Essen
  2. Gruppenleiter Applikationsmanagement (m/w/d)
    IT-Consult Halle GmbH, Halle (Saale)
  3. Global Procurement Expert (m/f/d)
    Advantest Europe GmbH, Böblingen
  4. Mitarbeiter IT-Support Arbeitsmedizinische Software (Samas) (m/w/d)
    DEKRA Automobil GmbH, Stuttgart

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 105,90€ + 6,99€ Versand (Vergleichspreis 139,99€)
  2. 161€ (Angebot auch bei Saturn erhältlich. Vergleichspreis ca. 240€)
  3. 129€ (Bestpreis mit MediaMarkt & Saturn. Vergleichspreis 155€)
  4. 2.599€ (Vergleichspreis 2.999€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Digitale-Dienste-Gesetz: Regierung bessert bei der Störerhaftung nach
Digitale-Dienste-Gesetz
Regierung bessert bei der Störerhaftung nach

Bei der Umsetzung des DSA in deutsches Recht soll der Schutz vor kostenpflichtigen Abmahnungen nun doch beibehalten bleiben.
Ein Bericht von Friedhelm Greis

  1. Störerhaftung Verbraucherschützer befürchten neue Abmahnwelle bei WLANs

Powerstream-Wechselrichter: Mein Balkonkraftwerk, mein Strom
Powerstream-Wechselrichter
Mein Balkonkraftwerk, mein Strom

Mit dem Powerstream-Wechselrichter hat Ecoflow ein Gerät, das verschiedene Powerstationen des Herstellers als Energiespeicher nutzen kann. Wie gut das funktioniert und wie wirtschaftlich es ist, haben wir ein halbes Jahr lang getestet.
Von Mario Keller

  1. Erleichterungen bei Balkonkraftwerken Bundestag tritt bei Solarpaket auf die Bremse
  2. Juristisches Gutachten Wer haftet bei Schäden durch ein Balkonkraftwerk?
  3. Eigentümer und Mieter Anspruch auf Balkonkraftwerke kommt im Frühjahr 2024

Zbox Pico PI430AJ: Flotter Mini-PC mit Solid-State-Kühlung
Zbox Pico PI430AJ
Flotter Mini-PC mit Solid-State-Kühlung

Die fast lautlosen Kühler von Frore Systems funktionieren gut. Mehr Leistung auf so kleinem Raum ist kaum möglich. Eine ARM-CPU wäre aber spannend.
Ein Test von Martin Böckmann