Lufthansa entdeckt E-Mail für ihre Mitarbeiter - zunächst für die Passage-Mitarbeiter

[Travelling_Geek]

ANZEIGE

Nein, das schrieb ich in Bezug auf deine Aussage, dass selbst bei intakter Trust Chain Angriffe durch Proxies möglich sind. Das ist einfach falsch. Wenn du dem Zertifikat, das der Proxy dir unterscheibt, vertraust, ist die Trust Chain per Definition intakt. Wenn nicht, dann kriegst du eine Warnung. Ganz einfach.

Hmmm... Du bestätigst mich schon wieder
Client vertraut Proxy, Server vertraut Proxy = intakte Chain of Trust

Dass der Proxy aus Sicht des Servers in der Kette nix verloren hat, mag aus Sicht des Serverbetreibers, des Clients und der Väter von SSL bedauerlich sein. Es ändert aber nichts an der Tatsache, dass eine SSL-Verbindung decodiert wird. Und zwar per Mitm und ohne Fehlermeldung.
Womit wir wieder am Anfang meiner (und Deiner) Ausführungen wären

 

[Wombert]

Hmmm... Du bestätigst mich schon wieder
Client vertraut Proxy, Server vertraut Proxy = intakte Chain of Trust

Dass der Proxy aus Sicht des Servers in der Kette nix verloren hat, mag aus Sicht des Serverbetreibers, des Clients und der Väter von SSL bedauerlich sein. Es ändert aber nichts an der Tatsache, dass eine SSL-Verbindung decodiert wird. Und zwar per Mitm und ohne Fehlermeldung.
Womit wir wieder am Anfang meiner (und Deiner) Ausführungen wären

Wenn Mittelsmänner im Besitz der Schlüssel sind, lässt sich *jede* Verschlüsselung "knacken", das ist doch logisch.

 

[Wombert]

Die Wahrscheinlichkeit das die beiden grossen CAs wissentlich eine Lücke eingebaut haben ist nicht gerade gering.

Lücke *in* einer CA? Häää?

 

[Travelling_Geek]

Lücke *in* einer CA? Häää?

Danke...

Ich mag nicht mehr mit anwe diskutieren, da mir seine Behauptungen zu wirr sind.
Aber vielleicht kannst Du mir erklären, was Open Source mit (bösartig?) modifizierten Wurzelzertifikaten zu tun hat?

 

[dipoli]

Das hättest Du auch schon unter den OP von rcs schreiben können

na ja...

 

[linuxguru]

Hmmm... Du bestätigst mich schon wieder
Client vertraut Proxy, Server vertraut Proxy = intakte Chain of Trust

Dass der Proxy aus Sicht des Servers in der Kette nix verloren hat, mag aus Sicht des Serverbetreibers, des Clients und der Väter von SSL bedauerlich sein. Es ändert aber nichts an der Tatsache, dass eine SSL-Verbindung decodiert wird. Und zwar per Mitm und ohne Fehlermeldung.
Womit wir wieder am Anfang meiner (und Deiner) Ausführungen wären

Du kannst es auch noch zehn Mal schreiben und es wird nicht besser.
Wenn ich zu blöd bin, ein System zu benutzen (also alles und jedem vertraue), ist das Design des Systems doch nicht per se schuld und das System schlecht.
Wenn ich die entsprechenden Root-CAs besitze, kann ich nahezu alles als man-in-the-middle machen.
Wenn ich als Client absolute Sicherheit will, muss ich dafür auch etwas investieren.
Dann gehe ich nämlich hin und vergleiche die Fingerprint, die ich vorher trusted bekommen und verwahrt habe.

BTT:
Ich glaube nicht, dass der "hinterletzte" Mitarbeiter zwangsläufig unter dem Aspekt des Kundenservice (eine eigene) eMail benötigt.
Andererseits ist es sicherlich für die unternehmensinterne Kommunikation sehr förderlich, andererseits geht auch Zeit drauf, die ggfs. anderweitig besser eingesetzt werden kann.
Und ja: Es ist eine Schande, dass so eine Meldung durch die Presse geht. Imagefördernd ist dies ganz sicher nicht.

 

[Travelling_Geek]

Habe ich irgendwo geschrieben das SSL nicht per Proxy oder mitm ausgehebelt werden kann?

Du hast mich gefragt:

Wie kommst Du auf die Idee das SSL entschlüsselt werden kann?

Dem entnahm ich, dass Du noch nie von SSL Proxies gehört hast (und nimms mir nicht übel: ich glaube immer noch, dass Du zuerst durch diesen Thread davon erfahren hast)

