[
https://issues.apache.org/jira/browse/GEODE-8144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17113679#comment-17113679
]
ASF GitHub Bot commented on GEODE-8144:
---------------------------------------
pivotal-jbarrett commented on a change in pull request #5131:
URL: https://github.com/apache/geode/pull/5131#discussion_r429004979
##########
File path:
geode-core/src/main/java/org/apache/geode/internal/net/SocketCreator.java
##########
@@ -791,7 +792,19 @@ private boolean setServerNames(SSLParameters
modifiedParams, HostAndPort addr) {
return false;
}
- serverNames.add(new SNIHostName(addr.getHostName()));
+ String hostName = addr.getHostName();
+ if (this.sslConfig.doEndpointIdentification()
+ && InetAddressValidator.getInstance().isValid(hostName)) {
+ // endpoint validation typically uses a hostname in the sniServer
parameter that the handshake
+ // will compare against the subject alternative addresses in the
server's certificate. Here
+ // we attempt to get a hostname instead of the proffered numeric address
+ try {
+ hostName = InetAddress.getByName(hostName).getCanonicalHostName();
Review comment:
This strikes me as a security issue. Let's say I issued a start server
with `locators=1.2.3.4`, which is bad but stick with me. Then here we lookup
1.2.3.4's PTR record. What if someone has maliciously inserted themselves into
my DNS resolution path, easy to do with out greater adoption of DNSSEC. So my
reverse lookup finds `1.2.3.4 PTR locator1.malicious.com` and adds
"locator1.malicious.com" to the SNI and proceeds to connect. Then connection is
established to what our network stack thinks is 1.2.3.4, but is really our
malicious router redirecting the connection. Now the malicious host will
respond with a valid signed certificate for "locator1.malicious.com" and we
will happily verify it. Of course that assumes also that the malicious
certificate is signed by someone in our chain of trust. So, not a likely attack
vector since we don't trust the root signers by default but not something a
service that does trust the roots should ever do.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> endpoint identification in servers is not working
> -------------------------------------------------
>
> Key: GEODE-8144
> URL: https://issues.apache.org/jira/browse/GEODE-8144
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
> Reporter: Bruce J Schuchardt
> Priority: Major
>
> *update 5/20/2020*: this needs to be ported to 1.13 so it's picked up ASAP by
> TGF for VMs.
> If you enable endpoint identification in a server the server will not start.
> It will log exceptions like this:
>
> {noformat}
> javax.net.ssl.SSLHandshakeException: General SSLEngine problem
> at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1566)
> at
> sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:545)
> at
> sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1217)
> at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1185)
> at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:471)
> at
> org.apache.geode.internal.net.NioSslEngine.handshake(NioSslEngine.java:158)
> at
> org.apache.geode.internal.net.SocketCreator.handshakeSSLSocketChannel(SocketCreator.java:597)
> at
> org.apache.geode.internal.tcp.Connection.createIoFilter(Connection.java:1731)
> at org.apache.geode.internal.tcp.Connection.<init>(Connection.java:1167)
> at
> org.apache.geode.internal.tcp.Connection.createSender(Connection.java:1004)
> at
> org.apache.geode.internal.tcp.ConnectionTable.handleNewPendingConnection(ConnectionTable.java:288)
> at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:392)
> at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:571)
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:800)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:451)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:268)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:510)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2058)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1986)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:74)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1623)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3033)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:216)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:159)
> at src.EntryConsumer.initialize(EntryConsumer.java:69)
> at src.EntryConsumer.main(EntryConsumer.java:340)
> Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:198)
> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1729)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:333)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:325)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1688)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:226)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1082)
> at sun.security.ssl.Handshaker$1.run(Handshaker.java:1015)
> at sun.security.ssl.Handshaker$1.run(Handshaker.java:1012)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1504)
> at
> org.apache.geode.internal.net.NioSslEngine.handleBlockingTasks(NioSslEngine.java:225)
> at
> org.apache.geode.internal.net.NioSslEngine.handshake(NioSslEngine.java:185)
> ... 27 more
> Caused by: java.security.cert.CertificateException: No subject alternative
> names matching IP address 10.118.26.62 found
> at sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:168)
> at sun.security.util.HostnameChecker.match(HostnameChecker.java:94)
> at
> sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:462)
> at
> sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:442)
> at
> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:261)
> at
> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:144)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1675)
> ... 35 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
