Why does a Chromebook need Port 80 open to connect to Google

[Tony B]

We have a number of users who have Chromebooks, we have identified that a connection is made over port 80 which of course is insecure and should not be used to initiate any sort of login session, can someone in the know tell me why this is and how we force the use of port 443? 

Thanks

[Kevin Chowski]

Which URL is being accessed over port 80?

On Thu, Nov 19, 2020, 12:52 AM 'Tony B' via Chromium OS Discussion <chromium-...@chromium.org> wrote:

We have a number of users who have Chromebooks, we have identified that a connection is made over port 80 which of course is insecure and should not be used to initiate any sort of login session, can someone in the know tell me why this is and how we force the use of port 443? 

Thanks

--
--
Chromium OS Discussion mailing list: chromium-...@chromium.org
View archives, change email options, or unsubscribe:
https://groups.google.com/a/chromium.org/group/chromium-os-discuss
---
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dis...@chromium.org.

[Tony B]

we see the devices connecting to different IP addresses which resolve to Google 216.58.211.227 being one of them. Im being told that port 80 is needed to login which I find very hard to believe

[dragon788]

Have you traced the sessions with Wireshark to see whether it upgrades the connection to SSL after the initial connection on port 80?

[Tony B]

We cannot deploy WireShark unfortunately, I would have hoped someone from Google would have the answer to hand, it seems strange that Port 80 is used at all especially during the connection initiation process. I've searched around the interweb for an answer, all I can find are people reporting issues when trying to connect and port 80/443 being blocked. 

Does anyone from Google monitor these forums/groups? 

[Pavol Marko]

One thing Chrome OS does is captive portal checks by trying to reach e.g. http://www.gstatic.com/generate_204

https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/shill/portal_detector.cc#51

If that fails, Chrome OS assumes that a captive portal or something in the network is preventing connection to the internet.

[Tony B]

Thanks that is useful but why check on HTTP at all? and if it fails on HTTP but works on HTTPS then why would the Chromebook not login, we have blocked port 80 outbound and have seen the users are unable to login to their devices. 

[Pavol Marko]

+stev...@chromium.org - do you know if there were plans to allow captive portal detection to work on https only?

[Pavol Marko]

I do seem to remember that Chrome OS just shows "Network not available" if gstatic.com is not reachable over HTTP. Will try to repro in the next few days.

On Fri, Nov 20, 2020 at 7:06 PM Steven Bennetts <stev...@chromium.org> wrote:

Is this actually preventing login? Is this a recent regression? If so, can you identify the version where the behavior regressed?

Chrome OS does an HTTP probe to try to identify a redirect URL (which is not provided by an HTTPS probe). This has been the case for a while, however there has been some recent re-factoring of that code which may impact the behavior, and if there are bugs associated with the changes we would very much like to know the specifics.

[Joe Ellett]

Since port 80 is the original "website" port, it's a good way to "ping a website to see if it´s up. If port 80 doesn't respond, the website is probably down, whereas if port 80 responds but port 443 doesn't, it indicates that there is a security problem.

So, consider it used for diagnostic information as part of making the connection to the site.

[Tony B]

Port 80 is insecure, Chrome and all browsers inform users of this presently and organizations are strongly advised not to advertise port 80 any more so its strange that it is used for a so called ping to make sure a web site is alive, any decent website with appropriate security controls in place would drop such a connection attempt if it even got through the perimeter controls. 

[Steven Bennetts]

Right.

I just tested OOBE and login with Chrome OS 86 (which predates the recent re-factoring)  against a router with port 80 blocked, and the behavior is the same for both OOBE and Login. (The UX for this is pretty poor, but it is not a scenario that was anticipated).

I'm not sure that expecting login to work correctly with port 80 blocked is feasible at this time, but I will ask some of our security experts.

[Tony B]

Thanks Steve, please keep us posted.

[Steven Bennetts]

Chrome OS login and updates use their own very strong security. I am not an expert on that topic, so I am unfamiliar with which ports and protocols are used and why, but I suspect there are good reasons for what they do. That said, I will follow up with some experts.

[dragon788]

Just to clarify one thing, port 80 in and of itself is not insecure, by *convention* HTTP communication on port 80 is not encrypted with TLS and web browsers have been coded to assume that it is an unencrypted connection, the same way they have been coded to assume that 443 is secure.

As stated the request checking for the availability of a website does not transmit credentials, and unless some information that should be private is being transmitted port 80 is perfectly adequate.

This network connectivity check also requires a DNS request  via port 53 and I'd wager in the majority of networks that request is not encrypted either because DNSSec isn't ubiquitous.

I just want to make sure that nobody's making mountains out of mole hills.

[Tony B]

You’ll probably find that a good majority of orgs prefer not to allow port 80 comms outbound to protect them and their employees therefore it would be beneficial if the network check looked for availability of servers on 443 also if the solution must do a network check during login. At this stage I’m trying to establish what is actually occurring during the boot up and login process to decide whether theres any risk of allowing port 80 for these specific devices. 

[Pavol Marko]

