cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rafaelweingartner <...@git.apache.org>
Subject [GitHub] cloudstack issue #1557: Removed unused methods from XenServerConnectionPool
Date Wed, 01 Jun 2016 15:05:36 GMT
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message