> Starting with Chrome 94, Chrome no longer allows HTTP requests to local IP addresses.
What kind of scenario does that prevent?
What kind of scenario does that prevent?
https://developer.chrome.com/blog/private-network-access-upd...
To answer your question:
HTTP is vulnerable to MITM attacks. For example your ISP can modify any page you visit, steal passwords, cookies, oauth tokens, etc. If the site is forced to switch to HTTPS, your ISP can no longer pull off this attack.
Full disclosure I work at Google, but not on Chrome.
My evil website can no longer access the top secret stuff you are developing on localhost.
My evil website can no longer enumerate the http servers in your local LAN.
But that isn't very elegant, so I propose version 2.0:
"This site has requested communication with a local device. Please select it from this list:"
[the user is presented with a list of devices discovered by zeroconf/dns-sd/mdns/upnp matching the service descriptor given by the page]
Turns out, this was an actual spec [0] pushed by Opera of all companies. Here's a quote from the spec:
> window . navigator . getNetworkServices ( type , successCallback [, errorCallback ] ) > > Prompts the user to select discovered network services that have advertised support for the requested service type. > > The type argument contains one or more valid service type tokens that the web page would like to interact with. > > If the user accepts, the successCallback is invoked, with zero or more NetworkService objects as its argument. > > If the user declines, the errorCallback (if any) is invoked.
Full disclosure I work at Google, but not on Chrome.
> If your website needs to issue requests to a target server on a private IP address, then simply upgrading the initiator website to HTTPS does not work. Mixed Content prevents secure contexts from making requests over plaintext HTTP, so the newly-secured website will still find itself unable to make the requests.
The solution, of course, is clear to the Chrome devs - certificate pinning. Unfortunately, they implemented it in an absolutely ridiculous way that limits you to WebTransport for absolutely no other reason other than they want to force developers to use it as soon as possible before the other browser vendors (*vendor) implement it. As I mentioned in a sibling comment, there is absolutely no reason to not simply add a "CACert" option to XHR,fetch,WebSocket... and let developers use the existing protocols.
What do you mean? The only change Chrome is making is limiting it from http:// sites. If Portal is saying Chrome is breaking them, then they must have been making connections from http:// sites. The mixed content limitations have been there for a long time already, which must be why they were using http:// . I've never used Portal myself so I don't have direct evidence they were using http:// , but this is the only logical explanation I can come up with for why they would say Chrome is breaking them.
https://developer.chrome.com/blog/private-network-access-upd...
> The aim is to protect users from cross-site request forgery (CSRF) attacks targeting routers and other devices on private networks.
https://developer.chrome.com/blog/private-network-access-upd...
I believe the change is that http:// pages on public websites won't be able to talk (such as via XHR/fetch, embedded images/scripts/css) to private IP address or sites with domains that resolve to private IP addresses.
One obvious workaround is to change the requesting page to https:// instead of http:// . This is somewhat difficult because then there's the problem of mixed content, since it's often difficult to get an https:// certificate for the server that runs on the private IP address.
There are 2 other workarounds listed on the Chrome blog post: WebTransport and and Reverse embedding (which means running the site on a private IP address instead of a public IP address). It looks to me like those could work in the Portal case.
Full disclosure I work at Google, but not on Chrome.