Aber schön das Du zu theoretischen Möglichkeiten etwas gesagt hast. Wenn ich vor deinem Rechner sitze kann ich deine Daten löschen.

Was ist an einem Weg theoretisch, der in vielen tausend Unternehmen weltweit Realität ist?
Palo Alto Networks (PAN) hat mehrere tausend von diesen Büchsen verkauft, Sourcefire etliche weniger. Checkpoint dürfte noch mehr vertickt haben als PAN.
Alles Theorie? Die Maschinen stehen eingepackt im Keller?

Mit dem Codec hat es wenig zu tun sonder mit der Transportverschlüsselung.

Den Codec hast Du selbst erwähnt...

Dein Beispiel des Bundes/Bayern oder sonstigem Trojaners ist nett, geht aber an der Fragestellung vorbei.

Nein, das geht es meiner Ansicht nach nicht. Warum mit großem Aufwand einen Trojaner entwickeln lassen, wenn es doch die Backdoor von Skype gibt? Als Ablenkungsmanöver?

Aber immerhin schön das Du mir zustimmst das ein SSL VPN ohne DPI nicht zu blocken ist.
Darum ging es und um nichts anderes.

Dafür, dass es nur darum ging, hast Du aber noch vergleichsweise viele anderen "Fakten" in Deinem Posting untergebracht.
Die leider dafür sorgten, dass dieser eine (korrekte) Satz untergeht.

Deine theoretischen Betrachtungen kannst Du also für Dich behalten, sie sind im normalem Einsatzfall ohne Wert.

Ich fürchte, ich habe mehr Praxiserfahrung als Du. Was angesichts unserer Jobs wirklich bedenklich wäre.

 

[Travelling_Geek]

Wenn ich zu blöd bin, ein System zu benutzen (also alles und jedem vertraue), ist das Design des Systems doch nicht per se schuld und das System schlecht.

Ich habe auch nie behauptet, dass SSL schlecht und das System schuld ist.
Ich warne nur schlicht davor, einer Verschlüsselungstechnik blindlings zu vertrauen.
Es sei denn, sie warnt von sich aus vor Modifikationen (wie beispielweise Zfone, das sich leider nie durchgesetzt hat).

Dann gehe ich nämlich hin und vergleiche die Fingerprint, die ich vorher trusted bekommen und verwahrt habe.

Ganz im Ernst: Gibt es ein für Endkunden (nicht zwingend private Endkunden) gemachtes Produkt (VPN-Client, Browser-Add-on etc), das den Vergleich automatisch erledigt?

 

[Wombert]

Ganz im Ernst: Gibt es ein für Endkunden (nicht zwingend private Endkunden) gemachtes Produkt (VPN-Client, Browser-Add-on etc), das den Vergleich automatisch erledigt?

AFAIK gibts da ein Firefox-Plugin, was sich zumindest CAs und weitere Details von einmal akzeptierten Zertifikaten merkt (aber z.B. nicht Ausstellungs- und Ablaufdatum). Wenn sich die dann ändern, schlägt es Alarm. Sowas ist sehr nützlich in Ländern wie China, wo der Staat die Kontrolle über CAs hat, die in den meisten Betriebssystemen und Browsern Rootzertifikate hinterlegt haben (z.B. CNNIC Root, SHA1 8B AF 4C 9B 1D F0 2A 92 F7 DA 12 8E B9 1B AC F4 98 60 4B 6F, dürfte auch bei dir installiert sein). Wenn man dann auf https://www.facebook.com/ surft, und das Zertifikat ist auf einmal von CNNIC signiert und nicht mehr von entrust.net, weiss man, was los ist...

 

[linuxguru]

Ich habe auch nie behauptet, dass SSL schlecht und das System schuld ist.
Ich warne nur schlicht davor, einer Verschlüsselungstechnik blindlings zu vertrauen.
Es sei denn, sie warnt von sich aus vor Modifikationen (wie beispielweise Zfone, das sich leider nie durchgesetzt hat).

Das hörte sich aber in Deinen bisherigen Posts - für mich zumindest - stets anders an.

Ganz im Ernst: Gibt es ein für Endkunden (nicht zwingend private Endkunden) gemachtes Produkt (VPN-Client, Browser-Add-on etc), das den Vergleich automatisch erledigt?

AFAIK ja. Ich könnte Dir jetzt aber aus dem Gedächtnis keinen Produktnamen nennen.

 

[anwe]

