Testing for SSL-TLS (OWASP-CM-001)

OWASP Testing Guide v2 Table of Contents

SSL certificate validity – client and server

When accessing a web application via the https protocol, a secure channel is established between the client (usually the browser) and the server. The identity of one (the server) or both parties (client and server) is then established by means of digital certificates. In order for the communication to be set up, a number of checks on the certificates must be passed. While discussing SSL and certificate based authentication is beyond the scope of this Guide, we will focus on the main criteria involved in ascertaining certificate validity: a) checking if the Certificate Authority (CA) is a known one (meaning one considered trusted), b) checking that the certificate is currently valid, and c) checking that the name of the site and the name reported in the certificate do match.

Let’s examine each check more in detail.

a) Each browser comes with a preloaded list of trusted CAs, against which the certificate signing CA is compared (this list can be customized and expanded at will). During the initial negotiations with a https server, if the server certificate relates to a CA unknown to the browser, usually a warning is raised. Usually this happens because a web application relies on a certificate signed by a self-established CA. Whether this is to be considered a concern depends. For example, this may be fine for an intranet environment (think of corporate web email being provided via https; here, obviously all users do recognize the internal CA as a trusted CA). When a service is provided to the general public via the Internet, however (i.e. when it is important to positively verify the identity of the server we are talking to), it is usually imperative to rely on a trusted CA, i.e. on a CA which is recognized by all the user base (and here we stop with our considerations, i.e. we won’t delve deeper in the implications of the trust model being used by digital certificates).

b) Certificates have associated a period of validity, therefore they may expire. Again, we are warned by the browser about this. A public service needs a temporally valid certificate; otherwise, it means we are talking with a server whose certificate was issued by someone we trust, but that has expired, and has not been renewed.

c) Why the name on the certificate and the name of the server should not match? If this happens, it might sound suspicious (i.e.: whom are we talking with?). For a number of reasons, this is not so rare to see. A situation which causes this is when a system hosts a number of name-based virtual hosts, i.e. virtual hosts sharing the same IP address, that are identified by means of the HTTP 1.1 Host: header information. In this case, since the SSL handshake – during which the client browser checks the server certificate – takes place before the HTTP request is processed, it is not possible to assign different certificates to each virtual server. Therefore, if the name of the site and the name reported in the certificate do not match we have a condition which is typically signaled by the browser. To avoid this, IP-based virtual servers must be used. [2] and [3] describe techniques to deal with this problem and allow name-based virtual hosts to be correctly referenced.

How to Test

Black Box

Examine the validity of the certificates used by the application. Browsers will issue a warning when encountering expired certificates, certificates issued by untrusted – meaning unknown to the browser – CAs, certificates which do not match namewise with the site they should refer. By clicking on the padlock which appears in the browser window when visiting an https site, you can look at information related to the certificate – including issuer, period of validity, encryption characteristics, etc.

If the application requires a client certificate, you probably have installed one to access it. Certificate information is available in the browser, by inspecting the relevant certificate(s) in the list of the installed certificates.

These checks must be applied to all visible SSL-wrapped communication channels used by the application. Though this is the usual https service running on port 443, there may be additional services involved depending on the web application architecture and on deployment issues (for example, an https administrative port left open, https services on non-standard ports, etc.). Therefore, apply these checks to all SSL-wrapped ports which have been discovered. For example, the nmap scanner features a scanning mode (enabled by the –sV command line switch) which identifies SSL-wrapped services. The Nessus vulnerability scanner has the capability of performing SSL checks on all SSL/TLS-wrapped services.

White Box

Examine the validity of the certificates used by the application – at server and client level. The usage of certificates is primarily at the web server level, however there may be additional communication paths protected by SSL (for example, towards the DBMS). You should check the application architecture to identify all SSL protected channels.

References

Examples

Rather than providing a fictitious example, we have inserted an anonymized real-life example to stress how frequent is to stumble on https sites whose certificates are inaccurate with respect to naming.

The following screenshots refer to a regional site of a high-profile IT company.

Warning issued by Microsoft Internet Explorer. We are visiting a .it site and the certificate was issued to a .com site! Internet Explorer warns that the name on the certificate does not match the name of the site.

Warning issued by Mozilla Firefox. The message issued by Firefox is different – Firefox complains because it cannot ascertain the identity of the .com site the certificate refers to; this because it does not know the CA who signed the certificate. In fact, Internet Explorer and Firefox do not come preloaded with the same list of CAs. Therefore, the behavior experienced with various browsers may differ.

Whitepapers

• [1] RFC2246. The TLS Protocol Version 1.0 (updated by RFC3546), http://www.ietf.org/rfc/rfc2246.txt
• [2] RFC2817. Upgrading to TLS Within HTTP/1.1, http://www.ietf.org/rfc/rfc2817.txt
• [3] RFC3546. Transport Layer Security (TLS) Extensions, http://www.ietf.org/rfc/rfc3546.txt

Tools

Vulnerability scanners may include checks regarding certificate validity, including name mismatch and time expiration. They also usually report other information, such as the CA which issued the certificate. Remember, however, that there is no unified notion of a “trusted CA”; what is trusted depends on the configuration of the software and on the human assumptions made beforehand. Browsers come with a preloaded list of trusted CA. If your web application rely on a CA which is not in this list (for example, because you rely on a self-made CA), you should take into account the process of configuring user browsers to recognize the CA.

The Nessus scanner includes a plugin to check for expired certificates or certificates which are going to expire within 60 days (plugin “SSL certificate expiry”, plugin id 15901). This plugin will check certificates installed on the server.

As suggested in the Section SSL/TLS Testing: support of weak ciphers, you may also rely on specialized tools such as SSL Digger, or on the openssl tool.

Fuzzing – TO DO

BENEFITS OF FUZZING APPLICATIONS AND PROTOCOLS [ DANIEL CUTHBERT & SIMON ROSES FEMERLING ([email protected])]

GENERAL GUIDELINES WHEN FUZZING[ DANIEL CUTHBERT &SIMON ROSES FEMERLING ([email protected])]

FUZZING EXAMPLES (THIS COULD BE A STEP BY STEP PROCESS DETAILING A SUCCESSFUL FUZZ OF A COMPONENT) [ DANIEL CUTHBERT & SIMON ROSES FEMERLING ([email protected])]

Category

OWASP Testing Guide v2 Table of Contents

This article is a stub. You can help OWASP by expanding it or discussing it on its Talk page.