4 ms·

> 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 alway

by 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.
    - X-Istence 12y ago
      Except that didn't really make much of a difference in the case of heartbleed. The information was still in memory decrypted, before it was encrypted by the front end, so an attacker could get the decrypted content, which may include users usernames/passwords and all that fun stuff.
      - peterwwillis 12y ago
        Yes, you could get the data going to and from the clients, which is most of the important user data. The big problem is when your SSL/http/whatever is being terminated on the app server itself, exposing things like database access, SANs, etc.
        X-Istence 12y ago
        No, it wouldn't expose those things. It would only expose things that OpenSSL itself had allocated/deallocated in that single process due to the way it was saving memory allocations for later re-use...
        peterwwillis 12y ago
        You're right. I meant in the case of a code execution exploit in the openssl layer, those things would be exposed if they were all on the same host/network.
- vtlynch 12y ago
  I agree that this false sense of security is troubling. Many inexperienced site owners will think setting up Flexible SSL with Cloudflare is all they need to do. And it is unclear if the enduser has any way to see if the site they are connecting to is using Flexible or Full SSL. However, in the announcement Cloudflare did say: " Later today we'll be publishing a blog with instructions on how to do that at no cost. Once you've installed a certificate on your web server, you can enable the Full or Strict SSL modes which encrypt origin traffic and provide a higher level of security." So this gives me a lot of hope that end to end encryption will proliferate. What I dont understand is how they will be doing this at no cost. It looks like the certificates being issued automatically are to "xxxxxx.cloudflare.com", and not to the origin domain. Perhaps to get Full SSL you will have to enroll via Cloudflare's website to get a separate SSL that is for your site. This could then be verified the traditional way for Domain Validation certs. Globalsign and Comodo seem to be the two providers for this.
  - notdonspaulding 12y ago
    > What I dont understand is how they will be doing this at no cost. The same way that they're doing the first-mile encryption at no cost, by partnering with a CA that will sign certificates for free. StartSSL (http://www.startssl.com/ http://www.startssl.com/) has been signing certs at no cost for years. The marginal cost for a CA to sign an additional cert is negligible, particularly when there's no customer support involved (i.e. Cloudflare customers won't be calling Comodo or Globalsign's support numbers). > It looks like the certificates being issued automatically are to "xxxxxx.cloudflare.com", and not to the origin domain. Not having one in front of me, I can't say for sure, but they have to sign the cert for the origin domain or the browser wouldn't give you a padlock when you went to the origin domain. Certs may contain extended Subject Alternative Name fields that include other hostnames for which the cert should be considered valid. I'm guessing they're using something like this to add the origin domain alongside the xxxx.cloudflare.com domains. This is traditionally how you can have a single cert which works for both the root domain as well as the "www" version of the same (i.e. yourdomain.com and www.yourdomain.com use the exact same cert).
    - vtlynch 12y ago
scintill76 12y ago
The centralization argument still has merit. If this catches on big time, there's only one company to coerce/compromise, to backdoor a bunch of services at once. Arguably the CA/ISP structure is like this already, but this may be worse.
- cbg0 12y ago
  Hasn't this been the case with people using SSL on Amazon's ELB?
  - DrJosiah 12y ago
    Yes, Amazon's ELB has always been a potential attack target for people who want to get to unencrypted data.
- MCRed 12y ago
  Totally true, but on the other hand, the first mile will be encrypted for a lot more connections: "Yesterday, there were about 2 million sites active on the Internet that supported encrypted connections. By the end of the day today, we'll have doubled that." That's kind of spectacular. I think the first mile is one of the key places where data gets stolen. OF course the final millimeters-on the server- is another.
  - sarciszewski 12y ago
    Yes, but this (free SSL everywhere) can (and should!) become the bandwagon that all other service/hosting providers and CAs should adopt.
mattmanser 12y ago
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.
- jgrahamc 12y ago
  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).
- sah2ed 12y ago
  > Gordon Brown brokered the deal with jgrahamc to sell out personal privacy for a pardon for Turing (joke!) For some background on this, see http://en.wikipedia.org/wiki/Alan_Turing#Government_apology_and_pardon http://en.wikipedia.org/wiki/Alan_Turing#Government_apology_...
imanaccount247 12y ago
>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? Or online purchasing pages that just sent plain text emails containing the credit card info to sales@domain? Today is still that age unfortunately, I just ran into one the other day.
- pbreit 12y ago
  I'd like to think we've made some progress since then.

