Transport Layer Protection Cheat Sheet

Page is under construction - michael.coates@owasp.org

= Introduction =

This article provides a simple model to follow avoid transport security protection related vulnerabilities. Although the concept of SSL is known to many, the actual details and security specific decisions of implementation are poorly understood and frequently result in insecure deployments.

This article will establish clear rules which provide guidance on securely designing and configuring transport layer security for an application.

Architectural Decision
An architectural decision must be made to determine the appropriate method of implementing transport layer security. The most common options available to corporations are Virtual Private Networks (VPN) or a SSL/TLS model commonly used for web applications. This decision will be determined by the business needs of the particular system. For example, a VPN connection may be the best design for a partnership between two companies that includes mutual access to a shared server over a variety of protocols. Conversely, a company hosting an application which will be used exclusively over the HTTP protocol by a variety of Internet users would likely be best served by a SSL/TLS model.

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 the most common architecture model for publicly accessible web applications and many thick client applications.

= Providing Transport Layer Protection with SSL/TLS =

Benefits

 * Confidentiality
 * Integrity
 * Replay Protection
 * End Point Authentication

SSL vs TLS
"The differences between this protocol (TLS) and SSL 3.0 are not dramatic, but they are significant enough that TLS 1.0 and SSL 3.0 do not interoperate (although TLS 1.0 does incorporate a mechanism by which a TLS implementation can back down to SSL 3.0).“ RFC 2246

For the purposes of this cheat sheet we will refer to the technology generically as SSL.

Rule - Use SSL for All Login Pages and All Authenticated Pages
The login page and all subsequent authenticated page must be exclusively accessed over HTTPS. The initial login page, referred to as the "login landing page", must be served over SSL. Failure to utilize SSL for the login landing page can enable an attacker to modify where the login form posts the user password. Failure to utilize SSL for internal pages enables an attacker to view the unencrypted session ID and compromise the user's authenticated session.

Rule - Use SSL on Any Networks (External and Internal) Transmitting Sensitive Data
All networks which transmit sensitive data must utilize SSL or an equivalent transport layer security. Sensitive data which is transmitted over an internal, or partner network must also utilize transport layer security. It is not sufficient to claim that access to the internal network is "restricted to employees". Numerous recent 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-SSL Pages for Secure Content
All pages which are available over SSL must be not be available over a non-SSL 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 the data in the unencrypted response.

Rule - Do Not Perform Redirects from Non-SSL Page to SSL Login Page
A common practice is to redirect users that have requested a non-SSL version of the login page to the SSL version (e.g. http://site.com/login goes to https://site.com/login). Unfortunately this practice creates an additional attack vector for the attacker. 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 attackers choosing.

Ultimately, this issue is the responsibility of the user since the website cannot prevent the user from initially typing http://site.com/login. However, a responsible website should display a security warning to the user whenever the non-ssl login page is requested. This security warning should urge the user to always type "HTTPS" into the browser or bookmark the secure login page.

Rule - Do Not Mix SSL and Non-SSL Content
A page that is available over SSL must not contain any content that is provided over the unencrypted HTTP. Even if the primary page is available over SSL, an attacker could intercept the non-SSL portion and inject malicious content into the user's page.

Rule - Use "Secure" Cookie Flag
The "Secure" flag must be set for all user cookies. Failure to use the "secure" flag will enable an attacker to perform a sidejacking attack and compromise the user's authenticated session ID.

Rule - Use an Appropriate Certificate Authority for the Application's User Base
A user of an application must never be presented with a warning that the certificate was signed by an unknown or untrusted authority. The user population of the application must have the public certificate of the certificate authority which issued the server's certificate. For Internent accessible websites the most effective method of achieving this goal is to purchase the SSL certificate from a recognize certificate authority. Major Internet browsers already contain the public certificates of these recognized certificate authorities.

Internal application or applications with a limited user population can use an internal certificate authority provided this public certificate is securely distributed to all users. In no situation is it acceptable to use a self signed certificate. 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.

Rule - Only Support Strong Cryptographic Algorithms
The strength of the encryption used within a SSL session is determined by the encryption algorithm negotiated between the server and the browser. In order to ensure that only strong crytographic algorithms 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 algorithms such as those specified by the US Security Requirements for Cryptographic Modules (FIPS 140-2). These algorithms are as follows:

ADH-AES256-SHA, DHE-RSA-AES256-SHA, DHE-DSS-AES256-SHA AES256-SHA, ADH-AES128-SHA, DHE-RSA-AES128-SHA, DHE-DSS-AES128-SHA, AES128-SHA, ADH-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, EDH-DSS-DES-CBC3-SHA, DES-CBC3-SHA

Rule - Only Support Strong Protocols
Weaknesses have been identified with older SSL protocols. As a result, older protocols are no longer acceptable for SSL. In no situation should SSL 2.0 be enabled on the server. It is also recommended to disable SSL 3.0 and TLS 1.0. The recommended protocols are TLS 1.1 and TLS 1.2.

Rule - Establish a Strong Private Key for the Server
The private key used to generate the cipher key should be at least 1024 bits long. In addition, the private key should be unique for each certificate requested. The private key should be stored in a secure location to prevent disclosure to unauthorized individuals.

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 accomodate both situations. The presence of domain mimatch errors desensitize users to SSL error messages and increases the possiblity an attacker could launch a convincing man-in-the-middle attack.

Client Configuration
The following rules for client configuration encompass items controlled by the browser and those decided by the user. Applications that utilize thick clients must incorporate all of these rules to ensure only secure connections are established.

Rule - Validate the Server's Certificate
The server's certificate must be validated by checking the following:


 * 1) The certificate is within the epxiration period
 * 2) The certificate was issued by a trusted certificate authority
 * 3) The name listed in the certificate matches the domain name.
 * 4) The certificate has not been revoked.

Rule - Perform Certificate Revocation List Checking
Browsers or thick client applications must be configured to regularly check certificate revocation lists (CRL) for all certificate authorities in the trusted root store. It is highly recommended to check the CRL over an encrypted channel such as SSL. In addition, consider denying all certificates from a particular certificate authority if revocation information cannot be obtained after a reasonable number of attempts.

Rule - Ensure the Trusted Root Store Contains Only Trusted Entries
The trusted root store must be reviewed and the public certificates of untrusted certificate authorities must be removed. If the public certificate of an untrusted certificate authority is present in the trusted root store then any certificates issued by this authority would be trsuted by the browser. In this situation an attacker could create a legitimate SSL certificate for a site that they do not own. The attacker could then execute a man-in-the-middle attack and the browser would not issue any alerts since the issuing certificate authority is within the trusted root store.

Rule - Deny Connections if Any SSL Related Errors are Encountered
If any SSL related errors are encountered then a user should stop cancel connections to the target site. Similarly, a thick client application should drop the SSL connection if any errors are encountered. The complexity and creativity of SSL related man-in-the-middle attacks makes it extremely difficult to determine if a SSL related error message is safe to ignore.

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 assuarance that the owner of the certificate is a verified legal entity for the site. Browsers with support for EV certificates distinguish an EV certificate from a regular certificate by coloring a portion of the URL in green. 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 SSL. The purpose of the EV certificate is to increase user confidence.

Client Side Certificates
Client side certificates can be used within the SSL authentication handshake between the client and server. Refered to as "two-way SSL" this configuration not only the server to provide their SSL certificate to the client, but also the client to provide their client certificate to the server. A SSL connection cannot be established without a valid client certificate. If client certificates are used ensure that proper validation is performed as indicated for the validation of server certificates above.

Resources &amp; References
OWASP.org - Testing for SSL-TLS

SSLLabs.com - SSL Server Rating Guide