Pending: https://chromium-review.googlesource.com/c/chromium/src/+/1105299

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/36b8980c6b8763633161ee0472e10b4b4fd72ce3

commit 36b8980c6b8763633161ee0472e10b4b4fd72ce3
Author: Adam Langley <agl@chromium.org>
Date: Tue Jun 19 00:36:56 2018

Drop 1.1.1.1 from HSTS preloaded list.

This IP address is misused by some networking equipment and is breaking
things like captive portals. Hopefully in time we can reverse this but,
for now, ease the pain and drop 1.1.1.1 from the preload list.

BUG= 853934 

Change-Id: I8e8e9b212312430b66a19880ed5a74ebe303ec41
Reviewed-on: https://chromium-review.googlesource.com/1105299
Reviewed-by: Nick Harper <nharper@chromium.org>
Commit-Queue: Adam Langley <agl@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568260}
[modify] https://crrev.com/36b8980c6b8763633161ee0472e10b4b4fd72ce3/net/http/transport_security_state_static.json

Requesting merge:

This is a low-risk change: it's a change to a data file that removes a recently added entry that marked 1.1.1.1 as HTTPS-only. While Cloudflare own that IP address and are perfectly correct in setting policy for it, several instances have come to our attention where network equipment has squatted on that address incorrectly and is breaking.

I don't know if we're doing another M67 release but, if so, this would be a candidate for including in it. It doesn't justify an M67 respin on its own.

This bug requires manual review: M68 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Will this change be fully safe to merge to M67, won't cause any other regression?

This is a safe change to merge to M67. This change only affects the behavior of requests specifically made to the IPv4 address 1.1.1.1. It fixes the problem in this bug, and will not negatively affect requests made to that IP address.

Approving merge to M67 branch 3396 based on comment #4 and #7. Please merge now. Thank you.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3068f9ee90500c25388197a4fb8ee9bb3b4d6fca

commit 3068f9ee90500c25388197a4fb8ee9bb3b4d6fca
Author: Adam Langley <agl@chromium.org>
Date: Thu Jun 21 22:14:57 2018

Drop 1.1.1.1 from HSTS preloaded list.

This IP address is misused by some networking equipment and is breaking
things like captive portals. Hopefully in time we can reverse this but,
for now, ease the pain and drop 1.1.1.1 from the preload list.

BUG= 853934 

Change-Id: I8e8e9b212312430b66a19880ed5a74ebe303ec41
Reviewed-on: https://chromium-review.googlesource.com/1105299
Reviewed-by: Nick Harper <nharper@chromium.org>
Commit-Queue: Adam Langley <agl@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#568260}(cherry picked from commit 36b8980c6b8763633161ee0472e10b4b4fd72ce3)
Reviewed-on: https://chromium-review.googlesource.com/1110858
Cr-Commit-Position: refs/branch-heads/3396@{#787}
Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}
[modify] https://crrev.com/3068f9ee90500c25388197a4fb8ee9bb3b4d6fca/net/http/transport_security_state_static.json

Verified the fix in Chrome 67.0.3396.99 by opening net-internals, making a request to http://1.1.1.1, and verifying that an http (port 80) request is sent. (In Chrome 67.0.3396.87, net-internals showed an internal redirect from http to https and no traffic sent on port 80.)

Approved for M68. Branch:3440

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7bdb72af41fd3ed1771b14e43ff30947d396fdca

commit 7bdb72af41fd3ed1771b14e43ff30947d396fdca
Author: Adam Langley <agl@chromium.org>
Date: Mon Jun 25 18:38:36 2018

Drop 1.1.1.1 from HSTS preloaded list.

This IP address is misused by some networking equipment and is breaking
things like captive portals. Hopefully in time we can reverse this but,
for now, ease the pain and drop 1.1.1.1 from the preload list.

BUG= 853934 

Change-Id: I8e8e9b212312430b66a19880ed5a74ebe303ec41
Reviewed-on: https://chromium-review.googlesource.com/1105299
Reviewed-by: Nick Harper <nharper@chromium.org>
Commit-Queue: Adam Langley <agl@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#568260}(cherry picked from commit 36b8980c6b8763633161ee0472e10b4b4fd72ce3)
Reviewed-on: https://chromium-review.googlesource.com/1113878
Cr-Commit-Position: refs/branch-heads/3440@{#512}
Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733}
[modify] https://crrev.com/7bdb72af41fd3ed1771b14e43ff30947d396fdca/net/http/transport_security_state_static.json

Issue 856680 has been merged into this issue.

Was this merged to Android too?  I'm seeing Android portal problems in the Chrome Help Forum.  
Is it in Android Beta 68.0.3440.40 released 6/28?

Portals may also be able to fix this by adding an external DNS record on the portal wifi network that points 1.1.1.1 to the captive portal page i.e. guest.xxxxx.net.

Forum Android posts (there are more..)
https://productforums.google.com/forum/#!topic/chrome/OR8MGJvjVX4
https://productforums.google.com/forum/#!topic/chrome/XVg6zUa9COs

This change should be in 68.0.3440.40 on all platforms.

Confirmed working in Android 68.0.3440.40 here
  https://productforums.google.com/d/msg/chrome/OR8MGJvjVX4/erBcU7xrCwAJ

Is this going to make it to Android stable M67 soon?  Mobile portal users are stuck until their portal reconfigures.

FYI: The HSTS exclusion is only a partial fix.  Access to the 1.1.1.1 portal still throws the 'Connection not private' error, but at least the 'Advanced - Proceed to unsafe' option is now available.

The fix was also merged to M67 (in 67.0.3396.99), but I don't know if M67 is being updated on Android before M68 is released to stable.

Apparently this is a partial workaround fix.  Users get the Not Private intrestial and then have to use the Advanced, Proceed to unsafe option at the bottom to reach the portal.

The captive portal detection 'Connect to Wifi' page is not displayed.
Will this be added later?

For an example of the portal detection page look here
https://productforums.google.com/forum/#!topic/chrome/F5kD0jrjqtg

BTW: I saw a user confirmation that Android Beta 68.0.3440.40 allows signin thru the advanced option.

I have the same issue with open-mesh with chilli ,it uses the ip 1.0.0 1 

Deleted: IMG-20180708-WA0004.jpg 93.8 KB

	IMG-20180708-WA0004.jpg 93.8 KB View Download

I have the same issue with open-mesh with chilli ,it uses the ip 1.0.0 1 

Hi,

I work at Aerohive in its Tier 3 technical support team handling escalations from the field.

For reference, the software that runs on our APs, HiveOS, is affected by this issue - versions prior to HiveOS 8.0r1 would use 1.1.1.1 as a default CWP IPv4 address in its allocation algorithm.

It was an unfortunate default, bad practice in the wider industry to use this range.

We have changed the default behaviour in all our supported/maintained code branches of HiveOS to use a non-publicly routable IP range starting with HiveOS 6.5r10, HiveOS 8.2r4 and HiveOS 8.4r2, and we will be encouraging customers to update.

There has always been the ability to change the IP range used via an advanced setting, but most customers do not have this configured.

Thanks,

Nick