19 ms·
Cloudflare Introduces Universal DNSSEC: Secure DNS for Your Domain
- collinmanderson 11y agoWow. Cloudflare is the perfect company to push DNSSEC forward. DNSSEC seems incredibly complicated and prone to amplification attacks, and I trust Cloudflare to get it right. :)
- sintaxi 11y agoDoes this seem ironic to anyone else considering CloudFlares SSL offering essentially is a MITM attack?
- jgrahamc 11y agoHow is it an "attack"?
- Tloewald 11y agoHow is Cloudflare SSL a MITM attack? Obviously, they're in the middle, but you have to trust someone.
- blfr 11y agoIn this case, you don't. You can terminate SSL on your own machine, where you are actually running the service/site.
- jerf 11y agoThe essense of "MITM" isn't the Middle but the fact that the Man is unauthorized, Eve to Alice and Bob. If Alice and Bob agree to put CloudFlare (oh, look, the C already works!) in between them, there's a Middle but there's no [unauthorized] Man. SSL's purpose isn't to create some sort of quasi-mythical "direct connection" between Alice and Bob, it's just removing the general Internet as a vector for many attacks. An utterly critical building block of the global Internet, but nothing more; certainly not a magic invocation that casts the spell of Security +1 across the entire communication, neither in fact nor in intent. It's worth taking a moment to try to explore what the idea of "direct connection" is that you have in your head, in a world where Bob is probably already a program generating HTTP with no human interaction in an arbitrarily-complicated manner, with arbitrarily-complicated combinations of SSL accelerators, WAFs, and whoknows what other network appliances, even before we consider what it means to assemble a page from JS and images from 10 different domains representing other entities, and where Alice is using a browser and arbitrary plugins, each of which she is implicitly trusting, and possibly a proxy. If you examine this closely it becomes surprisingly complicated.
- Mtinie 11y ago"...certainly not a magic invocation that casts the spell of Security +1 across the entire communication..." I appreciate the whole post, but this is such a wonderfully geeky turn of phrase that I have to acknowledge it!
- untog 11y agoIs a CDN also a MITM attack?
- jnbiche 11y agoIs an SSL-terminating load balancer an MITM attack?
- nailer 11y agoI think the parent is referring to CloudFlare not requiring SSL between CloudFlare and their customers. An SSL-terminating load balancer is in plaintext between the LB and your servers, whereas CloudFlare Universal SSL can be plaintext over the internet. Since the latter still shows users it's a secure connection, it would be reasonable for CF to require HTTPS between themselves and their customers. Last time I asked CF about this, their answer was "yes, but not our problem".
- meowface 11y agoThey allow "SSL termination" where traffic to/from Cloudflare's Edge is protected with TLS, as well as full TLS, where you also provide your own certificate and the entire chain is protected.e. So, you can very easily opt out of the "MITM" if you buy your own certificate. You can use a self-signed one to get a little more safety within Cloudflare's network, or a CA-signed one for a lot more safety.
- deleted 11y ago[deleted]
- mtgx 11y agoWhy not DNSCurve? http://dnscurve.org http://dnscurve.org I mean, I feel like adoption is so low for DNSSEC already - does it even matter if it's 0% for DNSCurve or 1% adoption for DNSSEC? Why even bother with a 20 year old protocol?
- treenyc 11y agoSounds like a better option. Why should I trust a single company when there are open source non-profit alternative?
- treenyc 11y agoSounds like a better option. Why should I trust a single company when there are open source non-profit alternative?
- drdaeman 11y agoDNSSEC and DNSCurve are completely different matters. As far as I understand (I may be wrong!): 1. DNSCurve establishes an encrypted and, optionally, authenticated channel between you and upstream nameserver. It doesn't do anything about the data that is served over that channel. 2. DNSSEC protects the integrity of the data that is served by authoritative nameserver (and redistributed further) from some rogue adversaries (except for registries). About DNSCurve - you should ask your upstream nameserver provider (usually, an ISP) to support it. Although everyone running a nameserver should do so. But it's purpose is completely different from DNSSEC is about - even though the latter's concept is flawed.
- deleted 11y ago[deleted]
- jgrahamc 11y agoIs darronz a CloudFlare employee?
- jeromegv 11y agoI just got the announcement through my email so it seems more likely than a HN reader got the same announcement and decided to post about it.
- jacquesm 11y agoIf you don't know for sure that that is a post by a cloudflare employee then I suggest you change the text or delete the comment. When google rolls out a new feature there are 10's of submissions around the theme and surely not all of those are by google employees, why should cloudflare be any different?
- blantonl 11y agoExactly. And why should it matter anyways who posted the article here on HN? The community here decides what is or is not worthy of discussion, not any single company.
- Kiro 11y agoWhat makes you think it's a CloudFlare employee?
- deleted 11y ago[deleted]
- EwanToo 11y agoDupe of https://news.ycombinator.com/item?id=10539245 https://news.ycombinator.com/item?id=10539245 ?
- jgrahamc 11y agoThis is a post of the DNSSEC microsite containing a bunch of information (not sure who the poster is, it's not someone from CloudFlare) whereas that's a link the announcement blog.
- tptacek 11y agoI think it's important that those of you who haven't read up on DNSSEC understand how bad an idea it is: https://news.ycombinator.com/item?id=10539418 https://news.ycombinator.com/item?id=10539418 If DNSSEC had been deployed a few years back, Muammar Gadaffi could conceivably controlled BIT.LY's TLS keys. Yesterday, today, and tomorrow, DNSSEC gives the NSA immense control over the TLS keys of sites in .COM, .ORG, .NET, .CO.UK, .IO, .COM.AU, and many more.
- caskance 11y agoThat's what it means to have a domain in Libya - you're subject to the jurisdiction of the officially recognized Libyan government. If you don't want to have to deal with the whims of a crazy dictator, don't register your business in his country.
- tptacek 11y ago"DNSSEC: everything will be fine as long as everyone moves to domains in Bouvet Island's .BV. Brought to you by Cloudflare."
- drzaiusapelord 11y agoand exactly what country is safe from the whims of politics? I was just reading about censorship in the Netherlands and other Euro states because of fear of offending religious people, especially muslims. If the far left Europeans can't protect speech, then who can? DNNSEC just enables centralized government control on a level that's not needed. DNS is fine as-is. Domain authentication should be done via the transport layer like SSL. That's the way things are going now anyway.
- danyork 11y agoIt's great to see this microsite (and the announcement yesterday) as this rollout by CloudFlare will do two major things to help move DNSSEC forward: 1. Simplify the process of setting up DNSSEC-signing for so many people; and 2. Advance the usage of stronger crypto through the used of ECDSA (DNSSEC algorithm 13). The first point will help with getting many more domains signed. The second point will help those of us who want to see even stronger crypto used within DNSSEC. On that last note, I'd also note that there is an Internet Draft submitted about adding Ed25519 as a new DNSSEC crypto algorithm. You can find it here: https://tools.ietf.org/html/draft-sury-dnskey-ed25519-01 https://tools.ietf.org/html/draft-sury-dnskey-ed25519-01 Support for this draft within the IETF working groups - and indeed in implementations - will help make this a reality.
- tptacek 11y ago1. The roots and TLDs remain RSA-keyed. 2. As recently as months ago, those keys were 1024-bit RSA. 3. If the zones above those Cloudflare manages are RSA, it doesn't matter if Cloudflare's own zones are ECDSA. 4. ECDSA is itself outmoded and dangerous.[1]. Cloudflare has the first significant deployment of curve-based DNS on the Internet, and because of standards group torpor, they're forced to use bad NIST-curve DSA, while the rest of the world has moved on to better curves and deterministic signatures. 5. It takes just a few hours to write a new draft for ED25519. Pretty much the entire browser vendor community agrees that TLS needs a standardized Curve25519; a draft for that was submitted over a year ago, and still hasn't made it out of committee because of bikeshedding. Worse: browsers can enable Curve25519 piecemeal, because TLS is a negotiation protocol. DNS isn't. Because DNSSEC advocates have pushed deployment of broken '90s crypto, it could take close to a decade to get Ed25519 deployable in DNSSEC. The idea that better DNSSEC crypto is just a standards document away is a pretty good illustration of what has gone wrong with 21+ years of attempted DNSSEC standardization. There's a better alternative than DNSSEC, and it isn't DNSCurve: it is literally "do nothing". Don't break the Internet. Don't create a massive new deployment of embarrassing old curve crypto. Don't effectively sign keys over to the NSA. Billions of dollars of commerce flow over the Internet every week and none of it, not one bit, is protected by DNS security. DNSSEC isn't useful, it isn't needed, it certainly isn't a priority. It's in this case a way for Cloudflare to make some extra money, and nothing more. [1]: http://blog.cr.yp.to/20140323-ecdsa.html http://blog.cr.yp.to/20140323-ecdsa.html
- arca_vorago 11y agoDNSCurve and DNSCrypt are the better solutions for slightly different problems that I think we should be pushing.
- jgrahamc 11y agoCome work at CloudFlare! Let's get working on that.
- jedisct1 11y agoAre you serious about that?
- jgrahamc 11y agoWe're interested in making the Internet more secure. Go look at our history. Why would we not be thinking about ways to secure DNS etc. further?
- deftnerd 11y agoWell said! I know one thing I would like is Cloudflare doing something magical with Sub Resource Integrity. Maybe if the source HTML specifies a SRI string, check that the hash in the HTML matches the hash of the resource before allowing it in your cache for that website. If it doesn't match, don't cache that resource and don't serve it. This would allow sites to enable and enforce SRI without browser support.
- arca_vorago 11y agoIt's good to see CloudFlare continuing to embrace security as it evolves. I saw the AMA Matthew Prince did where he said he was concerned about ICANN giving control to the UN, which is a bigger deal than most admit, and he also said he was against regionalization of the net, another issue that doesn't get enough attention. Keep up the good work.
- gwu78 11y agoThis is the fourth time in the last 30 days I have seen some blog post about DNSSEC on the front page. Three overtly pushing Cloudflare DNSSEC and one about email and DNSSEC written by a Cloudflare employee. But still no discussion of cache poisoning. So if a user runs their own personal cache bound to the loopback do they need DNSSEC? What if they run their own root? What if they have local copies of all the zones they need? DNSSEC gives control to untrusted third parties to periodically determine what is and what is not a "valid" domain name. What are the protections against abuse of this control? I would not call DNSSEC "secure DNS". I would call it "validated DNS". The question is who is doing the "validation"? And why should we as users trust them more than the endpoint we're trying to reach?
- fensipens 11y ago> This is the fourth time in the last 30 days I have seen some blog post about DNSSEC on the front page. Three overtly pushing Cloudflare DNSSEC and one about email and DNSSEC written by a Cloudflare employee. Absolutely, this is getting out of hand. Would be easier to just buy HN and replace all top stories with your crappy DNSSEC ads..
- peterwwillis 11y agoLet's not lose sight of the fact that DNSSEC purports to make client connections more secure. Does it? - If the server in question doesn't have DNSSEC set up: No. - If there is a problem with one of the pieces of DNS infrastructure between the server and client: No. - If the DNS resolver server the client is using doesn't support DNSSEC: No. - If the client's stub resolver isn't a validating one: No. - The user is never notified if DNSSEC is working for them or not. They can only determine this by making queries with a command-line tool, or when they get a 'could not resolve domain' error on an invalidly-configured domain. --- Compare this to HTTPS, where the only thing the client needs to verify a secure connection is: - The server delivering its certificate and certificate chain to the client - The client validates the certificates - If it isn't validated the user knows immediately. You can go ahead and implement DNSSEC for your server, but when it comes to HTTPS connections, this does not improve user security over what we have now.