|
|
| (222 intermediate revisions by 24 users not shown) |
| Line 1: |
Line 1: |
| − | Page is under construction - michael.coates@owasp.org<br>
| + | __NOTOC__ |
| | + | <div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div> |
| | | | |
| − | = Introduction =
| + | The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]! |
| | | | |
| − | == Benefits ==
| + | Please visit [https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html Transport Layer Protection Cheat Sheet] to see the latest version of the cheat sheet. |
| − | | |
| − | *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> =
| |
| − | | |
| − | === Rule -<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> ==
| |
| − | | |
| − | === Rule - Use SSL for All Login Pages and All Authenticated Pages<br> ===
| |
| − | | |
| − | === Rule - Use SSL on Any Networks (External and Internal) Transmiting Sensitive Data<br> ===
| |
| − | | |
| − | === Rule - Do Not Provide Non-SSL Pages for Secure Content<br> ===
| |
| − | | |
| − | === Rule - Do Not Perform Redirects from Non-SSL Page to SSL Login Page ===
| |
| − | | |
| − | === Rule - Do Not Mix SSL and Non-SSL Content ===
| |
| − | | |
| − | === Rule - Use "Secure" Cookie Flag ===
| |
| − | | |
| − | == Server Certificate & Protocol Configuration ==
| |
| − | | |
| − | === Rule - Use an Appropriate Certificate Authority for the Application's User Base ===
| |
| − | | |
| − | === Rule - Only Support Strong Cryptographic Algorithms<br> ===
| |
| − | | |
| − | === Rule - Only Support Strong Protocols ===
| |
| − | | |
| − | === Rule - Establish a Strong Private Key for the Server ===
| |
| − | | |
| − | === Rule - Use a Certificate That Supports All Available Domain Names<br> ===
| |
| − | | |
| − | == Client Configuration ==
| |
| − | | |
| − | === Rule - Validate the Server's Certificate<br> ===
| |
| − | | |
| − | === 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 ==
| |
| − | | |
| − | === Extended Validation Certificates<br> ===
| |
| − | | |
| − | === Client Side Certificates ===
| |
| − | | |
| − | === ===
| |
