827543 - Remove *all* TURKTRUST root certificates from the b2g18 branch

Status: RESOLVED FIXED

(Core :: Security: PSM, defect)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

There is a hard deadline (January 15th) for changes on the b2g18 branch. After that date, we have no guarantee that we will have changes in that branch accepted by partners that adopt B2G 1.0.

Because of this unusual (for Mozilla) hard deadline, and because we don't know what we will do with the existing TURKTRUST roots, and because the target market for the initial phones is FAR away from Turkey and its neighbors, we should err on the caution and remove the caution and just remove the TURKTRUST roots from B2G 1.0. (The target market for the initial B2G devices is somewhere the Americas, south of the US. Not sure I can be more specific than that due to partner confidentiality concerns.)

Note that it is way too late for us to implement any kind of name constraints for the TURKTRUST roots that could land in time for B2G 1.0.

If we eventually decide not to remove the TURKTRUST roots from other branches then we can ask our partners to add the TURKTRUST roots back to the device.

Comment 1

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Note: I filed this bug in PSM because I think we'd best do this as a private patch to Gecko on the mozilla-b2g18 branch, instead of releasing a new variant of NSS with this change.

Also, bug 826666 is the bug for removing TURKTRUST from all branches.

Comment 2

[Gervase Markham [:gerv]]

I agree that our options for this branch are simply to ship the roots, or not to ship them.

Without stronger confirmation from the product owner, I would be very wary of saying that B2G 1.0 will only get shipped in the south-of-the-US country or countries you mention. In other bugs, I have seen 5 countries named, some of which are a lot closer to Turkey.

However, I'm also not convinced of the principle that a CA necessarily does business in places geographically close to it, so it's safe to remove it for objects shipping in countries far away. QuoVadis, for example, is based in Bermuda. 

Anyway, the ideal here is that we do whatever it is we are planning to do on all other branches. And we have just under a week to see if we can get closer to a consensus on what additional action to take, if any, regarding TurkTrust. We should re-evaluate the situation on the 12th or 13th. If someone wants to prepare a just-in-case removal patch, so we have all options open, that would be entirely reasonable.

Gerv

Comment 3

[Andrew Overholt [:overholt]]

(In reply to Gervase Markham [:gerv] from comment #2)
> We should re-evaluate the situation on the 12th or 13th.

Okay, please let us know when we've made a decision.  Sooner is better than later :)

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Let's do this for now, and if Desktop Firefox decides to keep it, we can attempt to put the cert back in at that point.

Comment 5

[Andreas Gal :gal]

We can yank the certs post 1/15 if we need to.

Comment 6

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Attachment: Remove TURKTRUST roots from B2G, B2G-only

I tested this by visiting https://turktrust.com.tr/ and verifying that the page failed to load. Note that you may need to shift-reload (or test in a new profile) to actually reload the page since Firefox caches it.

Note that it is possible that some other CAs in our program cross-signed TURKTRUST's certificates. In that case, certificates TURKTRUST issued will still be trusted in B2G. This is something that we should investigate soon. Unfortunately, without adding new code to NSS or PSM, there's not much we can do about that, and any such new code would be too high-risk to land for B2G in the next few days.

r?kwilson since she is the module owner so she has the final call here. I expect that the r+/r- won't come until late today (Berlin time) or perhaps Monday PST.

Comment 7

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Brian Smith (:bsmith) from comment #6)
> Note that it is possible that some other CAs in our program cross-signed
> TURKTRUST's certificates. In that case, certificates TURKTRUST issued will
> still be trusted in B2G. This is something that we should investigate soon.
> Unfortunately, without adding new code to NSS or PSM, there's not much we
> can do about that, and any such new code would be too high-risk to land for
> B2G in the next few days.

To explain this further, and to explain why I didn't add active distrust records: Active distrust in NSS is based on issuer/serial number. So, in order to block any cross-certs with the existing code, we would need to know the issuers and serial of the cross-certs. If/when we have any of them, we can add them.

Comment 8

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Andreas Gal :gal from comment #5)
> We can yank the certs post 1/15 if we need to.

We decided to make this blocking-basecamp+ to make sure we get it landed before the code hand-off, because we don't want to risk the patch not being accepted after we hand off the Gecko code (after which all patches are subject to partner approval).

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Not tef+ since this isn't a request from TEF. But tracking.

Comment 10

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Attachment: Remove TURKTRUST roots from B2G, B2G-only

kaie also looked at the patch to verify that it does what it says on the box. He suggested that I change the version number for nssckbi, to show that this is a frankenbuild. I investigated doing that but decided it was unnecessary risk and it could possibly be more confusing to do that, so I didn't make that change.

This is the same as the previous version of the patch, functionality. The only difference is that this fixes the NPOTB patch file in security/patches. The previous version of the patch included all the revisions of the patch because I was doing `cp .hg/patches/remove-turktrust-bug-827543.patch security/patches && hg qrefresh`.

Comment 11

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Comment on attachment 701013 [details] [diff] [review]
Remove TURKTRUST roots from B2G, B2G-only

[Approval Request Comment]
This was originally blocking-basecamp+ but now it is blocking-basecamp- because there was uncertainty about whether we'd have it done before today.

Comment 12

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/f789e08d20c2

Comment 13

[Christoph Anton Mitterer]

Were now really all Turktrust certs removed? Or just some of them?

Doesn't this also close #826666?

Comment 14

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Christoph Anton Mitterer from comment #13)
> Were now really all Turktrust certs removed? Or just some of them?

All the TURKTRUST certs were *tentatively* removed only for B2G 1.0. 

> Doesn't this also close #826666?

This bug is only about B2G 1.0, not for the other projects like Firefox.

This was checked in for B2G 1.0 only due to scheduling/project management concerns. It is possible that this patch will be reverted to add them back even for B2G 1.0, if we decide to WONTFIX bug 826666.

Comment 15

[Christoph Anton Mitterer]

Ah I see.

Well I haven't followed the discussion now on the list, as to me, any X.509 based PKI is inherently broken and can never really be fixed.

IMHO, Turktrust would deserve to be fully removed, as they proved they cannot be trusted.
But OTOH we see that while it would be easy to remove someone small like TT, we could never really remove the big players (Verisign, Equifax,...etc. pp.)


I wonder when browser manufacturers will have learned enough to start switching to better alternatives.
Will probably need many more incidents like this.

Comment 16

[Lukas Blakk [:lsblakk] use ?needinfo]

Landed on mozilla-b2g18/gaia master prior to the 1/25 branching to mozilla-b2g18_v1_0_0/v1.0.0, updating status-b2g-v1.0.0 to fixed.