Chrome uses http://webcache.googleusercontent.com instead of https://webcache.googleusercontent.com
Reported by
93m4qau...@gmail.com,
Jan 3 2018
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.108 Safari/537.36 Steps to reproduce the problem: 1. Open a website when Chrome thinks that it is temporarily unavailable. 2. From Chrome's gray screen telling you about the situation, go to the cached version of the page at http://webcache.googleusercontent.com What is the expected behavior? Since both HTTP and HTTPS are available, Chrome should take you to the HTTPS as it is much more secure. What went wrong? Even though HTTPS is an option, Chrome takes you to the HTTP, which is much less secure. Did this work before? N/A Chrome version: 63.0.3239.108 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: I already submitted a report to the Google Issue Tracker (issuetracker.google.com) that the HTTP version should just redirect to the HTTPS so that it is always HTTPS, but they immediately refused to fix it and closed it as Won't Fix.
,
Jan 4 2018
I don't think this needs to be view-restricted. I couldn't find this hostname directly in our code, but I think the behavior is in the NetError pages: https://cs.chromium.org/chromium/src/components/error_page/common/localized_error.cc?l=501&rcl=569dd0ccbd64a2311aaf6df9f90cec997ddd30f0 Chrome hits a "LinkDoctor" service on Google.com, and *it* returns the HTTP link. Moving such links to HTTPS may not be trivial because they may have mixed content; we need to consult a subject matter expert on this.
,
Jan 16 2018
,
Jan 24 2018
I don't have a link to a page that does this at the moment, unless there is some set of test pages out there that could do the job. I also don't have a screenshot either.
,
Jan 24 2018
Thank you for providing more feedback. Adding requester "nparker@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 26 2018
Thanks for the report! elawrence's comment in #2 is correct - this insecure navigation comes from Link Doctor, and is an external dependency from Chrome. elawrence/nparker, can you file an internal bug against link doctor as to whether they can write their URLs as https:// ? ============= What happens ============= (In my demonstration below, I am using www.apple.com as the failed navigation) (1) Navigate to www.apple.com (2) Chrome issues a request to "https://www.googleapis.com/rpc" for details (3) Link doctor responds with this relevant JSON snippet (here I chose www.apple.com as the unavailable webpage): ... "correctionType": "cachedPage", "urlCorrection": "http://www.google.com/search?q=cache:https://www.apple.com/", ... (4) When clicking the "Show Saved Copy" button, Chrome navigates to http://www.google.com/search?q=cache:https://www.apple.com/ (HSTS addresses this insecure load on www.google.com) (5) The response redirects to "http://webcache.googleusercontent.com/search?q=cache:https://www.apple.com/" (The URL named in this report). ============= Steps to reproduce ============= (1) Launch Chrome with command line: --host-resolver-rules="MAP www.apple.com ~NOTFOUND" (2) Ensure "Use a web service to help resolve navigation errors" is enabled under advanced settings. (3) Navigate to www.apple.com (4) Click the button.
,
Jan 26 2018
(Eh, I will leave the Network label on to simplify tracking this)
,
Jan 28 2018
I already filed a bug on the Google Issue Tracker requesting that the webcache.googleusercontent.com domain be made HSTS, but they refused because their "internal project" is all locked up and secret.
,
Mar 12 2018
Has anyone filed the internal bug for this?
,
Mar 16 2018
I've reproduced it in M67 canary by following steps in Comment 7 and have created internal issue b/75310367.
,
Mar 21 2018
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by metzman@chromium.org
, Jan 4 2018