• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx

  • We are developing a new feature in Plesk that will help you promote your websites or business on social media. We want to conduct a one-hour online UX test to present the prototype and collect feedback. If you are interested in the feature, please book a meeting via this link.
    Thank you in advance!
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Question About ports 465 and 587

I didn't say a MitM attack would require STARTTLS. I'm saying a MitM attack only works if there's no security on the connection at all and since Plesk requires STARTTLS on 587, the certificate validation would fail once STARTTLS was attempted to be negotiated (which occurs prior to authentication) unless either:

1. The user intentionally ignores the warning from the mail app, or
2. There's a malicious or hacked certifying authority that granted an SSL certificate to the MitM attacker that matches the hostname of the server (or the mail domain).

But these exceptions are identical for SSL/TLS over 465.

This means 587 with required STARTTLS before auth should be equally as secure as 465 with SSL/TLS.
I think you have a fundamental misunderstanding how a MitM attack works.

In case of such an attack, the attacked user wants to contact the plesk server, but instead contacts the MitM server because someone managed to tweak DNS or routing or whatever.
Now why would that MitM server tell the user's client that it requires STARTTLS?
It won't. It will just ask the client to authenticate. So if the client has no setting to never send passwords unencrypted, it will happily give its credentials to the MitM server. Which can then contact the plesk server, use STARTTLS, log in using these credentials, and relay the data to the client so the user won't notice anything.
 
I think you have a fundamental misunderstanding how a MitM attack works.

In case of such an attack, the attacked user wants to contact the plesk server, but instead contacts the MitM server because someone managed to tweak DNS or routing or whatever.
Now why would that MitM server tell the user's client that it requires STARTTLS?
It won't. It will just ask the client to authenticate. So if the client has no setting to never send passwords unencrypted, it will happily give its credentials to the MitM server. Which can then contact the plesk server, use STARTTLS, log in using these credentials, and relay the data to the client so the user won't notice anything.

Thank you for the clarification!

My understanding is that most mail clients that have already negotiated with the server a previous time will assume the same connection settings and present an error if they don't work (unless the client has an 'automatically try other settings' option). Granted that isn't a guarantee, and doesn't cover the initial setup connection. Having said that if guides all indicate to use StartTLS, at least it's somewhat mitigated by that as well, yet I fully understand that not all users will necessarily obey that config, still resulting in lesser security than 465.
 
Back
Top