Opened 3 years ago

Closed 2 years ago

#19192 closed defect (fixed)

untrust bluecoat CA

Reported by: mrphs Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ff52-esr-will-have
Cc: saint, fdsfgs@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Apparently BlueCoat now has a signed CA. Can we please make sure it's not trusted in the Tor Browser?

Child Tickets

Change History (9)

comment:1 Changed 3 years ago by saint

Cc: saint added
Priority: MediumVery High
Severity: NormalMajor

Changing severity to reflect the impact that having BlueCoat as a trusted intermediary would have on end-users. It would not surprise me if BlueCoat's move were a way to quietly support one of the many countries experimenting with national SSL/TLS certificates. It's an excellent way to silently mitm, I'll give them that much.

comment:2 Changed 3 years ago by yawning

Changing severity to reflect the impact that having BlueCoat as a trusted intermediary would have on end-users. It would not surprise me if BlueCoat's move were a way to quietly support one of the many countries experimenting with national SSL/TLS certificates. It's an excellent way to silently mitm, I'll give them that much.

If this was part of some evil plan, wouldn't they have gotten an intermediate CA that can create more CAs (the pathlen in their cert is 0 so it can only sign leafs). What are they gonna do, distribute the CA private key in every single one of their shit boxes? *.google.com MITM certs as a service? What?

We've so far avoided from getting into the "which CAs are evil" game, despite people complaining (for good reason), about CAs being run by actual nation states...

comment:3 Changed 3 years ago by gk

See: https://bugzilla.mozilla.org/show_bug.cgi?id=1276146 for the upstream bug. We should closely follow it and take Mozilla's reasoning into account. I am still not convinced we should go into the "which CA is evil" business and agree with comment:2.

comment:4 Changed 3 years ago by mrphs

FYI, Google has apparently already distrusted Symantec because of not compiling with CA/B Forum baseline requirements: https://security.googleblog.com/2015/12/proactive-measures-in-digital.html

comment:5 Changed 2 years ago by cypherpunks

Priority: Very HighMedium
Severity: MajorNormal

The Department of Defense has a CA. South Korean government has a CA. China has a CA. Why are we trusting them? Though admittedly the DoD PKI is not trusted by Firefox, even if it is in the Windows trust store. The CA system itself is broken. It's not up to us to fix it by blacklisting authorities we dislike.

The point is that I agree with Yawning and gk. We shouldn't get into the "which CAs are evil" game.

I think this ticket should be closed, myself.

comment:6 in reply to:  3 ; Changed 2 years ago by cypherpunks

Status: newneeds_information

Replying to gk:

See: https://bugzilla.mozilla.org/show_bug.cgi?id=1276146 for the upstream bug. We should closely follow it and take Mozilla's reasoning into account. I am still not convinced we should go into the "which CA is evil" business and agree with comment:2.

Upstream bug was fixed. Next step?
"which CA is evil" - start to update root certificates according to Firefox release?

comment:7 in reply to:  6 Changed 2 years ago by gk

Keywords: ff52-esr-will-have added
Status: needs_informationassigned

Replying to cypherpunks:

Replying to gk:

See: https://bugzilla.mozilla.org/show_bug.cgi?id=1276146 for the upstream bug. We should closely follow it and take Mozilla's reasoning into account. I am still not convinced we should go into the "which CA is evil" business and agree with comment:2.

Upstream bug was fixed. Next step?
"which CA is evil" - start to update root certificates according to Firefox release?

Next step is moving to Firefox ESR 52 which is planned for the next alpha (i.e. 7.0a3).

Last edited 2 years ago by gk (previous) (diff)

comment:8 Changed 2 years ago by tokotoko

Cc: fdsfgs@… added

comment:9 Changed 2 years ago by gk

Resolution: fixed
Status: assignedclosed

This will be fixed in 7.0a3 which is based on Firefox 52 ESR.

Note: See TracTickets for help on using tickets.