• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • We are looking for U.S.-based freelancer or agency working with SEO or WordPress for a quick 30-min interviews to gather feedback on XOVI, a successful German SEO tool we’re looking to launch in the U.S.
    If you qualify and participate, you’ll receive a $30 Amazon gift card as a thank-you. Please apply here. Thanks for helping shape a better SEO product for agencies!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

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