The Trust Cartel has broken SSL
|
| Author | Content |
|---|---|
| ljmp Apr 10, 2015 8:58 AM EDT |
First: How can an article be written about SSL certs, and not include one the best known free certificate providers: Startssl Solution to broken CA model: Create a self-owned CA which doles out as many certs as you need for your own domain. The self-run CA is setup to be tied to a PGP key as the trust root... and then you simply create a second pgp to sign the trust root key.
.-------------------------.
| Trust Root | .---------------------.
| PGP Key | | Key-signing PGP key |
| Signed by key-signing |<----| Keep this off line |
| PGP Key | | |
'-------------------------' '---------------------'
|
|
|
|
|
v
.-----------------.
| Domain level CA |
.----| |---.
| | | |
| '-----------------' |
| |
| |
| |
v |
.--------------------------. |
| Domain issued cert | |
| protects service traffic | |
| | |
'--------------------------' |
v
.--------------------------.
| Domain issued cert |
| protects service traffic |
| |
'--------------------------'
This is nearly identical to DKIM for email servers. It should work just fine for Domain level CAs... just put the domain CA trust root key in a DNS record... and done. On the browser side: The browsers check DNS records first. If there's a key it trusts only the domain level CA. If there's no key, it finds the trust root through the current CA model. Done. There are many people who will say - "That's just exchanging the DNS key servers for trust versus the current CAs." And I say, "You already need to trust DNS, regardless of the current CA model." |
| mbaehrlxer Apr 11, 2015 6:31 AM EDT |
but my ISP can intercept my DNS requests more easily than it can take over a CA to issue fake certificates. greetings, eMBee. |
| ljmp Apr 11, 2015 10:20 AM EDT |
@mbaehrlxer: Intercept DNS requests: That's true regardless of the location of the CA on the Internet. DNS poisoning can redirect any request already -- and as 'Superfish' shows, installing a root cert on a client machine is easy-peasy. The solution is to remove the CA architecture, and DNS poisoning goes away with DNSSEC. If you can't trust the root DNS servers - then there's nothing that can be trusted at all including the path to any given CA. Of course, the argument of how to fix things will go on forever... but using DNS as a trust root makes much more sense than using CAs as they exist currently, and give security control, and liability, mostly back to the domain owner -- which is where it belongs. |
| mbaehrlxer Apr 12, 2015 8:33 AM EDT |
hmm, yes, the redirect could point to a site set up with the method above. so i am not loosing anything if i use the same method.
that's good in a way because the method looks interesting and i too believe that the CA-model is broken.
(my main issue is that CAs have no way to verify that i am actually allowed to use the domain i am registering, but the impression is given that they do just that) i am not sure about dnssec however. there is an interesting discussion with convincing counterarguments: http://sockpuppet.org/blog/2015/01/15/against-dnssec/ greetings, eMBee. |
| ljmp Apr 12, 2015 12:29 PM EDT |
@mbaehrlxer: I browsed the anti-DNSSEC page... most of it is wrong or incomplete. There are quite a few Domain level CA RFCs. I believe one is listed under the acronym DANE. The domain-org authority problem is not really a problem. There can still exist CA type orgs that signed your key to validate that you are the organization with that domain. This is already the current CA model too. For example: I can and do get free non-org SSL certs from Startssl. These certs are good for only one subdomain, 'www', but allow me to protect traffic from and to a personal domain. If I want an org-validated cert, I must submit paperwork and pay a fee. This particular model of free/pay works great. The problems are: 1. I can only get a single subdomain cert - this limits the complexity of my personal site. 2. I cede control over the crypto authority. Both 1&2 are fixed and regained with keys in DNS as the trust model. The org-certs can still be a paid service... although it would be really great to have the local government sign your domain key instead... as you already need to register your business for tax purposes -- so, if they just had key signing key process for an extra $20.00USD fee or something -- done. The CA model is going to go away anyway --- there's very little doubt about that. I don't like the idea of cert pinning to the web server, as that's still a model that is hamstrung by 1&2. But there are tons people who just want something 'new' and 'shiny' --- and that's the problem... the CA model could have been replaced a long time ago with plenty of great ideas since 2006 [when T-Rex roamed the interwebs - and DKIM was gifted to the world by Yahoo!] |
| ljmp Apr 12, 2015 3:14 PM EDT |
Here's a diagram with DNSSEC and org-verify.
.-----------------.
| Root |
.--------------| DNSSEC |---------------------------.
| | | |
| '-----------------' |
v |
.-----------------. .---------------------. |
| Domain | | Key-signing PGP key | |
| DNS Records | .---------| Keep this off line | |
| | | | | |
'-----------------' v '---------------------' |
^ .-------------------------. |
| | Trust Root | |
| | PGP Key | |
'-----| Signed by key-signing |<------. |
| PGP Key | | |
'-------------------------' | |
| | |
| .------------------------. |
| | Government Signing Key | |
| | For Org verification | |
| | | |
v '------------------------' |
.-----------------. -------. |
| Domain level CA | v |
.----| |---. .----------------------. |
| | | | | Government | |
| '-----------------' | | or Commercial Verify |<-'
| | | DNS Records |
| | '----------------------'
| |
v |
.--------------------------. |
| Domain issued cert | |
| protects service traffic | |
| | |
'--------------------------' |
v
.--------------------------.
| Domain issued cert |
| protects service traffic |
| |
'--------------------------'
If you are interested in DNSSEC, here's the trust root: https://www.iana.org/dnssec/files Note that there are both PGP keys and x509 certs. Either one can be used depending on your architecture needs. If you look at the crypto presented on IANA, you'll notice that the key length is not 1024 -- it's 2048 for x509, and a combo of 1024 for the signature on the 2048 PGP key. The anti-DNSSEC website has quite a bit of odd and wrong information about how DNSSEC works and crypto in general. For example: anti-point: need EC to be modern. actual crypto: both x509 [openssl] and PGP [openpgp] have EC ciphers. PGP EC: https://code.google.com/p/gnupg-ecc/ x509 EC: http://wiki.openssl.org/index.php/Elliptic_Curve_Cryptography x509 and PGP are public key crypto... the ciphers, key length, etc are changeable, making the claim that either basic software 'thingie' needs replacing absurd - updating, patching, verifying -- absolutely... but no need to replace. I suppose most people just simply make an assumption equating cryptography to other software items... and it just doesn't work that way. Cryptography is math, with a good implementation [meaning internal math functions and coding best practices - not the user interface], the general crypto 'engine' so to speak doesn't really age. The ciphers do age, but that's only because computers get faster. The ciphers are also interchangeable and replaceable. |
| mbaehrlxer Apr 13, 2015 1:53 PM EDT |
that's one point that the anti-dnssec page makes, what about the others? if you think most of that page is wrong or incomplete, i'd like to know what's missing, or why it's wrong. i appreciate your insights because i don't know what's right here. greetings, eMBee. |
| ljmp Apr 13, 2015 2:25 PM EDT |
OK... The biggest wrong claim is the one about controlling domain keys. DNSSEC is a trusted root architecture. However, without the trusted root, a keyyed domain is still possible as an Island of Trust. This, again, is what DKIM does. For example: If you have a gmail account, you can send yourself an email message and view the headers. You'll see that there's a signature within the header. However, Google does not use DNSSEC... so the DKIM public key is operating as an Island of Trust. Google's DKIM private key is signing the email, the DNS record is still present, and the system is still functional without DNSSEC. If DNSSEC were used, and a government decided to remove, change, or disable the root DNS key -- DKIM would still operate anyway, and no government would suddenly be in control of Google's DKIM private key. Thus, the whole discussion point about CAs versus DNSSEC is rendered moot. It's not DNSSEC versus CAs, it's domain level keys provided by domain operators/owners versus third party CA provided keys which are very likely already controlled or compromised by governments worldwide. DNSSEC is moving the trust root and extending the island of trust to include all domains... But public keys inserted into DNS works fine without DNSSEC, as DKIM clearly shows. It's also worth noting that there exist methods for storing SSH keys in DNS too. I suppose I could run through the entire anti-'old' crypto arguments... but the reality is, the people complaining don't seem to understand what they already have at their fingertips, or the crypto items currently in use protecting a wide range of services, types of traffic, and long term storage. It's useful to remember that crypto is not about old ideas versus new ideas, it's about math and speed of computers. So whenever you hear or read someone complaining about 'old' ideas in cryptography -- it's very likely wrong. If you hear or read about sunset dates for ciphers -- it's very likely that individual has at least a little bit of clue. |
| ljmp Apr 13, 2015 6:03 PM EDT |
Very Long Post follows: Sorry -- I do not wish to post this elsewhere or somewhere more permanent. If mods wish to delete - so be it. A non-authoritative, perhaps sometimes inaccurate rebuttal... please correct my errors, but give accurate references if a correction is needed. These are my thoughts and only my thoughts - if someone takes offense - too bad, I believe my understanding of DNSSEC is correct... but please see this recursive statement and correct my errors with references and gusto. Anti-Anti-DNSSEC Rant Rebuttal for Anti-DNSSEC Rant found here: http://sockpuppet.org/blog/2015/01/15/against-dnssec Meta / Older Against DNSSEC 15 January 2015 This post also has an FAQ. 1. DNSSEC is Unnecessary All secure crypto on the Internet assumes that the DNS lookup from names to IP addresses are insecure. Securing those DNS lookups therefore enables no meaningful security. DNSSEC does make some attacks against insecure sites harder. But it doesn’t make those attacks infeasible, so sites still need to adopt secure transports like TLS. With TLS properly configured, DNSSEC adds nothing. Take “domain-validated TLS certificates”. Some TLS CAs will sign certificates based solely on the requester’s ability to receive a confidential email sent to a domain. DNSSEC makes attacks against this scheme harder. But domain-validated certificates remain insecure, because SMTP is itself insecure. Put differently: the problem is “validating domain ownership via email” in the first place, not that the DNS is insecure. Rebuttal: 1. DNSSEC is better than no DNSSEC. Only a few specialized crypto solutions on the Internet use an IP address as a component within the crypto. SSH keys can be assigned an IP address. But besides that, IP addresses are mostly left out. Every SSL certificate includes an English language domain name, and a lookup is performed to retrieve the current IP address of that domain within the certificate. It does not matter to the SSL certificate or the SSL architecture if DNSSEC exists or does not exist. However, if DNSSEC does exist, the certificate user can be sure that DNS poisoning has not occurred, as 'sockpuppet' notes. Email domain validated certificates can be quite secure if DNSSEC and SPF, DKIM, DMARC are deployed as per best practices and as most mail providers are currently configured. Thus the argument that SMTP is itself insecure is not entirely valid. The claim is either willfully misleading or shows that the author is not knowledgeable of email provider security best practices. 2. DNSSEC is a Government-Controlled PKI Securing DNS lookups isn’t a high-priority Closing browser RCEs or fixing TLS crypto are high-priority tasks. task. DNSSEC proponents recognize this. And, for historical reasons, DNSSEC proponents disdain the X.509 machinery behind the TLS CA. DNSSEC’s real job is thus to replace the TLS CA system. This plan is called DANE. TLS CAs do need to be replaced. But it’s hard to imagine a worse replacement than DANE. For something as harebrained as the CA system, remarkably few criminal breaches trace back to it. The real threat to CAs is “the global adversary” i.e., NSA. . Whichever system replaces CAs needs to make TLS more resilient to government attacks. And governments control the DNS. Even in a future where the USG decisively cedes control of the DNS roots, it will retain control of the most important TLDs Amusing fact: the biggest player among TLS CAs? Also the most important DNSSEC player. . And governments with even fewer scruples will control other important TLDs. In a world where users rely on DANE, those governments have much of the same cryptographic authority as the CAs do now. Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys. Rebuttal: 2. Domain owners Storing public keys in DNS gives control to the domain ownership Ensuring cryptographically correct DNS lookups is an enabling technology that can be used to give greater assurance and security control to domain owners. If DNS lookups are assured as secure from the DNS root, then Internet wide PKI becomes much easier whether that PKI is x509 or PGP or SSH or any other public keys. DANE is one of many PKI architectures which exist and can be deployed. DNS enabled PKI architectures have been documented in RFCs and technical papers describing DKIM, SSH, Email User keys [STEED], and other architectures. DNSSEC is not needed to deploy these PKI structures, but if DNSSEC is deployed the assurance of network security provides a significantly large Island of Trust. DNSSEC provides assurance, but does not control the domain's private key. Thus control over DNSSEC does not give any extra control over DNS than without DNSSEC. In short, control over DNS is control with or without DNSSEC. However, this does not mean that DNSSEC is unnecessary... see #1. 3. DNSSEC is Cryptographically Weak The original DNSSEC design is two decades old; the first drafts I can find are from 1994. Real-world DNSSEC therefore relies on RSA with PKCS1v15 padding. The deployed system is littered with 1024-bit keys. No cryptosystem created in 2015 would share DNSSEC’s design. A modern PKI would almost certainly be based on modern elliptic curve signature schemes, techniques for which have coalesced only in the last few years. DNSSEC has virtually no real-world deployment. It makes no engineering sense, knowing what we know now about cryptography, to instigate a massive new deployment of obsolete crypto. Rebuttal: 3. DNSSEC is only as weak as is chosen to be: Keys are cheap to make and easily replaced. A good crypto-system is not determined by newness of idea or implementation. There exist very old archaeological documents that remain undeciphered. It is possible that some of those documents are, in fact, mathematically undecipherable. Cryptography is about math and the speed of computers, not about Unix greybeards versus node.js. The DNSSEC trust root is 2048 bits and includes both x509 certificates as well as PGP keys. Claiming that domain owners or secondary signers utilize 1024 bit keys is a specious argument and has nothing at all to do with DNSSEC as a product. It's important to note that there are significant weak keys and ciphers still in use in CA generated certificates. Weak key use is a security best practices problem, and is solved by proper training regardless of the cryptographic security mechanisms utilized. Again, the sockpuppet authors seem ignorant of currrent cryptography, as elliptic curve ciphers are available in both x509 certificates and in the most recent pgp key creation software. 4. DNSSEC is Expensive To Adopt Today, DNS lookups either succeed or fail. And there are generally two reasons a lookup fails: the name doesn’t exist, or the requestor lacks connectivity to the Internet. Network software is built around those assumptions. DNSSEC changes all of that. It adds two new failure cases: the requestor could be (but probably isn’t) under attack, or everything is fine with the name except that its configuration has expired. Virtually no network software is equipped to handle those cases. Trouble is, software must handle those cases. End-users excoriate browser vendors for making it harder to “click through” certificate warnings, which are common. So frustrating were these warnings that the authors of curl egregiously broke their own API to appease programmers. So there’s no reason to believe that hard failures for DNS lookups will be acceptable to users. But the code that handles lookups today is buried deep in the lowest levels of application network code, and is rarely if ever wired for user interface. Some very popular standard library interfaces (looking at you, gethostbyname(3)) to DNS can’t support DNSSEC failure cases at all. A lot of code will need to be rewritten to make DNSSEC workable. Rebuttal: 4. Everything is expensive, but DNSSEC would give unlimited key generation and storage options to domain owners at the price of electricity to compute the key pairs. There may need to be some software adjustments to fully accommodate DNSSEC. However, there currently exist several DNSSEC plugins, extensions, or modules for several end user browsers. Thus, the code base has already been started, making improvements and merging code bases is the next step. But, well begun is half done. Excuses can always be made to just continue using the broken CA system, but replacement of that system will be 'expensive' whatever the replacement happens to be. 5. DNSSEC is Expensive To Deploy DNSSEC is harder to deploy than TLS. TLS is hard to deploy (look how many guides sysadmins and devops teams write to relate their experience doing it). It’s not hard to find out what a competent devops person makes. Do the math. Rebuttal: DNSSEC requires a domain record, and that the registrar provides a domain signing process. This is extremely easy to setup, and requires very little effort on the part of both a domain owner as well as a registrar. Many registrars have provided DNSSEC signing for many years already. In short, if a devops can type a few characters in a DNS record, a devops can deploy DNSSEC within a few hours depending on the domain complexity. A domain with a few servers should take less than a day or so to configure, test, and put into production. There are also numerous tools and online test suites for validating and configuring DNSSEC. 6. DNSSEC is Incomplete You’d think, for all its deployment expense, the forklifting out of incompatible networking code, and the required adoption of a government PKI running 1990s crypto, DNSSEC would at least nail its marginally valuable core use case. Nope. DNSSEC doesn’t secure browser DNS lookups. In fact, it does nothing for any of the “last mile” of DNS lookups: the link between software and DNS servers. It’s a server-to-server protocol. Why? Because there are two DNS security problems. The first is somewhat esoteric, and allows servers to exploit the way DNS records refer to one another in order to add a bogus record for VICTIM.ORG to a lookup for EVIL.NET. The latter is obvious and allows any attacker with access to the network to simply spoof entire DNS responses. The committee designing DNSSEC split the baby and chose the former problem over the latter. Even if DNSSEC was deployed universally and every zone on the Internet was signed, a coffee-shop attacker would still be able to use DNS to man-in-the-middle browsers. Rebuttal: 6. See #4. Generally #6 is specious. 7. DNSSEC is Unsafe DNSSEC builds on the original DNS database. So applications will need to distinguish between secure DNSSEC records and or insecure DNS records. To solve this problem, DNSSEC provides a cryptographically-secure “no such host” response. But DNSSEC is designed for offline signers; it doesn’t encrypt on the fly. Meanwhile, there are infinite nonexistent hostnames. But all you can sign offline are the hostnames that do exist. So to provide authenticated denial, those signed records “chain”. You cryptographically verify that a record doesn’t exist by observing that no other record chains to it. Authenticated denial. Offline signers. Secret hostnames. Pick two. In the past couple years (reminder: DNSSEC has been “ready to deploy” for almost 15 years), the DNSSEC standards project has solved this problem, if we accept as a “solution” “NSEC3 and “minimum covering NSEC records” with online signers managing DNS zones as a sort of bizarro Unix password file in which fake records are added at random to foil password crackers Confused? Don’t worry, there’s an NSEC5 coming too. . This mode of deployment is, of course, not the default. For everyone who accepts the default, every hostname in their DNS zones are public information. This works for the kind of person who works on standardizing DNS extensions, because their hostnames are things like “dec-multia-in-my-basement.greybeard.com”. It does not work so well for Bank of America. Rebuttal: 7. DNSSEC provides records with public key resources. DNSSEC does not provide encrypted services. All DNS requests are still in the clear. This is well documented in the DNSSEC RFCs. The comment about off-line encryption is a misnomer. The appropriate term would be offline signing of domains and subdomains. This simply means that a domain or subdomain needs to be signed before being deployed. There should be little to no problem doing that for most domains. Furthermore the term offline is a little wrong as well, as a key signing key can be used to instantly sign a domain or subdomain in a service type method. There is a vulnerability in DNSSEC, that is openly listed in the RFCs, that indicates subdomains are enumerated. Thus with DNSSEC fully deployed, a domain cannot hide hosts. However, all signed hosted are cryptographically validated [not encrypted]. This enumerated host – network architecture revealing problem is what NSEC5 is being developed to overcome. However, for simple domains with a few hosts, enumerated architectures should be a minor problem if a problem at all. 8. DNSSEC is Architecturally Unsound Don’t take my word for this; here’s 1981’s End-To-End Arguments In System Design, one of the foundational papers of the Internet: The function in question [security] can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function [security] as a feature of the communication system itself is not possible. A casual look at the last 20 years of security history backs this up: effective security is almost invariably application-level and receives no real support from the network itself. There’s a simple reason for this: security is about policy, and policy is about choices. DNSSEC tries to make a single set of choices for the entire Internet. We all know what to expect: a frankensystem that decisively solves no problems while imposing painful tradeoffs and concessions on everyone. How could US government IT not love it? Rebuttal: 8. Apllication level security provides only as much protection as the host environment. You don't need to look too far to find out that if an application is running in an insecure environment, that application's security is necessarily broken. The trust root, so to speak, of an application running on a Desktop is the Desktop OS [whatever that may be]... no amount of cryptographic function is going to prevent an eavesdropper with root access to the machine bypassing whatever security may be employed. The same is true for servers and all computing platforms. This is one of reasons why Chromebooks include a cryptographical root within the BIOS and then use that root to sign user keys at the OS level. When considering the Chromebook security architecture, it can be clearly seen that DNSSEC is analogous – securing the DNS root level rather than the system BIOS level. 9. DNSSEC doesn’t have to happen. Don’t support it. If you’re running systems carefully today, no security problem you have gets solved by deploying DNSSEC. But lots of other problems —– software maintenance, network operations, user support, protecting your secrets from NSA/GCHQ —– get harder. When it suits DNSSEC boosters to say it, “DNSSEC has been ready to deploy for over a decade”. Other times, “the root zones have only been signed since 2010”. The protocol changed in 1998, 2000, 2001 (“DNSSEC-bis”), 2003 (“the typecode roll”), 2004 (NSEC3, the DNS password file), and 2005. But it still retains the genetic imprint of the first versions of the protocol, designed when serious cryptography was deemed too expensive for DNS servers and before HMAC was invented, let alone deterministic ECC signatures. In the years since the USG paid TIS to solve DNS security, the Internet routed around the damage. TLS isn’t a beautiful system, but its problems don’t stem from the DNS and aren’t solvable in the DNS. It’s protected more people than DNSSEC ever will. The Internet loses nothing if it declares a TKO on DNSSEC and starts fresh. There are better DNS security proposals circulating already. They tend to start at the browser and work their way back to the roots. Support those proposals, and keep DNSSEC code off your servers. Copyright © 2015 Thomas & Erin Ptacek Rebuttal: 9: Conclusion. This sockpuppet Anti-DNSSEC rant is inaccurate, incomplete, and presents a picture of DNSSEC that is unsupported factually, mathematically, and architecturally. The terms used to define cryptographic objects and trust are inaccurate or mislabeled. The authors pose no significant solution to the current CA model while also claiming that DNSSEC does nothing to advance the replacement of the CA model and also that the CA model needs replacing. As I state in this rebuttal, DNSSEC is not a replacement of the CA model, it is an enabler for assurance enhancement of DNS records – and DNSSEC functions quite well architecturally for the part it was designed to fill. |
| mbaehrlxer Apr 14, 2015 11:03 AM EDT |
wow, thank you for taking the effort to write this. i to believe the future of the internet is on topic for lxer, so i expect that no-one will mind this discussion. unfortunately i have to deal with some urgent work so i don't have time right now to study your response. i'll get back to it in a few days... greetings, eMBee. |
| ljmp Apr 14, 2015 4:47 PM EDT |
I was inspired and posted this on HN. So much for not posting somewhere more permanent. Anyway... I suppose I had an argument or two with the author of the original posting. Arguments rarely solve anything... but again oh well... |
| mbaehrlxer Apr 16, 2015 1:18 AM EDT |
could you please post the link on HN? they are hard to find once they drop off the front page. greetings, eMBee. |
| ljmp Apr 16, 2015 4:53 PM EDT |
Sure: https://news.ycombinator.com/item?id=9374802 My thoughts on the HN commenters: danyork has it right. tptacek has it wrong. Reading the bio sections: danyork is a holder of a component of the DNSSEC root private key. From other references: tptacek is the author of the Jan 2015 Anti-DNSSEC post. Simple logically breakdown of argument is mainly two points:
So, if you actually believe NSA could supplant the DNSSEC private key - the anti-DNSSEC position is valid. or If there is no way to partially hide hosts, and that is part of your architecture, then DNSSEC is not for your domain. I see no logical argument beyond these two. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!