Authentifizierung am SMTP-Server verschlüsseln

[SynNAS]

Hallo zusammen,

Ich verwende die Mail Station (Version 1.2 -0130 unter DSM 4.2) um von dort aus via SMTP-Relay-Funktion die Mails meiner DSM-User
an den SMTP-Server des Providers weiterzugeben. (via Authentifizierung und sicherer Verbindung [TLS])

Meine DSM-User verwenden z.B. den Thunderbid-Mail-Client, um von Ihren Rechnern
die Mails an die Synology-Mail-Station zu senden.

Dazu müssen Sie sich mit folgenden Einstellungen an den SMTP-Server der Mail-Station wenden:

Serve-IP-Adresse
Port 465
Benutzernahme: Name
Authentifizierungsmethode: Passwort, normal
Verbindungssicherheit: SSL/TLS

Wenn ich nun, die Authentifizierungsmethode im Thunderbird-Client
auf

Authentifizierungsmethode: Passwort, verschlüsselt
Verbindungssicherheit: SSL/TLS

stelle,
kommt beim Versuch eine Mail via SMTP Server des Synology-Mail-Servers abzusetzen:



Heist das,
daß die Passwort-Authentifizierung zwischen dem Mailclient (in dem Fall Thunderbird auf z.B. einem Windows-Rechner)
und dem Synology-Server (Mail-Server) UNVERSCHLÜSSELT läuft?

Die Verbindung, die nach der Authentifizierung aufgebaut wird, und über die dann auch die Mails laufen scheinen dann ja SSL/TLS verschlüsselt abzulaufen, oder?


Wer kennt den genauen Zusammenhang?

Grüße Stefan

 

[jahlives]

Port 465 resp TLS/SSL ist implizites SSL d.h. die Verbindung ist von Anfang an verschlüsselt. Im Gegensatz dazu Port 587 und STARTTLS (explizites SSL) d.h. die Verbindung wird erst verschlüsselt wenn der Client das STARTTLS Kommando schickt. Zudem gibt es noch die Möglichkeit das PW innerhalb der SSL Verbindung zu verschlüsseln. Das ist aber imho doppelt gemoppelt wenn man bereits eine SSL Verbindung hat. Ich würde auf Port 587 und STARTTLS umstellen und die unverschlüsselte Passwortübermittlung wählen. Da die Transportverbindung dann bereits verschlüsselt ist, brauchst du nicht das PW extra zu verschlüsseln. Da müsste der Server zudem auch unterstützen

 

[Peter_Lehmann]

Um die (völlig korrekte!) Antwort noch deutlicher zu machen: Zuerst wird sowohl bei TLS/SSL und auch bei STARTTLS eine verschlüsselte Verbindung aufgebaut, und erst wenn diese steht, erfolgt über diese verschlüsselte Verbindung die Authentisierung mit Benutzername und Passwort.

Eine Auth. mit verschlüsseltem Passwort ist im Internet unüblich. Mir ist bis jetzt ein einziger Provider untergekommen, der dieses Verfahren unterstützt. Im Intranet entsprechend ausgerüsteter Firmen wird eine Auth. mit verschlüsseltem PW dagegen öfters angewendet.

MfG Peter

 

[SynNAS]

Hallo "jahlives", hallo Peter,

Danke für Eure ausführlichen Antworten.

Ich bin mir nicht ganz sicher, ob ich es auch vollständig verstanden habe, deshalb wiederhole ich mal in meinen Worten, was bei mir "angekommen" ist:

