10 ms·

What is the point? If you need a secure connection then use https, if there is no value securing the connection then use http. Why deprecate a working technolog

by josho 12y ago

What is the point? If you need a secure connection then use https, if there is no value securing the connection then use http. Why deprecate a working technology that continues to have many valid use cases? As an analogy this strikes me as deprecating an array for a linked list because a list has certain features that array's don't. Ie. there is a time and place for both.

mabbo 12y ago
Can you list some of the use cases where you can do something using HTTP that you can't using HTTPS? I had always assumed one was a superset of the other, feature-wise. As long as HTTPS offers all features of HTTP, then the reason to deprecate HTTP is to prevent accidental use of it, and websites which don't know/care from leaving their users vulnerable.
- chc 12y ago
  Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy. In theory, HTTP is a subset of HTTPS. But that subset is much simpler for common tasks. HTTPS requires you to either subject yourself to the complexities of the CA system or be accused constantly of attacking yourself and everyone else who visits.
  - blowski 12y ago
    So why not require HTTPS, and let a thousand "make HTTPS simple" startups bloom? Seems like we're saying "we should just accept insecurity because we can't think of an alternative".
    - chc 12y ago
      > So why not require HTTPS, and let a thousand "make HTTPS simple" startups bloom? Much the same reason we don't all cut our hands off and let a thousand prosthetics startups bloom, I think. > Seems like we're saying "we should just accept insecurity because we can't think of an alternative". It seems more like we're saying "We should unnecessarily break the free Web and just cross our fingers that somebody figures out how to fix it sooner or later."
      - blowski 12y ago
        The analogy doesn't hold. There's absolutely no value in all chopping off our hands, but there _is_ value in requiring all traffic to go over HTTPS. We can deprecate HTTPS for a decade without actually disabling it, and in the unlikely event that we _don't_ figure it out, we can undeprecate it some years later.
        chc 12y ago
        > there _is_ value in requiring all traffic to go over HTTPS. I'm not so sure. It seems to me that there is almost no value in requiring all traffic to go over HTTPS compared to requiring a subset of traffic to go over HTTPS. > We can deprecate HTTPS for a decade without actually disabling it, and in the unlikely event that we _don't_ figure it out, we can undeprecate it some years later. If you want to deprecate it in name only, I guess I can't object since we wouldn't actually be doing anything. I'd figured this would involve trying to hinder HTTP use (similar to how we make self-signed certificates a royal PITA). At any rate, I think you're overestimating the likelihood that we'll figure it out in the short term — particularly given that the proposed happy scenario is to deprecate HTTP and then have thousands of additional for-profit actors trying to put themselves between people and the ability to have websites.
- Dylan16807 12y ago
  You can't do ephemeral hosting with HTTPS unless you use a self-signed cert, and then browsers go absolutely mad.
- dheera 12y ago
  Things you can do with HTTP that you can't do with HTTPS: * Create a website for free (you have to pay for certificates to use HTTPS) * Report sensor data from small embedded devices with extremely limited CPU * Your JS can talk to APIs that don't yet support HTTPS (e.g. NextBus). If your serve your JS over HTTPS, your browser will complain if you try to access a HTTP-only API. * Transfer large files at gigabit speeds on consumer-grade hardware
  - mike_hearn 12y ago
    > Create a website for free (you have to pay for certificates to use HTTPS) No you don't. You can get free certificates. But even if that was true, it's still a misleading argument. You can only make a website for free if you are OK with your website not having a domain name and running it off your personal laptop with electricity paid for by your roommates/parents. For any actual website, there are already a multitude of real costs of which a certificate is just one more. > Report sensor data from small embedded devices with extremely limited CPU If your CPU is really so limited then why are you using HTTP at all? Use a custom binary protocol with or without encryption as appropriate. > Your JS can talk to APIs that don't yet support HTTPS (e.g. NextBus). Then those APIs suck - avoid them and/or ask the providers to get with the program. > Transfer large files at gigabit speeds on consumer-grade hardware AES-NI can decrypt at 3.5 cycles per byte. With modern consumer grade hardware you will not find symmetric streaming crypto to be a serious bottleneck.
    - ciupicri 12y ago
      From where can one get free certificates? Not everyone has modern hardware. My hosting provider doesn't have AES-NI for example.
      - blowski 12y ago
        > From where can one get free certificates? e.g. https://www.startssl.com/?app=1 https://www.startssl.com/?app=1 Also, if HTTPS became a requirement, then demand would increase for free HTTPS certificates in exchange for, say, advertising.
