Ticket #1389 (closed defect: fixed)

Opened 8 years ago

Last modified 5 years ago

Remove MIT CA from global trust store

Reported by: geofft Owned by:
Priority: high Milestone: Summer 2014
Component: -- Keywords:
Cc: Fixed in version: debathena-ssl-certificates 1.6-0debathena2
Upstream bug:

Description

It's been more than a year since mitcert started issuing certs via InCommon/Internet2 (an intermediate via the well-known AddTrust root), instead of via the MIT CA. I believe this means that all MIT CA-signed certs are now expired, although I haven't checked. If this is the case, we no longer need to ship the MIT CA and configure it in the system trust store.

Chrome / Chromium now has a  certificate authority pinning feature, where several high-risk sites (Google, Twitter, Tor,  etc.) are restricted in which CAs are allowed to sign them. As that article points out, any locally-configured CAs are also permitted, since Chrome can't distinguish private CAs like MIT's from semi-legitimate SSL MITM proxies. This effectively means that the MIT CA is permitted to MITM these high-traffic sites, meaning that including the MIT CA is a security risk (it could get stolen or otherwise misused) for zero security benefit (if there are no unexpired MIT CA-signed certs).

Change History

comment:1 Changed 8 years ago by geofft

Hm, just in case it wasn't obvious, in other browsers and for the sites not pinned by Chrome, including the MIT CA is also a risk. My point is that local inclusion of the MIT CA defeats special protections in Chrome for these high-risk sites, in addition to being a security risk for SSL usage in general.

comment:2 Changed 8 years ago by achernya

As per Zephyr, Scripts got its first InCommon? certificate on May 29, 2012 (committed June 6, 2012). Assuming all MIT CA certificates are only 1 year, there cannot be MIT CA certs that are valid left.

comment:3 Changed 8 years ago by davidben

I assume mitcert can answer this question definitively, since they have a record of every certificate they ever intentionally signed. (They do, right? ;-) )

comment:4 Changed 8 years ago by achernya

I did a small census of 18/8 and found a few things that are concerning, mainly being the 17 2014 expiry MIT CA certificates. Also, let it be noted the EFF SSL Observatory is the jankiest scripts I've ever met. They parse textual openssl x509. This can't possibly have ever worked.

comment:5 Changed 7 years ago by jdreed

  • Milestone changed from The Distant Future to Summer 2014

comment:6 Changed 7 years ago by jdreed

Dan tells me we can't do this just yet, because there are a few one-offs that are still being signed by the MIT CA. I'm getting a list. The situation should be slightly better in June.

comment:8 Changed 5 years ago by jweiss

Have we checked in with Dan, to confirm the one-offs have all been taken care of?

comment:9 follow-up: ↓ 10 Changed 5 years ago by andersk

jweiss: Not to my knowledge. Would you like to ask, or should I? (Is Dan = dlogcher?)

comment:10 in reply to: ↑ 9 Changed 5 years ago by jweiss

Replying to andersk:

jweiss: Not to my knowledge. Would you like to ask, or should I? (Is Dan = dlogcher?)

Dan is dlogcher, and his office is around the corner from where I sit, so I asked him and he confirmed that he hasn't issued any MIT CA signed server certs in a long time, so it should indeed be safe to remove. thanks for letting me close that loop.

comment:11 Changed 5 years ago by andersk

  • Status changed from new to development
  • Fixed in version set to debathena-ssl-certificates 1.6-0debathena2

comment:12 Changed 5 years ago by andersk

  • Status changed from development to proposed

comment:13 Changed 5 years ago by andersk

  • Status changed from proposed to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.