Re: Intermediate common name ambiguous naming

[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

[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

[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

[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

[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

[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

[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)

[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

[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

[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)

[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)

[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

[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

[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

[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

[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

[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?

[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

[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

[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

[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

[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)

[Hanno Böck via dev-security-policy]

On Fri, 2 Mar 2018 16:10:52 +0900
Hector Martin 'marcan' via dev-security-policy
 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

[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

[Hanno Böck via dev-security-policy]

Hi,

On Tue, 27 Feb 2018 09:20:33 -0700
Wayne Thayer via dev-security-policy
 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

[Hanno Böck via dev-security-policy]

On Thu, 8 Feb 2018 15:50:08 +
Gervase Markham via dev-security-policy
 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

[Hanno Böck via dev-security-policy]

Hi,

On Tue, 6 Feb 2018 16:56:48 +0100
Kurt Roeckx via dev-security-policy
 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

[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

[Hanno Böck via dev-security-policy]

On Mon, 5 Feb 2018 12:07:06 -0500
Eric Mill via dev-security-policy
 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

[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

[Hanno Böck via dev-security-policy]

Hi,

On Sun, 21 Jan 2018 12:09:23 -0800 (PST)
Ryan Hurst via dev-security-policy
 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

[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

[Hanno Böck via dev-security-policy]

Hi,

On Tue, 09 Jan 2018 21:04:34 +
Nicholas Humfrey via dev-security-policy
 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)

[Hanno Böck via dev-security-policy]

On Mon, 25 Dec 2017 14:43:21 +
Jeremy Rowley via dev-security-policy
 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)

[Hanno Böck via dev-security-policy]

On Mon, 25 Dec 2017 04:19:58 -0800 (PST)
"Adrian R. via dev-security-policy"
 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)

[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)

[Hanno Böck via dev-security-policy]

On Sun, 24 Dec 2017 23:07:56 -0800 (PST)
"Adrian R. via dev-security-policy"
 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)

[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)

[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

[Hanno Böck via dev-security-policy]

Hi,

On Mon, 11 Dec 2017 11:01:10 -0800 (PST)
Ryan Sleevi via dev-security-policy
 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

[Hanno Böck via dev-security-policy]

On Fri, 8 Dec 2017 16:43:48 -0700
Wayne Thayer via dev-security-policy
 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

[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

[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 
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)

[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

[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?

[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

[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

[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

[Hanno Böck via dev-security-policy]

On Mon, 7 Aug 2017 15:59:07 +
Ben Wilson via dev-security-policy
 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

[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

[Hanno Böck via dev-security-policy]

On Tue, 18 Jul 2017 19:29:10 +
Jeremy Rowley via dev-security-policy
 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

[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

[Hanno Böck via dev-security-policy]

On Wed, 12 Jul 2017 10:47:51 -0400
Ryan Sleevi  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

[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

[Hanno Böck via dev-security-policy]

On Wed, 21 Jun 2017 10:40:01 -0700 (PDT)
Matthew Hardeman via dev-security-policy
 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

[Hanno Böck via dev-security-policy]

On Wed, 1 Mar 2017 02:36:22 -0800 (PST)
benjaminpill--- via dev-security-policy
 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

[Hanno Böck via dev-security-policy]

On Wed, 1 Mar 2017 02:21:21 -0800 (PST)
benjaminpill--- via dev-security-policy
 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

[Hanno Böck via dev-security-policy]

On Wed, 1 Mar 2017 00:44:54 -0800 (PST)
benjaminpill--- via dev-security-policy
 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