1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Verschlüsselung: TLS 1.3 ist so gut…

man in the middle angriffe

  1. Thema

Neues Thema Ansicht wechseln


  1. man in the middle angriffe

    Autor: moppi 16.02.18 - 16:04

    das wollen Cisco und co für ihre blackboxen ... das sollte man so auch rein schreiben.

    eigentlich ist das krank ... nur damit firmen ihre eigenen MA ausspioniern können werden solche löcher doch wieder rein gerissen :\ frag mich echt wann HTTPS wieder abgeschafft wird weil es einfach immer wieder zerlöchert wird

    hier könnte ein bild sein

  2. Re: man in the middle angriffe

    Autor: schap23 16.02.18 - 16:09

    Es geht doch nicht (vor allem) darum, daß Firmen wissen wollen, wer während der Arbeitszeit Pornos schaut. Firmen sind auch verpflichtet, zu dokumentieren, was bei ihnen vorgeht. Auch wollen Firmen auffälligen Verkehr rechtzeitig erkennen, bevor alle Rechner verschlüsselt sind.

    Manchmal beißen sich rechtliche Anforderungen und Sicherheit mit Privatheit. Es steht aber jedem frei, auf dem heimischen Rechner alles zu treiben, was sie wünscht.

  3. Re: man in the middle angriffe

    Autor: Ninos 16.02.18 - 16:14

    Dafür gibt es andere Möglichkeiten, als die Verschlüsselung zu durchlöchern.

  4. Re: man in the middle angriffe

    Autor: Anonymer Nutzer 16.02.18 - 16:16

    bei tls 1.3 ging es nie um die belauschbarkeit. die konzepte dagegen sind die gleichen wie bei tls 1.2 und davor. sie sind nach wie vor sicher. tls 1.3 ist nicht in der art besser abgesichert, dass men in the middle nicht mehr mit den gleichen mitteln ginge wie bei tls 1.2.

  5. Re: man in the middle angriffe

    Autor: moppi 16.02.18 - 16:17

    du verstehst nicht wie ich das meine
    es wird eine man in middle funktion eingebaut ... es ist dann egal wo ich surfe, die funktion ist da.
    ergo das system ist mist bevor es eigentlich auf den markt gebracht wird. weil es von hausaus geknackt werden kann. weil firmen drauf zugriff haben wollen.

    sei es zuhause oder in der pampa mit dem privat handy ... es ist möglich sich wieder in den stream zu hacken.

    hier könnte ein bild sein

  6. Re: man in the middle angriffe

    Autor: Dadie 16.02.18 - 16:21

    moppi schrieb:
    --------------------------------------------------------------------------------
    > [..]
    > eigentlich ist das krank ... nur damit firmen ihre eigenen MA ausspioniern
    > können werden solche löcher doch wieder rein gerissen :\
    > [..]

    Die meisten Firmen haben eigentlich kein Interesse die Mitarbeiter auszuspionieren. Das kostet nur Geld und bringt i.d.R. kaum Gegenwert. Aus Analogen Gründen sparen Firmen auch gerne an der internen IT.

    Im Falle eines größeren Schadens fragt die Versicherung (und/oder die Aktionäre) aber, was man getan hat um den Schaden präventiv abzuwenden. Und wenn dann ein Gutachten sagt, dass mit einer MITM-Blackbox das Ganze hätte verhindert werden können, willst du nicht der arme Idiot sein der im Zweifel dafür Haftet.

    Bring den Gutachtern, Versicherungen und Aktionären bei, dass die Blackboxen ein größeres Sicherheitsrisiko sind und kaum eine Firma wird diese mehr nutzen, allein schon weil es billiger ist *keine* Blackbox zu kaufen, zu betreiben oder zu verwalten.

  7. Re: man in the middle angriffe

    Autor: Anonymer Nutzer 16.02.18 - 16:22

    es wird _KEINE_ men in the middle schnittstelle eingebaut. die sicherheit von tls 1.3 wurde auch in keinster weise verringert um men in the middle möglich zu machen. das ist eine absolute fehlinformation. bitte nicht weiter verbreiten.

  8. Re: man in the middle angriffe

    Autor: theq86 16.02.18 - 17:43

    Es ist vom logischen Denken allein schon Schwachsinn anzunehmen, dass MITM sozusagen als "Feature" mit eingebaut wird. Denn dann müsste man ja regulieren, wer es nutzen darf und wer die Möglichkeit hat die Verschlüsselung aufzubrechen. Desweiteren hätte man schon ein paar Wochen später effektive Angriffsvektoren, weil Unberechtigte sich irgendwie einen Weg gegraben hätten das MITM-Feature zu benutzen. Oder ein Leak hätte dafür gesorgt, dass jeder das dann kann. In dem Falle bräuchte man TLS 1.3 gar nicht erst releasen.

    Im Übrigen ist es völlig falsch anzunehmen, dass in Firmen, wenn der HTTPS Traffic abgehört wird, die Verschlüsselung irgendwie gebrochen wird. Keine Firma fährt Angriffe auf HTTPS und entschlüsselt den Verkehr durch "knacken" oder "hacken"

    Vielmehr wird bei einer angefragten HTTPS-Verbindung vom Client diese an der Firewall "gehalten" und die Firewall mimt den angefragten Request selbst. Zwischen Browser und angefragter sicherer Seite wird nie eine Verbindung zustandekommen. Diese kommt zwischen Firewall und angefragter Seite zustande, wobei TLS ganz normal und auf sicherem Weg genutzt wird. Die Firewall nimmt nun die Response und schickt sie per HTTPS mit ihrem eigenen Zertifikat zurück an den Browser. Die Firewall führt also den angefragten Request stellvertretend aus.

    Damit das funktioniert muss man aber die Clients auch entsprechend konfigurieren und die Zertifizierungsstelle der Firewall manuell installieren und ihr Vertrauen aussprechen. Jeder andere Client der zB. privat in die Firma mitgebracht wird und das Zertifikat nicht hat wird merken, dass da was falsch läuft.

  9. Re: man in the middle angriffe

    Autor: traxanos 16.02.18 - 18:14

    Und das ist was mich stört. Ich möchte gerne dieses Feature im TLS implementiert haben, so dass ich als Client sehen kann...

    a) dass die Verbindung von einer Firewall aufgedröselt wird.
    b) dass das Zertifikat vom eigentlichen Server ebenfalls vom Client verifiziert wird und nicht von der Firewall und ich als Benutzer die Entscheidung habe, traue ich dem Server oder nicht.

    Würde man dass im TLS implementieren, müsste die Firewall keine Zertifikate für Fremddomains ausstellen, sondern die Firewall verschlüsselt immer mit dem gleichen Zertifikat, welchem ich vertrauen muss (z.B. durch GPO).

  10. Re: man in the middle angriffe

    Autor: theq86 16.02.18 - 18:33

    > a) dass die Verbindung von einer Firewall aufgedröselt wird.

    Kannst du sehen. Wenn du zB. auf die Seite deiner Bank gehst und das Zertifikat im Browser zwar auf zB. banking.postbank.de passt, aber der Aussteller nicht der Richtige ist, zB. dein Firmenname.

    Gerade bei Banken und Seiten, die ein sogenanntes EV Zertifikat haben merkst du es sofort, weil nicht mehr der ganze Balken grün ist.

    Generell gilt aber: guck dir das Zertifikat an und du wirst es in den meisten Fällen erkennen. Stutzig würde ich auch werden, wenn der Aussteller eines jeden Zertifikates einer jeden Seite der Gleiche wäre.

    > b) dass das Zertifikat vom eigentlichen Server ebenfalls vom Client verifiziert wird und
    > nicht von der Firewall und ich als Benutzer die Entscheidung habe, traue ich dem Server
    > oder nicht.

    Ist bei dieser Konstellation eben nicht möglich. Denn eine direkte Verbindung zwischen Client und Server existiert nicht. Der Client bekommt das eigentliche Zertifikat nie zu Gesicht. Aber wie gesagt, solang du auf dem Client deines AG bist und der das Zertifikat der FW installiert hat wird der Browser es als sicher einstufen. Und trotzdem hast du ja durch Punkt a) die Möglichkeit zu erkennen, OB dein Verkehr entschlüsselt wurde und du hast dann natürlich die Möglichkeit entsprechend zu reagieren. Auch wenn es mehr Aufwand kostet.

    > Würde man dass im TLS implementieren, müsste die Firewall keine Zertifikate für
    > Fremddomains ausstellen, sondern die Firewall verschlüsselt immer mit dem gleichen
    > Zertifikat, welchem ich vertrauen muss (z.B. durch GPO).

    Das ist technisch absolut nicht realisierbar. Um die Serverantwort auf die exakt selbe Weise wieder verschlüsseln zu können, wie die Firewall sie entschlüsselt hat, bräuchte die Firewall den PRIVATEN Schlüssel JEDES Servers mit dem sie kommuniziert. Das würde das gesamte Konzept des Public/Private Key Verfahrens ad absurdum führen und nicht nur die Verschlüsselung, sondern vor allem die Vertraulichkeit unterminieren.

    Alles nicht so einfach.

  11. Re: man in the middle angriffe

    Autor: ldlx 16.02.18 - 18:37

    Bei der Gegenseite wird die Verbindung ebenfalls "aufgedröselt", bevor du "den Webserver" erreichst - da sind Reverse Proxys, Load Balancer, irgendwelches Cloud-Gedöns für die Verteilung des Datenverkehrs auf verschiedene Regionen. Es wird auch TLS-Offloading betrieben, so dass die eigentlichen Webserver nicht mehr mit der Entschlüsselung belastet werden, sondern vorgelagerte Server das entschlüsseln und nur noch HTTP durchreichen. Wo fängt deiner Meinung nach die Verschlüsselung an und wo hört sie auf? Welchen Zertifizierungsstellen vertraust du oder überlässt du das den Betriebssystemanbietern oder deinem Arbeitgeber? Es soll auch Virenscanner geben, die lokale Proxys mit SSL-Neuverschlüsselung direkt auf deinem Computer laufen lassen - vertraust du denen?

  12. Re: man in the middle angriffe

    Autor: robbyflobby 16.02.18 - 19:09

    ldlx schrieb:
    --------------------------------------------------------------------------------
    > Bei der Gegenseite wird die Verbindung ebenfalls "aufgedröselt", bevor du
    > "den Webserver" erreichst - da sind Reverse Proxys, Load Balancer,
    > irgendwelches Cloud-Gedöns für die Verteilung des Datenverkehrs auf
    > verschiedene Regionen. Es wird auch TLS-Offloading betrieben, so dass die
    > eigentlichen Webserver nicht mehr mit der Entschlüsselung belastet werden,
    > sondern vorgelagerte Server das entschlüsseln und nur noch HTTP
    > durchreichen.
    Also wenn das bei Banken wirklich betrieben wird, dann gute Nacht.
    In sicherheitskritischen Umgebung dürfen Loadbalancer nur im Passthrough Modus laufen. Damit ist zwar nur noch TCP Loabalancing möglich, was aber hier in Kauf genommen werden muss.
    Die Last zum Ver- und Entschlüsseln ist auch vernachlässigbar, das läuft symmetrisch.
    Bei etwas weniger kritischen Umgebungen man auch am LB terminieren und neu verschlüsseln. Damit funktioniert auch das HTTP Loadbalancing. Geht das nun eigentlich noch mit TLS 1.3?
    Aber ganz ohne Verschlüsselung zwischen LB und App-webserver ist fahrlässig und für Spielewiesen gedacht.

  13. Re: man in the middle angriffe

    Autor: ldlx 16.02.18 - 19:11

    und wer sagt dir, dass das nicht genau so gemacht wird? technisch geht es und einblick in die infrastruktur jedes unternehmens/jeder bank dürftest du wohl auch nicht haben (ich übrigens auch nicht).



    1 mal bearbeitet, zuletzt am 16.02.18 19:11 durch ldlx.

  14. Re: man in the middle angriffe

    Autor: traxanos 16.02.18 - 19:23

    theq86 schrieb:
    --------------------------------------------------------------------------------
    > > a) dass die Verbindung von einer Firewall aufgedröselt wird.
    >
    > Kannst du sehen. Wenn du zB. auf die Seite deiner Bank gehst und das
    > Zertifikat im Browser zwar auf zB. banking.postbank.de passt, aber der
    > Aussteller nicht der Richtige ist, zB. dein Firmenname.
    >
    > Gerade bei Banken und Seiten, die ein sogenanntes EV Zertifikat haben
    > merkst du es sofort, weil nicht mehr der ganze Balken grün ist.
    >
    > Generell gilt aber: guck dir das Zertifikat an und du wirst es in den
    > meisten Fällen erkennen. Stutzig würde ich auch werden, wenn der Aussteller
    > eines jeden Zertifikates einer jeden Seite der Gleiche wäre.

    Ja, ich weil ich täglich damit arbeite. Aber ein Symbol für Normaluser wäre deutlich lesbarer.

    >
    > > b) dass das Zertifikat vom eigentlichen Server ebenfalls vom Client
    > verifiziert wird und
    > > nicht von der Firewall und ich als Benutzer die Entscheidung habe, traue
    > ich dem Server
    > > oder nicht.
    >
    > Ist bei dieser Konstellation eben nicht möglich. Denn eine direkte
    > Verbindung zwischen Client und Server existiert nicht. Der Client bekommt
    > das eigentliche Zertifikat nie zu Gesicht. Aber wie gesagt, solang du auf
    > dem Client deines AG bist und der das Zertifikat der FW installiert hat
    > wird der Browser es als sicher einstufen. Und trotzdem hast du ja durch
    > Punkt a) die Möglichkeit zu erkennen, OB dein Verkehr entschlüsselt wurde
    > und du hast dann natürlich die Möglichkeit entsprechend zu reagieren. Auch
    > wenn es mehr Aufwand kostet.
    >
    > > Würde man dass im TLS implementieren, müsste die Firewall keine
    > Zertifikate für
    > > Fremddomains ausstellen, sondern die Firewall verschlüsselt immer mit dem
    > gleichen
    > > Zertifikat, welchem ich vertrauen muss (z.B. durch GPO).
    >
    > Das ist technisch absolut nicht realisierbar. Um die Serverantwort auf die
    > exakt selbe Weise wieder verschlüsseln zu können, wie die Firewall sie
    > entschlüsselt hat, bräuchte die Firewall den PRIVATEN Schlüssel JEDES
    > Servers mit dem sie kommuniziert. Das würde das gesamte Konzept des
    > Public/Private Key Verfahrens ad absurdum führen und nicht nur die
    > Verschlüsselung, sondern vor allem die Vertraulichkeit unterminieren.
    >
    > Alles nicht so einfach.

    Doch ist es. Der Vorgang ist wie aktuell auch. Die Firewall baut die Verbindung weiterhin selbstständig auf und der Client weiterhin zur Firewall. Aber wenn es eine Spezifikation gibt, könnte nun in der Verbindung zwischen Client und Firewall der Client informiert werden das es sich um ein SSL Interception handelt. Dann würde der Browser das Zertifikat >zur Firewall< als Trusted markieren, egal was im Commonname steht (wenn es ein TrustedCert im Browser ist). Dann baut die Firewall eine Verbindung zum Server auf. Das resultierende Zertifikat kann dann an den Client geschickt werden, welcher dann selber entscheidet ob er fortfährt oder nicht.

    Also wie gesagt, gehen würde es, wenn man es vorsieht/spezifiziert. Man muss es nur wollen und das ist das eigentliche Problem, weil man es immer als böse bezeichnet.

  15. Re: man in the middle angriffe

    Autor: sneaker 16.02.18 - 22:22

    theq86 schrieb:
    --------------------------------------------------------------------------------
    > Im Übrigen ist es völlig falsch anzunehmen, dass in Firmen, wenn der HTTPS
    > Traffic abgehört wird, die Verschlüsselung irgendwie gebrochen wird. Keine
    > Firma fährt Angriffe auf HTTPS und entschlüsselt den Verkehr durch
    > "knacken" oder "hacken"
    >
    > Vielmehr wird bei einer angefragten HTTPS-Verbindung vom Client diese an
    > der Firewall "gehalten" und die Firewall mimt den angefragten Request
    > selbst. Zwischen Browser und angefragter sicherer Seite wird nie eine
    > Verbindung zustandekommen. Diese kommt zwischen Firewall und angefragter
    > Seite zustande, wobei TLS ganz normal und auf sicherem Weg genutzt wird.
    > Die Firewall nimmt nun die Response und schickt sie per HTTPS mit ihrem
    > eigenen Zertifikat zurück an den Browser. Die Firewall führt also den
    > angefragten Request stellvertretend aus.
    Nein, was bei TLS 1.3 gefordert wurde war kein Man-In-The-Middle. MITM geht auch mit TLS 1.3 wie bisher: eigenes Zertifikat auf dem Client installieren und dann die TLS-Verbindungen an der Firewall/dem Proxy "aufdröseln".

    Es geht darum, daß bei TLS 1.3 nur noch epheremal Keys eingesetzt werden sollten. Bisher haben Banken nämlich interne Kommunikation an bestimmten Punkten gespeichert und dann - unter Kenntnis der RSA-Keys der eigenen Server - sehr wohl entschlüsseln können ("out-of-band TLS decryption"). Das wird mit TLS 1.3 so nicht mehr möglich sein, weil man dann die Clients manipulieren muß:
    a) dort Monitoring-Software installieren, die jedweden Verkehr aufzeichnet
    b) dort Monitoring-Software installieren, die zumindest die epheremal Keys aufzeichnet
    c) eigene Zertifikate auf die Clients spielen und eine MitM-Lösung im Netz installieren
    Und genau diese aufwendigen Lösungen wollen die sich sparen. U.a. auch deshalb, weil man dann den PC des Mitarbeiters, den man überwachen will, manipulieren müßte. Dann läuft man Gefahr, daß dieser die Überwachungssoftware stilllegt oder mit falschen Daten füttert.

    [www.ietf.org]

    Die wollten also, daß TLS 1.3 auch weiterhin Verbindungen ohne perfect forward secrecy anbietet.



    1 mal bearbeitet, zuletzt am 16.02.18 22:23 durch sneaker.

  16. Re: man in the middle angriffe

    Autor: robbyflobby 16.02.18 - 22:27

    ldlx schrieb:
    --------------------------------------------------------------------------------
    > und wer sagt dir, dass das nicht genau so gemacht wird? technisch geht es
    > und einblick in die infrastruktur jedes unternehmens/jeder bank dürftest du
    > wohl auch nicht haben (ich übrigens auch nicht).


    Dein Beitrag liest sich so als würden alle Unternehmen am Loadbalancer oder Reverse-Proxy terminieren...

  17. Re: man in the middle angriffe

    Autor: Anonymer Nutzer 16.02.18 - 22:30

    man muss dazu sagen, dass diese methode einfach nur falsch ist und die methode mit den selbst gebauten root zertifikaten die eindeutig richtige und vollkommen gleichwertige ist. die banken wollten einfach nicht in neue hardware und software investieren und haben sich vor der änderung der it-landschaft gescheut. in meinen augen also nicht unbedingt ein so extrem verteufelswerter grund wie absichtliches man in the middle aber immerhin geiz und faulheit.

  1. Thema

Neues Thema Ansicht wechseln


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. BARMER, Wuppertal
  2. CipSoft GmbH, Regensburg
  3. Stabilus GmbH, Koblenz, Langenfeld, Aichwald
  4. Allianz Deutschland AG, München Unterföhring

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (Hardware, PC-Zubehör und mehr für kurze Zeit reduziert)
  2. 36,48€ (Vergleichspreis ca. 56€)
  3. (u. a. Planet Zoo - Deluxe Edition für 19,99€, Hitman 3 - Epic Games Store Key für 39,99€ und...
  4. 54,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de