Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Weitere Verwandte Inhalte

Domain Key Infrastructure (From Black Hat USA)

  1. 1. Black Ops of Fundamental Defense:Introducing theDomain Key Infrastructure<br />Dan Kaminsky<br />Chief Scientist<br />Recursion Ventures<br />http://www.recursion.com<br />
  2. 2. So. Another DNS Talk.<br />There may have been some…consequences…of the last one<br />After 15 years of work, the DNS root is signed<br />Even more surprisingly…<br />It’s actually a good thing.<br />
  3. 3. This is my 11th year at Black Hat<br />It’s been quite the ride!<br />Contrary to popular belief, I haven’t always been obsessed with DNS<br />Once upon a time, I was obsessed with SSH<br />My first Black Hat talk got a feature put into it!<br />Dynamic Forwarding / -D flag<br />Anyone notice how excited I’ve been about DNSSEC?<br />This talk is about why.<br />
  4. 4. Introduction<br />I’m Dan Kaminsky, and this is my 11th Black Hat talk.<br />I’ve not always been talking about DNS<br />Ten years ago, my talk was all about SSH<br />SSH (Secure Shell) is the most popular package for remote system administration in the world<br />We used SSH to administer remote machines<br />On a security audit of SSH, it became clear that tunnels (for other protocols, like web browsers) could be opened up on demand<br />
  5. 5. Thus, the –D Flag<br />Dynamic Forwarding was born<br />-D flag<br />“If you can SSH into the box, you can administer its web interface”<br />Code is now in every Mac and Linux system on the planet<br />This was the result of a pen test!<br />
  6. 6. An Unsolved Problem<br />OK, so now we can manage any machine<br />How do we log in?<br />Cross Organizational Authentication was then, and remains now, a capital-h Hard Problem.<br />Verizon Business: 60% of compromises traced to authentication<br />No passwords<br />Default passwords<br />Shared passwords<br />Can we do better?<br />
  7. 7. A Very Common Scene<br />
  8. 8. [That’s A Strange Username…]<br />
  9. 9. [Heh Wait, That Worked?]<br />
  10. 10. [What’s that in authorized_keys2?!]<br />
  11. 11. Redefining The Possible<br />We’ve been trying to authenticate (federate) from one domain to another for years<br />DNSSEC makes it easy.<br />This is the power of the Domain Key Infrastructure<br />We can’t do this if DNSSEC is hard to deploy<br />So is it possible to make DNSSEC easy?<br />Yes.<br />But I get ahead of myself.<br />
  12. 12. DNSSEC<br />For the last eighteen years, people have been trying to secure the DNS<br />Now it’s our turn to secure everything else<br />We live in the future.<br />I recently spent six hours in a secure facility helping sign the DNSSEC root – I’m honored to have been a part of that<br />Everything in this talk is only possible because the DNSSEC root is finally signed.<br />But I get ahead of myself.<br />
  13. 13. What Recursion Ventures Stands For<br />It is time to get serious about defense.<br />Our society runs on Information Technology. We can’t go back.<br />That does not mean we stop talking about how to break into things<br />The only hope we have for creating effective defenses is maintaining strong offensive knowledge, and using it to drive defensive engineering<br />Otherwise, we end up with Please Turn Off Your Cellphones Before Departure Syndrome – major exertions of effort with no measureable or measured relationship with the problem at hand<br />
  14. 14. The Need For Fundamental Defense<br />We believe there are fundamental links between most of the security failures out there<br />Two core issues<br />It’s because of these two issues that attackers succeed.<br />First: We don’t know how to write secure code affordably<br />Second: We can’t authenticate across organizational boundaries<br />Recursion is working on both problems<br />Interpolique, a secure (and public! Go break it!) framework for cross-language communication, is dealing with some of the first<br />We’re here today to talk about the second<br />
  15. 15. There Are Four Audiences For This Talk<br />The User<br />The Buyer<br />The Builder<br />The Breaker<br />
  16. 16. To The Users<br />DKI (Domain Key Infrastructure) will let you know, when you receive a mail from your bank, that it is actually from your bank.<br />We have been talking about secure email for over a decade<br />We apologize. We have failed you.<br />We ask you too many questions.<br />We make awful demands upon your memory<br />We blame you when things go wrong<br />Our failure comes not from lack of trying, but from taking the wrong approach.<br />
  17. 17. To The Buyers<br />DKI is going to increase your budget.<br />Ten years ago, your community spent hundreds of millions of dollars trying to implement Public Key Infrastructure<br />On the one hand, it did not work.<br />On the other, do you think we need strong authentication any less now, than we did a decade ago?<br />Information Technology has only gotten more important, not less.<br />The question is: Is this pendulum swing, with the DNSSEC root being signed, finally the one that will solve this problem?<br />We believe so.<br />
  18. 18. To The Builders<br />DKI will make your security products scale<br />How much stuff have you sold that sits on customer shelves, because it worked in the lab but failed large scale deployment?<br />How many devices have you really been able to ship with certificates?<br />How many sacrifices have you had to make in your products, that in the end equated to disabling the security in the first place?<br />Ahem, devices that don’t even validate the identity of the SSL peer they’re communicating with<br />
  19. 19. To The Breakers<br />You are the most important group here.<br />People think code is secure until proven otherwise<br />You know better.<br />“Holy crap! Recursion Ventures just made DNSSEC OpenSSH Pre-auth!”<br />Thank you for noticing. Lets get to work.<br />
  20. 20. Towards Radical Transparency<br />Recursion Ventures will be actively supporting an aggressive public audit of all DNSSEC and DKI technologies<br />Justin Ferguson (jf / @not_me) is auditing LDNS, NLnet Labs’ excellent DNSSEC library<br />His report will be released publicly in a few weeks (by September 1st, 2010, probably earlier)<br />Initial findings are mostly positive, with some finds<br />Nlnet Labs is being very supportive of this effort<br />
  21. 21. To Grandma<br />Welcome to your seventhBlack Hat!<br />You are officially more l33t than 90% of this room <br />Yes, everyone, there are cookies <br />
  22. 22. What We Are Here To Do<br />1) Explain DNSSEC. It’s simpler than you think.<br />2) Deploy DNSSEC. See #1<br />3) Discuss some approaches that may make DNSSEC scale better on the server side.<br />4) Describe how we will acquire end-to-end trust via DNSSEC, thus enabling DKI<br />5) Demonstrate DKI working. Not theoretically, but right here, right now, on stage.<br />Code or GTFO<br />
  23. 23. Some Ground Rules [0]<br />No Religion But One<br />We don’t care about Not Invented Here<br />Some of the coolest things in this talk were not my idea<br />We have an Internet to fix<br />Bigger than any one person<br />…or one organization<br />…or one community<br />…or one country<br />
  24. 24. Some Ground Rules [1]<br />We can’t care about style.<br />Skype’s Law: The Internet was frozen in 2001. Deal with it.<br />Theoretical elegance is great, and there are times where it’s important to “take a stand”<br />But it’s gotta work.<br />And it’s gotta work well. Not just barely.<br />Systems that barely work are barely deployed.<br />1M SSL endpoints.<br />Half of them don’t even pretend to be secure.<br />Corollary: We can’t care about historical precedent<br />Historically, we have not achieved success.<br />
  25. 25. Ops Is King<br />We do care about Operations<br />We will not win by calling people Lazy and Stupid<br />Great for our egos – defines us as intelligent and industrious – but the customer remains 0wned<br />We will not win through moralization<br />“You’re bad people! You release broken code!”<br />We will really not win through regulation<br />Product liability is the end result of no market forces differentiating secure code from bad<br />We will win the old fashioned way: By delivering a better product to market, as judged by the people who actually have to run with it<br />
  26. 26. Timelines<br />18 months ago, we declared at Black Hat DC:<br />DNSSEC, as an implementation, is an undeployable train wreck.<br />It will get better.<br />Today is Yesterday’s Future<br />Look what we have!<br />
  27. 27. Market Survey(Not A Sales Pitch)<br />Open Source Servers<br />Bind 9.7 (“DNSSEC for Humans”)<br />PowerDNSSEC (Lazy Signing)<br />OpenDNSSEC (IXFR Secure Slaves)<br />Commercial Servers<br />Xelerance<br />Secure64<br />Infoblox<br />Managed Service Providers<br />Afilias / Proteus<br />Verisign<br />Dyn<br />UltraDNS<br />
  28. 28. Why This Matters<br />There is a robust market of companies out to make DNSSEC easy to deploy.<br />This is a sign of maturity<br />A bevy of suppliers is the mark of a healthy industry<br />A lot of skin in this game<br />A lot of people out to make DNSSEC operations-friendly<br />I’m here to show where it’s all going, on the six-to-eighteen month timeline<br />
  29. 29. 1) DNSSEC is not that complicated <br />Normal DNS:<br />Ask a question, get an answer<br />Ask a question, get a referral<br />Alice: Jenny’s number? Ask Travis.<br />Travis: Jenny’s number? Ask Charlie.<br />Charlie: Jenny’s number? 876-5309<br />
  30. 30. Not Too Different<br />DNSSEC<br />Ask a question, get an answer and a signature<br />Ask a question, get a referral and a signature<br />Alice: Jenny’s number? Ask Travis™<br />Travis: Jenny’s number? Ask Charlie™<br />Charlie: Jenny’s number? 876-5309™<br />Is that it?<br />Mostly<br />
  31. 31. What’s New<br />Referrals now contain new keys<br />Before, you were just told where Travis was<br />“Oh, ask Travis, he’s down by the water fountain”<br />Now you’re told how to recognize him<br />“He’s the guy with the dreadlocks.”<br />Who is now the new Chief Hardware Officer of Recursion Ventures<br />Welcome aboard, neighbor ;)<br />Computers can make stronger identifiers than people can, so we use crypto<br />But it’s just the same<br />
  32. 32. Is That It?<br />There’s magic here and there<br />Saying “Jenny has no number” has some magic (NSEC/NSEC3)<br />Records can expire (time exists)<br />Keys can lead to other keys (KSK/ZSK)<br />Some of the magic is optional<br />More than you’d think<br />All of the magic can be implemented in an easily deployable manner<br />Easiest of course is a managed service or a “one click” device<br />But, failing that, lets deploy DNSSEC.<br />Right now.<br />
  33. 33. A Simple Bind9 Install With A Handful Of Small Zones<br />
  34. 34. Step 1: Change The Port To 50053<br />
  35. 35. Step 2: Launch Phreebird, the Recursion Ventures DNSSEC Server<br />
  36. 36. Step 3: There is no step 3<br />
  37. 37. I ask for keys, I get keys!<br />
  38. 38. OK, maybe there’s a Step 3:.org needs to know<br />
  39. 39. Go To GoDaddy<br />
  40. 40. Click “Manage DNSSEC”<br />
  41. 41. Push the DS<br />
  42. 42. Click OK<br />
  43. 43. Wait 30 seconds<br />…<br />
  44. 44. And Look!<br />
  45. 45. It works!(ahem, end to end)<br />
  46. 46. Why This Works<br />Phreebird is an online key signer<br />Like SSH, SSL, and IPsec, it depends on a signing key being available on demand<br />Alternative: Magic key sits in a vault<br />When a request comes in, it figures out right then and there what response needs to go back out<br />Phreebird caches responses, so that 1,000 requests for the same name don’t require 1,000 hits against the encryption engine<br />
  47. 47. Offline Key Signing<br />DNSSEC was designed to allow offlinekey signing<br />Age: When DNSSEC was designed, processors were slow and hardware RSA accelerators didn’t exist<br />Scale: DNSSEC needs to work for both the root – which needs maximum security – and .com – which needs maximum performance<br />Not every server should be run like the root<br />It’s a big deal that every server can be, though<br />
  48. 48. Reality<br /> A large part about what made DNSSEC complicated to deploy, was the requirement for offline key signing<br />Offline keying systems are an order of magnitude more complicated<br />PGP<br />
  49. 49. Why Phreebird Works<br />DNSSEC was designed to allow a “key in a vault” approach to security<br />“Offline keying” – no ability to generate responses on demand<br />Age: DNSSEC was designed in an era where CPUs were slow and RSA acceleration was horribly expensive/nonexistent<br />We live in the future. Neither is true anymore.<br />Scale: DNSSEC has to handle everything from the smallest domain to the root to .com – for very, very large sites, the resources exist to implement offline keying<br />When you ask why Verisign hasn’t signed .com yet, remember, .com is absolutely massive on a ridiculous scale<br />
  50. 50. The Key Observation<br />Offline Keying is operationally expensive.<br />The contortions that one must go through to support it are significant in DNSSEC<br />The thrust of most of the products coming out is to hide it all behind cron jobs<br />…and not just in DNSSEC<br />
  51. 51. Not Just DNSSEC<br />Look at PGP / GPG<br />Best solution available for secure email<br />Sure there are keyservers, but everyday use is supposed to depend on keyrings with validated contents<br />What happens when you receive mail from someone not on your keyring?<br />What happens when you have to send mail to someone not on your keyring?<br />What happens when a key expires?<br />What happens when a key is lost?<br />What happens when a key is stolen?<br />
  52. 52. Popup<br />Popup<br />Popup<br />Popup<br />Popup<br />Popup<br />Popup<br />Popup<br />
  53. 53. A simple statement<br />Can you imagine if DNS worked that way?<br />It doesn’t.<br />Requests are made on demand, and are cached for relatively short periods of time<br />This works very well<br />Whenever possible, DNSSEC should be allowed to work like DNS<br />That being said, it’s awesome that DNSSEC can operate in an offline capacity<br />
  54. 54. Further Precedent<br />We did not invent online keysigning<br />Obviously, there are the other protocols<br />DNSSEC has quietly been including support for online signing for years<br />Thanks Ben Laurie!<br />Some precedent even for DNSSEC servers signing on demand<br />PowerDNSSEC by Bert Hubert<br />
  55. 55. Phreebird Is A Proxy<br />Phreebird uses the existing DNS framework – whatever it may be – and enhances it with DNSSEC responses<br />No operational impact: Manage your DNS as you always have, it’s just signing all its responses now<br />No configuration: There is enough information in any DNS request to cobble together the appropriate DNS response<br />Always returns the right answers – even if they change a lot!<br />Implementation notes<br />Today: UDP Port Forwarder<br />Tomorrow: Linux Mangle Table (won’t even have to change the port – DNSSEC on, DNSSEC off)<br />
  56. 56. Phreebird Is An Online Keysigner<br />We sign requests when they come in, not in some huge precomputation phase<br />We didn’t invent online keysigning<br />SSL, SSH and IPsec all have the keys online<br />WARNING: There’s some religion here. The reality however is that every company has keys online for some protocols. HSMs exist to keep keys from leaking if necessary, but not everything exists within an HSM!<br />Quiet but very visible support throughout a number of the RFCs<br />Thanks, Ben Laurie!<br />We’re not the only implementation that’s doing it<br />Bert Hubert’s PowerDNSSEC does it as well<br />
  57. 57. Phreebird Is A Proxy<br />As close to a “bump in the wire” as possible<br />Nothing Operations likes more than minimal disruption <br />There’s effectively nothing to configure – turn it on and go to lunch<br />Present implementation – UDP port forwarder<br />Coming (very) soon – Linux Mangle Table<br />Mangle Tables maintain original Source IP, which is actually important for many servers (GeoIP, etc)<br />
  58. 58. Phreebird is fast<br />Thank you, Linux Kernel Developers and LibEvent developers<br />NielsProvos is a badass<br />Few hundred lines of code == DNS server that runs at 60,000 qps on stock fast hardware<br />So says author of evldns<br />We won’t be so fast, since we have a backend to talk to and some records to sign<br />But we’re pretty clearly faster than almost any name server we’re put in front of <br />
  59. 59. Phreebirdcaches<br />The general idea is we always send a query to the backend, and sign each response<br />If we’ve already signed that particular response, we go to the cache, otherwise we generate the response on the fly<br />This design keeps us compatible with dynamic name servers<br />CDNs, etc.<br />
  60. 60. Phreebird is open<br />You’d just reimplement it anyway <br />Should have code out today, but demos took precedence over release<br />Send an email to info@recursion.com if you want a pre-preview copy with known (and horrifying) bugs<br />Code should be out in next few weeks (with pen test report)<br />Remember, six to eighteen months – this is where things are going, not where things are at<br />
  61. 61. Phreebird does a lot of things I don’t have time to tell you about today<br />There is a lot of obscura in the DNSSEC realm that we’ve been filtering through<br />How do we handle nonexistent records dynamically?<br />How do we tunnel trusted records to registries when the registrars in front of them don’t implement DNSSEC?<br />How do we manage rollover and expiration?<br />How do we keep clocks in sync, especially given the chicken-and-egg relationship between NTP and DNSSEC?<br />The full version of these slides will contain answers to these questions, but right now we want to demonstrate the value of this platform conclusively.<br />
  62. 62. Phreebirdlies<br />White lies <br />Consider the problem of nonexistent names<br />DNS supports NXDOMAIN – “this domain doesn’t exist”<br />DNSSEC supports NSEC/NSEC3 – “this range of domains doesn’t exist, and here’s proof”<br />Authoritative Nonexistence<br />Actually really useful, surprisingly<br />The reason NSEC/NSEC3 operate on ranges is because there are a finite number of records that do exist and an infinite number of records that do not<br />Offline signers need the ability to say, “anything between here and here, here’s proof it’s not real”<br />
  63. 63. White Lies<br />If you have an online signer, it’d be great to just say “that name you just asked for, here, let me synthesize some proof it doesn’t exist”<br />Problem: The language only lets you express ranges that don’t exist, not actual domains<br />Solution: Generate a record in which there is nothing between “the name right before this one” and “the name right after this one”<br />Simple explanation: “You looked up foo. There are no names between fon and fop”<br />A little too simple…<br />
  64. 64. NSEC White Lies Are A Little Ugly<br />[what they look like]<br />
  65. 65. Solution: NSEC3 White Lies<br />In NSEC3, rather than saying there are no values between “fol” and “fop”, all names are turned into very large numbers<br />This is so offline signers don’t leak all the names in the domain<br />Nice side effect: It makes it much easier to implement the White Lies semantic<br />“No names between 1 and 3”<br />Pretty easy to prove that the only name blocked is 2<br />
  66. 66. NSEC3 White Lies Demo<br />
  67. 67. Beyond the Name Server<br />“No Man Is An Island”<br />Neither is any zone<br />Domains chain, from the root to .org, and from .org to foo.org<br />Hosting foo.org is not enough -- .org needs to know where to send people who are looking for foo.org<br />This is the NS record in DNS<br />Hosting foo.org securely is not enough -- .org needs to know the key to switch people to when they’re looking for foo.org<br />This is the DS record in DNS<br />
  68. 68. The Problem<br />Every company (“registrar”) reselling access to .org lets you declare a NS record<br />Very few companies reselling access to .org let you declare a DS record<br />DS is very new<br />It’s a tremendous amount of work to rev UI<br />We have yet to prove the value of that work<br />I’m working on it! Here! Now! <br />
  69. 69. One Solution: NSDS<br />Before: ns1.domain.com<br />After: nsds-v1-60485-5-2-D4B7D520E7BB5F0F67674A0CCEB1E3E0614B93.nsds-C4F9E99B8383F6A1E4469DA50A.domain.com<br />The idea is that the DS record follows the same secure path it otherwise would, it just gets tunneled inside the NS record<br />Familiar? This is the coolest part of Dan Bernstein’s DNScurve<br />It’s a great idea and DNSSEC should adopt it<br />
  70. 70. Supporting Rotation<br />NSDS is great for the initial keying<br />Past that, in DNSSEC, keys can sign keys<br />Name servers should be able to publish “this is the next key I’m going to use, please see me signing the new key with the old key”<br />Somebody should visit the server to collect the update<br />Possibly, Phreebird could send a NOTIFY packet somewhere – “heh, get my new key”<br />
  71. 71. On Time<br />There is another external dependency in DNSSEC<br />Time<br />1) Signatures expire<br />2) What if your clock is wrong?<br />
  72. 72. Expiration<br />Who here has been to a site where the certificate expired?<br />Why is there UX for this?<br />Fundamental flaw: When a system fails enough, it gets special case handling.<br />Prompts are the direct result of a security system that fails too often in legitimate use<br />Expiration seems like a good idea<br />Don’t we want to make sure that a bad guy eventually loses access?<br />
  73. 73. OPS IS KING<br />Do we buy hard drives by the year?<br />Servers?<br />Networks?<br />Keyboards?<br />No, because that’s totally ridiculous<br />Certificate expiration is not the only reason why X.509 is only deployed when absolutely required<br />But the inconvenience to the ops guys is clearly a contributing factor<br />
  74. 74. You May Have Heard…<br />…that if you don’t update your DNS keys every thirty days, your domain fails<br />Tell this to an ops guy, and he’ll literally remove you from the premises<br />DKI cannot depend on any technology that requires manual maintenance on pain of total failure<br />Phreebird’s keys will expire in 2100 (obviously configurable)<br />But don’t we want to make keys go bad?<br />
  75. 75. Sure!<br />The right place to do this is in the chain to root, not at the endpoint<br />.org has a DS record – “this is how you can recognize Travis”<br />This record is signed for some number of days (30 now, could be 5)<br />On key rotation, or an emergency event, this record is updated<br />“Heads up, Travis cut his hair, he’s got a mullet now”<br />The “infinite lifespan” key is now of no value to the attacker<br />
  76. 76. What If The Clock’s Wrong?<br />In DNS, all time is relative<br />“This value is good for the next 600 seconds”<br />In DNSSEC, all time is absolute<br />“This value is good until August 1st, 2010, 0630 GMT”<br />This is necessary to prevent replay attacks<br />600 seconds from now is not 600 seconds from a month ago<br />But what if you think it’s August 15th, 2010?<br />
  77. 77. Well then…<br />Either:<br />A) The Internet stops resolving<br />B) Ops disables expiration checking<br />OPS IS KING<br />If we want expiration checking, we have to manage time<br />Couldn’t we use NTP (the Network Time Protocol)?<br />
  78. 78. Chicken and Egg<br />How do you authenticate time?<br />It’s a cross organizational auth request<br />Even if you have your own time servers, what do they sync against?<br />Couldn’t we use DNSSEC to bootstrap NTP?<br />We’re trying to use NTP to bootstrap DNSSEC!<br />Chicken and Egg!<br />
  79. 79. Solution: DnsTime<br />Basic idea: Simple timestamp, signed by some unique domain chaining to the DNSSEC root<br />Say, “dnstime.” or something<br />There be politics here, don’t want to speculate on where exactly this would live<br />Retrieve the timestamp<br />A) On expiration error<br />B) No more than once every 24 hours<br />
  80. 80. There’s An Attack<br />Can anyone see it?<br />
  81. 81. Replay!<br />Two weeks ago, attacker got a signed record with a short expiration, and the root-chained timestamp<br />Now, he can replay those things forever and ever…<br />…unless we add a nonce.<br />
  82. 82. Replay Defeat<br />On receiving an expiration error, resolve dnstime<br />If the resulting time indeed suggests local time is wrong, requery for 74A0CCEB1E3E.dnstime<br />This record is online-signed just for that particular query<br />Since the response is both signed and unique, the name server can add an offset to its clock to compensate for local time differential from global truth<br />
  83. 83. Dnstime demo<br />
  84. 84. Towards TheDomain Key Infrastructure<br />Perhaps DNSSEC is easy to deploy. But is it useful?<br />Distributed authentication is only interesting if it provides end to end semantics<br />“My desktop to your server”<br />Isn’t DNSSEC only designed to secure the links between recursive name servers, and not endpoints like desktops?<br />
  85. 85. The Basic Mode: The AD Bit<br />DNS responses have a bit referred to as AD<br />Meaning: “The name server you were speaking to validated the DNSSEC status of this record”<br />So?<br />Starbucks, I like your coffee<br />I don’t trust you to tell me the appropriate certificate for my bank<br />No application on earth is going to alter the user experience based on the AD bit<br />
  86. 86. The Normal End To End Modes<br />Chasing<br />Follow up, from www.foo.com to foo.com, from foo.com to .com, from .com to root<br />You only talk to your local DNS server<br />Problems<br />Might get blocked by local resolver<br />Requires lots of round trips<br />Fixable using “SuperChase” – tell the local resolver “don’t just give me the immediate, bottom of the chain signature – give me all the information needed”<br />
  87. 87. About Ten Lines Of Code For End To End!(in LDNS)<br />
  88. 88. How Do We Get Full Keys To Your Desktop, Laptop, or Phone?<br />Chasing<br />Tracing<br />Wrapping<br />Packing<br />
  89. 89. Chasing: Going Up The Stack<br />Each signature (“RRSIG”) names its source<br />So, we go up the stack<br />“www.foo.com was signed by foo.com”<br />“foo.com” was signed by “com”<br />“com was signed by the root”<br />“I trust the Root, therefore I trust www.foo.com”<br />
  90. 90. LDNS makes it easy<br />This is about ten lines of code in ldns<br />Instantiate a resolver w/ NS list<br />Provide the root key<br />Do a resolve<br />Extract the answers<br />“Build the data chain” (ldns_dnssec_build_data_chain)<br />“Derive the trust tree” (ldns_dnssec_derive_trust_tree)<br />Check for success (ldns_dnssec_trust_tree_contains_keys)<br />
  91. 91. Two Problems With Chasing<br />1) Requires a decent number of round trips to the DNS server<br />Somewhat slow<br />Being fixed (we think) with what Paul Vixie and I refer to as “Superchase”<br />RD=1 CD=1<br />Server returns not just the bottom of the chain, but all the way up<br />Possible configuration of how far up – “Heh, I already have this com DS, can you just get me there?”<br />
  92. 92. The Other Problem<br />Noncompliant networks<br />Local resolver might not respond properly to CD=1<br />Local network might block DNSSEC traffic<br />This stuff will work 80-90% of the time<br />That’s not enough<br />Ops is King<br />
  93. 93. Tracing: Going Down The Stack<br />Chasing: Given a domain, go up to root<br />Tracing: Given root, get down to the domain<br />This is basic recursion, the fundamental system by which DNS servers work normally<br />Unbound is the nameserver built upon ldns<br />Unbound can be integrated via libunbound, and is itself only a few lines of code as well<br />
  94. 94. Tracing in LibUnbound<br />Even fewer lines of code!<br />Create an unbound context (ub_ctx_create)<br />Add a Trust Anchors file (ub_ctx_add_ta_file)<br />Containing just the root <br />Resolve a domain (ub_resolve)<br />If result->secure==1, read the output from result->data.<br />
  95. 95. Issues With Tracing<br />1) Entirely bypasses the local cache, increasing load on the root and TLD servers<br />Somewhat acceptable if the cache on the end host is very long lived<br />Almost entirely unacceptable if it’s short lived / flushed for each call<br />(This was the problem with DNSCurve – if you used it to achieve end to end trust, the end hosts needed to talk to the roots directly in order to function)<br />
  96. 96. Those Again<br />2) The middleboxen are still a problem<br />They do bad things to a lot of traffic! What can you do?<br />Respect Skype’s Law<br />
  97. 97. Wrapping: DNS over HTTP<br />Not complicated – instead of doing DNS over UDP packets that might get intercepted, talk to a custom DNS server that exposes an HTTP endpoint<br />GET requests w/ Base64 encoded DNS requests<br />8 bit clean responses<br />Phreebird implements this<br />
  98. 98. Performance Data<br />So, how much of a perf hit does DNS take, running over TCP and then HTTP?<br />
  99. 99. Well, it ain’t slower.It might even be faster.<br /># DNS over UDP./queryperf -d target2 -s -l 10…  Queries per second:   3278.676726 qps<br /># DNS over HTTPab -c 100 -n 10000… Requests per second:    3910.13 [#/sec] (mean)<br />
  100. 100. Could Be Wrong!<br />Paul Vixie thinks I am<br />“Being wrong just means the world is more interesting than you thought it was.”<br />Even with a significant penalty, superchase over HTTP should work reasonably well though<br />Recursion Ventures will be hosting a DNS over HTTP service in the Cloud within the next few weeks<br />
  101. 101. Wrapping: Brett Watson’s Observation<br />Brett Watson is a really smart Kiwi<br />He was quite the skeptic about DNSSEC<br />So was I, so we got along well<br />His exact quote: “You have to be willing to separate the content of DNS from the transport of DNS”<br />This is a fairly profound point<br />Led to an interesting concept<br />
  102. 102. X.509<br />X.509 normally carries chains to one of a few hundred CA roots, through possibly one of some unknown thousand god-mode Intermediates<br />This is part of why X.509 didn’t work<br />Other parts<br />Unable to reliably delegate – you can’t get a cert for .domain.com that lets you sign other certs<br />Unable to exclude – if Verisign gives you a cert for a domain, so can everyone else<br />See 2009 “Black Ops of PKI” for details<br />
  103. 103. X.509 Reloaded<br />X.509 could also carry the DNSSEC chain.<br />SSL already moves X.509<br />DNS over X.509 over SSL<br />Take that, hotel miniboxen<br />Also, super high performance!<br />Implementing this requires:<br />Extracting all the keys of the full trust chain<br />Not too hard – build a trust chain in ldns, then iterate through it extracting all unique keys<br />Validating the morass of key material you’re left with<br />That’s being a bit tricky – requires some rearchitecture<br />
  104. 104. So Adam Langley at Google sent me a private unofficial build of Chrome…<br />
  105. 105. That certificate was self signed……with a DNSSEC chain embedded.<br />
  106. 106. NOTE<br />This is an unofficial private build of Chrome!<br />Google is not at all committed to DNSSEC, DKI, or X.509 Certificate embedding!<br />This is just Adam and I seeing what is possible <br />And now, I think it’s a good idea to start talking about actual applications.<br />
  107. 107. Where Do We Implement The DKI?<br />PhreeShell: Federated Identity For OpenSSH<br />This was the demo at the start of the talk<br />Based on the idea that end nodes should validate identities, not public keys<br />Today: Identities instead of keys in authorized_keys2<br />Tomorrow: LDAP backend (similar to FedSSH)<br />“Let everyone at support.vendor.com into all the machines in the vendor.com group”<br />
  108. 108. The Dirty Secret Of Federation<br />People have been selling this stuff for years<br />But nobody’s deploying it in large amounts<br />OPS IS KING<br />Three choices<br />M to N complexity: Every group has painful and expensive meetings with every other group<br />The Risk Of The Kingmaker: One group is trusted by all others as the identity manager, and that one abuses his role (lets not name names)<br />Key Bleed: Everybody has to trust way too many keyholders not to abuse their powers.<br />
  109. 109. The Fourth Path<br />The Silent Overseer<br />DNSSEC: A single root keyholder, incredibly constrained by both external political constraints and a technical delegation system designed to suppress operational dependency<br />DKI: Federation that will actually work<br />
  110. 110. So, do we add ldns/libunboundto each package, one by one?<br />Eventually, possibly<br />But in the short term? To prove value?<br />On Linux/Unix, SSL is handled via OpenSSL<br />Specifically, X509_verify_cert<br />A nice and self contained library call…hmm…<br />
  111. 111. PhreeLoad: Adding DNSSEC Verification To OpenSSL Apps Via LD_PRELOAD<br />Prior Work: libval_shim from Russ Mundy @ Sparta<br />Great work!<br />Two major differentiators<br />1) Written before the root was signed, so no provisions for chasing a signature down to the root<br />2) Validated the results of a DNS query – which might just be an IP address, attackable via other means<br />PhreeLoad operates at a different layer<br />Given software that’s attempting to achieve end-to-end security, replace/augment the auth layer with DNSSEC<br />
  112. 112. Curl (without Phreeload)<br />
  113. 113. Curl (With LD_PRELOAD)<br />
  114. 114. Debugging – Just Making Sure This Thing Is Working<br />
  115. 115. The (DELIBERATELY INCORRECT) Schema<br /># dig +short _ssl_absolute.www.hospital-link.org TXT <br />"'5e0905b0eafd35d59f1b178727d4eaadd06c415d'"<br />
  116. 116. …and if we break DNS…<br />_ssl_absolute.www.hospital-link.org. IN TXT 'AAAA05b0eafd35d59f1b178727d4eaadd06c415d'<br />
  117. 117. We break curl.<br />
  118. 118. (When fixed, curl works. So does wget)<br />
  119. 119. All OpenSSL apps means All OpenSSL Apps<br />Postfix<br />Postgres<br />MySQL<br />Apache<br />Want to start working on client certificates that actually work? Much easier now that we have a signed root<br />Welcome to DKI<br />
  120. 120. But Lets Keep The Focus On Browsers<br />OpenSSL is great, but browsers don’t use it<br />IE: CryptoAPI<br />Firefox / Chrome: NSS<br />Also, no LD_PRELOAD on Windows<br />*whistles innocently*<br />What to do?<br />
  121. 121. HTTPS Proxying<br />PDP @ GNUCitizen put together httpservers.py, which uses Browser Secure Proxy functionality to inject into HTTPS sessions (assuming appropriate keys are set up)<br />Based on the work of UZUKI Hisao, Andres Riancho, and Dave Aitel<br />What is sent:CONNECT www.site.com:443 HTTP/1.1<br />
  122. 122. Phoxie: Remote Validation Proxy For Production Browsers<br />1) We can provide the client a custom root certificate<br />2) Before the SSL connection is established, we get the name of the domain the client would like to connect to<br />3) For each connection, we can provide a custom root-signed certificate<br />Wildcards don’t work nearly as well as they used to<br />Sorry about that <br />4) The browser will always trust us. We, however, will only proxy if the real server passes SSL validation<br />Of course, we have PhreeLoad up and running, so SSL validation includes “DNSSEC is happy”<br />
  123. 123. Browser Lock In IE<br />
  124. 124. Browser Lock In Firefox<br />
  125. 125. Browser Lock In Chrome(Not a Private Build!)<br />
  126. 126. A Neat Trick<br />Remember “No Religion”?<br />There’s something very interesting we can do once we’ve outsourced validation<br />It doesn’t involve DNSSEC at all<br />Just DNS (and even then, barely)<br />Wouldn’t it be nice if we could bootstrap trust, with nothing but a domain name?<br />
  127. 127. Self Certifying URLs(Inspired by SFS)<br />
  128. 128. It even works by IP!<br />
  129. 129. It’s just a toy…<br />…with a rather strange history<br />SFS-HTTP: Securing the Web with Self-Certifying URLs<br />Authors: Michael Kaminsky, Eric Banks<br />Their model: http://www.amazon.com:we36hsq8xwgam3tcgzkuay8gy7rb3y8h<br />They had a weiiiiiiiird proxy that did caching even if there wasn’t a built in URL<br />This has scalability issues<br />Links work! Securely!<br />But, man, if the SSL cert is ever lost…the links are dead forever<br />Or you get a crappy UI saying “Oh heh! Would you rather try this other cert?”<br />Still. COOL.<br />
  130. 130. So, can we get rid of the CA’s?<br />No. The CA’s are critical, now more than ever.<br />There are DOMAINS<br />www.bankofamerica.comwww.proctorandgamble.comwww.yahoo.com<br />There are BRANDS<br />Bank of AmericaProctor And GambleYahoo Inc.<br />Brands are a closed namespace.Domains are an open namespace.Certificate Authorities are in the position to overlay a closed, validated namespace on top of the open, delegated hierarchy.<br />This sounds easy until you realize branding is international and you don’t know all of them.<br />
  131. 131. Extended Validation…<br />
  132. 132. …has a problem.<br />2008: Adam Barth and Collin Jackson: Beware of Finer Grained Origins<br />2009: Mike Zusman and Alex Sotirov: Sub-Prime PKI: Attacking Extended Validation SSL<br />“SSL Rebinding”<br />Basic concept: EV only protects you against phishing attacks (www.bank--of--america.com). If an attacker actually gets a real www.bankofamerica.com certificate, EV offers no defense<br />Content from the DV certificate can intermix with content from the EV certificate<br />(There’s more, but this is the core fault that makes it impossible to build a secure EV site.)<br />
  133. 133. DKI Has The Fix:The Exclusionary Property<br />DKI is built on DNSSEC.DNSSEC is built on DNS.DNS excludes.<br />When your DNS domain is registered through eNom, GoDaddy can’t interfere with it.<br />When your X.509 certificate comes from Verisign, GoDaddycan interfere with it – it can issue one of its own.<br />DKI by its very nature declares the canonical certificate (or cert set) for www.bankofamerica.com<br />If that certificate happens to be EV, great!No other certificate, even if chaining to a proper root, will validate.<br />
  134. 134. What About The Invisible Domains?<br />Sites are not servers<br />One “website” assembles content from sometimes dozens of servers<br />If the content retrieved is more complicated than a simple image, effectively all browsers will require it to be delivered over SSL<br />…but not EV-SSL, because there’s no branding associated (the server name is hidden).<br />Zusman and Sotirov demonstrated: Compromise the invisible domain, get content in w/ the green bar intact<br />
  135. 135. We Fix Those Too<br />First, we make it really amazingly easy to deploy SSL, even on CDNs<br />There are some issues with virtual hosting for SSL, requiring crazy certificates that list out all possible domains<br />In the DKI model, many domains can share the same certificate because the lookup is against the domain, not the IP<br />Second, exclusion works for the invisible domains too<br />Breaking random CA’s won’t work anymore<br />
  136. 136. But Before We Finish<br />I do believe we promised to do something about email.<br />Don’t you hate having to deal with locating PGP keys?<br />Wouldn’t it be great if you could securely retrieve them via DNSSEC?<br />
  137. 137. PhreeGP: Porting End-To-End DNSSEC Lookups To GPG<br />
  138. 138. Some Problems<br />GPG really does not want to trust a random key that comes in over DNS (a reasonable thing )<br />PGP signatures don’t appear to actually contain the email address they’re signatures for<br />GPG doesn’t let you declare the name of the email address you’re trying to verify on the command line<br />PKA support (which involves looking up a key in DNS) is only written into the encrypt path<br />Some pretty deep hacking of Enigmail is going to be necessary to make this work<br />
  139. 139. DKIM?<br />Scheme for retrieving public keys (not certificates) for domains out of DNS<br />Pretty trivial to port end-to-end validation into it, and get domain-to-domain trust<br />But there’s no user experience, and it can’t function end-to-end<br />It’s an anti-spam system, not a replacement for generic secure email<br />
  140. 140. S/MIME<br />Doesn’t have a very good reputation, but…<br />…it is the most widely deployed secure email system on the planet<br />Outlook<br />Thunderbird<br />(There’s a S/MIME plugin for Gmail but it doesn’t verify signatures, so it doesn’t count.)<br />Just has some key management problems<br />
  141. 141. Lack Of Exclusion Kills S/MIME<br />Even if you have the greatest Enterprise CA in the world, you have to hope no other CA issues a free certificate with your name in it<br />Many CA’s issue email certificates freely, just depending on domain validation <br />Can we fix this?<br />Actually…can we?<br />
  142. 142. APIs<br />We were able to hijack OpenSSL because of LD_PRELOAD<br />We were able to hijack the browsers because of Secure Proxy<br />How are we supposed to hijack CryptoAPI?<br />The only extensibility point lets us reject certificates for being revoked<br />It doesn’t let us accept certificates that are, say, self-signed<br />We could write an Outlook extension, but man, that’s hard.<br />(There’s another trick, but it’s too hideous to even mention.)<br />I guess we’re hosed, right? <br />
  143. 143. This is what a bad idea looks like.(In the Michael Jackson sense.)<br />
  144. 144. API Hooking:Not Just For World Of Warcraft Anymore<br />It’s possible to inject your code into any process, to alter how it works<br />At best, this is usually done for instrumentation<br />At worst, it’s used for cheating at games or extracting data maliciously<br />We’re going to use it to make Outlook better.<br />PhreeCAPI: DNSSEC Validation for CryptoAPI<br />CryptoAPI has a function called CertGetCertificateChain<br />If it returns True, the chain is valid<br />The call receives all sorts of context about how its called, like purpose etc.<br />
  145. 145. See? You can see it in the debugger!While it’s running inside of Outlook!<br />
  146. 146. So, we have this signed email from dan@the-bank.org(Not exactly the most compelling image)<br />
  147. 147. Suppose We Added A DKI Checker<br />
  148. 148. We just added the checker, didn’t put any records into the DKI<br />
  149. 149. Well, there’s the fingerprint of the canonical certificate…<br />
  150. 150. So, lets put this (DELIBERATELY OVERSIMPLISTIC) thing in the DKI<br />dan._smpka.the-bank.org. IN TXT '460c1be3f86d39f537864700560f37aef6ce3775'<br />
  151. 151. Now we have mail from the bank, signed by the only key in the world that can sign it.<br />
  152. 152. Ahem.<br />Now, perhaps, can we apply more than 15 pixels for security and identity?<br />
  153. 153. This is where EV should go next.<br />The user experience around secure email has been minimal because our faith – both in being right, or in being wrong – has been so small<br />Now, we can strongly identify email senders<br />Furthermore, we can strongly identify the brands associated with those senders<br />When you receive an email from the bank, someday soon, you will know it came from the bank.<br />
  154. 154. Conclusion:DKI Is Coming.<br />We’ve shown DNSSEC can be deployed in 2 minutes.<br />We’ve shown that it can achieve end to end security, even through the weird hotel miniboxes we need to deal with.<br />We’ve shown how it allows federation of SSH and key retrieval for GPG.<br />We’ve shown how it can be integrated into any OpenSSL based app using LD_PRELOAD<br />We’ve shown how nicely real world browsers can play with DNSSEC<br />We’ve shown how EV, and the Certificate Authority system, still makes sense in a DKI world – validating brands, for both web sites and emails.<br />
  155. 155. Conclusion<br />A new era begins<br />The root is signed<br />The market is ready<br />It is time to build<br />It is time to break<br />Lets fix the net!<br />

Hinweis der Redaktion

  • Edit: added recursion.com
  • Edit:Spelled out DKI again
  • Dan -&gt; RV, or Dan@RV ?
  • Gtfo -&gt; Go home
  • Perhaps promise ‘in a few weeks’?
  • We’re working…
  • CapitalizePhreebird?
  • Bowler -&gt; mullet (MT agrees – mullet is funnier)
  • Add a footnote defining a nonce?
  • Consider restating the law, since it was a zillion slides ago.
  • The final sentence is hard to understand when structured like that.
  • No relation? 
  • When you’re hosed, you should follow that with ‘eh?’ 