Re: Intermediate common name ambiguous naming
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
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
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
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
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
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
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)
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
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
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)
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)
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
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
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
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
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
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?
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
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
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&opt=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
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&opt=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
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)
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
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
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
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
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
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
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
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&opt=ocsp https://crt.sh/?id=663&opt=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
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
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
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)
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)
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)
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)
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)
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)
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
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
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
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
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)
On Wed, 22 Nov 2017 12:26:15 +0100 Tom via dev-security-policy wrote: > About the past behavior of WoSign, the incident report > https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf > from https://wiki.mozilla.org/CA:WoSign_Issues seems missing. It can be read through wayback machine: https://web.archive.org/web/20170203172437/https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf I was wondering if I should edit the wiki, but it's linked at multiple places and other PDFs as well that may have disappeared. In any case: I agree these are legitimate questions, if past CA incidents happen the documents describing them shold be properly archived. I think having a rule that one copy of them has to be stored on mozilla infrastructure is wise. -- 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)
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
Hi, This certificate has a duplicate commonname: https://crt.sh/?id=242683153&opt=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
Re: ROCA fingerprints found on crt.sh (was Re: Efficient test for weak RSA keys generated in Infineon TPMs / smartcards)
Hi, For completeness: I checked some of the eIDAS providers after this and I found a couple of non-logged certificates that are also vulnerable. They don't seem to chain up to any CA that is loggable by CT logs. But for completeness I'll post them here. These are the subjects: C=DE, O=Deutscher Sparkassen Verlag GmbH, OU=ZDA mit Anbieterakkreditierung, CN=S-TRUST CA fuer qualifizierte Zertifikate 2014-01 1:PN C=DE, O=Deutscher Sparkassen Verlag GmbH, OU=ZDA mit Anbieterakkreditierung, CN=S-TRUST CA fuer qualifizierte Zertifikate 2014-02 1:PN C=DE, O=Deutscher Sparkassen Verlag GmbH, OU=ZDA mit Anbieterakkreditierung, CN=S-TRUST CA fuer qualifizierte Zertifikate 2014-03 1:PN C=DE, O=Deutscher Sparkassen Verlag GmbH, OU=ZDA mit Anbieterakkreditierung, CN=S-TRUST CA fuer qualifizierte Zertifikate 2014-04 1:PN C=DE, O=Deutsche Rentenversicherung, OU=QC Root CA, CN=DRV QC Root CA 2017a C=DE, O=D-Trust GmbH, CN=D-TRUST akkr 2014 CRL 1 1:PN C=DE, O=D-Trust GmbH, CN=D-TRUST akkr 2014 CRL 2 1:PN C=DE, O=D-Trust GmbH, CN=D-TRUST akkr 2014 CRL 3 1:PN C=DE, O=D-Trust GmbH, CN=D-TRUST akkr 2014 CRL 4 1:PN C=DE, O=D-Trust GmbH, CN=D-TRUST akkr 2014 CRL 5 1:PN C=DE, O=D-Trust GmbH, CN=D-TRUST akkr 2014 CRL 6 1:PN I have no detailed knowledge what the exact usage of these certs is, but some of it can be guessed based on the subjects. -- 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?
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
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&tl=en&js=y&prev=_t&hl=de&ie=UTF-8&edit-text=&act=url&u=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
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
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
On Tue, 18 Jul 2017 21:43:28 +0200 Hanno Böck via dev-security-policy 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
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
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
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
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
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
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
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
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