Cannot decrypt email SMTP traffic over port 587

[amiq96]

I am trying to decrypt thunderbird traffic at SMTP port 587, but it doesn't work. Although, SMTP 465 decrypts just fine.

• Output of sslproxy -V

SSLproxy v0.9.4-17-g0e8e2c3-dirty (built 2024-01-31)
Copyright (c) 2017-2022, Soner Tari <[email protected]>
https://github.com/sonertari/SSLproxy
Copyright (c) 2009-2019, Daniel Roethlisberger <[email protected]>
https://www.roe.ch/SSLsplit
Build info: V:GIT
Features: -DHAVE_NETFILTER
NAT engines: netfilter* tproxy
netfilter: IP_TRANSPARENT IP6T_SO_ORIGINAL_DST
Local process info support: no
compiled against OpenSSL 1.1.1n  15 Mar 2022 (101010ef)
rtlinked against OpenSSL 1.1.1n  15 Mar 2022 (101010ef)
OpenSSL has support for TLS extensions
TLS Server Name Indication (SNI) supported
OpenSSL is thread-safe with THREADID
OpenSSL has engine support
Using SSL_MODE_RELEASE_BUFFERS
SSL/TLS protocol availability: tls10 tls11 tls12 tls13 
SSL/TLS algorithm availability: !SHA0 RSA DSA ECDSA DH ECDH EC
OpenSSL option availability: SSL_OP_NO_COMPRESSION SSL_OP_NO_TICKET SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION SSL_OP_TLS_ROLLBACK_BUG
compiled against libevent 2.1.12-stable
rtlinked against libevent 2.1.12-stable
compiled against libnet 1.1.6
rtlinked against libnet 1.1.6
compiled against libpcap n/a
rtlinked against libpcap 1.10.0 (with TPACKET_V3)
compiled against sqlite 3.34.1
rtlinked against sqlite 3.34.1
4 CPU cores detected

• Output of uname -a

Linux debian 5.10.158 #5 SMP Tue Jan 3 20:42:05 IST 2023 x86_64 GNU/Linux

• Exact command line arguments used to run sslproxy

./src/sslproxy -D -p /var/run/sslproxy.pid  -j /tmp/sslproxy -k /etc/ssl-certs/private/default-ca.key -c /etc/ssl-certs/cadir/default-ca.crt https 0.0.0.0 18443 http 0.0.0.0 18442 ssl 0.0.0.0 18444 -e tproxy

./src/sslproxy -D -p /var/run/sslproxy.pid  -j /tmp/sslproxy -k /etc/ssl-certs/private/default-ca.key -c /etc/ssl-certs/cadir/default-ca.crt https 0.0.0.0 18443 http 0.0.0.0 18442 smtps 0.0.0.0 18444 -e tproxy

./src/sslproxy -D -p /var/run/sslproxy.pid  -j /tmp/sslproxy -k /etc/ssl-certs/private/default-ca.key -c /etc/ssl-certs/cadir/default-ca.crt https 0.0.0.0 18443 http 0.0.0.0 18442 smtp 0.0.0.0 18444 -e tproxy

[sonertari]

The submission port requires autossl proxyspec. See the sslproxy and pf configuration on UTMFW for examples.
And my comments on your previous issue for enabling DEBUG_PROXY apply here as well.

[amiq96]

sslproxy args used:

./src/sslproxy -D4 -n -p /var/run/sslproxy.pid -j /tmp/sslproxy -k /etc/ssl-certs/private/default-ca.key -c /etc/ssl-certs/cadir/default-ca.crt https 0.0.0.0 18443 http 0.0.0.0 18442 autossl 0.0.0.0 18444 -e tproxy -o VerifyPeer=no

-D4 output

[FINEST] pxy_thr_timer_cb: thr=0, load=0, to=0
[FINEST] pxy_thr_timer_cb: thr=6, load=0, to=0
[FINEST] pxy_thr_timer_cb: thr=2, load=0, to=0
[FINEST] pxy_thr_timer_cb: thr=3, load=0, to=0
[FINEST] pxy_thr_timer_cb: thr=1, load=0, to=0
[FINEST] pxy_thr_timer_cb: thr=4, load=0, to=0
[FINEST] pxy_thr_timer_cb: thr=7, load=0, to=0
[FINEST] pxy_thr_timer_cb: thr=5, load=0, to=0
[FINEST] pxy_thr_timer_cb: thr=2, load=0, to=0
[FINEST] pxy_thr_timer_cb: thr=4, load=0, to=0
[FINEST] pxy_thr_timer_cb: thr=7, load=0, to=0
[FINEST] pxy_thr_timer_cb: thr=5, load=0, to=0
[FINEST] pxy_thr_timer_cb: thr=1, load=0, to=0
[FINEST] pxy_thr_timer_cb: thr=3, load=0, to=0
[FINEST] pxy_thr_timer_cb: thr=6, load=0, to=0
[FINEST] pxy_thr_timer_cb: thr=0, load=0, to=0
[FINEST] pxy_thr_timer_cb: thr=4, load=0, to=0
[FINEST] pxy_thr_timer_cb: thr=0, load=0, to=0
[FINEST] pxy_thr_timer_cb: thr=5, load=0, to=0
[FINEST] pxy_thr_timer_cb: thr=7, load=0, to=0
[FINEST] pxy_thr_timer_cb: thr=3, load=0, to=0
[FINEST] pxy_thr_timer_cb: thr=6, load=0, to=0
[FINEST] pxy_thr_timer_cb: thr=1, load=0, to=0
[FINEST] pxy_thr_timer_cb: thr=2, load=0, to=0

[sonertari]

Do you have any problems with the autossl proxyspec now?

[amiq96]

Yes.even autossl proxy arg is not decrypting traffic. Nor is it allowing the mail to be sent. Same has been the case with args ssl smtp and smtps

[sonertari]

You should inspect the logs with the -D4 option (the logs you have provided above do not have anything relevant).

[amiq96]

That's the thing, I supplied the arg -D4 to sslproxy, and those are the only logs I got. Apart from the general output to stdout when sslproxy starts, which is the same as -D output

[amiq96]

@sonertari any ideas?

[sonertari]

I don't know why you cannot get verbose logs with -D4. I don't have any idea without those logs.
Remind you that first you said that smtp and smtps proxyspecs were fine, but now you say that they don't work either.
It is also possible that there may be a problem/bug in sslproxy with the -n option using autossl, but I cannot do anything without verbose logs.

[amiq96]

I may have misunderstood you. Is passing smtp or smtps as args to sslproxy different than enabling them in the proxyspecs file?

My current understanding is I can either do the latter or the former. Doing both is not necessary. SMTP on port 465 works fine, but not on 587, is what I said I think. Also, to make SMTP 465 decryption work, I don't even need to use smtp smtps or autossl. The ssl arg to sslproxy is enough to decrypt SMTP 465 traffic.

I assure you I have enabled DEBUG_PROXY and am running with -D4.

[sonertari]

Yes, you don't need smtps, ssl proxyspec is expected to work on 465 too. But smtps proxyspec validates the smtp protocol used on those connections, which can be used to enforce protocol use on standard ports (prevents misuse).
587 is the submission port with STARTTLS, and it should work with autossl proxyspec.
But honestly I don't remember using the -n option (split mode) with autossl for smtp. I did use it with the default divert mode on UTMFW (and it seems to work for me).
I have released v0.9.5 a few days ago, but I doubt it will change anything in your case.
I need verbose logs.