Re: CA handling of contact information when reporting problems
On Monday, 19 August 2019 17:26:06 UTC+3, Mathew Hodson wrote: [...] > If these situations were common, it could create a chilling effect on > problem reporting that would hurt the WebPKI ecosystem. Are specific > procedures and handling of contact information in these situations > covered by the BRs or Mozilla policy? >From my experience if something is already covered by legislation there >doesn't need to be a separate procedure for "complying with the law". Since that researcher is an EU citizen from Netherlands, the GDPR applies for his personal contact data and both Sectigo's and that "angry" company's actions are (possible) GDPR violations. Was there explicit consent given to Sectigo to forward his contact details to that company? Is that "angry" company even aware of the GDPR? (GDPR, article 6 and 7) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Avast Antivirus enables the entire Microsoft PKI for Firefox
Wayne Thayer wrote: > > > That is not my understanding of how this setting works: it only imports > roots that have been added to the Windows root store, e.g. by a program > such as Avast, or an administrator. It does not import roots Microsoft > ships with Windows. > The problem is that if a root certificate is revoked locally by: - exporting it from any place in the windows certificate store, - adding it to the Untrusted Certificates store - keeping it untouched in the initial store where it was exported from ... Firefox considers that certificate as valid when it should consider it as revoked. Windows considers such a certificate to be revoked. With Avast antivirus it's not possible to delete their MITM scanner certificate because they will re-create another if i delete it, but they allow it to be revoked and stay revoked. Adrian R. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Avast Antivirus enables the entire Microsoft PKI for Firefox
Hello Today, as part of an "upgrade" to version 19.5 Avast Antivirus has forcefully enabled the entire Microsoft PKI for all Firefox users that also happen to be users of Avast [Free] Antivirus. They now forcefully set this Mozilla enterprise policy for all users of Avast: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Mozilla\Firefox\Certificates "ImportEnterpriseRoots"=dword:0001 And this causes Mozilla Firefox to trust all the root certificates in the Windows store... but with a bug: Firefox ignores the local revocation info for root certificates and thus considers revoked root certificates as being valid. Related Mozilla bugzilla bug id: 1553233 *sigh* Adrian R. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: question about DNS CAA and S/MIME certificates
Pedro Fuentes wrote: > Just to say that looking at this from Europe, I don't see this feasible. > > Citizens getting their personal eIDAS-compliant certificate go through > face-to-face validation and will give virtually any valid e-mail address to > appear in their certificate. > Then that is a problem with eIDAS certificates not with CAA - eIDAS certificates identify the person, and (assuming that email validation is even performed) that they have temporary control of an email address, but if the email is on a corporate domain this does nothing to address the issuance against policies of that company. >From this point of view, an email address should not even be part of an eIDAS >certificate (and thus CAA would not apply), but an email is usually included >for convenience. (why?) This is because the eIDAS regulation 910/2014 does not contain the words "e-mail", "email" or "message" at all. (!!!) https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32014R0910 As it is now, it is even possible to use and 'verify control' of anonymous disposable email services (e.g. mailinator) for an eIDAS certificate because the CA TSP doesn't care about the email or domain policies. As is noted on the GitHub issue, many providers of free email services have been careful to avoid deploying CAA for the domain names used by their email users, but some have deployed restrictive CAA policies that might affect their users if CAA checking is done (e.g. Yahoo, Yandex). Adrian R. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
question about DNS CAA and S/MIME certificates
Hello, this question is somewhat outside the current Baseline Requirements, but... wouldn't it be normal for the same CAA rules for server certificates to also apply to client certificates when the email address is for a domain that already has a valid CAA policy published in DNS? RFC 6844 doesn't seem to make any distinction between server and S/MIME client certificates, it combines them together by referring to certificates "for that domain" as a whole. i tested this last night - i obtained an email certificate from one of the CAs participating here (not for this exact address though) and it was happily issued even if CAA records authenticated by DNSSEC do not allow their CA to issue for this domain. Now, this is technically not a mis-issuance because it was a proper email-validated address and their CPS says that CAA is only checked for server-type certificates. It doesn't say anything about CAA validation for such client certificates. I got in touch with them and they seemed equally surprised by such intended use case for CAA, so my second question is: is anyone actually checking CAA records for client certificates where an email address is included in the certificate subject info and the EKU includes Secure Email? Or is CAA usually checked only for server-type certificates, even if RFC 6844 refers to certificates "for that domain" as a whole? Thank you, Adrian R. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.6 Proposal: Require English Language Audit Reports
Then we go back to: what's the point of becoming a globally-recognized CA if you are not allowed by law to recognize as legal the English language version? Some user from the other part of the world might not know YOUR local language, but they are more likely to know English. A local country can simply issue legislation that XYZ Certification Authority with certificate public key ##[...] is mandatory to be recognized by everyone in the country and that's that. You don't really need Mozilla / Microsoft / Apple to accept you as CA to operate. You have to earn their (and their user's) trust. One critical step to earning this trust is having legally-binding, easy to understand documents. Adrian R. On Thursday, 5 April 2018 12:38:12 UTC+3, Buschart, Rufus wrote: > I would like to suggest to add the clause "if legally allowed" at the end. I > had some crazy discussions with colleagues in Russia and Québec about > documents in English. Also it should be added that the audit information must > be publicly available in the Internet. The whole sentence would be: > > "The audit information MUST be publicly available in the Internet. An English > version MUST be provided. The English version MUST be authoritative if > legally possible under the jurisdiction of the CAs home country." > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: FW: Complying with Mozilla policy on email validation
On Thursday, 5 April 2018 03:08:44 UTC+3, Wayne Thayer wrote: [...] > If a CA first confirms that it is a condition of a > particular federated authentication system that a user must have proven > control over the email account that constitutes their username to activate > their account, then requires that user to prove they can authenticate in to > the account, I think that meets the "reasonable" standard, even though a > threat analysis might determine that the method is insufficient for various > reasons. > As you said, the S/MIME Working Group would be a better venue to define these, because the email username used for email authentication is not always identical to the email address. I might send a message to bob[at]example.com but they could actually use alice[at]example.com as username for authentication when accessing their messages or sending messages from the bob@ address. The same RFC 5321 section 2.3.11 allows this. > If the problem is that the user is not the "entity submitting the request", > could that be changed? > > Alternately, maybe you can suggest a change to 2.2(2) that achieves your > goals without going so far as permitting "business controls" for validation? If the federated auth username is different, but from the same domain as the intended email address, then require mandatory DNSSEC and CAA for the domain and also require email validation? This might actually be easier to deploy than "business controls" when provisioning multiple S/MIME certificates for users, because DNSSEC and CAA need to be configured only once (in DNS) and then each user only has to do the email address validation part. Adrian R. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: FW: Complying with Mozilla policy on email validation
On Tuesday, 3 April 2018 20:19:40 UTC+3, Ryan Hurst wrote: > > Reading this thread and thinking the current text, based on the > interpretation discussed, does not accommodate a few cases that I think are > useful. > > For example, if we consider a CA supporting a large mail provider in > providing S/MIME certificates to all of its customers. In this model, the > mail provider is the authoritative namespace owner. > > In the context of mail, you can imagine gmail.com or peculiarventures.com as > examples, both are gmail (as determined by MX records). It seems reasonable > to me (Speaking as Ryan and not Google here) to allow a CA to leverage this > internet reality (expressed via MX records) to work with a CA to get S/MIME > certificates for all of its customers without forcing them through an email > challenge. > > In this scenario, you could not rely on name constraints because the > onboarding of custom domains (like peculiarventures.com) happens real time as > part of account creation. The prior business controls text seemed to allow > this case but it seems the interpretation discussed here would prohibit it. > > > Another case I think is interesting is that of a delegation of email > verification to a third-party. For example, when you do a OAUTH > authentication to Facebook it will return the user’s email address if it has > been verified. The same is true for a number of related scenarios, for > example, you can tell via Live Authentication and Google Authentication if > the user's email was verified. > > The business controls text plausibly would have allowed this use case also. > > I think a policy that does not allow a CA to support these use cases would > severly limit the use cases in which S/MIME could be used and I would like to > see them considered. > > Ryan Hurst There's also (1) the case of wildcard/catch-all email addresses and (2) that of the email provider for hosted domains, provider that has access to the postmaster account. case (1) wildcard/catch-all addresses ( *@example.com ) are allowed by some services (even Google's G Suite) as a delivery method when an email address does not map to a traditional email account. RFC 5321 section 2.3.11. (Mailbox and Address) allows such usage of wildcard email addresses and they are VERY useful when used as receive-only addresses for anti-spam usage and as indicators of compromise in case of data leaks in 3rd party databases. S/MIME certificates for such wildcard addresses should not be allowed without strict verification - such certificates should require at least Domain Validation or a validation method of equal strength to what the domain already has (if it has a cert already). If the domain has an OV or EV certificate then the S/MIME certificate for the wildcard should use, in addition to DV, at least the same validation rules. I use a wildcard configuration with receive-only addresses tailored to the service that asks them and made up on the spot (e.g. --- @ domain), for almost anything that asks me for an email address. This way i can even use a pen on a traditional paper form and make up an unique email address JUST for filling on that form. If that address starts to receive unsolicited mail from anywhere else except the site/company it was designed for then that means that they either sold my data to a 3rd party or they had a data leak and the EU GDPR is very unforgiving with such usage. GMail's traditional plus-aliased addresses are not really usable anymore because many sites do not allow "plus" characters in email addresses. Wildcards are much more flexible for this. case (2): that of the email provider for hosted domains, provider that has access to the postmaster account - this is a form of delegation of email verification to a third-party. In this case the postmaster account used by the email provider for technical management of the service should not be allowed to be used to obtain wildcard S/MIME certificates (but they can obtain regular, non-wildcard ones). root or webmaster would be more suitable as contact addresses in this case. Again, i use G Suite as an example why: when using email for domains hosted at GMail then the domain owner must give access to the abuse and postmaster accounts to Google Support. In my opinion this access is ok for managing the service, but is not ok when performing validations to obtain S/MIME certs for wildcard catch-all addresses. Adrian R. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request
Hello can you please sign the PDF files on that site? the very first page of CPS_eidas_EN_v_1_2_3.pdf says "Document valid only in digital format digitally signed by the Policy Authority" but the PDF that i was offered to download is not signed and was delivered via a plain http link, are those working draft versions and not final? I also looked at a few of the older/other versions published there: CPS_EN_v_3_3.pdf - PDF not signed but that phrase is not present either. CPS_eidas_v_1_2_1_EN.pdf - (april 2017) same phrase is present on the first page but the PDF file is not signed. CPS_eidas_EN_v_1_1.pdf - (nov 2016) - signed PDF (and that phrase is not present) Adrian R. On Tuesday, 27 March 2018 12:42:50 UTC+3, ramiro...@gmail.com wrote: > > > New versions of CPS are being published today in our WebSite. > > http://www.camerfirma.com/en/area-de-usuario/jerarquia-politicas-y-practicas-de-certificacion/ > > CPS-EIDAS (2016 root) v 1.2.3 > CPS (2003 2008 roots) v.3.3 > > Regards > Ramiro ___ 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)
Matthew Hardeman wrote: > 6. Thus, the direction this goes is that the developer creates a self-signed > cert and imports it into the trust store. The developer may do this on the > software host, but historically is more likely to just create one and package > it just like they did with the trusted ones before. Only now, the developer > has to annoyingly ask for admin permission to install the certificate to the > trust store. All because they want to be able to run web-sockets or HTTP(s) > to the local host at the command of the browser, as directed by a remote web > site. Mere revocation of the trusted certificates is not sufficient to stop > the bad practices which will arise (and have already arisen) in response to > revoked certificates. > > 7. My proposal would almost certainly halt the interest in trusted > certificates which refer back to the local endpoint -- particularly for > shared certs/keys. > > Thanks, > > Matt Hardeman In the case of "localhost" there's even no need to import the certificate to the certificate store: browsers can be told to automatically skip certificate validation for 'localhost'. Chrome is one of the browsers that implemented this validation bypass for localhost, you need only to set a flag in settings to enable it and you don't need to mess with the certificate store after that: chrome://flags/#allow-insecure-localhost *Allow invalid certificates for resources loaded from localhost.* Allows requests to localhost over HTTPS even when an invalid certificate is presented. Mac, Windows, Linux, Chrome OS, Android Also, these restrictions should fit in nicely with the upcoming standard https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-02 Adrian R. ___ 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)
P.S. i assumed only a TLS context, but the same rule should probably apply for any connection, whether plaintext or SSL/TLS: > If the url resource resolves to local IP addresses then only reserved names > from > https://cabforum.org/wp-content/uploads/Guidance-Deprecated-Internal-Names.pdf > should be allowed ___ 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)
+1 imho that would be the best idea, and the local/non-local check should happen inside the same PKI-validation logic flow that is used for certificate validation. If the url resource resolves to local IP addresses then only reserved names from https://cabforum.org/wp-content/uploads/Guidance-Deprecated-Internal-Names.pdf should be allowed to continue with the certificate validation logic. I think that would be the best approach that also allows continued use of internal names for local ip addresses. Adrian R. Matthew Hardeman wrote: > The only way that will ever happen is to fix the browser to kill the > capability to hit a local IP endpoint if the main resource is non-local. > Once that change is made, the software developers will have far less > incentive to do things like this. ___ 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)
those cases can be easily ruled out like this: 1) after authentication in the BattleNet app and the app starts properly, disconnect the device from any network. In my case i physically unplugged the ethernet cable from the PC, and it has no other connection available, not even wireless. 2) try to access the same site: https://127.0.0.1:22886 result: https://imgur.com/A9kW8nh since the local web server still works and there is no connection to the outside world, the private key must be here, somewhere. Adrian R. On Monday, 25 December 2017 17:59:24 UTC+2, Peter Bowen wrote: > The problem is that this is not true. I've not investigated this > software at all, but there are two designs I have seen in other > software: ___ 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)
since it's a webserver running on the local machine and is using that certificate key/pair, i think that someone more capable than me can easily extract the key from it. >From my point of view as an observer it's plainly obvious that the private key >must be on my local machine too, even if i haven't actually got to the key >itself yet. On Monday, 25 December 2017 16:58:42 UTC+2, Jeremy Rowley wrote: > I think this raises a question on what level of investigation and assumption > is required by the ca. Let's encrypt, for example, requires submission of the > private key for revocation (https://letsencrypt.org/docs/revoking/). Is > simply providing a reference rather than the key sufficient? > ___ 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)
1) get a virtual machine 2) install windows, install the Blizzard BattleNet client. 3) create a BattleNet account with any email address - it's free, subscription/payment is not required for this. 4) login in the BattleNet app client with the account from step 3. 5) after the main BattleNet interface appears and shows that the user is properly logged in to their BattleNet account, open https://127.0.0.1:22886/ in a web browser on the same virtual machine result: this screen appears: https://imgur.com/v5vqedX On Monday, 25 December 2017 16:44:03 UTC+2, Jeremy Rowley wrote: > Without the private key, im not sure how we're supposed to confirm key > compromise. > ___ 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)
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? On Monday, 25 December 2017 12:42:05 UTC+2, Hanno Böck wrote: > 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)
The BattleNet app needs to be installed and running, i am logged in with a battlenet account. the public certificate is attached below and i don't know how to get the private key from inside the app, but it must be there since it runs as local webserver on 127.0.0.1 Adrian R. -BEGIN CERTIFICATE- MIIFbTCCBFWgAwIBAgIQCn+uUpLudsH09lYYIPTK5DANBgkqhkiG9w0BAQsFADBw MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 d3cuZGlnaWNlcnQuY29tMS8wLQYDVQQDEyZEaWdpQ2VydCBTSEEyIEhpZ2ggQXNz dXJhbmNlIFNlcnZlciBDQTAeFw0xNzEyMTMwMDAwMDBaFw0xODEyMTgxMjAwMDBa MHQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMQ8wDQYDVQQHEwZJ cnZpbmUxJTAjBgNVBAoTHEJsaXp6YXJkIEVudGVydGFpbm1lbnQsIEluYy4xGDAW BgNVBAMTD2xvY2FsYmF0dGxlLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAL7pCsdGFhOe0aTk/1zPuBhD+5dc4Lg6VMg+Y+HRfJv9nlLfFoDKS2dy 3cwPTW3NaQqNRhGug5ODBsoLUOI7heT4tiv91yQ+OlIFENsS1vWgba85ifIKt3pS PG6kLc96nZ3JLpU4qjXOiF14/BECtNfBnIRsq60Vd/STWSNo84XrEvYBraTXT7Pg kkU2DFeUcl9pvfcsLmtJ4tUk1E1euL7cqQxN5LRr+6hPyhN1rqB5SEaWoIaUd4OD stR4H8RbxCXunIUS3o1O12cWAt4q4jDTay+8Bqy0sYGPvlLSOHMSrWHshpMGMVUL Plh5pKpXQn78usEyTw4O3hDPFnHv4McCAwEAAaOCAf0wggH5MB8GA1UdIwQYMBaA FFFo/5CvAgd1PMzZZWRiohK4WXI7MB0GA1UdDgQWBBTlPRA/nSH/T/W5QfGmpEwp YI/YEzAvBgNVHREEKDAmgg9sb2NhbGJhdHRsZS5uZXSCE3d3dy5sb2NhbGJhdHRs ZS5uZXQwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF BQcDAjB1BgNVHR8EbjBsMDSgMqAwhi5odHRwOi8vY3JsMy5kaWdpY2VydC5jb20v c2hhMi1oYS1zZXJ2ZXItZzYuY3JsMDSgMqAwhi5odHRwOi8vY3JsNC5kaWdpY2Vy dC5jb20vc2hhMi1oYS1zZXJ2ZXItZzYuY3JsMEwGA1UdIARFMEMwNwYJYIZIAYb9 bAEBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMw CAYGZ4EMAQICMIGDBggrBgEFBQcBAQR3MHUwJAYIKwYBBQUHMAh0dHA6Ly9v Y3NwLmRpZ2ljZXJ0LmNvbTBNBggrBgEFBQcwAoZBaHR0cDovL2NhY2VydHMuZGln aWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkhpZ2hBc3N1cmFuY2VTZXJ2ZXJDQS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQsFAAOCAQEAaAidMTizU/KDox3Rd/Ak 9u/iGbGjwssc9582FoRQVBdOxVkvxNWy/+9As/v6HUhZhWRBYOPMwvMSYBufNcdq +zrEK8uJU4T0zI684pqzVsPwpFw3t9JzcdTZGScrD5//7fAkTql4YW9FGTyWz4ka qXwt19R615xxFBGPt25jaB2vZHXrHl3v49GkntFpvlKLwhlidcrVg1F3px4di7c3 OR82PbAnjipHzg0KXZWZdbRh3IliYgoH31ygkuVKLd3HrmsDIXYe+zN/nWLA6tw0 O9NKI7THpe62be+Anarbvj9x3/78+rojqMl/oXpiNEKl/lOYuFKomtt+sA7NxNL0 kg== -END CERTIFICATE- On Monday, 25 December 2017 12:17:36 UTC+2, Hanno Böck wrote: > On Sun, 24 Dec 2017 23:07:56 -0800 (PST) > "Adrian R. via dev-security-policy" > <dev-security-policy@lists.mozilla.org> wrote: > > > on any computer with BattleNet installed and active go to this url: > > > > https://127.0.0.1:22886/ > > and currently it uses this certificate... which doesn't appear on > > crt.sh yet > > I'm not able to reproduce this. Right now if I install battle.net I > don't get a listening port on 22886 at all. Can you please export the > certificate and send it here? > > > -- > Hanno Böck > https://hboeck.de/ > > mail/jabber: ha...@hboeck.de > GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)
p.s. 1) i posted here because i don't even have access to viewing the Blizzard bug on Bugzilla, even if i'm logged in with a Bugzilla account I get the message " You are not authorized to access bug 1425166. " 2) i also sent the same message to the certificate problem-reporting address specified at https://www.digicert.com/certificate-revocation.htm Adrian R. > Bug Blizzard: > https://bugzilla.mozilla.org/show_bug.cgi?id=1425166 > Cert Blizzard: > https://crt.sh/?id=26142 ___ 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)
> Bug Blizzard: > https://bugzilla.mozilla.org/show_bug.cgi?id=1425166 > Cert Blizzard: > https://crt.sh/?id=26142 > Blizzard went to DigiCert and got another certificate instead: 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 https://crt.sh/?q=%25localbattle.net Certificate: Data: Version: 3 (0x2) Serial Number: 0a:7f:ae:52:92:ee:76:c1:f4:f6:56:18:20:f4:ca:e4 Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 High Assurance Server CA Validity Not Before: Dec 13 00:00:00 2017 GMT Not After : Dec 18 12:00:00 2018 GMT Subject: C=US, ST=California, L=Irvine, O=Blizzard Entertainment, Inc., CN=localbattle.net Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:be:e9:0a:c7:46:16:13:9e:d1:a4:e4:ff:5c:cf: b8:18:43:fb:97:5c:e0:b8:3a:54:c8:3e:63:e1:d1: 7c:9b:fd:9e:52:df:16:80:ca:4b:67:72:dd:cc:0f: 4d:6d:cd:69:0a:8d:46:11:ae:83:93:83:06:ca:0b: 50:e2:3b:85:e4:f8:b6:2b:fd:d7:24:3e:3a:52:05: 10:db:12:d6:f5:a0:6d:af:39:89:f2:0a:b7:7a:52: 3c:6e:a4:2d:cf:7a:9d:9d:c9:2e:95:38:aa:35:ce: 88:5d:78:fc:11:02:b4:d7:c1:9c:84:6c:ab:ad:15: 77:f4:93:59:23:68:f3:85:eb:12:f6:01:ad:a4:d7: 4f:b3:e0:92:45:36:0c:57:94:72:5f:69:bd:f7:2c: 2e:6b:49:e2:d5:24:d4:4d:5e:b8:be:dc:a9:0c:4d: e4:b4:6b:fb:a8:4f:ca:13:75:ae:a0:79:48:46:96: a0:86:94:77:83:83:b2:d4:78:1f:c4:5b:c4:25:ee: 9c:85:12:de:8d:4e:d7:67:16:02:de:2a:e2:30:d3: 6b:2f:bc:06:ac:b4:b1:81:8f:be:52:d2:38:73:12: ad:61:ec:86:93:06:31:55:0b:3e:58:79:a4:aa:57: 42:7e:fc:ba:c1:32:4f:0e:0e:de:10:cf:16:71:ef: e0:c7 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Authority Key Identifier: keyid:51:68:FF:90:AF:02:07:75:3C:CC:D9:65:64:62:A2:12:B8:59:72:3B X509v3 Subject Key Identifier: E5:3D:10:3F:9D:21:FF:4F:F5:B9:41:F1:A6:A4:4C:29:60:8F:D8:13 X509v3 Subject Alternative Name: DNS:localbattle.net, DNS:www.localbattle.net X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 CRL Distribution Points: Full Name: URI:http://crl3.digicert.com/sha2-ha-server-g6.crl Full Name: URI:http://crl4.digicert.com/sha2-ha-server-g6.crl X509v3 Certificate Policies: Policy: 2.16.840.1.114412.1.1 CPS: https://www.digicert.com/CPS Policy: 2.23.140.1.2.2 Authority Information Access: OCSP - URI:http://ocsp.digicert.com CA Issuers - URI:http://cacerts.digicert.com/DigiCertSHA2HighAssuranceServerCA.crt X509v3 Basic Constraints: critical CA:FALSE Signature Algorithm: sha256WithRSAEncryption 68:08:9d:31:38:b3:53:f2:83:a3:1d:d1:77:f0:24:f6:ef:e2: 19:b1:a3:c2:cb:1c:f7:9f:36:16:84:50:54:17:4e:c5:59:2f: c4:d5:b2:ff:ef:40:b3:fb:fa:1d:48:59:85:64:41:60:e3:cc: c2:f3:12:60:1b:9f:35:c7:6a:fb:3a:c4:2b:cb:89:53:84:f4: cc:8e:bc:e2:9a:b3:56:c3:f0:a4:5c:37:b7:d2:73:71:d4:d9: 19:27:2b:0f:9f:ff:ed:f0:24:4e:a9:78:61:6f:45:19:3c:96: cf:89:1a:a9:7c:2d:d7:d4:7a:d7:9c:71:14:11:8f:b7:6e:63: 68:1d:af:64:75:eb:1e:5d:ef:e3:d1:a4:9e:d1:69:be:52:8b: c2:19:62:75:ca:d5:83:51:77:a7:1e:1d:8b:b7:37:39:1f:36: 3d:b0:27:8e:2a:47:ce:0d:0a:5d:95:99:75:b4:61:dc:89:62: 62:0a:07:df:5c:a0:92:e5:4a:2d:dd:c7:ae:6b:03:21:76:1e: fb:33:7f:9d:62:c0:ea:dc:34:3b:d3:4a:23:b4:c7:a5:ee:b6: 6d:ef:80:9d:aa:db:be:3f:71:df:fe:fc:fa:ba:23:a8:c9:7f: a1:7a:62:34:42:a5:fe:53:98:b8:52:a8:9a:db:7e:b0:0e:cd: c4:d2:f4:92 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DigiCert-Symantec Announcement
a small question: what's going to happen with https://www.freessl.com/ ? under Symantec's leadership it was intended for the site to become a free alternative to StartCom and LetsEncrypt, but it was not quite opened for issuance except for non-profits. Now with the transition of the CA activities to DigiCert i haven't seen anything about it, not even the site blog over there says anything about it. https://www.freessl.com/freessl/blog/ Any news about it? Thanks, ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
SHA-1 collision
Hello i just saw this in the news... a SHA-1 collision has been achieved. https://arstechnica.com/security/2017/02/at-deaths-door-for-years-widely-used-sha1-function-is-now-dead/ proof site: https://shattered.io/ authors: Marc Stevens (1), Elie Bursztein (2), Pierre Karpman (1), Ange Albertini (2), Yarik Markov (2) 1 = CWI Amsterdam 2 = Google Research File: shattered-1.pdf CRC-32: 348150fb MD5: ee4aa52b139d925f8d8884402b0a750c SHA-1: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a SHA-256: 2bb787a73e37352f92383abe7e2902936d1059ad9f1ba6daaa9c1e58ee6970d0 SHA-512: 3c19b2cbcf72f7f5b252ea31677b8f2323d6119e49bcc0fb55931d00132385f1e749bb24cbd68c04ac826ae8421802825d3587fe185abf709669bb9693f6b416 File: shattered-2.pdf CRC-32: b3fbab1c MD5: 5bd9d8cabc46041579a311230539b8d1 SHA-1: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a SHA-256: d4488775d29bdef7993367d541064dbdda50d383f89f0aa13a6ff2e0894ba5ff SHA-512: f39a04842e4b28e04558496beb7cb84654ded9c00b2f873c3ef64f9dfdbc760cd0273b816858ba5b203c0dd71af8b65d6a0c1032e00e48ace0b4705eedcc1bab ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
