1332853 - Insecure login hint on an HTTPS page

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect, P3)

Description

[Benjamin Bouvier [:bbouvier] (inactive)]

There's a form to log in to your user account (in French, sorry): https://assure.ameli.fr/PortailAS/appmanager/PortailAS/assure?_somtc=true

The "connection is not secure" panel appears under the identifier field, although the web page is using HTTPS. Is that expected?

Comment 1

[Matthew N. [:MattN]]

Hi Benjamin,

There are three things we currently look at when determining if a login form is insecure:
1) Whether the document and all ancestor documents are on HTTPS
2) Whether the form @action indicates it will submit to HTTPS
3) Whether the window.opener is secure. window.opener can refer to the browsing context of whatever opened the tab, not what loaded the origin. We are going to remove this check in bug 1329940 because it's too hard to explain to users and devs and there's not enough awareness about this problem with web developers.

I suspect you're seeing #2 or #3. Can you evaluate `window.opener` in the web console when you see the issue and check that it's not HTTPS to confirm you're seeing #3 and if so, dupe to that bug.

Thanks

Comment 2

[Benjamin Bouvier [:bbouvier] (inactive)]

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #1)
> 3) Whether the window.opener is secure. window.opener can refer to the
> browsing context of whatever opened the tab, not what loaded the origin. We
> are going to remove this check in bug 1329940 because it's too hard to
> explain to users and devs and there's not enough awareness about this
> problem with web developers.

This is exactly #3: I was browsing http://ameli.fr, which has the link to the connection page on the right. Opening the page from bugzilla doesn't show the insecure warning, but opening from http://ameli.fr does (and confirmed that on the https page, window.opener is http://ameli.fr and thus uses an insecure context).

Thanks for explaining the reasons that make the insecure form warning appear. I think this bug is good to be duped now, unless it could be moved to web evangelism? It seems important that this web site be fixed, since this is a government web site to access one's medical files.

Comment 3

[Benjamin Bouvier [:bbouvier] (inactive)]

cc'ing Karl who might know people working at CNAM :)

Comment 4

[Matthew N. [:MattN]]

There are a few potential fixes:
1) use @rel="noopener" on links from HTTP to HTTPS (though this doesn't fix third-party inbound links)
2) Use HTTPS on the whole site (also doesn't help with inbound links)
3) Run `window.opener = null` ASAP on secure pages (supposedly this will give an error of window.opener is cross-origin on Safari). Note that this won't change the computed value of window.isSecureContext but does add some protection.
4) There is talk of a CSP header at https://github.com/w3c/webappsec/issues/139 that would allow the secure pages to be disowned but I don't think it's implemented anywhere yet.

So basically until we get (4) there is no perfect solution which is part of why aren't going to use it when deciding to show the warning.

Comment 5

[Oana Arbuzov [:oanaarbuzov]]

@Benjamin can you still reproduce the issue? 
For me both "Registration" and "Login" page are secure.

[Tested with:]
Browser / Version: Firefox Nightly 64.0a1 (2018-09-19)
Operating System: Windows 10 Pro

Comment 6

[Benjamin Bouvier [:bbouvier] (inactive)]

No, they solved it on their side, thanks for checking.