Re: [FORGED] Re: Incidents involving the CA WoSign

[Peter Gutmann]

Peter Bowen  writes:

>As someone pointed out on Twitter this morning, it seems that the PSC
>notification for Startcom UK was filed recently:
>https://s3-eu-west-1.amazonaws.com/document-api-images-prod/docs/UdxHYAlFj6U9DNs6VBJdnIDv4IQAWd4YKYomMERO_2o/application-pdf

So if I'm reading that correctly, Startcom UK is majority- or entirely owned
(both are > 25%, <= 50%) by Jianming Dong and Xianghong Shi?

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Incidents involving the CA WoSign

[Percy]

Yeah, it's almost impossible to distrust all WoSign authority manually from
keychain access. WoSign has 28 root certs or intermediate certs signed by
other CAs, listed below. (List from
https://github.com/chengr28/RevokeChinaCerts/wiki/ReadMe_Online#about-certificates
)

Certification Authority of WoSign  WoSign
CA Limited 
B94294BF91EA8FB64BE61097C7FB001359B676CB
CA 沃通根证书  WoSign CA Limited
 1632478D89F9213A92008563F5A4A7D312408AD6
Class 1 Primary CA WoSign CA Limited 
6A174570A916FBE84453EED3D070A1D8DA442829
Certification Authority of WoSign WoSign CA Limited
 33A4D8BC38608EF52EF0E28A35091E9250907FB9
Certification Authority of WoSign G2  WoSign
CA Limited 
FBEDDC9065B7272037BC550C9C56DEBBF27894E1
CA WoSign ECC Root  WoSign CA Limited
 D27AD2BEED94C0A13CC72521EA5D71BE8119F32B
Certification Authority of WoSign StartCom Certification Authority
 868241C8B85AF79E2DAC79EDADB723E82A36AFC3
Certification Authority of WoSign StartCom Certification Authority
 692790DA5189529CC5CE1E16E984277A03023E99
Certification Authority of WoSign StartCom Certification Authority
 804E5FB7DE84F5F5B28347233EAF07846B6070D3
Certification Authority of WoSign StartCom Certification Authority
 B0B68AE97CFE2AFACD0DC2010B9D70ACE593E8A6
Certification Authority of WoSign StartCom Certification Authority
 27D5BBE04301E1604839708D172CF09296ED9033
Certification Authority of WoSign UTN-USERFirst-Object
 7C1913D189C46577D7513F980A2CFD7EDCBA0EC9
Certification Authority of WoSign UTN-USERFirst-Object
 1C1ECDCCF764E6168177C5711F33EC9229A29F88
Certification Authority of WoSign G2 Certum CA 
B39191CFF08EB6FD8B447C21CAAEF6FC33F1D5AE
Certification Authority of WoSign G2 Certum CA 
73FFCA3F815B7A77717FE91912A4DC7B6BFB79CA
CA 沃通根证书 StartCom Certification Authority 
D8EFF6C28BB508E4702565F42748454A872BD412
CA 沃通根证书 StartCom Certification Authority 
CE335662F0EA6764B95C7F50A995A514ACE8C815
CA 沃通根证书 StartCom Certification Authority 
B2FBDA222493A93C38F77C90D4BE6DA17F15F0B0
Certification Authority of WoSign UTN – DATACorp SGC
 56FAADDC596DCF78D585D83A35BC04B690D12736
WoSign Premium Server Authority AddTrust External CA
Root/UTN-USERFirst-Hardware 
E3D569137E603E7BACB6BCC66AE943850C8ADF38
WoSign Server Authority AddTrust External CA Root/UTN-USERFirst-Hardware
 3E14B8BD6C568657D852D95D387249AE857B4A39
WoSign SGC Server Authority UTN – DATACorp SGC 
6D5A18050D56BFDE525CBE89E8C45DD1B53D12E9
WoSign Client Authority UTN-USERFirst-Client Authentication and Email
 FAD4319D4E173FF3853E51C98D21919BF3DA1A1E
WoTrust Premium Server Authority AddTrust External CA
Root/UTN-USERFirst-Hardware 
381CBC5048AFD9A02D3E5882D5F22D962B1A5F72
WoTrust Premium Server Authority AddTrust External CA
Root/UTN-USERFirst-Hardware 
CF37A5B5C9166BD6B57A56BF67165A584B057241
WoTrust Server Authority AddTrust External CA Root/UTN-USERFirst-Hardware
 337DF96418F08A9355870513AFCEBDC68BCED767
WoTrust SGC Server Authority UTN – DATACorp SGC 
46A762F3C3CF3732DE22A8BA1EBBA3BC048F9B8C
WoTrust Client Authority UTN-USERFirst-Client Authentication and Email
 38CFE78D9F1F0B0637AFCAAA3D5549D87C0AA1D0

Percy Alpha(PGP
)


On Tue, Sep 6, 2016 at 8:19 AM, Peter Gutmann 
wrote:

> Nick Lamb  writes:
>
> >On Tuesday, 6 September 2016 15:11:00 UTC+1, Peter Gutmann  wrote:
> >> Why would a public CA even need cross-certification from other CAs?
> >
> >Maybe this question has some subtlety to it that I'm missing?
>
> OK, I really meant "that many other CAs".  To take one example, the cross-
> certifying CA known as Usertrust that eventually became part of Comodo has
> been around since the late 1990s, so it's presumably trusted by everything
> under the sun, and then Comodo owns (at least) AddTrust AB, eBiz Networks,
> Positive Software, RegisterFly, Registry Pro, The Code Project, The
> USERTRUST
> Network, WebSpace-Forum e.K., and Wotone Communications.  Getting a whole
> pile
> of other cross-certifications from additional CAs seems a bit redundant,
> and
> has the flipside that once you've got a sufficiently complex mesh of cross-
> certifications you've established 

Re: [FORGED] Re: Incidents involving the CA WoSign

[Peter Gutmann]

Nick Lamb  writes:

>On Tuesday, 6 September 2016 15:11:00 UTC+1, Peter Gutmann  wrote:
>> Why would a public CA even need cross-certification from other CAs?
>
>Maybe this question has some subtlety to it that I'm missing?

OK, I really meant "that many other CAs".  To take one example, the cross-
certifying CA known as Usertrust that eventually became part of Comodo has
been around since the late 1990s, so it's presumably trusted by everything
under the sun, and then Comodo owns (at least) AddTrust AB, eBiz Networks,
Positive Software, RegisterFly, Registry Pro, The Code Project, The USERTRUST
Network, WebSpace-Forum e.K., and Wotone Communications.  Getting a whole pile
of other cross-certifications from additional CAs seems a bit redundant, and
has the flipside that once you've got a sufficiently complex mesh of cross-
certifications you've established such a level of fault-tolerance that it's
difficult to untrust a CA because there'll always be another cross-
certification somewhere leading to a trusted root.

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Incidents involving the CA WoSign

[Nick Lamb]

On Tuesday, 6 September 2016 15:11:00 UTC+1, Peter Gutmann  wrote:
> Why would a public CA even need cross-certification from other CAs?

Maybe this question has some subtlety to it that I'm missing?

Acceptance into root trust stores is slow. Glacial in some cases. Mozilla has a 
published process. Microsoft, Apple and Oracle all say basically "email this 
address with your details" and beyond that all is opaque, other trust stores 
are worse / slower.

Let's Encrypt was announced in 2014, with its intention from the outset being 
to operate as a public CA. The ISRG Root (ISRG is the actual 501(c)3 entity 
behind Let's Encrypt formally) was self-signed in June 2015. In September 2015 
they formally applied to all major root trust stores including Mozilla.

In October 2015 they received a cross-certification from IdenTrust for Let's 
Encrypt Authority X1 (and its backup X2) and soon after began "beta" issuance, 
making real working leaf certificates for the web PKI, obeying the BRs and so 
on, initially for subscribers who had been pre-vetted and then for the general 
public.

By June 2016, with all major root trust stores still deliberating (Mozilla 
publicly, everyone else behind closed doors) Let's Encrypt was one of the 
biggest issuers on the entire World Wide Web. Officially, they were merely a 
subCA of IdenTrust as far as every trust store is concerned. In practice they 
were now bigger than almost all the directly trusted public CAs (Symantec and 
Comodo are bigger by most measures).

In July 2016 Mozilla signalled that future Firefox versions would add ISRG Root 
X1 to their trust store. No word yet from any other major trust store. This is 
not at all unusual.

So, cross signatures are the difference between being able to actually "enter 
the market" in reasonable time and being stalled out essentially indefinitely.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Incidents involving the CA WoSign

[Myers, Kenneth (10421)]

There could be multiple reasons for xcerts from internal policies to controlled 
trust stores. It depends on the root and the company. Part of the reason the 
FPKI has xcerts is for both those reasons. Companies may only want to use their 
root. They may not want to rely on the trust bundle approach or have internal 
policies that there must be mutual trust. I think this group has seen some 
examples of questionable audits.

Ken

Message: 4
Date: Tue, 6 Sep 2016 14:10:19 +00
From: Peter Gutmann <pgut...@cs.auckland.ac.nz>
To: Peter Bowen <pzbo...@gmail.com>, Gervase Markham
<g...@mozilla.org>
Cc: Richard Wang <rich...@wosign.com>,
"mozilla-dev-security-pol...@lists.mozilla.org"
<mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: [FORGED] Re: Incidents involving the CA WoSign
Message-ID: <1473170991071.38...@cs.auckland.ac.nz>
Content-Type: text/plain; charset="iso-8859-1"

Peter Bowen <pzbo...@gmail.com> writes:

>In addition to the direct impact, I note that WoSign is the subject of cross-
>signatures from a number of other CAs that chain back to roots in the Mozilla
>program (or were in the program).

This is incredible, it's like a hydra.  Do the BRs say anything about this
type of cross-certification, or is it just "find as many other CAs as you can
to cross-certify you so you can't be killed".

Why would a public CA even need cross-certification from other CAs?

Peter.


Ken

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+kenneth.myers=protiviti@lists.mozilla.org]
 On Behalf Of dev-security-policy-requ...@lists.mozilla.org
Sent: Tuesday, September 6, 2016 10:19
To: dev-security-policy@lists.mozilla.org
Subject: dev-security-policy Digest, Vol 93, Issue 34

Send dev-security-policy mailing list submissions to
dev-security-policy@lists.mozilla.org

To subscribe or unsubscribe via the World Wide Web, visit

https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.mozilla.org_listinfo_dev-2Dsecurity-2Dpolicy=DQICAg=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY=gx-RPkgIBbnv1o7pHc6J2JDA0hiijyCDt6lIsqVJaTk=3DxgIVrE6qM1HU21hDF7kWz-URTpSuAa2CzJ9fhbisw=
or, via email, send a message with subject or body 'help' to
dev-security-policy-requ...@lists.mozilla.org

You can reach the person managing the list at
dev-security-policy-ow...@lists.mozilla.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of dev-security-policy digest..."


Today's Topics:

   1. Re: Sanctions short of distrust (Jakob Bohm)
   2. Re: Sanctions short of distrust (Kurt Roeckx)
   3. Re: Incidents involving the CA WoSign (Peter Gutmann)
   4. Re: [FORGED] Re: Incidents involving the CA WoSign (Peter Gutmann)
   5. Re: Sanctions short of distrust (Jakob Bohm)
   6. Re: Incidents involving the CA WoSign (Jakob Bohm)


--

Message: 1
Date: Tue, 6 Sep 2016 14:16:32 +0200
From: Jakob Bohm <jb-mozi...@wisemo.com>
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Sanctions short of distrust
Message-ID: <rvydna3-rae8llpknz2dnuu7-lxnn...@mozilla.org>
Content-Type: text/plain; charset=utf-8; format=flowed

On 06/09/2016 10:25, Kurt Roeckx wrote:
> On 2016-09-06 10:13, Nick Lamb wrote:
>> Quality of implementation for OCSP stapling seems to remain poor in
>> at least apache and nginx, two of the most popular servers. Apache's
>> in particular gives me that OpenSSL "We read this standards document
>> and implemented everything in it as a series of config options
>> without any understanding" feeling, rather than Apache's maintainers
>> taking it upon themselves to figure out what will actually work best
>> for most servers and implementing that.
>
> If you think there is something we can do in OpenSSL to improve this,
> please let us know.
>
>

Here are a list of software where I have personally observed bad OCSP stapling 
support:

OpenSSL 1.0.x itself: There are hooks to provide stapled leaf OCSP responses in 
sessions, but no meaningful sample code to do this right (e.g. caching, error 
handling etc.)  I am working on my own add-on code for this, but it is not 
complete and not deployed.
   There is no builtin support for multistapling and no clear documentation on 
how to add arbitrary TLS extensions (such as this) to an OpenSSL application.

OpenSSL 1.1.x itself: This is a heavily rewritten library and very new at this 
time, basic reliability procedures suggest waiting a few patch levels before 
deployment.

