Certificate management APIs

[Stéphanie Ouillon]

Hello,

Firefox OS doesn't currently have a proper certificate manager to view,
import and revoke certificates.
Right now, there is an ErrorPage:AddCertException in Gecko which pops
out in the browser to enable the user to add an exception, but we lack
some key features:

* On Firefox OS, users can't view the certificates their phone is trusting.
* There is no manager to import or delete certificates. This is an issue
considering the history of CA's being compromised and that users want
to use self-signed certificates they control.
* In case a certificate exception has been granted, the phone needs to
be rebooted to have the exception revoked.
* Certificate exceptions granted in the browser are granted for all
installed apps.

There are a couple workarounds for importing a certificate:
* If users want to add a cert exception for one app other than the
browser, for example the email or the calendar app, they can browse to
a website using the same cert in order trigger the cert exception UI.
* Another workaround is to manually import the cert (see script attached
to bug https://bugzilla.mozilla.org/show_bug.cgi?id=919807)


So it looks like we need an API to enable managing certificates in Gaia.
The user use cases would be:
* Viewing and revoking valid certificates
* Viewing, importing and revoking invalid certificates (certificate
exceptions)
(* Viewing, importing and revoking certificate exceptions per app) ->
this use case might not apply with the security model in v3
=> the API would be used to implement a Cert Manager in the Settings app

More preliminary notes are available here:
https://etherpad.mozilla.org/certmanagement-api

I have a couple questions:
1/ We have several APIs living security/manager/ssl/public to manage
certificates. Would it be feasible to expose a subset as a web API?
2/ In Gecko, valid certificates and certificates exceptions are handled
by two different APIs, so it'll require as many web APIs.

Any comments and advice are welcomed!
Thanks,

Stéphanie

[Gervase Markham]

On 21/05/15 15:01, Stéphanie Ouillon wrote:
> So it looks like we need an API to enable managing certificates in Gaia.

Cert management UI is a golden opportunity to produce some really poor
UX. Let's try and avoid that :-)

Pulling in the community from mozilla.dev.tech.crypto may help you
refine the requirements better, although (obviously) you should focus
relentlessly on the common use cases.

Gerv

[Anders Rundgren]

You need to drop NSS in order to progress certificate support to a level where it makes sense for large scale usage.

A not fully up-to-date suggestion:
http://webpki.org/papers/PKI/certenroll-features.pdf

Anders

>
> Stéphanie

[Ehsan Akhgari]

On 2015-05-21 10:01 AM, Stéphanie Ouillon wrote:
> I have a couple questions:
> 1/ We have several APIs living security/manager/ssl/public to manage
> certificates. Would it be feasible to expose a subset as a web API?

If by "expose", you mean using the existing IDLs, then no. You'd need
to propose a new API using WebIDL. But of course, you can borrow ideas
from that API.

> 2/ In Gecko, valid certificates and certificates exceptions are handled
> by two different APIs, so it'll require as many web APIs.

I suggest focusing on the exact use cases that you would like to handle
first, and coming up with the APIs that you will need in order to solve
those use cases. Off the top of my head, I can't think of why you'd
need two separate APIs for those cases...

[Paul Theriault]

> I suggest focusing on the exact use cases that you would like to handle first, and coming up with the APIs that you will need in order to solve those use cases. Off the top of my head, I can't think of why you'd need two separate APIs for those cases…

The two main FxOS use case I think we need to solve are are:

1. The FxOS Browser needs SSL details so that it can display certificate details of the current page (and have support EV certs!). i.e. read only access to the certificate information associated with the url currently loaded inside the mozbrowser frame.

2. The FxOS settings app needs the ability to import,manage & revoke certificates. It also needs the ability to manage certificate exceptions.

My initial thought was that case might be handled by changing the browser API to somehow expose basic certificate details . (i.e. enough to display a certificate information info box, and show EV cert data in the address bar.) I was thinking something like changing the mozbrowersecurutychange event to include this information but I am not sure if that is a good or feasible approach.

The second use case though we need a more fully featured API, so as start I guess we can try to map out the exact use cases that we are trying to solve. We certainly could make an API which allows settings app to manage both certificate and exceptions, but maybe we should keep it separate from the browser use case? What do you think?

Thanks,
Paul

[Robert Kaiser]

Paul Theriault schrieb:

> The two main FxOS use case I think we need to solve are are:

I'll throw in one more use case that I think we will want to solve -
maybe not in the first round, but hopefully "soon" after:

I have my SMTP server configured so that I need to provide a client cert
to be able to send email through it - right now, there is no way that I
can put a client cert on Firefox OS and no way for me to specify it when
the SMTP server requests it, so I can't add my email account to the
email app at all.
Also, there are websites (like the StartSSL interface to validate info,
create certs, etc.) that require a client cert to get in - right now,
Firefox OS is blocked from using those websites at all due to the above.

KaiRo

[Stéphanie Ouillon]

Here is a more granular list of use cases:

* Accessing certificate information
When browsing to a website in the Firefox OS browser, users can display
the certificate details of the current page, i.e. read-only acces to the
certificate information.

* Accessing EV information
When browsing to a website in the Firefox OS browser, users see the EV
certificate information of the current page in the address bar.

* Adding a certificate exception
Users can add a certificate exception from a specified server using a
specific UI on the phone (e.g: a certificate manager in the Settings app).

* Being prompted to add a certificate exception
If an app (other than the browser, e.g. calendar or email app) connects
to a service requiring users to accept to an invalid certificate (e.g.
unknown authority), the users are shown a UI to add a new exception.

* Importing a certificate
Users import a new certificate in the phone via the certificate manager,
using a file picker to select the certificate file on the device file
system.
e.g.: users import the ZAP certificate to be able to decrypt SSL content
when they proxy their web requests through ZAP.

* Listing trusted certificates
Users can browse the list of the certificates which are trusted on their
phone and access their details: name of certificate, name of the server,
permanent or temporary status, expiration date.

* Revoking a certificate
Users revoke a trusted certificate.

On Tue, May 26, 2015 at 10:24 AM, Paul Theriault <pther...@mozilla.com>
wrote:

>
> > On 26 May 2015, at 5:27 am, Ehsan Akhgari <ehsan....@gmail.com>
> wrote:
> >
> > On 2015-05-21 10:01 AM, Stéphanie Ouillon wrote:
> >> I have a couple questions:
> >> 1/ We have several APIs living security/manager/ssl/public to manage
> >> certificates. Would it be feasible to expose a subset as a web API?
> >
> > If by "expose", you mean using the existing IDLs, then no. You'd need
> to propose a new API using WebIDL. But of course, you can borrow ideas
> from that API.
> >
> >> 2/ In Gecko, valid certificates and certificates exceptions are handled
> >> by two different APIs, so it'll require as many web APIs.
> >
> > I suggest focusing on the exact use cases that you would like to handle
> first, and coming up with the APIs that you will need in order to solve
> those use cases. Off the top of my head, I can't think of why you'd need
> two separate APIs for those cases…
>

> The two main FxOS use case I think we need to solve are are:
>

[Andrew Sutherland]

On Thu, May 28, 2015, at 03:14 AM, Stéphanie Ouillon wrote:
> * Being prompted to add a certificate exception
> If an app (other than the browser, e.g. calendar or email app) connects
> to a service requiring users to accept to an invalid certificate (e.g.
> unknown authority), the users are shown a UI to add a new exception.

Note that this is a dangerous UX flow to optimize for and for the email
app we've been resisting any calls for the email app to make it easier
to do this on https://bugzilla.mozilla.org/show_bug.cgi?id=874346.

While there are mitigations (discussed on the bug), in general it seems
preferable to concentrate engineering efforts on making it easier to
obtain and configure valid certificates (a la Let's Encrypt), or to help
users switch to email providers who take security/privacy remotely
seriously.

Which is to say, I don't think there should be *any* means of prompting
the user to directly add a certificate exception (although the user
should absolutely be able to manually add one by going in through the
settings app). Without additional engineering effort, all certificate
exceptions are device-wide. One app making the ill-conceived call to
easily enable certificate exceptions potentially enables attacks against
the user in all apps.

Andrew

[Andrew Sutherland]

On Thu, May 28, 2015, at 12:31 PM, Christiane Ruetten wrote:

> On 28/05/2015 17:46, Andrew Sutherland wrote:
> > While there are mitigations (discussed on the bug), in general it seems
> > preferable to concentrate engineering efforts on making it easier to
> > obtain and configure valid certificates (a la Let's Encrypt), or to help
> > users switch to email providers who take security/privacy remotely
> > seriously.
>

> I would strongly object to this line of argument. In terms of SSL, the
> perhaps most serious way of doing e-mail is via a small, privately-run
> server with a self-signed CA that's pinned in the client.
>
> Helping users who consciously choose such an e-mail setup over to a less
> secure or less privacy-assuring solution – which unfortunately includes
> Let's Encrypt – does not seem like the right signal to send.
>
> So I would not only call for engineering effort for proper certificate
> management through the settings (I agree that ad-hoc prompting is
> somewhat dangerous), but also for configurable pinning of CAs to certain
> servers, and for alerting the user whenever that CA spontaneously
> changes on the server side.

I think we may actually be in agreement and I was too terse, leading you
to think I was saying something I was not. My statement was
specifically referring to mitigations discussed on the bug for the
"ad-hoc" prompting scenario. The ambiguity when we receive an invalid
certificate is whether:
1) The server just has a self-signed / otherwise invalid certificate.
2) The user is under attack.

A specific mitigation would be to have the Thunderbird ISPDB/a web
service either statically or dynamically indicate: "Yeah, I'm seeing the
same invalid certificate for that domain too" or "oh yeah, this server
has been showing this invalid certificate for a long time, so I guess
it's okay". The same mechanism would also need to be used if the
apparent certificate used by the server changed. Allocating engineering
effort to this end is basically creating a second ad-hoc trust
infrastructure.

CA and/or certificate pinning seems quite reasonable and indeed will
provided additional security and confidence, but is a separate issue
from prompting to add exceptions.

I do think it's reasonable to say that if a user wants to add a
certificate exception, pinned CA, or pinned certificate, that it should
be done explicitly through the settings UI. It need not be arduous, but
it's still not appropriate to do the prompting scenario because of the
ambiguity of the "Hey, this is either an attacker or your actual mail
server" situation, and that for most users any dialog is going to be
viewed as a "Hey, do you want your mail or not?" that they're just going
to click through.

Andrew

[Eric Rescorla]

On Thu, May 28, 2015 at 9:31 AM, Christiane Ruetten <c...@mozilla.com> wrote:

> On 28/05/2015 17:46, Andrew Sutherland wrote:
> > While there are mitigations (discussed on the bug), in general it seems
> > preferable to concentrate engineering efforts on making it easier to
> > obtain and configure valid certificates (a la Let's Encrypt), or to help
> > users switch to email providers who take security/privacy remotely
> > seriously.
>
> I would strongly object to this line of argument. In terms of SSL, the
> perhaps most serious way of doing e-mail is via a small, privately-run
> server with a self-signed CA that's pinned in the client.
>
> Helping users who consciously choose such an e-mail setup over to a less
> secure or less privacy-assuring solution – which unfortunately includes
> Let's Encrypt – does not seem like the right signal to send.
>

These statements seem like they need some support. I'm not at all convinced
that as a practical matter doing email with a self-signed CA is more secure,
since you have to then manage it and there's lots of things that can go
wrong
there. Do you have any data to support this?

-Ekr

So I would not only call for engineering effort for proper certificate
> management through the settings (I agree that ad-hoc prompting is
> somewhat dangerous), but also for configurable pinning of CAs to certain
> servers, and for alerting the user whenever that CA spontaneously
> changes on the server side.
>
>

> --
>
> Christiane Ruetten
> Mobile Malware Specialist
> Firefox OS Security
>
>
> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
>
>

[Eric Rescorla]

On Thu, May 28, 2015 at 3:43 PM, Christiane Ruetten <c...@mozilla.com> wrote:

> On 28/05/2015 19:46, Eric Rescorla wrote:
> > I would strongly object to this line of argument. In terms of SSL,
> the
> > perhaps most serious way of doing e-mail is via a small,
> privately-run
> > server with a self-signed CA that's pinned in the client.
> >
> > Helping users who consciously choose such an e-mail setup over to a
> less
> > secure or less privacy-assuring solution – which unfortunately
> includes
> > Let's Encrypt – does not seem like the right signal to send.
> >
> >
> > These statements seem like they need some support. I'm not at all
> convinced
> > that as a practical matter doing email with a self-signed CA is more
> secure,
> > since you have to then manage it and there's lots of things that can go
> > wrong
> > there. Do you have any data to support this?
>

> Reports about compromised and cooperative CAs are numerous, but I don't
> think there is a way to collect hard data about self-signed CA use for a
> meaningful comparison.
>
> Though my argument was mostly technical to begin with. I was asserting a
> carefully instructed or technically skilled user, as well as a skilled
> server admin, ruling out config error.
>

Neither of these seems like reasonable assumptions.



> Under this assumption the key argument is that CA/cert-pinned private
> server connections are not vulnerable to SSL MITM by means of one
> compromised or cooperative CA, while all major e-mail services are.
>

This seems like an unfair comparison, since you can also pin certificates
by ordinary
CAs.

-Ekr




That being said, a client warning of unexpected CA/cert changes would
> already provide a good mitigation for those who care.

[Paul Theriault]

Can we bring this discussion back to Stephanie’s use cases? I’ve removed the “prompt for certificate exception” use case for now based on Andrew's points above - I agree that its not a UX we would like to encourage, and that the use of self-signed certs can be handled by explicitly by installing your own cert via the settings app. Maybe we can investigate this use case after we get the basics implemented. My main goal here is achieving parity with Firefox desktop.

The question I have, is whether we should try to augment the browser API or create a whole new API - currently it looks like we will need both. I assume that for the use cases which require read-only access to certificate data associated with the current page, that augmenting the Browser API will be enough. And I assume that ultimately we will need a higher privileged API for modifying the certificate store.

Unless I hear otherwise, we’ll start investigating this approach. (see also https://bugzilla.mozilla.org/show_bug.cgi?id=b2g-ssl <https://bugzilla.mozilla.org/show_bug.cgi?id=b2g-ssl>)

Thanks,
Paul


=== Use Cases ===
== Read Only access to certs ==

* Accessing certificate information
When browsing to a website in the Firefox OS browser, users can display the certificate details of the current page, i.e. read-only acces to the certificate information.

* Accessing EV information
When browsing to a website in the Firefox OS browser, users see the EV certificate information of the current page in the address bar.

== Requires cert db changes ==

* Adding a certificate exception
Users can add a certificate exception from a specified server using a specific UI on the phone (e.g: a certificate manager in the Settings app).

[Robert Kaiser]

Paul Theriault schrieb:

> Can we bring this discussion back to Stephanie’s use cases?

Can we add a use case "(Prompt for and) send a client certificate - when
requested by< the connection"?
I know that client certs are not in use too much but where they are, we
should provide a way to send them. The prompting is a UX choice that we
made in Firefox desktop, but I think a prudent one as the user should
know when they are personally authenticating with the site.

KaiRo

[Andrew Sutherland]

On Fri, May 29, 2015, at 08:57 AM, Robert Kaiser wrote:
> Paul Theriault schrieb:

> > Can we bring this discussion back to Stephanie’s use cases?
>

> Can we add a use case "(Prompt for and) send a client certificate - when
> requested by< the connection"?

I don't think there's a standard for XMLHttpRequest to indicate that a
client certificate is intended to be used. https://xhr.spec.whatwg.org/
does mention client certificates as part of its definition of "user
credentials", but it seems a lot like the assumption is that the
certificate will be bound to the host with the
nsClientAuthRememberService
(https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsClientAuthRemember.h)
before an XMLHttpRequest would ever be made that depends on it.

Similarly, although TCPSocket is currently a Mozilla-specific API, the
standardization effort at https://github.com/sysapps/tcp-udp-sockets
does not discuss client certificates, nor does the Chrome API at
https://developer.chrome.com/apps/sockets_tcp we could potentially
converge to.

> I know that client certs are not in use too much but where they are, we
> should provide a way to send them. The prompting is a UX choice that we
> made in Firefox desktop, but I think a prudent one as the user should
> know when they are personally authenticating with the site.

I 100% agree that we don't want to tell servers that request client
certificates all the certificates the user has. That's a major privacy
problem.

I don't think prompt-on-request is the right flow for XHR/TCPSocket,
which I think is the request here. (It makes sense if we're talking
about your email server.) I think it would make sense to have the
settings UI make it possible to cause a client certificate to be
associated with a specific origin using the aforementioned
nsClientAuthRememberService.

I see no reason why this UI couldn't be specifically triggered by a web
activity. The email app could expose a button in the manual
configuration flow to this end. If TCPSocket were capable of expressing
that the server wanted a client certificate in its errors, a button
could even be displayed when the error occurs. (Noting that the bug
would probably be considered rather low priority and would probably need
a contributor to step up to implement this after they enhanced
TCPSocket.) Note that I don't believe XMLHttpRequest returns
usable/fine-grained security errors at all, and TCPSocket's were a hack
I added
(https://dxr.mozilla.org/mozilla-central/source/dom/network/TCPSocket.js?from=tcpsocket.js#788).

Andrew

[Robert Kaiser]

Andrew Sutherland schrieb:

> I don't think prompt-on-request is the right flow for XHR/TCPSocket,
> which I think is the request here. (It makes sense if we're talking
> about your email server.)

I was talking about those cases in addition to the case of going to a
website that asks for a client cert to log in (StartSSL Control Panel
for example).

But yes, XHR and TCPSocket are probably harder to handle there than the
"normal" website case.

KaiRo