Re: StartEncrypt considered harmful today

2016-07-08 Thread Nick Lamb 
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
> the document.  In fact it pretty much explicitly says that it's not covered in
> the doc because no-one cared how it was done.

But alas, even if you didn't care, it does matter.

Which is why there's VU#971035

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. Certificates are issued, public key mathematics is 
done, there is superficial appearance of a secure system but no useful 
assurance of identity is achieved and so no real threat is neutralised.

> What does that have to do with no-one bothering to add whatever magic
> ingredient ACME is claiming to have to any other protocol that does the same
> thing?

This idea that you should just be able to "add whatever magic ingredient" is 
the exact sort of naivety that Bruce is talking about.

> OK, I think I can parse that convoluted sentence... in response: Each week who
> knows how many certificates are issued using HTTP POST, Xenroll.dll, SCEP,
> CMP, and who knows what else.  What's your point?

This is still mozilla.dev.security.policy. ACME automatically issues 
certificates that are trustworthy in the web PKI. That's the point of the 
protocol and the point of my statistic.

Counting up certificates that aren't ever going to be trusted by Mozilla's 
software may make you feel better about the time you invested, but it's not 
relevant to this group.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [FORGED] Re: StartEncrypt considered harmful today

2016-07-08 Thread Peter Gutmann 
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 StartEncrypt just a couple
>of weeks ago).

Fair enough.  Just trying to figure out why someone would invent an entire new
protocol rather than tweak any one of the existing ones.

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

Re: StartEncrypt considered harmful today

2016-07-08 Thread Patrick Figel 
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 ago).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: StartEncrypt considered harmful today

2016-07-08 Thread Peter Gutmann 
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 to verify that the applicant
>is or controls the subject DN and treat this problem as completely out of
>scope. 

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
the document.  In fact it pretty much explicitly says that it's not covered in
the doc because no-one cared how it was done.

So I'll repeat this again: It wasn't added to any existing protocol because
no-one's ever cared about it before.  If people do care about it, why not add
it to any one of the many existing protocols rather than inventing yet another
incompatible way of doing what numerous other protocols already do?

Or is it that ACME is just a desperate attempt to derail StartCom's
StartEncrypt at any cost?

>"Schneier's Law" very much applies.

