[
https://issues.apache.org/jira/browse/JAMES-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17613283#comment-17613283
]
Benoit Tellier commented on JAMES-3832:
---------------------------------------
I think we should go further.
According to me, remote delivery have 2 use cases:
- Gatewaying: you did set up an other MX on your site to send emails to others
domains on behalf of James. James could maintain a persistent SMTP connection
to this gateway. The IP / hostname of the gateway is hard coded in James. All
is in local network, so SSL is only secondary line of defense, less crucial.
SMTPS can be setted up.
- MX mode: DNS resolution and hands over the mail to the remote domain. Third
party is unknown, and changes for every mail. No persistent connection can be
attempted. Port 25 SMTP is used, STARTTLS can opportunistically encrypt the
exchange, but there's a dilemma between delivery/security. Here we deal with
third party on the internet.
I think if a certificate is handed to us in MX mode, it needs to be seriously
validated to avoid Man In The Middle attacks. I could see people opening CVEs
on this just like they did for Netty.
Ref: https://security.snyk.io/vuln/SNYK-JAVA-IONETTY-1042268
We should expect sites on the internet to have correctly configured
certificates. Failure to do so would be a good reason NOT to deliver the mail.
Also, hobbyists that just want something to work should be able to:
- Get quickly related errors
- And turn of related configuration
> 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
> Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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
