You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Benno Evers (JIRA)" <ji...@apache.org> on 2019/06/25 13:38:00 UTC

[jira] [Created] (MESOS-9863) Libprocess SSL tests may fail client certificate validation

Benno Evers created MESOS-9863:
----------------------------------

             Summary: Libprocess SSL tests may fail client certificate validation
                 Key: MESOS-9863
                 URL: https://issues.apache.org/jira/browse/MESOS-9863
             Project: Mesos
          Issue Type: Bug
            Reporter: Benno Evers


In the current libprocess `ssl_tests.cpp`, we create a "valid" server certificate containing the hostname returned by ::getnameinfo() for the IP of `libprocess::address()`. The libprocess IP is by default determined by a DNS lookup for the current hostname.

As an example, let's assume my hostname is `poincare` and the libprocess IP is `127.0.1.1`.

The tests then spawn the `ssl-client` binary as a subprocess passing the server IP as a command-line argument. The `ssl-client` binary will connect to the passed IP. Since we do not bind() before calling connect, the source IP for that connection will be automatically determined by the kernel.

Continuing the example, the `ssl-client` connects to 127.0.1.1. Since it is a loopback address, the kernel will automatically select 127.0.0.1 as the source IP.

On the server side, libprocess will now do a reverse DNS lookup on the source  IP to determine the hostname of the connecting client. If it doesnt match the provided client certificate, the connection is rejected.

In the example, libprocess will determine (127.0.0.1, 'localhost') as source ip/hostname, but the certificate contains (127.0.1.1, 'poincare'). Therefore, the connection attempt is rejected.


Possible solutions to this include binding before calling connect to fix the source ip, or only running these tests with the 'openssl' hostname validation scheme after the corresponding review chain has landed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)