Karsten Otto created JAMES-3832:
-----------------------------------
Summary: Support TLS host name verification
Key: JAMES-3832
URL: https://issues.apache.org/jira/browse/JAMES-3832
Project: James Server
Issue Type: Improvement
Components: Remote Delivery
Affects Versions: master
Reporter: Karsten Otto
I recently noticed that when RemoteDelivery establishes a TLS connection, it
does not verify the remote host name against the supplied server certificate.
While this seems to be default in Java, it potentially allows attackers to fake
legitimate mail servers and intercept mail traffic. Thus server admins might
want to enable host name verification in a security sensitive deployment.
Java Mail has a boolean property for this purpose,
mail.smtps.ssl.checkserveridentity, which I can add to the RemoteDelivery
mailet configuration. However, RemoteDelivery uses the IP address to contact
remote servers by default. While it is possible to include IP addresses in a
certificate, this is rarely used in practice.
I propose to change RemoteDelivery to use host names instead of IP addresses
for contacting remote servers, in order to support host name verification if
needed. I do not see any disadvantages with such a change, but the intricacies
of server lookup are complex, and I may not see the full picture. Any reasons
why this would be a problem?
I tested the change with SocketTLS/SMTPS, and it works nicely. I do not have a
test setup for StartTLS, but from checking the code paths I believe it should
work as well, except that the configuration property will likely need to be
mail.{*}smtp{*}.ssl.checkserveridentity (not smtps) due to Java Mail property
naming weirdness.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
