fetchmail: ssl oder TLS

[michaa7]

Wegen eines Fehlers (behoben) mußte ich mich die vergangenne Tage mit dem fetchmail.log beschäftigen. Dabei ist mir folgende Sequenz aufgefallen, die sich bei jedem Abholen so wiederholt:

fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-RSA-AES256-SHA, 256/256 secret/processed bits
fetchmail: POP3< +OK The Microsoft Exchange POP3 service is ready. (UNIEX-W2-B)
fetchmail: POP3> CAPA
fetchmail: POP3< +OK
fetchmail: POP3< TOP
fetchmail: POP3< UIDL
fetchmail: POP3< SASL PLAIN
fetchmail: POP3< USER
fetchmail: POP3< STLS
fetchmail: POP3< .
fetchmail: mail.meineuni.de: WARNING: server offered STLS, but sslproto '' given.

Mit "tcpflow -i enp0s25 -c tcp port 995" sehe ich dass die Kommunikation auf Port 995 läuft. Ausser IP.Port und Certifikatnamen sehe ich nichts im Klartext sondern nur ein Gemisch aus ... Zahlen und Buchstaben. Ich gehe davon aus dass dies das Abbild einer verschlüsselten Verbindung ist.

Dennoch irritiert mich die Warnung und das sslproto '' . In meiner fetchmailrc steht nur "ssl" (nach dem "user" Angaben, nichts von sslproto, ich habe aber hier auch schon tls1.2+ explizit angegeben was an der Meldung im Log nichts ändert).

Wenn der Uniserver wie im Log oben angegeben TLSv1.2 anbietet, was fetchtmail ja beherrscht, warum dann dieses Herumgeeiere?

Was will mir diese Warnung sagen?

[Livingston]

Teilantwort: STLS steht für "STARTTLS". Das ist eine Verbindungsart, die zunächst unverschlüsselt beginnt und dann TLS unter beiden beteiligten Seiten aushandelt.
Ich vermute, dass Dein fetchmail im Moment so konfiguriert ist, dass es nur reines TLS bedient, der Server (Microsoft Exchange - grusel ) aber nur mit STARTTLS klarkommt.

[michaa7]

Ich sehe aber mit

Code: Alles auswählen

tcpflow -i enp0s25 -c tcp port 110

überhaupt keinen Traffic und mit

Code: Alles auswählen

tcpflow -i enp0s25 -c tcp port 995 

wohl nur von Anfang an verschlüsselten Traffic. Unsicher bin ich mir bei letzterem nur deshalb weil ich nicht weiß wie sich verschlüsselter Traffic im Terminal darstellt. Ich sehe lesbare IP:Port Angaben und Certificatnamen, sonst nur Buchstaben, Zahlen, Sonderzeichen, Punkte.

Eigentlich schaut das für mich so aus als wäre es von Anfang an verschlüsselt. Um so weniger verstehe ich die genannte Warnung. Und ich versteh nicht warum fetchmail auf sslproto '' ausweicht (sslproto '' given), oder dies behauptet, wo es ausdrücklich *nicht* von mir in der fetchmail deklariert wurde.

Ich will da weiter keinen Bohei darum machen, ich hätte einfach nur gerne verstanden was da passiert ... das scheint nicht so einfach zu erreichen.

Danke jedenfalls.

[Livingston]

Es hängt davon ab, was der Exchange erwartet. Einerseits sagt Dein fetchmail, womit es arbeitet:

Code: Alles auswählen

fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-RSA-AES256-SHA, 256/256 secret/processed bits

Andererseits beschwert sich der Exchange-Server (beachte: fetchmail zitiert hier nur, was der Server sagt):

Code: Alles auswählen

fetchmail: mail.meineuni.de: WARNING: server offered STLS, but sslproto '' given.

Er besteht also auf STARTTLS (hier abgekürzt mit STLS), mokiert sich aber darüber dass er nur ein sslproto sieht.
Dass hier nicht Port 110 genutzt wird, heißt nix. Es liegt im Ermessen des Servers, welche Ports für welche Dienste genutzt werden sollen.

Hab lange nicht mehr mit fetchmail gearbeitet, aber ich bin mir sicher, dass es da eine Konfigurationsmöglichkeit für STARTTLS gibt.
Für eine genaue Analyse kannste ja auch mal tcpdump oder den Kabelhai (wireshark) einklinken.
Und ein Testlauf mit nem klassischen Mail-Client (Thunderbird, claws-mail, ...) könnte auch Licht in die Sache bringen.