- RexRollman 12y ago
  Not everything needs to be encrypted. It's not that hard to grasp.
  - mike_hearn 12y ago
    Are you sure? Probably Baidu thought the same thing about their Javascript. It's a public file, so why use HTTPS? Then they got turned into the Great Cannon and now they're being described as a weapon of the PRC in major newspapers. It's obvious that governments are systematically weaponising any non-SSLd connections. If you don't use SSL, you're making it easier for them to hack your users and turn your website into a weapon. If you wouldn't let botnets run wild on your servers, you should take the same care to encrypt your website.
    - mariusz79 12y ago
      People may need to run embedded servers on many different devices, and be able to access them. Forcing them to use not the latest version of the browser simply because they can't use it to connect to a device that costs 100k and will not be replaced every year like your average iDevice will not make anything better or safer.
    - dragonwriter 12y ago
      > Are you sure? Yes, I'm sure that the communication between my browser and the test app I'm running on localhost doesn't need to be encrypted. > It's obvious that governments are systematically weaponising any non-SSLd connections. Over the public internet, sure. OTOH, if a government controls a root CA trusted by your target population, TLS doesn't provide any protection at all against them anyway.
      - stouset 12y ago
        Yes, it absolutely does. If they actually use that CA to MITM connections, it is usually detected pretty quickly, and browsers quickly revoke that CA's trust. Even in a scenario where this doesn't happen, it elevates the required attack from a passive eavesdropping attack (which is comparatively simple to conduct en masse, and to analyze data retroactively) to an active attack (which must typically be done in a targeted, real-time fashion).
- abritishguy 12y ago
  How is my router admin page supposed to have an always up to date SSL certificate?
  - blfr 12y ago
    It could be a ten-year self-signed certificate. You accept and remember it the first time you connect (preferably over a cable).
- web007 12y ago
  telnet www.example.com 80 GET / HTTP/1.0
  - giovannibajo1 12y ago
    openssl s_client -connect www.example.com:443 GET /
- bandrami 12y ago
  > Can you list some of the use cases where you can do something using HTTP that you can't using HTTPS? Sure: host a web server anonymously. With HTTPS+PKI (and it's the PKI half of this that people are complaining about) I have to claim an identity.
voidlogic 12y ago
This. Maybe I want all the transparent caches on the Internet to cache my stupid cat picture? How is this not going to destroy the cachability of the internet? Being able to operate transparent caches is important for institutions (Edit: some which may not have access to their users local cert stores). There is many things like blogs, news articles, photo galleries that gain zero value by being encrypted. Encrypting these things is going to require more hardware, more energy usage and more bandwidth and thus again more energy usage.
- Dylan16807 12y ago
  How much of the internet is actually cached? Especially when most of the traffic is video feeds that always get resent.
  - voidlogic 12y ago
    When I worked for an IT consulting firm I saw medium sized institutions (colleges, hospitals, hotels) save huge amounts of bandwidth by implementing transparent HTTP caches. I totally am for securing POSTs, HTML, etc with SSL, but images and CSS, etc really make little sense.
- bifurcation 12y ago
  The use of HTTPS doesn't destroy cacheability, it just requires that one of the legitimate endpoints authorize the cache to be there.
  - voidlogic 12y ago
    Right, it forces the cache to come from the content provider rather than being provided downstream by the client's organization.
    - Dylan16807 12y ago
      If it's inside the organization then they can put in a local cert and run a cache. It only prevents caches that are in the middle and trusted by neither end. I'm okay with that in almost all cases.
mariusz79 12y ago
It will just make it easier to create walled gardens, and charge companies and individuals for certificates. It will also pretty much get rid of privacy, since to get the cert you will need to provide someone with your detailed information. Using self-signed certs will become harder. Yes, it's a good idea to use https _almost_ everywhere, but forcing everyone to use it is a terrible, stupid idea.
- pfg 12y ago
  > It will just make it easier to create walled gardens, and charge companies and individuals for certificates. letsencrypt.org will solve this problem. > It will also pretty much get rid of privacy, since to get the cert you will need to provide someone with your detailed information. That's something that applies to buying/owning a domain as well. Domain-verified certificates require very little private information, and I suspect letsencrypt.org might be able to provide a way to get trusted certificates without giving up privacy. > Using self-signed certs will become harder. How so? The proper way to use self-signed certificates would be to distribute them in a safe way (e.g. deploy them through your Active Directory Domain, provide the fingerprint through a separate channel, etc.) and install them in your trust store. I couldn't find any intended changes to this in their announcement. > Yes, it's a good idea to use https _almost_ everywhere, but forcing everyone to use it is a terrible, stupid idea. I agree that it should be a slow process, and I think that's exactly what they're suggesting. Eventually, when the tooling and processes around SSL/TLS catch up with the new "encrypt everything" mentality, it would probably be no big deal to deprecate almost every use-case of HTTP without SSL/TLS.
  - ciupicri 12y ago
    Let’s Encrypt does not even provide a RPM for Fedora or RHEL yet or at least there's no mention of it on the front page [1]. [1]: https://letsencrypt.org/howitworks/ https://letsencrypt.org/howitworks/
    - TheHippo 12y ago
      There is an open protocol[1] on how to retrieve the certificates, so you can implement a client in a language of your choice, or wait until someone else does it. [1]: https://github.com/letsencrypt/acme-spec https://github.com/letsencrypt/acme-spec
IgorPartola 12y ago
The point is that HTTP to HTTPS is what telnet is to ssh. There are no use cases for HTTP where HTTPS cannot fill that need. With free certificates available now, and more coming, there is no reason to not use HTTPS because of cost. The only valid reason I can see to continue supporting HTTP in some form is for legacy devices (consumer routers, printers, etc.) that don't yet do HTTPS. My 5 year old printer does HTTPS, so we should be able to get rid of these devices soon.
- mariusz79 12y ago
  Did you know that there are still valid use cases for devices that have less 512kb of ram that can be access over http?
  - IgorPartola 12y ago
    I did. I work with these, time permitting. For these devices we have a range of options, including having the central station support plain HTTP, or having a special legacy mode in the browser. These devices should not hold back HTTPS adoption on the web. Edit: I bet there are 1000x more IE6 users, than users of these devices. Shall we support IE6 until every single of it's users upgrade?
    - mariusz79 12y ago
      We're not talking about some JS framework but about an established internet protocol. If I want I can spend time and still support IE6 users, and no browser will prevent me from doing that. That's not the case with this proposal.
  - realusername 12y ago
    I've worked on this kind of device. You can rarely use them directly anyway, you need some kind of reverse-proxy/caching to use them otherwise they will crash if to many people are connecting on it directly. Anyway, these kind of device are rarely connected to the outside world so on the worst case, HTTP is still not a problem on an internal network.

by josho 12y ago

mabbo 12y ago

Can you list some of the use cases where you can do something using HTTP that you can't using HTTPS? I had always assumed one was a superset of the other, feature-wise. As long as HTTPS offers all features of HTTP, then the reason to deprecate HTTP is to prevent accidental use of it, and websites which don't know/care from leaving their users vulnerable.

chc 12y ago
Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy. In theory, HTTP is a subset of HTTPS. But that subset is much simpler for common tasks. HTTPS requires you to either subject yourself to the complexities of the CA system or be accused constantly of attacking yourself and everyone else who visits.
- blowski 12y ago
  So why not require HTTPS, and let a thousand "make HTTPS simple" startups bloom? Seems like we're saying "we should just accept insecurity because we can't think of an alternative".
  - chc 12y ago
    > So why not require HTTPS, and let a thousand "make HTTPS simple" startups bloom? Much the same reason we don't all cut our hands off and let a thousand prosthetics startups bloom, I think. > Seems like we're saying "we should just accept insecurity because we can't think of an alternative". It seems more like we're saying "We should unnecessarily break the free Web and just cross our fingers that somebody figures out how to fix it sooner or later."
    - blowski 12y ago
      The analogy doesn't hold. There's absolutely no value in all chopping off our hands, but there _is_ value in requiring all traffic to go over HTTPS. We can deprecate HTTPS for a decade without actually disabling it, and in the unlikely event that we _don't_ figure it out, we can undeprecate it some years later.
      - chc 12y ago
        > there _is_ value in requiring all traffic to go over HTTPS. I'm not so sure. It seems to me that there is almost no value in requiring all traffic to go over HTTPS compared to requiring a subset of traffic to go over HTTPS. > We can deprecate HTTPS for a decade without actually disabling it, and in the unlikely event that we _don't_ figure it out, we can undeprecate it some years later. If you want to deprecate it in name only, I guess I can't object since we wouldn't actually be doing anything. I'd figured this would involve trying to hinder HTTP use (similar to how we make self-signed certificates a royal PITA). At any rate, I think you're overestimating the likelihood that we'll figure it out in the short term — particularly given that the proposed happy scenario is to deprecate HTTP and then have thousands of additional for-profit actors trying to put themselves between people and the ability to have websites.
Dylan16807 12y ago
You can't do ephemeral hosting with HTTPS unless you use a self-signed cert, and then browsers go absolutely mad.
dheera 12y ago
Things you can do with HTTP that you can't do with HTTPS: * Create a website for free (you have to pay for certificates to use HTTPS) * Report sensor data from small embedded devices with extremely limited CPU * Your JS can talk to APIs that don't yet support HTTPS (e.g. NextBus). If your serve your JS over HTTPS, your browser will complain if you try to access a HTTP-only API. * Transfer large files at gigabit speeds on consumer-grade hardware
- mike_hearn 12y ago
  > Create a website for free (you have to pay for certificates to use HTTPS) No you don't. You can get free certificates. But even if that was true, it's still a misleading argument. You can only make a website for free if you are OK with your website not having a domain name and running it off your personal laptop with electricity paid for by your roommates/parents. For any actual website, there are already a multitude of real costs of which a certificate is just one more. > Report sensor data from small embedded devices with extremely limited CPU If your CPU is really so limited then why are you using HTTP at all? Use a custom binary protocol with or without encryption as appropriate. > Your JS can talk to APIs that don't yet support HTTPS (e.g. NextBus). Then those APIs suck - avoid them and/or ask the providers to get with the program. > Transfer large files at gigabit speeds on consumer-grade hardware AES-NI can decrypt at 3.5 cycles per byte. With modern consumer grade hardware you will not find symmetric streaming crypto to be a serious bottleneck.
  - ciupicri 12y ago
    From where can one get free certificates? Not everyone has modern hardware. My hosting provider doesn't have AES-NI for example.
    - blowski 12y ago
      > From where can one get free certificates? e.g. https://www.startssl.com/?app=1 https://www.startssl.com/?app=1 Also, if HTTPS became a requirement, then demand would increase for free HTTPS certificates in exchange for, say, advertising.
RexRollman 12y ago
Not everything needs to be encrypted. It's not that hard to grasp.
- mike_hearn 12y ago
  Are you sure? Probably Baidu thought the same thing about their Javascript. It's a public file, so why use HTTPS? Then they got turned into the Great Cannon and now they're being described as a weapon of the PRC in major newspapers. It's obvious that governments are systematically weaponising any non-SSLd connections. If you don't use SSL, you're making it easier for them to hack your users and turn your website into a weapon. If you wouldn't let botnets run wild on your servers, you should take the same care to encrypt your website.
  - mariusz79 12y ago
    People may need to run embedded servers on many different devices, and be able to access them. Forcing them to use not the latest version of the browser simply because they can't use it to connect to a device that costs 100k and will not be replaced every year like your average iDevice will not make anything better or safer.
  - dragonwriter 12y ago
    > Are you sure? Yes, I'm sure that the communication between my browser and the test app I'm running on localhost doesn't need to be encrypted. > It's obvious that governments are systematically weaponising any non-SSLd connections. Over the public internet, sure. OTOH, if a government controls a root CA trusted by your target population, TLS doesn't provide any protection at all against them anyway.
    - stouset 12y ago
      Yes, it absolutely does. If they actually use that CA to MITM connections, it is usually detected pretty quickly, and browsers quickly revoke that CA's trust. Even in a scenario where this doesn't happen, it elevates the required attack from a passive eavesdropping attack (which is comparatively simple to conduct en masse, and to analyze data retroactively) to an active attack (which must typically be done in a targeted, real-time fashion).
abritishguy 12y ago
How is my router admin page supposed to have an always up to date SSL certificate?
- blfr 12y ago
  It could be a ten-year self-signed certificate. You accept and remember it the first time you connect (preferably over a cable).
web007 12y ago
telnet www.example.com 80 GET / HTTP/1.0
- giovannibajo1 12y ago
  openssl s_client -connect www.example.com:443 GET /
bandrami 12y ago
> Can you list some of the use cases where you can do something using HTTP that you can't using HTTPS? Sure: host a web server anonymously. With HTTPS+PKI (and it's the PKI half of this that people are complaining about) I have to claim an identity.

voidlogic 12y ago

