6 ms·

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 no

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.
  - mariusz79 12y ago
    I work with them every day, and the point of having HTTP server is not to allow many people to connect to them but one person, or script to do it once in a blue moon without a need to install any software. If HTTP is removed from browsers, this will simply not be possible anymore
    - IgorPartola 12y ago
      Look, you are clearly a minority (developer who works with HTTP-enabled limited RAM devices). Why should we hold back the progress of the web to cater to your very specific use case? Why should my grandmother be subjected to phishing attacks and injected ads because your situation would be slightly inconvenienced by dropping plain HTTP from popular browsers? Also, you are a developer. I am sure we can figure out some way for developers to re-enable plain HTTP in some hidden settings. That way people like you and me can continue to do what we do, while the rest of the web users are enjoying the benefits of being more secure by default.
      - mariusz79 12y ago
        Why should my embedded system have to support unnecessary functionality? Just so your grandmother is safer from phishing attack? I'm a developer, but my clients are not.
        IgorPartola 12y ago
        Nobody is asking your embedded systems to support unnecessary functionality. At worst, you are going to have to one time go to about:config and change enable_plain_http from 0 to 1. Then for you life goes on as before. Is that too much to ask for much greater security for everyone involved?
        mariusz79 12y ago
        Just like I can disable javascript? Oh wait, I can't! Does having ftp support in firefox affect anyone's security? Getting rid of HTTP will in best case make people think that they are more secured, that's all. Most of the malware that is active today propagates not because HTTP is unsecure, but because we made the web an Advertisement Delivery System. Malware now attacks browsers, through Flash, Javascript and Java.. first fix this before you start working on getting rid of an established protocol.
_delirium 12y ago
The analogy doesn't seem close to me. The problem with telnet is that it was used for connections intended to be authenticated, but they were authenticated very poorly, by sending a cleartext login/password. That is easy to compromise, so it needed to be replaced with a better authentication method. If telnet were normally used without any authentication at all, e.g. only for guest-type access to BBSs, then the case to replace it would have been much weaker. The analogous case might be if you're doing plaintext password authentication over HTTP. I agree that for that use-case you should switch to HTTPS.
- IgorPartola 12y ago
  I wholeheartedly disagree. Any content should be delivered over an encrypted channel because any content site can be used to launch an attack on the user os site owner if the data in transit can be tempered with. Passwords and session keys are just a small subset (though admittedly a valuable one) of the stuff you may go after. For example, do you want the FBI putting you on a tracking list because you googled something they consider suspicious just out of curiosity? Do you want a rival of yours messing with how your resume you publish on your personal site is presented to Google or potential employees. Do you want to read man pages that tell you how to run commands over an unauthenticated connection? Do you want Pillsbury to double the amount of their ingredients you need for a chicken pot pie? There is almost no use case where content should remain unprotected. Apple.com is a great example of this. It's served over plain HTTP, and likes to http://store.apple.com http://store.apple.com. Can I intercept that link and send you to http[s]?://store.appl.com or http[s]://store.apple.con? I can then grab your credit card. Heck, I could process your order so you won't even know something went wrong. Or how would it look if suddenly people started getting a goatse instead of the latest video of Jony Ivy tilting his head to the side?
  - josho 12y ago
    Then your issue is with sites that host content on http, and the solution is to address the content hosts—not deprecate a protocol. Besides, If you can MITM http then you can probably do the same for DNS, so https doesn't really solve the attack vector you mention. Finally, Read this thread for use cases for http. They may not apply for you, but are sufficient that I think we can keep http around for awhile longer.

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.
- mariusz79 12y ago
  I work with them every day, and the point of having HTTP server is not to allow many people to connect to them but one person, or script to do it once in a blue moon without a need to install any software. If HTTP is removed from browsers, this will simply not be possible anymore
  - IgorPartola 12y ago
    Look, you are clearly a minority (developer who works with HTTP-enabled limited RAM devices). Why should we hold back the progress of the web to cater to your very specific use case? Why should my grandmother be subjected to phishing attacks and injected ads because your situation would be slightly inconvenienced by dropping plain HTTP from popular browsers? Also, you are a developer. I am sure we can figure out some way for developers to re-enable plain HTTP in some hidden settings. That way people like you and me can continue to do what we do, while the rest of the web users are enjoying the benefits of being more secure by default.
    - mariusz79 12y ago
      Why should my embedded system have to support unnecessary functionality? Just so your grandmother is safer from phishing attack? I'm a developer, but my clients are not.
      - IgorPartola 12y ago
        Nobody is asking your embedded systems to support unnecessary functionality. At worst, you are going to have to one time go to about:config and change enable_plain_http from 0 to 1. Then for you life goes on as before. Is that too much to ask for much greater security for everyone involved?
        mariusz79 12y ago
        Just like I can disable javascript? Oh wait, I can't! Does having ftp support in firefox affect anyone's security? Getting rid of HTTP will in best case make people think that they are more secured, that's all. Most of the malware that is active today propagates not because HTTP is unsecure, but because we made the web an Advertisement Delivery System. Malware now attacks browsers, through Flash, Javascript and Java.. first fix this before you start working on getting rid of an established protocol.

_delirium 12y ago

The analogy doesn't seem close to me. The problem with telnet is that it was used for connections intended to be authenticated, but they were authenticated very poorly, by sending a cleartext login/password. That is easy to compromise, so it needed to be replaced with a better authentication method. If telnet were normally used without any authentication at all, e.g. only for guest-type access to BBSs, then the case to replace it would have been much weaker. The analogous case might be if you're doing plaintext password authentication over HTTP. I agree that for that use-case you should switch to HTTPS.

IgorPartola 12y ago
I wholeheartedly disagree. Any content should be delivered over an encrypted channel because any content site can be used to launch an attack on the user os site owner if the data in transit can be tempered with. Passwords and session keys are just a small subset (though admittedly a valuable one) of the stuff you may go after. For example, do you want the FBI putting you on a tracking list because you googled something they consider suspicious just out of curiosity? Do you want a rival of yours messing with how your resume you publish on your personal site is presented to Google or potential employees. Do you want to read man pages that tell you how to run commands over an unauthenticated connection? Do you want Pillsbury to double the amount of their ingredients you need for a chicken pot pie? There is almost no use case where content should remain unprotected. Apple.com is a great example of this. It's served over plain HTTP, and likes to http://store.apple.com http://store.apple.com. Can I intercept that link and send you to http[s]?://store.appl.com or http[s]://store.apple.con? I can then grab your credit card. Heck, I could process your order so you won't even know something went wrong. Or how would it look if suddenly people started getting a goatse instead of the latest video of Jony Ivy tilting his head to the side?
- josho 12y ago
  Then your issue is with sites that host content on http, and the solution is to address the content hosts—not deprecate a protocol. Besides, If you can MITM http then you can probably do the same for DNS, so https doesn't really solve the attack vector you mention. Finally, Read this thread for use cases for http. They may not apply for you, but are sufficient that I think we can keep http around for awhile longer.