[Meillo]

Fuer mich sieht es so aus, als weise Fetchmail darauf hin, dass du statt POP3S auf Port 995, lieber POP3 mit StartTLS auf Port 110 machen solltest. Wobei fuer mich unklar ist, warum es das lieber haette.

Vielleicht ist das aber auch eine falsche Faehrte und es geht um das hier beschrieben Problem: https://forums.centos.org/viewtopic.php?t=45380
... also in der Config statt `ssl' nun `sshproto' zu nutzen.

[michaa7]

Fuer mich sieht es so aus, als weise Fetchmail darauf hin, dass du statt POP3S auf Port 995, lieber POP3 mit StartTLS auf Port 110 machen solltest. Wobei fuer mich unklar ist, warum es das lieber haette.

Das würde ja bedeuten dass, obwohl beide den vollverschlüsselten Standard unterstützen möchte der Exchange Server nur die anfangs unverschlüsselte Variannte verwenden. So ähnlich wirkt das auch auf mich. Aber das wäre ja blanker Unsinn.
Grund meiner Nachfragerei ist dieses *alte* (2013) posting. Darin wird beschreiben, dass das alleinige Statement "ssl" dafür sorgen würde dass entweder verschlüsselt wird oder die Verbindung abgebrochen wird, während sslproto als fallback in den unverschlüsselten Modus wechselt. viewtopic.php?t=140434#p914923
Von daher interessiert mich woher dieses sslproto'' stammt, was ich ausdrücklich nicht deklariere.
Zudem gehe ich davon aus, dass, da ich fetchmail im usermodus laufen lasse, ausser der fetchmailrc und /usr/bin/fetchmail keine weitere Datei, insbesondere keine weitere Konfigdatei eine Rolle spielt. Dennoch bin ich die per "dpkg -L fetchmail" auffindbaren konfig Dateien durchgegangen und finde da nirgends ein sslproto deklariert. Irgendwie ergibt das einfach kein stimmiges Bild.

[michaa7]

..
Hab lange nicht mehr mit fetchmail gearbeitet, aber ich bin mir sicher, dass es da eine Konfigurationsmöglichkeit für STARTTLS gibt.

Ich will aber kein STARTTLS wenn beide Seiten angeblich zu Vollverschlüsselung fähig sind. *Augenscheinlich* (tcpflow) ist die Verbindung ja vollverschlüsselt.

Für eine genaue Analyse kannste ja auch mal tcpdump oder den Kabelhai (wireshark) einklinken.

wie würde ich das am unaufwendigsten machen?

Und ein Testlauf mit nem klassischen Mail-Client (Thunderbird, claws-mail, ...) könnte auch Licht in die Sache bringen.

Ja, das läß?t sich wohl machen

[Meillo]

Vielleicht ist nur die Fetchmail-Meldung irrefuehrend. Ich verstehe derzeit auch nicht, warum das eine Warning ist.

