A Guide to a Safer HTTPS Environment
By MONITORAPP Product Management Division Senior General Manager: Hocheol Park
The web has become a part of everyday life and can be used anytime, anywhere. However, it is open to the public and popular websites become easy targets because they have the potential to infect many visitors. Typical technical measures to protect the web servers include secure coding and WAF solutions. However, in this article instead of discussing techniques or security solutions, I will be discussing HTTPS security settings needed for the webserver operation.
- Building a secure HTTPS environment
Due to the changed market perception and cultural reception, there is no need to emphasize the importance of adopting HTTPS.
Most well-known websites, whether it’s for business or personal use, have adopted HTTPS. However, when you look at the statistic, although slight discrepancies exist between different research institutions, the HTTPS adoption rate is between 60-65%. This means there are still 35-40% of websites operating without HTTPS.
The main reasons for not using HTTPS can be due to the cost of hiring a specialist and issuing certificates, which might not make sense for smaller businesses. However, using Let’s Encrypt (
https://letsencrypt.org/), a non-profit internet security research group (ISRG), which provides free certificates, and renewal service (including automatic renewal service), can significantly relieve the burden of HTTPS adoption.
However, just because the certificate is installed and the web browser connects to “
https://wesiteaddress,” that doesn’t mean the process is complete. Here are some of the essentials steps to take to make a secure website.
Before we start, there exists several security settings can be used but will not be mentioned in this article such as CORS, HTTP only, and X-XSS-protection. Qualys SSL Labs (https://www.ssllabs.com/ssltest/) and Mozilla Observatory (https://observatory.mozilla.org/) provide free diagnostics and guides to additional information regarding diagnostic results. We hope these resources will help you with additional server security.
- The use of RSA 2,048 bit level private key (or ECC 225bit)
Regardless of where the certificate was issued from, Let’s Encrypt or a private organization, we recommend the length of 2,048 bit for RSA type and 224 bit for ECC type. The longer the length, the stronger the security but it negatively correlates with the webserver’s system performance so selecting an appropriate key length is important. In the past, 1024 bit key was enough but considering the current CPU processing power, it can be decrypted using calculations so we do not recommend using a private key shorter than the recommended lengths.
HTTPS protocol can be divided into two large categories which are SSL (SSL 2.0, 3.0) and TLS (TLS 1.0, 1.1, 1.2, 1.3). SSL 2.0 was discontinued in 2011 and the same for SSL 3.0 in 2015. TLS 1.0 and TLS 1.1. has also discontinued in the first half of 2020 (discontinued by most manufacturers from March 2020). This is due to their POODLE and BEAST vulnerabilities and they are no longer considered secure. If you are using HTTPS for security reasons, it is recommended to use TLS 1.2 and TLS 1.3.
Since the latest versions of the well-known browsers do not support the weak SSL/TLS version or are disabled by default, enabling only TLS 1.2 or higher protocol does not affect general web services. However, if the clients accessing the web site (or web application service) are using old terminals or have software, API, and SDK-based applications other than a general browser (for example, health check packets of specific network devices, CS programs, etc.), the service might not work properly since TLS 1.2 and TLS 1.3 are not supported. In this case, rather than enabling TLS 1.0 and TLS 1.1 on the server for service availability, it is better to modify the client-side to use the TLS 1.2 or higher protocols.
- Disable vulnerable cipher-suite list
Disable “Anonymous Diffie-Hellman, eNull, RC4, 3DES” Cipher-Suite or place ECDHE and DHE, which are PFS (or FS) cipher-suite, at the top of the list.
In SSL/TLS negotiation (handshake), along with the encryption protocol version, there is a cipher-suite, which is also an important factor in determining security strength. Simply put, it is a set of cryptographic algorithms used for negotiation between a client and a server.
When negotiating between a client and a server, there is an option to select which side will have the priority to pick the cipher-suite. Even if the server-side has a strong level of cipher-suite, if the client has the priority to select the cipher-suites, the negotiation might be done using the low strength encryption.
For the priority option settings, the highest market share web application server and encryption libraries have different names. For apache, it’s called SSLHonorCipherOrder, for Nginx, it’s called ssl_prefer_server_ciphers, and for OpenSSL, it’s called SSL_OP_CIPHER_SERVER_PREFERENCE. It’s recommended to enable the above options to negotiate with clients with ECDHE or DHE type, which are PFS (or FS) cipher-suites.
If an attacker intercepts or stores the encrypted communication along with the private key, between the client and the server, the private key can be used to decrypt all previously-stored ciphertexts (of course if the key is not exposed then the ciphertexts are impossible to decrypt). PFS (Perfect Forward Secrecy) is a feature that stops the decryption of the stored ciphertexts even if the private key is exposed. In other words, it allows the decryption of the text-only data between the communicating terminals (sessions). PFS is a great option to keep the ciphertext encrypted even when the private key is exposed.
To give an idea of how PFS works. In the case of recorded TCPDUMP on Wireshark (which are often used by the IT engineers), communicated using RSA cipher-suite, the decrypted PLAIN data can be viewed once you insert the private key. However, if you use DH or ECDHEH cipher-suite, which provide PFS, the data cannot be decrypted even with the private key.
This is also the reason why all SSL visibility solutions currently available in the market are deployed and operated as a proxy that directly intervenes in the session (also called MITM). This is because only the subjects of the communication (session) can decrypt DH or ECDHE cipher suites.
- HSTS(HTTP Strict Transport Security) Activation
HSTS is making HTTPS connection mandatory on the client’s browser so that HTTPS connection is forced from the initial connection. Depending on the browser type, the HSTS URL list preloaded, and the browser learns and manages the corresponding HSTS URL list according to the server’s response header (Strict-Transport-Security). For example, if the website
www.monitorapp.com responds to the client’s request with the header including “Strict-Transport-Security: max-age=31536000; includeSubDomains” then that browser has now learned to connect to *.monitorapp.com with HTTPS for 1 year. “includeSubDomains” means applying HSTS to the subdomains as well.
HSTS’s main motive is to respond to MITM attacks. Normally, encrypted sessions are secure even when an attacker peaks in because the data is encrypted. However, if the initial request is connected with HTTP, then SSL Strip becomes a possibility.
The web server is providing service with HTTPS so the server and the attacker maintain HTTPS connection, but the attacker and the client are connected through HTTP so any sensitive information logged by the client and all data between the server and the client is exposed.
In summary, HSTS is an option to disable the attacker's SSL strip in the middle by forcing the connection to be made via HTTPS from the first request.
A web cookie has been around for a long time and has become an essential part of the web. Its application is becoming more widespread. All web servers (not limited to languages like ASP, JSP, and PHP) can exchange cookies through HTTP and HTTPS, and cookies can be accessed and managed by the client. A cookie can be created from both the server and the client-side and the browsers learn from the established cookies and any response thereafter contain those cookies. The server understands the cookies included in the browser’s request and responds accordingly to the client. Many websites contain login information, personal information, and other sensitive information within the cookies so attackers use session high jacking and XSS to steal these cookies.
If all requests and responses are done via HTTPS, then the cookies are encrypted so even if it’s leaked, no damage can be done. However, web server response pages contain many links and if the developer made a mistake and added a link to HTTP through a hardcoding page (<img src="http://www.monitoprapp.com/images/top.jpg">), then the browser will connect to that URL via HTTP and not HTTPS (additional HTTP session is created regardless of the previous HTTPS session). Hence, the cookie is exposed to the network and it is difficult to realize this leak.
In conclusion, Secure Cookie is an option to prohibit hackers from eavesdropping on the network by sending cookies to the server (only in case of HTTPS communication between the web browser and the webserver).
