SSL/TLS Protocols Security Guidelines

Introduction

SSL/TLS¹ protocols are pervasive throughout information systems and the Internet. They protect the confidentiality of communication. HTTPS protocol is one of the more common applications that make use of SSL/TLS for encrypting communication between browsers and websites². A typical example is that to make sure the confidentiality and integrity of an online transaction. However, vulnerabilities exist in some SSL/TLS protocol versions. If they were configured improperly, the information security risks will increase.

Instruction: Use the “Check-Remedy-Verify” approach to secure your website’s SSL/TLS deployment.

This guideline is divided into 2 parts. Part 1 of this guideline is “Check”, which introduces how to use free tools to “Check” website’s SSL/TLS protocols and configuration. You will get a security ranking and a test report upon test completion. Then you can pass the testing report to the technical staff to perform the remediation.

Part 2 is “Remedy”, which introduces how to secure SSL/TLS and related suggested configuration. To improve the SSL/TLS security ranking of your website, technical staffs can “Remedy” the vulnerable settings by following the advices. After that, you can “Verify” the improvement on SSL/TLS security by rerunning the same checking in part 1.
 


Note: this guideline quotes information of SSL Labs³ and information of SSL Pulse⁴ when analyzing the security of SSL/TLS implementation.
 

Security risks of SSL/TLS protocols

SSL/TLS has been around for a long period of time. The older version, SSL3.0, which was released in 1996, is plagued with multiple known vulnerabilities. Some well-known vulnerabilities are POODLE, Heartbleed and FREAK⁷. Furthermore, improper configuration is another source of security risks and it may cause data breaches and network attacks. To mitigate these security risks, we must use secure SSL/TLS protocols and ensure they are configured according to the best practice.

Note: This security guideline revolves around advice regarding SSL/TLS over the HTTP application.

HKCERT analyzed common security problems in using SSL/TLS according to the data collected by the SSL Pulse project⁶ from the first publish date of project (April 2012) to 7th May 2015 . It was discovered that more than three quarters of tested websites were rated “Inadequate security” (B or below) in the QUALYS SSL Server Test. Moreover, only a quarter of websites were rated ‘A’ in the aforementioned test. This indicated that there are huge margins for improvement and that the security of SSL/TLS implementation in websites is a huge concern.
 

Part 1: How to test SSL/TLS protocol and configuration

The traditional approach to check the configuration of SSL/TLS protocol is through manual test. The tester has to be equipped with relevant knowledge. Because the lack of knowledge and technical skill, many people probably give up.

Now, there are many online test service websites providing SSL/TLS protocol and configuration test. The test can be done with simple steps: entering URL of the website which is going to be tested; clicking to agree to the terms and conditions; pressing “Start” button to perform the automated test. Then you can wait for the report. You don’t need to be an expert to do this. You can run the test and pass the report to the technical staff to fix it. You can run the same test later to verify if there are any improvements.
 

Here are some popular tools for SSL/TLS configuration test^#:

Web server testing tools:

• COMODO SSL Analyzer
  https://sslanalyzer.comodoca.com/
• QUALYS SSL Server Test
  https://www.ssllabs.com/ssltest/
• Symantec SSL Certificate Installation Checker
  https://cryptoreport.websecurity.symantec.com/checker/

Email server testing tools:

• SSL-Tools (Test SSL/TLS configuration of email server)
  https://ssl-tools.net/mailservers
• Check TLS (safe email testing tool and service)
  http://www.checktls.com/

Here we introduce Qualys SSL Server Test, which is a well-recognized SSL/TLS testing tool in the HTTP market.
https://www.ssllabs.com/ssltest/

This tools not only let you understand the SSL/TLS ranking of your website configuration, but also provide detail report and corresponding self-help instruction to upgrade the security ranking of your website.

Step 1. Input the URL in the “Domain name” field. If you don’t want the test result goes public, ticks the check box. Lastly, click the submit button to perform the test.


Step 2. Test is in progress. Please wait.


Step 3. This is the test report. Different colours will be used if problem is found. You can also check the detail explanation to fix the configuration.


How to be an “A” grade website?
You can achieve  “A” grade by configuring your web server according to part 2 of this guideline.
Note: assume that basic SSL/TLS configuration have been configured successfully.
 

Part 2: Secure use SSL/TLS and related suggested configuration
 

1.    Apply basic protection

Some basic protections that are crucial for the SSL/TLS communication security protocol are often ignored.

-    Update systems regularly
Regular system updates can fix most known SSL/TLS vulnerabilities, e.g. the Heartbleed vulnerability in OpenSSL⁸ and the insecure renegotiation vulnerability in SSL/TLS⁹.

-    Use newer software and protocol
Normally, newer software are able to support certificates that are signed with stronger hash algorithm¹⁰, more secure TLS protocols and support more secure cipher suites. Thus, website owners and administrators should use most updated software and protocol in operating systems, network devices or browsers, in order to support a safer security configuration.

2.    Use secure digital certificates
As the computing power and memory of computers are exponentially increasing, breaking older encryptions has become much easier. To combat the increasing risk, some certificate authorities have adopted 2048-bit (key length) certificate and used SHA2/SHA-256 as the default hash algorithm, replacing 1024-bit (key length) certificate and SHA1.

-    Use newer SHA2/SHA-256 certificate
According to the data from SSL Pulse, around half of the websites are still utilizing certificates signed with SHA1⁶. Due to security concern, updated browsers will NOT support certificate that was signed by SHA1 hash algorithm. If your website still uses certificate signed by SHA1, it will be recognized as invalid and treated as unsafe¹¹. To minimize the impact to user, HKCERT suggests website owner/ administrator to renew their certificates to 2048-bit (key length) and signed by SHA2 as soon as possible.

-    Ensure the completeness of the certificate chain
In addition to having a secure digital certificate, completeness of certificate chain is important. Malformed certificate chain can not only disrupt the function of certificates, but may also make your website looking like a phishing website. To have a complete certificate chain, website administrators need to import the root certificate and/or intermediate certificates into the server with proper configuration. For more details, please visit the websites of certificate authorities¹².

3.    Deploy “Forward Secrecy”
Forward secrecy can enhance the confidentiality of transmission. It ensures that the secret key used to perform encryption is independent and is validate only for a short-term for each transmission. Even if the secret key used before is stolen, the eavesdropper will be unable to decrypt the transmission¹³.

According to the SSL Pulse report, around one fifth of websites have turned on forward secrecy and supported most browsers⁶. It can be seen that many websites do not support forward secrecy. They may be risky. To achieve forward secrecy, website administrators and owners should adapt the following configuration.

-    Use safer SSL/TLS protocol versions
Some of the old SSL/TLS protocol may cause security risks. From an earlier security blog published by HKCERT [/my_url/blog/15012902], SSL3.0 contains the POODLE security vulnerability and is unsafe. The current TLS1.2 is the most secure version of SSL/TLS. As TLS1.0 is still popular, HKCERT suggests website owners and administrators to use TLS1.2 and offer backwards compatibility for TLS1.1 and TLS1.0. Nonetheless, for security reasons, SSL3.0 and previous versions should not be supported. Please note that the server side should also use the following order when negotiating with users: TLS1.2 > TLS1.1 > TLS1.0 – which implies that a newer version of TLS is enforced to use if it is available¹⁴. For the status of SSL/TLS protocol versions, please refer to the following table¹⁴:
 

-    Use safe cipher suites
As the computing power keep growing, the older cipher suites used weak encryption algorithms are not as safe as before. They may lead to increasing risk of information leakage. Earlier in 2013, research indicated that the RC4 cipher suite does not achieve the current security standards^15,16. According to SSL Pulse, around half of websites were still using RC4 cipher suites⁶. Thus, HKCERT suggests that website administrators to use safer cipher suites based on stronger encryption algorithm as primary suite e.g. ECDHE, AES 256. For those less secure cipher suites that are still popular, they should be configured as secondary suite, e.g. SHA1. But please stop using cipher suites with insecure algorithms e.g. MD5, RC4.¹⁷
 

Note: a newer version is enforced to use if it is available e.g. Use AES256 first, use AES128 ONLY if AES256 can’t be used.

Here is an example of cipher suites configuration and their ordering. In order to be compatible with most users, this configuration balances the confidentiality and availability.

Note: cipher suites on the top take precedence over those at the bottom

Note: In addition to the safe cipher suites configuration on the server side, cooperation from the user side (browser and OS) must also be adapted to ensure the confidentiality of data. Most of the newer browsers and operation systems can support the cipher suites required by the Forward Secrecy¹⁸.
 

4.    Other suggestion of SSL/TLS configuration
-    Disable SSL/TLS compression settings on server side
Only a small amount of clients support SSL/TLS compression. However, using SSL/TLS compression is susceptible to CRIME attacks, which causes leakage of sensitive information¹⁹. HKCERT suggests disabling SSL/TLS compression on the server side.

-    Implement HTTP Strict Transport Security (HSTS)
HSTS²⁰ (RFC6797) is a server-side setting which forces client to use SSL/TLS in the transmission to ensure the confidentiality.
For example, assume that the web server of www.hkcert.org have implemented HSTS. Once a user enters http://www.hkcert.org in the browser (client side), that request will be redirected to https://www.hkcert.org by the server. The prerequisite is that the client must support HSTS as well, otherwise an error message will be shown in the client side²¹. Newer browsers already support HSTS.

Due to the increasing attention on information security, https secure connection will become more popular in the near future, while HSTS implementation will also become important.

-    Implement HTTP Public Key Pinning
HTTP Public key pinning (HPKP)²² is a server side configuration. The client (e.g. browser) checks whether the public key of a particular digital certificate has been altered before transferring data. This let user distinguish whether the digital certificate is genuine ²³. When a browser first visits a website which has implemented HPKP, it will cache the public key of this website certificate. If an attacker tries to perform man-in-the-middle attack e.g. pretending as a phishing HTTPS website, which intends to intercept the encrypted transmission, the browser will be able to discover that the public key of certificate from the attacker is different from the one it cached. The browser will then terminate the transmission with the phishing website. As a result, HPKP can provide point to point encrypted protection, to prevent users accessing phishing website that uses malicious digital certificate registration from the other CA.

HPKP is not as popular as other configurations introduced above. They may not be compatible with legacy browsers²⁴. HKCERT suggests users to consider HPKP according to their needs. Users should also configure HPKP carefully, making sure to consider different scenarios and corresponding solutions, for instance, how to handle certificate renewal/ revocation and loss of the private key. For detail, please refer to the server configuration document.
 

Note: HKCERT suggests website administrator to plan comprehensively and evaluate the impact of changes before implementing any configuration change (including HSTS, HPKP)

Reference

1. TLS is the new generation of SSL protocol, it provides better confidentiality.
2. Normally, the application of SSL/TLS in the WWW is called HTTPS. And the applications of SSL/TLS in email are POP3S, SMTPS and IMAPS.
3. SSL Labs is a non-commercial research project of Qualys. It aims to improve the implementation of SSL protocols and increase the SSL awareness for general public.⁵
4. SSL Pulse is a project which makes use of assessment technology of SSL Labs. The first publish date was on April 25 2012 and it keeps updating periodically. SSL Pulse monitors the implementation of SSL across famous web sites. Its goal is to facilitate website owner/administrator to keep improving the implementation of SSL.⁶
5. https://www.ssllabs.com/
6. https://www.trustworthyinternet.org/ssl-pulse/
7. https://en.wikipedia.org/wiki/Transport_Layer_Security
8. http://heartbleed.com/
9. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555
10. http://www.hongkongpost.gov.hk/support/faq/index_c.html#P2
11. http://www.symantec.com/page.jsp?id=sha2-transition
12. https://hongkongpost.gov.hk/product/download/root/index.html
13. http://en.wikipedia.org/wiki/Forward_secrecy
14. https://www.rfc-editor.org/rfc/rfc7525.txt
15. https://tools.ietf.org/html/rfc7465
16. http://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2868725-recommendation-to-disable-rc4.aspx
17. http://www.cisco.com/c/en/us/about/security-center/next-generation-cryptography.html
18. https://www.ssllabs.com/ssltest/clients.html
19. https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls
20. https://www.owasp.org/index.php/HTTP_Strict_Transport_Security
21. https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
22. https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
23. https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
24. https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning
25. https://timtaubert.de/blog/2014/10/http-public-key-pinning-explained/
26. https://raymii.org/s/articles/HTTP_Public_Key_Pinning_Extension_HPKP.html

^#Disclaimer:
HKCERT does not endorse specific vendor products or services. Inclusion of products or services in this reference list does not indicate endorsement by HKCERT. Tools are listed with no quality rating. The tools in this list are owned by tool developers or vendors and they can be modified any time. HKCERT does not verify the accuracy of these tools. If you have any question about these tools, please direct contact tool developers or vendors.