5 ms·

Surely we are past this bullshit now thanks to https being everywhere? Also this is our reminder that yes, HTTPS is worth it even for "It's just my blog, I hav

by jraph 3y ago

Surely we are past this bullshit now thanks to https being everywhere? Also this is our reminder that yes, HTTPS is worth it even for "It's just my blog, I have nothing to hide, why should I encrypt?"

dosinga 3y ago
Agreed. It's interesting to see though in the comments that all the links there are http:// http:// even the ones that are to security posts
- olabyne 3y ago
  The comments are from 2012.
vaylian 3y ago
> Surely we are past this bullshit now thanks to https being everywhere? Plenty of hotels (and other places) misdirect your DNS queries so that your machine will connect to the hotel's captive portal where you need to accept the terms and conditions for using the wifi. This causes HTTPS connections to fail. Captive portals are a rather inelegant hack, but in most cases they achieve what they are designed to achieve.
- red_admiral 3y ago
  But once you're past the portal (even if you need to manually load example.com so you actually see it without hitting cert pinning errors), TLS gives you back the "can't touch this" you want.
  - jraph 3y ago
    Yep, and more and more OSes and browsers detect this situation and propose you a button to go to the portal. At least for me, both KDE and firefox have their mechanism for this. It still breaks a lot of stuff (notably, the Nextcloud client) as long as you are not logged on the captive portal, but well…
    - extraduder_ire 3y ago
      Android, iOS, and windows also have this functionality. It's a shame there hasn't been a widely implemented standard for captive portal things yet. Even if what we have now works alright if you're doing web things.
- labcomputer 3y ago
  > Plenty of hotels (and other places) misdirect your DNS queries so that your machine will connect to the hotel's captive portal where you need to accept the terms and conditions for using the wifi. And for all the whining about how "but DNSSEC doesn't do anything!", this is exactly an attack scenario which DNSSEC protects, and which it has protected since the very first RFC describing it. The client can check for itself whether the IP address in the response has been correctly signed by the (sub-)domain owner (and recursively whether the (sub-)domain has been signed by the parent domain, all the way back to the root). As for "but how will I redirect hosts to my captive portal?", that's what DHCP option 114, DHCPv6 option 103 and IPv6 Router Advertisement option 37 are for. https://developer.apple.com/news/?id=q78sq5rv https://developer.apple.com/news/?id=q78sq5rv
  - WillowZzzzz 2y ago
    Add DoH/DoT to your reply and you're correct.
  - tdtd 3y ago
    If the network’s owner was the one doing DNS redirects, couldn’t they just instead use the IP address in the DNSSEC-signed record themselves? I don’t think DNSSEC is a robust protection if you don’t trust the network you’re connected to.
    - lmz 3y ago
      This would break the chain of trust (you wouldn't trust the network's key signing the address for that zone).
      - tdtd 3y ago
        The attacker doesn’t resign the DNS record with their own key, they just let the legitimately signed record though and use the IP address in that legitimate record themselves. If someone owns the network (or is an active MitM) they can control where IP addresses route to.
    - tptacek 3y ago
