Allow and ignore TLS sessions

[jrobbins]

So tons of spam is getting through, but it doesn't show up in the logs. I looked at the email "properties" of one of the offenders and it appears spammers are using TLS. The box is checked for "Allow and ignore TLS sessions". I see on the Wiki it says:

"Allow and ignore TLS sessions: This option controls the allowance of TLS sessions. If unchecked (the default) the TLS advertisement (if present) is removed from the server advertisements and TLS is not allowed on any scanned sessions. If checked, the TLS advertisement is allowed and if the client initialized TLS the message will pass through completely unscanned, even if it is spam."

So, if I uncheck the box, will it block ALL email that uses TLS? It's clearly letting any and all TLS through now. Seems like a lose-lose. Any advice?

[sky-knight]

Yeah... this is one of those ugly places where you simply need a better tool that runs on the mail server itself.

If you don't block TLS, Untangle's anti-spam functionality simply can't work. There is logic in doing that... If you want authenticated users to use TLS to send mail to the server itself, that should be running over TCP 587 on it's own service / connector. That way your end users can use TLS to protect the authentication tokens when they send mail. Users shouldn't be authenticating on TCP 25, leave that dedicated for email server and direct SMTP purposes.

There is however, minimal benefit of using TLS to move mail from one email host to another... BUT some organizations require it. So if you do make the choice to prevent any incoming TLS on TCP 25, you'll want to watch your SMTP logs because you might have to use them to get IP addresses to bypass so those specific servers can transmit without impacting the SMTP module at all.

Another thing you can do, because the Spam Blocker is a rack app, you can use policy rules to push traffic sourced from servers that need TLS into a policy that has a Spam Blocker that's configured to allow it.

But yeah... this is a bit of a thorny place, there's no really good answers.

[jrobbins]

Thank you for the reply. Definitely some things to think about.

[johnsonx42]

SMTP-TLS is getting annoying. I'm running into more companies and organizations that require it or they'll refuse to do business with you. Beginning Dec 1st, SAM will require it (SAM is the system all government procurement contracts go through). Nothing can be done about it, everyone has a security bug up their hind ends, and requiring SMTP-TLS is an easy way to say "Look how super-serious we are about security!!!!!!11!!!11"

Can SSL Inspector work with email? I'm guessing not, else Sky would've said so.

[johnsonx42]

Can SSL Inspector work with email? I'm guessing not, else Sky would've said so.

I guess it is supposed to be possible according to the Wiki: https://wiki.untangle.com/index.php/...fic_Processing

I assume the trick will be to have an SSL certificate on the untangle machine that has the mail server host name as a SAN; that's the only way I can imagine it would work. It'd be nice if the documentation said a few more words about this...

[sky-knight]

Not necessarily... I don't use SSL inspector, I avoid MITM SSL stuff like the plague. To further complicate matters, 100% of my email servers are now M365 or Google.

So all my anti-spam stuff has transitioned to cloud tech. If I had an on premise Exchange, I'd be using one of those cloud solutions anyway because it does archival, spam, anti-malware, AND acts as a holding bin for incoming mail while Exchange is down for updates.

I'm living in a head space that has zero percent room for spam assassin on a router somewhere.

So if SSL Inspectors can do this, it's very possible that I would not be aware of it.

[johnsonx42]

What I'm finding at the moment is that 16.something seems to have broken the "Allow and Ignore TLS sessions" switch. I couple of weeks ago I tested SMTP TLS and it worked fine, but I didn't want to enable it until I decided what to do about the spam blocker, and I needed to add the mail server's backup DNS name into the certificate... so I unchecked the box again and verified that TLS was again being blocked.

Now today I tried to turn it on again, and it won't work... no matter what I do, Untangle is blocking the STARTTLS command. The only thing different is that it's updated itself to 16.0.1 and now 16.1.1. The STARTTLS command works fine if I telnet to the mail server internally. I've verified with a packet capture that Untangle is definitely blocking STARTTLS, it never reaches the mail server; it's also changing the response to the EHLO command.

Very frustrating.

[sky-knight]

That would be expected behavior if Allow and ignore TLS sessions wasn't enabled, but if it is... that's a bug.

[johnsonx42]

That would be expected behavior if Allow and ignore TLS sessions wasn't enabled, but if it is... that's a bug.

yes, I've toggled it and saved and untoggled it and saved more times than I can count, and even turned off Spam Blocker altogether, to no avail. Even tested with it unchecked just to see if it's suddenly backwards for some reason. no matter what, untangle simply dumps the STARTTLS command into the bit bucket, and responds with "500 Syntax error, command unrecognized". Even that last bit is a tell because my mail server's syntax error message is just "500 Syntax error"
the only thing I haven't done is reboot it, but I rebooted it Monday for a completely unrelated reason and that was after the 16.1.1 update.

[sky-knight]

yes, I've toggled it and saved and untoggled it and saved more times than I can count, and even turned off Spam Blocker altogether, to no avail. Even tested with it unchecked just to see if it's suddenly backwards for some reason. no matter what, untangle simply dumps the STARTTLS command into the bit bucket, and responds with "500 Syntax error, command unrecognized". Even that last bit is a tell because my mail server's syntax error message is just "500 Syntax error"
the only thing I haven't done is reboot it, but I rebooted it Monday for a completely unrelated reason and that was after the 16.1.1 update.

Yeah, I'd have a ticket open for that mess.

[johnsonx42]

Well it works fine today, nothing is different, it just works. No idea.

[johnsonx42]

...and having gotten SMTP-TLS working, I turned on SSL Inspector and it's seamlessly inspecting SMTP-TLS sessions and the spam blocker is seeing them unencrypted.

so, detour aside, that's the answer for our OP - if you need to allow SMTP-TLS but don't want a flood of encrypted spam, enable SSL Inspector