Problem m. Freemail-GMX-Verschlüsselung

  • Zitat von Fury


    Findet denn bei GMX die Datenübertragung zwischen Mail-Client und Postfach verschlüsselt statt?


    Ja, absolut!
    Wenn beispielsweise Thunderbird zum Einsatz kommt, erfolgt sowohl der Mailabruf als auch der Versand per SSL/TLS.

    Mailabfrage = POP-Mailserver; Port 995
    Mailversand = SMTP-Server; Port 465

    oder per IMAP > Port 993/TCP (IMAPS)

    Viele Grüsse von hall77
    Betriebssystem: Linux Mint 64-bit, Desktop Mate

  • Fury fragte Folgendes:

    Zitat

    Findet denn bei GMX die Datenübertragung zwischen Mail-Client und Postfach verschlüsselt statt?


    Normalerweise wird die Übertragung vertraulicher Nachrichten durch das zugrundeliegende Mail-Protokoll (SMTP) ungeschützt übertragen. SMTP gilt somit als ungesichertes Übertragungsmedium.

    SMTP (also das „Simple Mail Transfer Protokoll“), welches zwischen einem elektronischen Mailserver und einem lokalen Client (z.B. Thunderbird) zur Anwendung kommt stellt sich - wie der Name bereits suggeriert – als „simple“ (also als unverschlüsselt) dar, sofern die Kommunikation nicht über gesicherte Sockets geführt wird.

    Das SMTP-Übertragungsprotokoll untersteht bezüglich einfacher ASCII-Textübertragungen dem MIME (Multipurpose Internet Mail Extensions) und überträgt vertrauliche Nachrichten unverschlüsselt und schützt obendrein auch nicht vor einer unautorisierten Nachrichtenmodifikation – bzw. vor Maskierungsangriffen.

    Eine Möglichkeit der vertraulichen (verschlüsselten) und obendrein der verbindlichen (nicht widerlegbaren Zuordnung von Informationen zu einer Person / Datenquelle) geführten Mail-Kommunikation könnte - meinen bisherigen Informationen nach – nur durchgeführt werden wie folgt:


    a. Lokale Verschlüsselung des vertraulichen Nachrichtentextes vor dem Versand durch wie auch immer geartete öffentliche Übertragungs-Standards. Es findet im Zuge so eines lokalen Verschlüsselungsverfahrens jedoch keine Einwirkung auf die Metadaten der zu übertragenen IP-Pakete selber statt. Die Verbindlichkeit ist somit nicht gesichert, wohl aber die vertrauliche Informationsübertragung der Nachrichtenkörper. (Des Textes).

    b. Einbindung von diversen Add-Ons für Mail-Clients (z.B. Enigmail for Thunderbird etc.)[/b] welche i.d.R. jedoch auf der Sicherheit allg. verfügbarer GNU-Projekte (also öffentlich zugänglicher Verschlüsselungsstandards) selber aufsetzen müssen. Die Metadaten der einzelnen Übertragungspakete werden jedoch auch hier nicht verschlüsselt, bzw. nicht verfälscht, sofern die Kommunikation nicht über einen separaten Proxy geführt wird.

    c. Einsatz von PEM „Private Enhanced Mail“ - eines als Signatur geprüften - jedoch unflexiblen Maildienstes, der jedoch die Verbindlichkeit einzelner Teilnehmer (durch dedizierte Header-Informationen) bereitzustellen vermag, dabei jedoch nicht als anonymer Übertragungsdienst geeignet ist.


    Eine dezentral geführte Nachrichten-Kommunikation kann vor ihrem jeweiligen Hintergrund sowohl einer „Verbindlichkeit“ – bzw. auch der Notwendigkeit einer „Unverbindlichkeit“ unterliegen müssen. ;)


    Cheers to a new Year to all of you!


    Oliver


    http://de.wikipedia.org/wiki/IP-Paket#….28IP-Header.29
    http://www.itwissen.info/definition/lex…d-mail-PEM.html

  • Zitat von Oliver222


    Normalerweise wird die Übertragung vertraulicher Nachrichten durch das zugrundeliegende Mail-Protokoll (SMTP) ungeschützt übertragen. SMTP gilt somit als ungesichertes Übertragungsmedium.


    Wenn man SMTP per SSL/TLS über Port 465 fährt, meines Wissens einer gesicherten Verbindung, dann müsste das doch ok sein - oder hat sich zwischenzeitlich etwas geändert?

    Hey, krass der Winter in Europa! Wünsche Dir sowie allen hier im Forum einen guten Rutsch nach 2011!!
    Mögen alle Eure Wünsche in Erfüllung gehen!!

    Viele Grüsse von hall77
    Betriebssystem: Linux Mint 64-bit, Desktop Mate

  • hal77 erklärte Folgendes:

    Zitat

    Wenn man SMTP per SSL/TLS über Port 465 fährt, meines Wissens einer gesicherten Verbindung, dann müsste das doch ok sein - oder hat sich zwischenzeitlich etwas geändert?


    Du hast Recht – Jedoch hat sich bezüglich der Thematik bisher scheinbar nicht viel verändert.

    Der von Dir genannte gesicherte Port: 465 unterscheidet sich – meinen bisherigen Erkenntnissen nach - nur dadurch vom allgemein zugänglichen Mail-Port: 25 - als dass die vertraulichen Mail-Verbindungen (via Port 465) über einen gesicherten Tunnel (SSL) geführt werden.

    Diese vertraulichen Verbindungen können jedoch auch ohne Username/Passwort verwendet werden, sofern der Partner kein SMTP AUTH-Verfahren unterstützt - bzw. so ein reduziertes Authentifikationsverfahren explizit durch unterschiedliche (nationale / internationale Standards) eingefordert werden muss.

    SSL schützt von daher bloss die Kommunikationswege – nicht jedoch die Kommunikationspartner.

    Happy New Year to You in Mexico City - 7 hours after UK / UTC.

    O.T.
    Wie schön, dass sich die Erde mit nahezu 1100 Meilen pro Stunde (1770 km/h) dreht – denn sollte sie plötzlich stillstehen, flögen wir vermutlich alle mit Überschallgeschwindigkeit gegen die Wand. ;)


    Oliver

  • Brummelchen stellte u.A. Folgendes:dar.

    Zitat

    [...]SSL wird nur für die Anmeldung benutzt, danach nicht mehr, weil fehlendes HTTPS.[...]


    Wie kommst Du darauf?

    Das SSL-Protokoll beinhaltet zumindest eine verschlüsselte streckengeführte Absicherung zweier Kommunikations-Partner (Endpunkte), die durch diverse Verschlüsselungsverfahren einerseits zwar „gesichert“ übertragen wird, andererseits jedoch an den jeweilig aufgebauten Kommunikationsendpunkten wiederum enden muss.

    Die Integrität (also die Vertrauenswürdigkeit) der einzelnen Kommunikations-Partner kann somit durch das SSL-Verfahren alleine nicht überprüft werden.

    Platt ausgedrückt, könnte ja z.B. die Mail-Adresse eines Deiner vertrauenswürdigen Geschäftspartner im Vorfeld bereits kompromittiert worden sein - ohne das Ihr beide Euch dessen bewusst seit. Jemand könnte sich absichtlich zwischen Eure Kommunikation schieben und diese obendrein abfangen (engl. to intercept). Die kompromittierte Kommunikation würde dann zwar weiterhin über das SSL-Protokoll verschlüsselt verlaufen – jedoch könntest Du Dir nicht sicher sein, es mit dem originalen „Gesprächspartner“ selber zu tun zu haben.


    Oliver