Page is under construction - [email protected]

1 Introduction
- 1.1 Architectural Decision
2 Providing Transport Layer Protection with SSL/TLS

Introduction

This article provides a simple model to follow when implementing transport llayer protection for an application. 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 by web applications. The selected model will be determined by the business needs of the particular organization. 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, an Internet facing enterprise web server 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 a frequently used 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

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

"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

Secure Server Design

Rule - Use SSL for All Login Pages and All Authenticated Pages

The login page and all subsequent authenticated page must be exclusively accessed over SSL. 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 allows an attacker to modify the login form action, causing the user's credentials to be posted to an arbitrary location. Failure to utilize SSL for authenticated pages after the login 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 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-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 all of the user's data as they communicate with the site over unencrypted HTTP.

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 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 performing 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 (versuse https). However, a responsible website should display a security warning message 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, including content is from unrelated third party sites. 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 access the session cookie by tricking the user's browser into submitting a request to an unencrypted page on the site. This attack is possible even if the server is not configured to offer HTTP content since the attacker is monitoring the requests and does not care if the server responds with a 404.

Server Certificate & Protocol Configuration

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. Popular 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. However, remember that all certificates issued by this certificate authority will be trusted by the users. Therefore, utlize controls to protect the private key and ensure that only authorized individuals have the ability to sign certificates.

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 desensitizes 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:

The certificate is within the validity period (e.g. not expired and not before the beginning date)
The certificate was issued by a trusted certificate authority
The name listed in the certificate matches the domain name.
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 trusted 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 and 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.

Additional Controls

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 requires the server to provide their SSL certificate to the client, but also the client to provide their client certificate to the server. If client certificates are used ensure that proper validation of the client certificate is performed, as indicated for the validation of server certificates above.In addition, the server should be configured to drop the SSL connection if the certificate cannot be verified or is not provided.

Transport Layer Protection Cheat Sheet