The Future of SSL

1. The Future of SSL Spring 2018 – Secure E-Commerce Jeremiah Benes

2. Overview DNSSEC CAA Records Certificate Transparency

3. Motivation • Self-professed SSL nerd • SSL is everywhere and it’s not going away anytime soon • SSL is complicated and the industry is slow-moving • SSL is used to protect sensitive online transactions – compromising it can have significant ramifications • How is SSL changing? What new technologies are improving SSL?

4. Scenario 1: DNS Cache Poisoning- A Case for DNS Security • DNS queries are unencrypted and can be modified in transit • A network attacker can modify host records, mail (MX records), and more • Example: Poison mail server to route mail through fake provider

5. Solution: DNSSEC • DNSSEC: Domain Name System Security Extensions • Allows DNS responses to be authenticated (not encrypted) • DNS responses are digitally signed (includes all DNS records) • Each name server signs response provided to client • Ensures integrity of the response • ~90% of TLDs use DNSSEC • ~12% of domains use it

6. DNSSEC Flaws • DNSSEC is not perfect • The hierarchical model of trust relies on a root authority • This root authority is controlled by ICANN which was controlled by the US • Who manages key and how do you rotate them? (hold a ceremony) • DNSSEC records increase computational load • Larger DNS records (5-7 times larger) require more transit time • Verifying signatures requires additional computation • There is a lack of DNSSEC diagnostic and management tools

7. Scenario 2: Mis-Issued Certs • Recall: There have been many previous instances where certs are issued to the wrong party 2011: Comodo and DigiNotar CAs hacked, issue certs for Gmail, Yahoo! Mail 2013: TurkTrust issues cert for gmail.com 2014: Indian NIC for Google and Yahoo! Domains 2015: MCS issues certs for Google domains • Takeaway: certs continue to be incorrectly issued and cannot solely trust the CA

8. Solution: CAA Records • CAA: Certification Authority Authorization • Goal: prevent cert mis-issuance • Idea: the owner of a domain name can add a CAA record specifying which CA(s) can issue certs for the domain • 8 September 2017: All CAs must check for CAA records

9. CAA Record Examples • Records are additive – having multiple will apply all of them • This record allows: • Allows Digicert to issue for utulsa.edu • Allows Let’s Encrypt to issue for *.utulsa.edu (e.g. secon.utulsa.edu) • Notifies security@utulsa.edu when a cert issue is attempted

10. Dissecting CAA Records • Three record property types: • Issue: specifies which CA can issue for a given domain • Issuewild: specifies which CA can issue wildcard domain certs • Iodef: specifies an email address to notify of issuing violations

11. CAA Flaws • Unfortunately, CAA has flaws… • A compromised CA can still mis-issue certificates for a domain • Browsers do not check CAA records, only CAs do • CAs check up the hierarchy for CAA records • E.g. new.blog.utulsa.edu. -> blog.utulsa.edu. -> utulsa.edu. -> edu. • TLDs can set CAA records for domains if domains don’t specify • CAs also follow CNAME records to check for CAA records • E.g. travel.utulsa.edu has a CNAME record for concursolutions.com • Should Concur Solutions be able to set CAA records for travel.utulsa.edu? • If a domain does not have DNSSEC, the CA can ignore the CAA records

12. What now? • CAA records aren’t good enough • We need a system that: • Makes it impossible for a CA to issue a cert without the cert being made known to the owner • Provides domain owners the ability to audit the system to see if certs were mistakenly issued • Protects users from being tricked by maliciously issued certs

13. Solution: Certificate Transparency • If all certificates are public, so are mis-issued certificates • Maintain a public log of all certs issued (blockchain anyone?) • 3 key roles in this system:

14. What do we gain? • Earlier detection of mis-issued certs and rogue CAs • Detection with CT typically takes a few hours rather than days, weeks, or months • Faster mitigation of mis-issued certs and rogue CAs • Malicious certs still need to be revoked, but this can be done more quickly because its easier to find the certs in the first place • Better oversight of TLS • Anyone can monitor cert issuances because the system is open and there are many open-source implementations

15. Making It Work • The open, append-only nature of the lists can be audited by anyone • And it has been! (link) • Likewise, anyone can create their own certificate transparency list • Now certs are being logged, how does the check work? • Browsers look for cert in log(s) when browsing to confirm validity • This is a violation of privacy • It greatly increases latency • Server provides SCT (Signed Certificate Timestamp) to the browser • SCT can be embedded in the cert itself when it is issued (most common) • Can also be stapled to OCSP response or presented using a TLS extension (provides backward compatibility)

17. Logging Revisited • This system relies on third-party logging to function correctly • What if multiple CAs manipulate logs? • Browsers only use a vetted list of logs meeting certain criteria • Users are only protected if all certs are logged • Chrome has required CT for all EV certs since 1 January 2015 • Chrome will require CT for all public certs issued after April 2018 • This change is huge! • But how do you efficiently maintain a log of this size?

18. Storing All Issued Certs • All certs are logged in an append-only list • What is the most efficient way to store this data? • Need to make computations for both log operators and auditors low • Hash chain: easy to insert records, difficult to audit/validate (~n/2 scale) • Merkle tree: easy to insert and audit • Insertion and validation costs are ~log2(size) • Insertion and validation are low cost • Verification of a log with 10 million certs requires computation of 24 hashes • 20 million certs requires a 25-hash computation • Further discussion can be saved for a data structures course 

19. Final Words on CT • CT is a new requirement but it has been around for some time • First implemented by DigiCert in September 2013 • Required of Symantec for all certs on 1 June 2016 because of many previous mis-issuances • Doesn’t solve all problems/attacks • Website owners must check logs to ensure a cert was not mis-issued • Certificate revocations are still difficult and rarely done • See CT in action

20. Questions or Comments?

21. References • DNSSEC stats: http://rick.eng.br/dnssecstat/ • DNSSEC graphics and info: https://www.cloudflare.com/dns/dnssec/ and https://www.cloudflare.com/dns/dnssec/universal-dnssec/ • CAA records: https://support.cloudflare.com/hc/en-us/articles/115000310792-Configuring-CAA-Records- and https://blog.cloudflare.com/caa-of-the-wild/ • CAA record creator: https://sslmate.com/caa/ • Certificate transparency and associated graphics: https://www.certificate-transparency.org/log-proofs-work, https://www.certificate-transparency.org/how-ct-works, https://www.certificate-transparency.org/what-is-ct, https://www.certificate-transparency.org/benefits, https://blog.cloudflare.com/introducing-certificate-transparency-and-nimbus/, https://blog.cloudflare.com/a-tour-through-merkle-town-cloudflares-ct-ecosystem-dashboard/