Could you allow port 80 to www.gstatic.com ? (I guess more correct "could you allow port 80 to the IP addresses that www.gstatic.com resolves to? )

[Tony B]

apparently there's a bunch of IP addresses that need to be allowed outbound and as its a URL I assume the DNS resolves to any one of the servers set behind it that Google choose to use. I wouldn't have thought it would be difficult to disable port 80 and configure for 443 only checks. 

[Kevin Chowski]

A complication I see is how to handle the case where a chromebook user wants to connect to the WiFi at a location where there's an interstitial they must accept (e.g. terms and conditions) before accessing the internet. This is the "captive portal" situation that was mentioned very early in in the thread. Let me clarify the importance, at least as I see it:

With HTTP (over port 80) the WiFi provider can easily redirect the user to the relevant "captive portal" page, because they are on the physical layer between the chromebook and the gstatic servers (and because HTTP is very trusting of the physical layer, allowing content injection).

On the contrary, with HTTPS (over port 443) the WiFi provider cannot successfully impersonate gstatic.com, because it does not have the certificate of of gstatic.com, so I'm not actually sure what it could do to get the client to the terms and conditions. Providing some arbitrary certificate would cause issues for the client laptop, because it would look like a different server than gstatic and the client should refuse the connection as unsafe. (this is working as intended, HTTPS is supposed to help prevent against snooping on the physical layer).

So, blocking port 80 on some chromebook would ultimately prevent that chromebook for accessing these sorts of WiFi points, unless I'm missing something.

[DennisLfromGA]

On a related subject, Chrome OS uses an 'iptables' firewall. 

For a look at what is DROPPED and ACCEPTED by default see the below file in /etc/init that will 'start on starting network-services'

• https://source.chromium.org/chromiumos/chromiumos/codesearch/+/master:src/third_party/chromiumos-overlay/chromeos-base/chromeos-firewall-init/files/iptables.conf;l=1?q=iptables.conf%20

~DennyL

[Tony B]

@Kevin, you stated the exact reason why Port 80 is bad for a business situation, spoofing sites etc, logically I would expect this to be configurable, e.g. switch port 80 checks off in policy or at least check port 80 and if not available switch to 443 for the checks, the behavior we are seeing is that if Port 80 is blocked the users cannot log in. 

[Kevin Chowski]

Bob, the issue is that if port 80 is blocked entirely, then there is no way to "go through the captive portal flow" at all. As I understand it, that flow needs to be served via HTTP. If it's blocked, it can't be done regardless of whether the check happens first or second.

On Mon, Nov 23, 2020, 1:03 PM Bob Haarman <ingl...@chromium.org> wrote:

As I understand this thread, the logic is:

We want to connect to something using HTTPS on port 443. To do this, we:

1. Try to connect to something using unencrypted HTTP on port 80.
2. If there is a captive portal, it can intercept this and go through some steps before enabling real Internet access.
3. If connecting on port 80 fails altogether, we give up and claim there is no Internet access.
4. If we are able to connect to our special page on port 80, we then attempt the connection to port 443.

Why don't we instead

1. Try the connection on port 443 that we are trying to establish.
2. If that succeeds, we're done.
3. If it fails, go through the captive portal flow, then try again?

It seems to me this would avoid failing to establish connections to port 443 because an unrelated port is blocked, while still enabling the captive portal flow Kevin described.

[Kevin Chowski]

Oh, I guess I was thinking the port 80 blockage was happening on the laptop itself. If the blocking of port 80 that OP is talking about is just in their network, then I can't find fault in that strategy, since port 80 wouldn't be blocked on some other network with a captive portal. (But I am not an expert nor do I speak for the project at large.)

[Pavol Marko]

Yeah, captive portal needs to go through port 80 because only there will the captive portal (which is "hijacking" the HTTP request) be able to server a HTTP redirect, hinting Chrome OS at the captive portal web page location.

Agree that if you explicitly don't have a captive portal Chrome OS should probably accept "port 443 works fine" as a working non-portalled connection - though we would probably need to collect data from real world usage to see if that assumption is true in practice. Would you mind creating a feature request on crbug.com for this (Chrome OS should work when port 80 is blocked but port 443 is open)?

[Bob Haarman]

As I understand this thread, the logic is:

We want to connect to something using HTTPS on port 443. To do this, we:

1. Try to connect to something using unencrypted HTTP on port 80.
2. If there is a captive portal, it can intercept this and go through some steps before enabling real Internet access.
3. If connecting on port 80 fails altogether, we give up and claim there is no Internet access.
4. If we are able to connect to our special page on port 80, we then attempt the connection to port 443.

Why don't we instead

1. Try the connection on port 443 that we are trying to establish.
2. If that succeeds, we're done.
3. If it fails, go through the captive portal flow, then try again?

It seems to me this would avoid failing to establish connections to port 443 because an unrelated port is blocked, while still enabling the captive portal flow Kevin described.

On Monday, November 23, 2020 at 10:02:01 AM UTC-8 Kevin Chowski wrote: