Why/User Benefit/User Problem
User Story
As a user, I want to be able to view the site certification, so I have more control and transparency over my browsing experience.
Dependencies:
- [x] #5073 initial phase
- [x] #5892 Error pages is landed
Acceptance Criteria
-I can view the certificate for each site that I browse.
vesta0
All 15 comments
@vesta0 Is there anything left to do here?
mcarare
on 2 Apr 2020
@mcarare this feature has not been built yet (can't view site certificate in mobile) but it's also not a priority for now that we have the "verified by" part in the app.
vesta0
on 3 Apr 2020
the "verified by" part
perhaps the bigger problem is when the certificate can't be verified. if trust anchors are missing, or even if your clock is wrong, you are getting the same generic message with the only option to âaccept the risk and continueâ. no certificate information whatsoever, not even any clue as to what exactly went wrong.
even more surprisingly, when you do in fact âaccept the risk and continueââwithout knowing what risk you are acceptingâthe app shows you the lock icon đ, and if you tap on it, you can see that the connection suddenly became âsecureâ and âverifiedâ... !?
...that is, if the button works at all. i've got a website that upon clicking âaccept the risks and continueâ simply displays the button again. so i have no idea what's going on there.
compare this to chrome that not only displays the certificates in all casesâeven when they can't be verifiedâbut also shows helpful messages such as âyour clock is behindâ. and it also displays a warning icon â in the toolbar instead of the lock if you decide to accept the risks.
oakkitten
on 20 Aug 2020
Hi @oakkitten,
Lots of good observations and suggestions. If there aren't already issues raised for them then I suggest you raise them separately as that's the best way to get them considered and treated.
Cheers đ
madb1lly
on 21 Aug 2020
I've had a bunch of people email me about this today. I think all the code for about:certificate is there, it just seems like it's not wired up to the UX.
april
on 26 Aug 2020
How can we get this implemented asap?
The public key infrastucture requires users are able to verify certificates, not only to trust an application handling specific tasks based on pki.
Currently firefox removed the control from the user to verify any certificate. We should not develop or release like users do not need control over basic security mechanisms or do not be able to view technical details of core www functionality.
clientenq
on 5 Sep 2020
A workaround in nightly https://twitter.com/FirefoxPreview/status/1313128741208502272
https://blog.mozilla.org/addons/2020/09/29/expanded-extension-support-in-firefox-for-android-nightly/
andreicristianpetcu
on 6 Oct 2020
A workaround in nightly https://twitter.com/FirefoxPreview/status/1313128741208502272
https://blog.mozilla.org/addons/2020/09/29/expanded-extension-support-in-firefox-for-android-nightly/
This is not working on latest stable version of Firefox for Android.
PeopleInside
on 6 Oct 2020
It works on latest Nightly version which is a good workaround for a lot of people until it gets implemented.
andreicristianpetcu
on 7 Oct 2020
Just to expand on this, in case anybody still thinks that showing "verified by" is enough for most users and this shouldn't be high priority: anybody can go out and register famouscompany.info then send phishing links to famouscompany.com users. I guarantee they'll get a cert from a trusted issuer, at least for a while.
Worse, plenty of major companies do buy and use other TLDs -- I came to this issue because Asus sent me an email with a link to asus.me. The only way to know if the site is legit is to look at the full certificate details. That's why it's absolutely critical to user security that they be able to see this:
and it's just not safe to use a browser that does not have this feature.
thw0rted
on 22 Oct 2020
@PeopleInside the fix would break other sites. There was a huge discussion in the Mozilla community about this. They said they will flip the config and break some sites once they see such issue being exploited in the wild. They are not exploited in the wild now.
It's not that Mozilla is not security focused, this is an over generalization.
Also this is super off topic for this discussion.
andreicristianpetcu
on 22 Oct 2020
The fact that Mozilla thinks that IDN homograph attacks are "super off topic" when discussing the information a browser surfaces about certificates is a huge red flag.
The story here is, "I want to click a link, then have a good idea of who owns the site I'm looking at". This is basically the fundamental principle on which web safety is built. Phishing attacks are almost exclusively possible when browsers do a bad job surfacing ownership information. My example was "popular company name" dot "other TLD", but the example of a homograph attack is also very relevant.
You know what happened when I clicked that link? My browser showed an interstitial page, asking if I intended to go to (actual) "apple.com" and not the (example) attack site. The default button was for the well-known site, and there was a less-weighted button for "Ignore" (to go to the attacks site). Know why? Because I wasn't using Firefox. Chrome took action to protect its users, Mozilla did not. On Firefox for Android, the site loads immediately, and it just says Secure Connection / Verified by Let's Encrypt, with (quite on topic for this issue!) absolutely no way to get more details.
Now, this actually isn't relevant, but just for kicks, I pasted the same link into (desktop) Firefox:
I guess it's Apple, right? Click the padlock, says "Connection Secure"; click the arrow, says "Connected to www.apple.com" and "Verified by Let's Encrypt"; click "More Information", says "www.apple.com" ("this website does not supply ownership information" is strange but no active red flags yet); click "View Certificate" and finally we actually see the punycode for the URL.
thw0rted
on 22 Oct 2020
I reported a separate bug since I think this is a different issue than the one discussed here https://github.com/mozilla-mobile/fenix/issues/16127
andreicristianpetcu
on 22 Oct 2020
This issue is not about Punnycode. While related it is a separate issue. The Fenix team is unlikely to choose a different path than Gecko/Desktop. Gecko enables internationalized domain names (IDN) for top level domains (TLDs) that have a policy to avoid mixed character attacks along with confusables. See https://wiki.mozilla.org/IDN_Display_Algorithm
kbrosnan
on 22 Oct 2020
@kbrosnan The algorithm is a good protection against homograph attacks but so is being able to take an additional action to see the "real" (punycode) name. As a user, the action I expect to use is viewing the certificate details. It's another reason why this issue should have a (high) priority assigned.
thw0rted
on 23 Oct 2020
Related issues
abodea
·
3Comments
phileastv
·
3Comments
thelazyoxymoron
·
3Comments
softvision-miralobontiu
·
3Comments
abodea
·
3Comments
Most helpful comment
perhaps the bigger problem is when the certificate can't be verified. if trust anchors are missing, or even if your clock is wrong, you are getting the same generic message with the only option to âaccept the risk and continueâ. no certificate information whatsoever, not even any clue as to what exactly went wrong.
even more surprisingly, when you do in fact âaccept the risk and continueââwithout knowing what risk you are acceptingâthe app shows you the lock icon đ, and if you tap on it, you can see that the connection suddenly became âsecureâ and âverifiedâ... !?
...that is, if the button works at all. i've got a website that upon clicking âaccept the risks and continueâ simply displays the button again. so i have no idea what's going on there.
compare this to chrome that not only displays the certificates in all casesâeven when they can't be verifiedâbut also shows helpful messages such as âyour clock is behindâ. and it also displays a warning icon â in the toolbar instead of the lock if you decide to accept the risks.