This blog post is based on OWASP Transport Layer Protection Cheat Sheet, and it will provide simple rules to follow when implementing transport layer protection for an application.
Although the concept of TLS is known to many, the actual details and security specific decisions of implementation are often poorly understood and frequently result in insecure deployments.
TLS Benefits
The primary benefit of transport layer security is the protection of web application data from unauthorized disclosure and modification when it is transmitted between clients (web browsers) and the web application server, and between the web application server and back end and other non-browser based enterprise components.
The server validation component of TLS provides authentication of the server to the client.
TLS also provides two additional benefits that are commonly overlooked; integrity guarantees and replay prevention. A TLS stream of communication contains built-in controls to prevent tampering with any portion of the encrypted data. In addition, controls are also built-in to prevent a captured stream of TLS data from being replayed at a later time.
Rules for Secure Server Design
- Use TLS or Other Strong Transport Everywhere
All networks, both external and internal, must utilize TLS or an equivalent transport layer security mechanism for all communication. Lack of TLS leads to a lack of integrity which allows attackers to modify content in transit. Also, sites that do not provide TLS are marked lower in pagerank for SEO.
- Do Not Provide Non-TLS Pages for Secure Content
All pages which are available over TLS must not be available over a non-TLS connection. A user may inadvertently bookmark or manually type a URL to a HTTP page within the authenticated portion of the application. If this request is processed by the application, then the response and any sensitive data, would be returned to the user over the clear text HTTP.
- Do Not Mix TLS and Non-TLS Content
A page that is available over TLS must be comprised completely of content which is transmitted over TLS. This includes content from unrelated third party sites.
- Use «Secure» Cookie Flag
The «Secure» flag must be set for all user cookies.
- Keep Sensitive Data Out of the URL
Sensitive data must not be transmitted via URL arguments. A more appropriate place is to store sensitive data in a server side repository or within the user’s session.
- Prevent Caching of Sensitive Data
The TLS protocol provides confidentiality only for data in transit. It does not help with potential data leakage issues at the client or intermediary proxies. As a result, it is frequently prudent to instruct these nodes not to cache or persist sensitive data.
- Use HTTP Strict Transport Security
HTTP Strict Transport Security is an opt-in security enhancement that is specified by a web application through the use of a special response header.
- Use Public Key Pinning
An application which pins a certificate or public key no longer needs to depend on others – such as DNS or CAs – when making security decisions relating to a peer’s identity.
Rules for Server Certificate
- Use Strong Keys & Protect Them
The private key used to generate the cipher key must be sufficiently strong for the anticipated lifetime of the private key and corresponding certificate. The current best practice is to select a key size of at least 2048 bits.
- Use a Certificate That Supports Required Domain Names
A user should never be presented with a certificate error, including prompts to reconcile domain or hostname mismatches, or expired certificates.
- Use Fully Qualified Names in Certificates
Unqualified names, local names, or private IP addresses violate the certificate specification.
- Do Not Use Wildcard Certificates
Though they are expedient at circumventing annoying user prompts, they also violate the principal of least privilege and asks the user to trust all machines.
- Use an Appropriate Certification Authority for the Application’s User Base
The use of self-signed certificates is never acceptable. Self-signed certificates negate the benefit of end-point authentication and also significantly decrease the ability for an individual to detect a man-in-the-middle attack.
- Always Provide All Needed Certificates
A server should provide the user with all required certificates used in a path validation.
Rules for Server Protocol and Cipher Configuration
- Only Support Strong Protocols
The best practice for transport layer protection is to only provide support for the TLS protocols. This configuration will provide maximum protection against skilled and determined attackers and is appropriate for applications handling sensitive data or performing critical operations.
- Prefer Ephemeral Key Exchanges
Use cryptographic parameters that use a secure length that match to the supported keylength of your certificate.
- Only Support Strong Cryptographic Ciphers
The strength of the encryption used within a TLS session is determined by the encryption cipher negotiated between the server and the browser. In order to ensure that only strong cryptographic ciphers are selected the server must be modified to disable the use of weak ciphers and to configure the ciphers in an adequate order. It is recommended to configure the server to only support strong ciphers and to use sufficiently large key sizes.
Want to learn more?
Read the full version of the OWASP Transport Layer Protection Cheat Sheet.
This blog post is based on contents provided by OWASP, and it follows a Creative Commons Attribution ShareAlike 4.0 license.