This is targetted for M7, but can take one of two very different approaches: 1) Expose the PSM cert manager or some derivative of it. This is easy enough, manually launching it works as expected, just a question of finding a good hook for it (preferences, probably). 2) Build a PKCS#12 module to tie us into the phone's cert store. I really don't think we'd want to call it "Firefox" if it allowed arbitrary certs from a given phone vendor, but we could look at some way to combine things there. Writing that kind of code is not really my bailiwick - if we go that way I think I'd want to pull doug (or bob relyea) in to see how best to approach that. There is arguably a madhava decision here in terms of prioritization - I could accept the argument that a 1.0 browser does not need to emphasize this kind of technology, and that access to PSM's cert manager via preferences is "good enough." Given the uncertainty, I'm not sure this is M7 material, nor do I think it really needs to block that milestone. It needs to be in final, and it should be in before we go to betas arguably, but before that, it feels like development here doesn't block anything else, except maybe bug 437372, and there only kind-of.
Madhava and I had a discussion about this the other day, because this is a potentially broad topic. There are really four kinds of certs that we might care about: 1) Regular SSL certs. These make the secure internet go, but don't need any management per se. They are exposed via the Larry identity UI. 2) CA certs. Managing CA certs is something that a small-- but non-zero -- number of people do - either removing trust from ones they consider inadequate/suspect, or more often installing new ones for their corporate intranet. 3) SSL Exceptions. The new PSM ssl error pages cause all gecko 1.9 based browsers to have to solve the question of what to do with invalid or broken certificates. In Firefox 3 we handle this by letting users add "exceptions", and managing those is something that users might legitimately want/need to do. 4) Client certificates. In north america we don't think about these much but in several european and asian countries they are de rigeur. There are certain important web-based things like interacting with the government or doing banking that simply assume you have the ability to present a client certificate, and may or may not have any fallbacks. This is something we really need to handle. There are also a couple approaches we can take in terms of the management infrastructure we expose, which I outline in comment 1. In discussion with Madhava, we really focused on the key use cases we care about supporting, which left us with: - We need a way to add SSL exceptions, but not necessarily a way to manage them. That's controversial and will absolutely paint us into some tough spots (what happens when my wireless router changes its cert after a reboot and I need to remove the old exception?) but if we make the product call that that is not a thing we decide to support in 1.0, I can understand that. - We need a way to add client certs, and present them in web interactions, but not necessarily a way to manage them. The mechanisms for adding them over the web and presenting them to sites already exist in our platform, though again the UI is not at all mobile-friendly. Figuring out how to install them from other sources might take us back to the idea of hooking into the device store, but as I mention in comment 1, writing PKCS#12 drivers is way outside my area of expertise. - CA management is indisputably useful, but not a top-tier use case for the 1.0 browser. Obviously - this list of decisions means a lot of security UI on the cutting room floor, and if we go this route, it will mean a lot of pushback from people in the security community and the corporate community who will want to know why typical Firefox features aren't available in our mobile product. On the other hand though, I absolutely understand and support the argument that, as a matter of principle, shipping a 1.0 product means making cuts, and I can't realistically argue that time be taken off of things like panning/zooming performance or implementing a location bar in order to write a mobile-friendly CA cert management interface. I think, then, that this bug nets out to a couple things: - We need to re-evaluate the client cert UI. This has been true for some time in Firefox, but it's not clear whether we need a custom UI for Fennec, or whether instead we should just focus on making the PSM one better in time for us to pick it up here. I'm leaning towards the latter, but I won't be able to size that work until I get back from vacation. If we go that way, we should open a bug against PSM for the work, which this one can reference. - We need to decide if we want to hook into the device's cert store. This is a bit controversial in parts, because we don't like to ship things called "Firefox" that have arbitrary additions to their cert DB, which is one possible outcome of hooking into the device. We could step carefully, only pull in the client certs, but not the CA certs - I think some version of this should happen - but someone like dougt is in a better position to comment on feasibility and scope than I am.
I ran into this issue while running a test case: https:/verisign.com. What is confusing is that the fennec UI indicated the ability to add an exception, but when trying to do so, there was no way and I was hosed (required a reboot to close down fennec). Here is what happens: - invalid cert (dialog popup): - details - cancel - view details (another dialog popup): - two tabs with info - no buttons to add exception - no buttons to cancel/ok - no way to close dialog - fennec "X" button does not close fennec This is a bad experience for an end user.
What Joel reports here sounds like he's seeing the PSM dialogs instead of the error page, which suggests that Fennec may need to port the work done in bug 453442, if it too is auto-fetching favicons even on error pages. That's a different bug than this one, though, so I would recommend Joel file a new one.
Resetting assignee since I'm not currently working on this.
Assignee: johnath → nobody
Regarding the client-cert UI, some design work here: https://wiki.mozilla.org/Mobile/UI/Designs/TouchScreen/workingUI#Client_Certificates
Subdividing this bug for (a) Client-side certificates (now in bug 478938) and (b) dealing with expired certificates (bug 478940)
tracking-fennec: --- → ?
since all bugs related have been duped to this bug, i want to make sure the fix for this will allow us to add a permanent exception rather than just the one time exception that we are supporting for 1.0. There is a button on the page for this functionality, but as of now it does nothing
The "untrusted connection" error page has support for temporary and permanent cert exceptions. closing this bug.
Status: NEW → RESOLVED
tracking-fennec: 6+ → -
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
I'm sorry to resurrect this bug, but it still isn't resolved. I think it's possible that :mfinkle misunderstood the problem. Adding a temporary/permanent cert exception is still vulnerable to MITM attacks during the first certificate transfer. Basically, there is no way to know if we are adding a permanent exception for the server you want, or another server impersonating it. This is why it's important to have the option to import the certificate file manually. The file is added to your Android device by a trusted party (IT admin, yourself, etc), and then imported in Firefox. Firefox desktop has this function, most desktop OSs have this function, and so does Android (Settings/Security/Install from storage).
This doesn't work, definitely it is not resolved. There is still no way to import a client certificate that is sometimes needed to access e.g. corporate websites.
tracking-fennec: - → ---
This bug is not valid. It is in the graveyard area of bugzilla for products that are not developed any more. All the bugs filed against XUL Fennec were moved here before the native Android UI rewrite in 2011.
You need to log in before you can comment on or make changes to this bug.