Lücke *in* einer CA? Häää?

Lücke in einer CA heisst in diesem Falle:
Die Dienste die es wollen haben den privat key.

Und dann schaue man mal wo diese Dienste und die Anbieter sitzen, die Gerichtsbeschlüsse bzgl. Wikileaks gegen twitter, das Beispiel skype, das nicht augegriffen wurde etc.

 

[anwe]

>Zitat Zitat von anwe Beitrag anzeigen
>Habe ich irgendwo geschrieben das SSL nicht per Proxy oder mitm ausgehebelt werden kann?
>Du hast mich gefragt:
>Zitat Zitat von anwe Beitrag anzeigen
>Wie kommst Du auf die Idee das SSL entschlüsselt werden kann?
>Dem entnahm ich, dass Du noch nie von SSL Proxies gehört hast (und nimms mir nicht übel: ich glaube immer noch, dass Du zuerst durch diesen Thread davon erfahren hast)


Wie schonmal gesagt,warum sollte ich es Dir übel nehmen. Ich kann für dich oder deine Firma gerne eine Sicherheitsanalyse und Verbesserungsvorschläge erarbeiten, was aber nichts daran ändert das wir hier aneinander vorbei reden.

Ein SSL Proxy erfordert entweder den privat key des target hosts, oder auf dem Client muss der key des Proxy eingetragen sein.
Beides bricht das Vertrauensverhältniss und ist nur mit aktiven Eingriff (und im ersten Fall mit einer Schwachstelle des Targets) eines Admins (der den Proxy und/oder den Client betreut) möglich.
Unter diesen Vorraussezungen ist jede TLS (transport layer security) zu brechen. Im Anwendungsfall, bei einem sicherem Client (Windows - User nur mit User Rechten, Linux generell), leider nicht möglich.
Wenn Du mir ein Angriffsszenario zeigen kannst bei dem das so ist: Ich bin gespannt.

Sollte dem nicht so sein, also Admin der sich aktiv einschaltet, Schwachstellen im Client OS usw:
Dann kann man auch keysniffer und "Bundestrojaner" installieren.


>Zitat Zitat von anwe Beitrag anzeigen
>Aber schön das Du zu theoretischen Möglichkeiten etwas gesagt hast. Wenn ich vor deinem Rechner sitze kann ich deine Daten löschen.
>Was ist an einem Weg theoretisch, der in vielen tausend Unternehmen weltweit Realität ist?
>Palo Alto Networks (PAN) hat mehrere tausend von diesen Büchsen verkauft, Sourcefire etliche weniger. Checkpoint dürfte noch mehr vertickt haben als PAN.
>Alles Theorie? Die Maschinen stehen eingepackt im Keller?

Ich warte auf den Beweis, praktisch oder theoretisch, das diese Machinen ohne die o.g. Massnahmen

nochmal
- bekannter privat key des targets
- Modifikation des Clients

funktionieren.

Das behauptest Du und dem ist nicht so.

>Zitat Zitat von anwe Beitrag anzeigen
>Mit dem Codec hat es wenig zu tun sonder mit der Transportverschlüsselung.
>Den Codec hast Du selbst erwähnt...

>Zitat Zitat von anwe Beitrag anzeigen
>Dein Beispiel des Bundes/Bayern oder sonstigem Trojaners ist nett, geht aber an der Fragestellung vorbei.
>Nein, das geht es meiner Ansicht nach nicht. Warum mit großem Aufwand einen Trojaner entwickeln lassen, wenn es doch die Backdoor von Skype gibt? Als Ablenkungsmanöver?


Wie ich schon geschrieben hatte.
Das Sykpe eine Backdoor hat ist relativ sicher. Genauso wie Blackberrs in diversen Staaten ihre Sicherheit aufgegeben haben um im Geschäft zu bleiben.
Heisst das das jedes LKA oder auch das BKA darauf Zugriff hat?
Wohl eher nicht.



>Zitat Zitat von anwe Beitrag anzeigen
>Aber immerhin schön das Du mir zustimmst das ein SSL VPN ohne DPI nicht zu blocken ist.
>Darum ging es und um nichts anderes.
>Dafür, dass es nur darum ging, hast Du aber noch vergleichsweise viele anderen "Fakten" in Deinem Posting untergebracht.
>Die leider dafür sorgten, dass dieser eine (korrekte) Satz untergeht.

