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. 
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 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: ISRG Root Inclusion Request

2016-07-01 Thread Peter Kurrasch 
I'm not sure I follow. Why should the inclusion process proceed before the 
updates are complete?


  Original Message  
From: j...@letsencrypt.org
Sent: Thursday, June 30, 2016 10:04 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: ISRG Root Inclusion Request

On Wednesday, June 8, 2016 at 7:56:44 AM UTC-5, Peter Kurrasch wrote:
> I have comments as well. I made it to only Section 3.2.1 before I decided I 
> have too many concerns about Let's Encrypt to include in a review of the CPS. 
> I'll raise them in a separate thread, so here are my comments on just this 
> CPS document.

Hi Peter,

We've reviewed your feedback, much of it is helpful. Thanks. We'll work on 
incorporating improvements based on it into the next revision of our CPS. We 
don't believe any of these items need to block inclusion, however.

--
Josh Aas
Executive Director
Internet Security Research Group
Let's Encrypt: A Free, Automated, and Open CA
___
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 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 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: ISRG Root Inclusion Request

2016-07-01 Thread Ryan Sleevi 
On Fri, Jul 1, 2016 at 12:31 PM, Peter Kurrasch  wrote:
> I'm not sure I follow. Why should the inclusion process proceed before the 
> updates are complete?

Because the concerns you have raised are not requirements of the
Mozilla CA Inclusion Policy, nor do they appear to be part of the
Baseline Requirements.

At more fundamental question is whether the concerns you raised
present risk to relying party communities. While you personally may
feel they do, I'm not sure that's a reasonable conclusion, but I'm
still working through your feedback as well to see whether it's
reasonable. As you can see from the list, others have disagreed with
some of your concerns, and I concur with them.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Security attacks on Firefox.

2016-07-01 Thread John T. McF. Mood AA4PC 
A web site or two out there is spawning a false (probably malicious) 
patch to Firefox. I will give you what I can.


https://eijugonsemi.net/495416513016/3538a5ce1e43f7196a2500a98cfe73ad.html

-- This link starts a download to the "Patch". I of course refused to 
download or run the "Patch".


The web page I was on that spawned this was:

http://www.thepoliticalinsider.com/leaked-outrage-michelle-obamas-moroccan-vacation/?utm_source=SailThru%26utm_newsletter_medium=email_campaign=TPI%20Newsletter%2007-01-16%20Best%20of%20Week%20Friday%20Sends_term=New%20Friday%20Active%20Users

I'm not sure what the trigger on that page is, it may be a rollover, a 
non-clicked event, or closing an annoying advert, but it did spawn from 
this page.


I also got many "Script Non-responsive warnings" about that page.

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