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. 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.

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.

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.

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

I believe one of the big reasons why things aren't cached cross-domain is the possibility of fingerprinting by looking at which requests are cached. It's also a lot less beneficial in today's (one could say unfortunate) world of JS and CSS bundling/compilation/whatever.

What's the downside of HTTPS that you'd want to remove the encryption feature?

Captive portal detection is endlessly buggy.

That's explicitly why captive portal detection does not use HTTPS. If your OS of choice fails to detect captive portal (or doesn't implement detection), and you have the ability to visit a website, you can visit example.com to get into the captive portal.

The really annoying part is when a device (cough, Switch at launch) doesn't have portal detection nor a web browser, making it useless on hotel wifi.

I guess one could bring a laptop, spoof the Switch's WiFi MAC on the laptop and use it to login through that portal, and then disconnecting, and connect the "authorized" Switch. And make sure the Switch doesn't have "randomize MAC" like on Android/iOS.

But that's a huge workaround for many.

Yep I've done it. What a pain. Thankfully now the Switch does have captive portal detect and a little purpose built web view for agreeing to the terms.

I could see some forms of advertising or spam (or scams) preferring this.

You could do it today with TLS_RSA_WITH_NULL_SHA if null ciphers were still supported.

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

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.

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

The comments are from 2012.

> 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.

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.

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…

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.

> 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

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.

This would break the chain of trust (you wouldn't trust the network's key signing the address for that zone).

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.

They don't even have to do that. If they control the network, they can just set the AD flag to 'true' in a forged DNS response.

Add DoH/DoT to your reply and you're correct.

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.

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".