Du hast mit der theoretischen Sicherheit von SSL angefangen.
Ich habe nur geantwortet und deine Aussagen als möglich, in der Praxis (ausserhalb geschlosserner Systeme, wie z.B. grossen Firmen, wo der Admin mal eben auf dem Clientrechner machen kann was er will) als undurchführbar dargestellt.


>Zitat Zitat von anwe Beitrag anzeigen
>Deine theoretischen Betrachtungen kannst Du also für Dich behalten, sie sind im normalem Einsatzfall ohne Wert.
> Ich fürchte, ich habe mehr Praxiserfahrung als Du. Was angesichts unserer Jobs wirklich bedenklich wäre.

Und ich fürchte Du vermischt "Wissen- was ist theoretisch machbar" mit der Realität.

Aber ich kann Dich beruhigen. Sowohl mir und meinen Kunden geht es gut

Aber gerne können wir das aktuelle Szenario ausprobieren, wie Du willst mit VPN oder SSL.
Ich setze einen Server auf, mit selbst signiertem Cert, Verification per Cert, komme zu Dir nach Hause, in die Firma oder wohin auch immer * und dann zeigst Du mir deine Erkenntnisse ...
Mit meinem Laptop in deinem Netz, Zugriff auf meinen Server

* in D wenn ich in der Gegend bin, ausserhalb wenn Du die Anreise zahlst. Überzeugst Du mich bekommst Du die Kosten zurück

 

[anwe]

Ganz im Ernst: Gibt es ein für Endkunden (nicht zwingend private Endkunden) gemachtes Produkt (VPN-Client, Browser-Add-on etc), das den Vergleich automatisch erledigt?

Nur am Beispiel von openvpn, um das es hier zuerst ging.

Der Keyexchange beruht auf einem Server und einem Client Key.
Entweder die passen, oder sie passen nicht.

Ist einer der Keys kopiert (sprich ein Proxy hat den privat key des Servers, als Beispiel) ist eh Alles vorbei.

 

[Travelling_Geek]

Nur am Beispiel von openvpn, um das es hier zuerst ging.

Der Keyexchange beruht auf einem Server und einem Client Key.
Entweder die passen, oder sie passen nicht.

Das, was Du da zu erklären versuchst, ist PKI.

Zumindest glaube ich, dass Du PKI meinst. Denn OpenVPN funktioniert u.a. mit einer PKI und hat mit Zertifikaten zu tun. Es gibt in einer PKI aber keinen "Server Key" und auch keinen "Client Key", sondern Paare aus privaten und öffentlichen Schlüssel.

Darum ging es bei der Aussage von linuxguru (und meiner Nachfrage) aber nicht.
Vielmehr ging es darum, dass die gepeicherten Hashwerte eines Zertifikats automatisch mit dem Hash des gerade ausgelieferten Zertifikats abgeglichen werden. Außerdem soll geprüft werden, ob sich die Daten einer der beteiligten CAs geändert haben (z.B. das Land).
Nachdem die von Dir beschriebene OpenVPN-Konfiguration ohne Wurzelzertifikat einer externen CA auskommt, ist ein solcher Check hinfällig.

 

[Travelling_Geek]

Lücke in einer CA heisst in diesem Falle:
Die Dienste die es wollen haben den privat key.

Und wie genau hilft Open Source in einem solchen Fall weiter?

 

[Travelling_Geek]

Ich warte auf den Beweis, praktisch oder theoretisch, das diese Machinen ohne die o.g. Massnahmen

nochmal
- bekannter privat key des targets
- Modifikation des Clients

funktionieren.

Das behauptest Du und dem ist nicht so.

Das habe ich nie behauptet. Ich habe auch nie behauptet, dass diese Maschinen ohne Modifikation des Clients (meint: hinzufügen eines Zertifikats) auskommen.

Vielmehr schrieb ich schon vor ein paar Tagen:

Das Konzept im Groben: Der Proxy terminiert die SSL-Session vom Client und schickt diesem sein eigenes Zertifikat. Zwischen Proxy und (Web)Server werden dann die vom (Web)Server verteilten Zertifikate genutzt.
Eines (von diversen) kommerziellen Produkten, dass SSL-MitM beherrscht, ist die PA-4050 von Palo Alto Networks.

Genauso wie Blackberrs in diversen Staaten ihre Sicherheit aufgegeben haben um im Geschäft zu bleiben.

Du bist doch ein erklärter Freund von End-to-End-Encryption. Wie kann RIM die Sicherheit aufgeben, wenn nur der Betreiber des BES den Schlüssel hat?

 

[economyflieger]

Um was gehts??

 

[Travelling_Geek]

