Re: Apple: Patch Management
On Fri, Dec 06, 2019 at 07:08:46PM -0800, Apple CA via dev-security-policy wrote: > On Saturday, November 23, 2019 at 3:28:10 PM UTC-8, Matt Palmer wrote: > > [aside: this is how incident reports should be done, IMHO] > > > > On Fri, Nov 22, 2019 at 07:23:27PM -0800, Apple CA via dev-security-policy > > wrote: > > > We did not have an accurate understanding of how the vulnerability scanner > > > worked. Our understanding of its capabilities lead us to believe it was > > > scanning and detecting vulnerabilities in EJBCA. > > > > There's a reasonable chance that other CAs may have a similar situation, so > > I think it's worth digging deeper into the root causes here. Can you expand > > on how this misunderstanding regarding the vulnerability scanner came to > > pass? What was the information on which you were relying when you came to > > the understanding of the vulnerability scanner's capabilities? Were you > > misled by the vendor marketing or technical documentation, or was it an > > Apple-internal assessment that came to an inaccurate conclution? Or > > "other"? > > In order to identify vulnerabilities, the vulnerability scanner (1) > attempts to identify/profile software listening on ports and (2) compares > software versions against public CVEs and proprietary data sources. EJBCA > is not broadly used software, and the vulnerability scanner did not have > custom EJBCA detection logic. Upon our deeper investigation, we > discovered that it (1) only scans the HTTP service and not the EJBCA > software, which we would consider insufficient on its own and (2) is not > as effective at flagging vulnerabilities in EJBCA because CVEs are not > published by EJBCA. We don’t feel we were mislead by the vendor. Thanks for clarifying how the security scanning software worked; that's useful. I'm not confident that we've determined any root causes for the failure, though, especially things that other CAs in the ecosystem can learn from. I'll try a different phrasing, which will hopefully provide more clarity as to what I'm trying to achieve: What specific, actionable items would you recommend all CAs undertake to remove or mitigate the risk of this, or a substantially similar, problem occurring in their environment? > CVEs are not published by EJBCA. Does anyone else feel that this is a really, really, *really* bad idea? The CVE system, whilst far from perfect, seems to be the agreed upon medium for managing these types of issues, and it disappoints me that EJBCA would appear to be "opting out" of it. Should discussions with EJBCA, either from their customers or the wider community, be initiated? - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: How Certificates are Verified by Firefox
On 2019-12-09 11:44, Ben Laurie wrote:
On Wed, 4 Dec 2019 at 22:13, Ryan Sleevi wrote:
Yes, I am one of the ones who actively disputes the notion that AIA
considered harmful.
I'm (plesantly) surprised that any CA would be opposed to AIA (i.e.
supportive of "considered harmful", since it's inherently what gives them
the flexibility to make their many design mistakes in their PKI and still
have certificates work. The only way "considered harmful" would work is if
we actively remove the flexibility afforded CAs in this realm, which I'm
highly supportive of, but which definitely encourages more distinctive PKIs
(i.e. more explicitly reducing the use of Web PKI in non-Web cases)
Of course, AIA is also valuable in helping browsers push the web forward,
so I can see why "considered harmful" is useful, especially in that it
helps further the notion that root certificates are a thing of value (and
whose value should increase with age). AIA is one of the key tools to
helping prevent that, which we know is key to ensuring a more flexible, and
agile, ecosystem.
The flaw, of course, in a "considered harmful", is the notion that there's
One Chain or One Right Chain. That's not the world we have, nor have we
ever. The notion that there's One Right Chain for a TLS server to send
presumes there's One Right Set of CA Trust Anchors. And while that's
definitely a world we could pursue, I think we know from the past history
of CA incidents, there's incredible benefit to users to being able to
respond to CA security incidents differently, to remove trust in
deprecated/insecure things differently, and to set policies differently.
And so we can't expect servers to know the Right Chain because there isn't
One Right Chain, and AIA (or intermediate preloading with rapid updates)
can help address that.
It would be a whole lot more efficient and private if the servers did the
chasing.
It would also greatly help if:
1. More clients (especially non-browser client such as libraries used by
IoT devices) supported treating the received "chain" more like a pool
of potential intermediaries and accepted any acceptable combination of
received certs and locally trusted roots. This would allow servers to
send an appropriate collection of intermediaries for different client
needs. Clients that detect different levels of trust (such as the
Qualsys checkers and EV clients) also need to choose the best of the
offered set, as the alternative certs are obviously for use by other
clients. In particular, clients should not panic and block on the
presence of any "bad" certificates in the pool, if a valid chain can
be assembled without that certificate.
This is already in the CMS/PKCS#7 spec and apparently also in the TLS
1.3 spec, but remains seemingly optional when TLS 1.2 or older is
negotiated.
I recently became aware of at least one IoT-focused TLS library that
doesn't support the "pool" interpretation due to lack of a memory-
efficient chain building algorithm.
2. Certain CAs made it a lot easier to get the recommended-to-send list
of certificates ("chain") for server operators to configure. Some
CAs make server operators manually chase down links to each cert in
the list, and some don't send out pre-emptive notification of changes
to paying subscribers.
3. Certain TLS libraries didn't refuse to provide server software
vendors with working stapling code, especially the code to collect
and cache OCSP responses.
P.S. One commonly wilified server brand actually does use AIA to build
the server chain.
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: How Certificates are Verified by Firefox
On Wed, 4 Dec 2019 at 22:13, Ryan Sleevi wrote: > Yes, I am one of the ones who actively disputes the notion that AIA > considered harmful. > > I'm (plesantly) surprised that any CA would be opposed to AIA (i.e. > supportive of "considered harmful", since it's inherently what gives them > the flexibility to make their many design mistakes in their PKI and still > have certificates work. The only way "considered harmful" would work is if > we actively remove the flexibility afforded CAs in this realm, which I'm > highly supportive of, but which definitely encourages more distinctive PKIs > (i.e. more explicitly reducing the use of Web PKI in non-Web cases) > > Of course, AIA is also valuable in helping browsers push the web forward, > so I can see why "considered harmful" is useful, especially in that it > helps further the notion that root certificates are a thing of value (and > whose value should increase with age). AIA is one of the key tools to > helping prevent that, which we know is key to ensuring a more flexible, and > agile, ecosystem. > > The flaw, of course, in a "considered harmful", is the notion that there's > One Chain or One Right Chain. That's not the world we have, nor have we > ever. The notion that there's One Right Chain for a TLS server to send > presumes there's One Right Set of CA Trust Anchors. And while that's > definitely a world we could pursue, I think we know from the past history > of CA incidents, there's incredible benefit to users to being able to > respond to CA security incidents differently, to remove trust in > deprecated/insecure things differently, and to set policies differently. > And so we can't expect servers to know the Right Chain because there isn't > One Right Chain, and AIA (or intermediate preloading with rapid updates) > can help address that. > It would be a whole lot more efficient and private if the servers did the chasing. > > On Wed, Dec 4, 2019 at 5:02 PM Tim Hollebeek via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Someone really should write up "AIA chasing considered harmful". It was >> disputed at the TLS session at IETF 105, which shows that the reasoning >> behind it is not as widely understood as it needs to be, even among TLS >> experts. >> >> I'm very appreciative of Firefox's efforts in this area. Leveraging the >> knowledge of all the publicly disclosed ICAs to improve chain-building is >> an >> idea whose time has come. >> >> -Tim >> >> > -Original Message- >> > From: dev-security-policy < >> dev-security-policy-boun...@lists.mozilla.org> >> On >> > Behalf Of Wayne Thayer via dev-security-policy >> > Sent: Monday, December 2, 2019 3:29 PM >> > To: Ben Laurie >> > Cc: mozilla-dev-security-policy >> ; >> > Peter Gutmann >> > Subject: Re: [FORGED] Re: How Certificates are Verified by Firefox >> > >> > Why not "AIA chasing considered harmful"? The current state of affairs >> is >> that >> > most browsers [other than Firefox] will go and fetch the intermediate if >> it's not >> > cached. This manifests itself as sites not working in Firefox, and users >> switching >> > to other browsers. >> > >> > You may be further dismayed to learn that Firefox will soon implement >> > intermediate preloading [1] as a privacy-preserving alternative to AIA >> chasing. >> > >> > - Wayne >> > >> > [1] >> > >> >> https://wiki.mozilla.org/Security/CryptoEngineering/Intermediate_Preloading >> > #Intermediate_CA_Preloading >> > >> > On Thu, Nov 28, 2019 at 1:39 PM Ben Laurie wrote: >> > >> > > >> > > >> > > On Thu, 28 Nov 2019 at 20:22, Peter Gutmann >> > > >> > > wrote: >> > > >> > >> Ben Laurie via dev-security-policy >> > >> >> > >> writes: >> > >> >> > >> >In short: caching considered harmful. >> > >> >> > >> Or "cacheing considered necessary to make things work"? >> > > >> > > >> > > If you happen to visit a bazillion sites a day. >> > > >> > > >> > >> In particular: >> > >> >> > >> >caching them and filling in missing ones means that failure to >> > >> >present correct cert chains is common behaviour. >> > >> >> > >> Which came first? Was cacheing a response to broken chains or broken >> > >> chains a response to cacheing? >> > >> >> > >> Just trying to sort out cause and effect. >> > >> >> > > >> > > Pretty sure if broken chains caused browsers to not show pages, then >> > > there wouldn't be broken chains. >> > > >> > > -- >> > > I am hiring! Formal methods, UX, SWE ... verified s/w and h/w. >> > > #VerifyAllTheThings. >> > > >> > > https://g.co/u58vjr https://g.co/adjusu *(Google internal)* >> > > >> > ___ >> > dev-security-policy mailing list >> > dev-security-policy@lists.mozilla.org >> > https://lists.mozilla.org/listinfo/dev-security-policy >> >> ___ >> dev-security-policy mailing list >> dev-security-policy@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-security-policy >> > -- I am hiring! Formal
Re: [FORGED] Re: How Certificates are Verified by Firefox
On Mon, 2 Dec 2019 at 20:28, Wayne Thayer wrote: > Why not "AIA chasing considered harmful"? The current state of affairs is > that most browsers [other than Firefox] will go and fetch the intermediate > if it's not cached. This manifests itself as sites not working in Firefox, > and users switching to other browsers. > AIA does not prevent single verifications from working, unlike caching. > > You may be further dismayed to learn that Firefox will soon implement > intermediate preloading [1] as a privacy-preserving alternative to AIA > chasing. > If that involves loading and using intermediates that are not actually available via AIA, then yes. > - Wayne > > [1] > https://wiki.mozilla.org/Security/CryptoEngineering/Intermediate_Preloading#Intermediate_CA_Preloading > > On Thu, Nov 28, 2019 at 1:39 PM Ben Laurie wrote: > >> >> >> On Thu, 28 Nov 2019 at 20:22, Peter Gutmann >> wrote: >> >>> Ben Laurie via dev-security-policy < >>> dev-security-policy@lists.mozilla.org> writes: >>> >>> >In short: caching considered harmful. >>> >>> Or "cacheing considered necessary to make things work"? >> >> >> If you happen to visit a bazillion sites a day. >> >> >>> In particular: >>> >>> >caching them and filling in missing ones means that failure to present >>> >correct cert chains is common behaviour. >>> >>> Which came first? Was cacheing a response to broken chains or broken >>> chains a >>> response to cacheing? >>> >>> Just trying to sort out cause and effect. >>> >> >> Pretty sure if broken chains caused browsers to not show pages, then >> there wouldn't be broken chains. >> >> -- >> I am hiring! Formal methods, UX, SWE ... verified s/w and h/w. >> #VerifyAllTheThings. >> >> https://g.co/u58vjr https://g.co/adjusu >> *(Google internal)* >> > -- I am hiring! Formal methods, UX, SWE ... verified s/w and h/w. #VerifyAllTheThings. https://g.co/u58vjr https://g.co/adjusu *(Google internal)* ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
