On Sunday, 10 July 2016 14:29:34 UTC+1, Peter Gutmann wrote:
> Uhh, do you even know how SCEP is used? When you're provisioning a VPN
> gateway, SCADA device, an iPhone, or one of the other systems that SCEP is
> used with, the cert issue is auth'd with a PSK unique to that system, so you
> know
Nick Lamb writes:
>SCEP (and all the real SCEP implementations that I could find) take the
>optimistic view that this is somebody else's problem, and so the practical
>result is security theatre.
Uhh, do you even know how SCEP is used? When you're provisioning a VPN
gateway, SCADA device, an i
On Friday, 8 July 2016 07:04:49 UTC+1, Peter Gutmann wrote:
> Various SCEP drafts have contained all sorts of stuff that was dropped when
> no-one cared about it. The "out of band"/"beyond the scope of this document"
> is standard boilerplate that's used when no-one cares enough to include it in
Patrick Figel writes:
>On 08/07/16 08:04, Peter Gutmann wrote:
>> Or is it that ACME is just a desperate attempt to derail StartCom's
>> StartEncrypt at any cost?
>
>That doesn't make any sense - ACME has been in production for close to a
>year, while StartAPI was launched this April (and StartEn
On 08/07/16 08:04, Peter Gutmann wrote:
> Or is it that ACME is just a desperate attempt to derail StartCom's
> StartEncrypt at any cost?
That doesn't make any sense - ACME has been in production for close to a
year, while StartAPI was launched this April (and StartEncrypt just a
couple of weeks a
Nick Lamb writes:
>Early drafts of SCEP, before it confined itself to "closed networks" even
>spell out what the problem is before they basically say they're not going to
>make any real attempt to tackle it. CMP, CMC and SCEP all resort to saying
>that some "out of band" mechanism should be used
On Thursday, 7 July 2016 01:52:23 UTC+1, Peter Gutmann wrote:
> There wasn't any decision to leave it unaddressed, no-one had ever expressed
> any interest in this at any point during the work on the previous protocols,
> so there's nothing about it in any of the specs.
This claim is plainly fals
Nick Lamb writes:
>In the examples I've reviewed the decision seems to have been made (either
>explicitly or tacitly) to leave the really difficult problem - specifically
>achieving confidence in the identity of the subject - completely unaddressed.
There wasn't any decision to leave it unaddres
On Wed, Jul 6, 2016 at 4:50 AM, Peter Gutmann
wrote:
> Nick Lamb writes:
>
> >ACME is a protocol intended to become an IETF Standards Track RFC.
>
> Oh dear God, another one? We've already got CMP, CMC, SCEP, EST, and a
> whole
> slew of other ones that failed to get as far as RFCs, which all d
On Wednesday, 6 July 2016 09:50:46 UTC+1, Peter Gutmann wrote:
> Oh dear God, another one? We've already got CMP, CMC, SCEP, EST, and a whole
> slew of other ones that failed to get as far as RFCs, which all do what ACME
> is trying to do. What's the selling point for ACME? That it blows up in
Nick Lamb writes:
>ACME is a protocol intended to become an IETF Standards Track RFC.
Oh dear God, another one? We've already got CMP, CMC, SCEP, EST, and a whole
slew of other ones that failed to get as far as RFCs, which all do what ACME
is trying to do. What's the selling point for ACME? T
On Friday, July 1, 2016 at 3:26:52 PM UTC-5, Nick Lamb wrote:
> ACME is a protocol intended to become an IETF Standards Track RFC. You are
> welcome to read the existing discussions of the protocol, or to participate
> (subject to usual IETF rules) https://www.ietf.org/mailman/listinfo/acme. As
On 07/01/2016 05:54 PM, Patrick Figel wrote:
Can you comment on how your backend checks would have prevented any
misissuance? My understanding of the report is that this was not so much
an issue with the client software, but rather an oversight in the
protocol that allows Domain Validation check
On Friday, 1 July 2016 20:44:00 UTC+1, Peter Kurrasch wrote:
> Only reason I'm focusing on Let's Encrypt and ACME is because they are
> currently under review for inclusion. As far as I'm concerned all CA's with
> similar interfaces warrant this extra scrutiny.
>
> I am somewhat curious if any
these interfaces can be abused and lead to certificate mis-issuance?
Original Message
From: Matt Palmer
Sent: Friday, July 1, 2016 12:16 AM
To: dev-security-policy@lists.mozilla.org
Subject: Re: StartEncrypt considered harmful today
On Thu, Jun 30, 2016 at 11:10:45AM -0500, Peter Ku
On Friday, July 1, 2016 at 9:35:20 AM UTC+2, Eddy Nigg wrote:
> So far less than three hundred certificates have been issued using
> this method, none should have been effectively issue wrongfully due
> to our backend checks.
Can you comment on how your backend checks would have prevented any
misi
> On 30 Jun 2016, at 23:10, Andrew Ayer wrote:
>
> On Thu, 30 Jun 2016 22:36:19 +0200
> Christiaan Ottow wrote:
>
>> We acquired certificates for a private domain (and some subdomains)
>> of the tester in question, and one for our domain pine.nl. Details of
>> the latter are attached, with the
On 06/30/2016 06:30 PM, Rob Stradling wrote:
https://www.computest.nl/blog/startencrypt-considered-harmful-today/
Eddy, is this report correct? Are you planning to post a public
incident report?
Hi Rob and all,
There were indeed a couple of issues with the client software - known
bugs
On Thu, Jun 30, 2016 at 11:10:45AM -0500, Peter Kurrasch wrote:
> Very interesting. This is exactly the sort of thing I'm concerned about
> with respect to Let's Encrypt and ACME.
Why? StartCom isn't the first CA to have had quite glaring holes in its
automated DCV interface and code, and I'm sur
On Thursday, 30 June 2016 18:13:53 UTC+1, Peter Kurrasch wrote:
> Let's be even more pointed: How do we know that *any* of the certs issued
> through this interface were issued to the right person for the right domain?
> How can StartCom make that determination?
Assuming that
* This was the o
On Thu, 30 Jun 2016 22:36:19 +0200
Christiaan Ottow wrote:
> We acquired certificates for a private domain (and some subdomains)
> of the tester in question, and one for our domain pine.nl. Details of
> the latter are attached, with the modulus and signature left out. The
> SHA256 fingerprint of
On 30 Jun 2016, at 22:00, Andrew Ayer wrote:
>
> On Thu, 30 Jun 2016 15:54:02 -0400
> Jonathan Rudenberg mailto:jonat...@titanous.com>>
> wrote:
>
>>
>>> On Jun 30, 2016, at 15:44, Christiaan Ottow
>>> wrote:
>>>
>>> The certificates we had issuedto us as proof of concept (only for
>>> our
On Thu, 30 Jun 2016 15:54:02 -0400
Jonathan Rudenberg wrote:
>
> > On Jun 30, 2016, at 15:44, Christiaan Ottow
> > wrote:
> >
> > The certificates we had issuedto us as proof of concept (only for
> > our own domains), were not revoked and we don't see them in the CT
> > logs. However, we info
On Thu, 30 Jun 2016 21:44:02 +0200
Christiaan Ottow wrote:
> > On 6/30/16 8:30 AM, Rob Stradling wrote:
> > > https://www.computest.nl/blog/startencrypt-considered-harmful-today/
> > >
> > > Eddy, is this report correct? Are you planning to pos
> On Jun 30, 2016, at 15:44, Christiaan Ottow wrote:
>
> The certificates we had issuedto us as proof of concept (only for our own
> domains), were not revoked and we don't see them in the CT logs. However, we
> informed StartCom that we had only issued certificates for domains under our
> c
> On 6/30/16 8:30 AM, Rob Stradling wrote:
> > https://www.computest.nl/blog/startencrypt-considered-harmful-today/
> >
> > Eddy, is this report correct? Are you planning to post a public
> > incident report?
>
> Does StartCom honor CAA?
>
> Does
On Thu, Jun 30, 2016 at 12:46 PM, Juergen Christoffel <
juergen.christof...@zv.fraunhofer.de> wrote:
> On 30.06.16 18:24, Phillip Hallam-Baker wrote:
>
>> What makes something easy to hack in Perl does not make for good security
>> architecture.
>>
>
> Bad design, engineering or implementation is
TBH, the OWASP Top Ten is not really a metric, it's a set of general bins
of threats. There's no such thing as "passing the OWASP Top Ten".
I think you're going to struggle to establish any sort of objective,
general criteria. These protocol bugs are challenging to find and specific
to different
All good points. I wonder if we need to start with something more basic:
setting expectations.
Maybe we need to communicate to all participating CA's that we expect them to
perform a security scan of all Internet-facing interfaces. That we expect each
interface to be able to pass the OWASP Top
Let's be even more pointed: How do we know that *any* of the certs issued
through this interface were issued to the right person for the right domain?
How can StartCom make that determination?
Original Message
From: Daniel Veditz
Sent: Thursday, June 30, 2016 12:04 PM
...
How many mis-is
On 6/30/16 8:30 AM, Rob Stradling wrote:
> https://www.computest.nl/blog/startencrypt-considered-harmful-today/
>
> Eddy, is this report correct? Are you planning to post a public
> incident report?
Does StartCom honor CAA?
Does StartCom publish to CT logs?
How many mis-issue
On 30 June 2016 at 11:10, Peter Kurrasch wrote:
> Very interesting. This is exactly the sort of thing I'm concerned about with
> respect to Let's Encrypt and ACME.
>
> I would think that all CA's should issue some sort of statement regarding the
> security testing of any similar, Internet-facing
On 30.06.16 18:24, Phillip Hallam-Baker wrote:
What makes something easy to hack in Perl does not make for good security
architecture.
Bad design, engineering or implementation is not primarily a problem of the
language used. Or we would never have seen buffer overflows in C. Please
castigate
tps://www.computest.nl/blog/startencrypt-considered-harmful-today/
>
> Eddy, is this report correct? Are you planning to post a public incident
> report?
>
> Thanks.
>
> --
> Rob Stradling
> Senior Research & Development Scientis
: Rob Stradling
Sent: Thursday, June 30, 2016 10:31 AM
To: mozilla-dev-security-pol...@lists.mozilla.org; 'Eddy Nigg (StartCom Ltd.)'
Subject: StartEncrypt considered harmful today
https://www.computest.nl/blog/startencrypt-considered-harmful-today/
Eddy, is this report correct? Are
https://www.computest.nl/blog/startencrypt-considered-harmful-today/
Eddy, is this report correct? Are you planning to post a public
incident report?
Thanks.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust On
36 matches
Mail list logo
