debian-mailing-lists@thomas.freit.ag <debian-mailing-lists@thomas.freit.ag> (Sa 18 Dez 2021 18:05:21 CET):
> Hi Lars,
>
> On 18.12.21 12:19, Lars Schimmer wrote:
> > Client ist default debian setup, kein Zertifikat, smarthost server 1 eingetragen.
> >
> > Server ist public reachable, nur wenig Änderungen zur Standard Config, unter anderem Limits an Receipients, Size,...
> >
> > Und für TLS wichtig: MAIN_TLS_ENABLE = true
> >
> > Zertifikat habe ich ein wildcard von AlphaSSL und/oder ein mit dem debian exim cert gen (aus den Dokus) erstelltes probiert.
> >
> > #Ports to listen on
> > daemon_smtp_ports = 25 : 465
> > tls_on_connect_ports = 465
>
> Damit sollte der Exim-Client mMn. über Port 25 seine Mails am Smarthost abgeben, typischerweise mit opportunistic TLS, also
> verschlüsselt wenn es passt (es sei denn Du erzwingst TLS per "tls_try_verify_hosts" (oder entsprechendem Macro).
tls_try_verify_hosts *erzwingt* kein TLS. Es erzwingt nicht mal eine
Überprüfung des Zertifikats (wie ja auch der Name der Option schon
andeutet.)
Wenn Du vom Server sprichst:
Überhaupt möchtest Du für Port 25 und 587 erst in einer späteren Phase prüfen,
ob TLS verwendet wird. Nachdem Du es natürlich am Anfang angeboten hast.
tls_advertise_hosts = *
ist mittlerweise Default, Exim zeigt jedem Client seine Bereitschaft zu
STARTTLS.
tls_on_connect_ports = ….
wäre wichtig für die Submission-Clients, die sich am TLS-before-SMTP
(oder wie Options sagt „tls-on-connect“ versuchen.)
Beim Client möchstest Du TLS erzwingen mit der Transport-Option
hosts_require_tls = …
*Möglicherweise* möchtest Du noch etwas das Zertifikat der Gegenseite
prüfen, dann wäre das mit dem tls_verify_hosts oder tls_try_verify_hosts
die Option, ja. *ABER*, die überprüft nur, ob das Zertifikat gültig ist
(von einer bekannten CA ausgestellt wurde, nicht abgelaufen, …), aber
*nicht*, ob es etwas mit dem Host auf der Gegenseite zu tun hat!
Dafür müsstest Du festlegen, *wie* die „Policy“ für die Prüfung sein
soll, also muss das Zertifikat zum Hostnamen passen, muss es von einer
*bestimmten* CA ausgestellt worden sein, muss es zu einem TLSA-Datensatz
passen, etcpp.
> Willst Du nur TLS testen geht auch openssl s_client --connect localhost:465 (oder mit korrektem Hostnamen, dass das Zertifikat auch validiert werden kann.
Und für Port 25 oder 587 (oder sonst einen Port, wo kein tls-on-connect
gemacht wird:
openssl s_client -connect <host>:<port> -starttls smtp
(Ja, auch ein Minus genügt.)
> 465 bzw 587 nutzen typischerweise TLS komplett (das heißt kein Upgrade der zunächst unverschlüsselten Verbindung auf TLS), das vermeidet Probleme mit
> STARTTLS (siehe zB. https://www.feistyduck.com/bulletproof-tls-newsletter/issue_80_vulnerabilities_show_fragility_of_starttls).
Das ist nicht ganz richtig. 465 nutzt typischerweise tls-on-connect und
ist damit nicht anfällig für diese Downgrade-Angriffe. 587 nutzt
STARTTLS.
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -
Attachment:
signature.asc
Description: PGP signature