What does that have to do with no-one bothering to add whatever magic
ingredient ACME is claiming to have to any other protocol that does the same
thing?  Or are you claiming that ACME is flawed because it's a reinvention of
the wheel by amateurs (which is what Schneier's Law would be saying)?  That
seems a bit unlikely...

>Each week several hundred thousand certificates are issued using (an earlier
>draft of) ACME by what is now as a result one of the Web PKI's top five
>Certificate Authorities in terms of how many sites use its certificates.

OK, I think I can parse that convoluted sentence... in response: Each week who
knows how many certificates are issued using HTTP POST, Xenroll.dll, SCEP,
CMP, and who knows what else.  What's your point?

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

Re: StartEncrypt considered harmful today

2016-07-06 Thread Nick Lamb 
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 false. 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 to verify that the applicant is or controls the subject DN and treat 
this problem as completely out of scope. Even by 2005 this should have seemed 
like weak sauce indeed.

> If anyone did care about it,
> it shouldn't be too hard to add support for it to any of the existing
> protocols.

"Schneier's Law" very much applies.

> Well, it solves a problem that no previous protocol, or potential user of the
> protocol, had even acknowledged as a problem before.  Whether that's (a) worth
> creating an entirely new protocol rather than just adding support for it to an
> existing, long-established one and (b) will make said new protocol a success
> when every other attempt to do this has failed, is another matter.

Each week several hundred thousand certificates are issued using (an earlier 
draft of) ACME by what is now as a result one of the Web PKI's top five 
Certificate Authorities in terms of how many sites use its certificates.

I'm content to label this "success" even before ACME becomes an RFC.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartEncrypt considered harmful today

2016-07-06 Thread Richard Barnes 
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 do what
> ACME
> is trying to do.  What's the selling point for ACME?  That it blows up in
> your
> face at the worse possible time?
>

Read the draft, man.  ACME is targeted at a problems that none of those
other protocols solve -- most critically, enabling the applicant to
demonstrate control of an identifier.  That's the reason you have all of
these CA proprietary APIs and ACME; these previous efforts failed to solve
the problems people actually cared about.

--Richard


>
> Peter.
> ___
> 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

Re: StartEncrypt considered harmful today

2016-07-06 Thread Nick Lamb 
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 your
> face at the worse possible time?

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. 
ACME went out of its way to address it for the domain we care about around here.

Your work on SCEP is probably appreciated by people who aren't interested in 
that problem, but this forum is concerned with the Web PKI, where that problem 
is pre-eminent, and this thread is about another provider, StartCom trying and 
failing to solve that problem.

So the answer to your question is that ACME's selling point is that it solves 
the problem lots of people actually have, a problem which was traditionally 
solved by various ad hoc methods whose security (or more often otherwise) was 
only inspected after the fact rather than being considered in advance.

I presume the "blows up in your face" comment was purely because of ACME's 
hilarious choice of name, but if not please elaborate _in a thread about ACME_
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: StartEncrypt considered harmful today

2016-07-06 Thread Peter Gutmann 
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?  That it blows up in your
face at the worse possible time?

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

Re: StartEncrypt considered harmful today

2016-07-02 Thread josh 
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 
> with Mozilla's inclusion process the IETF process ends up partly being a test 
> of endurance, as even simple ideas are dragged out over several months with 
> posts that have some technical meat being mixed in with axe-grinding and 
> larger politics.
> 
> Let's Encrypt's implementation of ACME, Boulder, is on github for anyone to 
> inspect. I am not aware of any independent formal analysis, but it's obvious 
> from the contributions to Boulder that people outside Let's Encrypt do look 
> at it.

We'll probably never be 100% sure that ACME or any other protocol doesn't 
contain serious flaws but we've done quite a bit to build up confidence that 
ACME is secure. Here's a list, in no particular order:

1) Clearly documented the spec in public. This allows anyone to read it and 
give us feedback, from day one and into the future. We know that people do look 
at it and provide valuable feedback (Andrew Ayer and Martin Thomson are good 
examples). Our server implementation of the spec is also open source.

2) We're working to get ACME standardized in the IETF. This gets us more high 
quality feedback.

3) We paid to have the cryptography and application security teams at NCC Group 
audit the spec. This is also true for our boulder software (at least annually).

4) We commissioned a review and formal modeling of the ACME protocol from 
Karthikeyan Bhargavan (INRA).

5) ACME has proven to be quite solid in production so far. It has been used to 
safely issue millions of certificates.

6) We have skilled technical staff, community, and partners who helped to build 
ACME and continue to review and think about it every day. These people are not 
only skilled, but have strong reputations in the security, cryptography, and 
open source communities.

Like I said, we probably can't ever be 100% sure there aren't serious flaws in 
ACME, but I think this constitutes pretty reasonable due diligence. If/when the 
next flaw is found, it'll be found earlier than it might have been due to our 
transparency.

I don't know enough about what StartCom is doing to comment on this thread's 
actual topic, but I do wish others would use ACME (if ACME doesn't work for 
someone, let's talk about what we might do to fix that in the IETF working 
group). If not ACME, then at least something with a well-written public 
specification.

CAs ask the public to trust them and there is no trust without transparency.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartEncrypt considered harmful today

2016-07-02 Thread Eddy Nigg 

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 checks that are not sufficient in
assuring domain ownership, thus the issue was very much a backend issue.
I assume there are reasonable controls in place to prevent misissuance
for high-risk domains, but what about other domains? Would they have
been affected by this?


Hi Patrick,

Depending on the flagging parameters and the attending certificate 
officer, the (some) certificate might or might have not been issued - 
I'm careful with this statement as suspicion can arise for this or the 
other reason, but it's not 100%. High-profile names would have been 
flagged and not issued though.



I would also be curious about why the certificate has not been logged to
CT, given StartCom's prior statements with regards to CT adoption.


We are checking it, it might have been logged at the wrong place. I'll 
try to provide an answer on this too when possible.


--
Regards
Signer: Eddy Nigg, COO/CTO
StartCom Ltd. 
XMPP:   start...@startcom.org 
Blog:   Join the Revolution! 
Twitter:Follow Me 

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