stuff4ben 3y ago
I remember when this stuff was happening. It was like the world shifted over to HTTPS instantly. Wish we could do the same for IPv6.
- OkayPhysicist 3y ago
  It basically did. Cloudflare rolled out a free feature to enable HTTPS support on every site they served via (not unchecking? Don't remember the opt-in/opt-out detail) a checkbox in 2014, and less than a year later Let's Encrypt became available. Only a couple years later in 2018, Chrome and Firefox started marking non-http sites as "unsafe".
ramon156 3y ago
You'd be surprised how many hotels can't be bothered
- bongodongobob 3y ago
  I wouldn't be surprised at all. It's not like they've got on-site IT support. Split off a guest network on its own VLAN and done, never to be touched again. The less complicated the better.
kevincox 3y ago
I've long wondered if there was a place for a httpv mode. Where traffic is signed but not encrypted. This would allow local caching or torrent-like distributed fetching but not modification. The obvious downside is that the page contents are not private. Chrome implemented something sort of like this with https://developer.chrome.com/blog/signed-exchanges https://developer.chrome.com/blog/signed-exchanges. However this is very limited. It requires the linking site to cooperate. For example Google Search can link to a signed exchange rather than the original site. But this just moves traffic from the site's CDN to Google's. It also packages full bundles so shared resources need to be duplicated. Also any navigation inside that site will go to the origin and can't be cached. Overall it seems like it probably isn't worth it. But I find it an interesting idea.
- Jerrrry 3y ago
  This is awesome. Propose an RFC - seriously. This simplifies, democratizes, and makes transparent the "internal resource sharing/caching" that some browsers can do, like when needing to load the latest jQuery for the 15th time in the last minute, even across domains. Also would be perfect for captive portals, or other static LAN content.
  - pkage 3y ago
    I think the problem comes down to fingerprinting. For example, resources used to be cached in the browser regardless of site exactly as you described, but then ad companies figured out you can track a user's browsing history by timing the cache accesses to see if a user had loaded a bundle from another site. To remove that vector, browsers split up caches per domain.
    - Jerrrry 3y ago
      That's a vector for literally all assets so adding a random delay to every layer up to the last Paint() is the only real counter. It can be mitigated by adding a property to scripts to allow/default/deny shared domain resource caching, and the ecosystem can benefit from jquery/etc from being hot but still maintain opt-in default/backwards-compat status. that, combined with the already established HTML <script> integrity Attribute and you are gravy
deleted 3y ago
[deleted]

by jraph 3y ago

dosinga 3y ago

Agreed. It's interesting to see though in the comments that all the links there are http:// http:// even the ones that are to security posts

olabyne 3y ago
The comments are from 2012.

vaylian 3y ago

> Surely we are past this bullshit now thanks to https being everywhere? Plenty of hotels (and other places) misdirect your DNS queries so that your machine will connect to the hotel's captive portal where you need to accept the terms and conditions for using the wifi. This causes HTTPS connections to fail. Captive portals are a rather inelegant hack, but in most cases they achieve what they are designed to achieve.

red_admiral 3y ago
But once you're past the portal (even if you need to manually load example.com so you actually see it without hitting cert pinning errors), TLS gives you back the "can't touch this" you want.
- jraph 3y ago
  Yep, and more and more OSes and browsers detect this situation and propose you a button to go to the portal. At least for me, both KDE and firefox have their mechanism for this. It still breaks a lot of stuff (notably, the Nextcloud client) as long as you are not logged on the captive portal, but well…
  - extraduder_ire 3y ago
    Android, iOS, and windows also have this functionality. It's a shame there hasn't been a widely implemented standard for captive portal things yet. Even if what we have now works alright if you're doing web things.
labcomputer 3y ago
> Plenty of hotels (and other places) misdirect your DNS queries so that your machine will connect to the hotel's captive portal where you need to accept the terms and conditions for using the wifi. And for all the whining about how "but DNSSEC doesn't do anything!", this is exactly an attack scenario which DNSSEC protects, and which it has protected since the very first RFC describing it. The client can check for itself whether the IP address in the response has been correctly signed by the (sub-)domain owner (and recursively whether the (sub-)domain has been signed by the parent domain, all the way back to the root). As for "but how will I redirect hosts to my captive portal?", that's what DHCP option 114, DHCPv6 option 103 and IPv6 Router Advertisement option 37 are for. https://developer.apple.com/news/?id=q78sq5rv https://developer.apple.com/news/?id=q78sq5rv
- WillowZzzzz 2y ago
  Add DoH/DoT to your reply and you're correct.
- tdtd 3y ago
  If the network’s owner was the one doing DNS redirects, couldn’t they just instead use the IP address in the DNSSEC-signed record themselves? I don’t think DNSSEC is a robust protection if you don’t trust the network you’re connected to.
  - lmz 3y ago
    This would break the chain of trust (you wouldn't trust the network's key signing the address for that zone).
    - tdtd 3y ago
      The attacker doesn’t resign the DNS record with their own key, they just let the legitimately signed record though and use the IP address in that legitimate record themselves. If someone owns the network (or is an active MitM) they can control where IP addresses route to.
  - tptacek 3y ago

stuff4ben 3y ago

I remember when this stuff was happening. It was like the world shifted over to HTTPS instantly. Wish we could do the same for IPv6.

OkayPhysicist 3y ago
It basically did. Cloudflare rolled out a free feature to enable HTTPS support on every site they served via (not unchecking? Don't remember the opt-in/opt-out detail) a checkbox in 2014, and less than a year later Let's Encrypt became available. Only a couple years later in 2018, Chrome and Firefox started marking non-http sites as "unsafe".

ramon156 3y ago

You'd be surprised how many hotels can't be bothered

bongodongobob 3y ago
I wouldn't be surprised at all. It's not like they've got on-site IT support. Split off a guest network on its own VLAN and done, never to be touched again. The less complicated the better.

kevincox 3y ago

I've long wondered if there was a place for a httpv mode. Where traffic is signed but not encrypted. This would allow local caching or torrent-like distributed fetching but not modification. The obvious downside is that the page contents are not private. Chrome implemented something sort of like this with https://developer.chrome.com/blog/signed-exchanges https://developer.chrome.com/blog/signed-exchanges. However this is very limited. It requires the linking site to cooperate. For example Google Search can link to a signed exchange rather than the original site. But this just moves traffic from the site's CDN to Google's. It also packages full bundles so shared resources need to be duplicated. Also any navigation inside that site will go to the origin and can't be cached. Overall it seems like it probably isn't worth it. But I find it an interesting idea.

Jerrrry 3y ago
This is awesome. Propose an RFC - seriously. This simplifies, democratizes, and makes transparent the "internal resource sharing/caching" that some browsers can do, like when needing to load the latest jQuery for the 15th time in the last minute, even across domains. Also would be perfect for captive portals, or other static LAN content.
- pkage 3y ago
  I think the problem comes down to fingerprinting. For example, resources used to be cached in the browser regardless of site exactly as you described, but then ad companies figured out you can track a user's browsing history by timing the cache accesses to see if a user had loaded a bundle from another site. To remove that vector, browsers split up caches per domain.
  - Jerrrry 3y ago
    That's a vector for literally all assets so adding a random delay to every layer up to the last Paint() is the only real counter. It can be mitigated by adding a property to scripts to allow/default/deny shared domain resource caching, and the ecosystem can benefit from jquery/etc from being hot but still maintain opt-in default/backwards-compat status. that, combined with the already established HTML <script> integrity Attribute and you are gravy

deleted 3y ago

[deleted]