Dan Kaminsky P H R E E B IR D S U IT E 1 .0 : IN T R O D U C IN G T H E D O M A IN K E Y IN F R A S T R U C T U R E
The V agaries O f Talking D efense Security Conferences are normally about discussing offense Necessary: We spent the 90’s thinking all security could be accomplished with Crypto ™ and Java™ Understanding the full scope of vulnerabilities is critical if we’re to fix anything However…
W e actually need to fix things every once in a w hile We’re finding lots and lots of new bugs The old bugs aren’t actually going away We have a choice Either keep finding the same problems for the next ten years Change the ground rules
M y N ew R ule It’s not enough to make security better We have to make security cheaper Security needs to drop in cost by two orders of magnitude (100x) That’s OK – security needs to increase in effectiveness by five orders of magnitude (10,000x) We’re building our economies on this foundation It doesn’t feel particularly solid, does it? Hard Truth: We are competing with insecure systems They’re (sometimes/appear) cheaper than getting owned But they’re not exactly cheap right now We can do a better job if we care to!
A V ery C om m on Scene
[That’ s A Strange U sernam e…]
[H eh W ait, That W orked?]
[W hat’ s that in authorized_keys2?!]
R edefining The Possible We’ve been trying to authenticate (federate) from one domain to another for years DNSSEC makes it easy. This is the power of the Domain Key Infrastructure We can’t do this if DNSSEC is hard to deploy So is it possible to make DNSSEC easy? Yes.
W hat I’ m R eleasing Phreebird Suite 1.0 Demonstration Toolkit for DNSSEC Phreebird: Zero Configuration DNSSEC Server Phreeload: Automatic DNSSEC Integration Engine Sample Code for End-To-End DNSSEC Integration Including the Phreeshell Federated Identity Code BSD Licensed – Lets get working on apps Why?
Introduction While we continue to fight the war against implementation flaws… …authentication continues to haunt us Verizon Business: Majority of compromises linked to credential failure Authentication, by in large, remains synonymous with one technology: PASSWORDS No passwords Default passwords Shared passwords Stolen passwords
W hy? They work. More importantly, they work cross organizationally “Anyone who thinks a large company is one organization, has never worked at a large company” Passwords are based on strings of text – we’ve figured out how to make them cross boundaries
The Problem From Workgroups, to Domains, to Forests, the model is based on an internal hierarchy, where authentication for outsiders is a special case Workgroups beget Domains (up) Domains beget Forests (up) Forests beget manually established Federations / Cross Forest Trusts (out) However, authenticating outsiders is not actually a special case
R eality Groups Outside Your Hierarchy Clients Customers Vendors Partners Contractors Outsourcers Governments (and not necessarily your own) A lot of people still need to be authenticated Couldn’t there be a hierarchy that sits above all of them?
The Three (B ad) C hoices M-to-1: “Everybody Trust Me!” Keeps getting tried Almost always leads to the guy in charge seeking rents Always leads to guys not in charge trying to get in charge, so they can seek rents M-to-Any: “Everybody Trust The Cabal” Basis of X.509 CAs Always leads to too many people in the Cabal for any serious trust M-to-N: “Everybody, Figure Out Who You Trust” Every new major group has to be manually brought into the Federation Doesn’t scale
The O ne G ood C hoice DNS (newly enhanced with DNSSEC) Starts out a M-to-1 system, but… Politically limited – massive governance on ICANN It’s so hard to get even legitimate content into the root, that imagine getting bad content in Technically limited The root hosts such a small subset of the final data, that it’s a weak point to attack anyway Huge install base All customers, vendors, partners, contractors, etc are already in it – they’re receiving emails, aren’t they? Already trusted DNS is how they’re receiving emails
D N S is actually pretty sim ple DNS: Ask a question, get an answer Ask a question, get a referral Alice: Jenny’s number? Ask Travis. Travis: Jenny’s number? Ask Charlie. Charlie: Jenny’s number? 876-5309
D N SSEC C H A N G ES EV ER YTH IN G (N o, it DNS ’ S s E s C im ple too) Ask a question, get an answer and a signature Ask a question, get a referral and a signature Alice: Jenny’s number? Ask Travis™ Travis: Jenny’s number? Ask Charlie™ Charlie: Jenny’s number? 867-5309™ Yes, that’s mostly it. A lot of the complexity came from optional magic
The G eneral Idea DNSSEC lets DNS store trusted data Use this data to bootstrap trust in various protocols, as per a globally shared namespace Open Questions Can DNSSEC be deployed easily? Will it function end to end? Does it actually help real world applications? Lets see some working code… First: Can DNSSEC be deployed easily?
A Sim ple B ind9 Install W ith A H andful O f Sm all Zones
Step 1: C hange The Port To 50053
Step 2: Launch Phreebird
Step 3: There is no step 3
O K , you have to tell your registrar… (G oD addy for now )
It w ants a D S record…
W here can w e get these values?
Just R un D ig… # dig +short @127.0.0.1 remote- support.org ds 12839 7 1 619EB6EB0521605393FA6035366079 49AE58EDD6
Just paste ‘ em in…
A nd, that’ s it!
D N SSEC is deployed. D O N E. (dnsviz.net)
W elcom e to Phreebird, R eleased Today! Phreebird: A realtime DNSSEC proxy that sits in front of any DNS server, supplementing its responses with signed answers Most of DNSSEC’s problems have come from the requirement to be able to operate offline DNSSEC can also be done online, like TLS, IPSec, Kerberos, and SSH Phreebird can be deployed in minutes No key generation phase No zone signing phase Doesn’t care how many zones you have No configuration It Just Works™
Phreebird Efficiency Signatures are cached as they’re generated Answers are sacred – whatever answer happens to be delivered, based on time/geo/load/mood, will still get delivered Nonexistence records are dynamically generated “White Lies”, only for NSEC3 instead of NSEC In NSEC3, names are turned into numbers “There are no names between 1 and 3” Under heavy load or attack, server prioritizes positive replies over NSEC3 sigs Under overload conditions, SERVFAIL is returned NSEC3 does not actually stop SERVFAIL – but servers don’t cache it
Isn’ t O nline K eysigning D angerous? Many protocols use online keysigning SSL SSH IPSec DNSSEC needed to be able to support offline keys The root should not have the keys online Massive TLDs shouldn’t need to have key material in every location/jurisdiction they have hosting But supporting online keys != requiring online keys
The C ost O f O ffline O peration PGP/GPG What happens when you receive mail from someone not on your keyring? What happens when you have to send mail to someone not on your keyring? What happens when a key expires? What happens when a key is lost? What happens when a key is stolen?
If you can’ t handle failures, you can’ t succeed Offline key management is unable to handle special cases well In DNSSEC, you can quickly publish new data, and client can quickly retrieve it. The special cases get first class support. Revocation stops being an exceptions. Keys expire all the time, get over it!
Is There O ther M agic? There is a lot of obscura in the DNSSEC realm that we’ve been filtering through How do we tunnel trusted records to registries when the registrars in front of them don’t implement DNSSEC? How do we manage rollover and expiration? How do we keep clocks in sync, especially given the chicken-and-egg relationship between NTP and DNSSEC? If you’re interested – ask me after this talk. Right now, I want to focus on applications.
W hat A pp D evelopers N eed App developers don’t want to be crypto developers! They don’t have to be masters of distributed databases, but they get to benefit from one every day when they resolve DNS names App developers need to be able to easily authenticate entities outside their organization It’s no drama to look up a user’s mail server. It’s epic drama to recognize a user’s smartcard Can DNSSEC fix this?
End-to-End Security for D N SSEC Problem: DNSSEC was originally envisioned to allow name servers (not desktops) to be able to verify data Desktops would just get a “bit” declaring everything safe Reality: I like Starbucks, but I’m not trusting their name server to tell me anything is safe Is it possible to efficiently determine a trust chain via DNSSEC, at the desktop?
Yes, in about 10 lines of code using LD N S
A pproaches for End-To-End Trust (A ll Im plem ented H ere) Chase (via ldns) Given the signature for www.foo.com, discover the signature up from foo.com, then com, then the root. Trace (via libunbound) Given the signature for the root, discover the signature down from the root, then com, then foo.com. Basically, just embed a recursive DNS resolver in client Load issues! Wrap (via Phreebird-modified ldns) Encapsulate DNS in an HTTP request to a compliant server Useful when behind inclement firewalls (common!) Pack…
X .509 Packing Inspired by Brett Watson’s quote “You have to be willing to separate the content of DNS from the transport of DNS” X.509 as a chain delivery mechanism is pretty broken (see 2009 Black Ops of X.509 for details) X.509 as a way to transfer arbitrary payloads as part of a chain bound to a TLS session…is pretty solid Why not tunnel DNSSEC data re: a TLS endpoint through DNSSEC?
So Adam Langley at G oogle sent m e a p rivate unofficial build of C hrom e…
That certificate w as self signed……w ith a D N SSEC chain em bedded.
So, do w e add ldns/libunbound to each package, one by one? Eventually, possibly Works very well for PhreeShell, the Federated OpenSSH Demo at the start of the talk Sample code for this also part of Phreebird Suite But in the short term? To prove value? On Linux/Unix, SSL is handled via OpenSSL Specifically, X509_verify_cert A nice and self contained library call… hmm…
PhreeLoad: Integrating D N SSEC into O penSSL via LD _PR ELO A D Prior Work: libval_shim from Russ Mundy @ Sparta Great work! Two major differentiators 1) Written before the root was signed, so no provisions for chasing a signature down to the root 2) Validated the results of a DNS query – which might just be an IP address, attackable via other means PhreeLoad operates at a different layer Given software that’s attempting to achieve end-to- end security, replace/augment the auth layer with DNSSEC
C U R L to a self signed certificate # curl https://www.hospital-link.org curl: (60) SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICAT E:certificate verify failed … If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.
A fter Loading Phreeload # phreeload curl https://www.hospital- link.org <pre> Now this is a story all about how my life got twisted upside down and id like to take a minute just sit right there ill tell you how i became the prince of a town called Bel-Air
Enabling D ebug # phreeload curl https://www.hospital-link.org Resolving www.hospital-link.org Secure result recieved. V:1 Hash Algorithm:sha1 Hash:5e0905b0eafd35d59f1b178727d4eaadd06c415d STS:0. Secure Reneg:0 Livehash:0 Hash Range:(null) Hash detected: sha1 5e0905b0eafd35d59f1b178727d4eaadd06c415d Hash Validated DNSSEC validated <pre> Now this is a story all about how my life got twisted upside down
W hat A re W e A ctually Putting Into D N S? www.hospital-link.org IN TXT "v=key1 ha=sha1 h=5e0905b0eafd35d5…“ v=KEY1 Version is KEY1 ha=sha1 Hash Algorithm is SHA-1 h=5e0905b0eafd35d5… Hash of certificate is h=5e0905b0eafd35d5…
A lternate K ey R etrievals lh=[0|1]: LiveHash Whether, upon a failed resolution for www.foo.com, a second lookup to _tlshash- f1d2d2f924e986ac86fdf7b36c94bcdf32beec1 5.www.foo.com should be attempted. (Not done by default due to performance implications.) hr=[cert|pubkey]: Hash Range If set to "cert" (or unset), the hash validated is the hash of the entire certificate. If set to "pubkey", the hash validated is the hash of the public key in the certificate.
Extensible M etadata Support sts=[0|1]: Strict-Transport-Security: Whether insecure (http) access to www.foo.com should be allowed This is how we address Firesheep! It’s too expensive / tricky right now to get certs for everything It’s too expensive / tricky right now to shut down insecure channels after secure ones exist DNSSEC fixes things by making security cheaper. sn=[0|1]: Secure Negotiation: Whether secure renegotiation will be present at this HTTPS endpoint
W hy This Particular Schem a? Have to go live with something – this should not be seen as canonical or consensus However… Last four protocols to try to do complex things in DNS went TXT DKIM SPF HPA (in GPG) IPSec Don’t want a record compiler Don’t want to require upgrading servers / web Uis Really don’t want another binary protocol If you notice, we’ve sort of abandoned ASN.1 for XML/JSON For a reason
All O penSSL apps m eans All O penSSL Apps Postfix Postgres MySQL Apache Want to start working on client certificates that actually work? Much easier now that we have a signed root Welcome to DKI But how do we get this working on browsers? Most not running on Linux Most not running with OpenSSL
Phoxie: R em ote SSL V alidation For A ll B row sers
B row ser Lock In IE
Also: A N eat Toy! Self C ertifying U RLs (Inspired by SFS)
It even w orks by IP!
Self C ertification M odes: U seful? Possibly – it’d be nice if applications had a clean way to directly declare the actual key they wanted to use. This approach adds the key to the domain being connected to Works well for HTTP-based APIs Works poorly for OS sockets Admittedly, those are ugly domain names But they work for free
W hat A bout W indow s? Linux makes it very clean, to hook individual functions inside of major APIs Windows makes it harder, but not impossible PhreeCAPI: A DLL Injector for CryptoAPI Target Application: Outlook 2007 Problem: S/MIME certificates are free and automatically issued. Not much confidence in them. Could we use DNSSEC to achieve exclusion, the primary property that makes DNSSEC better than X.509?
So, w e have this signed em ail from dan@ the- bank.org (N ot exactly the m ost com pelling im age)
W e just added the checker, didn’ t put any records into the D KI
W ell, there’ s the fingerprint of the canonical certificate…
So, lets put this (D ELIB ER ATELY O VER SIM PLISTIC ) thing in the D KI dan._smpka.the-bank.org. IN TXT ‘v=KEY1 ha=sha1 h=460c1be3f86d39f537864700560f3 7aef6ce3775'
N ow w e have m ail from the bank, signed by the only key in the w orld that can sign it.
So…w hy not m ake it look even better?
W e’ ve B een Prom ising Secure Em ail For O ver A D ecade DNSSEC is how we can deliver it CAs remain useful – DNSSEC only says that this is the-bank.org. It doesn’t say that this is “The Bank.” That is what EV is for We can (and should) port EV to email With added confidence in the source of email, even cross organizationally, we could reasonably implement meaningful UI around message security We are blocked from doing that today because we have so little confidence in either success or failure
C onclusion The Domain Key Infrastructure is real Federated OpenSSH works Browser locks work Easy application integration works Email works The CA’s still matter! This is real, and this is a big deal Phreebird Suite 1.0 is on blackhat.com’s website! Enjoy!