Re: StartEncrypt considered harmful today

2016-07-01 Thread Nick Lamb 
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 of this has come up before in other forums--that 
> these interfaces can ‎be abused and lead to certificate mis-issuance? 

As I understand it StartCom sprang their protocol and its implementation, which 
are proprietary and very thinly documented, as a surprise from first 
announcement to general availability in a day or less - presumably for 
commercial advantage. I'm not aware of - and suspect there hasn't been any - 
independent analysis of their system.

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 
with Mozilla's inclusion process the IETF process ends up partly being a test 
of endurance, as even simple ideas are dragged out over several months with 
posts that have some technical meat being mixed in with axe-grinding and larger 
politics.

Let's Encrypt's implementation of ACME, Boulder, is on github for anyone to 
inspect. I am not aware of any independent formal analysis, but it's obvious 
from the contributions to Boulder that people outside Let's Encrypt do look at 
it.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartEncrypt considered harmful today

2016-07-01 Thread Peter Kurrasch 
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 of this has come up before in other forums--that 
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 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 sure it won't be the last. What
is so special about Let's Encrypt and ACME that you feel the need to
constantly refer to it as though it's some sort of new and special threat to
the PKI ecosystem?

- Matt

___
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

Re: StartEncrypt considered harmful today

2016-07-01 Thread Patrick Figel 
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
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 checks that are not sufficient in
assuring domain ownership, thus the issue was very much a backend issue.
I assume there are reasonable controls in place to prevent misissuance
for high-risk domains, but what about other domains? Would they have
been affected by this?

I would also be curious about why the certificate has not been logged to
CT, given StartCom's prior statements with regards to CT adoption.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartEncrypt considered harmful today

2016-07-01 Thread Christiaan Ottow 
> 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 modulus and signature left out. The
>> SHA256 fingerprint of the certificate is:
>> A7:E5:BD:6E:81:8F:A8:CE:FD:73:97:32:70:06:89:59:98:86:33:5A:06:7E:FD:ED:EA:B6:19:B3:3F:67:F6:A1
> 
> Thanks.  There's no SCT extension, despite StartCom claiming to embed
> SCTs in all certificates they issue.  Also, the cert was issued over a
> week ago, so even if StartCom was logging post-issuance the cert should
> have been logged by now.
> 
> I would like to hear StartCom explain this as well.
> 
> Regards,
> Andrew

If you plan on checking CT logs, make sure to check WoSign-signed certs as 
well. The "caID" parameter in the POST request to the StartEncrypt API allows 
you to select which CA will sign you certificate. The default, "2", makes that 
your request is signed by "StartCom Class 1 DV Server CA", "1" selects "WoSign 
CA Free SSL Certificate G2" and "0" selects "CA 沃通根证书". Perhaps the 
certificates are being logged into a different CT audit server because of this 
feature. 

We selected "1" for a test certificate last week, and the certificate we 
obtained was dated 20 December 2015, and signed using a SHA-1 checksum. I've 
attached the certificate (excluding modulus and signature). The checksum 
(SHA256) of the full cert is 
D1:2F:AB:12:E2:40:70:40:B4:2B:FF:46:FF:9B:A8:BB:8C:1F:63:E4:7F:ED:F2:D3:70:D2:12:3B:54:28:D1:4B

Kind regards,


Christiaan Ottow
CTO Security

Computest • Pine Digital Security
M: +31 (0) 6 51997213 • T: +31 (0) 88 7331337
E: cot...@computest.nl • I: www.computest.nl  
A: Signaalrood 25 • 2718 SH Zoetermeer
P: https://www.pine.nl/4eo3UYWmU.asc
 
Pine Digital Security is part of Computest
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
65:65:e1:71:0a:48:fb:be:1e:2b:61:83:5c:78:9c:39
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=CN, O=WoSign CA Limited, CN=WoSign CA Free SSL Certificate G2
Validity
Not Before: Dec 20 01:27:28 2015 GMT
Not After : Dec 29 16:00:00 2016 GMT
Subject: CN=startssl9.s.xnyhps.nl
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
...
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
E8:A7:BF:9B:15:3A:16:73:8B:AC:9C:D7:23:6F:AF:F3:CD:24:BC:C2
X509v3 Authority Key Identifier:

