Skip to content

guide security quick S9 Basic Communication Security

jorge dacal cacantos edited this page May 29, 2018 · 1 revision

S9 Basic Communication Security

This package describes basic communication security controls.

S9-1

A path can be built from a trusted CA to each Transport Layer Security (TLS) server certificate, and that each server certificate is valid.

Purpose: Valid certificates on the path mitigate the threat of Man in the Middle (MitM) attacks.

Solution: Buy certificates from the official RA (Registration Authority) or go for Let’s Encrypt if possible. Deploy the certificates properly. If the work has been done properly can be manually checked via SSL Labs (host available in internet) or Test SSL (host not available in internet).

S9-2

TLS is used for all connections (including both external and backend connections) that are authenticated or that involve sensitive data or functions, and does not fall back to insecure or unencrypted protocols. Ensure the strongest alternative is the preferred algorithm.

Purpose: TLS offers message confidentiality, integrity and sever authentication. If you don’t use TLS, you don’t have any of them.

Solution: Use TLS. Everywhere.

S9-3

HTTP Strict Transport Security headers are included on all requests and for all subdomains, such as Strict-Transport-Security: max-age=15724800; includeSubdomains.

Purpose: Even if the application uses TLS, it is a common practice to deploy the application on both port 80 (HTTP, not TLS) and 443 (HTTPS). This can lead to multiple problems like:

  • To access the application the user inputs an URL like myapplication.com. The user agent fires a HTTP request on port 80 with URL http://myapplication.com. The server will most probably redirect it with response 301 to https://myapplication.com (clear mistake if it does not). Still, the redirect leaves a hole for the attacker to catch the request and redirect it elsewhere due to in inexistent server authentication.

  • Due to a DEV mistake the application loads JS files from the server over HTTP, even though the REST requests are TLS protected introducing mixed content problems.

Solution: HTTP Strict Transport Security (HSTS) header will register the given domain as a STS domain on the user agent (browser) for the defined period of time (15724800 seconds = 182 days). The browser will then make an internal redirect (307) for every HTTP call going to this domain or any subdomain (if includeSubdomains turned on).

Note
This actually means, that you can’t go back to HTTP any more, as the user agent will not allow HTTP calls any more.

Spring Security offers a quick and easy way to turn HSTS on.

S9-4

Forward secrecy ciphers are in use to mitigate passive attackers recording traffic.

Purpose: A passive attacker might choose to record all TLS encrypted traffic waiting for an opportunity to steal the private key from the server. This would normally expose all past communication between the client and the server.

TLS 1.2 introduces the idea of (perfect) forward secrecy ciphers, which prevent previous communication from being exposed if the certificate leaks. The ciphers use the Diffie Hellman key exchange algorithm to negotiate the encryption key between two parties every time a new TLS session is started. This key remains a secret even if the attacker comes into the possession of the servers private key.

Solution: Make sure you have TLS 1.2 turned on. Make sure, you have support for DHE or ECDHE ciphers in your configuration. Test your configuration with SSL Labs (host available in internet) or Test SSL (host not available in internet) to make sure this is really the case.

S9-5

Proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured.

Purpose: How does the client make sure, that the servers certificate is still valid? It must contact the CA and ask, if the certificate has been revoked or not. This reveals to the CA, that the client wants to access a specific server. This is an information leak. OCSP stapling is meant to prevent it

S9-6

Only strong algorithms, ciphers, and protocols are used, through all the certificate hierarchy, including root and intermediary certificates of your selected certifying authority.

Purpose: Chain is only as strong as the weakest link.

Solution: Test your configuration with SSL Labs (host available in internet) or Test SSL (host not available in internet) to make sure the configuration is ok. Make configuration changes if necessary.

S9-7

TLS settings are in line with current leading practice, particularly as common configurations, ciphers, and algorithms become insecure.

Purpose: Chain is only as strong as the weakest link.

Solution: Test your configuration with SSL Labs (host available in internet) or Test SSL (host not available in internet) to make sure the configuration is ok. Make configuration changes if necessary.

Clone this wiki locally