Transport Layer Protection Cheat Sheet
- 1 Introduction
- 2 Providing Transport Layer Protection with SSL/TLS
- 2.1 Benefits
- 2.2 Basic Requirements
- 2.3 SSL vs. TLS
- 2.4 When to Use a FIPS 140-2 Validated Cryptomodule
- 2.5 Secure Server Design
- 2.5.1 Rule - Use TLS for All Login Pages and All Authenticated Pages
- 2.5.2 Rule - Use TLS on Any Networks (External and Internal) Transmitting Sensitive Data
- 2.5.3 Rule - Do Not Provide Non-TLS Pages for Secure Content
- 2.5.4 Rule - Do Not Perform Redirects from Non-TLS Page to TLS Login Page
- 2.5.5 Rule - Do Not Mix TLS and Non-TLS Content
- 2.5.6 Rule - Use "Secure" Cookie Flag
- 2.6 Server Certificate & Protocol Configuration
- 2.7 Client (Browser) Configuration
- 2.8 Additional Controls
- 3 Providing Transport Layer Protection for Back End and Other Connections
- 4 Related Articles
- 5 Authors and Primary Editors
This article provides a simple model to follow when implementing transport layer protection for an application. Although the concept of SSL is known to many, the actual details and security specific decisions of implementation are often poorly understood and frequently result in insecure deployments. This article establishes clear rules which provide guidance on securely designing and configuring transport layer security for an application. This article is focused on the use of SSL/TLS between a web application and a web browser, but that we also encourage the use of SSL/TLS or other network encryption technologies, such as VPN, on back end and other non-browser based connections.
For each security model, there are several security considerations which must be properly addressed in order to provide effective transport layer security. This security cheat sheet will focus on security considerations when the SSL/TLS model is selected. This is a frequently used model for publicly accessible web applications and many thick client applications.
Providing Transport Layer Protection with SSL/TLS
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. If configured to require client side certificates, TLS can also play a role in client authentication to the server. However, in practice client side certificates are not often used in lieu of username and password based authentication models for clients.
It should be noted that TLS provides the above guarantees to data during transmission. TLS does not offer any of these security benefits to data that is at rest. Therefore appropriate security controls must be added to protect data while at rest within the application or data stores.
The basic requirements for using TLS are: access to a Public Key Infrastructure (PKI) in order to obtain certificates, access to a directory or an Online Certificate Status Protocol (OCSP) responder in order to check certificate revocation status, and agreement/ability to support a minimum configuration of protocol versions and protocol options for each version.
SSL vs. TLS
The terms, Secure Socket Layer (SSL) and Transport Layer Security (TLS) are often used interchangeably. SSL v3.1 is equivalent to TLS v1.0. Different versions of SSL and TLS are supported by modern web browsers and by most modern web frameworks and platforms. For the purposes of this cheat sheet we will refer to the technology generically as TLS. Recommendations regarding the use of SSL and TLS protocols can be found in the rule below title "Only Support Strong Protocols"
When to Use a FIPS 140-2 Validated Cryptomodule
If the web application may be the target of determined attackers (for example, if it is accessible on the Internet), it is strongly advised to use TLS services that are provided by FIPS 140-2 validated cryptomodules that are operating in either an approved or an allowed mode of operation. Simply put, using a FIPS 140-2 validated cryptomodule provides a greater chance that the cryptomodule is providing the services that you are expecting from it.
- Components that implement cryptographic algorithms (symmetric and asymmetric algorithms, hash algorithms, random number generator algorithms, and message authentication code algorithms)
- Components that call and manage cryptographic functions (inputs and outputs include cryptographic keys and so-called critical security parameters)
- A physical container around the components that implement cryptographic algorithms and the components that call and manage cryptographic functions
The security of a cryptomodule and its services (and the web applications that call the cryptomodule) depend on the correct implementation and integration of each of these three parts.
While most developers understand that implementing cryptographic algorithms correctly is a hard thing to do, many do not realize that calling and managing cryptographic functions and their inputs and outputs, and ensuring the secure construction of the physical container around the components, are equally important in determining the security of a cryptomodule and its services. These are the things that FIPS 140-2 compliance helps with.
In order to leverage the benefits of TLS it is important to use a TLS service (e.g. library, web framework, web application server) which has been FIPS 140-2 validated. Furthermore, the TLS service must be used according to its FIPS 140-2 security policy. This means installing, configuring, and operating the TLS service in either an approved or an allowed mode.
Secure Server Design
Rule - Use TLS for All Login Pages and All Authenticated Pages
The login page and all subsequent authenticated pages must be exclusively accessed over TLS. The initial login page, referred to as the "login landing page", must be served over TLS. Failure to utilize TLS for the login landing page allows an attacker to modify the login form action, causing the user's credentials to be posted to an arbitrary location. Failure to utilize TLS for authenticated pages after the login enables an attacker to view the unencrypted session ID and compromise the user's authenticated session.
Rule - Use TLS on Any Networks (External and Internal) Transmitting Sensitive Data
All networks, both external and internal, which transmit sensitive data must utilize TLS or an equivalent transport layer security mechanism. It is not sufficient to claim that access to the internal network is "restricted to employees". Numerous recent data compromises have shown that the internal network can be breached by attackers. In these attacks, sniffers have been installed to access unencrypted sensitive data sent on the internal network.
Rule - 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. An attacker executing a man in the middle attack may modify a user's request such that the requested URL is no longer HTTPS but instead HTTP. The attacker could then view all of the user's data as they communicate with the site over unencrypted HTTP.
Rule - Do Not Perform Redirects from Non-TLS Page to TLS Login Page
A common practice is to redirect users that have requested a non-TLS version of the login page to the TLS version (e.g. http://site.com/login redirects to https://site.com/login). Unfortunately, this practice creates an additional attack vector. A man-in-the-middle attack enables the attacker to intercept the redirect response and modify or replace the redirection with a site of the attacker's choosing. This allows the attacker to easily perform phishing attacks or inject scripts or malicious content into the page returned to the user.
Ultimately, this issue is the responsibility of the user since the website cannot prevent the user from initially typing http://site.com/login (versus https).
The most secure recommendation is to display a security warning message to the user whenever the non-TLS login page is requested. This security warning should urge the user to always type "HTTPS" into the browser or bookmark the secure login page. This approach will help educate users on the correct and most secure method of accessing the application.
Rule - Do Not Mix TLS and Non-TLS Content
A page that is available over TLS must not contain any content that is provided over unencrypted HTTP, including content from unrelated third party sites. Even if the primary page is available over TLS, an attacker could intercept the non-TLS portion and inject malicious content into the user's page, or steal the user's session cookie that is transmitted with any non-TLS requests (if the cookie's 'secure' flag is not set. See the next rule.).
Rule - Use "Secure" Cookie Flag
Server Certificate & Protocol Configuration
Note: If using a FIPS 140-2 cryptomodule defer to the recommended configuration for the particular cryptomodule.
Rule - Use an Appropriate Certificate Authority for the Application's User Base
An application user must never be presented with a warning that the certificate was signed by an unknown or untrusted authority. The application's user population must have access to the public certificate of the certificate authority which issued the server's certificate. For Internet accessible websites, the most effective method of achieving this goal is to purchase the TLS certificate from a recognize certificate authority. Popular Internet browsers already contain the public certificates of these recognized certificate authorities.
Internal applications with a limited user population can use an internal certificate authority provided its public certificate is securely distributed to all users. However, remember that all certificates issued by this certificate authority will be trusted by the users. Therefore, utilize controls to protect the private key and ensure that only authorized individuals have the ability to sign certificates.
Rule - 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. It is recommended to configure the server to only support strong ciphers and to use sufficiently large key sizes. In general, the following should be observed when selecting CipherSuites:
- Use AES, 3DES for encryption
- Use CBC mode
- Use SHA1 for digest
- MD5 may be used within the TLS protocol
- Do not provide support for NULL ciphersuites
- Do not provide support for anonymous Diffie-Hellman
Rule - Only Support Strong Protocols
In situations where lesser security requirements are necessary, it may be acceptable to also provide support for SSL 3.0. It should be noted that this configuration is a derivation from the best practice and should only be used if the ensuing security risks are evaluated and can be accepted for the particular business operation.
In no situation should SSL 2.0 be enabled on the server. This protocol has multiple known weaknesses and does not provide effective transport layer protection.
- Internet Explorer in IE7 (also supported in IE6, but disabled by default)
- Firefox 2.0
- Chrome 1.0
- Apple Safari (version unknown)
- Opera 5
Rule - 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. Keys of length 1024 will be obsolete beginning in 2010. Additional information on key lifetimes and comparable key strengths can be found in NIST SP800-57. In addition, the private key must be stored in a location that is protected from unauthorized access.
Rule - Use a Certificate That Supports All Available Domain Names
A user should never be presented with a domain mismatch certificate error. If the application is available at both www.site.com and site.com then an appropriate certificate must be selected to accommodate both situations. The presence of domain mismatch errors desensitizes users to TLS error messages and increases the possibility an attacker could launch a convincing man-in-the-middle attack.
Alternatively, subject alternate names can be used to provide a specific listing of multiple names where the certificate is valid. These certificates are sometimes referred to as "multiple domain certificates" or enhanced wildcard certificates.
Client (Browser) Configuration
- The application server establishes connections to other applications over TLS for purposes such as web services or any exchange of data
- A thick client application is connecting to a server via TLS
In these situations extensive certificate validation checks must occur in order to establish the validity of the certificate. Consult the following resources to assist in the design and testing of this functionality. The NIST PKI testing site includes a full test suite of certificates and expected outcomes of the test cases.
As specified in the above guidance, if the certificate can not be established to be valid for any reason then the connection between the client and server must be dropped. Any data exchanged over a connection where the certificate has not properly been validated could be exposed to unauthorized access or modification.
Extended Validation Certificates
Extended validation certificates (EV Certificates) require more intensive investigation into the requesting party. The purpose of EV certificates is to provide the user with greater assurance that the owner of the certificate is a verified legal entity for the site. Browsers with support for EV certificates distinguish an EV certificate in a variety of ways. Internet Explorer will color a portion of the URL in green, while Mozilla will add a green portion to the left of the URL indicating the company name.
High value websites should consider the use of EV certificates to enhance customer confidence in the certificate. It should also be noted that EV certificates do not provide any greater technical security for the TLS. The purpose of the EV certificate is to increase user confidence that the target site is indeed who it claims to be.
Client side certificates can be used with TLS to prove the identity of the client to the server. Referred to as "two-way TLS", this configuration requires the client to provide their certificate to the server, in addition to the server providing their's to the client. If client certificates are used, ensure that the same validation of the client certificate is performed by the server, as indicated for the validation of server certificates above. In addition, the server should be configured to drop the TLS connection if the client certificate cannot be verified or is not provided.
The use of client side certificates is relatively rare currently due to the complexities of certificate generation, safe distribution, client side configuration, certificate revocation and reissuance, and the fact that clients can only authenticate on machines where their client side certificate is installed. Such certificates are typically used for very high value connections that have small user populations.
Providing Transport Layer Protection for Back End and Other Connections
Although not the focus of this cheat sheet, it should be stressed that transport layer protection is necessary for back connections and any other connection where sensitive data is exchanged or where user identity is established. Failure to implement an effective and robust transport layer security will expose sensitive data and undermine the effectiveness of any authentication or access control mechanism.
Secure Internal Network Fallacy
OWASP – ASVS Article on Why you need to use a FIPS 140-2 validated cryptomodule
SSL Labs - SSL Server Rating Guide
Other Articles in the OWASP Prevention Cheat Sheet Series
- XSS (Cross Site Scripting) Prevention Cheat Sheet
- Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
- SQL Injection Prevention Cheat Sheet
Authors and Primary Editors
Michael Coates - firstname.lastname@example.org
Dave Wichers - email@example.com