Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Universal SSL

blog.cloudflare.com

Post reply on HN
Print view View original

71–80 of 250 posts

Re: Universal SSL

#71

Post by mattmanser »

buro9 wrote: post #39
vader1 wrote: post #23

I have very mixed feelings about this. Yes, on the one hand this is great news because a lot of websites who otherwise never would have bothered with SSL can now be protected from snooping or traffic manipulation on your local (possibly very insecure: your neighborhood Starbucks' wifi) network. On the other hand, this completely destroys the premise of HTTPS that you have an encrypted connection to the website you ar…

> this completely destroys the premise of HTTPS that you have an encrypted connection to the website you are visiting It does nothing of the kind, it has always been the case that seeing the SSL padlock only informed you that the connection to whichever server you are communicating with is encrypted and nothing more. Do you not recall the age of customer feedback pages hosted behind SSL that actually just sent plain…

5 years ago most sites didn't even bother to SSL a lot of their pages and then firesheep came along to show us all how much of a security hole that was.

Harking back to "Oh, but we used to do X back in the day" is a really silly thing to say. Do you still string concat your SQL variables perhaps?

The Snowdon revelations showed that the NSA were happily hoovering up all our plaintext emails because the tech companies were naive enough to decrypt at the edge instead of the source, leaving their internal networks open to easy tapping.

This is the situation Cloudflare have setup.

I am also conflicted, cloudflare is great, but it's obvious that in 5 or 10 years time the next Snowdon will reveal cloudflare was infiltrated on day 727 of cloudflare's life, Gordon Brown brokered the deal with jgrahamc to sell out personal privacy for a pardon for Turing (joke!). It's such an obvious internet security weak point and it's made itself an even more obvious one now.

Re: Universal SSL

#72

Post by buro9 »

iancarroll wrote: post #60
buro9 wrote: post #32

Earlier quoted context omitted.

Just tested using the WinXP+IE6 virtual machine from https://www.modern.ie/en-gb/virtualization-tools Tested against: https://www.buro9.com/ , which is my own domain running behind CloudFlare using their SSL cert (it's a Pro account - my free accounts have not yet been enabled with the free SSL). IE6 on WinXP accesses this without warning providing CloudFlare Apps are disabled. If CloudFlare Apps are enabled, then IE…

Pro accounts don't use SNI.

Right you are.

So a pure SNI test using https://sni.velox.ch/ on IE6 on WinXP does produce a warning dialog, "The name on the security certificate is invalid or does not match the name of the site".

Clicking OK clears it for the remainder of the browser session.

Re: Universal SSL

#73

Post by jgrahamc »

mattmanser wrote: post #71
buro9 wrote: post #39

Earlier quoted context omitted.

> this completely destroys the premise of HTTPS that you have an encrypted connection to the website you are visiting It does nothing of the kind, it has always been the case that seeing the SSL padlock only informed you that the connection to whichever server you are communicating with is encrypted and nothing more. Do you not recall the age of customer feedback pages hosted behind SSL that actually just sent plain…

5 years ago most sites didn't even bother to SSL a lot of their pages and then firesheep came along to show us all how much of a security hole that was. Harking back to "Oh, but we used to do X back in the day" is a really silly thing to say. Do you still string concat your SQL variables perhaps? The Snowdon revelations showed that the NSA were happily hoovering up all our plaintext emails because the tech companies…

Gordon Brown brokered the deal with jgrahamc to sell out personal privacy for a pardon for Turing (joke!)

To be clear... I was opposed to the pardon; it was the apology that I was after (and got).

Re: Universal SSL

#74

Post by benjojo12 »

jgrahamc wrote: post #43
escapologybb wrote: post #41

Earlier quoted context omitted.

Okay, really seems like it is something to do with Cloudflare. When I pause Cloudflare the site loads really quickly every single time, then when I resume using Cloudflare I get the same error in Chrome. In Firefox I'm told by an Cloudflare error page my web server is down, when it's demonstrably not. This is really not my area of expertise, but does it seem to anybody else like this is something to do with the Cloud…

Contact CloudFlare support?

Whats your ticket ID?

Re: Universal SSL

#75

Post by vader1 »

buro9 wrote: post #39
vader1 wrote: post #23

I have very mixed feelings about this. Yes, on the one hand this is great news because a lot of websites who otherwise never would have bothered with SSL can now be protected from snooping or traffic manipulation on your local (possibly very insecure: your neighborhood Starbucks' wifi) network. On the other hand, this completely destroys the premise of HTTPS that you have an encrypted connection to the website you ar…

> this completely destroys the premise of HTTPS that you have an encrypted connection to the website you are visiting It does nothing of the kind, it has always been the case that seeing the SSL padlock only informed you that the connection to whichever server you are communicating with is encrypted and nothing more. Do you not recall the age of customer feedback pages hosted behind SSL that actually just sent plain…

Of course using HTTPS is no guarantee that the site doesn't leak your data in any other way. But never before has it been this easy to create a false sense of security: give the impression that connections to your site are encrypted, while in reality it's plaintext for half of the route.

I think this will ultimately dilute the value of HTTPS as we know it, and can only hope that it will lead to the adoption of better alternatives.

Re: Universal SSL

#76

Post by dividuum »

fiedzia wrote: post #69
dividuum wrote: post #52

EDIT: Won't work: You need to verify that you own the domain by pointing your NS records to cloudflares nameservers. What prevents me from doing this MITM attack in (for example) a public wifi: I add a domain I don't own (example.com) to my cloudflare account. Then I point a hostname (www.example.com) to an IP address I own (1.2.3.4). From what I understand, cloudflare now serves HTTPS for this domain through their p…

I am pretty sure Cloudflare will verify that you are owner of the domain.

I hope so. But I'm still trying to figure out how. The only way I see they do it is that they check that the nameservers responsible for the domain actually points to cloudflares nameservers. This check doesn't seem to happen for http traffic, so it would be interesting to see how that works with https.

Re: Universal SSL

#77

Post by innocenat »

dividuum wrote: post #63
iancarroll wrote: post #57

Earlier quoted context omitted.

That wouldn't work. CloudFlare isn't acting as the RA (the person verifying you own example.com). They serve a verification file at example.com, but the bot cannot see this file as example.com isn't pointing to CloudFlare.

Not sure I'm following you. Probably because I didn't use SSL on cloudflare before, so I don't know about any verification file. How does that work? I guess before serving SSL traffic for a domain they verify both that the nameserver for a domain is actually one of cloudflares nameservers AND they test for the presence of some kind of signed file that has to be reachable on the domain you added?

The verification file are needed by CA issueing cert. I don't think said CA are on your spoofed wifi.

Re: Universal SSL

#78

Post by pdkl95 »

First, let me say that the aggressive approach to actually making encryption happen that CloudFlare has been pushing recently is very commendable. The hard part about finally retiring the old plaintext protocols we currently are stuck with is critical mass - nobody sees the point when plaintext seems to "work just fine". The various steps CloudFlare has taken to encourage SSL will go a long way towards reversing that attitude.

That said, I worry about the future we are creating by entrusting so much security and traffic to a single point of failure.[1]

It seems to me that CloudFlare is positioning themselves as another Google or Facebook, where a key feature of their business is that they get to track the web history of a large portion of internet users. Much like Google gets to have a lot of my email when other party is @gmail.com, CloudFlare gets click histories by people using their CDN and caching/filtering servers.

While I don't really know anything about the motives and personalities behind the company, I can give them the benefit of the doubt for now. Unfortunately, their motives don't matter - in a world where "national security letters" Prism, XKeyscore, and the like exist, CloudFlare's motives may not matter.

Even more concerning is that while it my hard to avoid Google's tracking, it is at least theoretically possible. With CloudFlare (or any similar service) we are stuck with a situation similar to tinyurl/t.co/bit.ly [2] where content is hidden behind serves from which you have to request the real URL (or in this case, the content itself).

Don't get me wrong - SSL becoming significantly more common is good regardless of what else is going on, and CloudFlare still deserves a lot of praise for advancing a problem that has been so resistant to progress in the past. I would even agree that CloudFlare's caching services and security protections are (very) good engineering techniques that we should be using. It just seems like everybody is (yet again) setting up a single point of failure that will suddenly have very significant consequences the minute somebody with real power decides they want those very-revealing server logs.

[1] I'd be the first to admit I don't have the best understanding of how CloudFlare works; corrections to any misunderstandings I may have about their business or tech would be greatly appreciated.

[2] http://preview.tinyurl.com/feckless-imbroglio

Re: Universal SSL

#79

Post by spacefight »

iancarroll wrote: post #58
0x0 wrote: post #53

Earlier quoted context omitted.

I guess you're right about that, but it still feels a bit weird that a third party can just allocate a private key and a valid certificate without the actual owner of the domain requesting it.

CloudFlare just simplifies this process. You can do the same thing if you can upload a file to a site.

It's not the simplification - it's that they do it for all their clients at once - no opt-in.

Re: Universal SSL

#80

Post by Dolimiter »

cynix wrote: post #48

The majority of CloudFlare's IP addresses are blocked by China's great firewall, which means CloudFlare is out of the question if you expect that your website will be visited by Chinese users.

That can't be correct, I get lots of traffic from China, and use Cloudflare. Unfortunately, the traffic is often SQL injection type garbage, so I'm going to be upgrading to Cloudflare Pro as it seems they block such traffic.
Post reply on HN