February 25, 2016

515276483_691482

 

In the last Years, there have been several high-profile vulnerabilities in the SSL and TLS protocols such as Heartbleed or POODLE (Padding Oracle On Downgraded Legacy Encryption) that have sent administrators scrambling. There are a number of tools that can help you identify and evaluate the security of your SSL configuration. One tool, SSLyze, is a SSL scanner that can give you an idea of what flaws exist in your SSL implementation. While it won’t fix them, it will help you identify issues in your configuration.

 

SSLyze is a freely available SSL scanner from iSEC Partners. It works by attempting different, secure connections to the server that you are testing. SSLyze is built in python and runs in the command line. Let’s see how it works.

 

Let’s look how to install it, if you are Kali Linux user it present by default. Just update it frequently.

 

SSL is a good thing to have implemented as security on a website. But only if it is set up correctly. And the newest version, Otherwise you (your site) maybe will be hacked (Heartbleed).

 

It is a Python tool that can analyze the SSL configuration of a server by connecting to it. It is designed to be fast and comprehensive, and should help organizations and testers identify mis-configurations affecting their SSL servers. SSLyze is all Python code but it uses an OpenSSL wrapper written in C called nassl, which was specifically developed for allowing SSLyze to access the low-level OpenSSL APIs needed to perform deep SSL testing.

 

 

Some features are:

 

  • Multi-processed and multi-threaded scanning: it’s very fast.
  • Support for all SSL protocols, from SSL 2.0 to TLS 1.2.
  • NEW: SSLyze can also be used as a library, in order to run scans and process the results directly from Python.
  • Performance testing: session resumption and TLS tickets support.
  • Security testing: weak cipher suites, insecure renegotiation, CRIME, Heartbleed and more.
  • Server certificate validation and revocation checking through OCSP stapling.
  • Support for StartTLS handshakes on SMTP, XMPP, LDAP, POP, IMAP, RDP, PostGres and FTP.
  • Support for client certificates when scanning servers that perform mutual authentication.

 

 
To install SSLyze you can use either pip

 

 

#pip install sslyze

 

or  clone it from Github

 

#git clone https://github.com/nabla-c0d3/sslyze.git
#cd sslyze
#pip install -r requirements.txt –target ./lib

 

The following command is how you run a basic SSLyze scan:

 

#python sslyze.py  –regular  example.com:443

 
Additionally, SSLyze can be packaged as an executable so you can use it on windows machine easily. That command would look like this:

 

 

sslyze.exe –regular somewebsite.com:443

 
This command scans the domain and writes the output back to the console. The option, –regular, is a shortcut for several options that are commonly used. The output will look something like the example screenshot below.

 

This gives you some good information about the security of your SSL configuration, such as whether or not specific settings are enabled (like secure renegotiation or compression), some general information about the certificate, and what SSL protocols and ciphers are accepted by your server. Let’s look at each section individually.

 

#sslyze -h

 

Screenshot from 2016-02-26 00:59:27

Screenshot from 2016-02-26 01:01:11

 

 

The first section of the report requires little explanation, it’s just SSLyze letting you know what plugins it’s using and checking to see if the host you entered is available.

 

 

REGISTERING AVAILABLE PLUGINS

—————————–

PluginCertInfo

PluginChromeSha1Deprecation

PluginHSTS

PluginOpenSSLCipherSuites

PluginSessionResumption

PluginHeartbleed

PluginCompression

PluginSessionRenegotiation

CHECKING HOST(S) AVAILABILITY

—————————–

0.0.0.0:443 => 0.0.0.0:443

In the second section we start to see some of the first vulnerabilities SSLyze is looking for. All of these relate to some issue with SSL configuration.

 

For example, if compression is enabled, then you are probably vulnerable to the CRIME attack. Or if you have an insecure renegotiation vulnerability (that’s when client-initialed renegotiations are accepted and secure renegotiation is disabled) that can lead to denial of service attacks and man-in-the-middle request injections. Generally, if SSLyze says VULNERABLE instead of OK, then you have some reconfiguring to do.

 

* Deflate Compression:

OK – Compression disabled

* Session Renegotiation:

Client-initiated Renegotiations: OK – Rejected

Secure Renegotiation: OK – Supported

* OpenSSL Heartbleed:

OK – Not vulnerable to Heartbleed

 

 

The next section of the report contains a lot of simple info about the SSL certificate. It contains the name of the certificate authority that signed this certificate and the key size signature algorithm.

 

Right now, SHA1 with a 2048 bit key is the standard, however in the next few years, browsers will no longer trust SHA1. Also, this section is where SSLyze will check if OCSP (Online Certificate Status Protocol) Stapling or session resumption are enabled.

 

* Certificate – Content:

SHA1 Fingerprint: 00000000000000000000000000000

