Re: Cerificate Concern about Cloudflare's DNS
On 11/09/2016 12:37 AM, Han Yuwei wrote: I am using Cloudflare's DNS service and I found that Cloudflare has issued a certficate to their server including my domain. But I didn't use any SSL service of theirs. Is that ok to Mozilla's policy? Issued certificate:https://crt.sh/?id=31206531 My domain is BUPT.MOE I'm just going to reply to the top of the thread because it addresses something said in multiple places now. Is it allowed? Surely yes. From: https://www.cloudflare.com/plans/ "Free Includes... These great features: * ... * Shared SSL Certificate * ..." IMO it doesn't need to be in the Ts&Cs because it says right on the box that an SSL certificate is included with your plan. Should Cloudflare allow an opt-out? Maybe, but that seems to be a feature/enhancement request rather than a problem. (Rob's case with crt.sh is an example where an opt-out would be a good thing) - N ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Update on transition of the Verizon roots and issuance of SHA1 certificates
I'm not sure exactly what you are asking. These sub CAs are cross-signs with other entities. DigiCert controls the root, but not the issuing CAs. Except for the ones I listed, they are all WebTrust or ETSI audited so we trust them. They are primarily government, large corporations, and other CAs. Most are transferring away from DigiCert or moving to a solution where we host the private keys and certificates. There are some who insist on operating their own root and cross-sign for ubiquity. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of Han Yuwei Sent: Thursday, November 3, 2016 6:14 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Update on transition of the Verizon roots and issuance of SHA1 certificates 在 2016年11月4日星期五 UTC+8上午3:52:23,Jeremy Rowley写道: > Resent without a signature > > > > Hi everyone, > > > > This email is intended to gather public and browser feedback on how we are > handling the transitioning Verizon's customers to DigiCert and share with > everyone the plan for when all non-DigiCert hosted sub CAs will be fully > compliant with the BRs and network security guidelines. Primarily, this > letter addresses when all issuing CAs previously held by Verizon will be > covered by an unqualified audit and how we are responding to the sub CAs that > issued SHA1 certificates. We are looking forward to the browser and public > feedback on how to handle the non-compliant cross-signs and insight on how > the public views our transition progress and planned completion dates. > > > > Background > > Prior to presenting the plan for remediation, I thought I'd share a bit about > our progress with migrating Verizon customers. About a year ago in July, > DigiCert closed an agreement with Verizon where DigiCert took ownership of > three publicly-trusted Verizon root certificates. These certificates are the > Verizon Global Root CA, the Baltimore CyberTrust Root CA, and the Verizon > Root CA. There were many reasons the acquisition made sense, including > acquisition of a root that had cross-signed DigiCert for many years. The > ubiquity of the Verizon roots is wide-spread, which meant a lot of CAs like > to cross-sign with them. Another significant reason for the acquisition was > an attempt to improve the CA industry. After watching the issuance of > wildcard EV certs, non-compliant subordinate CAs, and certs with poor > profiles, we made a conscious decision to purchase these roots with the > intention of migrating them to more complaint system. We felt that helping > these CAs get to the point of regular audits and best practices would raise > the quality of the entire industry. > > > > Prior to the acquisition, we were made aware of several potential > non-compliances by Verizon's customers. We worked closely with Verizon to > clean up many of the Sub CAs, including revoking CAs that would never be > compliant with the requirements and attempting to technically constrain > others. Sub CAs were revoked because they either didn't have an audit, were > unresponsive to communication, or couldn't control their issuance. Verizon > was a great partner and took a very proactive approach in removing CAs that > were not actively working towards compliance. Unfortunately, the age of the > roots and large number of cross-signs led to a lot of missing paperwork and > certain issues in identifying which CAs were covered by audits. Prior to > closing we believed there were approximately five technically constrained sub > CAs and around 20 unconstrained sub CAs. Turns out there were actually more > than 200, each with various levels of compliance. Most of these Sub CAs > operated under the Baltimore Cybertrust root, which was created in 2000. > > > > To their credit, Verizon revoked 48 of the issuing CAs prior to DigiCert's > acquisition of the roots. Unfortunately, this left around 150 for our small > team to work through. Although the endeavor was daunting, Ben Wilson and > others worked to gather audit reports, email customers about compliance > dates, monitor certificates issued, and revoke non-compliant customers. > Verizon was very good at assisting us in these efforts. This information is > now recorded in the Mozilla database and continuously updated as the > information changes. > > > > Transition Process > > After our operational acquisition of the roots (which occurred the last part > of September, 2015), we identified 15 expired issuing CAs, 70 revoked sub > CAs, 131 audited sub CAs, and 36 where the status was unknown. Since then, > we've revoked 25 issuing CAs and assisted others with technical constraints, > exodus from the Omniroot cross-signing program, or obtaining audits. Of the > existing sub CAs, about half remain operational and are either audited or > technically constrained. The other half are eit
Re: Update on transition of the Verizon roots and issuance of SHA1 certificates
On Thu, Nov 3, 2016 at 11:28 AM, Jeremy Rowley wrote: > This email is intended to gather public and browser feedback on how we are > handling the transitioning Verizon's customers to DigiCert and share with > everyone the plan for when all non-DigiCert hosted sub CAs will be fully > compliant with the BRs and network security guidelines. Primarily, this > letter addresses when all issuing CAs previously held by Verizon will be > covered by an unqualified audit and how we are responding to the sub CAs > that issued SHA1 certificates. We are looking forward to the browser and > public feedback on how to handle the non-compliant cross-signs and insight > on how the public views our transition progress and planned completion > dates. Jeremy, Thank you for addressing this non-compliance head on. While it probably would have been better to raise this when you became aware of it, it is good that DigiCert brought this to the group proactively rather than waiting for a discussion on "should we dump these roots". I have a bunch of questions, through out the document. First, a couple of questions about DigiCert itself. The press release at https://thomabravo.com/2015/10/22/thoma-bravo-completes-acquisition-of-majority-stake-in-digicert/ says that Thoma Bravo acquired a majority stake in DigiCert in October 2015. Looking at the current portfolio (https://thomabravo.com/portfolio/all/current/), I don't see any other CAs, but can you confirm that (a) they still own a majority & controlling share of DigiCert and (b) that Thoma Bravo does not own a majority or controlling share (directly or indirectly) of any other CA? What is the relationship between Cyber Secure Asia (https://www.cybersecureasia.com/about-cyber-secure-asia-csa/newsroom) and DigiCert? Are they a subsidiary, a subordinate CA, a reseller or something else? It is hard to tell, as they talk about DigiCert all over their site but also say something about being a subsidiary of CyberTrust Japan (which might be part of DigiCert?) > About a year ago in > July, DigiCert closed an agreement with Verizon where DigiCert took > ownership of three publicly-trusted Verizon root certificates. These > certificates are the Verizon Global Root CA, the Baltimore CyberTrust Root > CA, and the Verizon Root CA. According to https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport, DigiCert currently has 10 roots in the Mozilla trust anchor list. These include eight with "DigiCert Inc" in the organization name attribute, one with "Baltimore" in the organization name attribute, and one with "CyberTrust, Inc" in the organization name attribute. The removed CA report (https://mozillacaprogram.secure.force.com/CA/RemovedCACertificateReport) lists one root as belonging to DigiCert. This has "GTE Corporation" in the organization name attribute. You list three root certificates in your email. Which of the DigiCert certificates in the Mozilla root reports map to the three you list? You talk about taking ownership of three "root certificates". Did you also take ownership and control of all copies of the associated private keys? Did you take control of other CAs and private keys (e.g. subordinate CAs) or just the three listed above? > After watching the > issuance of wildcard EV certs, non-compliant subordinate CAs, and certs with > poor profiles, we made a conscious decision to purchase these roots with the > intention of migrating them to more complaint system. We felt that helping > these CAs get to the point of regular audits and best practices would raise > the quality of the entire industry. So would just revoking them. > Unfortunately, the age of the > roots and large number of cross-signs led to a lot of missing paperwork and > certain issues in identifying which CAs were covered by audits. Prior to > closing we believed there were approximately five technically constrained > sub CAs and around 20 unconstrained sub CAs. Turns out there were actually > more than 200, each with various levels of compliance. Most of these Sub CAs > operated under the Baltimore Cybertrust root, which was created in 2000. > To their credit, Verizon revoked 48 of the issuing CAs prior to DigiCert's > acquisition of the roots. Given this huge variance, how sure are you that you have identified all the CA certificates issued by these roots? Did all of the CA certificates include zero path length constraints or are there possibly whole trees of CAs out there that are unknown? > After our operational acquisition of the roots (which occurred the last part > of September, 2015), we identified 15 expired issuing CAs, 70 revoked sub > CAs, 131 audited sub CAs, and 36 where the status was unknown. Since then, > we've revoked 25 issuing CAs and assisted others with technical constraints, > exodus from the Omniroot cross-signing program, or obtaining audits. What is "Omniroot"? How many of these are operated by DigiCert and how many are operated by unaffiliated third pa
Re: Update on transition of the Verizon roots and issuance of SHA1 certificates
在 2016年11月4日星期五 UTC+8上午3:52:23,Jeremy Rowley写道: > Resent without a signature > > > > Hi everyone, > > > > This email is intended to gather public and browser feedback on how we are > handling the transitioning Verizon's customers to DigiCert and share with > everyone the plan for when all non-DigiCert hosted sub CAs will be fully > compliant with the BRs and network security guidelines. Primarily, this > letter addresses when all issuing CAs previously held by Verizon will be > covered by an unqualified audit and how we are responding to the sub CAs that > issued SHA1 certificates. We are looking forward to the browser and public > feedback on how to handle the non-compliant cross-signs and insight on how > the public views our transition progress and planned completion dates. > > > > Background > > Prior to presenting the plan for remediation, I thought I'd share a bit about > our progress with migrating Verizon customers. About a year ago in July, > DigiCert closed an agreement with Verizon where DigiCert took ownership of > three publicly-trusted Verizon root certificates. These certificates are the > Verizon Global Root CA, the Baltimore CyberTrust Root CA, and the Verizon > Root CA. There were many reasons the acquisition made sense, including > acquisition of a root that had cross-signed DigiCert for many years. The > ubiquity of the Verizon roots is wide-spread, which meant a lot of CAs like > to cross-sign with them. Another significant reason for the acquisition was > an attempt to improve the CA industry. After watching the issuance of > wildcard EV certs, non-compliant subordinate CAs, and certs with poor > profiles, we made a conscious decision to purchase these roots with the > intention of migrating them to more complaint system. We felt that helping > these CAs get to the point of regular audits and best practices would raise > the quality of the entire industry. > > > > Prior to the acquisition, we were made aware of several potential > non-compliances by Verizon's customers. We worked closely with Verizon to > clean up many of the Sub CAs, including revoking CAs that would never be > compliant with the requirements and attempting to technically constrain > others. Sub CAs were revoked because they either didn't have an audit, were > unresponsive to communication, or couldn't control their issuance. Verizon > was a great partner and took a very proactive approach in removing CAs that > were not actively working towards compliance. Unfortunately, the age of the > roots and large number of cross-signs led to a lot of missing paperwork and > certain issues in identifying which CAs were covered by audits. Prior to > closing we believed there were approximately five technically constrained sub > CAs and around 20 unconstrained sub CAs. Turns out there were actually more > than 200, each with various levels of compliance. Most of these Sub CAs > operated under the Baltimore Cybertrust root, which was created in 2000. > > > > To their credit, Verizon revoked 48 of the issuing CAs prior to DigiCert's > acquisition of the roots. Unfortunately, this left around 150 for our small > team to work through. Although the endeavor was daunting, Ben Wilson and > others worked to gather audit reports, email customers about compliance > dates, monitor certificates issued, and revoke non-compliant customers. > Verizon was very good at assisting us in these efforts. This information is > now recorded in the Mozilla database and continuously updated as the > information changes. > > > > Transition Process > > After our operational acquisition of the roots (which occurred the last part > of September, 2015), we identified 15 expired issuing CAs, 70 revoked sub > CAs, 131 audited sub CAs, and 36 where the status was unknown. Since then, > we've revoked 25 issuing CAs and assisted others with technical constraints, > exodus from the Omniroot cross-signing program, or obtaining audits. Of the > existing sub CAs, about half remain operational and are either audited or > technically constrained. The other half are either winding down or have been > revoked. All revoked certificates were disclosed to Mozilla via Salesforce > and should be part of OneCRL. > > > > Issuing CAs > > There are only a handful of non-audited sub CAs remaining (see > https://crt.sh/mozilla-disclosures#disclosureincomplete). We have a plan for > each of them that we'd like to share with you. We welcome both browser and > public feedback. This is, of course, simply a proposal on how to finish the > transition and provide transparency into where we are at. We are certainly > willing to modify the plan as needed to further online security and meet the > requirements of the root store operators. > > > > The seven companies listed below are responsible for the remaining unaudited > sub CAs: > > > > 1. ABB has three unaudited issuing CAs. ABB didn't under
Re: Cerificate Concern about Cloudflare's DNS
On Thu, Nov 03, 2016 at 03:39:11PM -0700, gerhard.tin...@gmail.com wrote: > On Thursday, November 3, 2016 at 11:23:18 PM UTC+1, Matt Palmer wrote: > > On Thu, Nov 03, 2016 at 02:08:04PM -0700, gerhard.tin...@gmail.com wrote: > > > Sadly, the shady behaviour is not with Comodo but with Cloudflare. As > > > cloudflare does not state anywhere that they issue certificates when SSL > > > and CDN features are explicitly switched off from the beginning. > > > > They do state it: in a blog post from 2014. They appear to believe this is > > sufficient notice. > > Well a blog post is not a TOS or a security policy. But maybe in some far > away country it is accepted. Any way, can you send me the link to that > post?? https://blog.cloudflare.com/introducing-universal-ssl/ > > > 1. trust issue: Cloudflare issues certificates without asking permission > > > or staing it in TOS or elsewhere. Doing so when in DNS-only mode appears > > > to me illegal. > > > > Illegal? In which jurisdiction(s)? > > Well, If you buy a VPS and the provider creates a certificate by > validating by adding content to your webserver, ... we would agree that > this is wrong, right? It would depend on the circumstances. However that is not what happened. > But when I get a service to host MY DNS entries, it > is fine if the provider manipulates them without my knowledge? ... But I > have noticed that in some countries the understanding of legal and iligal > is different. Sad. Which country or countries (or other legal jurisdiction) has an understanding that Cloudflare's behaviour as described in this thread is illegal? You've made a fairly specific claim, I would be interested to see the rationale for it. > > > 2. trust issue: Cloudflare modifies the DNS entries to validate without > > > consent of the domain owner or account holder. Again, no mention of it in > > > TOS or anywheer else. So the modification is not permitted in DNS-only > > > mode. > > > > So go tell Cloudflare. Take your business elsewhere. > > I understand, go and just lieve with a certificate that is issued without > my permission. It seems that CT is useless if there are no actions are > taken from wrong behaviour. There are actions taken for wrong behaviour. It's just that not every wrong behaviour results in the same action. I'm actually interested in what specific action you think should be taken here, and how keeping on about it on this list will help that action to occur. Please, state exactly what you think should be done. > > There is no need to keep banging on about it on this list. Everyone here > > knows what Cloudflare is doing, they have their opinion of it, and as a > > group this list can do nothing about it. > > > > > But from the moment on when the CA (Comodo) is informed about this shady > > > behavior by multiple domain owners / account owners, Comodo should start > > > acting. > > > > As the Wikipedians say: "Citation Needed". > > > > - Matt > > Still sad that wrong behaviour of companies that trick CAs into issuing > certificates What trickery was involved with the CA? Comodo requires proof of control over the domain to issue a certificate. $DEITY knows there are enough perfectly legitimate reasons to look askance at Comodo, but this isn't one of them. Cloudflare demonstrated the required domain control to Comodo, because YOU GAVE CONTROL TO CLOUDFLARE. Cloudflare may well have acted in bad faith, by taking an action you deemed unexpected or illegitimate, however that isn't something that a browser vendor or root store program can do anything about. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Cerificate Concern about Cloudflare's DNS
On Thursday, November 3, 2016 at 11:23:18 PM UTC+1, Matt Palmer wrote: > On Thu, Nov 03, 2016 at 02:08:04PM -0700, gerhard.tin...@gmail.com wrote: > > Sadly, the shady behaviour is not with Comodo but with Cloudflare. As > > cloudflare does not state anywhere that they issue certificates when SSL > > and CDN features are explicitly switched off from the beginning. > > They do state it: in a blog post from 2014. They appear to believe this is > sufficient notice. Well a blog post is not a TOS or a security policy. But maybe in some far away country it is accepted. Any way, can you send me the link to that post?? > > > 1. trust issue: Cloudflare issues certificates without asking permission > > or staing it in TOS or elsewhere. Doing so when in DNS-only mode appears > > to me illegal. > > Illegal? In which jurisdiction(s)? Well, If you buy a VPS and the provider creates a certificate by validating by adding content to your webserver, ... we would agree that this is wrong, right? But when I get a service to host MY DNS entries, it is fine if the provider manipulates them without my knowledge? ... But I have noticed that in some countries the understanding of legal and iligal is different. Sad. > > > 2. trust issue: Cloudflare modifies the DNS entries to validate without > > consent of the domain owner or account holder. Again, no mention of it in > > TOS or anywheer else. So the modification is not permitted in DNS-only > > mode. > > So go tell Cloudflare. Take your business elsewhere. I understand, go and just lieve with a certificate that is issued without my permission. It seems that CT is useless if there are no actions are taken from wrong behaviour. > > There is no need to keep banging on about it on this list. Everyone here > knows what Cloudflare is doing, they have their opinion of it, and as a > group this list can do nothing about it. > > > But from the moment on when the CA (Comodo) is informed about this shady > > behavior by multiple domain owners / account owners, Comodo should start > > acting. > > As the Wikipedians say: "Citation Needed". > > - Matt Still sad that wrong behaviour of companies that trick CAs into issuing certificates is protected by "go away!" comments. I would have expected more. And as this thread shows, I am not alone. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Cerificate Concern about Cloudflare's DNS
On Thu, Nov 03, 2016 at 02:08:04PM -0700, gerhard.tin...@gmail.com wrote: > Sadly, the shady behaviour is not with Comodo but with Cloudflare. As > cloudflare does not state anywhere that they issue certificates when SSL > and CDN features are explicitly switched off from the beginning. They do state it: in a blog post from 2014. They appear to believe this is sufficient notice. > 1. trust issue: Cloudflare issues certificates without asking permission > or staing it in TOS or elsewhere. Doing so when in DNS-only mode appears > to me illegal. Illegal? In which jurisdiction(s)? > 2. trust issue: Cloudflare modifies the DNS entries to validate without > consent of the domain owner or account holder. Again, no mention of it in > TOS or anywheer else. So the modification is not permitted in DNS-only > mode. So go tell Cloudflare. Take your business elsewhere. There is no need to keep banging on about it on this list. Everyone here knows what Cloudflare is doing, they have their opinion of it, and as a group this list can do nothing about it. > But from the moment on when the CA (Comodo) is informed about this shady > behavior by multiple domain owners / account owners, Comodo should start > acting. As the Wikipedians say: "Citation Needed". - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New SHA-1 certificates issued in 2016
On 03/11/2016 18:53, Gervase Markham wrote: On 28/10/16 16:11, Patrick Figel wrote: I found a number of SHA-1 certificates chaining up to CAs trusted by Mozilla that have not been brought up on this list or on Bugzilla yet. Using the handy crt.sh link posted by Rob, I have gone through the 2016 SHA-1 issuances known to crt.sh to filter out those which chain up to a root trusted by Mozilla. (Handily, crt.sh contains this information as well.) There are a distressingly large number of them :-( ... and based on this additional research, I have filed: ... https://bugzilla.mozilla.org/show_bug.cgi?id=1315018 (GlobalSign) Note that the GlobalSign SHA-1 intermediaries chain only to their old SHA-1 root which is (I believe) not used for any SHA-256 certs, except a cross-cert that signs their current SHA-256 root. The recent "revocation runaway" incident was caused by GlobalSign revoking the cross signing of their old SHA-1 root by their current SHA-256 root. So I suspect the intent of GlobalSign is that the old SHA-1 root should loose its ServerAuth trust bit around 2017-01-01, reducing it to a SHA-1-forever root trusted only by old SHA-1-only systems and maybe for e-mail (because some non-Mozilla e-mail clients were very late to supporting SHA-2 e-mail signatures). 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: Cerificate Concern about Cloudflare's DNS
On Thursday, November 3, 2016 at 11:55:15 AM UTC+1, Patrick Figel wrote: > On 03/11/16 10:59, Gervase Markham wrote: > > However, I still don't get why you want to use Cloudflare's SSL > > termination services but are unwilling to allow them to get a > > certificate for your domain name. > > > > AIUI their free tier uses certs they obtain, but if you pay, you can > > provide your own cert. So if you want to use Cloudflare but don't want > > them obtaining certs for you, join the paying tier. > > It is possible to use Cloudflare as a DNS-only provider, without any > CDN/reverse proxying functionality. That's what seems to be the issue > here - certificates are requested as soon as a domain is added to > Cloudflare, even if the CDN functionality is never enabled. > > I don't think these certificates are mis-issued or that this practice is > shady, but I can see how it might surprise a domain owner who is only > looking for a DNS provider. > > This is probably not something that can or should be resolved by the > CA/B Forum or Mozilla. Realistically speaking, asking CAs to confirm > that the actual domain registrant has authorized the issuance (rather > than whoever is operating the DNS for that domain) is not possible in > practice for DV. Going overboard with such a requirement carries the risk > > The only other thing the BRs could ask for is that a subscriber (which > would be Cloudflare in this case) has to include language regarding > certificate issuance in their ToS if they act on behalf of other domain > registrants. However, given that the goal is to avoid surprising the > domain registrant, adding yet another section to a typical ToS document > is hardly going to change anything. > > I don't think it's worth optimizing for the "I trust someone to host my > entire DNS zone and hold my DNSSEC keys (if you're into that kind of > thing) but TLS certificates? Boo!"-use-case. Sadly, the shady behaviour is not with Comodo but with Cloudflare. As cloudflare does not state anywhere that they issue certificates when SSL and CDN features are explicitly switched off from the beginning. 1. trust issue: Cloudflare issues certificates without asking permission or staing it in TOS or elsewhere. Doing so when in DNS-only mode appears to me illegal. 2. trust issue: Cloudflare modifies the DNS entries to validate without consent of the domain owner or account holder. Again, no mention of it in TOS or anywheer else. So the modification is not permitted in DNS-only mode. As issue 2 is allowing them to validate correctly against the CA validation request (as explained by Comodo) this does not mean the certificates are issues under shady circumstances at this point. But from the moment on when the CA (Comodo) is informed about this shady behavior by multiple domain owners / account owners, Comodo should start acting. Just referring to a valid dns verification is not magically fixing it. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Cerificate Concern about Cloudflare's DNS
On Thursday, November 3, 2016 at 1:23:48 PM UTC+1, Rob Stradling wrote: > On 03/11/16 12:13, Han Yuwei wrote: > > 在 2016年11月3日星期四 UTC+8下午7:09:48,Rob Stradling写道: > >> On 03/11/16 09:59, Gervase Markham wrote: > >>> On 02/11/16 23:26, gerhard.tin...@gmail.com wrote: > Befor I contacted this group, I contacted Cloudflare and asked them > to stop creating certificates with my domain. The answer in short > was, ... they cannot change it and as long as I am using there > service, they will continue. > >>> > >>> How would you expect the service to work without them doing that? > >>> > I also contacted Comodo as the CA and asked them. The answer was > different but also not helping. In short, ... I can use a CAA DNS > record (not supported by many DNS providers like Cloudflare) to avoid > it in the future. But in the next sentence telling me that those > records are not honoured by many CA's. > >>> > >>> Hopefully this will change before too long. > >>> > >>> However, I still don't get why you want to use Cloudflare's SSL > >>> termination services but are unwilling to allow them to get a > >>> certificate for your domain name. > >>> > >>> AIUI their free tier uses certs they obtain, but if you pay, you can > >>> provide your own cert. So if you want to use Cloudflare but don't want > >>> them obtaining certs for you, join the paying tier. > >> > >> In my experience, joining Cloudflare's paying tier doesn't guarantee > >> that Cloudflare won't also obtain a free cert. > >> > >> A few weeks ago we moved crt.sh onto Cloudflare. It was in the paying > >> tier from the start, and we uploaded an EV cert straight away. I was > >> surprised when https://crt.sh/atom?q=crt.sh alerted me to > >> https://crt.sh/?id=42619974 > >> > >> -- > >> Rob Stradling > >> Senior Research & Development Scientist > >> COMODO - Creating Trust Online > > > > So it is impossible to request a revocation even I do refuse to let > > Cloudflare issue the certificate of my domain and keep using Cloudflare's > > DNS service under these rules(CA/B BR and COMODO CPS)? > > Comodo does check CAA records, so you could add a CAA record for your > domain that doesn't permit Comodo to issue. This won't stop Cloudflare > from requesting a free cert, but it should block the issuance of any > requested cert. (Note however that our CAA checks fail open if there's > an error with the CAA DNS lookup). > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online This seems to be the standard answer from Comodo. Conveniently Cloudflare does not support CAA records. So this suggestion is not helping with Cloudflare. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Cerificate Concern about Cloudflare's DNS
On Thursday, November 3, 2016 at 10:59:53 AM UTC+1, Gervase Markham wrote: > On 02/11/16 23:26, wrote: > > Befor I contacted this group, I contacted Cloudflare and asked them > > to stop creating certificates with my domain. The answer in short > > was, ... they cannot change it and as long as I am using there > > service, they will continue. > > How would you expect the service to work without them doing that? > > > I also contacted Comodo as the CA and asked them. The answer was > > different but also not helping. In short, ... I can use a CAA DNS > > record (not supported by many DNS providers like Cloudflare) to avoid > > it in the future. But in the next sentence telling me that those > > records are not honoured by many CA's. > > Hopefully this will change before too long. > > However, I still don't get why you want to use Cloudflare's SSL > termination services but are unwilling to allow them to get a > certificate for your domain name. > > AIUI their free tier uses certs they obtain, but if you pay, you can > provide your own cert. So if you want to use Cloudflare but don't want > them obtaining certs for you, join the paying tier. > > Gerv Hi, I guess you never used Cloudflare, right? So let me explain it to you so you understand my concern. I have posted my whole explanation to this group but it is somewhere lost I think. 1.) Yes, Cloudflare offers a kind of MITM as a service. You dont have a certificate, you want there protection, ... etc. So they create it for you, intercept and cache the traffic. 2.) Cloudflare does offer much more. beside other things you can disable all those features and use cloudflare as "DNS-only mode" as they call it. This means the SSL option is switched of by the user. (my expectation would be that there are no ssl certificates issued for my domain in that mode. Now, knowing that, I get back to your questions: > How would you expect the service to work without them doing that? As far as I understand aDNS-only service, a SSL certificate is not required. My expectation would be that Cloudflare honers the settings I set on the account/domain. > However, I still don't get why you want to use Cloudflare's SSL > termination services but are unwilling to allow them to get a > certificate for your domain name. Again, I sue Cloudflare in the DNS-only mode. All the features (except DNS) is disabled. SSL: OFF, Intercepting traffic: OFF, ... > > AIUI their free tier uses certs they obtain, but if you pay, you can > provide your own cert. So if you want to use Cloudflare but don't want > them obtaining certs for you, join the paying tier. As far as I understood you can even upload the cert in the free plan, but beside the point. DNS-Only mpde would not require it. I would have at least expected that they stop issuing certificates after I requested it. But they dont! ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Cerificate Concern about Cloudflare's DNS
On 03/11/16 20:04, Nick Lamb wrote: > I actually find Rob's "so it would seem" rather reassuring. A CA which has > its own properties (not just one or two key brand name servers) on a high > value check list is not focusing properly on the things the Relying Parties > care about like banks and famous Internet brands likely to be targeted by bad > guys. :-) > It's slightly funnier that Commodo seemingly doesn't make use of its own CT > alerting service to be warned of such issuances after the fact though. I was alerted to the unexpected Cloudflare crt.sh cert because my installation of Thunderbird is subscribed to https://crt.sh/atom?q=crt.sh. But you're right. I should try to persuade our Infra team to eat the dogfood too. :-) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Cerificate Concern about Cloudflare's DNS
I actually find Rob's "so it would seem" rather reassuring. A CA which has its own properties (not just one or two key brand name servers) on a high value check list is not focusing properly on the things the Relying Parties care about like banks and famous Internet brands likely to be targeted by bad guys. It's slightly funnier that Commodo seemingly doesn't make use of its own CT alerting service to be warned of such issuances after the fact though. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Update on transition of the Verizon roots and issuance of SHA1 certificates
Resent without a signature Hi everyone, This email is intended to gather public and browser feedback on how we are handling the transitioning Verizon's customers to DigiCert and share with everyone the plan for when all non-DigiCert hosted sub CAs will be fully compliant with the BRs and network security guidelines. Primarily, this letter addresses when all issuing CAs previously held by Verizon will be covered by an unqualified audit and how we are responding to the sub CAs that issued SHA1 certificates. We are looking forward to the browser and public feedback on how to handle the non-compliant cross-signs and insight on how the public views our transition progress and planned completion dates. Background Prior to presenting the plan for remediation, I thought I'd share a bit about our progress with migrating Verizon customers. About a year ago in July, DigiCert closed an agreement with Verizon where DigiCert took ownership of three publicly-trusted Verizon root certificates. These certificates are the Verizon Global Root CA, the Baltimore CyberTrust Root CA, and the Verizon Root CA. There were many reasons the acquisition made sense, including acquisition of a root that had cross-signed DigiCert for many years. The ubiquity of the Verizon roots is wide-spread, which meant a lot of CAs like to cross-sign with them. Another significant reason for the acquisition was an attempt to improve the CA industry. After watching the issuance of wildcard EV certs, non-compliant subordinate CAs, and certs with poor profiles, we made a conscious decision to purchase these roots with the intention of migrating them to more complaint system. We felt that helping these CAs get to the point of regular audits and best practices would raise the quality of the entire industry. Prior to the acquisition, we were made aware of several potential non-compliances by Verizon's customers. We worked closely with Verizon to clean up many of the Sub CAs, including revoking CAs that would never be compliant with the requirements and attempting to technically constrain others. Sub CAs were revoked because they either didn't have an audit, were unresponsive to communication, or couldn't control their issuance. Verizon was a great partner and took a very proactive approach in removing CAs that were not actively working towards compliance. Unfortunately, the age of the roots and large number of cross-signs led to a lot of missing paperwork and certain issues in identifying which CAs were covered by audits. Prior to closing we believed there were approximately five technically constrained sub CAs and around 20 unconstrained sub CAs. Turns out there were actually more than 200, each with various levels of compliance. Most of these Sub CAs operated under the Baltimo re Cybertrust root, which was created in 2000. To their credit, Verizon revoked 48 of the issuing CAs prior to DigiCert's acquisition of the roots. Unfortunately, this left around 150 for our small team to work through. Although the endeavor was daunting, Ben Wilson and others worked to gather audit reports, email customers about compliance dates, monitor certificates issued, and revoke non-compliant customers. Verizon was very good at assisting us in these efforts. This information is now recorded in the Mozilla database and continuously updated as the information changes. Transition Process After our operational acquisition of the roots (which occurred the last part of September, 2015), we identified 15 expired issuing CAs, 70 revoked sub CAs, 131 audited sub CAs, and 36 where the status was unknown. Since then, we've revoked 25 issuing CAs and assisted others with technical constraints, exodus from the Omniroot cross-signing program, or obtaining audits. Of the existing sub CAs, about half remain operational and are either audited or technically constrained. The other half are either winding down or have been revoked. All revoked certificates were disclosed to Mozilla via Salesforce and should be part of OneCRL. Issuing CAs There are only a handful of non-audited sub CAs remaining (see https://crt.sh/mozilla-disclosures#disclosureincomplete). We have a plan for each of them that we'd like to share with you. We welcome both browser and public feedback. This is, of course, simply a proposal on how to finish the transition and provide transparency into where we are at. We are certainly willing to modify the plan as needed to further online security and meet the requirements of the root store operators. The seven companies listed below are responsible for the remaining unaudited sub CAs: 1. ABB has three unaudited issuing CAs. ABB didn't undergo an audit earlier this year on the assumption that their sub CAs were technically constrained. Unfortunately, the constraints weren't properly implemented, a fact that escaped notice until Rob Stradling's excellent tool exposed a deficiency
Update on transition of the Verizon roots and issuance of SHA1 certificates
Hi everyone, This email is intended to gather public and browser feedback on how we are handling the transitioning Verizon's customers to DigiCert and share with everyone the plan for when all non-DigiCert hosted sub CAs will be fully compliant with the BRs and network security guidelines. Primarily, this letter addresses when all issuing CAs previously held by Verizon will be covered by an unqualified audit and how we are responding to the sub CAs that issued SHA1 certificates. We are looking forward to the browser and public feedback on how to handle the non-compliant cross-signs and insight on how the public views our transition progress and planned completion dates. Background Prior to presenting the plan for remediation, I thought I'd share a bit about our progress with migrating Verizon customers. About a year ago in July, DigiCert closed an agreement with Verizon where DigiCert took ownership of three publicly-trusted Verizon root certificates. These certificates are the Verizon Global Root CA, the Baltimore CyberTrust Root CA, and the Verizon Root CA. There were many reasons the acquisition made sense, including acquisition of a root that had cross-signed DigiCert for many years. The ubiquity of the Verizon roots is wide-spread, which meant a lot of CAs like to cross-sign with them. Another significant reason for the acquisition was an attempt to improve the CA industry. After watching the issuance of wildcard EV certs, non-compliant subordinate CAs, and certs with poor profiles, we made a conscious decision to purchase these roots with the intention of migrating them to more complaint system. We felt that helping these CAs get to the point of regular audits and best practices would raise the quality of the entire industry. Prior to the acquisition, we were made aware of several potential non-compliances by Verizon's customers. We worked closely with Verizon to clean up many of the Sub CAs, including revoking CAs that would never be compliant with the requirements and attempting to technically constrain others. Sub CAs were revoked because they either didn't have an audit, were unresponsive to communication, or couldn't control their issuance. Verizon was a great partner and took a very proactive approach in removing CAs that were not actively working towards compliance. Unfortunately, the age of the roots and large number of cross-signs led to a lot of missing paperwork and certain issues in identifying which CAs were covered by audits. Prior to closing we believed there were approximately five technically constrained sub CAs and around 20 unconstrained sub CAs. Turns out there were actually more than 200, each with various levels of compliance. Most of these Sub CAs operated under the Baltimore Cybertrust root, which was created in 2000. To their credit, Verizon revoked 48 of the issuing CAs prior to DigiCert's acquisition of the roots. Unfortunately, this left around 150 for our small team to work through. Although the endeavor was daunting, Ben Wilson and others worked to gather audit reports, email customers about compliance dates, monitor certificates issued, and revoke non-compliant customers. Verizon was very good at assisting us in these efforts. This information is now recorded in the Mozilla database and continuously updated as the information changes. Transition Process After our operational acquisition of the roots (which occurred the last part of September, 2015), we identified 15 expired issuing CAs, 70 revoked sub CAs, 131 audited sub CAs, and 36 where the status was unknown. Since then, we've revoked 25 issuing CAs and assisted others with technical constraints, exodus from the Omniroot cross-signing program, or obtaining audits. Of the existing sub CAs, about half remain operational and are either audited or technically constrained. The other half are either winding down or have been revoked. All revoked certificates were disclosed to Mozilla via Salesforce and should be part of OneCRL. Issuing CAs There are only a handful of non-audited sub CAs remaining (see https://crt.sh/mozilla-disclosures#disclosureincomplete). We have a plan for each of them that we'd like to share with you. We welcome both browser and public feedback. This is, of course, simply a proposal on how to finish the transition and provide transparency into where we are at. We are certainly willing to modify the plan as needed to further online security and meet the requirements of the root store operators. The seven companies listed below are responsible for the remaining unaudited sub CAs: 1. ABB has three unaudited issuing CAs. ABB didn't undergo an audit earlier this year on the assumption that their sub CAs were technically constrained. Unfortunately, the constraints weren't properly implemented, a fact that escaped notice until Rob Stradling's excellent tool exposed a deficiency a few months ago in how Verizon issuance process. Although Verizon r
Re: New SHA-1 certificates issued in 2016
On Thu, 3 Nov 2016 17:53:01 + Gervase Markham wrote: > On 28/10/16 16:11, Patrick Figel wrote: > > I found a number of SHA-1 certificates chaining up to CAs trusted by > > Mozilla that have not been brought up on this list or on Bugzilla > > yet. > > Using the handy crt.sh link posted by Rob, I have gone through the > 2016 SHA-1 issuances known to crt.sh to filter out those which chain > up to a root trusted by Mozilla. (Handily, crt.sh contains this > information as well.) There are a distressingly large number of > them :-( > > Based on Patrick's report, I filed: > https://bugzilla.mozilla.org/show_bug.cgi?id=1313874 (Gov of Spain) > https://bugzilla.mozilla.org/show_bug.cgi?id=1313872 (DigiCert) > https://bugzilla.mozilla.org/show_bug.cgi?id=1313873 (DocuSign) > > and based on this additional research, I have filed: > https://bugzilla.mozilla.org/show_bug.cgi?id=1315019 (TeliaSonera) > https://bugzilla.mozilla.org/show_bug.cgi?id=1315016 (Visa) > https://bugzilla.mozilla.org/show_bug.cgi?id=1315018 (GlobalSign) > https://bugzilla.mozilla.org/show_bug.cgi?id=1315035 (T-Systems) > > There may be more in the future. I would be interested in the group's > opinion on what to do about: > > A) SHA-1 precerts with no actual cert logged (1 CA) This is just as bad as signing an actual cert with SHA-1. RFC6962 says: "The signature on the TBSCertificate indicates the certificate authority's intent to issue a certificate. This intent is considered binding (i.e., misissuance of the Precertificate is considered equal to misissuance of the final certificate)." This is not just a theoretical concern. When this came up earlier this year with Symantec, I explained that pre-certificates are a vector for exploiting a SHA-1 collision, since the forged/collided certificate need not contain the pre-certificate poison extension. > B) SHA-1 email certificates with no DNS names, although their lack of >an EKU means they are valid for server auth (2 CAs) The more pertinent question is the issuing CA's EKU. > C) SHA-1 email certificates with EKU but no serverAuth (1 CA) Ditto. > D) Small numbers (1 or 2) of SHA-1 certs issued in early January. One >could perhaps charitably say that the CA or their subCA made a >mistake, realised, has fixed it, and hasn't made it since. Now it's >November, is this worth chasing? (4 CAs) > > Also, does it make it better if the CA has already revoked the > certificate before we report it to them? No. Revocation doesn't help because the forged/collided cert need not share the same serial number. Revocation would only help if it were based on the SHA-1 hash of the TBSCertificate. The common thread in all of these answers is that the forged/collided certificate need not look anything like the data that the CA signed with SHA-1. Any time a CA trusted for serverAuth signs attacker-controlled data using SHA-1 there is a risk of a forged serverAuth certificate. Regards, Andrew ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: References to key generation guideline across Mozilla
On 03/11/16 10:30, Tim Guan-tin Chien wrote: > PS Apologies if this is not in-scope for dev-security-policy. I think you might be better off asking Mozilla IT :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New SHA-1 certificates issued in 2016
On 28/10/16 16:11, Patrick Figel wrote: > I found a number of SHA-1 certificates chaining up to CAs trusted by > Mozilla that have not been brought up on this list or on Bugzilla yet. Using the handy crt.sh link posted by Rob, I have gone through the 2016 SHA-1 issuances known to crt.sh to filter out those which chain up to a root trusted by Mozilla. (Handily, crt.sh contains this information as well.) There are a distressingly large number of them :-( Based on Patrick's report, I filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1313874 (Gov of Spain) https://bugzilla.mozilla.org/show_bug.cgi?id=1313872 (DigiCert) https://bugzilla.mozilla.org/show_bug.cgi?id=1313873 (DocuSign) and based on this additional research, I have filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1315019 (TeliaSonera) https://bugzilla.mozilla.org/show_bug.cgi?id=1315016 (Visa) https://bugzilla.mozilla.org/show_bug.cgi?id=1315018 (GlobalSign) https://bugzilla.mozilla.org/show_bug.cgi?id=1315035 (T-Systems) There may be more in the future. I would be interested in the group's opinion on what to do about: A) SHA-1 precerts with no actual cert logged (1 CA) B) SHA-1 email certificates with no DNS names, although their lack of an EKU means they are valid for server auth (2 CAs) C) SHA-1 email certificates with EKU but no serverAuth (1 CA) D) Small numbers (1 or 2) of SHA-1 certs issued in early January. One could perhaps charitably say that the CA or their subCA made a mistake, realised, has fixed it, and hasn't made it since. Now it's November, is this worth chasing? (4 CAs) Also, does it make it better if the CA has already revoked the certificate before we report it to them? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Cerificate Concern about Cloudflare's DNS
On 03/11/16 14:18, Jakob Bohm wrote: > On 03/11/2016 12:09, Rob Stradling wrote: > >> In my experience, joining Cloudflare's paying tier doesn't guarantee >> that Cloudflare won't also obtain a free cert. >> >> A few weeks ago we moved crt.sh onto Cloudflare. It was in the paying >> tier from the start, and we uploaded an EV cert straight away. I was >> surprised when https://crt.sh/atom?q=crt.sh alerted me to >> https://crt.sh/?id=42619974 > > So I guess you haven't added your own domains (such as crt.sh) to the > list of "high-value manual review" domains for your own certificate > issuance processes? So it would seem. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Cerificate Concern about Cloudflare's DNS
On 03/11/2016 12:09, Rob Stradling wrote: In my experience, joining Cloudflare's paying tier doesn't guarantee that Cloudflare won't also obtain a free cert. A few weeks ago we moved crt.sh onto Cloudflare. It was in the paying tier from the start, and we uploaded an EV cert straight away. I was surprised when https://crt.sh/atom?q=crt.sh alerted me to https://crt.sh/?id=42619974 So I guess you haven't added your own domains (such as crt.sh) to the list of "high-value manual review" domains for your own certificate issuance processes? 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: New SHA-1 certificates issued in 2016
On 28/10/16 16:11, Patrick Figel wrote: > I found a number of SHA-1 certificates chaining up to CAs trusted by > Mozilla that have not been brought up on this list or on Bugzilla yet. > Apologies in case I missed prior discussion for any of these, and kudos > to censys for making this search incredibly easy. See also: https://crt.sh/?cablint=211&minNotBefore=2016-01-01 (Note: This shows all SHA-1 certs with notBefore dates in 2016 that are known to crt.sh. Some of these certs might not be trusted by Mozilla) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Cerificate Concern about Cloudflare's DNS
On 03/11/16 12:13, Han Yuwei wrote: > 在 2016年11月3日星期四 UTC+8下午7:09:48,Rob Stradling写道: >> On 03/11/16 09:59, Gervase Markham wrote: >>> On 02/11/16 23:26, gerhard.tin...@gmail.com wrote: Befor I contacted this group, I contacted Cloudflare and asked them to stop creating certificates with my domain. The answer in short was, ... they cannot change it and as long as I am using there service, they will continue. >>> >>> How would you expect the service to work without them doing that? >>> I also contacted Comodo as the CA and asked them. The answer was different but also not helping. In short, ... I can use a CAA DNS record (not supported by many DNS providers like Cloudflare) to avoid it in the future. But in the next sentence telling me that those records are not honoured by many CA's. >>> >>> Hopefully this will change before too long. >>> >>> However, I still don't get why you want to use Cloudflare's SSL >>> termination services but are unwilling to allow them to get a >>> certificate for your domain name. >>> >>> AIUI their free tier uses certs they obtain, but if you pay, you can >>> provide your own cert. So if you want to use Cloudflare but don't want >>> them obtaining certs for you, join the paying tier. >> >> In my experience, joining Cloudflare's paying tier doesn't guarantee >> that Cloudflare won't also obtain a free cert. >> >> A few weeks ago we moved crt.sh onto Cloudflare. It was in the paying >> tier from the start, and we uploaded an EV cert straight away. I was >> surprised when https://crt.sh/atom?q=crt.sh alerted me to >> https://crt.sh/?id=42619974 >> >> -- >> Rob Stradling >> Senior Research & Development Scientist >> COMODO - Creating Trust Online > > So it is impossible to request a revocation even I do refuse to let > Cloudflare issue the certificate of my domain and keep using Cloudflare's DNS > service under these rules(CA/B BR and COMODO CPS)? Comodo does check CAA records, so you could add a CAA record for your domain that doesn't permit Comodo to issue. This won't stop Cloudflare from requesting a free cert, but it should block the issuance of any requested cert. (Note however that our CAA checks fail open if there's an error with the CAA DNS lookup). -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Cerificate Concern about Cloudflare's DNS
在 2016年11月3日星期四 UTC+8下午7:09:48,Rob Stradling写道: > On 03/11/16 09:59, Gervase Markham wrote: > > On 02/11/16 23:26, gerhard.tin...@gmail.com wrote: > >> Befor I contacted this group, I contacted Cloudflare and asked them > >> to stop creating certificates with my domain. The answer in short > >> was, ... they cannot change it and as long as I am using there > >> service, they will continue. > > > > How would you expect the service to work without them doing that? > > > >> I also contacted Comodo as the CA and asked them. The answer was > >> different but also not helping. In short, ... I can use a CAA DNS > >> record (not supported by many DNS providers like Cloudflare) to avoid > >> it in the future. But in the next sentence telling me that those > >> records are not honoured by many CA's. > > > > Hopefully this will change before too long. > > > > However, I still don't get why you want to use Cloudflare's SSL > > termination services but are unwilling to allow them to get a > > certificate for your domain name. > > > > AIUI their free tier uses certs they obtain, but if you pay, you can > > provide your own cert. So if you want to use Cloudflare but don't want > > them obtaining certs for you, join the paying tier. > > In my experience, joining Cloudflare's paying tier doesn't guarantee > that Cloudflare won't also obtain a free cert. > > A few weeks ago we moved crt.sh onto Cloudflare. It was in the paying > tier from the start, and we uploaded an EV cert straight away. I was > surprised when https://crt.sh/atom?q=crt.sh alerted me to > https://crt.sh/?id=42619974 > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online So it is impossible to request a revocation even I do refuse to let Cloudflare issue the certificate of my domain and keep using Cloudflare's DNS service under these rules(CA/B BR and COMODO CPS)? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Cerificate Concern about Cloudflare's DNS
On 03/11/16 09:59, Gervase Markham wrote: > On 02/11/16 23:26, gerhard.tin...@gmail.com wrote: >> Befor I contacted this group, I contacted Cloudflare and asked them >> to stop creating certificates with my domain. The answer in short >> was, ... they cannot change it and as long as I am using there >> service, they will continue. > > How would you expect the service to work without them doing that? > >> I also contacted Comodo as the CA and asked them. The answer was >> different but also not helping. In short, ... I can use a CAA DNS >> record (not supported by many DNS providers like Cloudflare) to avoid >> it in the future. But in the next sentence telling me that those >> records are not honoured by many CA's. > > Hopefully this will change before too long. > > However, I still don't get why you want to use Cloudflare's SSL > termination services but are unwilling to allow them to get a > certificate for your domain name. > > AIUI their free tier uses certs they obtain, but if you pay, you can > provide your own cert. So if you want to use Cloudflare but don't want > them obtaining certs for you, join the paying tier. In my experience, joining Cloudflare's paying tier doesn't guarantee that Cloudflare won't also obtain a free cert. A few weeks ago we moved crt.sh onto Cloudflare. It was in the paying tier from the start, and we uploaded an EV cert straight away. I was surprised when https://crt.sh/atom?q=crt.sh alerted me to https://crt.sh/?id=42619974 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Cerificate Concern about Cloudflare's DNS
On 03/11/16 10:59, Gervase Markham wrote: > However, I still don't get why you want to use Cloudflare's SSL > termination services but are unwilling to allow them to get a > certificate for your domain name. > > AIUI their free tier uses certs they obtain, but if you pay, you can > provide your own cert. So if you want to use Cloudflare but don't want > them obtaining certs for you, join the paying tier. It is possible to use Cloudflare as a DNS-only provider, without any CDN/reverse proxying functionality. That's what seems to be the issue here - certificates are requested as soon as a domain is added to Cloudflare, even if the CDN functionality is never enabled. I don't think these certificates are mis-issued or that this practice is shady, but I can see how it might surprise a domain owner who is only looking for a DNS provider. This is probably not something that can or should be resolved by the CA/B Forum or Mozilla. Realistically speaking, asking CAs to confirm that the actual domain registrant has authorized the issuance (rather than whoever is operating the DNS for that domain) is not possible in practice for DV. Going overboard with such a requirement carries the risk The only other thing the BRs could ask for is that a subscriber (which would be Cloudflare in this case) has to include language regarding certificate issuance in their ToS if they act on behalf of other domain registrants. However, given that the goal is to avoid surprising the domain registrant, adding yet another section to a typical ToS document is hardly going to change anything. I don't think it's worth optimizing for the "I trust someone to host my entire DNS zone and hold my DNSSEC keys (if you're into that kind of thing) but TLS certificates? Boo!"-use-case. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
References to key generation guideline across Mozilla
Hi there, I've already regarding the document here [1] as the updated document to "how to generate a SSH key", however as my new hires points out there are other documents out there [2] [3]. Should we be updating [2] [3] and ask everyone to look at [1] instead? [1] https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Key_generation [2] https://mana.mozilla.org/wiki/display/SD/Generating+a+SSH+Public+Key [3] https://www.mozilla.org/en-US/about/governance/policies/commit/ which point to a GitHub tutorial. Tim PS Apologies if this is not in-scope for dev-security-policy. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Cerificate Concern about Cloudflare's DNS
在 2016年11月3日星期四 UTC+8下午5:59:53,Gervase Markham写道: > On 02/11/16 23:26, gerhard.tin...@gmail.com wrote: > > Befor I contacted this group, I contacted Cloudflare and asked them > > to stop creating certificates with my domain. The answer in short > > was, ... they cannot change it and as long as I am using there > > service, they will continue. > > How would you expect the service to work without them doing that? > > > I also contacted Comodo as the CA and asked them. The answer was > > different but also not helping. In short, ... I can use a CAA DNS > > record (not supported by many DNS providers like Cloudflare) to avoid > > it in the future. But in the next sentence telling me that those > > records are not honoured by many CA's. > > Hopefully this will change before too long. > > However, I still don't get why you want to use Cloudflare's SSL > termination services but are unwilling to allow them to get a > certificate for your domain name. > > AIUI their free tier uses certs they obtain, but if you pay, you can > provide your own cert. So if you want to use Cloudflare but don't want > them obtaining certs for you, join the paying tier. > > Gerv Somebody like me just want their DNS service because they support DNSSEC well and much more stable than others. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New SHA-1 certificates issued in 2016
On 03/11/16 04:25, c...@cem.me wrote: > Gerv, Given the discussions in the past about risks of SHA-1 issuance > for *any* cert type, and the responses from action #1c from the March > 2016 CA communication, are there any public plans for dealing type of > certificate yet? As in, do we have plans for banning SHA-1 issuance outright? Not at the moment, because there are lots of complex edge cases. A good step which provides much of the same protections is to simply stop accepting them, which we plan to do in January next year (for publicly-trusted roots). > Do these non-server-certs only fall under the BR's > sigAlg policy if a generated certificate collision has an EKU of > server auth? (And by that time, is it too late?) Like I said, the scope of the BRs is debateable. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incident Report - certificate with 'sb' as a SAN:dnsName
On 18/10/16 19:15, Rob Stradling wrote: > Hi Hanno. The questions that you and others have posted are entirely > reasonable. Sorry for the delay. Robin intends to post a reply this week. It seems like this reply has not yet appeared? I would like to make sure my initial question about "Where does Comodo's documentation of this methodological equivalence reside? etc." is answered. And also, how does: "Today we performed an exhaustive search of all the server authentication certificates we've issued since November 1 2015, and as a result we found just one further certificate [6] in which we'd included a public suffix (rivne.ua) due to this bug." fit with: https://crt.sh/?id=4467456 ? Why did you stop searching at Nov 1st 2015? It seems like the bug has been present for longer... Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Cerificate Concern about Cloudflare's DNS
On 02/11/16 23:26, gerhard.tin...@gmail.com wrote: > Befor I contacted this group, I contacted Cloudflare and asked them > to stop creating certificates with my domain. The answer in short > was, ... they cannot change it and as long as I am using there > service, they will continue. How would you expect the service to work without them doing that? > I also contacted Comodo as the CA and asked them. The answer was > different but also not helping. In short, ... I can use a CAA DNS > record (not supported by many DNS providers like Cloudflare) to avoid > it in the future. But in the next sentence telling me that those > records are not honoured by many CA's. Hopefully this will change before too long. However, I still don't get why you want to use Cloudflare's SSL termination services but are unwilling to allow them to get a certificate for your domain name. AIUI their free tier uses certs they obtain, but if you pay, you can provide your own cert. So if you want to use Cloudflare but don't want them obtaining certs for you, join the paying tier. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: Cerificate Concern about Cloudflare's DNS
On Wednesday, November 2, 2016 at 11:34:44 PM UTC+1, Peter Gutmann wrote: > Tom Ritter writes: > > >There's been (some) mention that even if a user moves off Cloudflare, the CA > >is not obligated to revoke. > > Would it matter? I guess it depends on circumstances (whether you control the > private key or Cloudflare does, whether you intend to use the same domain > elsewhere or not, etc), but in most cases it seems like no revocation is > necessary, you destroy or stop using the private key and that's it. That is exactly the point of it, the "domain owner" / "Cloudflare customer" does not have or ever get the key of the certificate that was created without the knowledge of the domain owner. And Cloudflare will continue using the wildcard certificate with a number of domains in them. Oh, and they are valid for 2 years! > Even in > the worst-case scenario, Cloudflare has your private key and you intend to > keep using the domain, presumably there's some contractual obligation for them > to stop using it when you close your account with them. It seems like a > revocation isn't necessary (not just for this but for pretty much every > revocation reason except keyCompromise). > > Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New SHA-1 certificates issued in 2016
On Saturday, October 29, 2016 at 12:02:54 PM UTC-5, Gervase Markham wrote: > The scope of the BRs is debateable. These certs are clearly in scope for > Mozilla policy, as they chain up to trusted roots; however Mozilla > policy does not (yet) ban SHA-1 issuance other than via the BRs. This > may be fixed in policy version 2.3. > > Without tls-server-auth and with other EKUs, these certs would not be > trusted in Firefox. The systemic risks from SHA-1 issuance remain, however. > > Gerv Gerv, Given the discussions in the past about risks of SHA-1 issuance for *any* cert type, and the responses from action #1c from the March 2016 CA communication, are there any public plans for dealing type of certificate yet? Do these non-server-certs only fall under the BR's sigAlg policy if a generated certificate collision has an EKU of server auth? (And by that time, is it too late?) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Cerificate Concern about Cloudflare's DNS
On Wednesday, November 2, 2016 at 11:39:09 PM UTC+1, Peter Kurrasch wrote: > This raises an interesting point and I'd be interested in any comments that > Comodo or other CA's might have. > > > It appears we have a situation where a cert is being issued to what is > presumably an authorized party yet that party is not actually authorized by > the subscriber. How does Comodo or any other CA validate that a "domain > manipulator" has been and continues to be authorized by the actual domain > registrant? Is any attestation provided by a party (such as CloudFlare) that > they have authorization by their own clients to do whatever they are doing? > > > It's in the interest of CA's to have some well thought-out plans here > because I think we know who is getting the blame when the system breaks down. > I don't think it would sit well if a CA were to come here and say "you can't > blame us for the misissuance because we will give CloudFlare any cert they > want." > > > > > > > > > > From: gerhard...@gmail.com > Sent: Wednesday, November 2, 2016 4:16 AM > To: mozilla-dev-s...@lists.mozilla.org > Subject: Re: Cerificate Concern about Cloudflare's DNS > > > Hi, > > > > > Since you delegated your DNS server to Cloudflare, you implicitly allowed > > them to perform this certificate request on your behalf. > > > > > This is where I strongly disagree! I have checked the TOS and Security > policy, ... etc. There is nowhere stated that Cloudflare is allowed without > the Users knowledge to manipulate there DNS settings. That sad, there is the > proxy service they offer which is changing the DNS settings. But as you > actively enable it, you are aware. > > By delegating the DNS server to Cloudflare, you entrust Cloudflare to > distribute the User defined DNS settings. To be able to validate for the > certificate, the DNS settings are changed without the users knowledge. No TOS > or any other policy states this. > > Even if that might not be issue for the CA itself (which i do not agree on), > This is definitely braking the trust to its users. > > And the CA (Comodo) informed about it, and not at least requesting a > statement from Cloudflare, means they support this, from my point of view, > wrong behavior. > > > As it seems the only thing that can be done is move to a different DNS > provider!! Still, this is a vialation of trust!!! > > ___ > dev-security-policy mailing list > dev-secur...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy Thank you. I could not agree more. Befor I contacted this group, I contacted Cloudflare and asked them to stop creating certificates with my domain. The answer in short was, ... they cannot change it and as long as I am using there service, they will continue. I also contacted Comodo as the CA and asked them. The answer was different but also not helping. In short, ... I can use a CAA DNS record (not supported by many DNS providers like Cloudflare) to avoid it in the future. But in the next sentence telling me that those records are not honoured by many CA's. I started reading the TOC and policies of Cloudflare again looking for any clue about this. Nothing. No mention about the certificates that get issued, nothing about the DNS changes, ... Still everybody tells me something like, "Well if Cloudflare is doing it, it must be right. Why do you complain?" It is nice to read a answer like this even if it doe not solve it. :) Thanks! ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Cerificate Concern about Cloudflare's DNS
On Wednesday, November 2, 2016 at 11:42:00 PM UTC+1, Kristian Fiskerstrand wrote: > On 11/02/2016 11:38 PM, Peter Kurrasch wrote: > > This raises an interesting point and I'd be interested in any comments > > that Comodo or other CA's might have. > > > > It really seems like a matter of discussion for the terms of agreement > and interaction between the user and service provider, and not a CA matter. > This is true in general. But when the used practice of validating a domain is possible against the will and knowledge of the domain owner, ... I guess that puts the CA in trouble at some point as well. Even if it is only in form of a loss of trust. > > -- > > Kristian Fiskerstrand > Blog: https://blog.sumptuouscapital.com > Twitter: @krifisk > > Public OpenPGP keyblock at hkp://pool.sks-keyservers.net > fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 > > Aurum est Potestas > Gold is power ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy