Embed Size (px)
Citation preview
Transparency, Trust Agility, Pinning (Recent Developments in Server Authen;ca;on)
Trevor Perrin <[email protected]>
Cer;ficate Authori;es
Browser Web Server
Web server requests cert, typically authen;cated via email
Server presents cert to Client
CA
Web PKI
• 50+ Root CAs, unknown number of Sub CAs
• Most CAs can issue certs for any domain
• Known CA failures in last 2 years: – Comodo -‐ hacker issued bad certs – Diginotar -‐ hacker issued bad certs for MITM – Trustwave -‐ issued sub CA to customer for MITM
– Turktrust -‐ issued sub CA by mistake, used for MITM
Can we recover from bad certs?
Revoca;on
• Online lookups (CRLs, OCSP) – Slow – Leaks browsing history – Connec;on could fail (security/reliability tradeoff)
• Fresh signatures from CA (e.g. OCSP stapling)
• Out-‐of-‐band update (soZware update, crlsets) – (Chrome current crlset = ~24000 entries, ~250 KB)
Change who we trust?
DNSSEC/DANE
• DNSSEC adds key and signature records to DNS
• DANE adds records for applica;on keys
• Considered as a PKI: – Fewer trusted par;es (ICANN root, TLD registry, registrar, and your own DNSSEC keys)
– Builds on exis;ng authen;ca;on rela;onships
DNSSEC/DANE challenges
• “Last mile” problem: gecng DNSSEC to clients – Fetching DNSSEC records over DNS has reliability and latency problems
– Stapling needs universal deployment before a “fail-‐if-‐absent” client policy
• DNSSEC is not widely deployed on domains – More complex than cert requests
Change how much we have to trust anyone?
Cer;ficate Transparency
• Goals – CAs publish all cer;ficates
• Challenges – What if they don’t? (mistakes, hacks, inten;onal, etc.)
• Laurie and Langley et al, Google, started 2011 – IETF draZ in progress
Logs and Monitors
Browser Web Server
CA
Monitors
Logs
Monitors watch logs and send revoca;ons
CAs send certs to Logs
Logs periodically publish hash trees of all certs
CT Part 1 – Log Signing
Browser Web Server
CA sends each pre-‐signed cert to a quorum of logs, gets back “log signatures” to embed in cert
Browser rejects any cert without quorum of log sigs
CA
Logs
Monitors
Monitors watch logs and send revoca;ons
CT Part 2 – Online Log Checking
Browser Web Server
Monitors
Log
Monitors send revoca;ons and hash tree roots.
Browsers report certs not in tree.
Browsers asynchronously fetch and check inclusion proofs for each cert they see
Cert Transparency Challenges
• Requires mul;ple high-‐availability logs
• Log signatures need universal deployment before a “fail-‐if-‐absent” policy – But can be done by CAs
• Requires good monitoring and revoca;on, and an infrequently-‐breached CA system
Don’t use CAs?
CAs again
Browser Web Server
Web server requests cert CA
Convergence
Browser
Monitors
Web Server
Browser sends server name and hash of cert to monitors
query
Convergence
Browser
Monitors
Web Server
Monitors probe server to confirm the cert
Browser sends server name and hash of cert to monitors
query probe
Convergence
Browser
Monitors
Web Server
Network Perspec;ve
Trust Agility
Trust Agility in ac;on
Monitors
Browsers
Observable Facts (e.g. observed certs, public log)
Observa;onal Trust Modes
• Net Perspec;ve: “Do you see what I see?”
• Key Con;nuity: “Is this the same as before?”
• SSH, Convergence, Perspec;ves, etc.
• Ra;onale: Internet works for most people most of the ;me
Convergence Challenges
• Online lookups – Performed on first connec;on or key discon;nuity
– Costly infrastructure – Performance and reliability risk
Observa;onal Trust Challenges
• Key Con;nuity – Doesn’t protect ini;al connec;on – Doesn’t handle key changes well
• Network Perspec;ve – Handles ini;al connec;on and key changes at cost of online lookups
– Doesn’t handle mul;ple-‐keys-‐per-‐site well
Observa;onal Trust
Browser
Monitors
Web Server
Key Con;nuity
Trust Agility Network Perspec;ve
Can we improve observa;onal trust…
…with some help?
Browser
Monitors
Web Server
Key Con;nuity
Trust Agility Network Perspec;ve
“I’m using keys X,Y,Z for the next week”
Server Asserted Pinning
• Improves reliability (server has made a commitment) – Regardless of mul;ple-‐keys-‐per-‐site or key change
• Can help with ini;al connec;on / online lookup – Gives us longer-‐lived “tokens” which can be distributed in different ways
Pins
• Pin = (Name, Authen;ca;on Data, Expira;on) • Authen;ca;on Data
– Public key(s) – Opt-‐In (HSTS, DNSSEC, Cer;ficate Transparency)
• How are pins asserted?
• How are pins distributed?
Distribu;ng Pins
• Preloaded pins
• Key con;nuity
Secure Links
Browser
Introducer Website
Web Server
Web page with secure links
Secure Links
Browser
Introducer Website
Web Server
Web page with secure links
E.g. trusted search engine
Observa;onal Trust
Secure Links
<a link-‐security="expiry=1357849989; pin-‐sha256=YWRmYXNkZmFzZGZhc2RmcXdlcnF3ZXJxd2VycXdlcnF=;
pin-‐sha256=LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=;"
href="hyps://www.example.com">a secure link!</a>
Secure Links
• Use current trust model on the web • A broken link is the introducer’s fault
• Build on trust in the web’s major “hubs” • Search engines, social networks, link shorteners
• Also useful for loading page resources securely • i.e. JavaScript libraries
• Feedback welcome: www.secure-‐links.org
Asser;ng Pins
• HPKP – HTTP layer, pins to EE keys and/or CA keys
• TACK – At TLS layer, pins to self-‐chosen signing key
Pin Asser;on Challenges
• Risks to relying party – Bad pins
• Risks to asser;ng party – Key loss – Key compromise
– Inflexible / impossible key changes
Pin Ac;va;on
end
30 days
Ac;ve periods
ini;al current
30 days
Ac;ve period dura;on = MIN(30 days, current – ini;al)
pin 1
Pin flexibility
Signing key
key 3
pin 2 pin 3
Ex: (K1,K2,K3,K4) (K3,K4,K5,K6) …
key 1 key 2 ShiZing pins could use CA or EE keys
Pin Redundancy
• Pin to mul;ple public keys (HPKP) – E.g. several popular CAs and your TLS key
• Distributed backup / delega;on of private key – E.g. TACK
Summary
• Lots to think about
• Oh, and we can combine lots of these things! – Sovereign Keys ~= transparency + pinning
Thanks!
• hyp://dnssec-‐deployment.org • hyp://www.cer;ficate-‐transparency.org • hyp://convergence.io • hyp://tack.io • hyp://tools.ie}.org/html/draZ-‐ie}-‐websec-‐key-‐pinning
• hyps://www.eff.org/sovereign-‐keys • hyp://www.secure-‐links.org