keyid:D2:A7:16:20:7C:AF:D9:95:9E:EB:43:0A:19:F2:E0:B9:74:0E:A8:C7

Authority Information Access:
OCSP - URI:http://ocsp1.wosign.com/ca6/server1/free
CA Issuers - URI:http://aia1.wosign.com/ca6.server1.free.cer

X509v3 CRL Distribution Points:
URI:http://crls1.wosign.com/ca6-server1-free.crl

X509v3 Subject Alternative Name:
DNS:startssl9.s.xnyhps.nl
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.36305.1.1.2
  CPS: http://www.wosign.com/policy/

Signature Algorithm: sha1WithRSAEncryption
...

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartEncrypt considered harmful today

2016-07-01 Thread Eddy Nigg 

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 have been fixed by our developers (hope there wont be anything more 
significant than that :-) ).


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.


At the moment I don't believe that a public incident report is 
necessary, but should anything change in our current assessment we will 
obviously act accordingly. I instructed additional verifications and 
confirmations to assert that assessment.


--
Regards
Signer: Eddy Nigg, COO/CTO
StartCom Ltd. <http://www.startcom.org>
XMPP:   start...@startcom.org <xmpp:start...@startcom.org>
Blog:   Join the Revolution! <http://blog.startcom.org>
Twitter:Follow Me <http://twitter.com/eddy_nigg>

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

Re: StartEncrypt considered harmful today

2016-06-30 Thread Matt Palmer 
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 sure it won't be the last.  What
is so special about Let's Encrypt and ACME that you feel the need to
constantly refer to it as though it's some sort of new and special threat to
the PKI ecosystem?

- Matt

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

Re: StartEncrypt considered harmful today

2016-06-30 Thread Nick Lamb 
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 only practical vulnerability that could lead to mis-issuance 
(other issues are listed in the article but without enough detail to be sure 
they were sufficient to cause mis-issuance - most certainly somebody 
independent of StartSSL should check these carefully)

* StartSSL keep detailed sufficient records of the circumstances in which they 
issued certificates suitable to verify _for themselves_ what follows below

* We're interested only in the same degree of confidence we have assigned to 
existing DV certificates, such as those verified by email to a WHOIS contact

Then it seems we can achieve that by checking that the default /signfile URL 
was used for verification (not some arbitrary forced URL) and that no HTTP 
redirect was followed.

This would mean either the applicant did own the site, or a hypothetical 
attacker was somehow able to arrange for /signfile, without redirection, to 
contain the desired value, which would be tricky even for most pastebin-type 
sites and impossible for an ordinary web site.

I'm not _happy_ about this, as I understand it the CA/B already discussed a 
revision to the BRs that would require this sort of check to use the 
IETF-approved /.well-known/ prefix. Reason being it's not inconceivable that 
somewhere on the web is a site where an attacker can make paths like /signfile 
contain arbitrary text, it's a LOT less likely to have a site where they can do 
this to a path beginning /.well-known/acme-challenge/

Still though, it does achieve similar levels of confidence to the usual "send 
an email to an address we found in WHOIS and check the applicant can read it" 
approach we see today, and which there is seemingly no hurry to deprecate.

If they don't have the records to check whether redirects were followed or 
whether the default path was used, then I agree they can't hope to achieve the 
usual levels of confidence in their own validation prior to the fix.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartEncrypt considered harmful today

2016-06-30 Thread Andrew Ayer 
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 the certificate is:
> A7:E5:BD:6E:81:8F:A8:CE:FD:73:97:32:70:06:89:59:98:86:33:5A:06:7E:FD:ED:EA:B6:19:B3:3F:67:F6:A1

Thanks.  There's no SCT extension, despite StartCom claiming to embed
SCTs in all certificates they issue.  Also, the cert was issued over a
week ago, so even if StartCom was logging post-issuance the cert should
have been logged by now.

I would like to hear StartCom explain this as well.

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

Re: StartEncrypt considered harmful today

