On Sat, Aug 12, 2023 at 01:35:11PM -0400, pgnd wrote:
> > https://datatracker.ietf.org/doc/html/rfc7672#section-8.2
>
> I've no idea in this case why aNULL is explicitly ref'd; for my own
> configs I don't call it out, rather stick with the default
See the final comment in this message.
> and, TBH, don't get what's happening here
>
> "aNULL:-aNULL:...!aNULL"
That's just cipherlist ordering gymnastics, to ensure that aNULL ciphers
are preferred, when mutually enabled.
> > PCAP capture of an attempted TLS handshake would have been more useful.
>
> I've just been reading up on tcpdump'ing TLS -- and trying to figure
> out extracting cipher types; seems a useful add'l tool to have at
> hand.
>
> latest naive attempt,
>
> tcpdump -i eth0 "tcp port 25 and (tcp[((tcp[12] & 0xf0) >> 2)] = 0x16)"
What is that complex filter for. Just save the traffic to a file:
# tcpdump -i eth0 -s0 -w /tmp/smtp.pcap tcp port 25
or perhaps limit the capture to a particular source IP (IIRC):
# tcpdump -i eth0 -s0 -w /tmp/smtp.pcap tcp port 25 and host 192.0.2.1
Then identify a session (client source port) of interest and extract
just that one connection:
# tcpdump -r /tmp/smtp.pcap -s0 -w /tmp/tls.pcap tcp port 12345
That'd then be the file to analyse:
# tshark -nr /tmp/tls.pcap -V ssl
> > My money is on an ECDSA server certificate
>
> on the receiving server's end, right?
Naturally.
> checking further
>
> grep smtpd_tls main.cf | grep file
> smtpd_tls_dh1024_param_file=${config_directory}/dh4096.pem
> smtpd_tls_eckey_file =
> /etc/sec/ssl/LE/deploy/${var_DOM_CMX0024}/priv.ec.key
> smtpd_tls_eccert_file =
> /etc/sec/ssl/LE/deploy/${var_DOM_CMX0024}/fullchain.ec.crt.pem
> smtpd_tls_key_file =
> /etc/sec/ssl/LE/deploy/${var_DOM_CMX0024}/priv.rsa.key
> smtpd_tls_cert_file =
> /etc/sec/ssl/LE/deploy/${var_DOM_CMX0024}/fullchain.rsa.crt.pem
>
> sigh. a continuation line.
>
> which, iiuc, would lead to the ec cert being offered, but NOT the
> 'continued' rsa cert spec
On Sat, Aug 12, 2023 at 01:42:04PM -0400, pgnd wrote:
> > one'd hope that banks and hospitals might be a bit more up-to-date on their
> > end.
>
> after the key file cleanup,
>
> ...
> Untrusted TLS connection established from
> esa.hc2802-61.iphmx.com[68.232.155.227]: TLSv1.2 with cipher
> ECDHE-RSA-AES128-GCM-SHA256
> ...
This explains the '!aNULL', added automatically by Postfix, because
you're soliciting and receiving client certificates. Drop the
smtpd_tls_ask_ccert = yes
from at least port 25, or in general any ports where you don't make use
of client certificates.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]