Re: Intermediate common name ambiguous naming

2020-12-11 Thread Hanno Böck via dev-security-policy
Hi,

On Fri, 11 Dec 2020 10:51:44 +
Burton via dev-security-policy 
wrote:

> The common name of the Let's Encrypt R3 intermediate certificate (
> https://crt.sh/?id=3479778542) is in my opinion short and ambiguous.
> It doesn't have any information in common name that can identify the
> operator of the CA "Let's Encrypt" which can cause confusion who is
> running the CA.
> 
> The intermediate certificate common name "R3" naming shouldn't be
> allowed. It's like the past root store naming that had ambiguous
> naming such as "Root CA".

I am somewhat "guilty" of that because I proposed to Let's Encrypt [1]
to try to shorten strings in the intermediate in order to make it
smaller (it is transmitted very often, so small savings matter).

The rationale in the discussion for the R3 common name was that the
organizationName already contains "Let's Encrypt" and is required,
thus putting the CA name into the CN is redundant.

I guess this comes down to the question whether you expect the common
name on its own to be meaningful in intermediate certs or if you
consider the whole subject. If you manage your CA store by always
showing the whole subject this problem does not exist. I feel this
makes sense, if an organizationName is required anyway then there
shouldn't be a need. And given that certs are transmitted very often
and the info in the subject is read rarely (it is after all just
informational and has little technical meaning except for identifying
the cert) I feel there shouldn't be rules that make this info
needlessly long.

[1]
https://community.letsencrypt.org/t/lets-encrypt-new-hierarchy-plans/125517/18
-- 
Hanno Böck
https://hboeck.de/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: CA Issuer AIA URL content types

2020-05-22 Thread Hanno Böck via dev-security-policy
Hi,

On Fri, 22 May 2020 09:55:22 -0400
Ryan Sleevi via dev-security-policy
 wrote:

> Could you please cite more specifically what you believe is wrong
> here? This is only a SHOULD level requirement.

I think I said that more or less:

> > I'm not going to file individual reports for the CAs. Based on
> > previous threads I don't believe these are strictly speaking rule
> > violations.

I'm not claiming this is a severe issue or anything people should be
worried about.
It's merely that while analyzing some stuff I observed that AIA fields
aren't as reliable as one might want (see also previous mails) and the
mime types are one more observation I made where things aren't what they
probably SHOULD be.
I thought I'd share this observation with the community.

-- 
Hanno Böck
https://hboeck.de/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Non-DER certificate (PKCS #7) in CA Issuers AIA field

2020-05-22 Thread Hanno Böck via dev-security-policy
Just reported this to Chunghwa Telecom Co., Ltd.:

--

I'm contacting you about a problem with the certificate for
*.hinet.net, as it can be found here [1].

The Authority Information Access / CA Issuers field points to:
http://repository.publicca.hinet.net/certs/IssuedToThisCA.p7b

According to RFC 5280 this must be a DER-encoded certificate. See also
recent discussion on the Mozilla policy list [2].
However this does not look like a different certificate encoding (PKCS
#7 binary).

Please make sure you serve a correct, DER-encoded intermediate via the
AIA field.

[1] https://crt.sh/?id=206075223
[2]
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/g09ZgCRPVe0

-- 
Hanno Böck
https://hboeck.de/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


CA Issuer AIA URL content types

2020-05-22 Thread Hanno Böck via dev-security-policy
Hi,

Doing some analysis on the AIA CA Issuer field I checked the content
types the certificates are served. These are the AIA issuer fields in
the top 1 from the alexa list, so this is incomplete.

According to RFCs application/pkix-cert is the only correct
content-type. However the majority serve application/x-x509-ca-cert.
According to this [1] documentation this is an old Netscape thing and
doesn't seem to be part of any standard.

Several certificates have mime types that look plain wrong.

text/html:
http://swisssign.net/cgi-bin/authority/download/E7F1E7FD2E53AD11E5811A57A4738F127D98C8AE
http://swisssign.net/cgi-bin/authority/download/EEFD46CAF7275E91BC5AB6E787CD0AFA550A2642
http://certificates.godaddy.com/repository/gdig2.crt.der

application/octet-stream:
http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%201.crt
http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%202.crt
http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%204.crt
http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%205.crt

Some have no content-type:
http://certificates.godaddy.com/repository/gdig2.crt
http://certificates.starfieldtech.com/repository/sfig2.crt
http://www.camerfirma.com/certs/camerfirma_cserverii-2015.crt
http://www.izenpe.com/contenidos/informacion/cas_izenpe/es_cas/adjuntos/SSLEV_cert_sha256.crt
http://www.izenpe.eus/contenidos/informacion/cas_izenpe/es_cas/adjuntos/AAPPNR_cert_sha256.crt

One more case looks like it's not a certificate at all, I'll check that
individually and will come back with a report later.

I'm not going to file individual reports for the CAs. Based on previous
threads I don't believe these are strictly speaking rule violations.
However I still recommend that CAs reading this check their own
intermediates and make sure they are served as application/pkix-cert.



[1] https://pki-tutorial.readthedocs.io/en/latest/mime.html

-- 
Hanno Böck
https://hboeck.de/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Mozilla's Expectations for OCSP Incident Reporting

2020-05-15 Thread Hanno Böck via dev-security-policy
On Fri, 15 May 2020 10:13:01 -0400
Lee via dev-security-policy 
wrote:

> How is this situation different from the time when the google ocsp
> service was down?

Maybe some clarification here:
The Google OCSP was the OCSP for end entity certificates.
The Identrust OCSP was the OCSP server for intermediate certs.

Checking OCSP for intermediates is less common than checking OCSP for
end entity certificates.

So there is a difference. However I still believe OCSP servers should
not be offline for longer periods of time in both cases :-)

-- 
Hanno Böck
https://hboeck.de/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: AIA CA Issuer field pointing to PEM encoded certs

2020-05-13 Thread Hanno Böck via dev-security-policy
Update:
All 4 CAs have corrected the certs and are now serving DER
encoded intermediates at the URLs.

-- 
Hanno Böck
https://hboeck.de/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Mozilla's Expectations for OCSP Incident Reporting

2020-05-13 Thread Hanno Böck via dev-security-policy
On Wed, 13 May 2020 02:29:07 +
Peter Gutmann via dev-security-policy
 wrote:

> Following up on this, would it be correct to assume that, since
> no-one has pointed out any impact that this had on anything, that
> it's more a certificational issue than anything with real-world
> consequences?

I have reported (and noticed) it because it had an impact.

The impact it had was a monitoring system that checked whether the
certificate of a host was okay, using gnutls-cli with ocsp enabled
(which also uncovered a somewhat unexpected inconsistency in how
the gnutls cli tool behaves[1]).

Not saying this is a particularly severe impact, however it took me
some time figuring out what's going on there.
It may very well that others have experienced impact that they were
unable to explain.


[1] https://gitlab.com/gnutls/gnutls/-/issues/981
-- 
Hanno Böck
https://hboeck.de/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: AIA CA Issuers URL gives 403 (Microsoft)

2020-05-11 Thread Hanno Böck via dev-security-policy
Hi,

On Mon, 11 May 2020 10:53:26 +0200
Hanno Böck via dev-security-policy
 wrote:

> I did some checks on certificates and their AIA sections and noticed
> that several Microsoft certificates were referencing intermediate
> certificates in the "CA Issuer" field that give a 403 error.
> 
> http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%201.crt
> http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%202.crt
> http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%204.crt
> http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%205.crt

So there's a somewhat unexpected update here:

After communicating with Microsoft it turns out this is due to user
agent blocking, the URLs can be accessed, but not with a wget user
agent.
Microsoft informed me that "the wget agent is explicitly being blocked
as a bot defense measure."

I leave it up to the community to discuss whether this is acceptable. I
stronly feel it's not and I feel that this is public information that
should be accessible without any hurdles, and there's no need to have
any "bot defense" on a static file that should be public information.

-- 
Hanno Böck
https://hboeck.de/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


AIA CA Issuer field pointing to PEM encoded certs

2020-05-11 Thread Hanno Böck via dev-security-policy
Hi,

As I mentioned in my previous mail I found some instances of CAs
pointing to PEM encoded certificates in their AIA fields, while they
should be DER encoded.

I found such instances for 4 CAs, I'll list them with one example cert
and the URL of the referenced intermediate.

Entrust/Affirmtrust:
https://crt.sh/?id=2747041731
http://aia.affirmtrust.com/aftov1ca.crt

Telia:
https://crt.sh/?id=2793617446
http://repository.trust.teliasonera.com/teliasoneraservercav2.cer

Multicert:
https://crt.sh/?id=2369674005
http://pki.multicert.com/cert/SSL_CA01.cer

TWCA:
https://crt.sh/?id=1238438742
http://sslserver.twca.com.tw/cacert/secure_sha2_2014.crt

I have informed all 4 CAs via their problem reporting mechanism from
CCADB.

-- 
Hanno Böck
https://hboeck.de/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


AIA CA Issuers field

2020-05-11 Thread Hanno Böck via dev-security-policy
Hi,

I have been doing some checks on certificates with the AIA Issuers
field. I already reported certificates with a 403 error on the HTTP url
of the intermediate (see earlier mail).

Now there's more stuff to be found and I'm wondering:
* Are there rules that CAs must adhere to in regards to referencing the
  intermediate in the AIA field? Does it need to be available? Does it
  need to be there at all?

* It seems common practice and desired by RFCs to have the intermediate
  referenced in binary DER format and not PEM encoded. But some
  certificates do reference PEM encoded intermediates. Is this a
  violation of any rule and should this be reported as an incident?

* RfC 5280 says certificates should be served as
  "application/pkix-cert". Is it a violation of any rule if they are
  not? (application/x-x509-ca-cert is common, no content type and
  completely bogus content types linke text/html also happen.)

-- 
Hanno Böck
https://hboeck.de/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


AIA CA Issuers URL gives 403 (Microsoft)

2020-05-11 Thread Hanno Böck via dev-security-policy
I did some checks on certificates and their AIA sections and noticed
that several Microsoft certificates were referencing intermediate
certificates in the "CA Issuer" field that give a 403 error.

http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%201.crt
http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%202.crt
http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%204.crt
http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%205.crt

These are listed in active use on certificates on public hosts
(e.g. azure.com, msn.com, skype.com, xbox.com).

I have informed Microsoft through the contact mail address in the CCADB.

-- 
Hanno Böck
https://hboeck.de/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Paessler (was Re: Let's Encrypt: Failure to revoke key-compromised certificates within 24 hours)

2020-03-22 Thread Hanno Böck via dev-security-policy
On Sat, 21 Mar 2020 19:20:27 +
Nick Lamb via dev-security-policy
 wrote:

> Rather than mint an RSA key pair and self-signed certificate to
> bootstrap each install, they just supply a (presumably randomly
> generated) key and certificate right in the install data.

FWIW: Given that with the private key it's easily possible to revoke
certificates from Let's Encrypt I took the key yesterday and iterated
over all of them and called the revoke command of certbot.

They were all already revoked except for the latest [1], which was
issued on the 20th of march.

Now there's this [2] certificate with the same key that apparently got
revoked on the 19th.

I strongly recommend Let's Encrypt (and probably all other CAs)
blacklists that key if they haven't already done so.

[1] https://crt.sh/?id=2603336468
[2] https://crt.sh/?id=2574981982

-- 
Hanno Böck
https://hboeck.de/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Sectigo-issued certificates with concerningly mismatched subject information

2020-01-26 Thread Hanno Böck via dev-security-policy
On Sun, 26 Jan 2020 01:59:33 -0800 (PST)
Ian Carroll via dev-security-policy
 wrote:

> These certificates expired in 2019 and are thus no longer a problem,
> but they were actively used by the customer (e.infinityspeakers.com
> still serves one of them) and it does not appear anyone has noticed.

I guess this is the most relevant part here. Noone has noticed.

I see that a lot of people are having fun pointing out these issues
again and again to show how sloppy CAs work. Which is fine I guess, but
it leads to the question what the point of all this is. Maybe it's time
to change the WebPKI rules to reflect that - either say "any information
in a certificate that is not the CN/SAN is yolo and can be whatever and
web clients should make sure they never display that informaiton" or
"any useless extra information should be skipped".

Let's be honest: There are two reasons these extra fields exist in the
first place, and no good one. One reason is they are legacy baggage from
the X.509 standard. If we'd rewrite the webpki today we wouldn't have
such fields. The other is that they are upselling features where CAs can
create the illusion that there are more or less valuable certificates.

-- 
Hanno Böck
https://hboeck.de/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Certinomis Issues

2019-05-28 Thread Hanno Böck via dev-security-policy
Hi,

I just saw this on twitter:
https://twitter.com/sam280/status/1133008218677022722


And later in the thread:
https://twitter.com/sam280/status/1133112699385257985

