Re: Draft finding - "Transitioning the Web to HTTPS"

Mark Nottingham writes:
> To the latter point -- I still find it remarkable that this is
> extremely common practice:
>    http://ist.mit.edu/certificates
> ... and the OS/browser UX doesn't warn the user of the power granted
> by doing so (last I checked).

here's what it says [1]:
<!ENTITY downloadCert.title "Downloading Certificate">
<!ENTITY downloadCert.message1 "You have been asked to trust a new
Certificate Authority (CA).">
<!ENTITY downloadCert.trustSSL "Trust this CA to identify websites.">
<!ENTITY downloadCert.trustEmail "Trust this CA to identify email users.">
<!ENTITY downloadCert.trustObjSign "Trust this CA to identify software
developers.">
<!ENTITY downloadCert.message3 "Before trusting this CA for any
purpose, you should examine its certificate and its policy and
procedures (if available).">
<!ENTITY downloadCert.viewCert.label "View">
<!ENTITY downloadCert.viewCert.text "Examine CA certificate">


Henry S. Thompson wrote:
> I'll bite -- what _should_ the UX say?

1. it should have a Help / tell me more button.
2. it should have a red icon not weaker than the icon used for self
signed certificates [2] -- today it's just an iconless sheet

> That is, what _is_ the risk

The risk is that anyone with access to the MIT CA server can
impersonate any (* except for a tiny pinned list) secure server
reachable by your browser.

> (and what is the alternative that MIT should be using)?

First, the server documenting installing the certificate [3] should
use HSTS -- the certificate itself is served via via https (and it is
[4]),
Second, the certificate should include CA:NameConstraints [5] -- which
isn't really available today, but see below.

> The alternative an entity not a million miles away from my desk
> uses is to just self-sign and expect us to click through the resulting
> warnings. . .

Ideally (and maybe I'll see about offering it), the UI for adding a CA
could offer to restrict the CA to some set [6], non-FQDN, ccTLD,
domain. For mit.edu, I think I could make a pretty reasonable default
option (favoring non-FQDN only for .crt files served via non-FQDN,
selecting a domain based on Public Suffix [7] otherwise.

This should make users safer for most cases out of the box.
Done /slightly/ right, if two domains (example.com, and example.net)
serve the same .crt file, the browser would essentially let the user
extend their web of trust for example-ca from *.example.com to
*.example.com+*.example.net

[1] http://mxr.mozilla.org/mozilla-central/source/security/manager/locales/en-US/chrome/pippki/pippki.dtd#20
[2] https://bug327181.bugzilla.mozilla.org/attachment.cgi?id=212595
[3] https://ist.mit.edu/certificates
[4] https://ca.mit.edu/mitca.crt
[5] https://wiki.mozilla.org/CA:NameConstraints
[6] https://lists.w3.org/Archives/Public/www-tag/2015Jun/0006.html
[7] https://publicsuffix.org/list/

Received on Sunday, 14 June 2015 17:39:10 UTC