Haben VPN-Anbieter zugriff auf SSL Inhalte?

[S3veny]

Guten Mittag,

Es gibt ja Firmen die einen VPN-Zugang anbieten.
Was ist das ist und wofür usw lässt sich hier z.B nachlesen:
https://www.steganos.com/de/steganos-online-shield-vpn

Meine Frage allerdings betrifft jetzt nur eine technische Sache kurz.
Theoretisch könnte der Dienstleister ja den kompletten Datenverkehr mitlesen/speichern usw.
Aber wie ist das bei verschlüsselten Verbindungen (SSL/TLS), dort auch?
Also können dort auch Inhalte mitgelesen werden die über https laufen?
Oder kommt es noch auf die Verbindungsart drauf an ?
(Wäre dann OpenVPN und IKEv2)

Bitte drum auch nur die wirklich zu antworten die es tatsächlich wissen, sich damit auskennen usw.
Vielen Dank im vorraus!

 

[Sun_set_1]

Man in the Middle

Unter Gegenmaßnahmen und Poodle

 

[cs_reaper]

Das dürfte nicht so ohne weiteres möglich sein..........der VPN Tunnel ist verschlüsselt, den kann der Anbieter sicher entschlüsseln..........aber eine verschlüsselte Verbindung die über den verschlüsselten Tunnel läuft. Das ist wohl recht schwierig.

LG

 

[Fr4g3r]

Wie cs_reaper schon gesagt hat handelt es sich bei einer sauberen SSL-Verbindung um eine Ende-zu-Ende-Verschlüsselung.
Rufst du die HTTPS-Seite von Amazon auf, dann wird mit dieser Seite eine verschlüsselte Verbindung hergestellt.
Der Weg den der Traffic zum Amazon-Server nimmt ist dabei dann erstmal zweitrangig.

Dein VPN-Anbieter sieht in dem genannten Fall dann einfach den verschlüsselten Traffic und könnte genauso wie jeder andere versuchen den zu knacken.
Es ist aber nicht so das er hier einfach in den HTTPS-Traffic schauen kann.

Wichtig ist eben das die SSL-Verbindung sauber steht und hier dein Traffic nicht über einen Proxy geleitet wird der den Tunnel aufbricht.
Das siehst du aber wenn du auf der Seite bist ob dir dort das Zertifikat der richtigen Seite präsentiert wird oder das eines Proxy-Servers.
Bietet der Webserver Public Key Pinning an, dann sieht man das auch relativ schnell im Browser wenn einem ein anderes Zertifikat präsentiert wird als das welches der Webserver nutzt.

 

[S3veny]

Okay das beruhigt micht schon mal, danke euch.

Also wenn Domainname im Zerfitkat mit den der Seite übereinstimmt und die Verbindung TLS 1.2 verschlüsselt ist, sollte alles stimmen? Manchmal lese ich im dort auch das die Verbindung mit einer veralteten Codier-Suite verschlüsselt sei. Was hat es damit eigentlich auf sich?

Hier ein Beispiel (Comodo Dragon v46):

Spoiler

Unter anderen deswegen werde ich auch den Email-Provider wechseln..

 

[Fr4g3r]

Was ist das für ein Browser den du da benutzt?
Klick mal auf die blaue Schrift "Zertifikatinformation" die dein Screenshot zeigt und poste dann den Screenshot davon.

//edit: Ah ich sehe gerade dass das gmx.com ist, dann kann ich nachher selbst kurz schauen.
Vermute fast das entweder GMX selbst, eine Zwischenzertifizierungsstelle oder die Root-CA SHA1 nutzt.

 

[S3veny]

Browser ist Comodo Dragon v46
Im Zertifikat steht nicht viel.

Über Firefox ist die Ansicht übersichtlicher:

Spoiler

Also mit SHA1 ein Grund zur Sorge?

 

[Fr4g3r]

Also solang nur der Fingerprint SHA1 ist kannst du das ignorieren.
Wichtig sind der Signaturalgorithmus und der Signaturhashalgorithmus.
Das sieht für mich beides nach SHA256 aus.

Was ich auf die schnelle gesehen habe, ist dass die Root-CA (thawte) hierfür SHA1 nutzt.
Das verwundert mich dann doch etwas, wobei ich hier jetzt auch nicht sicher sagen kann ob das der Grund ist warum das bei gmx.com angemeckert wird.
Das Zertifikat für GMX selbst scheint ja wie gesagt sha256 zu nutzen.
Bin mir da aber auch nicht sicher ob es bei dem Browser schon genügt wenn in der Kette jemand SHA1 nutzt.

 

[S3veny]

Denke mal Comodo bezieht sich da auf die unverschlüsselten Inhalte.

Also wenn Zertifikat übereinstimmt und SHA256 nutzt, die Verschlüsselung TLS 1.2 (am besten AES256) verschlüsselt ist, brauch man sich keine Gedanken zu machen?

 

[Sun_set_1]

Ihr sagt also, auch wenn die Verschlüsselung schon über den Tunnel (und Proxy) ausgehandelt wird, ist es sicher? Das ist so nicht ganz richtig.

Solange die Initialisierung und Verbindung über dieselbe Leitung laufen, ist es nicht 100%ig sicher. Das geht nur mit einer 2-Wege-Authentifizierung.

 

[Fr4g3r]

SSL zeichnet sich ja gerade dadurch aus, dass trotz eines unsicheren Transportweges eine sichere Verbindung aufgebaut werden kann.
Kannst du daher bitte deine Gedanken dazu etwas genauer erläutern?

 

[S3veny]

Wüsst ich auch gern, vorallem warum Proxy?

 

[GrandTheft]

Hallo,

das ist zu komplex um es in einem Satz abschließend zu beantworten. In kurz und unter Nichtberücksichtigung technischer Sachverhalte "sieht" der VPN-Provider "wer Du bist" und wo Du Dich hinverbindest, aber nicht den Inhalt.
Der Kommunikationspartner (https - Website) sieht wer Du bist (nur nicht mehr an der IP - sozusagen nicht mehr "von Weitem"), aber nicht welchen Weg Du diesmal genommen hast. (bezogen auf webbrowser)

Die Themen SSL und VPN sind leider sehr komplex wenn man die theoretische Ebene mal verlässt. Man sollte nicht zu sehr darauf vertrauen.

Grüße
gt

 

[S3veny]

Mir ging es ja nur drum ob HTTPS Content mitgelesen werden kann.
Kann es scheinbar nicht bei der richtigen Prävention usw.
Danke an alle!

Natürlich kann man jetzt über das Thema weiter philosophieren, aber mein Abo ist raus.

 

[Sun_set_1]

Hallo,

das ist zu komplex um es in einem Satz abschließend zu beantworten. In kurz und unter Nichtberücksichtigung technischer Sachverhalte "sieht" der VPN-Provider "wer Du bist" und wo Du Dich hinverbindest, aber nicht den Inhalt.
Der Kommunikationspartner (https - Website) sieht wer Du bist (nur nicht mehr an der IP - sozusagen nicht mehr "von Weitem"), aber nicht welchen Weg Du diesmal genommen hast. (bezogen auf webbrowser)

Die Themen SSL und VPN sind leider sehr komplex wenn man die theoretische Ebene mal verlässt. Man sollte nicht zu sehr darauf vertrauen.

Grüße
gt

Richtig, empfehlenswert sind die Beiträge der CCC Auditoren zu den Themen. Vereinfacht gesagt, besteht theoretisch weiterhin die Möglichkeit, dass Zertifikate über einen Man-the-Middle (Proxy) ausgetauscht bzw ausgelesen werden, ohne dass du dies eigentlich bemerkst. Wirklich ganz vereinfacht gesagt (da hierfür natürlich auch weitere Sicherheitsmechanismen ausgehebelt werden müssen) könnte ein VPN Anbieter die Verbindung nicht direkt herstellen.

Wenn du die Banking-Seite aufrufst wird der Befehl dazu an den VPN gesendet. Dieser hat nun einen Proxy stehen, welcher seinerseits wiederum eine Verbindung zur SSL-Seite herstellt. Hier fordert er zwei Zertifikate an. Das erste nutzt der Proxy selbst. Eins um es selbst zu nutzen und das zweite für die eigentliche Verbindung/Kommunikation Client -> SSL Seite. Wie gesagt, natürlich geht das normalerweise nicht - wurde aber bereits als PoC bewiesen. Weiß auch nicht mehr genau wie, aber irgendwie konnte der Public-Token genutzt werden den Private-Key der zweiten Session zu entschlüsseln.

Das zielte wohl auch noch auf SSL / TSL 1.0 / 1.1 ab, theoretisch besteht aber ein Groß des Bugs wohl weiterhin. Jedoch braucht man wohl auch passende Browser-Exploits dazu.

Weiterhin bleib ich bei der Aussage, wenn es der VPN darauf anlegen würde, wäre er selbst die Schwachstelle im SSL/TSL-Verfahren.

Wie man oben sieht (2. Bild), als MITM hast Du immer die Möglichkeit die Error-Routinen zu triggern. Das alleine ist doch im Prinzip schon der Fuß in der Tür.

Eben ganz alleine aufgrund der Tatsache, dass SSL nicht mit Hinsicht auf solche Verbindungen konzipiert wurde, (A über B zu C), es wurde zur sicheren Kommunikation von A zu B entwickelt. Wenn man nun Identifikation/ Kommunikation und Verschlüseelungsinitiation auf 2 Wegen laufen lässt, könnte man die Schwachstelle aushebeln. Da dann, B (bei A->B-C) niemals eine seperate Verschlüsselung, oder komplizierte Netzwerkprotokolle, benötigen würde. Dieser hätte nur noch eine simple Relay-Rolle inne. Und wir wären bei einer wirklichen End-to-End.

http://de.slideshare.net/ThierryZoller/practicaltls1