"sunsetsha1" handler detecting TLS certificates using SHA-1 expiring during or after sunset period

[mkenne11]

A "sunsetsha1" handle was added to test for certificates using the SHA-1 signature algorithm and that expire during or after the Google Chrome SHA-1 sunset period. Changes were made to the mitm daemon and Android client for this handler.

See Chromium blog post for more details:
http://blog.chromium.org/2014/09/gradually-sunsetting-sha-1.html

[mkenne11]

This request is intended to address issue #60.

[chadbrubaker]

This should probably be a data handler with the rest of the TLS check stuff in https://github.com/google/nogotofail/blob/dev/nogotofail/mitm/connection/handlers/data/ssl.py, once #83 lands you can get the Certificate chain bytes pretty easily and then check in a passive handler.

Also I should add a data handler that handles buffering/parsing TLS records since we're currently duplicating a lot of code. I'll file a blocking issue :)

[mkenne11]

I changed the sunsetsha1 handler to be a data handler and passive. I also modified it to parse the certificate chain bytes (the new handshake "Certifcate" class) when checking the certs signing algorithm.

I am accessing the Certificate.certificates list to check each cert in the chain of trust. I was hoping to access the certificate attributes using the OpenSSL API attributes (e.g. .get_signature_algorithm()). Is the a way of casting the each cert byte string to a OpenSSL certificate type? Or maybe I'm off track ...

Here's the current handler commit with the relevant line highlighted. Thanks in advance.
https://github.com/mkenne11/nogotofail/blob/241d204cb218e48576509f17c2df5743394e021a/nogotofail/mitm/connection/handlers/data/ssl.py#l130

[mkenne11]

It's OKI worked out how to cast a certificate byte string to a pyOpenSSL certificate object.

When checking the signature algorithm of each certificate in the chain - do I need to check the algorithm for just the first certificate? Or the signature of the intermediate certificates and root certificate as well?

I assume I only need to check the signing algorithm of the first cert in the certificates list (index 0) which signs the encrypted message - but I'm happy to be told otherwise :)

[chadbrubaker]

Probably best to only go with the leaf cert.
On Thu, Sep 10, 2015 at 5:22 AM Michael Kennedy notifications@github.com
wrote:

It's OKI worked out how to cast a certificate byte string to a pyOpenSSL
certificate object.

When checking the signature algorithm of each certificate in the chain -
do I need to check the algorithm for just the first certificate? Or the
signature of the intermediate certificates and root certificate as well?

I assume I only need to check the signing algorithm of the first cert in
the certificates list (index 0) which signs the encrypted message - but I'm
happy to be told otherwise :)

—
Reply to this email directly or view it on GitHub
#78 (comment).

[mkenne11]

Thanks Chad. I revised the handler to check only the leaf node for use of SHA-1 during or after the sunset period.

I'll keep an eye out for the data handler that handles buffering/parsing of TLS records to land, then finalize this handler as well the noforwardsecrecy handler (PR # 79).

[mkenne11]

I changed the sha-1 handler to use the new TlsRecordHandler.

I also included a change to exclude compiled Android client and test harness files (APKs) from Git, by including these in the project .gitignore files. I built the projects in Android Studio and the default build path "app/" where the APKs are created.

It worked fine for me in testing - please let me know if you spot any issues. Happy to fix :)

[mkenne11]

Firefox is alerting on intermediate certificates using SHA-1 which expire after the sunset date.
https://blog.mozilla.org/security/2015/10/20/continuing-to-phase-out-sha-1-certificates/

Currently I'm only alerting when the leaf certificate uses SHA-1 after this date. Do you think there is much value in alerting on intermediate certificates as well?

[mkenne11]

I added alerts for intermediate certificates who use SHA-1 as the signature signing algorithm. I noticed both Firefox and SSL Labs alerts on intermediate certificates.

I raised the intermediate certificate alerts as a WARNING as the risk to the client should be small. I believe for an attacker to exploit this vulnerability they would need to have a cert with the same (SHA-1) hash value as the intermediate cert and convince the root CA to sign it (but I'm not an expert :) ).

[mkenne11]

Improved variable name consistency.