1. Es gibt drei Möglichkeiten, eine Verschlüsselte Verbindung zwischen Mail-Client und Mail-Server für SMTP aufzubauen.
A: In dem der Client einen Port anspricht der nur für TLS / SSL Verschlüsselung vorgesehen ist, wird SOFORT eine verschlüsselte Verbindung aufgebaut. Dazu ist der Port 465 gedacht.
B: In dem der Client einen Port anspricht, der normale Verbindung als auch verschlüsselte Verbindung unterstützt, wird erst NACH explizieter Anforderung einer Verschlüsselung
via STARTTLS (was den Befehl "Start TLS" symbolisiert) aufgebaut. Dazu ist der Port 587 gedacht.
=> Zuerst ist die Verbindung unverschlüsselt, nach senden des STARTTLS-Befehls wird die Verbindung verschlüselt.
C: In dem der Client den Port anspricht, der NUR für unverschlüsselte Verbindungen vorgesehen ist, wird auch NUR unverschlüsselt übertragen.

Für mein "Sorge" der unverschlüsselt Übertragung der User-Kennung inklusive Password kommt also nur der Fall B (=Port 587) (unter bestimmten Bedingungen)
als auch der Fall C (Port 25) in Betracht.
Bei Verwendung des Falls A (= Port 465) kommt immer eine sofortige Verschlüsselte Verbindung zustande (oder garkeine!)

In dem "verschlüsselten Tunnel (TLS/SSL)" kann die User-Daten und Password-Übertragung getrost unverschlüsselt erfolgen. (wie laut Peter im Internet auch so üblich ist)

=> Fall A = Port 465 ist somit sicher.
=> Fall B = Port 587 ist normalerweise auch sicher, da der Mail-Client vor der Übertragung der User-und Passwortdaten eine
verschlüsselte Verbindung via STARTTLS anfordert und auch bekommt. (allerdings läßt die RFC 2595 bei STARTTLS auch zu,
daß der Mail-Client bei nichterkennen des STARTTLS Komandos die Login-Daten im Klartext sendet).
Somit ist der Fall B zwar der Fall, der meistens funktioniert, der aber auch ein kleines Risiko der unverschlüsselten Übertragung enthält.
=> Fall C = Port 25 ist somit immer unsicher, da immer unverschlüsselt übertragen wird.


Wenn ich das so nun richtig verstanden habe,
würde ich die bei mir momentan eingestellten Parameter (Port 465) Verbindungssicherheit SSL/TLS, Password unverschlüsselt problemlos beibehalten können.
Bei dieser Einstellung kann es zwar eher mal zu gar keinem Verbindungsaufbau kommen, als bei Benutzung des Ports 587 (und STARTTLS), aber sie ist gefühlt etwas "sicherer".

Ist jetzt Deine Empfehlung, "Jahlives" zu dem Fall B darin zu Verstehen, daß diese Variante den zuverlässigsten Verbindungsaufbau darstellt, der meist (oder eigentlich fast immer) verschlüsselt erfolgt?
===================================================================================================================================================


@ Peter:
Du schreibst, daß Firmen in Ihrem Firmennetz öfters mal auch eine Authenifizierung mit verschlüsseltem Passwort verwenden, obwohl der Mailverkehr innerhalb des Intranet verwendet wird.
Sehen die Firmen die Intranet-Umgebung als gefährdeter als das Internet an, oder machen die das nur, weil eine IT-Abteilung sowiso die dann schwierigere Konfiguration (und Schlüssel-Verwaltung)
betreuen kann?

Grüße Stefan

 

[jahlives]

die meisten SMTP Server akzeptieren STARTTLS auf beiden Ports also 25 und 587.
Die Clients kennen dann Einstellungen, ob die Logindaten überhaupt übermittelt werden dürfen wenn STARTTLS nicht klappt. Das ist aber dann Clientsache darauf hat der Server keinen Einfluss

 

[SynNAS]

Hallo "Jahlives"

OK, dann muss ich in meiner Zusammenfassung die Fälle B und C gleichsetzen.

Damit wird auch klar, warum bei meinem Synology-E-Mail-Server die Einstellung unter

bei meinem Provider nur mit Port 25 funktioniert (wenn ich dort Port 465 eintrage geht es nicht)
obwohl ich direkt drunter die Einstellung: "Immer eine Sichere Verbindung verwenden (TLS) angehakt habe.
Das ist dann wohl die Angabe, STARTTLS auf Port 25 zu verwenden.

