[GitHub] cloudstack issue #1557: Removed unused methods from XenServerConnectionPool

[rafaelweingartner <gi...@git.apache.org>]

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 \u201ccom.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 \u201cjavax.net.ssl.HttpsURLConnection.setDefaultSSLSocketFactory(SSLSocketFactory)\u201d and \u201cjavax.net.ssl.HttpsURLConnection.setDefaultHostnameVerifier(HostnameVerifier)\u201d, 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\u2019 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.
---