The first tweet points out that Certinomis seems to use wrong OIDs in
their certs (quote "Of course the first invalid #PSD2 #QWAC had to come
from Certinomis... guys, the entire PSD2 roles OID arc is not meant to
be included in the list of certificate policies"). I don't know what
PSD2 and QWAC means, I'll leave it to others to interpret how big of an
issue this is.

The second tweet points to a cert issued for an unregistered domain:
https://crt.sh/?id=1514142478

That obviously seems like a big deal. (Cert issued 2 days ago, so I
believe it's unlikely that this domain existed at the point this cert
was generated.)

I understand the removal of Certinomis from NSS is already decided, but
maybe these incidents justify some acceleration.


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: DarkMatter Concerns

2019-02-26 Thread Hanno Böck via dev-security-policy
This statement repeats the claim that you wrote here previously,
specifically:
"I want to assure you that DarkMatter's work is solely focused on
defensive cyber security, secure communications and digital
transformation."

The statement does not comment on the Reuters article, but it is in
stark contradiction to it, as it clearly describes "offensive cyber"
operations by Dark Matter.

I find it very hard to believe that the entire Reuters story is a hoax.
Nobdody has challenged it yet. According to the Reuters article
DarkMatter was asked for a comment and didn't reply.

Either the Reuters story is false or your CEOs statement is false. They
can't both be true.


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

2019-01-24 Thread Hanno Böck via dev-security-policy
On Thu, 24 Jan 2019 11:14:11 +
"Buschart, Rufus via dev-security-policy"
 wrote:

> You are right, of course there are mandatory RFC to take into
> account. But there is - to my knowledge - no RFC that says, you MUST
> NOT issue a certificate to a domain that could be interpreted as an
> IDNA2008 punycode.

https://tools.ietf.org/html/rfc5891

4.2.3.1.  Hyphen Restrictions

   The Unicode string MUST NOT contain "--" (two consecutive hyphens) in
   the third and fourth character positions and MUST NOT start or end
   with a "-" (hyphen).

This means you can't have a valid host name that is just
xn--[something]. You can only have it if it is also a valid IDN name.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


AlwaysOnSSL web security issues

2019-01-09 Thread Hanno Böck via dev-security-policy
Hi,

AlwaysOnSSL was a free certificate authority operated by CertCenter.
I recently noticed that their main webpage was gone, but pieces of the
service were still online.
I immediately found a few web security issues. I reported those to
certcenter and digicert (which is the root CA their intermediate chains
to).

This is what I reported:

Partly disfuctional
===

The service seems to be partly disfunctional. The start page is just
showing an empty document.

However when directly calling subpages, e.g.
https://alwaysonssl.com/issue.php
there still seems to be an operational service.

This looks to me like AlwaysOnSSL is not actively maintained.

XSS
===

The certificate issuance form has a trivial injection issue. Simply
putting something like ">test will inject HTML. CSP+XSS Auditor
prevent this from being a simple XSS, but I'm pretty sure this can be
bypassed with enough effort.

CSRF


The forms don't seem to contain any CSRF tokens. I haven't analyzed
this in detail, but I believe this likely means an attacker can
interfere with the issuance process and may be able to inject his own
CSR and forge a certificate.

Account management
==

I have an existing account for alwaysonssl.com from previous tests.
There seems to be no way of either deleting the account or changing the
password. I consider not offering a password changing option a security
problem as well.


I believe all of these issues show that alwaysonssl.com is an
unmaintained, partly broken service with a total lack of secure coding
practice, yet it's able to issue valid certificates that chain down to
a digicert root.

-


In response to this the service was completely disabled.

In one of the response mails CertCenter wrote me:
"Among other things, we operate a web application firewall that
prevent requests when it detects dangerous data. An XSS request like
the one you carried out apparently did not consider the WAF to be
relevant."

This IMHO shows a serious lack of knowledge about web security basics
and an undeserved trust in WAFs. (The WAF filter was easily bypassable,
they also had a CSP which I believe was bypassable, too, but they
switched the service off before I could show that.)

Given the service is switched off now I think there's nothing
particularly to do, but maybe it's a reminder to have a closer look at
the security of CA issuance web systems.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: How harsh (in general) should Mozilla be towards CAs?

2018-11-09 Thread Hanno Böck via dev-security-policy
On Fri, 9 Nov 2018 14:56:41 +0100
Jakob Bohm via dev-security-policy
 wrote:

> However there are also some very harsh punishments handed out, such as
> distrusting some CAs (most notably happened to Symantec and WoSign,
> but others are also teetering), and distrusting auditors (most notably
> happened to the branch of Ernst & Young that audited the bad parts of
> those two).
> 
> A line of arguments often seen is that someone failed once to do
>  completely right, therefore they cannot be trusted to do
> anything similar to  right at all, therefore they should no
> longer be trusted.

I don't think anyone ever said something like that. Particularly
I'm not aware of any recent incident where a CA failed *once* and got
distrusted.

In the cases you mention - Symantec and Wosign - there were multiple
issues. In both cases there was also plenty of opportunity for the
affected CAs to explain and improve things before a distrust was
even considered. It was repeated failures and a long list of issues
that led to the distrust.


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


New certificate from compromised key

2018-08-17 Thread Hanno Böck via dev-security-policy
Hi,

Some of you may remember the discussion about embedded private keys in
Blizzard's battle.net software here:
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/pk039T_wPrI/VYi629oGCwAJ

One of the certificates with a compromised key back then was issued by
Digicert:
https://crt.sh/?id=287530764

I noticed that a new certificate for a different domain, but with that
same private key has been issued:
https://crt.sh/?id=638323656

I tried to report it to rev...@digicert.com - but that address was
replying with an error message...

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: localhost.megasyncloopback.mega.nz private key in client

2018-08-09 Thread Hanno Böck via dev-security-policy
On Thu, 9 Aug 2018 13:24:48 +
Jay Wilson via dev-security-policy
 wrote:

> The certificate has been revoked.
> The bounce issue has been escalated to resolve.

Really?

$ ocspverify 630835231.crt 
Response verify OK
630835231.crt: good
This Update: Aug  4 15:34:50 2018 GMT
Next Update: Aug 11 15:34:50 2018 GMT


crt.sh also says "Good" on OCSP:
https://crt.sh/?id=630835231=ocsp

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: localhost.megasyncloopback.mega.nz private key in client

2018-08-08 Thread Hanno Böck via dev-security-policy
On Sun, 5 Aug 2018 15:23:42 -0500
Alex Cohn via dev-security-policy
 wrote:

> The certificate [1] in the GitHub link you posted was issued by
> Comodo, not by GeoTrust. The two share a private key, though, so both
> the Comodo and GeoTrust certs should be considered compromised at
> this point. I've added the Comodo-issued cert to several CT logs for
> tracking, and I'm CCing ssl_ab...@comodoca.com for followup.

As of today this is still unrevoked:
https://crt.sh/?id=630835231=ocsp

Given Comodo's abuse contact was CCed in this mail I assume they knew
about this since Sunday. Thus we're way past the 24 hour in which they
should revoke it.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Unrevoked/unexpired certificate with Debian Weak Key

2018-05-14 Thread Hanno Böck via dev-security-policy
Hi,

Yesterday was the 10y anniversary of the Debian OpenSSL random number
generator bug.

A few days ago I did a re-check of the CT logs for vulnerable keys.

I found one unexpired, unrevoked certificate issued by a CA called
"QuoVadis". I reported it and it's been revoked, they told me they'll
check their systems why this certificate issuance wasn't blocked.

https://crt.sh/?id=308235142

I also found an unrevoked Wosign cert that I had already reported last
year. The abuse contact of wosign bounces mails.

(My check was semi-thorough, I didn't have access to all the possible
key combinations that could be generated with the Debian bug. There may
be more certs in the logs.)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Comodo and Trustico (was Re: Trustico code injection)

2018-03-02 Thread Hanno Böck via dev-security-policy
On Fri, 2 Mar 2018 16:10:52 +0900
Hector Martin 'marcan' via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:

> And what does Comodo think of all of this?

I'd like to second this.

When I wrote the original mail in this thread I considered adding
questions to Comodo, but I thought it's so obvious and Comodo people
will see this anyway that it's not necessary.

But yesterday, hours after the whole Trustico thing was unfolding,
Comodo's Twitter account sent out tweets indicating that they're proud
to be the new partner of Trustico:
https://twitter.com/Comodo_SSL/status/969302576649908226

So hereby I'd like to ask Comodo:
* Do you have any security vetting of your certificate reseller
  partners? Do you expect them to follow good security practice?
* Do you believe - given the events of recent days - that Trustico
  follows good security practice?

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Trustico code injection

2018-03-01 Thread Hanno Böck via dev-security-policy
Hi,

On twitter there are currently some people poking Trustico's web
interface and found trivial script injections:
https://twitter.com/svblxyz/status/969220402768736258

Which seem to run as root:
https://twitter.com/cujanovic/status/969229397508153350

I haven't tried to reproduce it, but it sounds legit.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Allowing WebExtensions to Override Certificate Trust Decisions

2018-02-27 Thread Hanno Böck via dev-security-policy
Hi,

On Tue, 27 Feb 2018 09:20:33 -0700
Wayne Thayer via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:

> This capability existed in the legacy Firefox extension system that
> was deprecated last year. It was used to implement stricter security
> mechanisms (e.g. CertPatrol) and to experiment with new mechanisms
> such as Certificate Transparency and DANE.

Wouldn't be a good compromise to say: Extensions can downgrade
security, but they can't upgrade it?
I.e. if a certificate is valid according to "normal" WebPKI validation
but there's an additional validation mechanism that fails the extension
could say "tread this like an untrusted cert", but it couldn't say
"our positive validation of that cert overrides the normal validation".

Is there any existing use case that would not work with that?

As far as I can see and if I understand it right all of those examples
should be able to work on top of existing validation.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Certificate for com and it

2018-02-08 Thread Hanno Böck via dev-security-policy
On Thu, 8 Feb 2018 15:50:08 +
Gervase Markham via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:

> In this case, the certificates are revoked in Firefox via OneCRL and
> Chrome via CRLSets (AIUI) and so the revocations are guaranteed to be
> noticed.

Hi Gerv,

Independent of this specific case, which I guess is mostly harmless, I
find this worrying.

Let's assume something like this happens:
* CA xyz, which is trusted by Mozilla and other root stores, issues a
  sub-certificate for company SuperShady Inc. Immediately after that
  CA xyz asks Mozilla to include it into OneCRL and Google to include
  it in CRLsets.
* SuperShady Inc. starts selling certificates. Their offer is that you
  can get a certificate for every domain you want, the price depends on
  how popular the domain is. If you pay enough you can get a
  certificate that's valid for google.com or facebook.com.
* SuperShady Inc. advertises their certificates with the fact that
  while they won't be valid in mainstream browsers due to revocation
  lists they still work in many situations, i.e. they will be
  considered valid by commandline tools or API calls from many
  programming languages as they don't include a mechanism like OneCRL.

I'm aware that this goes into the tricky topic of people consuming the
Mozilla CA root store without implementing the full certificate
validation logic, which is already a problem with deprecated CAs like
the old Symantec roots that are phased out.
But this is much more sever. While we don't expect that the
Symantec roots have been operated with the care we expect from a CA we
also don't have any indication that they're used for outright malicious
purposes.

Yet I feel what you and others here are implying is that once a subca
is part of OneCRL and revoked they're no longer bound to any standards
at all.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Certificate for com and it

2018-02-08 Thread Hanno Böck via dev-security-policy
Hi,

On Tue, 6 Feb 2018 16:56:48 +0100
Kurt Roeckx via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:
> I should probably more clear, the certificates of the CA have been
> revoked.

I'm wondering what that means.

Is a revoked intermediate cert a license for operating a yolo CA that
signs everything? Given the fragility of revocation checking I'd find
that a problematic precedent.

The OCSP seems operational and replies with "Good" and the issuance
happened before it's being added to OneCRL.
I don't find a reference why this intermediate had been added to
OneCRL, but I think this deserves more clarification what's going on
here.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Certificate for com and it

2018-02-06 Thread Hanno Böck via dev-security-policy
This certificate
https://crt.sh/?id=282908507
is issued for the names "com" and "it".

It also contains other suspicious hostnames:
sip.fideuram
sip.consule
sip.consultant.fideura

I don't think these TLDs exist.

Issuer is "Intesa Sanpaolo CA Servizi Esterni Enhanced", which is
a subca of Baltimore Cybertrust, which belongs to Digicert.

Source: https://twitter.com/OhDearApp/status/960520419831894016

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Certificates with 2008 Debian weak key bug

2018-02-05 Thread Hanno Böck via dev-security-policy
On Mon, 5 Feb 2018 12:07:06 -0500
Eric Mill via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:

> WoSign and StartCom are untrusted, but Certum is still trusted, right?

Yes.

In case that was unclear: The sentence "As we all know these are no
longer trusted by Mozilla, ..." was referring to the chapter above,
i.e. the three Startcom+Wosign certs, not the whole mail.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Certificates with 2008 Debian weak key bug

2018-02-05 Thread Hanno Böck via dev-security-policy
Hi,

I searched crt.sh for valid certificates vulnerable to the 2008 Debian
weak key bug. (Only 2048 bit.)

Overall I found 5 unexpired certificates.

Two certificates by Certum (reported on Saturday, Certum told me "We
have taken necessary steps to clarify this situation as soon as
possible", they're not revoked yet):
https://crt.sh/?id=308392091=ocsp
https://crt.sh/?id=663=ocsp

Wosign:
https://crt.sh/?id=30347743
StartCom:
https://crt.sh/?id=54187884
https://crt.sh/?id=307753186

As we all know these are no longer trusted by Mozilla, I reported them
nevertheless. No reply yet.

Old bugs never die, I recommend every CA adds a check for the Debian
bug to their certificate issuance process.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Google OCSP service down

2018-01-21 Thread Hanno Böck via dev-security-policy
Hi,

On Sun, 21 Jan 2018 12:09:23 -0800 (PST)
Ryan Hurst via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:

> We maintain contact details both within our CPS (like other CAs) and
> at https://pki.goog so that people can reach us expeditiously. In the
> future if anyone needs to reach us please use those details.

I just tried to see what I'd do if I wanted to report issues with
Google's CA (assuming I don't know where its webpage lives and assuming
I don't know any Googlers to report this directly).

When I look into the cert details the certificates for Google webpages
are issued by
"Google Internet Authority G2"

If I goole for that I end up at
https://pki.google.com/

This page has a similar style as the pki.goog, but notably it doesn't
list any contact info. It has an FAQ, but that doesn't have any
question of the form "How do I report a problem with your CA?"

The only thing that might be helpful is a pointer to report security
incidents. I'd probably have done that, though I would be unsure, as
it's debatable whether an offline OCSP counts as a security issue.


Meta-comment:

I think the whole CA incident reporting question has lots of room for
improvement. And I think this should be considered in a way that people
who are not familiar with the details of the CA ecosystem can
successfully report incidents. I.e. saying "you can find all the
contact info in our CPS" is not particularly helpful, as nobody outside
a small circle of people knows what that is.
I think if people try the "natural" way of contacting a certificate
issuing entity this should lead to a successful outcome. (And that is
more or less "This has been issued by X, so I try to contact X".)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Compromised certificate for localhost.cmdm.comodo.net / Comodo ITSM

2018-01-12 Thread Hanno Böck via dev-security-policy
Hi,

Comodo ITSM (IT Service Management Software) runs an HTTPS server on
localhost and port 21185. The domain localhost.cmdm.comodo.net pointed
to localhost.

It is obvious that with this setup the private key is part of the
application and thus compromised. With advanced next generation key
extraction software (strings and grep) I was able to extract the
private key from the software executable.

There exist two certificates that use the same key plus two
precertificates. Only one of the certificates is still valid, the other
is expired. List:
https://crt.sh/?spkisha256=accbb60afe2d28949e21d76f298a2f20c0a24488ad0980ea31b4c0e04b952879

I reported this to Comodo earlier today and the certificate got revoked
very quickly. It was pointed out to me that Comodo ITSM was developed
by Comodo Security Solutions and that Comodo CA played no part in the
development of that software.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: DYMO Root CA installed by Label Printing Software

2018-01-09 Thread Hanno Böck via dev-security-policy
Hi,

On Tue, 09 Jan 2018 21:04:34 +
Nicholas Humfrey via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:

> What is the correct way for them to achieve what they are trying to
> do?
> 
> Would it be better to use a self-signed localhost certificate (same 
> subject and
> issuer), generated individually on each machine it is installed on?

I covered this in detail in the last Bulletproof TLS Newsletter:
https://www.feistyduck.com/bulletproof-tls-newsletter/

Creating a local root on each host individually *with an individual
private key* is kinda okay. The cleaner solution is to connect via http
and the localhost IP (127.0.0.1), which should not throw mixed
contentwarnings - however not all browsers support that yet.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

2017-12-25 Thread Hanno Böck via dev-security-policy
On Mon, 25 Dec 2017 14:43:21 +
Jeremy Rowley via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:

> Without the private key, im not sure how we're supposed to confirm
> key compromise. 

I've pinged a few people with the right skillset to try to extract the
key. But if there are people here who feel capable feel free. (I already
tried the "simple" means, e.g. grepping through files.)

But one question: In the case of EA the cert got revoked and nobody
asked for the key as evidence. What happened there? Did EA ask for the
revocation? (I made them aware, but I have no knowledge of what happened
afterwards.)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

2017-12-25 Thread Hanno Böck via dev-security-policy
On Mon, 25 Dec 2017 04:19:58 -0800 (PST)
"Adrian R. via dev-security-policy"
<dev-security-policy@lists.mozilla.org> wrote:

> Side question: why wasn't the certificate from DigiCert logged into
> Certificate Transparency logs when it was issued and it had to be
> discovered this way?

There's no requirement for CT logging yet. 

Right now certs can end up in the CT log because:
1. the CA voluntarily submits them (LE does).
2. there's been a special situation that the CA needs to log certs
(e.g. this happened to Symantec after the first issues with them)
3. it's submitted by some third party. (everyone can do so.)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

2017-12-25 Thread Hanno Böck via dev-security-policy
Thanks, I also got it in the meantime and submitted it to CT:
https://crt.sh/?id=287530764

Bugreport:
https://bugzilla.mozilla.org/show_bug.cgi?id=1427034

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

2017-12-25 Thread Hanno Böck via dev-security-policy
On Sun, 24 Dec 2017 23:07:56 -0800 (PST)
"Adrian R. via dev-security-policy"
<dev-security-policy@lists.mozilla.org> wrote:

> on any computer with BattleNet installed and active go to this url:
> 
> https://127.0.0.1:22886/
> and currently it uses this certificate... which doesn't appear on
> crt.sh yet

I'm not able to reproduce this. Right now if I install battle.net I
don't get a listening port on 22886 at all. Can you please export the
certificate and send it here?


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Key compromise and root cert with shared key in german lawyer communication software (beA)

2017-12-23 Thread Hanno Böck via dev-security-policy
Hi,

The german bar association has a software for secure communication
between lawyers called "besonderes elektronisches
Anwaltspostfach" (beA).

They used a local https server run on the client with a valid
certificate for bealocalhost.de (the domain resolves to 127.0.0.1).
This means the private key is part of the software, so this is a key
compromise. This has been reported by Markus Drenger to the CA and it
got revoked.
Here's the cert:
https://crt.sh/?id=285821301

What happened after that is no longer relevant for the PKI as a whole,
but is even worse for the users of beA: They used a self-signed
certificate and asked the users to import that into the Windows root
certificate store. Thus the same problem appears as with Superfish,
edell and similar: Everyone can now sign certificates for arbitrary
hosts and use them to perform man in the middle attacks against the
users who followed these instructions.

Starting January 1st all lawyers in Germany have to use this beA
software.

Article in German:
https://www.golem.de/news/bea-bundesrechtsanwaltskammer-verteilt-https-hintertuere-1712-131845.html

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

2017-12-21 Thread Hanno Böck via dev-security-policy
Hi,

Tavis Ormandy recently tweeted this:
https://twitter.com/taviso/status/938503794098180096

What's happening here: The software battle.net by Blizzard has a domain
localbattle.net that points to localhost, allowing the software to
serve content there. The content is served via HTTPS with a valid cert,
making it obvious that the private key is part of the software.

I talked to Tavis, reported the issue to the CA and to Mozilla's
bugtracker. I learned that there's a practically identical issue with
EAs origin.net software.
I also heard a claim that "everyone does this", however this seemed to
refer to examples from the past that are already known. I briefly
checked other gaming software (steam, uplay), but didn't find anything
alike. (Which doesn't mean it's not there - but I didn't see open
ports after running the software that were served with TLS.)

Both certificates have been revoked. I don't have any detailed
information about what these local connections were used for, if they
changed anything and if anything broke due to the revocations, but I
haven't seen any reports of breakage (I checked twitter for signs of
it).
I also was not able to extract the private keys with simple methods
(grep), but it is almost certainly possible. (Full disclosure: Doing
anything on a Windows system is not my strength.)

In any case: If you are aware of other software doing something alike
please report it. This is a key compromise.

Bug EA:
https://bugzilla.mozilla.org/show_bug.cgi
Cert EA:
https://crt.sh/?id=54134792

Bug Blizzard:
https://bugzilla.mozilla.org/show_bug.cgi?id=1425166
Cert Blizzard:
https://crt.sh/?id=26142

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

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


Re: On the value of EV

2017-12-11 Thread Hanno Böck via dev-security-policy
Hi,

On Mon, 11 Dec 2017 11:01:10 -0800 (PST)
Ryan Sleevi via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:

> I suppose this is both a question for policy and for Mozilla - given
> the ability to provide accurate-but-misleading information in EV
> certificates, and the effect it has on the URL bar (the lone trusted
> space for security information), has any consideration been given to
> removing or deprecating EV certificates?

I support the removal of special treatments and UI for EV
certificates.

Rationale: I believe plenty of security research shows that it is
incredibly hard to communicate security indicators to users. If you ask
average users about the meaning of green locks, green URL bars or
anything else they will usually not know what it means.

This lets only one sensible conclusion: Security indicators should be
removed. The goal should be to have one security level that is the
default (HTTPS+DV) and make that as secure as possible. The community
should therefore try to strengthen the CA ecosystem as a whole and not
try to make any "special" certificates.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

2017-12-09 Thread Hanno Böck via dev-security-policy
On Fri, 8 Dec 2017 16:43:48 -0700
Wayne Thayer via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:

> The root CA is ultimately responsible for subordinate CAs it has
> signed.  

I see a problem with that, as this is far from obvious.

If a random person discovers a problem with a certificate it seems
quite natural to go to the place that issued it. If you see a
certificate issued by Microsoft then why would you believe that anyone
other than Microsoft is responsible for that?

(Add to that that in order to find out that it's ultimately Digicert
that is responsible you'd have to first figure out that the root is
"Baltimore Cybertrust", then figure out that this is a company that no
longer exists and that the root has been bought by Digicert at some
point.)

IMHO we're seeing a very problematic practice here. On the one Hand CAs
offer that companies can get their own "branded" certificates that are
"issued" by them, on the other hand that's not really the case and all
the responsibility is still with the CA. For the user - and also for
potential reporters of security problems - this is obfuscating things.

I'm mostly not concerned about the people following these things
closely and are members of this list, but about random other people who
happen to find problems. It surely seems beneficial for the certificate
ecosystem to make sure that they can easily find the right place to
report problems.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

2017-12-08 Thread Hanno Böck via dev-security-policy
Hi,

I guess this is of interest to the members of this list:
https://www.golem.de/news/microsoft-dynamics-365-wildcard-certificate-with-a-private-key-for-everyone-1712-131544.html
https://medium.com/matthias-gliwka/microsoft-leaks-tls-private-key-for-cloud-erp-product-10b56f7d648

tl;dr Microsoft used a shared wildcard certificate in a cloud ERP
product (Dynamics 365 for Operations). In the "sandbox" version
customers were allowed to log in via RDP and thus it was possible to
extract the private key.

The finder of this bug tried several months unsuccessfully to inform
Microsoft about this issue. Eventually he got in contact with me, I
reported it to Mozilla's bugzilla and it was sorted out.
https://bugzilla.mozilla.org/show_bug.cgi?id=1421820

The certificate was issued indirectly by DigiCert. This raises imho
again an interesting issue about Sub-CAs. The BRs say that after a
private key compromise a cert shall be revoked within 24 hours. This
clearly didn't happen. While it is probably no big deal if it takes
sometimes a bit longer, in this case it was several months.

So I wonder: If a CA signs an intermediate - are they responsible
making sure that reports brought to the subca are properly handled?

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Fw: StartCom temination announcement

2017-12-02 Thread Hanno Böck via dev-security-policy
I guess it's interesting for the community, this is the message I
just got as a former StartCom customer.

Begin forwarded message:

Date: Sat, 2 Dec 2017 06:24:44 +
From: StartCom CertMaster <cmsmas...@startcomca.com>
Subject: StartCom temination announcement


StartCom temination announcement

This is an automatically generated email, please do not reply.

Dear customer,

As you are surely aware, the browser makers distrusted StartCom around
a year ago and therefore all the end entity certificates newly issued
by StartCom are not trusted by default in browsers.

The browsers imposed some conditions in order for the certificates to
be re-accepted. While StartCom believes that these conditions have been
met, it appears there are still certain difficulties forthcoming.
Considering this situation, the owners of StartCom have decided to
terminate the company as a Certification Authority as mentioned in
Startcom´s website.

StartCom will stop issuing new certificates starting from January 1st,
2018 and will provide only CRL and OCSP services for two more years.

StartCom would like to thank you for your support during this difficult
time.

StartCom is contacting some other CAs to provide you with the
certificates needed. In case you don´t want us to provide you an
alternative, please, contact us at certmas...@startcomca.com

Please let us know if you need any further assistance with the
transition process. We deeply apologize for any inconveniences that
this may cause.

Best regards,

StartCom Certification Authority


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Possible future re-application from WoSign (now WoTrus)

2017-11-22 Thread Hanno Böck via dev-security-policy
FWIW my opinion:
I don't think there should be a lifetime or long term ban for people or
companies that have operated a bad CA in the past.

However I do believe that the way Wosign representatives on this list
acted in the past was often dishonest and highly problematic.
If Wosign continues to appear that way I don't see how they can
successfully be trusted again. Not because they are Wosign, but because
I wouldn't trust any other CA behaving that way.

If Wosign wants to be trusted they need to show a behavior where the
community feels questions are answered honestly and technical problems
are taken seriously.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Certificate with duplicate commonname

2017-10-29 Thread Hanno Böck via dev-security-policy
Hi,

This certificate has a duplicate commonname:
https://crt.sh/?id=242683153=problemreporting

This was pointed out by Mattias Geniar:
https://twitter.com/mattiasgeniar/status/924705516974112768

I'm not entirely sure if the wording of the BRs forbid this (they say
the CN field must contain a single IP or fqdn, but don't really
consider the case that 2 CNs can be present), though this is
clearly malformed.

