1 / 21

The Future of SSL

Discover how SSL is transforming with DNS Security Extensions (DNSSEC) and Certification Authority Authorization (CAA) Records, leading to the enhanced security of Certificate Transparency. Explore the impacts, flaws, and benefits of these technologies.

denverd
Download Presentation

The Future of SSL

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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)

  16. 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?

  17. 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 

  18. 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

  19. Questions or Comments?

  20. 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/

More Related