TLS & SSL Checker performs a detailed analysis of TLS/SSL configuration on the target server and port, including
checks for TLS and SSL vulnerabilities, such as BREACH, CRIME, OpenSSL CCS injection, Heartbleed, POODLE, etc.
The tool provide details about the certificate chain, certificate paths, TLS and SSL protocols and cipher suites,
and points out problems in the target server configuration and certificate issues.
This tool can help you deploy your services running on TLS/SSL protocols in a way they are secure
against the known attack vectors. Our SSL checker supports not only HTTPS, but also other protocols including
SMTPS, POP3S, RDP, FTPS, IMAPS, and others. STARTTLS is also supported on selected protocols.
According to Trustworthy Internet Movement
SSL Pulse survey, the security level of majority of web sites running HTTPS is inadequate. Few administrators are
well aware of all security aspects related to TLS/SSL protocols and thus new insecure machines are put online on
a daily basis. The current state of TLS/SSL covered services on servers world-wide needs to be improved and our SSL
Checker is one of the tools that can help.
Our checker is based on a modified SSLyze scanner,
testssl.sh tool, and our own certificate analyzis tool.
Testing your server is very simple. If you run an HTTPS web server on a single IP address, just fill in
the Domain name and hit the "Check SSL/TLS!" button. Wait for the results and analyze the results.
The default Port is set by default to the common HTTPS port 443.
If your domain resolves to more than one IP address, you might want to specify, which IP address should be
scanned. Use the IP address field to do so. If you are running your service on a different port,
simply change the Port field. If the target port is one of the common ports (such as 110
for POP3, or 25 for SMTP), and if the protocol is recognize, STARTTLS will be supported
automatically. For all other protocols, implicit TLS/SSL is assumed.
The length of the scan depends on the configuration of the target server. In extreme cases, where anti-abuse
filtering is implemented, it may take very long time to complete or even time out. However, for most services,
the scan is finished within 2 or 3 minutes, rarely it takes more than 5 minutes. If you are a registered user,
you do not need to wait for the scan to finish with your browser opened. You can check your
Tasks History any time later to see results of all scans
you executed.
Output Structure
The Problems Summary section contains a list of all problems that our tool detected during the scan.
The information in this section is relevant for both expert users as well as common users.
The most critical problems are displayed with red background. Red alerts should be taken seriously and fixed
as soon as possible, if security is critical for the target service. Non-critical problems are displayed
on yellow-orange background. It is a good idea to learn more about these problems and consider fixing the issues
if possible. Finally, there are notice-level problems (wtih blue background) that just informs you about
a potential problem that might soon be relevant to you (e.g. a server's certificate expires in the near future).
Further sections provide more details about the analyzed protocols and certificates. Most of the information
provided in these sections are intended for expert users only. If any of the values presented in these section
presents a critical problem, it is written in red. Similarly, non-critical values are written in orange.
Information about potential future problems are written in blue. Green color present values that are configured well
and are somehow significant for the security of the target service.
The Certificate Chain section contains the chain of certificates provided by the target server itself.
It starts with the server's certificate, for which we provide information about validity, used key and signature
algorithms, certificate's fingerprint, and some additional details such as whether it is an
extended validation certificate,
whether it supports certificate transparency,
which revocation methods
are supported. For publicly used services, probably the most important value here is whether the certificate is
Trusted. We check the trust status of the server's certificate against four different trust stores – Apple,
Java, Microsoft, and Mozilla. If any of these are missing, some users are likely to see warnings about untrusted
certificate, or will not be able to connect to the target service at all.
The Certificate Parts section contains list of different certification paths. Each certificate's trust can
be proved by one or more certificates. The root certificate in each path is self-signed and should be in the trust store
of the client, so that the client knows the whole path is trusted. For each certificate, we also provide information
on how it was obtained. The root certificates should be In trust store, which means
they are stored locally on the client. The Sent by server value means that the certificate
was directly sent by the target server. Certificates marked as Extra download had to
be obtained from an external source, which is unpleasant since this means the initial connection to the target service
takes longer time than necessary.
The Protocol Details section contains interesting data about the following supported features and detected vulnerabilities:
- Secure Renegotiation, Secure Client-Initiated Renegotiation, Insecure Client-Initiated Renegotiation –
Renegotiation is a possibility to rearrange the security connection between the client and the server after a security connection was established.
This feature is used for example when a client authentication is required, or if a new set of keys or algorithms are needed.
More information: Why should secure renegotiation be enabled?, Secure client-initiated renegotiation is vulnerable to DoS, Attacking insecure client-initiated renegotiation.
- OCSP Stampling – Alternative approach for checking revocation status of certificates that is lightweight on resources, compared to OCSP and CRL protocols.
More information: OCSP stapling on Wikipedia.
- Strict Transport Security (HSTS) – HSTS is a mechanism that informs the clients that only secured protocol (HTTPS) should be used at all times instead of unsecured one (HTTP).
Conforming clients will thus not attempt to access the target server via HTTP even if a link's scheme is HTTP and not HTTPS. Such links are automatically converted to
their secured variant. If the client is not able to establish secured connection with the target server, it will display an error.
More information: HTTP Strict Transport Security on Wikipedia.
- Session Resumption (Session IDs), Session Resumption (Session Tickets) – Resumption features make HTTPS faster by eliminating
the need for complex handshake with each new secured connection. If resumption is supported, the client only needs to perform the complex handshake once
and use the resumption mechanisms for further connections to avoid extra round trips.
More information: Session resumption explained.
- Deflate Compression – Compression in protocols saves bandwidth and improves speed of the transfer.
However, in combination with security protocols, using compression might lead to vulnerabilities and weaken the security
of the protocol. More information: HTTP compression on Wikipedia.
- Downgrade Attack Prevention (TLS_FALLBACK_SCSV) – There are currently five widely used version of SSL and TLS. Older versions such as SSL 2 and SSL 3
are known to be insecure. Also older TLS versions were already found vulnerable to various attacks. Servers commonly support more than one version of secure
protocol in order to support all kinds of clients including very old clients. Downgrade attack prevention is a mechanism to prevent manipulating the communicating
sides to use less secure protocols than both the client and the server support.
More information: RFC 7507 – TLS Fallback Signaling Cipher Suite Value.
- Supports Insecure Ciphers, Supports Weak Ciphers – SSL and TLS protocols can work with many different kinds of ciphers. A substantial
set of the supported ciphers, however, were proved weak or insecure over the time. If these ciphers are used, there is a risk that the encrypted communication
will be decrypted.
More information: Weak DH exchange parameters and common DH primes, Broken RC4 cipher.
- Common DH Prime – Many servers all around the world are based on common implementations of the security protocol libraries,
which means these servers are using the same prime numbers for Diffie-Hellman key exchange unless configured otherwise. Such servers
are vulnerable to cracking the encryption if the prime numbers are small enough (i.e. less than 2048 bits).
More information: Common DH primes.
- Forward Secrecy – Perfect forward secrecy is a property of a secure protocol that ensures that even
if keys of the one session is compromised, all other sessions will remain safe.
More information: Forward secrecy on Wikipedia.
- BREACH Vulnerability – An instance of CRIME vulnerability that attacks HTTP compression.
More information: BREACH attack.
- CRIME Vulnerability – A vulnerability that can be used to decrypt small data parts of secured communication – e.g. authentication cookies.
This can lead to session hijacking and other severe attacks. It exploits SPDY and TLS-level compression.
More information: Compression Ratio Info-leak Made Easy on Wikipedia.
- OpenSSL CCS Injection – This vulnerability allows MITM to intercept encrypted data and decrypt them while forcing
the sides to use weak keys which are exposed to the attacker.
More information: CCS Injection Vulnerability, CVE-2014-0224.
- Heartbleed Vulnerability – One of the most famous vulnerabilities in OpenSSL library. It allows reading memory of the affected systems,
which may lead to compromitation of secret keys or other sensitive data.
More information: The Heartbleed Bug, CVE-2014-0160.
- POODLE Vulnerability – This vulnerability affects SSL 3 and CBC encryption mode in TLS and it allows a MITM attacker to decrypt
the contents of the encrypted communication.
More information: This POODLE bites on Google Security Blog, CVE-2014-3566.
- BEAST Vulnerability – This vulnerability exploits SSL/TLS block ciphers and can be exploited using a malicious JavaScript
code or Java applet that are executed in the client's browser. A successful BEAST attack allows decryption of encrypted cookies.
More information: BEAST attack on Wikipedia, CVE-2011-3389.
- FREAK Vulnerability – Another attack that can force client and server to use weaker encryption than they both actually support.
This can lead to decryption of the entire communication.
More information: Tracking the FREAK Attack, CVE-2015-0204, CVE-2015-1067, CVE-2015-1637.
- LOGJAM Vulnerability – This vulnerability allows a MITM attacker to weaken vulnerable connections.
It attacks Diffie-Hellman key exchange used with weak parameters.
More information: The Logjam Attack, CVE-2015-4000.
The Supported Protocols and Cipher Suites section lists all supported protocols and their cipher suites. The level of security (grade) of each
supported cipher suite is evaluated as either Secure, Weak, or Insecure.
The actual grade is based on size of the keys, used parameters, and whether or not the cipher is vulnerable to known attacks. Additional information about
some of the features and values are also provided – Key Size, forward secrecy support (FS), whether or not it is anonymous or export cipher suite,
and whether it is preferred by the server.
