Github user rafaelweingartner commented on the issue:
https://github.com/apache/cloudstack/pull/1557
Hi @Daan,
We are also not sure, that is why we have sent an email to the security
maligning list to start a discussion about that. The question regarding the
âcom.cloud.hypervisor.xenserver.resource.XenServerConnectionPool.
"TrustAllManager" class was the following.
> The code at line 77-96 is setting the default SSL socket factory for
HTTPS connection to an implementation (TrustAllManager class created at lines
483- 506) that always considers the certificate of the server valid (without
any checks). Also, at line 90, it was overridden the host name verifier (the
check that matches hostname and certificates CN) to always returns true.
We also mentioned that:
> We might be misinterpreting the java doc of methods
âjavax.net.ssl.HttpsURLConnection.setDefaultSSLSocketFactory(SSLSocketFactory)â
and
âjavax.net.ssl.HttpsURLConnection.setDefaultHostnameVerifier(HostnameVerifier)â,
but those sets seem to affect every single HTTPS request that is performed by
ACS (JVM runtime in which those methods were executed). We do not know how many
HTTPS requests, and to what extent they are essential to ACS workings, but that
code seems to make ACS vulnerable to man in the middle attacks (if it uses
HTTPS requests to execute some of its tasks).
Speculating a bit, we had an idea why that code was added:
> We believe that was done in order to allow the use of the XAPI via rest
API through HTTPS, probably because the host is using self-signed certificates.
If that is the case, I think we have better options to work around that, such
as just disabling the check for those specific requests and or using a keystore
with the hostsâ public keys that could be downloaded at the host addition
process.
In conclusion, if ACS uses an HTTPS connection to either download a file
(template or something else) or to send a command to a remote region over the
internet that connection/request may be vulnerable to MID attacks. Even though
we will have an SSL connection, we will not know with whom, because the
certificate checks were all disabled.
Again I would like to say that we do not know how many (if) ACS uses much
HTTPS request to execute some of its tasks; that is why we raised the question.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