Somit ist dann auch hier davon auszugehen, daß die Übertragung sowohl des Users/ Passords als auch die Mails verschlüsselt erfolgt.

Noch kurz drei Fragen:
-1.: Ist meine Zusammenfassung sonst OK?
-2.: War Ihre Empfehlung für Port 587 in Verbindung mit STARTTLS wegen der meistens funktionierenden Verbindungswahscheinlichkeit zu sehen?
-3.: Ist somit die Verwendung des Ports 465 ein sicherers Indiz für eine IMMER stattfindende verschlüsselte Verbindung?

Grüße Stefan

 

[jahlives]

Port 587 empfehle ich weil immer mehr Provider Port 25 ausgehend aus ihren Netzen schlicht blockieren.

 

[Peter_Lehmann]

Hallo Stefan,

Im Prinzip hast du schon alles richtig verstanden.
TLS und SSL sind vom Prinzip her fast das gleiche. TLS ist eine Weiterentwicklung von SSL. Man sagt auch "SSL Version 3". Nutzt du TLS/SSL und den dafür vorgesehenen Port (für alle drei Protokolle natürlich jeweils ein anderer), dann ist das Zusammenspiel so, dass sofort eine verschlüsselte Verbindung aufgebaut wird. Allerdings kannst du nur das Protokoll nutzen, was der Provider auch anbietet. Bei den Posteingangsservern ist es meistens TLS/SSL und beim Postausgangsserver meistens STARTTLS.
(Frage 3 => ja, so ist es)

Frage 2 hat ja jahlives ja schon beantwortet: Du kannst die Ports 25 und 587 prinzipiell beide als SMTP-Ports betrachten. Du kannst auch, wenn es auf einem nicht funktioniert, schnell mal auf den alternativen Port umschalten. Und gerade bei Verbindungen aus dem Ausland zu einem einheimischen SMTP-Server ist das bei Nichterreichbarkeit immer das erste, was man machen sollte. Meistens (aber leider nicht immer!) funktioniert es mit :587. Aber weder der eine noch der andere Port ist ein Indiz für eine verschlüsselte oder eine nicht-verschlüsselte Verbindung!
Es ist einfach nur so, dass STARTTLS immer die Standardports (für die unverschlüsselte Verbindung) der drei genannten Protokolle benutzt. Auch hier spreche ich von der Mehrzahl, denn theoretisch kann ein Provider so konfigurieren, dass auch die Posteingangsserver mit STARTTLS angesprochen werden.
Du kannst davon ausgehen, dass bei einer Konfiguration mit STARTTLS nach wenigen ms und auch vor der Authentisierung die Verbindung verschlüsselt abläuft.
Hier habe ich mal was zum Selberlesen herausgesucht: Transport Layer Security – Wikipedia

Zum Schluss noch meine persönliche Wertung der ganzen Geschichte:
Du solltest die Verschlüsselung der Verbindung zw. deinem eigenen Gerödel und dem Server deines Providers nicht hinsichtlich der Sicherheit überbewerten!
Ja, der neugierige Nachbar kann garantiert nichts mitlesen. Und die meisten User klicken ja eh auf "weiter" oder "du darfst", wenn eine Zertifikatswarnung kommt. Wer beachtet das schon?
Es wird auch lediglich die Verbindung zwischen deinem eigenen Rechner und dem ersten Server deines Providers verschlüsselt. Bei deinem Provider liegen sowohl dein Mailtraffic, deine zumindest temporär zwischengespeicherten Mails als auch deine Passwörter (zumindest temporär) im Klartext vor. Wie es von deinem eigenen Provider zum Provider des Empfängers weitergeht, kannst du weder wissen noch beeinflussen. Du kannst höchstens glauben, was dir die Provider sagen (nach vielen Jahren des unverschlüsselten Transports wollen einige ja endlich verschlüsseln). Und auch wie der Empfänger deiner Mail seine Verbindung konfiguriert hat, weißt du nicht. Also, was solls ... .
Und du sollst auch wissen, dass die dt. Ermittlungsbehörden spätestens seit dem mit Lichtgeschwindigkeit durchgewunkenen Gesetz über die Bestandsdatenauskunft seit dem 01.07.2013 nicht nur deine Mails, sondern auch alle deine Zugangsdaten wie Benutzername und Passwort aber auch bei Providern gespeicherte kryptologische Schlüssel (Cloudanbieter!) ohne größere und lästige juristische Hürden (es wurde im Gesetzestext nicht ohne Grund von "Ordnungswidrigkeiten" geschrieben!) auf dem Silbertablett und auch innerhalb kürzester Zeit frei Haus geliefert bekommen.
Aber keine Angst, es sind ja nur die Guten und die Überwachen ja auch nur die Bösen ... .
Aber spätestens ab jetzt wird es [OT], deshalb beende ich jetzt an dieser Stelle.