Stunnel stand alone SSL/TLS filter (used with e.g. Varnish reverse
proxies): OCSP stapling is on their TODO-list, but not yet included.

Pound light-weight reverse proxy with SSL/TLS front end: 

Re: [FORGED] Re: Incidents involving the CA WoSign

[Jakob Bohm]

On 06/09/2016 16:10, Peter Gutmann wrote:

Peter Bowen  writes:


In addition to the direct impact, I note that WoSign is the subject of cross-
signatures from a number of other CAs that chain back to roots in the Mozilla
program (or were in the program).


This is incredible, it's like a hydra.  Do the BRs say anything about this
type of cross-certification, or is it just "find as many other CAs as you can
to cross-certify you so you can't be killed".



The BRs say that if the cross-certified CA is deemed no longer
compliant, the cross-signing CAs must retract their cross-signature or
be deemed non-compliant themselves.  This was already explained
elsewhere in this discussion.


Why would a public CA even need cross-certification from other CAs?



Because the delay from starting up a new trustworthy CA until all
deployed client software has been upgraded to trust that new CA is
unbearably long (bordering on infinite as the required support
percentage approaches 100.0%).  Hence it is common for new
CAs (other than the now historic RSADSI CA) to acquire cross-signatures
from established (or even defunct) CAs.

This is exacerbated by the fact the at least one Browser vendor
(Microsoft) no longer distributes the full list of trusted CAs with
their clients, but instead checks against an online copy of their root
stores as needed, giving people very little control over what they
trust other than a few historic CAs.

In relation to your well-published PKI criticism, it is noted that some
of the many new CAs found in root stores are governments who (unlike
commercial CAs) are the actual authority on the identity of their
citizens.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Incidents involving the CA WoSign

[Rob Stradling]

On 06/09/16 15:10, Peter Gutmann wrote:

> Why would a public CA even need cross-certification from other CAs?

To inherit trust on legacy platforms that don't have an automatic root
update mechanism.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Incidents involving the CA WoSign

[Peter Gutmann]

Peter Bowen  writes:

>In addition to the direct impact, I note that WoSign is the subject of cross-
>signatures from a number of other CAs that chain back to roots in the Mozilla
>program (or were in the program).

This is incredible, it's like a hydra.  Do the BRs say anything about this
type of cross-certification, or is it just "find as many other CAs as you can
to cross-certify you so you can't be killed".

Why would a public CA even need cross-certification from other CAs?

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [FORGED] Re: Incidents involving the CA WoSign

[Peter Gutmann]

Eddy Nigg  writes:
>On 09/04/2016 09:20 AM, Peter Gutmann wrote:
>> This is great stuff, it's like watching a rerun of Diginotar
>
>.says the audience on the backbenches gleefully

Well, it doesn't exactly paint the best picture of a competently-run CA, same
as Diginotar, and the progression does seem remarkably similar ("nothing to
see here, move along, move along", "OK, there was a small thing, we've fixed
it now", "OK, there was a little more than that but now it's definitely
fixed", "oh, we hadn't noticed that one, it's really, really fixed for sure
now", etc).

Hey look, I don't have anything personal against WoStartSignCom, my views on
the value of the whole browser PKI racket as a means of securing web users are
pretty well known, it's just such a wonderful example of the sort of stuff
that people are relying on for their "security", and how utterly toothless the
browser vendors are in terms of dealing with issues like this: it'll be
debated endlessly on here without anything happening, and Chrome, IE/whatever,
and Safari won't even address it, assuming they're even aware of it.  Just
business as usual.

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Incidents involving the CA WoSign

[Eddy Nigg]

On 09/04/2016 09:20 AM, Peter Gutmann wrote:

Peter Bowen  writes:


It was brought to my attention that there is another incident.

This is great stuff, it's like watching a rerun of Diginotar


.says the audience on the backbenches gleefully

but no, what are you talking about?? Even though some nasty and 
undesired errors happened here, its in no comparison to what happened at 
Diginotar which basically lost control over the CA.



--
Regards
Signer: Eddy Nigg, Founder
StartCom Ltd. 
XMPP:   start...@startcom.org 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [FORGED] Re: Incidents involving the CA WoSign

[Peter Gutmann]

Peter Bowen  writes:

>It was brought to my attention that there is another incident. 

This is great stuff, it's like watching a rerun of Diginotar.  Definitely the
best web soap in the last few weeks...

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy