10 ms·

> without recourse Doesn't the post say they'll fall back to http if the https attempt fails? > For sites that don’t yet support HTTPS, Chrome will fall back

by alecbz 6y ago

> without recourse Doesn't the post say they'll fall back to http if the https attempt fails? > For sites that don’t yet support HTTPS, Chrome will fall back to HTTP when the HTTPS attempt fails. The only change here seems like it's that, from the user's perspective, initial connections to http-only sites will be a bit slower (vs. the opposite which used to be true: initial connections to https-only sites were slower).

j1elo 6y ago
I'm talking about the general state of HTTPS implantation. If you develop an offline device which offers a web UI, and it happens to use any feature that is deemed to require a Secure Context, you're out of luck. WebRTC is such a feature, but there are lots more, and they can change from one version of the browser to the next one. The players who are pushing so hard to shove HTTPS down our throats are simply closing their eyes and ignoring the use cases that are not interesting to them. The mandatory renewal timing is a good example: it used to be more than 1 year, now it is 90 days (and some would like to reduce it to mere weeks!) Absolutely great for the grand scheme of things and global security of the Internet, but dismaying for lots of other use cases.
- dcow 6y ago
  Yeah, I think we need a browser that isn't developed by companies with vested interests in having all your traffic go to them...
  - spurgu 6y ago
    Then again I think Google would do just fine even if Firefox was the only browser.
- Wowfunhappy 6y ago
  I don't actually see the problem. If you're on a local network, there's no practical way to deal with certificates, so use http. Chrome will fall back. Problem solved. If http support ever gets truly removed, I will be very upset. But that hasn't happened, so what is there to complain about?
  - simias 6y ago
    HTTP is effectively considered legacy by the big web actors these days. More and more APIs are HTTPS-only (often for good reasons) and the "insecure" warnings you get from using HTTP become more intrusive every year. The trajectory is pretty clear, the long term plan is to phase out HTTP completely. And I'm not against it, but I need a solution for LAN devices, and it doesn't exist at the moment because the big web actors do everything in the cloud these days and they don't care about this use case.
    - forgotmypw17 6y ago
      I AM against it, because it puts more centralized censorship power in the hands of the certificate authority. Also, it completely cuts out "legacy" devices, basically anything more than 5 years old. The Web is once again splitting into AOLized mainstream and "indie underground" that you have to make an effort to access.
      - chc 6y ago
        Who is "the certificate authority" you're referring to here?
        jussij 6y ago
        The OP means that in using https (and being forced to used https) you are also being forced into paying a 'third party' an annual fee just to get a valid certificate. That 'third party' is one of the recognized 'certificate authorities'. But the OPs point is by going https, you don't have a choice, you have to pay the certificate tax.
        jjoonathan 6y ago
        Right, and Let's Encrypt doesn't solve the problem, it just kicks the can to DNS, which is globally unique and costs money. Communicating between your computer and any device that you supposedly own without the slow, unnecessary, and increasingly intrusive permission of some cloud IoT stack will become more and more difficult.
- bpye 6y ago
  Self-signed certificates seem reasonable in this context - unless I’m missing something.
  - tsimionescu 6y ago
    They might to you, but the browser doesn't agree. It will scream with all its force to all your users that this accessing that product is a really really dangerous idea.
    - chpatrick 6y ago
      You can set up the users' machines so that they trust your certificate.
      - heinrichhartman 6y ago
        I have tried to do just that but ran into all kinds of difficulties: 1. Overhead: I have 5 devices that I own 3 of my wife and a smart TV. Setting all this us takes a lot of time, even if it worked fine. 2. What about visitors to my home, that I want to give access? They need the cert as well together with lengthy instructions on how to install it. 3. How do I even install certs on an iPhone? 4. Firefox uses it's own Certificate Database -- for each profile. So I'll have to install certs on the system AND on the host (for e.g. Chrome to find it). 5. All these steps need to be repeated every year (90 days?!) depending on the cert expiration period. Eventually I just gave up on this. It's not practical. There needs to be a better solution.
        spockz 6y ago
        I have been looking at using MDM for my iPhone so I can install trusted root certs and require it to be on vpn when not using a specific list of WiFi networks. It is a hassle and as far as I could see it requires resetting the device and I’m not sure I can restore my backup over it and retain both.
        zaarn 6y ago
xg15 6y ago
> initial connections to http-only sites will be a bit slower (vs. the opposite which used to be true: initial connections to https-only sites were slower). More than a bit. For HTTPS-only sites, the site could serve a stub HTTP endpoint on port 80 that redirects to HTTPS. The redirect causes maybe some milliseconds to a few seconds (worst case) of latency. HTTP-only on the other hand can't do a HTTPS stub as easily (as the primary reason you'd want HTTP-only is probably that you don't want/can't deal with the certificate management - if you can set up a redirect from HTTPS to HTTP, you might as well go full HTTPS) So the only option for HTTP-only is to not open port 443 at all - meaning Chrome has to wait out the 30 seconds (!) network timeout until it can try the fallback. So pure-HTTP sites would become a lot more unpleasant to use. (A site might be able to cut this short by actively refusing the TCP handshake and sending an RST packet - or by opening and immediately closing the connection. I don't know how Chrome would react to this. In any case, that's likely not what HTTP-only sites in the wild are doing, so they'll need to update their software - at which point, they might just as well spend the effort to switch to HTTPS)
- zaarn 6y ago
  You can simply send a ICMP Rejected Message, which should direct your browser to immediately try any fallbacks or other hosts. Timeouts occur when you incorrectly configure your firewall to drop packets instead of rejecting.
  - xg15 6y ago
    True, that would work as well. Though I believe it's recommended as a best practice to simply drop packets as not to help port scanners.
    - zaarn 6y ago
      I don't worry about port scanners. If your infrastructure becomes less secure because of a port scanner, it's not very well secured. Sending a REJECT is cheap, no DDoS opportunity and helps browsers and other apps fail over fast. The recommended practise I've heard everywhere is that an ICMP REJECT provides no opportunities for an attacker they wouldn't have with 10 minutes extra time (modern port scanners can be set aggressive enough that REJECT or DROP doesn't matter if they have a known open port they can obtain an ACCEPT timeline from).

by alecbz 6y ago

j1elo 6y ago

I'm talking about the general state of HTTPS implantation. If you develop an offline device which offers a web UI, and it happens to use any feature that is deemed to require a Secure Context, you're out of luck. WebRTC is such a feature, but there are lots more, and they can change from one version of the browser to the next one. The players who are pushing so hard to shove HTTPS down our throats are simply closing their eyes and ignoring the use cases that are not interesting to them. The mandatory renewal timing is a good example: it used to be more than 1 year, now it is 90 days (and some would like to reduce it to mere weeks!) Absolutely great for the grand scheme of things and global security of the Internet, but dismaying for lots of other use cases.

dcow 6y ago
Yeah, I think we need a browser that isn't developed by companies with vested interests in having all your traffic go to them...
- spurgu 6y ago
  Then again I think Google would do just fine even if Firefox was the only browser.
Wowfunhappy 6y ago
I don't actually see the problem. If you're on a local network, there's no practical way to deal with certificates, so use http. Chrome will fall back. Problem solved. If http support ever gets truly removed, I will be very upset. But that hasn't happened, so what is there to complain about?
- simias 6y ago
  HTTP is effectively considered legacy by the big web actors these days. More and more APIs are HTTPS-only (often for good reasons) and the "insecure" warnings you get from using HTTP become more intrusive every year. The trajectory is pretty clear, the long term plan is to phase out HTTP completely. And I'm not against it, but I need a solution for LAN devices, and it doesn't exist at the moment because the big web actors do everything in the cloud these days and they don't care about this use case.
  - forgotmypw17 6y ago
    I AM against it, because it puts more centralized censorship power in the hands of the certificate authority. Also, it completely cuts out "legacy" devices, basically anything more than 5 years old. The Web is once again splitting into AOLized mainstream and "indie underground" that you have to make an effort to access.
    - chc 6y ago
      Who is "the certificate authority" you're referring to here?
      - jussij 6y ago
        The OP means that in using https (and being forced to used https) you are also being forced into paying a 'third party' an annual fee just to get a valid certificate. That 'third party' is one of the recognized 'certificate authorities'. But the OPs point is by going https, you don't have a choice, you have to pay the certificate tax.
        jjoonathan 6y ago
        Right, and Let's Encrypt doesn't solve the problem, it just kicks the can to DNS, which is globally unique and costs money. Communicating between your computer and any device that you supposedly own without the slow, unnecessary, and increasingly intrusive permission of some cloud IoT stack will become more and more difficult.
bpye 6y ago
Self-signed certificates seem reasonable in this context - unless I’m missing something.
- tsimionescu 6y ago
  They might to you, but the browser doesn't agree. It will scream with all its force to all your users that this accessing that product is a really really dangerous idea.
  - chpatrick 6y ago
    You can set up the users' machines so that they trust your certificate.
    - heinrichhartman 6y ago
      I have tried to do just that but ran into all kinds of difficulties: 1. Overhead: I have 5 devices that I own 3 of my wife and a smart TV. Setting all this us takes a lot of time, even if it worked fine. 2. What about visitors to my home, that I want to give access? They need the cert as well together with lengthy instructions on how to install it. 3. How do I even install certs on an iPhone? 4. Firefox uses it's own Certificate Database -- for each profile. So I'll have to install certs on the system AND on the host (for e.g. Chrome to find it). 5. All these steps need to be repeated every year (90 days?!) depending on the cert expiration period. Eventually I just gave up on this. It's not practical. There needs to be a better solution.
      - spockz 6y ago
        I have been looking at using MDM for my iPhone so I can install trusted root certs and require it to be on vpn when not using a specific list of WiFi networks. It is a hassle and as far as I could see it requires resetting the device and I’m not sure I can restore my backup over it and retain both.
      - zaarn 6y ago

xg15 6y ago

> initial connections to http-only sites will be a bit slower (vs. the opposite which used to be true: initial connections to https-only sites were slower). More than a bit. For HTTPS-only sites, the site could serve a stub HTTP endpoint on port 80 that redirects to HTTPS. The redirect causes maybe some milliseconds to a few seconds (worst case) of latency. HTTP-only on the other hand can't do a HTTPS stub as easily (as the primary reason you'd want HTTP-only is probably that you don't want/can't deal with the certificate management - if you can set up a redirect from HTTPS to HTTP, you might as well go full HTTPS) So the only option for HTTP-only is to not open port 443 at all - meaning Chrome has to wait out the 30 seconds (!) network timeout until it can try the fallback. So pure-HTTP sites would become a lot more unpleasant to use. (A site might be able to cut this short by actively refusing the TCP handshake and sending an RST packet - or by opening and immediately closing the connection. I don't know how Chrome would react to this. In any case, that's likely not what HTTP-only sites in the wild are doing, so they'll need to update their software - at which point, they might just as well spend the effort to switch to HTTPS)

zaarn 6y ago
You can simply send a ICMP Rejected Message, which should direct your browser to immediately try any fallbacks or other hosts. Timeouts occur when you incorrectly configure your firewall to drop packets instead of rejecting.
- xg15 6y ago
  True, that would work as well. Though I believe it's recommended as a best practice to simply drop packets as not to help port scanners.
  - zaarn 6y ago
    I don't worry about port scanners. If your infrastructure becomes less secure because of a port scanner, it's not very well secured. Sending a REJECT is cheap, no DDoS opportunity and helps browsers and other apps fail over fast. The recommended practise I've heard everywhere is that an ICMP REJECT provides no opportunities for an attacker they wouldn't have with 10 minutes extra time (modern port scanners can be set aggressive enough that REJECT or DROP doesn't matter if they have a known open port they can obtain an ACCEPT timeline from).