MfG Peter

 

[jahlives]

@Peter
was sind für dich Posteingangsserver? SMTP? Dann kleine Korrektur ;-) Dann haben Posteingangsserver niemals TLS/SSL sondern nur STARTTLS. Server-zu-Server Verbindungen gehen immer auf Port 25 und dort kann SSL nur mit STARTTLS laufen. Aber erzwingen kann man am Eingangsserver STARTTLS leider nicht. Sonst empfängt man von gut der Hälfte der Absender keine Post mehr

Noch eine Ergänzung zu deinem Schlussabsatz: genau diese Diskussion haben wir hier in der CH auch. Lawful Interception. Alle Access-Provider sind bei uns verpflichtet technische Massnahmen einzubauen, um gezielt Traffic sniffen zu können. Das bereitet uns als Accessprovider ziemliche Kopfschmerzen. Was wir aber rein technisch nicht können ist es Mailpassworte rauszugeben. Die stehen alle als SSHA512 Hashes in einer DB. Viel Spass beim Knacken Zudem haben wir im Zuge dieser ganzen Diskussion damit angefangen die Mailserver so zu betreiben, dass präferiert die starken SSL-Ciphren geliefert und benutzt werden d.h. sie können von uns auch der Herausgabe des Server-Schlüssels (private Key) verlangen. Das bringt bei solchen Verbindungen überhaupt nichts

 

[Peter_Lehmann]

Hallo jahlives,

was sind für dich Posteingangsserver?

Wie üblich aus Sicht des Clients. Also so, wie es der Nutzer einstellt: der POP3 oder der IMAP-Server. (Ich weiß, im Thema ging es nur um SMTP ...)
Üblicherweise SSL/TLS. Nach meinem Verständnis dürfte aber auch STARTTLS möglich sein, ich lasse mich aber auch gerne belehren.
(Irrtum von mir: ich habe oben TLS/SSL geschrieben, kommt aber mit SSL/TLS wohl auf das selbe raus.)

Ich habe hier selbst einen SMTP-Eintrag, der mit SSL/TLS betrieben wird. (smtp.gmail.com, SSL/TLS, :465). Habe mir gerade jetzt eben noch einmal "die Mühe" gemacht, und 2x zwischen SSL/TLS und STARTTLS 587) hin und her geschaltet und ein paar Mails verschickt. Es klappt perfekt mit beiden Konfigurationen! Ich wüsste auch keinen richtigen Grund, warum das nicht gehen sollte. Der Server kann es garantiert, und der (gut bestückte!) Provider wird die auf den drei unterschiedlichen Ports ankommenden Verbindungen schon zu den richtigen Servern routen. Wie schon bemerkt, man muss die Varianten nehmen, die der Provider anbietet und auf seiner Webseite veröffentlicht. Bei manchem Provider geht eben alles. Aber es bleibt dabei: SMTP in der Regel verschlüsselte Verbindung mit STARTTLS.

Server-zu-Server Verbindungen gehen immer auf Port 25