Common Name: example.com

Issuer: Some SSL CA – G2

Serial Number: 0000000000000000000000000000000

Not Before: Jan 24 00:00:00 2015 GMT

Not After: Jan 22 23:59:59 2019 GMT

Signature Algorithm: sha1WithRSAEncryption

Key Size: 2048 bit

Exponent: 65537 (0x10001)

X509v3 Subject Alternative Name: {‘DNS’: [‘example.com’]}

* Certificate – Trust:

Hostname Validation: OK – Certificate matches example.com

“Mozilla NSS – 08/2015” CA Store: OK – Certificate is trusted

“Microsoft – 08/2015” CA Store: OK – Certificate is trusted

“Apple – OS X 10.9.4” CA Store: OK – Certificate is trusted

“Java 6 – Update 65” CA Store: OK – Certificate is trusted

Certificate Chain Received: [‘example.com’, ‘Some SSL CA – G2’, ‘Some CA’, ‘Some Secure Certificate Authority’]

* Certificate – OCSP Stapling:

NOT SUPPORTED – Server did not send back an OCSP response.

* Session Resumption:

With Session IDs: OK – Supported (5 successful, 0 failed, 0 errors, 5 total attempts).

With TLS Session Tickets: NOT SUPPORTED – TLS ticket not assigned.

 

 

The last section of the report details all of the enabled protocols and the allowed cipher suites on top of those protocols.

 

In this example, the administrator has disabled SSL version 2 as it is very insecure (yay!). However, SSLv3 is enabled and there are still some weak ciphers enabled on the TLS protocols, namely RC4 and DES. The next step for this admin would be to implement SSLv3, to avoid issues like POODLE (Padding Oracle Over Downgraded Legacy Encryption). After that, it would be wise to disable older, insecure suites and support NIST compliant cipher suites. For example, EDCHE RSA key exchange, with RSA encryption.

 

* SSLV2 Cipher Suites:

Server rejected all cipher suites.

* TLSV1_2 Cipher Suites:

Preferred:

AES128-SHA – 128 bits HTTP 200 OK

Accepted:

AES256-SHA – 256 bits HTTP 200 OK

RC4-SHA – 128 bits HTTP 200 OK

AES128-SHA – 128 bits HTTP 200 OK

DES-CBC3-SHA – 112 bits HTTP 200 OK

* TLSV1_1 Cipher Suites:

Preferred:

AES128-SHA – 128 bits HTTP 200 OK

Accepted:

AES256-SHA – 256 bits HTTP 200 OK

RC4-SHA – 128 bits HTTP 200 OK

RC4-MD5 – 128 bits HTTP 200 OK

AES128-SHA – 128 bits HTTP 200 OK

DES-CBC3-SHA – 112 bits HTTP 200 OK

* TLSV1 Cipher Suites:

Preferred:

AES128-SHA – 128 bits HTTP 200 OK

Accepted:

AES256-SHA – 256 bits HTTP 200 OK

RC4-SHA – 128 bits HTTP 200 OK

RC4-MD5 – 128 bits HTTP 200 OK

AES128-SHA – 128 bits HTTP 200 OK

DES-CBC3-SHA – 112 bits HTTP 200 OK

* SSLV3 Cipher Suites:

Preferred:

AES128-SHA – 128 bits HTTP 200 OK

Accepted:

AES256-SHA – 256 bits HTTP 200 OK

RC4-SHA – 128 bits HTTP 200 OK

RC4-MD5 – 128 bits HTTP 200 OK

AES128-SHA – 128 bits HTTP 200 OK

DES-CBC3-SHA – 112 bits HTTP 200 OK

SCAN COMPLETED IN 3.16 S

 

You can download SSLyze here. Hopefully you now have enough information about this excellent tool to take advantage of it.  and keep your website safe from hacking.

 

Share

Some funny SSL stuff

Author: Martin Voelk
February 13, 2016

Everyone knows that you shouldn’t use self-signed certificates because they are not trusted by browsers natively and generate an error message. If users get used to accept untrusted certificates, they won’t know the difference between a self-signed and a man-in-the-middle attack. I think most Admins are clear about that. This is why there are CAs like Verisign, Comodo, Godaddy and so on.

But when it comes to Google everything is funny. Many people don’t know that Google runs their own CAs and so it must be natively trusted right because it’s Google?!? This is unfortunately, what the Internet has become. A company just needs to grow big enough and then form their own trusted CA and every browser trusts natively. German Telecom is the same thing.

No user would trust company X with a self-signed certificate over their portal login. Yet if it’s Google or Youtube, all is nicely signed by themselves and the little green lock shows in the browser. All good and safe 🙂 Happy Internet

Screen Shot 2016-02-12 at 22.52.32

Share