Issue metadata
Sign in to add a comment
|
iOS marks SHA-1 as mixed content |
||||||||||||||||||||||||
Issue descriptionVersion: Chrome 56.0.2891.0 OS: iOS 10.0 (iPhone SE) What steps will reproduce the problem? (1) Visit sha1-2016.badssl.com or sha1-2017.badssl.ocm (2) Tap on the ⓘ icon for Page Info. What is the expected output? We either don't downgrade, or the explanation talks about SHA-1 What do you see instead? Page Info implies there is a mixed content downgrade. There is no mixed content on the page. (You can also visit a 404 page like https://sha1-2016.badssl.com/404 to get the same behaviour, without any resources at all.) As of the WKWebView transition, the lock icons on these pages should be green: https://docs.google.com/document/d/1Z7HL9q2Rk9c_BZIjxfuJmuqmUifytT-jfvrJs-lWDE8/edit# I believe this is because we call hasOnlySecureContent [1] on the web view [2] and directly map a YES to web::SSLStatus::DISPLAYED_INSECURE_CONTENT. This matches the behaviour of Safari 10 on desktop. There used to be a "show SHA-1 as non-secure" developer menu setting in Safari 9, but it seems to be gone – SHA-1 always causes a downgrade to the insecure UI (no lock icon). We can ask Apple to expose more data on the web view about the kind of insecure content, but that's wouldn't be available to us any time soon, even if Apple were really motivated to provide it. I think the only safe thing we can do in the short term is change the mixed content string to something more vague. Sounds alright, emilyschechter@? [1] https://developer.apple.com/reference/webkit/wkwebview/1415002-hasonlysecurecontent [2] https://chromium.googlesource.com/chromium/src/+/fe5914ac26a8132c1588fb62ffe4bcde7bd29045/ios/web/web_state/ui/crw_web_controller.mm#4464 [3] https://chromium.googlesource.com/chromium/src/+/fe5914ac26a8132c1588fb62ffe4bcde7bd29045/ios/web/net/crw_ssl_status_updater.mm#77
,
Oct 19 2016
,
Oct 19 2016
,
Oct 19 2016
,
Oct 19 2016
,
Oct 19 2016
I would prefer to use consistent strings planned for desktop. For SHA-1: "You should not enter any sensitive information on this site (for example, passwords or credit cards), because it could be stolen by attackers." For mixed content: Attackers might be able to see the images you’re looking at on this site and trick you by modifying them. I would prefer to just use the SHA-1 string for this, since it's more conservative. WDYT?
,
Oct 20 2016
,
Oct 24 2016
Is there even a way to tell if cert uses SHA-1 on iOS? iOS implementation of net::CertVerifier uses SecTrust API which gives very limited information about the cert.
,
Oct 26 2016
,
Nov 16 2016
,
Jan 4 2017
FWIW, we previously told users and developers that we'd treat SHA-1 certificates as Mixed content: https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html Sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “affirmatively insecure”. Subresources from such domain will be treated as “active mixed content”. Given that Desktop & Android Chrome 56 block all SHA-1 certificates from public CAs behind an interstitial, I'm not sure it makes sense to invest much effort for this corner case.
,
Nov 10 2017
,
Nov 30 2017
I think this is obsolete now per SHA1 deprecation, elawrence please correct me if I'm wrong. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by lgar...@chromium.org
, Oct 19 2016