Wenn deine Verbindung sowieso schon verschluesselt ist, dann ist sowohl STLS als auch `sslproto ''' irrelevant. STLS brauchst du nur wenn die Verbindung noch nicht verschluesselt waere. Laut Manpage fetchmailrc(5) schaltet sslproto '' STLS explizit ab.

Die Warnung ist dann verstaendlich, wenn die Verbindung unverschluesselt waere. Dann wuerde sie darueber informieren, dass hier ein STLS moeglich waere, aber nicht genutzt wird, weil sslproto auf '' steht.

Vielleicht kann eine Seite der Verbindung nicht erkennen, dass sie schon verschuesselt ist und sorgt so dafuer, dass die Meldung erzeugt wird.

Allerdings ist laut Manpage sslproto per Default auf TLS1 gesetzt (zumindest falls ssl nicht gesetzt ist).

So ganz steige ich immer noch nicht durch. Vielleicht kannst du erweitertes Logging einschalten um noch mehr zu erfahren.

[Livingston]

Überlegung am Rande: Für echtes TLS ist natürlich eine vollständige Zertifikatskette nötig. Wenn die nicht komplett ist, kann nicht von Anfang an TLS genutzt werden. STARTTLS dient dann meist als Krücke und initiiert dann einen Schlüsselaustausch. Das ist nicht state of the art, insbesondere weil man-in-the-middle-Attacken prinzipiell möglich sind.

Ich hatte vor Jahren mal das Problem, dass ich immer mal wieder das Zertifikat meines Uni-Mailservers manuell installieren musste, weil es die Profis des dortigen Rechenzentrums regelmäßig nicht schafften, erneuerte Mailserver-Zertifikate ordentlich zu publizieren.

[michaa7]

...
So ganz steige ich immer noch nicht durch. Vielleicht kannst du erweitertes Logging einschalten um noch mehr zu erfahren.

Ich habe jetzt -v auf -v -v (man fetchmail!) erhöht, was aber am output nichts ändert. Hier mal ein vollständiger Durchlauf mit nur den persönlichen Angaben und Gegenstellenbezeichnungen editiert:

fetchmail: awakened at Do 04 Apr 2024 14:57:34 CEST
fetchmail: 6.4.38 querying mail.uni.de (protocol POP3) at Do 04 Apr 2024 14:57:34 CEST: poll started
fetchmail: Trying to connect to 137.226.78.60/995...connected.
fetchmail: SSL verify callback depth 2: verify_ok == 1, err = 0, ok
fetchmail: Certificate chain, from root to peer, starting at depth 2:
fetchmail: Issuer Organization: The USERTRUST Network
fetchmail: Issuer CommonName: USERTrust RSA Certification Authority
fetchmail: Subject CommonName: USERTrust RSA Certification Authority
fetchmail: SSL verify callback depth 1: verify_ok == 1, err = 0, ok
fetchmail: Certificate at depth 1:
fetchmail: Issuer Organization: The USERTRUST Network
fetchmail: Issuer CommonName: USERTrust RSA Certification Authority
fetchmail: Subject CommonName: GEANT OV RSA CA 4
fetchmail: SSL verify callback depth 0: verify_ok == 1, err = 0, ok
fetchmail: Server certificate:
fetchmail: Issuer Organization: GEANT Vereniging
fetchmail: Issuer CommonName: GEANT OV RSA CA 4
fetchmail: Subject CommonName: mail.uni.de
fetchmail: Subject Alternative Name: mail.uni.de
fetchmail: mail.uni.de key fingerprint: 98:B5:70:1F:68:8A:85:29:B1:CF:AA:98:91:9F:77:9A
fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-RSA-AES256-SHA, 256/256 secret/processed bits
fetchmail: POP3< +OK The Microsoft Exchange POP3 service is ready. (uniEX-W2-B)
fetchmail: POP3> CAPA
fetchmail: POP3< +OK
fetchmail: POP3< TOP
fetchmail: POP3< UIDL
fetchmail: POP3< SASL PLAIN
fetchmail: POP3< USER
fetchmail: POP3< STLS
fetchmail: POP3< .
fetchmail: mail.uni.de: WARNING: server offered STLS, but sslproto '' given.
fetchmail: POP3> USER id@post.uni.de
fetchmail: POP3< +OK
fetchmail: POP3> PASS *
fetchmail: POP3< +OK User successfully logged on.
fetchmail: selecting or re-polling default folder
fetchmail: POP3> STAT
fetchmail: POP3< +OK 0 0
fetchmail: No mail for id@post.uni.de at mail.uni.de
fetchmail: POP3> QUIT
fetchmail: POP3< +OK Microsoft Exchange Server 2016 POP3 server signing off.
fetchmail: 6.4.38 querying mail.uni.de (protocol POP3) at Do 04 Apr 2024 14:57:35 CEST: poll completed
fetchmail: New UID list from mail.uni.de:
<empty>
fetchmail: not swapping UID lists, no UIDs seen this query
fetchmail: Query status=1 (NOMAIL)
fetchmail: sleeping at Do 04 Apr 2024 14:57:35 CEST for 360 seconds

[chrbr]

Hallo michaa7,
in meiner .fetchmailrc habe ich folgendes stehen und bekommt praktisch die gleiche Ausgabe wie Du.

Code: Alles auswählen

poll pop.mail.wo with protocol POP3:
    username ich@mail.wo:
    ssl;
    sslcertck;
    password geheim;

[michaa7]

Wenn ich die Mails mit Thunderbird abhole steht in den Kopfzeilen auch nur etwas von

Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)

.

So weit so gut.

Falls jemand mit dem absoluten Durchblick die Ungereimtheiten aufklären kann, nur her damit, aber bis dahin lasse ich es hiermit gut sein.

Danke an alle.