Revision as of 03:28, 9 October 2009

Page is under construction - [email protected]

Introduction

Benefits

• Confidentiality
  
• Integrity
  
• Replay Protection
  
• End Point Authentication

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.

Rules for VPN

Deployment Options

• IPSEC VPN
• SSL VPN

Providing Transport Layer Protection with VPN

Rule -

Providing Transport Layer Protection with SSL/TLS

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.

Deployment Options

• Server Certificate
• Server Certificate + Client Certificate

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 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.

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. 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

Rule - Only Support Strong Protocols

Rule - Establish a Strong Private Key for the Server

Rule - Use a Certificate That Supports All Available Domain Names

Client Configuration

Rule - Validate the Server's Certificate

Rule - Perform Certificate Revocation List Checking

Rule - Ensure the Trusted Root Store Contains Only Trusted Entries

Rule - Deny Connections if Any SSL Related Errors are Encountered

Additional Controls

Extended Validation Certificates

Client Side Certificates