Closed Bug 1189110 Opened 9 years ago Closed 2 years ago

Firefox can't access HTTPS sites on a "Child" account

Categories

(Firefox :: General, defect, P3)

39 Branch
All
Windows 10
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: tdowner, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

When using an account with parental control enabled, Firefox can't access many HTTPS sites (Facebook, youtube, etc.) due to sec_error_unknown_issuer. 

STR:
1. Create a Windows 10 user account set to "Child"
2. Log into that account
3. Using Firefox, try to navigate to https://www.facebook.com
4. Fail

Edge loads Facebook with no problem.

This is a fairly significant source of feedback on input without an easily seen workaround.

Tested with 39 and Nightly
See also bug 1067174, regarding the same on Windows 8.
it is possible to work around that by following the (probably too complicated for most users) instructions of the "Known issues for Firefox users" on this windows 8 help page: https://support.microsoft.com/en-us/kb/2965142 

https://support.mozilla.org/questions/1075257
So the Microsoft Family Safety essentially MITM's connections and the work-around to the user-facing issue is to import their certificate in to the Firefox certificate store so that the MITM will not get interrupted?

I believe this is similar to how a lot of antivirus and security software works.

Should Firefox take care of importing this certificate?
Flags: needinfo?(dveditz)
In lieu of that / in the short term, a cert error page specifically for this case would be helpful for users to at least understand what is happening.

I feel like we should be very very careful about starting down the path of automatically integrating with MITM "features". Family Safety might be "good" (think of the children!), but there's a whole spectrum of dubiousness between it, antivirus software, corporate firewalls, government mandated filtering, and SuperFish.
I agree with Dolske's caution and suspect we should NOT automatically import it.
Tossing the needinfo to Richard, this is his area.
Flags: needinfo?(dveditz) → needinfo?(rlb)
It's a shame Mozilla is treating this not as a bug, but as an intentional decision not to work with Microsoft Family Safety. Lots of users want Family Safety to function and it is not Mozilla's place to try to hobble it. I've been a long-time Firefox advocate since even before 2.0, but I'm afraid this is where Mozilla and I part ways.

I've walked so many users through the Windows 8.1 workaround (manually importing the certificate) that I can practically do it in my sleep, but unfortunately I haven't been able to successfully import the certificate on any Windows 10 system. Now when people ask me why Firefox won't work in their kids' accounts in Windows 10, I have to tell them the workaround is to switch to Chrome.
I agree with the sentiment of comment #8 and I think it is unfair to make a leap from Microsoft Family Safety to SuperFish and other secretive/possibly nefarious attempts.

We need Firefox to be usable in more environments, and showing a specialized error page doesn't make it any more usable than it is today. People will still switch browsers regardless of how descriptive our error page is.

Specific to Microsoft Family Safety, this is an issue of pragmatism that we need to be realistic about. It is not developed as an advertising or malware vector.
Would it be worth considering as a workaround.
Showing a more informative error message as already suggested.
Documenting the issue on the support.mozilla Knowledge Base.
Link the KB article from the error message.

That would allow users to consider the available solutions and make an informed choice.
It would avoid any automated security compromises.
It would educate users that this is a known issue and is because of the use of MS Family Safety.
(In reply to (spotty availability 8/7 and 8/10) Jared Wein [:jaws] (please needinfo? me) from comment #9)
> I agree with the sentiment of comment #8 and I think it is unfair to make a
> leap from Microsoft Family Safety to SuperFish and other secretive/possibly
> nefarious attempts.

It's not so much a leap as a lack of a clear, bright line. Fundamentally, these are all enabling 3rd-party MITM interceptions between the user and the website, and we should carefully consider to what degree that means automatically integrating with such features when available. It's also our responsibility to ensure this doesn't violate user expectations when Firefox says the connection is secure. [For example: Is the cert system-specific, or global? Would this enable a vector where a malicious MITM could use it? Should Firefox downgrade its indicators when it is being used? What exactly is happening with intercepted content? If we do this for Microsoft, should we do it for a Cisco firewall in a corporate environment? How about at Starbucks free Wifi?]

> We need Firefox to be usable in more environments, and showing a specialized
> error page doesn't make it any more usable than it is today.

My suggestion was that an error page may be the fastest way to do _something_ here.

No decision has yet been made about supporting it or not -- we just shouldn't rush into a decision.

rbarnes is NI'd, and a trust he'll make an informed recommendation as to what we should do.
This link is a bit inflammatory (http://boingboing.net/2015/08/10/windows-10-automatically-spies.html), but seems to imply that child account usage ends up being sent to Microsoft where activity reports are being generated? Would be interesting to know if that's actually the case, and if the SSL MITM proxy is part of that.
yes it is. that's described in the ms knowledge base article i've linked to before:

> The Family Safety tool provides activity reports that show parents 
> the search terms that their children enter when they use a search engine 
> (...) Currently, some search engine sites require that web browser 
> connections to their sites use encryption, and this prevents some of these 
> search engine safety features from being implemented. After the Family Safety 
> update is installed, Windows 8.1 and Windows RT 8.1 users can continue to use 
> these search engine safety features. 

https://support.microsoft.com/en-us/kb/2965142
TL;DR
We’ve done some thinking and design around this topic:
https://wiki.mozilla.org/Security/Foreign_Certificate_Warning


Long answer

My opinion reflects comment #8 and #9:
 
> We need Firefox to be usable in more environments, and showing a specialized
> error page doesn't make it any more usable than it is today. People will
> still switch browsers regardless of how descriptive our error page is.

Today, Firefox really cannot afford people switching away from it. So being pragmatic seems to be a good way to go, right?

However, I do recognise that MITM presents itself in many ways, and not everything is malicious. Some examples:
* Parental filter (what this bug is about)
* Antivirus products
* Corporate surveillance
* Debugging
* Malwares (like Superfish)

Our job shouldn’t be to interrupt user in getting their job done. Instead, it should be to inform them that their connection is being monitored. Our message to them should be “Just so you know, your connection is being monitored by [vendor_name].”

The implications are twofold:
* “If the name looks suspicious, you should try to remove it, or ask other people about it”
* “If the name looks okay (like the Family Safety Tool, or your company’s monitoring software), then don’t worry about it.”

We only show an information page when user wants it. Maybe they’re wondering “Is this vendor legit? How can I tell the good ones from the bad? Is there a database of good and bad vendors?” – that’s a place for this page.

But we should always open the page that users want to access straight away, without interruption.
This is a tough one.  I'm not seeing an obviously optimal solution.  I've sent an email to some MS networking people to try to discuss.

In the short run, it's tempting to say that we should make it easier for users to install the necessary root.  I'm worried about the precedent that this sets though -- since we still allow drive-by certificate installation whenever Firefox encounters something of type "application/x-x509-ca-cert", it seems like training users to install a cert to make things work creates phishing risk.  

Jorge, Lawrence: Could you advise on what the operational boundaries are here?  It seems like if HTTPS is broken, then a number of the normal solutions are off the table.  For example, AMO is only available over HTTPS, so we can't expect the user to install an add-on from that channel.  IIRC, Firefox updates go over HTTP (relying on package signing), so maybe we could still use that channel?  Do hotfixes also go over this channel?  

Tyler: Does this attack have a clear signature?  That is, can we clearly recognize when breakage is due to this particular MS product?  For example, by looking at what CA certificate was in the chain presented by the server.  That seems like a pre-requisite to us being able to take action.
Flags: needinfo?(tdowner)
Flags: needinfo?(rlb)
Flags: needinfo?(lmandel)
Flags: needinfo?(jorge)
(In reply to Richard Barnes [:rbarnes] from comment #16)
> IIRC,
> Firefox updates go over HTTP (relying on package signing), so maybe we could
> still use that channel?  Do hotfixes also go over this channel?  

Firefox updates are served over HTTP, but they're verified by checking against a hash returned from the update check that's performed over HTTPS. I'd expect updates and hotfixes to fail as a result of this. :/ Further, I believe these certs are all specially pinned due to their sensitivity.
Dolske handled my ni.
Flags: needinfo?(lmandel)
For users, this is not a clear attack, as these same symptoms are caused by Avast anti-virus, etc. As for recognizing programmatically, I'm not sure if that is possible. Probably other people are better qualified to answer that.
Flags: needinfo?(tdowner)
AMO is HTTPS-only, as far as I know, so we couldn't use it for that. Dolske already covered the Hotfix.
Flags: needinfo?(jorge)
afaik the ms family safety filter only man-in-the-middles major search/content/social networking sites like google, facebook, youtube and others and not all https connections.
attached is the cert that they are using for this purpose...
(In reply to Richard Barnes [:rbarnes] from comment #16)
> This is a tough one.  I'm not seeing an obviously optimal solution.  I've
> sent an email to some MS networking people to try to discuss.
> 
> In the short run, it's tempting to say that we should make it easier for
> users to install the necessary root.  I'm worried about the precedent that
> this sets though -- since we still allow drive-by certificate installation
> whenever Firefox encounters something of type "application/x-x509-ca-cert",
> it seems like training users to install a cert to make things work creates
> phishing risk.  

I absolutely agree that we shouldn't train users to say yes to obscure certificate installation prompts. In fact, there should be no user action required and they could just use their browser normally, regardless of family safety mode being on or off.

If we feel the need for some kind of messaging, we could do that in different, more ambient ways that don't require user interaction.
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3

I was unable to replicate this on windows 10 using firefox nightly 97.0a1
when creating a child account and using it, it asked me for autorization to use firefox.

Entered on the parent account, authorized firefox, then went back to the child account, and i was able to enter firefox and facebook without problems.

resolving issues since original reporter has a disabled account

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: