Re: Incident Report – Certificates issued without proper domain validation
On 20/01/2017 00:35, Nick Lamb wrote:
On Thursday, 19 January 2017 20:20:24 UTC, Jakob Bohm wrote:
Google's CT initiative in its current form has serious privacy problems
for genuine certificate holders. I applaud any well-run CA that stands
up to this attack on the Internet at large.
I notice that you have not specifically identified which Certificate Authorities you
believe are "well-run", perhaps your argument would have more force if you
could name some market leaders in that category.
Presumably most that haven't been distrusted by Mozilla or otherwise
publicly shamed for massive misissuance.
As a Relying Party for the Web PKI I think Google's initiative makes a sensible
trade off, you can't have privacy while also delivering oversight. The public
CAs are clearly in need of oversight. This did not happen in a vacuum but as a
consequence of trusted Certificate Authorities exhibiting incompetence and
greed over many years.
As both a relying party and a certificate holder, I see no reason for
public listing of most of the details in the CT logs, and I do take
specific measures to not get public certificates for a number of things
(such as my e-mail addresses) that I don't want listed in Google
searches or attacked by spammers.
So far, I have not seen any good uses for CT logging stuff such as:
- Full domain name (below public suffix + 1) for things like employee
/contractor portals.
- Full domain name (below public suffix + 1) for alpha / beta tests,
staging servers etc.
- Full domain name (below public suffic + 1) for CDN / cluster names,
such as r2---sn-op5oxu-j2il.googlevideo.com
- E-mail addresses other than the RFC2142 special ones.
- City and street address.
- Telephone number.
- Citizens ID/Social security number/Company registration ID.
What is really needed for most non-malicious CT uses are the relevant
2nd/3rd level domain (1 level below public suffix), country, state and
organization names (or CN if not an internet name and no O name part),
slow one way hash of full name entries (e.g.
SHA-512**65536("someu...@gmail.com"),
full issuer details, cryptographic algorithm and strength, plus serial
number and technical details such as EKUs and other non-special cased
items.
For example, to check if someone issued a fraudulent certificate for
any domain or address under google.com, Google Inc could check the list
of redacted CT entries for *@*.google.com, then compare it against an
in-house non-public database of such certificates authorized by their
internal management procedures.
To check for certificates issued to non-existent / suspect domains such
as example.com and/or test[1-9].com (recent Symantec related post in
this group), this would still be fully visible too. So would SHA-1
certificates issued in 2016, duplicate serial numbers, etc. Someone
getting a misissued wildcard cert for a semi-public suffix such as
"sf.net" or "blogblog.com" would also show up.
For a service such as gmail.com, the information suggested above would
allow someone knowing a specific e-mail address such as
"someu...@gmail.com" to check if a certificate was misissued for that
address, but would not provide an easy way for a third party (such as a
spammer) to extract a list of all @gmail.com user names that happen to
have S/MIME certificates (Of cause Google has the original list of
their users already, but no one else should).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
RE: Misissued/Suspicious Symantec Certificates
Andrew, thank you for your efforts to report this issue. We are investigating and will report our resolution, cause analysis, and corrective actions once complete. Kind regards, Steven Medin PKI Policy Manager, Symantec Corporation > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of > Andrew Ayer > Sent: Thursday, January 19, 2017 4:46 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Misissued/Suspicious Symantec Certificates > > I. Misissued certificates for example.com > > On 2016-07-14, Symantec misissued the following certificates for > example.com: > > https://clicktime.symantec.com/a/1/LyhH99FiQBwyOqKcts8QGJ75k6 > TPEC_N7jOPRSjGhkA=?d=6VMu_T- > sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW- > AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw- > p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3 > NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D=https%3A%2F%2Fcrt.sh%2F% > 3Fsha256%3DA8F14F52CC1282D7153A13316E7DA39E6AE37B1A10C16288B902 > 4A9B9DC3C4C6 > https://clicktime.symantec.com/a/1/_X1- > P9bvSq0r_QG43YQ6BwhHeeRl4IrY8ebwWh9HWiQ=?d=6VMu_T- > sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW- > AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw- > p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3 > NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D=https%3A%2F%2Fcrt.sh%2F% > 3Fsha256%3D8B5956C57FDCF720B6907A4B1BC8CA2E46CD90EAD5C061A426C > F48A6117BFBFA > https://clicktime.symantec.com/a/1/1ux2sxPZpTNuRjN4JV5qOj0550 > RDi16i7NLrqi0eFaY=?d=6VMu_T-sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW- > AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw- > p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3 > NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D=https%3A%2F%2Fcrt.sh%2F% > 3Fsha256%3D94482136A1400BC3A1136FECA3E79D4D200E03DD20B245D19F0E > 78B5679EAF48 > https://clicktime.symantec.com/a/1/YT02EQBzJ13G0VwF_VLruHbKA > Ep4LXe40icNc0DLwUA=?d=6VMu_T- > sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW- > AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw- > p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3 > NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D=https%3A%2F%2Fcrt.sh%2F% > 3Fsha256%3DC69AB04C1B20E6FC7861C67476CADDA1DAE7A8DCF6E23E15311 > C2D2794BFCD11 > > I confirmed with ICANN, the owner of example.com, that they did not > authorize these certificates. These certificates were already revoked at the > time I found them. > > > II. Suspicious certificates for domains containing the word "test" > > On 2016-11-15 and 2016-10-26, Symantec issued certificates for various > domains containing the word "test" which I strongly suspect were > misissued: > > https://clicktime.symantec.com/a/1/_0lsjfT3DHqxu1QJl2eBU5zx948r > qJmGy-bHkTlww3c=?d=6VMu_T-sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW- > AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw- > p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3 > NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D=https%3A%2F%2Fcrt.sh%2F% > 3Fsha256%3Db81f339b971eb763cfc686adbac5c164b89ad03f8afb55da9604fd0 > d416bbd21 > https://clicktime.symantec.com/a/1/uF90PPzN7N3_lTMmPb8YzXKK > AfWPKKNmpvo_prjlE3Y=?d=6VMu_T- > sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- >
Re: Incident Report – Certificates issued without proper domain validation
On Thursday, 19 January 2017 20:20:24 UTC, Jakob Bohm wrote: > Google's CT initiative in its current form has serious privacy problems > for genuine certificate holders. I applaud any well-run CA that stands > up to this attack on the Internet at large. I notice that you have not specifically identified which Certificate Authorities you believe are "well-run", perhaps your argument would have more force if you could name some market leaders in that category. As a Relying Party for the Web PKI I think Google's initiative makes a sensible trade off, you can't have privacy while also delivering oversight. The public CAs are clearly in need of oversight. This did not happen in a vacuum but as a consequence of trusted Certificate Authorities exhibiting incompetence and greed over many years. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Misissued/Suspicious Symantec Certificates
I. Misissued certificates for example.com On 2016-07-14, Symantec misissued the following certificates for example.com: https://crt.sh/?sha256=A8F14F52CC1282D7153A13316E7DA39E6AE37B1A10C16288B9024A9B9DC3C4C6 https://crt.sh/?sha256=8B5956C57FDCF720B6907A4B1BC8CA2E46CD90EAD5C061A426CF48A6117BFBFA https://crt.sh/?sha256=94482136A1400BC3A1136FECA3E79D4D200E03DD20B245D19F0E78B5679EAF48 https://crt.sh/?sha256=C69AB04C1B20E6FC7861C67476CADDA1DAE7A8DCF6E23E15311C2D2794BFCD11 I confirmed with ICANN, the owner of example.com, that they did not authorize these certificates. These certificates were already revoked at the time I found them. II. Suspicious certificates for domains containing the word "test" On 2016-11-15 and 2016-10-26, Symantec issued certificates for various domains containing the word "test" which I strongly suspect were misissued: https://crt.sh/?sha256=b81f339b971eb763cfc686adbac5c164b89ad03f8afb55da9604fd0d416bbd21 https://crt.sh/?sha256=f45d090e1bf24738a8e86734aa7acf7c9e65b619eb19660b1f73c9973f11b841 https://crt.sh/?sha256=bcbc26c9e06c4fe1c9e4d55fa27a501c504ea84e23e114b8ac004f7c0776cd0b https://crt.sh/?sha256=f0935ce297419cc148bde49a7a123f2b2419cdd52df8e7f49e7bba07fe872559 https://crt.sh/?sha256=3601ab49034e69d6e2137a80e511a0640252f444b75d6baca7bf4672c35652a5 I have not attempted to contact the owners of these domains for confirmation, as doing so is probably not feasible (many of the domains are owned by squatters). However, the following facts lead to me to believe that these certificates were misissued: 1. The subject DNs contain clearly bogus values, such as: C=KR, ST=1, L=1, O=12, OU=1 C=KR, ST=1, L=1, O=1, OU=1 C=KR, ST=1, L=1, O=12, OU=1 C=KR, ST=Test1, L=Test, O=Test Note that the misissued example.com certificates also contain C=KR in their subjects. 2. The third certificate in the list above contains a SAN for DNS:*.crosscert.com - note that three of the misissued example.com certificates contain "Crosscert" in their Subject Organization. 3. None of these certificates have been observed in the wild by Censys. The live certificate for www.test.com was issued by Network Solutions. 4. The first two certificates in the list above both contain DNS SANs for *all* of the following domains: test.com test1.com test2.com test3.com test4.com test5.com test6.com test7.com test8.com test9.com test11.com With the exception of test4.com and test8.com, these domains are registered to different entities and appear to be wholly unrelated with one another in both ownership and operation. It is unlikely that the owners of these domains would collaborate to authorize these certificates. These certificates were already revoked at the time I found them. III. Certificates with O=Test Finally, Symantec has issued a large number of certificates with the following attributes in the Subject: C=KR, ST=test, L=test, O=test, OU=test e.g.: https://crt.sh/?sha256=09AECE5B94BBB8A9EE2152FA6FB7261630124918DA015EB3571508EF6D31DD30 https://crt.sh/?sha256=CC0A2AE0EF5B1A6CF242D7B4C77AC9F05B49494B42C8486B47804874734CFC1C https://crt.sh/?sha256=F177AC0064167354025CE12B3914A0E056628DD31152B5DF22E41913FC9D9B45 https://crt.sh/?sha256=DA7B1D433C071DA7A389EE2A4CAB854B89E441277B41E608F05FB7C7C6B2A761 For more, see: https://crt.sh/?O=test I doubt there is an organization named "test" located in "test, Korea." Regards, Andrew ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incident Report – Certificates issued without proper domain validation
On 19/01/2017 01:33, montel.bahn...@gmail.com wrote: On Thursday, January 12, 2017 at 7:38:47 PM UTC-5, Itzhak Daniel wrote: Why not posting _ALL_ certificates issues via that method to CT log? We had to nag and whine for a year to get IXSystems and FreeNAS folks to finally, begrudgingly use TLS (for Download of ISOs and SHA256 no less!). The 'Volunteers' and staff deleted my posts, accused me of trolling and stated that the CAs' system was something like bunk or a laughing stock. Though not a commiter or security guru, I submit that: If a CA refuses to take advantage of Google's Certificate Transparency Project or otherwise public log per RFC 6962, then Mozilla MUST shun them! Google's CT initiative in its current form has serious privacy problems for genuine certificate holders. I applaud any well-run CA that stands up to this attack on the Internet at large. I mean who dares disagree? Surely this is a non-partisan issue with Mozilla Devs AND majority of Firefox Users? Let's keep on topic of GoDaddy's second insufficiency, though it's not alone on the consensus naughty-list. I assume some relevant browser Devs were shown proof of what happened in detail? Can they complain their spaghetti code is that proprietary, really. It surely is not valuable now as a work product. Just sign NDAs if they won't the bother. The 'lapses' WILL keep getting more convoluted and ridiculous if Mozilla, Google et al. don't finally draw the line. I have no reason to believe Mozilla employees have any relevant GoDaddy information not posted right here on this newsgroup and the associated public web pages, bug trackers etc. This newsgroup is *the* place where Mozilla finds out these things. you and I are essentially standing inside the room where all this is happening, seeing and hearing almost everything that goes on, and even getting to contribute our opinions. PS: FreeNAS is still using GoDadddy, even though they have other valid certificates per: https://www.google.com/transparencyreport/https/ct/ Not at all relevant to this newsgroup. ...somebody has to lead by example and soon! Hopefully not you. Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.4 Proposal: Define how quickly audit reports must be provided
On 18/01/17 15:31, Kurt Roeckx wrote: > And I would like to see that as a requirement in the audit report, > which CA are actually checked. https://github.com/mozilla/pkipolicy/issues/50 . Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incident Report – Certificates issued without proper domain validation
On Thursday, January 12, 2017 at 7:38:47 PM UTC-5, Itzhak Daniel wrote: > Why not posting _ALL_ certificates issues via that method to CT log? We had to nag and whine for a year to get IXSystems and FreeNAS folks to finally, begrudgingly use TLS (for Download of ISOs and SHA256 no less!). The 'Volunteers' and staff deleted my posts, accused me of trolling and stated that the CAs' system was something like bunk or a laughing stock. Though not a commiter or security guru, I submit that: If a CA refuses to take advantage of Google's Certificate Transparency Project or otherwise public log per RFC 6962, then Mozilla MUST shun them! I mean who dares disagree? Surely this is a non-partisan issue with Mozilla Devs AND majority of Firefox Users? Let's keep on topic of GoDaddy's second insufficiency, though it's not alone on the consensus naughty-list. I assume some relevant browser Devs were shown proof of what happened in detail? Can they complain their spaghetti code is that proprietary, really. It surely is not valuable now as a work product. Just sign NDAs if they won't the bother. The 'lapses' WILL keep getting more convoluted and ridiculous if Mozilla, Google et al. don't finally draw the line. PS: FreeNAS is still using GoDadddy, even though they have other valid certificates per: https://www.google.com/transparencyreport/https/ct/ ...somebody has to lead by example and soon! ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