This. Maybe I want all the transparent caches on the Internet to cache my stupid cat picture? How is this not going to destroy the cachability of the internet? Being able to operate transparent caches is important for institutions (Edit: some which may not have access to their users local cert stores). There is many things like blogs, news articles, photo galleries that gain zero value by being encrypted. Encrypting these things is going to require more hardware, more energy usage and more bandwidth and thus again more energy usage.

Dylan16807 12y ago
How much of the internet is actually cached? Especially when most of the traffic is video feeds that always get resent.
- voidlogic 12y ago
  When I worked for an IT consulting firm I saw medium sized institutions (colleges, hospitals, hotels) save huge amounts of bandwidth by implementing transparent HTTP caches. I totally am for securing POSTs, HTML, etc with SSL, but images and CSS, etc really make little sense.
bifurcation 12y ago
The use of HTTPS doesn't destroy cacheability, it just requires that one of the legitimate endpoints authorize the cache to be there.
- voidlogic 12y ago
  Right, it forces the cache to come from the content provider rather than being provided downstream by the client's organization.
  - Dylan16807 12y ago
    If it's inside the organization then they can put in a local cert and run a cache. It only prevents caches that are in the middle and trusted by neither end. I'm okay with that in almost all cases.

mariusz79 12y ago

It will just make it easier to create walled gardens, and charge companies and individuals for certificates. It will also pretty much get rid of privacy, since to get the cert you will need to provide someone with your detailed information. Using self-signed certs will become harder. Yes, it's a good idea to use https _almost_ everywhere, but forcing everyone to use it is a terrible, stupid idea.

pfg 12y ago
> It will just make it easier to create walled gardens, and charge companies and individuals for certificates. letsencrypt.org will solve this problem. > It will also pretty much get rid of privacy, since to get the cert you will need to provide someone with your detailed information. That's something that applies to buying/owning a domain as well. Domain-verified certificates require very little private information, and I suspect letsencrypt.org might be able to provide a way to get trusted certificates without giving up privacy. > Using self-signed certs will become harder. How so? The proper way to use self-signed certificates would be to distribute them in a safe way (e.g. deploy them through your Active Directory Domain, provide the fingerprint through a separate channel, etc.) and install them in your trust store. I couldn't find any intended changes to this in their announcement. > Yes, it's a good idea to use https _almost_ everywhere, but forcing everyone to use it is a terrible, stupid idea. I agree that it should be a slow process, and I think that's exactly what they're suggesting. Eventually, when the tooling and processes around SSL/TLS catch up with the new "encrypt everything" mentality, it would probably be no big deal to deprecate almost every use-case of HTTP without SSL/TLS.
- ciupicri 12y ago
  Let’s Encrypt does not even provide a RPM for Fedora or RHEL yet or at least there's no mention of it on the front page [1]. [1]: https://letsencrypt.org/howitworks/ https://letsencrypt.org/howitworks/
  - TheHippo 12y ago
    There is an open protocol[1] on how to retrieve the certificates, so you can implement a client in a language of your choice, or wait until someone else does it. [1]: https://github.com/letsencrypt/acme-spec https://github.com/letsencrypt/acme-spec

IgorPartola 12y ago

The point is that HTTP to HTTPS is what telnet is to ssh. There are no use cases for HTTP where HTTPS cannot fill that need. With free certificates available now, and more coming, there is no reason to not use HTTPS because of cost. The only valid reason I can see to continue supporting HTTP in some form is for legacy devices (consumer routers, printers, etc.) that don't yet do HTTPS. My 5 year old printer does HTTPS, so we should be able to get rid of these devices soon.

mariusz79 12y ago
Did you know that there are still valid use cases for devices that have less 512kb of ram that can be access over http?
- IgorPartola 12y ago
  I did. I work with these, time permitting. For these devices we have a range of options, including having the central station support plain HTTP, or having a special legacy mode in the browser. These devices should not hold back HTTPS adoption on the web. Edit: I bet there are 1000x more IE6 users, than users of these devices. Shall we support IE6 until every single of it's users upgrade?
  - mariusz79 12y ago
    We're not talking about some JS framework but about an established internet protocol. If I want I can spend time and still support IE6 users, and no browser will prevent me from doing that. That's not the case with this proposal.
- realusername 12y ago
  I've worked on this kind of device. You can rarely use them directly anyway, you need some kind of reverse-proxy/caching to use them otherwise they will crash if to many people are connecting on it directly. Anyway, these kind of device are rarely connected to the outside world so on the worst case, HTTP is still not a problem on an internal network.