Sagen wir mal, da haben sich die Provider auf diesen Port geeinigt. Oder eben die Standards angewandt. Theoretisch könnten sich zwei Provider auf jeden unüblichen Port für die direkte Verbindung zwischen ihren Servern einigen. Aber warum sollten sie solchen Blödsinn machen ;-)


MfG Peter

 

[SynNAS]

Hallo Peter, hallo jahlives,

Noch mal Danke für Eure ausführlichen Informationen und Einschätzungen.

@ Peter,
Du hast Recht, es geht hier momentan nur um SMTP
(POP3 und IMAP hätte ich später nochmals erwähnt, wobei das Prinzip wohl ähnlich bis gleich ist, nur dass die Portnummern eben andere sind:

SMTP auf Port 25 bzw. 587 und secure SMTP auf Port 465
IMAP auf Port 143 und secure IMAP auf Port 993
POP3 auf Port 110 und secure POP3 auf Port 995 richtig??)

Noch mal exemplarisch zum SMTP-Ablauf:

Bei mir ist es so:

Mail-Client <=== SMTP via Port 465 ===> Synology Email-Server
dann
Synology Email-Server <== via SMTP-Relay via Port 25 und angefordertem TLS ==> Mailserver (SMTP = Posteingang) bei meinem Provider

somit folgende User/PW:
Mail-Client <===User/PW meines Servers====> Synology Email-Server
dann
Synology Email-Server<==User/Password meiner Postfach-Kennung beim Provider==> Mailserver (SMTP = Posteingang) bei meinem Provider

Wenn nun meine Mail-Clients in meinem internen Netz sind, eh kein Problem
aber im Zuge von mobilen Mai-Cclients kommt die Verbindung auch über das Internet, meine Firewall zu meiner DMZ (wo der Synology Email-Server steht) zustande.
deshalb muss dies auch verschlüsselt sein!
Zum Provider hin, hast Du völlig recht, die Mails sind dann beim Provider, und für den Fall, das diese Unverschlüsselt sind (noch die überwiegende Mehrheit) sind
diese von so vielen zumindestens theoretisch, wie von Dir ausführlich beschrieben, lesbar.
Etwas mehr sorgen machen mir nicht die Mails selbst, sondern eben die Zugangskennungen.

Gut, im Falle meiner Postfachkennung beim Provider, da würde der Missbrauch "nur" bedeuten, daß Meine Mails gelesen / geschrieben / verändert werden könnten.

Die User / PW Kombination vom Client zu MEINEM Synology-E-Mail-Server ist mir aber viel wichtiger!! Deshalb werde ich dort auf SMTP via 465 "bestehen" um immer den
von Dir bestätigten "Indizbeweis" einer verschlüsselten Verbindung VOR austausch der User-PW - Kombination zu haben.

Deshalb habe ich auch diesen Tread angefangen, da mir da doch viel dran liegt.
Dank Eurer Hilfe ist nun auch schon viel Licht in's Dunkel gekommen, und ich glaube?!?! ich bin auf dem richtigen Weg, oder?

Grüße Stefan

 

[jahlives]

@Peter
jap STARTTLS gibt es mittlerweile auch oft bei den IMAP/POP3 Servern. Spart den Providern Ports ein, da es wie bei SMTP über die default Ports geht

@Stefan

Gut, im Falle meiner Postfachkennung beim Provider, da würde der Missbrauch "nur" bedeuten, daß Meine Mails gelesen / geschrieben / verändert werden könnten.

gegen das Lesen und Schreiben kann man in dem Fall nicht viel machen. Aber das Verändern kannst du - wenn nicht verhindern - dann immerhin erkennen. Dazu gäbe es z.B. DKIM (Domain Keys Identified Mails) welches durch eine Signatur verhindert, dass bestimmte Header verändert werden können. Oder man nutzt Software wie PGP welche die Mails komplett verschlüsselt. Leider kommt dann damit das Problem, dass längst nicht jeder Empfänger einen Schlüssel hat. Hier wären imho die Hersteller der Mailclients in der Pflicht, damit sie diese Methoden direkt in ihre Software einbauen.

 

