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 -
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE0L/WueylaUpvFJ3Or0zGdqa2wUIFAmHBgIwACgkQr0zGdqa2 wUKdoQf+KmQw2qFNQ7jhaHpcWGVuvuH2W+lFl7Kb7r59R5W7WOssVNreCeVkGlo5 VIyjnrABohg+7D/M9fM4CSCkhGas7KdO1VpjHlg1TNSNUEfSLRvF6xI2Xho30Nlz m3bDS2rNijh4P+BsLTWC5YUiKEws+xDaLEGqkkUJm3O7Py6rpWhKatiDQflbC4hR b6TZL18cp/HkEg8zTGfJH27L8QxixgnuO3PELKYcFroHYvd86Z9gO4BDYE4ucOmw psbia6WfsMaRK6vK+VFwQQ3B0nF+JgkkLVrvykk9NDWOFkcBVtMCNxxtiiWXdvXc HROFkHkyhu7A8ZuymbzuQw1AUQVDQA==
=M1rP
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)