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.
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.
Encripto values your privacy. Therefore, we do not use tracking cookies. Read our policy for more information. AcceptRejectRead More
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.