On 12/12/2018 01.47, Ryan Sleevi via dev-security-policy wrote:
> Is this new from the past discussion?
I think what's new is someone actually tried this, and found 5 CAs that
are vulnerable and for which this attack works in practice.
>
Based on the information reported in this thread GlobalSign has started the
necessary activities to investigate this potential misuse.
Arvid
On Tuesday, December 11, 2018 at 8:24:43 AM UTC+1, Mark Steward wrote:
> This time it's just hanging around in memory, no need to do anything
> about the
I figured this presentation might be of interest to this list:
https://i.blackhat.com/eu-18/Thu-Dec-6/eu-18-Heftrig-Off-Path-Attacks-Against-PKI.pdf
It seems they found 5 (unspecified) public CAs out of 17 tested were
vulnerable to this attack, which can be performed by an off-path attacker.
On Tue, Dec 11, 2018 at 11:34 AM Hector Martin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I figured this presentation might be of interest to this list:
>
>
> https://i.blackhat.com/eu-18/Thu-Dec-6/eu-18-Heftrig-Off-Path-Attacks-Against-PKI.pdf
>
> It seems they
On Tuesday, December 11, 2018 at 11:27:52 AM UTC-6, Hector Martin 'marcan'
wrote:
> On 12/12/2018 01.47, Ryan Sleevi via dev-security-policy wrote:
> > Is this new from the past discussion?
>
> I think what's new is someone actually tried this, and found 5 CAs that
> are vulnerable and for which
On Tue, Dec 11, 2018 at 08:00:59AM +, Jeremy Rowley via dev-security-policy
wrote:
> I think pretty much every ca will accept a signed file in lieu of an
> actual key.
You'd rather hope so. If there are any CAs out there who *wouldn't* accept
a signature from the private key as proof of
Option 1 is the intended interpretation. We specified 30 days because the
tokens used for domain validation (Random Number) need to have a useful life
of 30 days. The 30-day usage period needed to be put into the definition of
the Test Certificate, or into Method 3.2.2.4.9, and we selected the
It is not absolutely clear for us how to manage the test certificates which
were issued by a CA where there are no certificate chains to a root certificate
subject to the Baseline Requirements (for example an independent test CA
hierarchy).
The BR wording is as follows:
Test Certificate: A
I think pretty much every ca will accept a signed file in lieu of an actual
key. Generally provide the key just means some proof of compromise the ca can
replicate.
From: dev-security-policy on
behalf of Matt Palmer via dev-security-policy
Sent: Monday,
On 2018/12/11 14:39, Matt Palmer via dev-security-policy wrote:
> On Tue, Dec 11, 2018 at 05:37:41AM +, Xiaoyin Liu via dev-security-policy
> wrote:
>> It’s clear that the private key for *.alipcsec.com is embedded in the
>> executable,
> There are ways of implementing SSL such that the
Thank you for this report. We've verified disclosure of the private key for
this certificate and have notified the customer that their certificate will
be revoked. Due to the large customer impact, we're provided them 24 hours
to get new client executables prepared and ready for download by
11 matches
Mail list logo
