|
|
| (200 intermediate revisions by 24 users not shown) |
| Line 1: |
Line 1: |
| − | = Introduction = | + | __NOTOC__ |
| | + | <div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div> |
| | | | |
| − | This article provides a simple model to follow when implementing transport layer protection for an application. Although the concept of SSL is known to many, the actual details and security specific decisions of implementation are often poorly understood and frequently result in insecure deployments. This article establishes clear rules which provide guidance on securely designing and configuring transport layer security for an application. This article is focused on the use of SSL/TLS between a web application and a web browser, but that we also encourage the use of SSL/TLS or other network encryption technologies, such as VPN, on back end and other non-browser based connections.<br>
| + | The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]! |
| | | | |
| − | == Architectural Decision ==
| + | 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. |
| − | | |
| − | 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 is 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 application 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 a frequently used 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 terms, Secure Socket Layer (SSL) and Transport Layer Security (TLS) are often used interchangeably. According to the RFC the two protocols are very similar. "The differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough that the various versions of TLS and SSL 3.0 do not interoperate (although each protocol incorporates a mechanism by which an implementation can back down to prior versions)" RFC 5246.
| |
| − | | |
| − | Both SSL and TLS are supported by all current web browsers and by most application server deployments. However, TLS is an IETF standard and also the preferred protocol due to identified weaknesses in SSL 2.0 and 3.0. For the purposes of this cheat sheet we will refer to the technology generically as TLS.
| |
| − | | |
| − | == Secure Server Design ==
| |
| − | | |
| − | === Rule - Use TLS for All Login Pages and All Authenticated Pages ===
| |
| − | | |
| − | The login page and all subsequent authenticated pages must be exclusively accessed over TLS. The initial login page, referred to as the "login landing page", must be served over TLS. Failure to utilize TLS 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 TLS for authenticated pages after the login enables an attacker to view the unencrypted session ID and compromise the user's authenticated session.
| |
| − | | |
| − | === Rule - Use TLS on Any Networks (External and Internal) Transmitting Sensitive Data ===
| |
| − | | |
| − | All networks, both external and internal, which transmit sensitive data must utilize TLS or an equivalent transport layer security mechanism. 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-TLS Pages for Secure Content ===
| |
| − | | |
| − | All pages which are available over TLS must not be available over a non-TLS 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-TLS Page to TLS Login Page ===
| |
| − | | |
| − | A common practice is to redirect users that have requested a non-TLS version of the login page to the TLS 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 perform 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 (versus https). However, a responsible website should display a security warning message to the user whenever the non-TLS 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 TLS and Non-TLS Content ===
| |
| − | | |
| − | A page that is available over TLS must not contain any content that is provided over unencrypted HTTP, including content from unrelated third party sites. Even if the primary page is available over TLS, an attacker could intercept the non-TLS portion and inject malicious content into the user's page, or steal the user's session cookie that is transmitted with any non-TLS requests (if the cookie's 'secure' flag is not set. See the next rule.).
| |
| − | | |
| − | === Rule - Use "Secure" Cookie Flag ===
| |
| − | | |
| − | The "Secure" flag must be set for all user cookies. Failure to use the "secure" flag enables 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 or doesn't respond at all.
| |
| − | | |
| − | == Server Certificate & Protocol Configuration ==
| |
| − | | |
| − | === Rule - Use an Appropriate Certificate Authority for the Application's User Base ===
| |
| − | | |
| − | An application user must never be presented with a warning that the certificate was signed by an unknown or untrusted authority. The application's user population must have access to the public certificate of the certificate authority which issued the server's certificate. For Internet accessible websites, the most effective method of achieving this goal is to purchase the TLS certificate from a recognize certificate authority. Popular Internet browsers already contain the public certificates of these recognized certificate authorities.
| |
| − | | |
| − | Internal applications with a limited user population can use an internal certificate authority provided its 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, utilize controls to protect the private key and ensure that only authorized individuals have the ability to sign certificates.
| |
| − | | |
| − | The use of self signed certificates is never acceptable. 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 TLS session is determined by the encryption algorithm negotiated between the server and the browser. In order to ensure that only strong cryptographic algorithms are selected the server must be modified to disable the use of weak algorithms. It is recommended to configure the server to only support strong algorithms such as those specified by [http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf 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 TLS protocols. As a result, older protocols are no longer acceptable for TLS. 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 accommodate both situations. The presence of domain mismatch errors desensitizes users to TLS error messages and increases the possibility an attacker could launch a convincing man-in-the-middle attack.
| |
| − | | |
| − | For example, consider a web application accessible at https://abc.site.com and https://xyz.site.com. A wild card certificate with the domain name of *.site.com would be an appropriate choice.
| |
| − | | |
| − | == Client (Browser) 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.
| |
| − | | |
| − | The following certificate checking rules will be automatically performed by the web browser each time a TLS connection is initiated with a web site. If a particular check fails an error message will likely be displayed to the user. The particular browser and individual browser settings can impact how the error messages and warnings to the user are handled.
| |
| − | | |
| − | #The certificate was issued by a trusted certificate authority.
| |
| − | #The certificate is within the validity period (e.g. not expired and not before the beginning date).
| |
| − | #The name listed in the certificate matches the domain name.
| |
| − | #The certificate has not been revoked.
| |
| − | | |
| − | === Rule - Verify the Certificate was Issued by a Trusted Certificate Authority ===
| |
| − | | |
| − | Confirm that the web server certificate is signed by a trusted certificate authority. A trusted certificate authority is any certificate authority who's public key is present within the trusted root certificates on the local machine. Many trusted root certificates are installed when the browser is initially installed to the operating system.
| |
| − | | |
| − | === Rule - Verify the Certificate is Within the Validity Period===
| |
| − | | |
| − | Confirm that the web server certificate is not expired and is not being used before the certificate's validity period has begun. This check often uses the machines local clock and is ineffective in situations where the clock is not accurate.
| |
| − | | |
| − | === Rule - Verify the Certificate Common Name Matches the Domain Name ===
| |
| − | | |
| − | Confirm that the common name listed within the certificate matches the domain name of the requested site. This check must consider wild card certificates such as *.site.com.
| |
| − | | |
| − | === Rule - Perform Certificate Revocation List (CRL) 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 TLS. 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 TLS 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 TLS Related Errors are Encountered ===
| |
| − | | |
| − | If any TLS related errors are encountered, then a user should stop and cancel connections to the target site. Similarly, a thick client application should drop the TLS connection if any errors are encountered. The complexity and creativity of TLS related man-in-the-middle attacks makes it extremely difficult to determine if a TLS 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 assurance 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 TLS. The purpose of the EV certificate is to increase user confidence that the target site is indeed who it claims to be.
| |
| − | | |
| − | === Client Side Certificates ===
| |
| − | | |
| − | Client side certificates can be used with TLS to prove the identity of the client to the server. Referred to as "two-way TLS", this configuration requires the client to provide their certificate to the server, in addition to the server providing their's to the client. If client certificates are used, ensure that the same validation of the client certificate is performed by the server, as indicated for the validation of server certificates above. In addition, the server should be configured to drop the TLS connection if the client certificate cannot be verified or is not provided.
| |
| − | | |
| − | The use of client side certificates is relatively rare currently due to the complexities of certificate generation, safe distribution, client side configuration, certificate revocation and reissuance, and the fact that clients can only authenticate on machines where their client side certificate is installed. Such certificates are typically used for very high value connections that have small user populations.
| |
| − | | |
| − | = Providing Transport Layer Protection for Back End and Other Connections =
| |
| − | | |
| − | Although not the focus of this cheat sheet, it should be stressed that transport layer protection is necessary for back connections and any other connection where sensitive data is exchanged or where user identity is established. Failure to implement an effective and robust transport layer security will expose sensitive data and undermine the effectiveness of any authentication or access control mechanism.
| |
| − | | |
| − | == Secure Internal Network Fallacy ==
| |
| − | | |
| − | The internal network of a corporation is not immune to attacks. Many recent high profile compromises, where thousands of sensitive customer records were compromised, have been perpetrated by attackers that have gained internal network access and then utilized sniffers to capture unencrypted data as it traversed the internal network.
| |
| − | | |
| − | = Related Articles =
| |
| − | | |
| − | OWASP.org - [[Testing for SSL-TLS (OWASP-CM-001)|Testing for SSL-TLS]], [[Guide_to_Cryptography]]
| |
| − | | |
| − | SSLLabs.com - [http://www.ssllabs.com/projects/rating-guide/index.html SSL Server Rating Guide]
| |
| − | | |
| − | NIST - [http://csrc.nist.gov/publications/nistpubs/800-52/SP800-52.pdf SP 800-52 Guidelines for the selection and use of transport layer security (TLS) Implementations]
| |
| − | | |
| − | NIST - [http://csrc.nist.gov/publications/drafts.html#sp800-95 SP 800-95 Guide to secure web services]
| |
| − | | |
| − | = Authors and Primary Editors =
| |
| − | | |
| − | | |
| − | | |
| − | Dave Wichers - dave.wichers@aspectsecurity.com
| |