Um was gehts??

Weiß ich auch nicht mehr

 

[peter42]

Als Nutzer schätze ich Exchange sehr.

Das ist das nicht die TCO-Sicht!

 

[peter42]

Ahha ....

Mal einfacher ausgedrückt an einem Beispiel:

Skype nutzt im Gegensatz zu MSN, ICQ etc keinen eigenen Port sondern Port 443 (SSL) oder 80 (http).
Schonmal Probleme mit Skype gehabt?

Genau den gleichen Effekt erreicht man mit einem SSL VPN auf SSL Port. Für eine Firewall ist der Traffic erstmal SSL Traffic, die Firewall kann nicht (ohne weiteres) unterscheiden ob es ein User ist der auf eine https Seite geht oder eben ein SSL VPN ist.
Dazu wäre Deep Packet Inspection – Wikipedia nötig, was (bis jetzt) eher wenig verbreitet ist.

Ein Beispiel ist swissvpn.net, als einer der grössten kommerziellen VPN Anbieter.
Die haben vor einiger Zeit openvpn mit ins Angebot genommen, Zitat "OpenVPN (falls PPTP bei Ihnen nicht funktioniert):"

Das eine Firewall nach einiger Zeit Traffic blockt ist technisch möglich, mir fällt aber nicht eine einzige ein die das tut.
Hast Du mal Hersteller/Modell, würde mich wirklich interessieren.
Viel grösser ist die Chance das bekannte VPN IP's, wie z.B. swissvpn, geblockt werden.

Im Enterpriseumfeld weredn Produkte wie Bluecoat, Webwasher oder Tommy eingesetzt, da ist es kein Problem das zu unterscheiden.

 

[peter42]

Im Intel-Umfeld mit Sicherheit (HP hatte ja das Glück, Compaq kaufen zu dürfen - die waren eigentlich diejenigen mit der besten Hardware). Was willst Du denn sonst kaufen? FSC? Dell? IBM? Gibt es sonst noch Anbieter, die einen weltweiten Support bieten? Im Unix-Umfeld teilen sich den Kuchen mehr oder weniger IBM und Solaris.

Open Source ist meistens ganz nett - aber meistens funktioniert diese nur ganz toll in kleinen Umgebungen und nicht für Userzahlen > 100k.
Und nicht für jeden Schnickschnack taugt OpenSource. Ich stelle mir gerade ERP als OpenSource vor....lach....einfach undenkbar.
Aber egal....ist hier ein Fliegerforum. Somit EOD für mich.


Ah ja, Du redest also von Stalkern oder Mördern. Terroristen haben es doch nicht auf einzelne abgesehen. So elitär dürfen die Opfer dann auch nicht sein. Das Gefährdungspotential, wenn "fremde Augen" LH-Mails (des Bodenpersonals) lesen, tendiert mE gegen Null. Unternehmenskritische Daten werden wohl kaum über OWA verschickt. Eher noch über Blackberry. Oder verschlüsselt.
Oder als Powerpoint (was laut Larry E. auch ausreichend verschlüsselt ist)

Also >100k User kann ich nicht dienen, aber in 30k Umgebungen lief es für viele Dienste recht gut.

 

[peter42]

Wenn du eine PA-4050 einsetzt, und HTTPS proxyen willst, dann müssen alle Clients im Netzwerk das selbstgebaute Root-Zertifikat geladen und als vertrauenswürdig markiert haben, mit dem die Firewall die Verbindungen wiederum verschlüsselt. Das geht natürlich. Ich hab schon von Firmen gehört, wo das "aus Sicherheitsgründen" gemacht werden muss (sprich: der Arbeitgeber möchte verschlüsselten Datenverkehr mitlesen).

Kenne wenige größere Firmen, die keinen SSL-Proxy haben!

 

[peter42]

Aber immerhin schön das Du mir zustimmst das ein SSL VPN ohne DPI nicht zu blocken ist.
Darum ging es und um nichts anderes.

AFAIR gibt es auch Produkte die es probieren anhand der Trafficsizepattern zu erkennen - und nein ich weiss nicht wie gut das fkt..

 

[Bergmann]

Es ist ja schon interessant, was man hier alles im Vielfliegerforum lernt. Was ich aber noch nicht verstanden habe: Sind die internen LH-Mailadressen nun Mist oder toll? *smile*

 

[flysurfer]

ANZEIGE

Es ist ja schon interessant, was man hier alles im Vielfliegerforum lernt.

Schlägt das Thema dort denn auch so hohe Wellen?