5 ms·

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 s

by 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

by vader1 12y ago

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