Legacy of Heartbleed: 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 – Cloudbleed 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 Firefox 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: Google 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: Microsoft Internet Explorer / 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: https://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: Google Chrome 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) Opera (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 .