I have informed telesec / Deutsche Telekom about this (this is
indirectly signed by them) via their contact form.

I haven't checked if other such certificates exist.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


CAA reporting support and tests?

2017-09-25 Thread Hanno Böck via dev-security-policy
Hi,

I was wondering how a CAA reporting endpoint should react and wanted to
test it. However none of the CAs I tested seems to support reporting
yet.

Is anyone aware of a CA that does CAA reporting? (either via mail or
https or both.)
If no reporting on a live CA is in place is at least anyone aware of
any kind of available test that is able to generate CAA reports?

Also I'm wondering if there are any plans to have a requirement for CAA
reporting support in the future. The cabforum ballot [1] says that
reporting "SHOULD" be done.



[1]
https://cabforum.org/2017/03/08/ballot-187-make-caa-checking-mandatory/

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Lack of CAA checking at Comodo

2017-09-11 Thread Hanno Böck via dev-security-policy
Hi,

On saturday I was able to receive a certificate from comodo depsite the
subdomain having a CAA record only allowing Let's Encrypt as the CA.
Here's the cert:
https://crt.sh/?id=207082245

I have by now heard from multiple other people that confirmed the same.
Seems right now Comodo isn't checking CAA at all. There's also a bug in
the Mozilla bug tracker:
https://bugzilla.mozilla.org/show_bug.cgi?id=1398545

