This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Transport Layer Protection Cheat Sheet"
m |
m |
||
| Line 3: | Line 3: | ||
= Introduction = | = Introduction = | ||
| − | == Architectural Decision == | + | == Benefits == |
| + | |||
| + | *Confidentiality<br> | ||
| + | *Integrity<br> | ||
| + | *Replay Protection<br> | ||
| + | *End Point Authentication | ||
| + | |||
| + | == Architectural Decision == | ||
| + | |||
| + | An architectual 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<br> = | = Rules for VPN<br> = | ||
| + | === Rule -<br> === | ||
= Rules for SSL/TLS<br> = | = Rules for SSL/TLS<br> = | ||
| − | == | + | == 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<br><br> | |
| − | |||
| − | |||
| − | |||
| − | + | For the purposes of this cheat sheet we will refer to the technology genericly as SSL. | |
== Secure Server Design <br> == | == Secure Server Design <br> == | ||
| Line 31: | Line 40: | ||
=== Rule - Do Not Mix SSL and Non-SSL Content === | === Rule - Do Not Mix SSL and Non-SSL Content === | ||
| − | === Rule - Use "Secure" Cookie Flag === | + | === Rule - Use "Secure" Cookie Flag === |
| − | |||
| − | |||
== Server Certificate & Protocol Configuration == | == Server Certificate & Protocol Configuration == | ||
| Line 46: | Line 53: | ||
=== Rule - Use a Certificate That Supports All Available Domain Names<br> === | === Rule - Use a Certificate That Supports All Available Domain Names<br> === | ||
| − | |||
| − | |||
== Client Configuration == | == Client Configuration == | ||
| − | === Rule - Validate the Server's Certificate<br> | + | === Rule - Validate the Server's Certificate<br> === |
| − | |||
| − | |||
| − | |||
| − | |||
| − | === Rule - | + | === Rule - Perform Certificate Revocatoin List Checking<br> === |
| + | === Rule - Ensure the Trusted Root Store Contains Only Trusted Entries<br> === | ||
| + | === Rule - Deny Connections if Any SSL Related Errors are Encountered<br> === | ||
== Additional Controls == | == Additional Controls == | ||
| − | === Extended Validation Certificates<br> === | + | === Extended Validation Certificates<br> === |
| − | === Client Side Certificates === | + | === Client Side Certificates === |
=== === | === === | ||
Revision as of 22:12, 7 October 2009
Page is under construction - [email protected]
- 1 Introduction
- 2 Rules for VPN
- 3 Rules for SSL/TLS
- 3.1 SSL vs TLS
- 3.2 Secure Server Design
- 3.2.1 Rule - Use SSL for All Login Pages and All Authenticated Pages
- 3.2.2 Rule - Use SSL on Any Networks (External and Internal) Transmiting Sensitive Data
- 3.2.3 Rule - Do Not Provide Non-SSL Pages for Secure Content
- 3.2.4 Rule - Do Not Perform Redirects from Non-SSL Page to SSL Login Page
- 3.2.5 Rule - Do Not Mix SSL and Non-SSL Content
- 3.2.6 Rule - Use "Secure" Cookie Flag
- 3.3 Server Certificate & Protocol Configuration
- 3.3.1 Rule - Use an Appropriate Certificate Authority for the Application's User Base
- 3.3.2 Rule - Only Support Strong Cryptographic Algorithms
- 3.3.3 Rule - Only Support Strong Protocols
- 3.3.4 Rule - Establish a Strong Private Key for the Server
- 3.3.5 Rule - Use a Certificate That Supports All Available Domain Names
- 3.4 Client Configuration
- 3.5 Additional Controls
Introduction
Benefits
- Confidentiality
- Integrity
- Replay Protection
- End Point Authentication
Architectural Decision
An architectual 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
Rule -
Rules for 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 genericly as SSL.
