• Hi, Pleskians! We are running a UX testing of our upcoming product intended for server management and monitoring.
    We would like to invite you to have a call with us and have some fun checking our prototype. The agenda is pretty simple - we bring new design and some scenarios that you need to walk through and succeed. We will be watching and taking insights for further development of the design.
    If you would like to participate, please use this link to book a meeting. We will sent the link to the clickable prototype at the meeting.
  • Our UX team believes in the in the power of direct feedback and would like to invite you to participate in interviews, tests, and surveys.
    To stay in the loop and never miss an opportunity to share your thoughts, please subscribe to our UX research program. If you were previously part of the Plesk UX research program, please re-subscribe to continue receiving our invitations.
  • 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.

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