[SynNAS]

Hallo jahlives,

... Dazu gäbe es z.B. DKIM (Domain Keys Identified Mails) welches durch eine Signatur verhindert, dass bestimmte Header verändert werden können. ...[/COLOR]

Wird dies "einmalig" auf dem entsprechenden Mailserver eingerichtet, oder von Nachricht zu Nachricht, ähnlich der Signierung (via z.B. PGP Schlüssel), eingestellt?

... Oder man nutzt Software wie PGP welche die Mails komplett verschlüsselt. Leider kommt dann damit das Problem, dass längst nicht jeder Empfänger einen Schlüssel hat. Hier wären imho die Hersteller der Mailclients in der Pflicht, damit sie diese Methoden direkt in ihre Software einbauen.[/COLOR]

Ja genau! da wäre ich sehr dafür, das endlich mal das Sicherheitsbewustsein wächst, und PGP (etc.) zum Standard wird!

Grüße Stefan

 

[jahlives]

Für dkim gibt es unter Linux opendkim. Der private Key ist statisch, ändert sich also nicht von Mal zu Mal. Im DNS der Zone wird dann der zugehörige Public Key publiziert. Anhand dessen kann die Empfangsseite prüfen ob die Signatur passt.
PGP als Standart wäre schön löst aber leider auch nicht alle Probleme v.a. deswegen weil man die Header einer Mail nicht verschlüsseln kann. Und die Header lassen bereits genügend Rückschlüsse zu wer mit wem gemailt hat. Auch nicht vergessen: das Subject ist ein Header und damit nicht zu verschlüsseln

 

[SynNAS]

Hallo "Jahlives"

erst mal
================== OT Anfang =====================

Euch allen ein gutes, glückliches und erfolgreiches neues Jahr 2014,
mit möglichst durchlaufenden Servern ;-))

================== OT Ende =======================

Ich sehe schon, mit den DKIM (Domain Keys Identified Mails) muss ich mich noch etwas auseinandersetzen, hört sich vielversprechend an,
da es eine gewisse Vertrauenswürdigkeit der Mails (Authentizität), zumindestens was die absendende Domain anbelangt, herbeiführen würde.

So ist doch schon mal klar, ob z.B. die Mail von einem bestimmten Firma / Geschäftspartner kommt. Im privaten Bereich wird das sicherlich noch dauern,
auch wenn schon Nahmhafte Provider wie Gmail oder Yahoo dies bereits einsetzten.

...
PGP als Standart wäre schön löst aber leider auch nicht alle Probleme v.a. deswegen weil man die Header einer Mail nicht verschlüsseln kann. Und die Header lassen bereits genügend Rückschlüsse zu wer mit wem gemailt hat. Auch nicht vergessen: das Subject ist ein Header und damit nicht zu verschlüsseln

Tja, da hast Du völlig recht, inzwischen wird auch der Allgemeinheit klar, daß man mit diesen Metadaten der e-Mails, die eben auch bei Verwendung der Verschlüsselung erhalten bleiben,
sehr sehr viel über die beteiligten Personen, vor allem aber über "Beziehungen" herausbekommen kann, niemand weis das besser als die NSA ;-))
Da hilft es auch nicht, daß immer wieder versucht wird darzustellen, daß das Wissen von "wann vom wem zu wem" doch gar nicht so schlimm sei... !
Gerade eine große Anzahl von diesen Metadaten ist sehr aussagekräftig, selbst wenn man davon ausgeht, daß im Betreff nichts aussagekräftiges oder was falsches stehen würde.

Trotzdem bin ich für Verschlüsselung, da ich in meiner "Umgebung" immer wieder feststellen, daß den e-Mails viel zu viel vertraut wird, und vor allem immer wieder geglaubt wird,
das liest doch eh niemand... Trugschluss!!!! Die ERGEBNISSE dessen, was die "FILTER" lesen sind eben doch sehr interessant!

Wers nicht glaubt... NSA fragen... ;-))

Grüße Stefan