5 ms·
'Trivially easy' to buy SSL certificate for domain you don't own
- mike-cardwell 17y agoYet another reason why the CA system is inherently untrustworthy and something like this should be adopted instead: https://secure.grepular.com/DNSSEC_Will_Kill_Commercial_CAs https://secure.grepular.com/DNSSEC_Will_Kill_Commercial_CAs
- tptacek 17y agoDNSSEC is drastically less secure than TLS is, and is itself a monolithic PKI. My guess, after looking at that link, is that the author of that post has never read the DNSSEC specs.
- tbrownaw 17y ago> DNSSEC is drastically less secure than TLS is .... My guess, after looking at that link, is that the author of that post has never read the DNSSEC specs. How so? The purpose of DNSSEC is to prevent the data from being tampered with (say, by a MitM or an evil caching resolver), does it not manage to do this? > DNSSEC ... is itself a monolithic PKI. It is many times better than a PKI with 128 independently and fully trusted CAs, since Evilco can't just go shopping for the most subvertible CA.
- tptacek 17y agoNo, it doesn't manage to do that. Here's a laundry list of problems with DNSSEC: * Amazingly, contrary to everything you'd expect about "secure DNS", DNSSEC does not in fact secure DNS queries from your machine. Instead, it delegates securing DNS to DNSSEC-enabled resolver servers. For securing the actual queries your computer makes, your browser is on its own. There's a whole different protocol, TSIG, intended to address that problem. * DNSSEC has zero successful real-world deployments, and no existing integration with any TLS stack. DNSSEC obviously does nothing to secure your actual traffic; all it does is try to protect the name lookup. TLS protects both. * DNSSEC does nothing to address all the other intercepts, from ARP to BGP4, that real traffic has to contend with. Once you go from name to IP address (or "cert" in the fairytale world where DNSSEC has replaced the CAs), you're on your own. TLS addresses all of these issues except for CA configuration. * DNSSEC actually reduces the security of DNS in some ways: in order to authenticate "no such host", DNSSEC publishes a sort-of-encrypted list of all your hosts. There's a whole other standards group drama surrounding the proposals to resolve this problem (NSEC3, whitelies, etc). * DNSSEC fails badly compared to TLS. When keys inevitably get screwed up in TLS, you get a browser click-through. There is no API support to recover from a "gethostbyname()" failure caused by DNSSEC. This sounds like a reliability problem, but it's actually a security problem, in the same sense as "the little blue key icon isn't big enough" is a security problem for SSL. We just don't know what the exploit is, because nobody has designed the "solution" for this problem. * TLS has 15+ years of formal review (it is the most reviewed cryptosystem ever published). We still find things in it. DNSSEC has received nothing resembling the same scrutiny. It's ludicrous to believe we won't find horrible problems with it. You'd be asserting that a protocol co-designed by Paul Kocher will eventually fare worse than one designed by the IETF DNS working group. The IETF DNS working group would basically have to crush some of the smartest practical crypto people in the world. * TLS is at least configurable (virtually all TLS problems are in fact user interface and configuration problems, not problems with the underlying system). You can nuke untrustworthy CAs. There is no clean way to opt in or out of different DNSSEC policies, as the drama surrounding DLV illustrates. In the '90s, we designed web security to assume that DNS was insecure. That was a smart decision. "Security" means different things to different people. It's a policy decision. The end-to-end argument strongly suggests that it's something that can't be baked into the lower parts of the stack. DNSSEC is a step backwards. I think you can already see the indications of the problems it will cause just by looking at the places it already falls down. What we need is a concerted effort to solve the security UI and policy problems that browsers have.
- mike-cardwell 17y agoI'm not sure you understand what the post was suggesting. All it was suggesting is that instead of validating the SSL certificate sent by using the hardcoded certs in the browser, it's validated by doing a DNS lookup to retrieve a hash of the cert. Where DNSSEC is used to "secure" the validity of that lookup. It could even be an addition to the protocol, so the validation is done as normal with the CA's certificates which are hardcoded in the browser, but then a DNS lookup is done as well. That would defend from unscrupulous CA's that create additional certificates for a domain and give them to government organisations.
- tptacek 17y agoThe original post was suggesting that we augment SSL by using DNSSEC to distribute cert authenticators instead of CAs. I'm saying that, for a lot of reasons, grafting DNSSEC onto web security is a solution far inferior to simply keeping TLS and solving the UI and policy problems we inevitably need to solve anyways.
- tbrownaw 17y agoSome of the problems are inherent in having multiple trusted CAs, or third-party CAs. These can be mostly solved by merging the CA function into DNS, or (almost) completely solved by something like Perspectives. Problems being: * someone who wants a fake cert, can go shopping for the worst CA available. You as a site owner cannot specify a CA. * in order to have a cert on your site, you have to pay off a third party. Otherwise the browsers will scream at your visitors that unknown https is more insecure than plain http. ubiquitous encryption requires that certs come "for free" with what you need to just have a presence (such as being bundled with the domain name because they're just an extra DNS record).
- tptacek 17y agoIt is, I think, a little crazy to suggest that a very simple configuration problem with the best-tested security protocol on the Internet should be solved by a complete overhaul of a different core Internet protocol.
- Mark_B 17y agoHEY! I just noticed your comment is id 1234567. CONGRATULATIONS!!
- lurkinggrue 17y agoAmazing! That's the combination on my luggage.
- pilif 17y agoThat reminds me: I'd like to purchase a SSL certificate for my domain please. The domain is gmail.com and to prove that it's mine, please send the confirmation to xxxx@gmail.com Thanks in advance! In the end though, most phishing attacks still use non-secured connections or they purchase one of these domain validation only certificates for evildomain.org and then use the usual tricks like paypal.com.evildomain.org or whatever. This would even work with EV certificates, helping the phishers to gain that green address bar said to be unachievable for them. SSL only proves identity. It can't say anything about malicious intents.
- mike-cardwell 17y agoThey tend to have a list of addresses that the certificate can be sent to, eg: postmaster@domain webmaster@domain ssladmin@domain If you can get access to ssladmin@gmail.com, then you can probably register an SSL cert for gmail.com.
- gus_massa 17y agoThe problem is that if each CA makes its own list, it is very difficult to make a secure web mail service and I hope that no Susan Sladmin is working at your organization. If I want to make a Mailinator clone, which address should I reserve? (For example webmaster@mailinator.com is working. http://www.mailinator.com/maildir.jsp?email=webmaster http://www.mailinator.com/maildir.jsp?email=webmaster)
- mike-cardwell 17y agoYes. There are hundreds of CA's and they all work differently. It's a security nightmare.
- UmYeah 17y agoApril fools? Please. The saddest part of this is that companies are spending thousands of dollars on these certificates without any knowledge of how it works. But hey, that lock on the address bar sure makes me feel secure.
- sp332 17y agoThat's how they are marketed, after all. Not by everyone, but check out the "features" on GoDaddy's SSL cert page: http://www.godaddy.com/ssl/ssl-certificates.aspx?ci=8979 http://www.godaddy.com/ssl/ssl-certificates.aspx?ci=8979 "Bigger, more colorful icons! Yay!"
- qeorge 17y agoFor better or for worse, big lock icons and green toolbars do help conversions.
- patio11 17y agoI have always thought that the key achievement of SSL was marketing. Specifically, while data can be sniffed off the wire on http connections, this was not a very practical attack until wireless started becoming popular. Compromising clients, servers or phishing were easier and more lucrative. However, people had generalized feelings of insecurity on conducting business over the Internet ("But what if hackers get my credit card with their magic super powers!?"), and SSL was a great solution to that: it is white magic which totally neutralizes the black magic. Take that, hackers -- the Internet is now open for business. And for phishing and insecure passwords and compromised servers but, hey, none of those things scare people away from typing in their credit card numbers. So to the extent that the white magic doesn't actually work, well, it doesn't really need to work. It just needs to be, to quote the most common description, As Good As What Your Bank Uses.
- tptacek 17y agoSniffing data off the Internet backbone was so practical that there are well-known cases of it actually happening to backbone providers. In one famous case, someone managed to hook solsniff.c up to Sprintnet's core.
- count 17y agoI no longer worry about the backbone sniffers - that's like drinking from a firehouse the size of 3 Gorges Dam. You can't surreptitiously consume that much I/O. I'm much more concerned about small targeted stuff in data centers and colo cages, sniffing just a few backend servers, behind the SSL terminator. Or, you know, just 'select * from creditcardinfo';...
- ssp 17y agoOne thing I like about my bank: I can send them an entirely unencrypted email and ask them to move money from my account to some other account, and they will do it. It was a pleasant surprise that I could do this; I fully expected it to be somewhere between "Not ever gonna happen" and "You can do this at full moon, but only if you stand on one leg while singing the Canadian national anthem blindfolded and entering a secret string of letters and digits into an Advanced Security System with over 9000 bits of encryption".
- jluxenberg 17y agoOnce you have a SSL cert for a domain you don't own, to use it you'd need to be able to host content on a domain you don't own. Surely this makes this kind of attack less viable?
- swolchok 17y agoWith such a cert, you can carry out a man in the middle attack without triggering SSL warnings (in the typical usage model for SSL), because you have a valid cert.