by buro9 12y ago

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.
  - X-Istence 12y ago
    Except that didn't really make much of a difference in the case of heartbleed. The information was still in memory decrypted, before it was encrypted by the front end, so an attacker could get the decrypted content, which may include users usernames/passwords and all that fun stuff.
    - peterwwillis 12y ago
      Yes, you could get the data going to and from the clients, which is most of the important user data. The big problem is when your SSL/http/whatever is being terminated on the app server itself, exposing things like database access, SANs, etc.
      - X-Istence 12y ago
        No, it wouldn't expose those things. It would only expose things that OpenSSL itself had allocated/deallocated in that single process due to the way it was saving memory allocations for later re-use...
        peterwwillis 12y ago
        You're right. I meant in the case of a code execution exploit in the openssl layer, those things would be exposed if they were all on the same host/network.
vtlynch 12y ago
I agree that this false sense of security is troubling. Many inexperienced site owners will think setting up Flexible SSL with Cloudflare is all they need to do. And it is unclear if the enduser has any way to see if the site they are connecting to is using Flexible or Full SSL. However, in the announcement Cloudflare did say: " Later today we'll be publishing a blog with instructions on how to do that at no cost. Once you've installed a certificate on your web server, you can enable the Full or Strict SSL modes which encrypt origin traffic and provide a higher level of security." So this gives me a lot of hope that end to end encryption will proliferate. What I dont understand is how they will be doing this at no cost. It looks like the certificates being issued automatically are to "xxxxxx.cloudflare.com", and not to the origin domain. Perhaps to get Full SSL you will have to enroll via Cloudflare's website to get a separate SSL that is for your site. This could then be verified the traditional way for Domain Validation certs. Globalsign and Comodo seem to be the two providers for this.
- notdonspaulding 12y ago
  > What I dont understand is how they will be doing this at no cost. The same way that they're doing the first-mile encryption at no cost, by partnering with a CA that will sign certificates for free. StartSSL (http://www.startssl.com/ http://www.startssl.com/) has been signing certs at no cost for years. The marginal cost for a CA to sign an additional cert is negligible, particularly when there's no customer support involved (i.e. Cloudflare customers won't be calling Comodo or Globalsign's support numbers). > It looks like the certificates being issued automatically are to "xxxxxx.cloudflare.com", and not to the origin domain. Not having one in front of me, I can't say for sure, but they have to sign the cert for the origin domain or the browser wouldn't give you a padlock when you went to the origin domain. Certs may contain extended Subject Alternative Name fields that include other hostnames for which the cert should be considered valid. I'm guessing they're using something like this to add the origin domain alongside the xxxx.cloudflare.com domains. This is traditionally how you can have a single cert which works for both the root domain as well as the "www" version of the same (i.e. yourdomain.com and www.yourdomain.com use the exact same cert).
  - vtlynch 12y ago

scintill76 12y ago

The centralization argument still has merit. If this catches on big time, there's only one company to coerce/compromise, to backdoor a bunch of services at once. Arguably the CA/ISP structure is like this already, but this may be worse.

cbg0 12y ago
Hasn't this been the case with people using SSL on Amazon's ELB?
- DrJosiah 12y ago
  Yes, Amazon's ELB has always been a potential attack target for people who want to get to unencrypted data.
MCRed 12y ago
Totally true, but on the other hand, the first mile will be encrypted for a lot more connections: "Yesterday, there were about 2 million sites active on the Internet that supported encrypted connections. By the end of the day today, we'll have doubled that." That's kind of spectacular. I think the first mile is one of the key places where data gets stolen. OF course the final millimeters-on the server- is another.
- sarciszewski 12y ago
  Yes, but this (free SSL everywhere) can (and should!) become the bandwagon that all other service/hosting providers and CAs should adopt.

mattmanser 12y ago

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.

jgrahamc 12y ago
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).
sah2ed 12y ago
> Gordon Brown brokered the deal with jgrahamc to sell out personal privacy for a pardon for Turing (joke!) For some background on this, see http://en.wikipedia.org/wiki/Alan_Turing#Government_apology_and_pardon http://en.wikipedia.org/wiki/Alan_Turing#Government_apology_...

imanaccount247 12y ago

>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? Or online purchasing pages that just sent plain text emails containing the credit card info to sales@domain? Today is still that age unfortunately, I just ran into one the other day.

pbreit 12y ago
I'd like to think we've made some progress since then.