The Future of SSL & DNS Security: Enhancements and Solutions
In the rapidly evolving landscape of online security, SSL and DNS security play crucial roles in safeguarding sensitive transactions. Explore upcoming technologies, challenges, scenarios, solutions, and the quest for improving the integrity and authenticity of digital interactions.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
The Future of SSL SPRING 2018 SECURE E-COMMERCE JEREMIAH BENES
DNSSEC Overview CAA Records Certificate Transparency
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?
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
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
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
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
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
CAA Record Examples Records are additive having multiple will apply all of them Name Type Value 0 issue "digicert.com" utulsa.edu. CAA 0 issuewild "letsencrypt.org" 0 iodef "mailto:security@utulsa.edu" 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
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 Name Type Value 0 issue "digicert.com" utulsa.edu. CAA 0 issuewild "letsencrypt.org" 0 iodef "mailto:security@utulsa.edu"
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
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
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: Log Operator Auditor Monitor Manages the append- only list of certs Add cert to list within a max merge delay (MMD) Provides submitter a Signed Certificate Timestamp (SCT) Keeps log operators honest Ensures SCTs are honored and certs are added properly Cryptographically verifies logs Alerts a website of mis- issuance This is often offered as Facebook s Transparency Monitoring Facebook s Transparency Monitoring a service (e.g. Facebook s Transparency Monitoring) Open source monitors allows someone to create their own Facebook s Transparency Monitoring
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
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)
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?
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
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
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/
