STARTTLS becoming a security issue

[EKjellquist]

A lot of new CVEs out for most implementations of STARTTLS, which is slowly becoming more of a risk. Utilizing AMS' built-in features along with IPBan or similar tool help tremendously, but eventually moving away from implicit connections and serving strictly explicit connections is coming down the pike...

https://cyware.com/news/starttls-flaws-affecting-major-email-clients-and-servers-b68936f7

[Code Crafters]

You can disable either implicit SSL (separate port with SSL from the start of the connection) or explicit SSL (normal SMTP port(s) with SSL negotiated after connecting) but unticking those options within SMTP. Are you saying you need something else more than this though?

[EKjellquist]

At the moment, no it's not a need, just another consideration for AMS upgrading; looking forward to hearing about AMS 5 betas this year, hopefully...

[Code Crafters]

But since you already can disable STARTTLS by turning off "Use Explicit SSL", are you suggesting some other feature that would be needed? If so, can you explain what the feature would do in more detail please?

As for AMS5, we're looking at doing an AMS5 release pretty soon. The initial release will include a lot of WebMail upgrades and bug fixes including adding a lot more language translations for WebMail which is the breaking change that forces a version 5. After the initial release, we hope to add DKIM and TLS 1.3 after but both are pretty big updates so no release dates confirmed for those yet.

[EKjellquist]

I wouldn't really have to disable STARTTLS entirely with an upgraded AMS version with modern protocols (e.g. TLS 1.3), but since TLS 1.2 is still viable for awhile, at least updating to the OpenSSL 1.1.1 branch would clear up the issues we currently have with PCI, if that's expected with AMS 5.0 / AFS 4.0.

The only weird issue I'm seeing fairly consistently is in Webmail while viewing an email and changing from HTML view to Source (which normally opens the raw mail data in a new tab), consistently the 'session expired, please log in again' appears (this is on clients, servers, whatever browser, etc). Been about a year or so, not sure if it's browser / windows updates since then, but haven't been able to figure it out (this on v 4.2.4). Not a major issue (as I can just look at plaintext server-side manually).

[Code Crafters]

I've logged your other bugs to investigate further.

Are you sure WebMail sessions are just timing out? There is an idle timeout setting in WebMail if the user doesn't do any API requests for a period of time.

As for switching to plain text, we haven't seen this issue. Are you sure the emails have a plain text section?

[EKjellquist]

Definitely not a timeout issue, and it happens on any mail, whether it's formatted for HTML or not. Happens in any browser, on any client in webmail (including on the server). We've used a Let's Encrypt certificate for at least 5 years now, and this issue only seems to have popped up in the last ~12-18 months on the same AMS version of 4.2.4, so imo it's probably either a Windows update thing over time or involving how browsers handle the handoff between the main tab and opening the 'Source' tab for an email that for whatever reason 'thinks' it's timed out. The session is definitely still good, you can keep browsing as normal on the already-open webmail tabs and i haven't seen anything in the logs that would indicate an issue on the AMS end.

My thought is it has something to do with progression of web browsers in how they handle things like redirects and session cache vs the older tech/ciphers/web server that AMS uses for this version. But there's no obvious errors either in the browsers or AMS, so I'm not sure if it's even something I can correct or not.

[Code Crafters]

Thanks for the feedback. We'll look into it.