I was originally informed about the lack of CAA checking at Comodo by
Michael Kliewe from the mail provider mail.de. However that was before
CAA became mandatory. But even back then the Comodo webpage claimed that
Comodo would check CAA since at least 12 months:
https://support.comodo.com/index.php?/Knowledgebase/Article/View/1204/1/caa-record---certification-authority-authorization

I have covered this also today in a news article for Golem.de [1]


[1]
https://www.golem.de/news/tls-zertifikate-zertifizierungsstellen-muessen-caa-records-pruefen-1709-129981.html
google translate:
https://translate.google.de/translate?sl=de=en=y=_t=de=UTF-8==url=https%3A%2F%2Fwww.golem.de%2Fnews%2Ftls-zertifikate-zertifizierungsstellen-muessen-caa-records-pruefen-1709-129981.html

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Certificate with Debian weak key issued by Let's Encrypt

2017-09-09 Thread Hanno Böck via dev-security-policy
Hi,

A while ago I tested how some CAs would react to certificate requests
with debian weak keys.

I was able to get a certificate from Let's Encrypt with a debian weak
key. Here is it:
https://crt.sh/?id=173588030

I reported this to Let's Encrypt. They told me that they are aware they
weren't checking debian weak keys, but they were in the process of
deploying a check:
https://github.com/letsencrypt/boulder/pull/2765

I don't know if this is active by now, but I assume so.

Maybe notable: The certificate hasn't been revoked, despite me
reporting it. However I haven't explicitely asked for revocation (and I
could revoke it myself, given that I have the private key).


I have also tried to get a cert with a debian weak key from the
free trial offerings from Comodo and Symantec. Both rejected the
request.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Certificates with invalidly long serial numbers

2017-08-07 Thread Hanno Böck via dev-security-policy
On Mon, 7 Aug 2017 15:59:07 +
Ben Wilson via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:

