8 ms·

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 no

by vader1 12y ago

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 are visiting. If this catches on big time, seeing the padlock will only tell you that you have an encrypted connection to Cloudflare's network, and no way of knowing if the traffic is still encrypted beyond that, or that it's flowing in plaintext between Cloudflare and the actual target server. Worse, you will have absolutely no way of knowing if the content you're seeing is what the target server originally sent, or that it has been manipulated (or wiretapped) by Cloudflare itself or any of the other hops while en route. If you are going to use this, just keep in mind that you're giving Cloudflare - a US company subject to the Patriot Act and the whole shebang of 3-letter agencies - the ability to collect, intercept, store, and manipulate every single byte of traffic sent between your users and your servers.

logn 12y ago
What they should do is require that the server has at least a self-signed certificate. They already support that but don't require it.
- meowface 12y ago
  I think this is a good idea as well. In their blog post they discuss how "Full SSL" is much better security than "Flexible SSL", but by not making it a requirement a lot of people won't bother with it.
  - ultramancool 12y ago
    "Full SSL" is still useless against an advanced attacker as it does absolutely nothing to prevent MITM. Only "Strict SSL" does, which makes sure it's a valid CA-signed certificate. What we need (and what myself and others have requested) is Full SSL with fingerprint checking so you can keep security with a self-signed cert. I honestly think CF should remove flexible SSL and full SSL as options - they're just too vulnerable to be valuable.
    - sbierwagen 12y ago
      Or public key pinning: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-19 http://tools.ietf.org/html/draft-ietf-websec-key-pinning-19
      - ultramancool 12y ago
        Yeah, if they supported that and showed you the fingerprint of the pinned key it may be workable. My worry with that is that few of the smaller websites would bother to validate it. Pasting a fingerprint in removes the need.
    - eli 12y ago
      Will Cloudflare take any self-signed certificate in that scenario? I assumed you'd have to confirm the fingerprint (essentially pinning it) from within Cloudflare interface.
      - ultramancool 12y ago
        Currently in "Full SSL" mode they take any self-signed certificate. No fingerprint confirmation or even pinning. I use CF on multiple sites and generally love it, but this is one of their biggest shortcomings - I still need to buy certs if I don't want to get MITM'd.
    - yincrash 12y ago
      Can you elaborate on what the attack on Full SSL would be? If you give CF your self signed certificate over a private secure channel, why isn't that still secure?
      - ultramancool 12y ago
        That would be secure. What they do is not secure. You never send them your public key, they simply try to connect to you take _any_ self-signed public key without performing any verification, allowing trivial MITM between them and your web server. I would love to be wrong here, but please show me where you upload your public key. Last time I used full SSL at least there was no such option. No upload of public key or paste of fingerprint, they simply take anything your (or an attacker's) server provides on connection.
- peterwwillis 12y ago
  What good would that do? A self-signed cert is about as secure as no cert at all. (Unless they implement their own form of certificate pinning for the origin, which would cause problems for sites with multiple certs on the same host, which is quite common)
  - ceejayoz 12y ago
    > A self-signed cert is about as secure as no cert at all. It protects enormously against a casual attacker who is able to sniff network traffic but not MITM you.
    - peterwwillis 12y ago
      This is the nail-clipper defense. For cases where a terrorist might take over a plane by threatening to give people tiny cuts or jabs, taking away nail clippers 'protects enormously'. How often have you encountered read-only network access? It doesn't happen in reality; even the middle hop in a route has total control over the flow of traffic and thus can terminate it and mitm on reconnect. In any case, confidentiality is next to worthless without integrity and non-repudiation.
      - ceejayoz 12y ago
        > How often have you encountered read-only network access? Public wireless points (i.e. Firesheep), any network with a hub instead of a switch...
        peterwwillis 12y ago
        None of those are read-only.
        ceejayoz 12y ago
        I don't recall ever being on a public hotspot that let me change its DNS settings to hijack other users' Facebook traffic.
orf 12y ago
I agree, but a big part of Cloudflare's business is to manipulate the content between the origin server and the client. There is an element of trust when using Cloudflare.
buro9 12y ago
> 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 text emails over the internet to the customer service email? SSL was never a guarantee that end-to-end communication was encrypted, and usually it was barely that. What CF have done is to say that the jump to their servers can now be secured by SSL and that this works even for those who would not configure SSL (for either cost or complexity reasons). It's nothing more than that, it remains the case with SSL that you are trusting the site to support end-to-end encryption for sensitive data. But what it does allow CF to do is partner with companies like Linode, Digital Ocean and so on, so that in effect when a user connects to CF via an SSL connection the entirety of the communication could occur within the trusted CF+Partner network and none of the traffic would be plain text over the internet. It's a foundation to build upon.
- vader1 12y ago
  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.
  - switch007 12y ago
    I would bet there are many, many load-balancers terminating SSL and then proxying plain HTTP to web servers over a VLAN.
    - peterwwillis 12y ago
      Actually, that's a good model. It would have kept the memory (and code execution domain) of the application server independent from the memory of the SSL terminator during Heartbleed. If you terminate SSL on the same box as your app server you're putting many eggs into one basket.
moe 12y ago
seeing the padlock will only tell you Seeing the padlock has never told you much interesting to begin with. You have to click the padlock and compare the fingerprint to a known good one. Yes, nobody does that. And that's why SSL in the browser is a red herring (as far as 3-letter agencies are concerned). Why no browser vendor ever tried to fix this basic design flaw is left as an exercise to the reader.
- rictic 12y ago
  Browser makers and others have been trying to fix this, it is actually harder than it looks. HSTS, certificate transparency, and shipping pre-pinned certs with the browser are all approaches pushed forward by browser makers. As an example of how this is harder than it looks one need only look to DNSSEC.
  - moe 12y ago
    pushed forward by browser makers Huh? Which browser alerts me when the cert changes from the previous one that it has seen for a site? That would be the most basic and trivial mitigation for a start. What we see instead is consortium paralysis for decades. Occam's razor much? HSTS does nothing for certificate trust. And the other two you mentioned still conveniently keep us at the mercy of browser vendors and infrastructure owners. Don't drink the snake oil.
    - jessaustin 12y ago
      Which browser alerts me when the cert changes from the previous one that it has seen for a site? This alone would make self-signing much more viable for many uses.
      - tekacs 12y ago
        Firefox + self-signed certs forces you to add an exception for the site, which makes the cert work and shouts at you again if that cert ever changes, so fulfilling the above. :)
neurobro 12y ago
Assuming I understand what they're offering here, I'd consider something like this for self-hosting a Facebook game having no valuable data, as Facebook requires apps to use SSL, and users tend to shy away from bright red browser windows with dire warnings about untrusted security certificates.
jerf 12y ago
"On the other hand, this completely destroys the premise of HTTPS that you have an encrypted connection to the website you are visiting." Yes, you do. You are visiting a website that CloudFlare is serving, and you have encryption to that. Other replies have already gone into how HTTPS never guaranteed anything about what happened after that, but I think that's the wrong POV. What HTTPS guarantees is that one of the central certificate authorities have authenticated that the entity they have granted the cert to is indeed that entity, and the entity can then do whatever they please with that certificate. (Which may be wrong, in which case you have already lost.) If the entity chooses to grant CloudFlare the authority to speak in their name, then it is a statement on their part that they trust CloudFlare to do so. It is not particularly different than any other bit of internal traffic. It is and always has been the responsibility of the certificate-owning entity to decide what to do with their certificate. This isn't new. This isn't even remotely new. The concept of allowing designated others to speak in someone's name is ancient, and even in the SSL world it has been going on forever. How many HTTPS sites are being served by Amazon or Rackspace or Linode, which are all technically capable of intercepting the plaintext request at will, or forging the response, or just plain stealing the certificate? It's bizarre to me to see people flipping out as if CloudFlare is doing something new, when it isn't new in the slightest. HTTPS has never been an assertion that the certificate holder is the only participant in the transaction. It has always been a statement of trust by the cert holder that everyone involved in the transaction is trustworthy, and it has always been the case that that statement could be in error, and it has always been the case that if that is so, you've already lost anyhow.
- pbreit 12y ago
  "https" has always implied that you are getting a secure connection between the browser and the origin server. I'm not sure how you can argue otherwise.
- alok-g 12y ago
  >> "On the other hand, this completely destroys the premise of HTTPS that you have an encrypted connection to the website you are visiting." >> Yes, you do. You are visiting a website that CloudFlare is serving, and you have encryption to that. Total newbie here. Since CloudFlare (and likewise any other CDN) is hosting many websites, how do I know the information served originated from the intended website and not from another one CloudFlare is hosting? We have been told to look at the browser's address bar to make sure domain belongs to the intended website (e.g., citibank.com and not citibank.another.com). With browser pulling information from CloudFlare, and often over twenty others listed by NoScript and Ghostery on practically every website today, what precautions should I be taking?
pbreit 12y ago
Yeah, it strikes me as worse than no SSL since it creates a false impression of security. I'm surprised they are doing this.
HoochTHX 12y ago
Thank you for pointing out that this is the now-equivalent of the clipper chip. I loved the 90's, I get to wear my parachute pants again, Yay!
itistoday2 12y ago
There's also the small issue whereby DNS MITM completely bypasses all of CloudFlare's protection... And no, DNSSEC won't help here: https://twitter.com/taoeffect/status/516650413987467266 https://twitter.com/taoeffect/status/516650413987467266
cyphunk 12y ago
thinking that the green padlock > red padlock has been a false positive for trust since forever. Any trust other than the red padlock is just a lie. About time we learn that, and understand the entire CA setup trying to convince you of something else is broken.
jingo 12y ago
What is it with Cloudflare marketing posts making page 1 on a daily basis? Is there some business relationship between HN and CF? The title of this one started off as "free" SSL. Now it is "universal SSL". C'mon. As vader1 points out, the level of potential deception here is getting a wee bit high. CF is just a MITM. A website owner lets CF control her DNS and this allows CF to route all requests for her website through CF servers; CF stands between the website and the user. Unless the website owner configures SSL then the user only gets an encrypted connection to CF. That's hardly "universal" SSL.

by vader1 12y ago

logn 12y ago

What they should do is require that the server has at least a self-signed certificate. They already support that but don't require it.

meowface 12y ago
I think this is a good idea as well. In their blog post they discuss how "Full SSL" is much better security than "Flexible SSL", but by not making it a requirement a lot of people won't bother with it.
- ultramancool 12y ago
  "Full SSL" is still useless against an advanced attacker as it does absolutely nothing to prevent MITM. Only "Strict SSL" does, which makes sure it's a valid CA-signed certificate. What we need (and what myself and others have requested) is Full SSL with fingerprint checking so you can keep security with a self-signed cert. I honestly think CF should remove flexible SSL and full SSL as options - they're just too vulnerable to be valuable.
  - sbierwagen 12y ago
    Or public key pinning: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-19 http://tools.ietf.org/html/draft-ietf-websec-key-pinning-19
    - ultramancool 12y ago
      Yeah, if they supported that and showed you the fingerprint of the pinned key it may be workable. My worry with that is that few of the smaller websites would bother to validate it. Pasting a fingerprint in removes the need.
  - eli 12y ago
    Will Cloudflare take any self-signed certificate in that scenario? I assumed you'd have to confirm the fingerprint (essentially pinning it) from within Cloudflare interface.
    - ultramancool 12y ago
      Currently in "Full SSL" mode they take any self-signed certificate. No fingerprint confirmation or even pinning. I use CF on multiple sites and generally love it, but this is one of their biggest shortcomings - I still need to buy certs if I don't want to get MITM'd.
  - yincrash 12y ago
    Can you elaborate on what the attack on Full SSL would be? If you give CF your self signed certificate over a private secure channel, why isn't that still secure?
    - ultramancool 12y ago
      That would be secure. What they do is not secure. You never send them your public key, they simply try to connect to you take _any_ self-signed public key without performing any verification, allowing trivial MITM between them and your web server. I would love to be wrong here, but please show me where you upload your public key. Last time I used full SSL at least there was no such option. No upload of public key or paste of fingerprint, they simply take anything your (or an attacker's) server provides on connection.
peterwwillis 12y ago
What good would that do? A self-signed cert is about as secure as no cert at all. (Unless they implement their own form of certificate pinning for the origin, which would cause problems for sites with multiple certs on the same host, which is quite common)
- ceejayoz 12y ago
  > A self-signed cert is about as secure as no cert at all. It protects enormously against a casual attacker who is able to sniff network traffic but not MITM you.
  - peterwwillis 12y ago
    This is the nail-clipper defense. For cases where a terrorist might take over a plane by threatening to give people tiny cuts or jabs, taking away nail clippers 'protects enormously'. How often have you encountered read-only network access? It doesn't happen in reality; even the middle hop in a route has total control over the flow of traffic and thus can terminate it and mitm on reconnect. In any case, confidentiality is next to worthless without integrity and non-repudiation.
    - ceejayoz 12y ago
      > How often have you encountered read-only network access? Public wireless points (i.e. Firesheep), any network with a hub instead of a switch...
      - peterwwillis 12y ago
        None of those are read-only.
        ceejayoz 12y ago
        I don't recall ever being on a public hotspot that let me change its DNS settings to hijack other users' Facebook traffic.

orf 12y ago

I agree, but a big part of Cloudflare's business is to manipulate the content between the origin server and the client. There is an element of trust when using Cloudflare.

buro9 12y ago

> 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 text emails over the internet to the customer service email? SSL was never a guarantee that end-to-end communication was encrypted, and usually it was barely that. What CF have done is to say that the jump to their servers can now be secured by SSL and that this works even for those who would not configure SSL (for either cost or complexity reasons). It's nothing more than that, it remains the case with SSL that you are trusting the site to support end-to-end encryption for sensitive data. But what it does allow CF to do is partner with companies like Linode, Digital Ocean and so on, so that in effect when a user connects to CF via an SSL connection the entirety of the communication could occur within the trusted CF+Partner network and none of the traffic would be plain text over the internet. It's a foundation to build upon.

vader1 12y ago
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.
- switch007 12y ago
  I would bet there are many, many load-balancers terminating SSL and then proxying plain HTTP to web servers over a VLAN.
  - peterwwillis 12y ago
    Actually, that's a good model. It would have kept the memory (and code execution domain) of the application server independent from the memory of the SSL terminator during Heartbleed. If you terminate SSL on the same box as your app server you're putting many eggs into one basket.

moe 12y ago

seeing the padlock will only tell you Seeing the padlock has never told you much interesting to begin with. You have to click the padlock and compare the fingerprint to a known good one. Yes, nobody does that. And that's why SSL in the browser is a red herring (as far as 3-letter agencies are concerned). Why no browser vendor ever tried to fix this basic design flaw is left as an exercise to the reader.

rictic 12y ago
Browser makers and others have been trying to fix this, it is actually harder than it looks. HSTS, certificate transparency, and shipping pre-pinned certs with the browser are all approaches pushed forward by browser makers. As an example of how this is harder than it looks one need only look to DNSSEC.
- moe 12y ago
  pushed forward by browser makers Huh? Which browser alerts me when the cert changes from the previous one that it has seen for a site? That would be the most basic and trivial mitigation for a start. What we see instead is consortium paralysis for decades. Occam's razor much? HSTS does nothing for certificate trust. And the other two you mentioned still conveniently keep us at the mercy of browser vendors and infrastructure owners. Don't drink the snake oil.
  - jessaustin 12y ago
    Which browser alerts me when the cert changes from the previous one that it has seen for a site? This alone would make self-signing much more viable for many uses.
    - tekacs 12y ago
      Firefox + self-signed certs forces you to add an exception for the site, which makes the cert work and shouts at you again if that cert ever changes, so fulfilling the above. :)