2016-06-30 Thread Christiaan Ottow 
On 30 Jun 2016, at 22:00, Andrew Ayer  wrote:
> 
> 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 informed StartCom that we had only issued
>>> certificates for domains under our control, so I can imagine no red
>>> flags were raised by their helpdesk.
>> 
>> The lack of CT logging is interesting, as StartCom claims that all
>> certificates they issue are being logged to at least three CT
>> servers: https://www.startssl.com/NewsDetails?date=20160323
>> 
>> Do you mind uploading the certificate files that were obtained
>> somewhere and linking us to them?
> 
> It would be best not to release the full certificates quite yet, since
> doing so would make it impossible to determine who logged them if they
> later show up in CT logs.
> 
> Providing a hash of the certificate and the contents of the SCT
> extension, if any, would be OK.
> 
> Regards,
> Andrew

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 
the certificate is:
A7:E5:BD:6E:81:8F:A8:CE:FD:73:97:32:70:06:89:59:98:86:33:5A:06:7E:FD:ED:EA:B6:19:B3:3F:67:F6:A1

Kind regards,


Christiaan Ottow
CTO Security

Computest • Pine Digital Security
M: +31 (0) 6 51997213 • T: +31 (0) 88 7331337
E: cot...@computest.nl • I: www.computest.nl  
A: Signaalrood 25 • 2718 SH Zoetermeer
P: https://www.pine.nl/4eo3UYWmU.asc
 
Pine Digital Security is part of Computest





smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartEncrypt considered harmful today

2016-06-30 Thread Andrew Ayer 
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 informed StartCom that we had only issued
> > certificates for domains under our control, so I can imagine no red
> > flags were raised by their helpdesk.
> 
> The lack of CT logging is interesting, as StartCom claims that all
> certificates they issue are being logged to at least three CT
> servers: https://www.startssl.com/NewsDetails?date=20160323
> 
> Do you mind uploading the certificate files that were obtained
> somewhere and linking us to them?

It would be best not to release the full certificates quite yet, since
doing so would make it impossible to determine who logged them if they
later show up in CT logs.

Providing a hash of the certificate and the contents of the SCT
extension, if any, would be OK.

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

Re: StartEncrypt considered harmful today

2016-06-30 Thread Jonathan Rudenberg 

> 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 
> control, so I can imagine no red flags were raised by their helpdesk.

The lack of CT logging is interesting, as StartCom claims that all certificates 
they issue are being logged to at least three CT servers: 
https://www.startssl.com/NewsDetails?date=20160323

Do you mind uploading the certificate files that were obtained somewhere and 
linking us to them?

Thanks,

Jonathan

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

Re: StartEncrypt considered harmful today

2016-06-30 Thread Christiaan Ottow 
> 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-issued certs were obtained by the researchers? Has there 
> been an investigation to see if there were similarly mis-issued certs 
> prior to this report? 
> 
> Have those certs been revoked? 
> 
> -Dan Veditz 
> 

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 
control, so I can imagine no red flags were raised by their helpdesk.

Kind regards,


Christiaan Ottow
CTO Security

Computest • Pine Digital Security
M: +31 (0) 6 51997213 • T: +31 (0) 88 7331337
E: cot...@computest.nl • I: www.computest.nl  
A: Signaalrood 25 • 2718 SH Zoetermeer
P: https://www.pine.nl/4eo3UYWmU.asc
 
Pine Digital Security is part of Computest





smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartEncrypt considered harmful today

2016-06-30 Thread Phillip Hallam-Baker 
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 not primarily a problem of
> the language used. Or we would never have seen buffer overflows in C.
> Please castigate the implementor instead.


​My college tutor, Tony Hoare used his Turing Award acceptance speech to
warn people why that feature of C was a terrible architectural blunder.

If you are writing security code without strong type checking and robust
memory management with array bounds checking then you are doing it wrong.​
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartEncrypt considered harmful today

2016-06-30 Thread Richard Barnes 
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 operational models.

Honestly, I think the best thing for the industry is to align around one
issuance API so that CAs don't have to keep reinventing the wheel.  In
addition to all the benefits that come from code reuse, it means that you
can go ahead and nail down a bunch of security stuff, so that there are
fewer ways for a CA deploying a new API to screw up.  For example, several
of the issues with the StartEncrypt API have already been raised on the
ACME mailing list and addressed in the draft protocol.  (And to be clear,
though I obviously think ACME is the bee's knees, I would be just as happy
to get alignment around *a* protocol.)

--Richard


On Thu, Jun 30, 2016 at 1:58 PM, Peter Kurrasch  wrote:

> 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 Ten. That we expect
> a scan to be performed at least once per year.
>
> To be sure, that's a pretty low bar but I don't know that all CA's could
> pass even that minimal benchmark today. If so, that's a big problem.
>
>
>   Original Message
> From: Tom Ritter
> Sent: Thursday, June 30, 2016 11:57 AM‎
>
> 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 API
> interface they might be using. I would actually like to see a statement
> regarding any interface, including browser-based, but one step at a time.
> Let's at least know that all the other interfaces undergo regular security
> scans--or when a CA might start doing them.
> >
> > Anyone proposing updates in CABF?
>
> In theory I would support this, in practice it has no teeth. There is
> no (real) accreditation for security reviews, and the accreditations
> that exist do not, in practice, ensure one with the accreditation is
> skilled. You can say "APIs must have a security review" or an
> "adversarial security scan" or a "vulnerability scan", or "manual
> penetration test", or a "red team assessment" - but the definition of
> the terms and the skillsets of people performing them vary so widely
> that it would not guarantee very much in practice.
>
> I believe that the CAs who want to be a leader in this niche already
> are, and the CAs who cannot afford to do so (because I assume every CA
> wants to take security seriously, but is confined in practice) will
> wind up meeting the requirement in a way that does not significantly
> improve their security. (And various shades in between)
>
> But I'm biased, being a security consultant and all.
>
> -tom
> ___
> 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

Re: StartEncrypt considered harmful today

2016-06-30 Thread Peter Kurrasch 
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-issued certs were obtained by the researchers? Has there
been an investigation to see if there were similarly mis-issued certs
prior to this report?

Have those certs been revoked?

-Dan Veditz
___
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

Re: StartEncrypt considered harmful today

2016-06-30 Thread Daniel Veditz 
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-issued certs were obtained by the researchers? Has there
been an investigation to see if there were similarly mis-issued certs
prior to this report?

Have those certs been revoked?

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

Re: StartEncrypt considered harmful today

2016-06-30 Thread Tom Ritter 
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 API interface they might be 
> using. I would actually like to see a statement regarding any interface, 
> including browser-based, but one step at a time. Let's at least know that all 
> the other interfaces undergo regular security scans--or when a CA might start 
> doing them.
>
> Anyone proposing updates in CABF?

In theory I would support this, in practice it has no teeth. There is
no (real) accreditation for security reviews, and the accreditations
that exist do not, in practice, ensure one with the accreditation is
skilled. You can say "APIs must have a security review" or an
"adversarial security scan" or a "vulnerability scan", or "manual
penetration test", or a "red team assessment" - but the definition of
the terms and the skillsets of people performing them vary so widely
that it would not guarantee very much in practice.

I believe that the CAs who want to be a leader in this niche already
are, and the CAs who cannot afford to do so (because I assume every CA
wants to take security seriously, but is confined in practice) will
wind up meeting the requirement in a way that does not significantly
improve their security. (And various shades in between)

But I'm biased, being a security consultant and all.

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

Re: StartEncrypt considered harmful today

2016-06-30 Thread Juergen Christoffel 

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 the implementor instead.


--jc

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

Re: StartEncrypt considered harmful today

2016-06-30 Thread Phillip Hallam-Baker 
Argh

As with Etherium, the whole engineering approach gives me a cold sweat.
Security and scripting languages are not a good mix.

What makes something easy to hack in Perl does not make for good security
architecture.


:(



On Thu, Jun 30, 2016 at 11:30 AM, Rob Stradling <rob.stradl...@comodo.com>
wrote:

> 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 Online
>
> ___
> 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

Re: StartEncrypt considered harmful today

2016-06-30 Thread Peter Kurrasch 
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 API interface they might be 
using. I would actually like to see a statement regarding any interface, 
including browser-based, but one step at a time. Let's at least know that all 
the other interfaces undergo regular security scans--or when a CA might start 
doing them.

Anyone proposing updates in CABF?


  Original Message  
From: 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 you planning to post a public 
incident report?

Thanks.

-- 
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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy