He-Pin opened a new pull request, #3164:
URL: https://github.com/apache/pekko/pull/3164
### Motivation
Classic remoting's `ConfigSSLEngineProvider.createSSLEngine()` never calls
`setEndpointIdentificationAlgorithm`, meaning TLS certificate hostname
verification is not performed on the remote peer's certificate — even when
mutual authentication is enabled. An attacker with any certificate signed by a
trusted CA could perform a man-in-the-middle attack.
Artery's `ConfigSSLEngineProvider` already supports hostname verification
via a configurable option (default off). Classic remoting has no equivalent.
### Modification
- `SSLSettings`: add `hostname-verification` config option (default off for
backward compatibility)
- `SSLEngineProvider` trait: add `createClientSSLEngine(hostname, port)`
default method for backward compatibility
- `ConfigSSLEngineProvider`: implement hostname-aware engine creation with
`setEndpointIdentificationAlgorithm("HTTPS")` when enabled
- `NettyTransport`: pass remote address hostname to SSL handler on client
side when hostname verification is enabled
- `NettySSLSupport`: accept optional hostname/port parameters
### Result
Classic remoting can now optionally verify TLS certificate hostnames,
matching Artery's behavior. Disabled by default for backward compatibility.
Enable with:
```hocon
pekko.remote.classic.netty.ssl.security {
hostname-verification = on
}
```
### Tests
- `sbt "remote / Test / testOnly
org.apache.pekko.remote.Ticket1978ConfigSpec"` — verified hostname-verification
defaults to off and can be enabled
### References
Fixes #3161
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
