How to detect SHA1 signed certificates on your network

A few colleagues at work today upgraded their Google Chrome browser to Chrome 57 and some of them were surprised they could no longer open many websites including gmail.

If you notice the error message it says NET:ERR_CERT_WEAK_SIGNATURE_ALGORITHM.  This is a clear indicator that we are dealing the use of SHA1 algorithm used to sign certificates.  If you click on the text that says WEAK_SIGNATURE you will get a dump of the certificate chain. You can then copy paste that into a file and then run openssl x509 -in err.pem -inform pem -text to print out the cert. When we did this we found that in each failure case atleast one of the certificates in the chain has the following line  Signature Algorithm: sha1WithRSAEncryption

Google has been trying very hard to phase out use of SHA1 and move to SHA2 (aka SHA256) for a long time now. With the latest release of Google Chrome (Rel 57) they seem to have really tightened the noose. It appears with Chrome 57 even intermediate CA certs that chain directly to a local “trust anchor” will not be honored. See the following explanation from Google Security.

Starting with Chrome 54 we provide the EnableSha1ForLocalAnchorspolicy that allows certificates which chain to a locally installed trust anchor to be used after support has otherwise been removed from Chrome. Features which require a secure origin, such as geolocation, will continue to work, however pages will be displayed as “neutral, lacking security”. Without this policy set, SHA-1 certificates that chain to locally installed roots will not be trusted starting with Chrome 57, which will be released to the stable channel in March 2017.

Google Security Blog

 

Since we have Trisul running 24×7 in our office network,  I decided to look into the issue from a network viewpoint.  Trisul saves all SSL Certs as Full Text Documents (FTS) in the same format as the command “openssl x509..” . This makes it easy to search old traffic or more importantly to script detection and analysis as we will see shortly.

From the SSL FTS we found that for the failing Chrome 57 browsers the cert chain looked like this.

The fail cases have 3 certs

The first line is the Subject name, the second line is the Issuer, and the last line is the Signature Algorithm.

and for browsers  that worked fine we found 2 in chain.

 

In the fail cases, GeoTrust Global CA is an intermediate CA and Equifax is the root CA. Equifax signed GeoTrust using SHA1 and therefore Chrome rejects it. In the success cases, GeoTrust Global CA happens to be the root CA and it uses SHA2.

The SHA1 rules for Chrome are :

• SHA1 can be used by the root CA for self signing ; the signatures of the Root CA dont matter because the browsers trust them by the public key.
• When any signature in the entire certificate chain except the Root is signed by SHA1, it appears Chrome 57 and above are going to block it.

While I am yet to get my Chrome 57 to open any Google site, I tried adding the Chrome profile “EnableSha1ForLocalAnchorsPolicy” as mentioned in the Google Security Blog without luck.  I have a support ticket open so will update this post when I figure out how to solve this.

UPDATE: SOLVED – see below

Alert when you see usage of SHA1 signing on your network

After this I decided to write a little script to alert whenever a SHA1 signed certificate was seen in our network traffic. Using the Trisul LUA API this kind of detection is super easy.  The script is available on Github at detect_sha1.lua

Once we got the script installed on our office perimeter Trisul has been generating alerts whenever SHA1 is detected. Surprisingly most websites from Facebook,Twitter,Github,many Banking sites seem to have moved to SHA2 so the alert volume is low.

The following is a screenshot you can see the highlighted sha1WithRSAEncryption  signing algorithm in the alert

We developed Trisul Network Analytics 6.0 to be a platform where you can build various applications on top of it using a general purpose language like LUA and loosely coupled from the actual protocol fields. For scripts like these the flow is :

1. you decide what you want to work off – in this case SSL Certificates
2. you plug in to that stream
3. use standard text manipulations to get the data because Trisul documents are in standardized canonical format
4. feed something back into the Trisul Analytics stream as a result of your script

In this script the real action takes place in only one line

 

What to do with this alert ?

One of the concerns of this  deep Network Security Monitoring (NSM)  action that generates an alert is — now what? out analysts now have extra alerts to take care of !!

After turning on SHA1 detection we have about 190+ alerts of this kind. These alerts are tagged Medium/Low priority and gives us an idea of exactly how much of SHA1 is going on.  It could be an annoyance if  each alert to be handled in some way.  In those cases, you can modify the  same Trisul LUA Script a bit  to turn the alert into a metric.  When you turn alerts into a metric you will be able to answer :

• How many SHA1 signed certs did I see over time
• You will not be able to see the individual alerts

Hope these techniques are useful to security pros particularly those obsessed with visibility and metrics.

Get Trisul , the LUA API Documentation , and the Github samples at trisulnsm  Trisul is totally free for a rolling 3-day window and works on Ubuntu 14.04, 16.04, RHEL/CentOS 7.x

 

— UPDATE 26-Mar-2017 —

SOLVED : 

I was able to solve the issue and get Chrome 57 working again by “Untrusting Equifax Secure CA”. See my answer at Chrome Help Forum