Neat. In tablet mode, the (i) icon is shown and says "Your connection to this site is not secure" when clicked, suggesting that we think we're in SecurityLevel::None instead of SecurityLevel::Secure. 

Similarly, if you use https://badssl.com/certs/ca-untrusted-root.crt, you see that we get the expected /!\ strikethrough behavior in the omnibox on the interstitial, but if you click through it, the warnings vanish and are replaced with the (i). Fortunately, this fails closed, as the page always shows "Download failed/Retry", and retry always fails too.

It appears that downloads on iOS work by catching an "unhandled content" error from the webview, removing the webview, and creating a native object UI to put in its place: https://cs.chromium.org/chromium/src/ios/web/web_state/ui/crw_web_controller.mm?l=3068&rcl=54fd9d1c6acceb8bbcd7e5dad595208ef281c917

Lucas, does this really warrant being view restricted?

Marking sev low out of an abundance of caution; showing something as less secure is usually a functional bug (but would be a security bug if it were the other way around).

WKWebView does not provide API to examine certificate for responses which were not rendered in web view. So ios/web can not set NavigationItem::SSLStatus for Download navigation item. 

We plan to refactor downloads code, so navigation item is not created. It will fix ios/web bug, but will not solve the UX problem. Lucas, given that there is no way to obtain SSL certificate for download item, how do you think the UI should look like?

Well, the UI should really show whether the download is secure. :-/
Right now, the UI strongly implies that it's *not* secure, and the user can't even check why.

Is there *any* way to tell if Chrome enters a download page for a secure URL vs. insecure?
Is it possible to block downloads from domains with insecure certificates, so that you can assume that HTTPS downloads are secure?
(It's okay if Page Info gives less information in this case, as long as it is correct.)

[1] And always be making Page Info accessible from the menu, but I'm losing hope on Issue 533581.

>> Is there *any* way to tell if Chrome enters a download page for a secure URL vs. insecure?
No. It is possible to tell if Chrome is about to navigate to insecure URL (before navigation has started). It is possible to tell if url is a download URL (after navigation has started, but before it is committed). But this information is provided in 2 different callbacks and there is no way to inspect the certificate in the second callback. Cashing cert in the first callback is not possible because of specific WKWebView limitations (no way to tell if first and second callbacks belong to the same navigation).

>> Is it possible to block downloads from domains with insecure certificates, so that you can assume that HTTPS downloads are secure?
No. Load/No-load decision callback is called during TLS handshake and there is no way to tell there if the URL will be a download URL.

I don't think that Desktop or Android show download URL, so maybe we should just change download UI on iOS in the way that it does no show URL and/or lock?

>> Is it possible to block downloads from domains with insecure certificates, so that you can assume that HTTPS downloads are secure?
>No. Load/No-load decision callback is called during TLS handshake and there is no way to tell there if the URL will be a download URL.

As I noted in #2, even after you click through a HTTPS interstitial to allow navigation, it appears that the download is blocked. Is the block not always present?

I did not see interstitial when I load https://badssl.com/certs/ca-untrusted-root.crt. Also I was able to download that file successfully. Please note that Chrome for iOS starts download only after DOWNLOAD button is tapped.

I use iOS 10.3.3, iPhone SE. I don't understand what does "download is blocked" mean in this context.

To attempt to download the file with over an invalid HTTPS connection, use  e.g. https://expired.badssl.com/certs/ca-untrusted-root.crt

After you click through the interstitial, you'll get a "Download failed" page with a red background. No matter how many times you click the "Retry" button, the download does not succeed.

Thanks! I guess by default URLFetcher does not accept bad certificates, which explains the current behavior. What's interesting is that URLFetcher's response code is -1 and status is OK. If we could tell that failure is caused by SSL error, then we could update NavigationItem::SSLStatus inside -[DonwloadManagerController onHeadFetchComplete]. That's pretty ugly hack, which will stop working when we move to new Download API: https://docs.google.com/document/d/1rfbN4RhKWthdbjs8HhQtc1tDj3letzVub0-BOZeCR1c/edit#heading=h.5ugemo7p04z9

Reclassifying as a non-security issue, as this doesn't represent a vulnerability.

New UI does not show URL anymore.