Note: The terms Secure Socket Layer (SSL) and Transport Layer Security (TLS) are often used interchangeably. In fact, SSL v3.1 is equivalent to TLS v1.0
- Use SSL (actually TLS v1.2 or greater) on the API endpoint.
- Do not use SSL v2, as it has know weaknesses
- SSL v3 and TLS v1 have recently been shown to have potential flaws, thus the use of TLS v1.2 or above is encouraged
Caveat: While this is true, the reality is that until OpenSSL GA's a version that supports TLS greather than version 1.0, it is not always practical. Support for TLS v1.2 is encouraged. If you cannot support TLS v1.2, then support of SSLv3 and TLS1.0 is acceptable with a road map item to TLS v1.2 when possible.
- Implement the following SSL/TLS configuration settings when selecting cipher suites:
- Use AES, 3DES for encryption
- Use key lengths of 2048 or greater
- Use cipher block chaining (CBC) mode
- Use SHA1 for digest (note that MD5 may be used within the TLS protocol, but not the SSL protocol)
- TLS usage of MD5 does not expose the TLS protocol to any of the weaknesses of the MD5 algorithm (see FIPS 140-2 IG). However, MD5 must never be used outside of TLS protocol (e.g. for general hashing).
- Do not provide support for NULL cipher suites
- Support ephemeral Diffie-Hellman key exchange (do not provide support for anonymous Diffie-Hellman)
- Use of Ephemeral Diffie-Hellman key exchange will protect confidentiality of the transmitted plaintext data even if the corresponding RSA or DSS server private key is compromised. An attacker would have to perform active man-in-the-middle attack at the time of the key exchange to be able to extract the transmitted plaintext.
- Disable support for TLS renegotiations or support only renegotiations compliant with RFC 5746
- Install a valid certificate
- Valid certificates (that is, certificates signed by a trusted Certificate Authority (CA)) can be obtained for a very low cost from providers such as GoDaddy or RapidSSL.
- The CN (common name) attribute must match the hostname part of the URL that is being requested. In other words, the CN must match the hostname in the cloud API endpoint URL, not usually the hostname of the web server.
- A valid certificate also helps prevent a man in the middle (MITM) attack
- Certificate Validation Level: We recommend Extended Validation (EV) SSL Certificates for production gateways.
- Extended Validation (EV) SSL Certificates (best): The Certification Authority (CA) checks the right of the applicant to use a specific domain name PLUS it conducts a thorough vetting of the organization. There is a strict set of validation guidelines that must be followed.
- Organization Validation (OV) SSL Certificates (better): The CA checks the right of the applicant to use a specific domain name, as well as conducts some vetting of the organization.
- Domain Validation (DV) SSL Certificates (good): The CA checks the right of the applicant to use a specific domain name. No company identity information is vetted.
Use an Extended Validation (EV) certificate. Domain Validation only SSL certificates are considered "low-validation" and use is discouraged. EV certificates have undergone more rigorous vetting, and are encouraged.
Optional: Cloud Provider and RightScale coordinate to determine if verification of the trust chain is required on each connection. If CN is equal to hostname, there is a reasonable assurance of identity, even if the certificate is not completely validated.
Optional: Perform SSL mutual authentication between the API endpoint and the RightScale systems.
- Obtain the client side certificate and validate that the client possesses a valid certificate for the *.rightscale.com domain.
IP Source filtering
While some of our customers utilize source IP filtering, RightScale does not recommend it as a mechanism for securing the API endpoint for the following reasons:
- Potential issues with auto scaling: If cloud providers restrict who can access the API endpoint by IP, they will need to have dynamic changes to their external firewall to accommodate the scaling of the RightScale platform itself.
- Potential issues with fail over: If a region fails and RightScale has to fail over to a different cloud/region, the ability to manage resources in the Cloud Provider would break until they updated the whitelist.
- Potential Compliance issues with dynamic firewall changes: Many compliance requirements require testing after any changes to firewalls. By dynamically updating the firewall access control lists, a customer may introduce gaps in the compliance program.
- Limits the timeliness of RightScale Technical Support: Many times RightScale Professional Services, Operations, or Engineering may have to troubleshoot the connection to the customer. With IP whitelisting in place, the IP addresses used in the trouble shooting need to be added to the allowed list before any testing can occur. As a policy, RightScale support does NOT use production systems (i.e., systems that are part of the platform and would be in the access list) to initiate troubleshooting from. Only RightScale Operations has access to the production systems, not Support, Professional Services, or Engineering.
- Validation of trusted sources can be done with SSL/TLS: Utilizing the mutual authentication capability in SSL/TLS, a Cloud Provider can be confident that they are communicating with a legitimate RightScale system.