> FWIW - In the case of Telecom Italia, they have a commercial CA
> product has a bug in it that occasionally causes this issue.  They
> may need some time for the software to be fixed/replaced. 

I'm more worried by this statement than by the actual bug.

If you're a CA and are not able to fix a bug in your product in a timely
manner then you probably shouldn't be a CA.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Certificate with invalid dnsName issued from Baltimore intermediate

2017-07-18 Thread Hanno Böck via dev-security-policy
On Tue, 18 Jul 2017 21:43:28 +0200
Hanno Böck via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:

> It has this commonname:
> commonName= .guidedstudies.com
> 
> Well... that's also not a valid hostname...

And of course it's not the only one:
https://crt.sh/?CN=.%25

(the first three seem to root to code signing certificates and probably
don't fall under BRs, but there are others)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Certificate with invalid dnsName issued from Baltimore intermediate

2017-07-18 Thread Hanno Böck via dev-security-policy
On Tue, 18 Jul 2017 19:29:10 +
Jeremy Rowley via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:

> Some of these certs are really old.

Some of them are also not so old and still valid.
All from GoDaddy:

https://crt.sh/?id=22835635
https://crt.sh/?id=8216255

This one
https://crt.sh/?id=637932
is also interesting.
It is not expired, but revoked.
It has this commonname:
commonName= .guidedstudies.com

Well... that's also not a valid hostname...


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Certificate with invalid dnsName issued from Baltimore intermediate

2017-07-18 Thread Hanno Böck via dev-security-policy
More dotdot-certificates:

https://crt.sh/?id=34528113
for autodiscover.amphenolcanada..com
Expired 2012
issued by Geotrust (aka symantec)

https://crt.sh/?id=3478078
for PDC-LIB-WEB1.RBI1.rbi..in
Expired 2016
issued by Institute for Development and Research in Banking Technology

https://crt.sh/?id=4112846
pkictslvws.dmdc.osd..mil
expired 2016
issued by U.S. Government

So all expired, but certainly at least the ones from 2016 are worrying,
indicating that the issuing CAs are failing at domain validation.

(Due to limitations in the search methodology - scraping crt.sh
search results and looping through tlds - I only searched for ..tld. It
would certainly be valuable to search further.)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Leaking private keys through web servers

2017-07-14 Thread Hanno Böck via dev-security-policy
On Wed, 12 Jul 2017 10:47:51 -0400
Ryan Sleevi <r...@sleevi.com> wrote:

> One challenge to consider is how this is quantified. Obviously, if you
> reported to Comodo the issue with the key, and then they issued
> another certificate with that key, arguably that's something Comodo
> should have caught. However, if you reported the compromise to, say,
> ACME CA, and then Comodo issued an equivalent cert, that's
> questionable. I'm loathe to make CAs rely on eachothers'
> keyCompromise revocation reasons, simply because we have no normative
> guidance in the BRs (yet) that require CAs be honest or competent
> with their revocation reasons (... yet). Further, we explicitly don't
> want to have a registry (of compromised keys, untrustworthy orgs,
> etc), for various non-technical reasons.
> 
> I'm curious if you have thoughts there - particularly, how you
> reported the private key was compromised (did you provide evidence -
> for example, a signed message, or simply a link to "Here's the URL,
> go see for yourself"?)
> - and how you see it working cross-CA boundaries.

To answer this question: As the private keys were available on webpages
I simply reported the URLs and corresponding certs to the CAs.
(This was also with the intention that in case the CA has a contact to
their customer they could inform them about the key on their server,
though I'm not sure if any CA informed them.)

So there are several questions and possible situations here.

I think it's relatively clear that a CA could prevent reissuance of
certs if they know about a key compromise.

Another question is if there has been a revocation that wasn't clearly
tied to a key compromise. On the other hand I hardly see any reason why
anyone would revoke a cert if there isn't any indication of a
compromise.

The next question would be if there should be a cross-CA blacklisting
of compromised keys. I think that would be valuable, but of course it
raises a lot of questions on how this information should be shared
(share the private keys? public keys? spki hashes? share it in public
or only between CAs?).

Ultimately I'm inclined to say that there really shouldn't be any good
reason at all to ever reuse a key. (Except... HPKP)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Leaking private keys through web servers

2017-07-12 Thread Hanno Böck via dev-security-policy
Hello,

I recently did an investigation where I tried to simply download private
keys from web servers with common filenames. I collected these
filenames simply from common tutorials on the web (server.key,
privatekey.key, myserver.key, key.pem and [hostname].key with and
without www).
In several cases I was able to download private keys belonging to
currently valid certificates.

I wrote about this today for the German news site Golem.de (with an
english translation available):
https://www.golem.de/news/https-private-keys-on-web-servers-1707-128862.html


In the course of this I also learned quite a bit about the revocation
process. According to the baseline requirements a CA shall revoke keys
within 24 hours in case of a key compromise.

Some notes about my experiences:
* All certificates I reported are revoked now.
* In several cases the deadline wasn't hit and CAs took longer. Some
  took over 4 days. In one case (Gandi) I learned that it's a branded
  CA from Comodo. Comodo immediately revoked the cert after they
  learned about it, but this raises interesting questions about the
  responsibilities of branded CAs.
* The reporting process is wildly different. Some CAs provide email
  addresses, others online forms, Symantec has forms with captchas. In
  the April CA communications [1] mozilla announced that it wants to
  compile a list of contact methods and has asked CAs for them. I would
  encourage streamlining that process. I also think revocation should
  be automatable (at least on the side of the reporter) and wonder
  whether things like forms with captchas should be outruled.
  Particularly interesting is Let's Encrypt that provides an API via
  ACME to revoke if you posess the private key. IMHO that's ideal.
* Comodo re-issued certs with the same key. I wonder if there should be
  a rule that once a key compromise event is known to the CA it must
  make sure this key is blacklisted. (Or maybe one of the existing
  rules already apply, I don't know.)

I had opened a private bug in mozillas bugtracker which contains some
more info and lists of the specific certificates. It's up to mozilla
when they'll open it, but from my side I think this can go public.


[1] https://wiki.mozilla.org/CA/Communications#April_2017_Responses
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1378074
-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: On GitHub, Leaked Keys, and getting practical about revocation

2017-06-21 Thread Hanno Böck via dev-security-policy
On Wed, 21 Jun 2017 10:40:01 -0700 (PDT)
Matthew Hardeman via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:

> Through a little Google digging, I find numerous comments and
> references from well informed parties going back quite several years
> lamenting the poor state of support of OCSP stapling in both Apache
> HTTPD and NGINX.  I'm well aware of the rising power that is Caddy,
> but it's not there yet.  The whole ecosystem could be greatly helped
> by making the default shipping versions of those two daemons in the
> major distros be ideal OCSP-stapling ready.

There is some movement here for apache, see discussion over at the
apache dev list:
https://lists.apache.org/thread.html/1a61e9dfbd685c4102b097e8189bccb7d5da39bf9f32fcbe7407a760@%3Cdev.httpd.apache.org%3E

I'm slightly optimistic that we'll have a better stapling
implementation in apache soon.
Also CII is interested in funding efforts that improve the state of ocsp
stapling.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: SHA1 root CA

2017-03-01 Thread Hanno Böck via dev-security-policy
On Wed, 1 Mar 2017 02:36:22 -0800 (PST)
benjaminpill--- via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:

> when connecting to a webserver
> 
> screenshot of the error message: http://imgur.com/a/BIQUm

It would be helpful if you told us which webserver. The error message
looks to me that it's web webpages certificate, not the root, that's
signed with sha1. But I may be wrong, would have to check.
Sometimes error messages are misleading and sometimes strange things
happen when websites send all kinds of wrong certs within a chain.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: SHA1 root CA

2017-03-01 Thread Hanno Böck via dev-security-policy
On Wed, 1 Mar 2017 02:21:21 -0800 (PST)
benjaminpill--- via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:

> so why is Firefox complaining with this error message:
> 
> SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED

Can you be more specific? Where are you seeing that error message?

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: SHA1 root CA

2017-03-01 Thread Hanno Böck via dev-security-policy
On Wed, 1 Mar 2017 00:44:54 -0800 (PST)
benjaminpill--- via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:

> are root (Enterprise) CA certificates wich are based on SHA1 handled
> as untrusted by Firefox 51? The  end certificate is sign using sha256
> and trusted by a intermidiate ca wich uses also sha256. Only the root
> ca is based on sha1. Chrome and IE are not complaining about the root
> cert.

The signatures on root certificates are mostly irrelevant, as they're
pure self-signatures that have no real meaning. I think they're
only there because the certificate format X.509 requires certificates to
have a signature on themselve.

Therefore afaik it's generally considered okay if root certificates have
SHA1 signatures. You probably wouldn't create new ones with such
signatures, but there is no risk for the ecosystem in keeping existing
ones.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Other Curves

2017-02-01 Thread Hanno Böck
On Wed, 1 Feb 2017 22:38:54 +
Jeremy Rowley <jeremy.row...@digicert.com> wrote:

> Some of these curves are considered much better than the NIST curves
> (well, that’s what I’ve read anyway).

Overall they have mostly the same weaknesses than the NIST curves.
There are differences in detail, but it really doesn't justify
introducing a lot of variety in the ecosystem. But I have a pretty good
idea where that hearsay comes from, and I'm pretty sure it has little
to do with security.

The modern curves like Curve25519 and Curve448 avoid many of the
security pitfalls of older curves. If you want more secure curves look
at them and push standards forward so they can be used within X.509.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Misissued/Suspicious Symantec Certificates

2017-01-24 Thread Hanno Böck
Hello,

I have a few observations to share about this incident, not sure how
relevant they are.

There are 4 "example.com" certificates related to this incident.

There are 114 "O=test" certificates that I assume are related to this
incident. This includes all certificates with a "Not Before" date of
2016-10 and later. crt.sh finds various older certificates with O=test
from various CAs, but I guess they are unrelated.

Issuers
===

The affected certificates were issued by three different intermediates
owned by Symantec:
Symantec Class 3 Secure Server CA - G4
thawte SSL CA - 
GeoTrust SSL CA - G3

Now Symantec told us these certificates were issued by one of their
WebTrust partners. This got me curious if it's usual that Symantec
gives their partners access to their systems in a way that they can use
various different intermediates related to different brand names.

This document here
https://cert.webtrust.org/SealFile?seal=2168=pdf
indicates that Korea Electronic Certification Authority Inc.
("CrossCert"), which is probably the partner Symantec is talking about,
is allowed to issue certificates with these intermediates
VeriSign Class 3 Secure Server CA - G3
VeriSign Class 3 International Server CA - G3
Symantec Class 3 Secure Server CA - G4
Which - as can be obviously seen - don't match.

(nitpick: It seems the PDF doc has a bogus document title which looks
like some changelog entry)


Revocations
===

The 4 example certs were already revoked when Andrew Ayer made this
incident public.
From the 114 "O=test" certificates 62 were revoked at some point in
2016, so before the incident became public. 52 were revoked at some
point in 2017. 37 of those were revoked on 2017-01-20, so directly
afterthe incident got public.
(I've counted this because in a statement sent to the media Symantec
said that when they learned about this incident "most" certificates
were already revoked. I feel I have a different definition of the word
"most".)


Other O=test certificates
=

A quick run through other "O=test" certs:
* "Cybertrust Japan Co.. Ltd." seems to have issued a large number of
  them, but a few checks indicate they are issued to domains they own.
  Not sure if that's still considered a problem, as "O=test" is
  obviously a bogus org, but at least they seem to not issue certs for
  other people's domains.
* There's one cert issued by "SHECA" which is itself an intermediate
  signed by "UniTrust". It's issued for a public IP. UniTrust seems to
  be accepted by Apple+Microsoft, but not by Mozilla+Chrome.
  https://crt.sh/?id=32335050




-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: SHA256 for OCSP response issuer hashing

2016-12-16 Thread Hanno Böck
On Fri, 16 Dec 2016 02:51:47 +0100
Jakob Bohm <jb-mozi...@wisemo.com> wrote:

> I believe it would cause a problem with legacy systems that don't
> understand SHA-256 signatures at all, noting that such systems will
> only ever trust SHA-1 (and older) certificates, thus SHA-1 signing can
> be limited to cases where the CA chain leading to the certificate
> issuer has no SHA-256 signatures and the certificate being checked is
> not a known SHA-256 certificate (generating the dynamic rejection
> response for a never issued certificate would choose the hash based on
> the hash algorithm in the involved intermediary CA certs).

I believe the potential problem is a different one: Systems that accept
SHA256 on certificate signatures, but not on OCSP responses. I don't
know if such systems exist, but if I had to make a bet I'd say they do.

I stated on multiple occasions that almost every imaginable TLS
implementation flaw can be found in the wild. I was never disappointed
with this prediction.

That said: I'd recommend just do it. We'll see what happens and if we
learn something about broken systems that's a good thing.

> I wonder if Let's Encrypt ever issued SHA-1 certificates, and if any
> of those are non-expired.

Almost certainly not. Given 3 month lifetime of certs this would have
been either a violation of the baseline requirements or an agreed upon
exception. Neither of which I'm aware of, and I'm pretty sure if one of
that happened it would've made some noise.


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Mozilla CT Policy

2016-11-04 Thread Hanno Böck
On Fri, 4 Nov 2016 14:09:55 +0100
Jakob Bohm <jb-mozi...@wisemo.com> wrote:

> * How do we allow organization internal non-public CAs to not reveal
>   their secret membership/server lists to public CT systems or
> otherwise run the (administratively and technically) expensive
> processes required of public CAs.  For example many medium or large
> companies have in-house CAs issuing certificates for communicating
> with their internal servers, VPNs, extranets etc.  Such internal CAs
> may very from primitive off-line CAs (no online active components
> such as OCSP responders or CT loggers) to off-the-shelf enterprise CA
> packages such as Microsoft Windows Server Certificate Services, xca
> or EJBCA.
> 
> * How do we prevent public CAs from misusing the exceptions for
> private CAs?

Isn't that already solved?

Browsers already treat manually installed roots differently, e.g.
bypassing key pinning. Chrome's CT requirements don't apply to locally
installed roots.

This seems to be the obvious solution. CT is there to have transparency
of certificates by the browser-accepted CAs. If you have your own CA
that souldn't be touched by that at all.

(By the way I always found the "secret server name" idea wrong and I
would generally recommend against local CAs in almost all cases. It
adds a lot of complexity and I assume it often creates more problems
than it solves.)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Mozilla CT Policy

2016-11-04 Thread Hanno Böck
Hi,

Great to see Mozilla committing to CT.

On Fri, 4 Nov 2016 12:19:32 +
Gervase Markham <g...@mozilla.org> wrote:

> So, please add comments with additional _questions_ you think the
> policy will need to address. What the answers should be is (for now)
> off-topic.

Some meta-thought:
In practice pretty much every webpage wants to be compliant with all
major browsers. It's hard to imagine anyone saying "I'll comply with
Chrome's CT requirements, but not with Mozilla's" (or vice versa).

Therefore practically the "real" CT requirements will be all
requirements combined. It also probably means that diverity in CT
requirements between different browsers doesn't make a whole lot of
sense.

So one could ask: Should mozilla just say "we agree with everything
Chrome does" ?

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Incident Report - certificate with 'sb' as a SAN:dnsName

2016-10-15 Thread Hanno Böck
Hello,

I think I have asked two reasonable questions here.
Can we get an answer?

On Tue, 4 Oct 2016 14:33:38 +0200
Hanno Böck <ha...@hboeck.de> wrote:

> There seem to be more certificates of that kind that weren't mentioned
> in the incident report. Here's a .re / www.re certificate (expired
> 2015):
> https://crt.sh/?id=4467456
> 
> Has comodo checked its systems for other certificates of that kind?
> Can you provide a full list of all such certificates?
> 
> 
> Also my understanding is that the error here was that control over the
> www.[domain] subdomain would indicate control over [domain]. Does that
> mean that this bug could've been used to also get wildcard
> certificates in the form of *.[tld]?

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


pgpEhCBg0LpHm.pgp
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Remediation Plan for WoSign and StartCom

2016-10-14 Thread Hanno Böck
On Fri, 14 Oct 2016 13:21:32 -0700 (PDT)
Ryan Sleevi <r...@sleevi.com> wrote:

> In particular, I'm hoping to expand upon the choice to allow existing
> certs to continue to be accepted and to not remove the affected roots
> until 2019.

Hi,

From my understanding the problem here is that the alternative of simply
whitelisting the existing certificates isn't feasible, because there
are too many of them.

*however* from what I remember almost all the time the free options of
startcom/wosign were limited to one year. (I think there was a short
period of time when it was possible to get 3-year-certs from wosign for
free, but they removed that shortly afterwards.)

Therefore there should be some middlegroupd option:
a) Keep the existing root for 1 year and trust that wosign won't
backdate certificates
b) After that the vast majority of wosign/startcom certificates will be
expired. The number of the remaining ones is probably low enough to
make whitelisting feasible.

I haven't checked CT logs for expiration dates, so this is more a
guess, but given the history of cert issuance and the reasonable
assumption most certs used the free option this seems plausible.


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


pgp3HxEEpd6Tt.pgp
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: SHA-1 exception First Data

2016-10-06 Thread Hanno Böck
On Wed, 5 Oct 2016 22:46:24 -0700
Peter Bowen <pzbo...@gmail.com> wrote:

> I think we can all look back with 20/20 hindsight and say that device
> vendors should not use the same roots as browsers and that maybe CAs
> should have created "SHA-1 forever" roots for devices that never plan
> to update, but that is great hindsight. We have the problem now, so we
> need an answer.

I find that a rather strange conclusion.
Device vendors shouldn't ship devices they never plan to update. If we
can't even agree on that... (after the Brian Krebs incident even more
so)

