4 ms·

If a user thinks the presence of "https" means it's safe to enter credit card details or medical information, that's already a huge problem. Yes, "https" should

by eridius 10y ago

If a user thinks the presence of "https" means it's safe to enter credit card details or medical information, that's already a huge problem. Yes, "https" should be a prerequisite to entering sensitive information, but that's only part of it; the other part is whether you actually trust the server you're sending that information to. The server could be using ironclad encryption across the whole connection, but that doesn't mean they'll still handle your data safely. Any site that wants sensitive information like this has to do many things to ensure it's secure, and making sure they have a secure connection is only one of those things. If you trust that the server operator has done everything else necessary to keep your credit card details safe, then you should also trust that they're not using Flexible SSL. Edit: Dear downvoters, can you please explain why you disagree? What I wrote really shouldn't be controversial in the least, so I don't understand the drive-by downvotes.

WillyOnWheels 10y ago
Can you think of an existing system (let's go with websites) that meets your standards?
- vertex-four 10y ago
  There isn't an automated system that can tell you whether it's safe to give data to a website, just like there's no automated system which can tell you a given vendor/service provider in general is reputable. All you've got is regulations, human-based reputation ranking, and public shaming.
  - eridius 10y ago
    Exactly this. Anytime you give sensitive information to another party you have to evaluate the risk. Having an insecure connection to that party is obviously risky, but that doesn't mean that having a secure connection means there's no risk. Companies that accept sensitive information while using Flexible SSL are probably mishandling your data in other ways too.
  - lmm 10y ago
    > All you've got is regulations, human-based reputation ranking, and public shaming. Indeed - so we should be applying all of those against CloudFlare, and any other organization that offers or uses a "Flexible SSL"-like product, as firmly as we can.
    - eridius 10y ago
      You seem to be missing the point. If the company is handling sensitive data, such as credit card information or medical information, there's already regulations to handle that. There's literally no point in trying to add regulations around Flexible SSL specifically, since the usage of Flexible SSL likely already contravenes the regulations for that sensitive data and therefore companies handling that data shouldn't be using it. If the company isn't handling sensitive data, then again there's no point in adding regulations around Flexible SSL, because what possible benefit would that serve? Flexible SSL is simply one tool that websites can use. It's intended to be used by sites that would otherwise just be using http:// http://. Sites that do protect more sensitive information certainly could use it, but that would be a bad decision on their part. And we don't need regulations around it specifically, because there's also a million other bad decisions that company could make that would expose that data, and there's really nothing special about Flexible SSL that makes it in particular need of regulation.
      - lmm 10y ago
        Some information might be sensitive for the end user, but not legally protected. Even something as simple as their name or pseudonym can be serious for some people. I think serving a site over https:// https:// amounts to advertising that information sent to/from that site will not be sent unencrypted over the public internet, and users will use that when deciding what things are or aren't safe to enter into that site. Surely there are regulations that already apply to that? And in any case regulations are only one of the options you mentioned; we should be applying a lot more shame to CloudFlare and anyone who uses "Flexible SSL".
problems 10y ago
It's always fairly safe to enter credit card details, you can chargeback that shit, type it wherever you feel like and just claim ignorance when it goes poorly. That's basically the whole point of using a credit card and not your bank account where you're liable for at least some of the money taken. No company is likely to handle your payment details completely securely. You're relying on it working out on sheer luck most of the time and chargebacks on the rest.
- eridius 10y ago
  This is why PCI Compliance exists. Part of the requirements of PCI are that you must encrypt transmission of cardholder data across the network. So companies that accept credit card details while using Flexible SSL are presumably violating the PCI DSS. Companies handling small volumes use self-assessment, but larger companies are actually audited annually for this stuff.
  - problems 10y ago
    Nice, good to know the credit card companies are doing their best to mitigate their liability due to issues like this too.
  - brennen 10y ago
    It's unfortunate that the actual content of PCI is an incoherent and actively counterproductive mess.
    - toss1941 10y ago
      A big part of that incoherence comes the fact that a lot of their guidelines are too broad. For instance, one requirement says all activity performed by an admin must be logged. How many financial companies do this today on every server/device in their PCI environments? My guess is nearly zero, because it's very difficult to find someone who knows what is needed and how to do it correctly, but very easy to avoid even being discovered as being out of compliance. Then there's the whole lone-auditor thing where a very large data-center or three are being audited by a single person over the course of two weeks, or less. That person is absolutely bombarded with information about an environment that is foreign to them. The end result I think is that so far companies have had it very easy to get by. They only have to pay for a week, or two at most, and whatever limited findings they get are fixed and they move on to the next year. If companies actually had to live with a slower and more methodical audit, there would be many more findings and a lot more money spent, both on the auditing process and the resulting cleanup. The upshot is this would drive actual innovation in the space of having proper logging, file integrity, encryption, access controls, etc. The whole audit industry is just.. icky. It needs a massive overhaul and the financials need to be forced to pay for it.
lmm 10y ago
> Any site that wants sensitive information like this has to do many things to ensure it's secure, and making sure they have a secure connection is only one of those things. If you trust that the server operator has done everything else necessary to keep your credit card details safe, then you should also trust that they're not using Flexible SSL. This is true, but conversely there is no legitimate use case for Flexible SSL. Having a datastore like Redis or MongoDB that by default listens insecurely on any address is almost as bad, and such things often compromise the security of a site if it e.g. sends your data across the internet to one of those, but at least there's a more-or-less legitimate use case for that default if it's used on a secured network - it's at least possible that someone using that default isn't deceiving their users. Whereas anyone using Flexible SSL is necessarily deceiving their users (I mean you can argue users might genuinely think "I don't trust my local cafe operator but I do trust the completely public, unsecured internet", but I don't think that's a coherent position for anyone to take).
- eridius 10y ago
  The use-case for Flexible SSL is when you're not handling sensitive data but still want to offer https:// https:// because really every website should offer it. In fact the blog post that introduced Flexible SSL (https://blog.cloudflare.com/easiest-ssl-ever-now-included-automatically-w/ https://blog.cloudflare.com/easiest-ssl-ever-now-included-au...) said basically that. The whole point of the feature was it was a simple one-click way to go from http:// http:// to https:// https://. That said, now that we have Let's Encrypt, and as more tooling gains support for automatically handling that, the value of Flexible SSL is going down, and I do hope they retire it eventually.
  - lmm 10y ago
    > The use-case for Flexible SSL is when you're not handling sensitive data but still want to offer https:// https:// because really every website should offer it. That's putting the cart before the horse. "Every website should offer" authentication and confidentiality, that's why we want every website to use HTTPS; having a URL that starts with https:// https:// is not a goal in itself.

by eridius 10y ago

WillyOnWheels 10y ago

Can you think of an existing system (let's go with websites) that meets your standards?

vertex-four 10y ago
There isn't an automated system that can tell you whether it's safe to give data to a website, just like there's no automated system which can tell you a given vendor/service provider in general is reputable. All you've got is regulations, human-based reputation ranking, and public shaming.
- eridius 10y ago
  Exactly this. Anytime you give sensitive information to another party you have to evaluate the risk. Having an insecure connection to that party is obviously risky, but that doesn't mean that having a secure connection means there's no risk. Companies that accept sensitive information while using Flexible SSL are probably mishandling your data in other ways too.
- lmm 10y ago
  > All you've got is regulations, human-based reputation ranking, and public shaming. Indeed - so we should be applying all of those against CloudFlare, and any other organization that offers or uses a "Flexible SSL"-like product, as firmly as we can.
  - eridius 10y ago
    You seem to be missing the point. If the company is handling sensitive data, such as credit card information or medical information, there's already regulations to handle that. There's literally no point in trying to add regulations around Flexible SSL specifically, since the usage of Flexible SSL likely already contravenes the regulations for that sensitive data and therefore companies handling that data shouldn't be using it. If the company isn't handling sensitive data, then again there's no point in adding regulations around Flexible SSL, because what possible benefit would that serve? Flexible SSL is simply one tool that websites can use. It's intended to be used by sites that would otherwise just be using http:// http://. Sites that do protect more sensitive information certainly could use it, but that would be a bad decision on their part. And we don't need regulations around it specifically, because there's also a million other bad decisions that company could make that would expose that data, and there's really nothing special about Flexible SSL that makes it in particular need of regulation.
    - lmm 10y ago
      Some information might be sensitive for the end user, but not legally protected. Even something as simple as their name or pseudonym can be serious for some people. I think serving a site over https:// https:// amounts to advertising that information sent to/from that site will not be sent unencrypted over the public internet, and users will use that when deciding what things are or aren't safe to enter into that site. Surely there are regulations that already apply to that? And in any case regulations are only one of the options you mentioned; we should be applying a lot more shame to CloudFlare and anyone who uses "Flexible SSL".

problems 10y ago

It's always fairly safe to enter credit card details, you can chargeback that shit, type it wherever you feel like and just claim ignorance when it goes poorly. That's basically the whole point of using a credit card and not your bank account where you're liable for at least some of the money taken. No company is likely to handle your payment details completely securely. You're relying on it working out on sheer luck most of the time and chargebacks on the rest.

eridius 10y ago
This is why PCI Compliance exists. Part of the requirements of PCI are that you must encrypt transmission of cardholder data across the network. So companies that accept credit card details while using Flexible SSL are presumably violating the PCI DSS. Companies handling small volumes use self-assessment, but larger companies are actually audited annually for this stuff.
- problems 10y ago
  Nice, good to know the credit card companies are doing their best to mitigate their liability due to issues like this too.
- brennen 10y ago
  It's unfortunate that the actual content of PCI is an incoherent and actively counterproductive mess.
  - toss1941 10y ago
    A big part of that incoherence comes the fact that a lot of their guidelines are too broad. For instance, one requirement says all activity performed by an admin must be logged. How many financial companies do this today on every server/device in their PCI environments? My guess is nearly zero, because it's very difficult to find someone who knows what is needed and how to do it correctly, but very easy to avoid even being discovered as being out of compliance. Then there's the whole lone-auditor thing where a very large data-center or three are being audited by a single person over the course of two weeks, or less. That person is absolutely bombarded with information about an environment that is foreign to them. The end result I think is that so far companies have had it very easy to get by. They only have to pay for a week, or two at most, and whatever limited findings they get are fixed and they move on to the next year. If companies actually had to live with a slower and more methodical audit, there would be many more findings and a lot more money spent, both on the auditing process and the resulting cleanup. The upshot is this would drive actual innovation in the space of having proper logging, file integrity, encryption, access controls, etc. The whole audit industry is just.. icky. It needs a massive overhaul and the financials need to be forced to pay for it.

lmm 10y ago

> Any site that wants sensitive information like this has to do many things to ensure it's secure, and making sure they have a secure connection is only one of those things. If you trust that the server operator has done everything else necessary to keep your credit card details safe, then you should also trust that they're not using Flexible SSL. This is true, but conversely there is no legitimate use case for Flexible SSL. Having a datastore like Redis or MongoDB that by default listens insecurely on any address is almost as bad, and such things often compromise the security of a site if it e.g. sends your data across the internet to one of those, but at least there's a more-or-less legitimate use case for that default if it's used on a secured network - it's at least possible that someone using that default isn't deceiving their users. Whereas anyone using Flexible SSL is necessarily deceiving their users (I mean you can argue users might genuinely think "I don't trust my local cafe operator but I do trust the completely public, unsecured internet", but I don't think that's a coherent position for anyone to take).

eridius 10y ago
The use-case for Flexible SSL is when you're not handling sensitive data but still want to offer https:// https:// because really every website should offer it. In fact the blog post that introduced Flexible SSL (https://blog.cloudflare.com/easiest-ssl-ever-now-included-automatically-w/ https://blog.cloudflare.com/easiest-ssl-ever-now-included-au...) said basically that. The whole point of the feature was it was a simple one-click way to go from http:// http:// to https:// https://. That said, now that we have Let's Encrypt, and as more tooling gains support for automatically handling that, the value of Flexible SSL is going down, and I do hope they retire it eventually.
- lmm 10y ago
  > The use-case for Flexible SSL is when you're not handling sensitive data but still want to offer https:// https:// because really every website should offer it. That's putting the cart before the horse. "Every website should offer" authentication and confidentiality, that's why we want every website to use HTTPS; having a URL that starts with https:// https:// is not a goal in itself.