neurobro 12y ago

Assuming I understand what they're offering here, I'd consider something like this for self-hosting a Facebook game having no valuable data, as Facebook requires apps to use SSL, and users tend to shy away from bright red browser windows with dire warnings about untrusted security certificates.

jerf 12y ago

"On the other hand, this completely destroys the premise of HTTPS that you have an encrypted connection to the website you are visiting." Yes, you do. You are visiting a website that CloudFlare is serving, and you have encryption to that. Other replies have already gone into how HTTPS never guaranteed anything about what happened after that, but I think that's the wrong POV. What HTTPS guarantees is that one of the central certificate authorities have authenticated that the entity they have granted the cert to is indeed that entity, and the entity can then do whatever they please with that certificate. (Which may be wrong, in which case you have already lost.) If the entity chooses to grant CloudFlare the authority to speak in their name, then it is a statement on their part that they trust CloudFlare to do so. It is not particularly different than any other bit of internal traffic. It is and always has been the responsibility of the certificate-owning entity to decide what to do with their certificate. This isn't new. This isn't even remotely new. The concept of allowing designated others to speak in someone's name is ancient, and even in the SSL world it has been going on forever. How many HTTPS sites are being served by Amazon or Rackspace or Linode, which are all technically capable of intercepting the plaintext request at will, or forging the response, or just plain stealing the certificate? It's bizarre to me to see people flipping out as if CloudFlare is doing something new, when it isn't new in the slightest. HTTPS has never been an assertion that the certificate holder is the only participant in the transaction. It has always been a statement of trust by the cert holder that everyone involved in the transaction is trustworthy, and it has always been the case that that statement could be in error, and it has always been the case that if that is so, you've already lost anyhow.

pbreit 12y ago
"https" has always implied that you are getting a secure connection between the browser and the origin server. I'm not sure how you can argue otherwise.
alok-g 12y ago
>> "On the other hand, this completely destroys the premise of HTTPS that you have an encrypted connection to the website you are visiting." >> Yes, you do. You are visiting a website that CloudFlare is serving, and you have encryption to that. Total newbie here. Since CloudFlare (and likewise any other CDN) is hosting many websites, how do I know the information served originated from the intended website and not from another one CloudFlare is hosting? We have been told to look at the browser's address bar to make sure domain belongs to the intended website (e.g., citibank.com and not citibank.another.com). With browser pulling information from CloudFlare, and often over twenty others listed by NoScript and Ghostery on practically every website today, what precautions should I be taking?

pbreit 12y ago

Yeah, it strikes me as worse than no SSL since it creates a false impression of security. I'm surprised they are doing this.

HoochTHX 12y ago

Thank you for pointing out that this is the now-equivalent of the clipper chip. I loved the 90's, I get to wear my parachute pants again, Yay!

itistoday2 12y ago

There's also the small issue whereby DNS MITM completely bypasses all of CloudFlare's protection... And no, DNSSEC won't help here: https://twitter.com/taoeffect/status/516650413987467266 https://twitter.com/taoeffect/status/516650413987467266

cyphunk 12y ago

thinking that the green padlock > red padlock has been a false positive for trust since forever. Any trust other than the red padlock is just a lie. About time we learn that, and understand the entire CA setup trying to convince you of something else is broken.

jingo 12y ago

What is it with Cloudflare marketing posts making page 1 on a daily basis? Is there some business relationship between HN and CF? The title of this one started off as "free" SSL. Now it is "universal SSL". C'mon. As vader1 points out, the level of potential deception here is getting a wee bit high. CF is just a MITM. A website owner lets CF control her DNS and this allows CF to route all requests for her website through CF servers; CF stands between the website and the user. Unless the website owner configures SSL then the user only gets an encrypted connection to CF. That's hardly "universal" SSL.