Also one thing I'd like to point out that I find very strange in this
discussion: The demise of SHA-1 was known since 2004.

Do these financial vendors use products that are older than 2004? Or
have they ignored the issue until 2014 when browser vendors finally
started to indicate some action on the issue?
The First Data request sent to the cabf list indicates that they
started the transition in 2014.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


pgp1EidDY0jk3.pgp
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Incident Report - certificate with 'sb' as a SAN:dnsName

2016-10-04 Thread Hanno Böck
Hi,

There seem to be more certificates of that kind that weren't mentioned
in the incident report. Here's a .re / www.re certificate (expired
2015):
https://crt.sh/?id=4467456

Has comodo checked its systems for other certificates of that kind? Can
you provide a full list of all such certificates?


Also my understanding is that the error here was that control over the
www.[domain] subdomain would indicate control over [domain]. Does that
mean that this bug could've been used to also get wildcard certificates
in the form of *.[tld]?

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


pgpq26I03NxxI.pgp
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: WoSign and StartCom: next steps

2016-09-30 Thread Hanno Böck
Hi,

I just want to throw out some thoughts and I hope the people involved
find it noteworthy. Please note that I am in no way in a position to
decide anything here, I'm just someone who happens to have an opinion
on the stuff going on.

This seems to be some last minute attempt to rescue wosign/startcom as
a CA. Despite all the stuff that happend I kinda sympathize with it,
for two reasons:
* I think wosign and startcom did a lot of good for the web by providing
  free certificate options and I think it'd be problematic to have a
  Let's Encrypt monopoly for free certificates.
