Legacy of : MITM and Revoked Certificates

Alexey Busygin [email protected] NeoBIT Notable Private Key Leaks

• 2010 – DigiCert Sdn Bhd. issued certificates with 512-bit keys • 2012 – Trustwave issued CA certificate for one of its customers DLP system • 2013 – DigiNotar CA was totally compromised • 2014 – Heartbleed bug caused certificate revocation storm. 500000+ certs to be revoked • 2015 – RSA-CRT private key leaks • 2017 – bug in Cloudflare reverse proxies

2 Checking Certificate Revocation Status: Certificate Revocation Lists (CRL)

• CAs publish CRLs – lists of revoked certificate serial numbers • Normally certificate contains URL of the corresponding CRL

Why it’s not OK?

CRLs are not appropriate for online checks:

• Excess size (up to 1 MB) • Vulnerable to replay attacks

3 Checking Certificate Revocation Status: Online Certificate Status Protocol (OCSP)

• CAs maintain OCSP responders answering with certificate revocation status • Normally certificate contains URL of the OCSP responder • OCSP provides optional replay attack protection

Why it’s not OK?

• Slows down connection establishment • Browsing history leaks to CA • OCSP responder is DDoS target

4 Checking Certificate Revocation Status: OCSP Stapling

• No browsing history leaks • Choose one: o Replay attack protection o TLS server side OCSP response caching:  Minimal impact on connection establishment time  Reduced load on OCSP responder

Why it’s not OK?

• Stapled OCSP responses are optional and may be stripped by MITM • OCSP responder is DDoS target (if replay attack protection is enabled)

5 Checking Certificate Revocation Status: Vendor Specific Solutions

• Software updates • Revocation information pushes

Why it’s not OK?

• Offline revocation check • Not controlled by end users • What about private CAs?

6 Man-in-the-Middle Attack Scenario

Use revoked certificate and block revocation info

7 Default Revocation Checks: Mozilla

Check local OneCRL store Fall-back Check stapled OCSP response positions Query OCSP responder explicitly Why it’s not OK?

• Soft fail → MITM vulnerable • OCSP replay attack protection is not supported • OCSP stapling for CA certificates is not supported • Online checks for DV CA certs are not performed Certificate is valid

8 Default Revocation Checks: Chrome

Check stapled OCSP response Fall-back Check local CRLSets store positions Query OCSP responder explicitly (for EV certificates only) Why it’s not OK?

• Soft fail → MITM vulnerable • OCSP replay attack protection is not supported • OCSP stapling for CA certificates is not supported Certificate is valid • Online checks for DV CA and EE certificates are not performed

9 Default Revocation Checks: / Edge

Check untrusted certificate store Fall-back Check stapled OCSP response positions Query OCSP responder explicitly Fetch CRL Why it’s not OK?

• Soft fail → MITM vulnerable • OCSP replay attack protection is not supported • OCSP stapling for CA certificates is not supported Certificate is valid

10 Why is hard fail not enforced?

Adam Langley explains: ://www.imperialviolet.org/2014/04/19/revchecking.html

• CA infrastructure becomes a single point of failure • CA infrastructure becomes a DDoS target • Increases CA maintenance costs (more network bandwidth and DDoS protection required) • Increases number of connection failures in noisy networks • Captive portals frequently deny access to OCSP responders

11 Hard Fail Enforcement: Mozilla Firefox

Why it’s still not OK?

• Online checks for DV CA certificates are not performed • Vulnerable to OCSP or CRL replay attacks • Hard fail is enforced for all sites

12 Hard Fail Enforcement:

Why it’s still not OK?

• Vulnerable to OCSP or CRL replay attacks • Hard fail is enforced for all sites

13 Hard Fail Enforcement: Microsoft Internet Explorer

Edit registry:

HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Why it’s still not OK? Internet Explorer \ Main \ FeatureControl \ FEATURE_WARN_ON_SEC_CERT_REV_FAILED \ • It doesn’t prevent attack iexplore.exe = 1 • Vulnerable to OCSP or CRL replay attacks • Hard fail is enforced for all sites

14 Hard Fail Enforcement: Squid Proxy

Enforces hard fail for predefined set • TLS decryption of sites (SslBump feature) • Custom certificate verification procedures (SSL Server Certificate Validator feature) • Optional transparent mode (TPROXY or WCCP features)

Why it’s still not OK?

• Proxy decrypts TLS traffic

15 Future Revocation Strategies

Not all services require paranoid revocation checks.

Strict Lightweight revocation status checking mode revocation status checking mode

• Online checks • Offline checks • Replay attack protection • Short-lived certificates • Hard fail

16 Strict Checking

• Service indicates that strict checking is required via certificate extension field • OCSP stapling with replay attack protection for entire certificate chain • Hard fail

RFC 7633 TLS Feature Extension as strict checking requirement indicator

17 Strict Checking: OCSP Availability Enhancements

• Session resumption via session IDs or session tickets to reduce OCSP responder loads • Load balancing between independent CAs:  Reduce loads  Mitigate DDoS  Protect against OCSP responder failures

18 Strict Checking: Browser Adoption

TLS Feature OCSP replay OCSP stapling Session Extension attack for CA resumption protection certificates (session ID, session ticket) Chrome (v.59) Edge (v.40) IE (v.11) Firefox (v.54) (v.46)

19 Lightweight Checking

• Online checks are not performed • End entity certificates with short validity period • Certificates are auto renewed • Intermediate CA revocation information pushes (CRLSets or OneCRL like) • Open standard for TLS client/revocation info pushing service integration is required

20 Takeaways

• Certificate revocation is broken • Use secondary browser configuration with enforced hard fail revocation checking to enhance your personal security • Use proxy with enforced hard fail revocation checking to enhance security of organization • Wait for new revocation checking strategies to be implemented and adopted

21