We are observing that this change is breaking traffic going through middleboxes when the upstreams have misconfigured TLS. The main problem is that from the moment a middlebox completes the TLS handshake of the HTTPS-upgraded connection, the fallback cannot be triggered. Although the blog post [link <https://blog.chromium.org/2023/08/towards-https-by-default.html>] and the explainer [link <http://main>] suggest using a 404 response or a specific header from the upstream to trigger the fallback, neither of these options seem to be available in Chrome. Consequently, enterprise proxies need to advise admins to disable the automatic upgrades feature for their users to avoid breaking some traffic. This is a bad outcome both in terms of security and configuration complexity. Ideally we’d like all users to keep this feature enabled, but have it work when middleboxes are involved and the upstream is faulty.
Another critical aspect here is that sometimes middleboxes terminate TLS with the eyeball before contacting the upstream. This can happen for security or performance reasons, to improve UX, or to provide other features. Previously this was acceptable as the middlebox could return an HTML error page if the connection failed. With the introduction of this feature, instead users are unable to access the upstream, only seeing an error message from the middlebox. If Chrome were to support the opt-out header as outlined in the explainer linked above, middleboxes could return it when upstreams turn out to be unreachable. Alternatively, following the recommendation on this comment [ link <https://github.com/w3ctag/design-reviews/issues/853#issuecomment-1622149334>], if Chrome sent a header identifying the current request as being triggered by the automatic upgrade flow, then middleboxes would be able to redirect to HTTP in these situations. Notice this can’t be done in the general case, since the middlebox might be redirecting the user to a site they didn’t request. We believe implementing these changes would greatly enhance compatibility with middleboxes and improve the overall user experience,so we appreciate your attention to this matter and eagerly await your feedback On Tuesday, December 5, 2023 at 1:26:28 AM UTC bul...@hotmail.com wrote: > On Thursday, November 9, 2023 at 11:18:51 AM UTC-5 Andreas S wrote: > > Same situation here @Franky > I'm working for a mobile payment service provider that offers mobile > payment in multiple countries in Europe. > Multiple mobile network operators in Europe like few ones in Poland > currently only support end user identification via header enrichment! > > The header enrichment is used for an automatic silent end user > identification that allows service providers in subsequent flow (of course > via https!) to: > a) auto-login an already known end user in mobile web > b) offer an end-user the possibility to purchase a good/service without > need to enter mobile phone number of a user in mobile web (which would > require a media break to validate the number via SMS). > > The enforced https upgrade has a huge negative impact on usability of such > services for end-users in mobile web: > Flow that worked automatically in the past gets now interrupted by a > request for confirmation for an unsecure flow -> scares a lot of people as > it looks very unprofessional. > > Hope you have a realizable idea to deal with this use case, to offer end > users a good user experience again! > (changing identify flow from HE to redirect loop ot mobile network > operator is unfortunately not, as they have very limited ressources :( > > > ATT Wireless USA (my testing, not easy to look up its exact header name > for me, but I've seen it before, partial evidence that ATTW has an > transparent port 80 proxy that adds req headers > https://howardforums.com/showthread.php/1908276-AT-amp-T-Prepaid-no-IPV6-address?p=17008722#post17008722 > > ) and Verizon Wireless USA ( https://news.ycombinator.com/item?id=8500131 > ) also add per-customer (I guess per SIM card) GUIDs to clear HTTP req > headers, by default. Its not politically correct, for any USA based service > provider, to publicly admit or document, they use ISP/customer specific > info from an LTE provider's port 80 transparent proxy, if a port 80 > transparent proxy exists, but as the post above says, in Poland, is it is > standard procedure to use an LTE ISP's metadata to change features and > behavior for customer facing websites. > > Advocating "can't you just make a smartphone native app and pass Apple and > Play store review if you want that info (raw TCP sockets)?" seems the > opposite of the goals and purpose of the W3C/WP. So whats the solution, if > there is a clear business need, as above, for a browser to navigate to a > cleartext port 80 domain and back again, which sounds impossible now? Note, > there is no opt-out mechanism from HTTPS upgrades defined in this spec > other than a a server delivering a RST TCP packet on port 443 or TLS > handshake but invalid/unsigned cert returned, or a many seconds long TCP > timeout on port 443. > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8874d5e9-2c8a-432e-94ac-9a19d99665a0n%40chromium.org.