* I fear that if wosign gets removed that this might lead to a further
  separation of the chinese web. I don't want to see a situation where
  chinese webpages use a chinese certificate that the browsers from the
  rest of the world don't accept. I don't think this is in anyone's
  interest, as it would harm the Internet as a whole.

I guess the community could agree to let wosign stay in the browsers,
but it must be clear that there is a sincere will to handle things
differently in the future. My advice to the representatives of
wosign/startcom/quihoo would be to be as transparent as possible.
I think the major reason people find this mozilla research so damning
is because it looks a lot like you were trying to hide things. This was
further fuelled by multiple statements in the form "we don't have to
talk about this".
If you want to regain trust from the community you'll have to talk
about it. This isn't about any legal requirements, it's about trust
from the community. Be open about who owns which company, who's in
charge and also tell us exactly why these things happened in the past
and how you want to prevent them from happening again.


Minor sidenote: there have been some concerns about TLS security
vulnerabilities of the qihoo 360 browser [1] [2]. While this is not
directly related to the operation of a CA, it surely would increase the
community's trust of qihoo 360 if these issues get resolved quickly.


[1] https://cabforum.org/pipermail/public/2015-April/005441.html
[2] https://twitter.com/ryancdotorg/status/780470538686697472

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


pgppRcHcrXVwf.pgp
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Maybe Mozilla can work with Chinese CAs to urge Chinese government to open up its internet a bit more?

2016-09-19 Thread Hanno Böck
On Mon, 19 Sep 2016 13:11:17 -0400
Richard Barnes <rbar...@mozilla.com> wrote:

> I believe this group is also accessible as a mailing list, with no
> connection to Google at all.
> 
> https://lists.mozilla.org/listinfo/dev-security-policy

The archive link there goes to the google page.

Maybe it'd be a good idea to provide a link to an alternative archive
option? The list is archived mail-archive.com:
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


pgpPuY4DyNpTJ.pgp
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Sanctions short of distrust

2016-09-01 Thread Hanno Böck
On Wed, 31 Aug 2016 12:43:38 -0700 (PDT)
Nick Lamb <tialara...@gmail.com> wrote:

> 1. Implement "Require SCTs" for problematic CAs. Notify the CA they
> are obliged to CT log all certificates, inform subscribers etc. or
> their subscriber's certificates will suddenly be invalid in Firefox
> from some future date.

I think this is generally a very good thing, because CT has uncovered a
lot of CA-badness in the past.
I'm happy to see that Wosign is going down that route (not sure if
someone forced them to do or if they did this voluntarily, but it seems
like the right step).

I'd like to propose another feature that one could ask "problematic"
CAs to implement: CAA.
It's a relatively simple thing: A domain owner has a DNS record that
says which CAs he wants to be allowed to issue certs.

Good thing: Can be easily tested by others whether a CA implements it
and it may reduce misissuances.

I'm inclined to say every CA should implement CAA, but it seems last
time this was discussed in the CA/Browser-Forum they agreed to make
this a SHOULD, not a MUST.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


pgpRMQhIqeyQ1.pgp
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Server certificate domain validation bug

2016-08-15 Thread Hanno Böck
On Thu, 11 Aug 2016 19:08:25 +0100
"Robin Alden" <ro...@comodo.com> wrote:

>   Simplicity is certainly a powerful aid to security.
> I like the text-only idea for the DCV emails.

Would you be interested in working on a proposal on that for the
CA/B-Forum? (I'm not allowed to post there, so I can't directly
have that disucssion.)
I'm a bit disappointed that this incident hasn't caused more
discussion. I think the domain validation process is one of the most
sensitive pieces of the CA ecosystem and should receive extra security
care. And the verification emails are an extremely common way of doing
domain validation.

> Not containing any user controlled content is a harder sell, I think,
> because we really want to give the domain owner all the information
> we can about the certificate request that has been submitted.

I understand that use-case, yet I still see a significant risk in any
user-controlled content even in text-only mails (there are most likely
mail implementations out there that can be tricked into rendering html
inside a text-only mail).

I wonder if user-controlled content could at least be restricted to
customers that have some kind of long-term relationship with a CA, e.g.
through payment, contracts etc. Because that business case doesn't seem
to be like something that the average "I want to get a cert quick,
cheap (free) and easy" use case.

If forbidding user-controlled content is a no-go for some I'd like to
see at the very least some very clear and specific guidelines on how to
filter or escape them. What I'd like to have is something that can be
checked and pointed out by security researchers if it isn't done.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgpzFGffHEink.pgp
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Server certificate domain validation bug

2016-07-29 Thread Hanno Böck
Hi,

I just saw this report and my initial reaction was that it seems to be
a grave security risk to use HTML emails with user controlled content
for email domain validation.

I don't see any need for this and would strongly recommend that a
policy forbidding that practice gets implemented. The alternative would
be carefully preventing XSS issues, but honestly, XSS is complicated
and subtle, I don't see it as realistic to prevent all XSS issues.

The domain validation process is one of the most security sensitive
pieces of the CA ecosystem, therefore I recommend that:
* Domain validation mails must not use HTML and must not contain any
  user-controlled content.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgpSoV7OKCqEc.pgp
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Private PKIs, Re: Proposed limited exception to SHA-1 issuance

2016-02-29 Thread Hanno Böck
On Mon, 29 Feb 2016 10:18:01 +0100
Jürgen Brauckmann <brauckm...@dfn-cert.de> wrote:

> Using private PKIs for such stuff isn't risk-free, as software
> vendors are confused about the security properties of their root
> store.

Actually I also thought while reading this thread that I disagree that
a private PKI is always a good idea.
I generally recommend the opposite. Running a private PKI requires
quite a bit of knowledge about certificates and the deployment of roots
and can introduce severe risks if you don't take care of your private
keys.

You avoid all questions about how to deploy it to a diverse device base
if you use publicly trusted roots.

The problem here imho was a different one: If you deploy devices that
you expect to stay around for a longer timeframe always make sure they
implement the most modern protocols available.
Pretty much *all* SHA1-hassle could've been avoided if people hadn't
deployed sub-standard crypto implementations. SHA2-based certificates
were available since the 90s.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgpXmlpWewtfi.pgp
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Certificate with space in CommonName found on deutschepost.de

2015-04-11 Thread Hanno Böck
On Sat, 11 Apr 2015 10:44:38 +
Peter Gutmann pgut...@cs.auckland.ac.nz wrote:

 Did anyone save a copy of the cert chain?  I'd like to add it to my
 collection of broken cer^H^H^H^H^Hcert parser test vectors, but the
 site has been fixed and the Bugzilla entry doesn't contain it.

Here you go.

Is your collection public?

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgpDmYuGYC_SO.pgp
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy