Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....
On Thu, Apr 12, 2018 at 02:15:02PM -0500, Matthew Hardeman via dev-security-policy wrote: > On Thu, Apr 12, 2018 at 1:57 PM, Eric Mill wrote: > > But he did not deceive users. Demonstrating that this is possible is not > > itself an act of deception. > > Except that if he can't maintain a working EV certificate in a name that > may deceive users, then that would make the text misleading/deceiving. In > a lovely chicken/egg debate fashion, the CA managed to make his website > deceptive. On a practical level, though, is there any reason to believe that the certificate was revoked for any reason *other* than because the existence of the certificate was widely publicised, beyond the publicity that any other EV cert would get (I'm thinking about CT, mostly)? If the only reason the cert got pulled is because Ian acted in a manner different to that of a scammer (I doubt J. Random Miscreant is going to be blogging about their ability to get an embarrassing-looking EV cert), then you're not really making a positive point about the value of EV. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....
On Friday, April 13, 2018 at 2:15:47 PM UTC-7, Matthew Hardeman wrote: As a parent it is not uncommon for me to have to explain to my children that something they ask for is not reasonable. In some cases I joke and say things like “well I want a pony” or “and I wish water wasn't wet”. When I look at arguments that support the idea of name squatting on a the internet and trying to solve that problem via the WebPKI I immediately think of these conversations with my kids. The topic of trademark rights has numerous professions dedicated to it combined with both international and domestic laws that define the rights, obligations and associated dispute resolution processes for claims associated with trademarks must use. I do not see how it would be effective or reasonable to place CAs as the arbitrator of this. Instead, should there be a trademark violation, it seems the existing legal system would be the appropriate way to address such concerns. If we accept that, which seems reasonable to me, then the question becomes in the event of a trademark dispute where should remediation happen. Since the CA is not the owner of the trademark or responsible for the registration of the name, it seems misplaced to think they should be the initiator of this process. Additionally it seems wrong that they would even be the first place you would go to if you wanted trademark enforcement, the registration of the name happens at the DNS layer and revoking the certificate does not change that the domain is still out there. To that end, ICANN actually has specific policies and procedures on how that process is supposed to work (see: https://www.icann.org/resources/pages/dispute-resolution-2012-02-25-en). The WebPKI ecosystem does not, it is, as has been discussed in this thread effectively acting arbitrarily when revoking for Trademark infringement. Based on the above, it seems clear to me the only potentially reasonable situation a CA should revoked on the basis of the outcome of Trademark claim through the aforementioned processes. To the topic of revoking a certificate because it is “deceiving”; this idea sounds a lot like book burning to me (https://www.ushmm.org/wlc/en/article.php?ModuleId=10005852). ``` Book burning refers to the ritual destruction by fire of books or other written materials. Usually carried out in a public context, the burning of books represents an element of censorship and usually proceeds from a cultural, religious, or political opposition to the materials in question. ``` This is a great example of that, what we have here is a legitimate business publishing information into the public domain that some people find offensive. Those people happen to control the doors to the library and have used that fact to censor that information so others can not access it. As a technologist who has spent a good chunk of his career working to secure the internet and make it more accessible this give me great pause and if you don’t come to the same conclusion I suggest you take a few minutes to look at how many CAs are operated by or in countries who have a bad history of freedom of speech. I strongly hope that Mozilla, and the other browsers, take a hard look at the topic of how CAs are expected to handle cases like this. The current situation may have been acceptable 10 years ago but as we approach 100% encryption on the web do we really want the WebPKI to be used as a censorship tool? Ryan Hurst (Speaking as an individual) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....
Judges must follow the law to the letter and must not let personal feelings influence their decision. The same rules apply to CAs. Every company who passes the EV guidelines has the right to have an EV cert and CAs must be impartial even if that cert might cause harm. If the CA doesn't like it then file a ballot on the CAB Forum. James Burton On Fri, Apr 13, 2018 at 10:23 PM, Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Fri, Apr 13, 2018 at 5:15 PM, Matthew Hardeman via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > I only named Let's Encrypt as an example of a CA that maintains a > scrubbing > > "blacklist". In their case, it appears to require exact match to a label > > including TLD and TLD+1. I was kind of surprised that they didn't just > > take all the high value domain names as to the TLD+1 field and decline > all > > combinations of (0...n_labels.)HIGH_VALUE_TLD+1.ANY_TLD_HERE, but I'm > sure > > there's a reasonable case either way. > > > > Reading the DNS policy discussions (over the past two decades) provides an > adequately ample understanding of the problems with, and complexities of, > such a naieve policy. The discussion around 'sunrise' and 'early > registration' periods for TLDs, or the UDRP, should be mandatory > comprehension for anyone arguing in favor of "popularity contests" or "big > domain holders > small domain holders" or "trademark holders > free speech" > or... well, the list goes on with the bad ideas proposed here that have > been roundly rejected by civil society and technologists regarding the > administration of the DNS :) > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....
On Fri, Apr 13, 2018 at 5:15 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I only named Let's Encrypt as an example of a CA that maintains a scrubbing > "blacklist". In their case, it appears to require exact match to a label > including TLD and TLD+1. I was kind of surprised that they didn't just > take all the high value domain names as to the TLD+1 field and decline all > combinations of (0...n_labels.)HIGH_VALUE_TLD+1.ANY_TLD_HERE, but I'm sure > there's a reasonable case either way. > Reading the DNS policy discussions (over the past two decades) provides an adequately ample understanding of the problems with, and complexities of, such a naieve policy. The discussion around 'sunrise' and 'early registration' periods for TLDs, or the UDRP, should be mandatory comprehension for anyone arguing in favor of "popularity contests" or "big domain holders > small domain holders" or "trademark holders > free speech" or... well, the list goes on with the bad ideas proposed here that have been roundly rejected by civil society and technologists regarding the administration of the DNS :) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....
My purpose in bringing up the High Risk Certificate Request and the BR that requires that a CA maintain a list of matching criteria to scrub certificate requests with was merely to illustrate yet another criteria upon which GoDaddy and other CAs may legitimately decline to issue a certificate such as the Stripe, Inc of Kentucky one. It's clear that acceptable practices include scrubbing by "names" of apparently any sort the CA can reasonably justify and use those to apply heightened scrutiny to issuance. I note that no where in that rule is it suggested that the "name" must be a domain label or part of a domain label. So it's not inconceivable that a CA can scrub issuances against names (including in the O= field) it find to be likely to be associated with phishing. I only named Let's Encrypt as an example of a CA that maintains a scrubbing "blacklist". In their case, it appears to require exact match to a label including TLD and TLD+1. I was kind of surprised that they didn't just take all the high value domain names as to the TLD+1 field and decline all combinations of (0...n_labels.)HIGH_VALUE_TLD+1.ANY_TLD_HERE, but I'm sure there's a reasonable case either way. On Fri, Apr 13, 2018 at 3:55 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thursday, April 12, 2018 at 5:39:39 PM UTC-7, Tim Hollebeek wrote: > > > Independent of EV, the BRs require that a CA maintain a High Risk > > Certificate > > > Request policy such that certificate requests are scrubbed against an > > internal > > > database or other resources of the CAs discretion. > > > > Unless you're Let's Encrypt, in which case you can opt out of this > > requirement via a blog post. > > > > -Tim > > As you know, that is not what that post says, nor does it reflect what > Let's Encrypt does. > > The BRs define the High Risk Certificate Request as: > > ``` > High Risk Certificate Request: A Request that the CA flags for additional > scrutiny by reference to internal criteria and databases maintained by the > CA, which may include names at higher risk for phishing or other fraudulent > usage, names contained in previously rejected certificate requests or > revoked Certificates, names listed on the Miller Smiles phishing list or > the Google Safe Browsing list, or names that the CA identifies using its > own risk-mitigation criteria. > ``` > > It also explicitly allows for phishing lists, such as the Google Safe > Browsing list to be used. > > The blog post in question (https://letsencrypt.org/2015/ > 10/29/phishing-and-malware.html) states that Let's Encrypt (rightfully in > my mind) believes that CAs are not the right place to try to protect users > from Phishing. They state this for a variety of reasons, including one > brought up in this thread about making CAs censors on the web. > > They go on to state that despite them thinking CAs are not the right place > to solve this problem that: > > ``` > At least for the time being, Let’s Encrypt is going to check with the > Google Safe Browsing API before issuing certificates, and refuse to issue > to sites that are flagged as phishing or malware sites. Google’s API is the > best source of phishing and malware status information that we have access > to, and attempting to do more than query this API before issuance would > almost certainly be wasteful and ineffective. > ``` > > They have also publicly stated that they maintain a blacklist of domains > they will not issue for. > > Ryan Hurst > (speaking for myself, not Google or Let's Encrypt) > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....
On Thursday, April 12, 2018 at 5:39:39 PM UTC-7, Tim Hollebeek wrote: > > Independent of EV, the BRs require that a CA maintain a High Risk > Certificate > > Request policy such that certificate requests are scrubbed against an > internal > > database or other resources of the CAs discretion. > > Unless you're Let's Encrypt, in which case you can opt out of this > requirement via a blog post. > > -Tim As you know, that is not what that post says, nor does it reflect what Let's Encrypt does. The BRs define the High Risk Certificate Request as: ``` High Risk Certificate Request: A Request that the CA flags for additional scrutiny by reference to internal criteria and databases maintained by the CA, which may include names at higher risk for phishing or other fraudulent usage, names contained in previously rejected certificate requests or revoked Certificates, names listed on the Miller Smiles phishing list or the Google Safe Browsing list, or names that the CA identifies using its own risk-mitigation criteria. ``` It also explicitly allows for phishing lists, such as the Google Safe Browsing list to be used. The blog post in question (https://letsencrypt.org/2015/10/29/phishing-and-malware.html) states that Let's Encrypt (rightfully in my mind) believes that CAs are not the right place to try to protect users from Phishing. They state this for a variety of reasons, including one brought up in this thread about making CAs censors on the web. They go on to state that despite them thinking CAs are not the right place to solve this problem that: ``` At least for the time being, Let’s Encrypt is going to check with the Google Safe Browsing API before issuing certificates, and refuse to issue to sites that are flagged as phishing or malware sites. Google’s API is the best source of phishing and malware status information that we have access to, and attempting to do more than query this API before issuance would almost certainly be wasteful and ineffective. ``` They have also publicly stated that they maintain a blacklist of domains they will not issue for. Ryan Hurst (speaking for myself, not Google or Let's Encrypt) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....
On Fri, Apr 13, 2018 at 1:13 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Possible outcomes of such an investigation: > > 1. That CA does not consider paypal to be a high risk name. This is > within their right, though unexpected. > It's not at all unexpected. I just explained to you precisely how and why it's expected. Everything else you said is irrelevant because of that :) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....
On 13/04/2018 18:05, Ryan Sleevi wrote: On Fri, Apr 13, 2018 at 11:53 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 13/04/2018 05:56, Ryan Sleevi wrote: On Thu, Apr 12, 2018 at 11:40 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Wow. I’m impressed. Let’s Encrypt by their own declaration and by observed interactions in their community help forums maintains a high value blacklist of domains. This is misrepresenting what is stated. It’s difficult to imagine how that list doesn’t include PayPal but did include mail.ru. Can you repeat that test with, say, microsoft.cologne? Just testing a theory... I think there's sufficient discussion in the past on such theories that it would seriously detrimental to try to rehash or relitigate - e.g. https://groups.google.com/d/msg/mozilla.dev.security.policy/ vMrncPi3tx8/ZOqtG2DBBgAJ That link does not discuss or answer what practices any real CA uses in complying with the high-risk list BR. The thread that followed contained lots of policy discussion, but almost nothing about what any real world CA does about the question posed above (are global high risk names flagged as high risk when used as 2nd level domains or public suffix+1 level domains). While I am thrilled that you viewed all of the links, you will find that the past discussion of what constitutes a "High Risk Domain" is not at all aligned with the notion you or Matthew is advocating. I can understand your desire to understand what "real CAs" do, but that's not at all aligned with what is required, which is the conversation that matters - as are the reasons for revocation. The simple answer is "It doesn't matter, because they're not required to, so stop trying to make it seem like they are" - and the threads all demonstrate the various flaws with the argument being made/advocated :) While I hope it is well-intentioned questioning, the answer is irrelevant to any of the discussions. What constitutes a high risk domain is mostly up to the CA in question, and no policy is being proposed to change that. However a new observation has been made that indicates that at least one well-behaved CA may have implemented their test against their own list of high risk subject identities in a way that is subject to a particular attack (registering the high risk name under an unexpected TLD or unexpected public suffix). It is thus relevant, as an incident response investigation (not a policy change investigation) to figure out if that is indeed a technical vulnerability in that CA's systems and if so to close the vulnerability and check for active exploits. Possible outcomes of such an investigation: 1. That CA does not consider paypal to be a high risk name. This is within their right, though unexpected. 2. That CA only considers paypal.com to be a high risk name, but not for example paypal.de (which has a real EV cert for PayPal San Jose). This is within their right, though unexpected. 3. That CA considers paypal.CCTLD to be high risk, but not paypal.NEWTLD (e.g. paypal.museum or paypal.bank or paypal.cologne). Again, within their rights though still somewhat unexpected. 4. This is indeed an implementation or design bug in their automated software, a fix will be deployed shortly and the database of currently issued certificates will be retroactively scanned with the new tests. 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: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....
Are you saying that's what actually happened, or that we should all pretend that's what happened? Because I don't believe anyone from GoDaddy has made such a claim, and we ought not put words in their mouths. Alex On Fri, Apr 13, 2018 at 12:39 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 13/04/2018 18:07, Ryan Sleevi wrote: > >> Indeed, it was a public demonstration that they'll happily issue, that >> their stated policies and guidelines disclaim responsibility for the >> content, but that they will happily revoke anything that is publicly >> embarassing, even if it is entirely technically correct. >> >> Or perhaps it demonstrates the arbitrary, capricious, and opaque nature of >> what some CAs call "phishing", such as being anything that might be seen >> (unreasonably so) as embarrassing to them for having issued, so they try >> to >> pretend by revocation that it never happened. >> >> > That's not at all what I was saying. I am saying that the security > researchers created a (harmless) simulation of how a phishing site could > game the systems (specifically the US company registry system and the EV > CA system combined). > > The CA's then simulated how they would respond if a real phishing > site had done the same. Not because the simulation was embarrassing, > but simply as the logical continuation of the simulated scenario. > > It's like a fire drill where the mayor "pretends" that an old school > building is on fire, and the firemen then proceed to evacuate the > building and douse it in enough water to put out a real fire. > > Everybody knows it's just a make-believe drill, but they proceed to > demonstrate their abilities to handle the make-believe situation, > because doing so is kind of the point of having a drill in the first > place. > > On Fri, Apr 13, 2018 at 12:00 PM, Jakob Bohm via dev-security-policy < >> >> dev-security-policy@lists.mozilla.org> wrote: >> >> My point, and that of some others is that the blunt revocation was a >>> public demonstation of how that CA would respond to a real phishing >>> site, thus completing your public demonstration of the problematic >>> scenario. >>> >> >> >> >>> >>> On 13/04/2018 02:40, James Burton wrote: >>> >>> We both work in the security space and yes, usually blocking a proof of concept is good practice but in this situation I feel that revoking this cert was heavy handed and unnecessary. The probability of Ian using the EV certs for deceptive purposes was extremely low. There are tons more ways of using EV certs for bad purposes. James On Thu, 12 Apr 2018 at 23:35, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 12/04/2018 21:20, James Burton wrote: > > Both mine and Ian's demonstrations never harmed or deceived anyone >> as >> >> they > > were proof of concept. The EV certs were properly validated to the >> EV guidelines. Both companies are legitimate. So what's the issue? >> None. >> >> >> >> In the security space, blocking a proof of concept exploit is usually > considered the right thing to do. But doing so in a way that is > entirely limited to the concrete example rather than the underlying > problem is considered cheating. > > Consider, as an analogy, a hypothetical freedom of speech law whose > only > exception was that you must not shout "fire" in a packed theater. Then > an actor standing on stage making speech about the silliness of that > law > and then shouting "fire", with full warning of the audience to avoid > panic, should not be surprised to get charged with the specific > offense, > as it was a deliberate test of the law. Of cause, such an actor might > deserve some leniency in the punishment, such as a $1 fine, but he > should not be surprised the law is formally upheld. > > > > > 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 > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....
On 13/04/2018 18:07, Ryan Sleevi wrote: Indeed, it was a public demonstration that they'll happily issue, that their stated policies and guidelines disclaim responsibility for the content, but that they will happily revoke anything that is publicly embarassing, even if it is entirely technically correct. Or perhaps it demonstrates the arbitrary, capricious, and opaque nature of what some CAs call "phishing", such as being anything that might be seen (unreasonably so) as embarrassing to them for having issued, so they try to pretend by revocation that it never happened. That's not at all what I was saying. I am saying that the security researchers created a (harmless) simulation of how a phishing site could game the systems (specifically the US company registry system and the EV CA system combined). The CA's then simulated how they would respond if a real phishing site had done the same. Not because the simulation was embarrassing, but simply as the logical continuation of the simulated scenario. It's like a fire drill where the mayor "pretends" that an old school building is on fire, and the firemen then proceed to evacuate the building and douse it in enough water to put out a real fire. Everybody knows it's just a make-believe drill, but they proceed to demonstrate their abilities to handle the make-believe situation, because doing so is kind of the point of having a drill in the first place. On Fri, Apr 13, 2018 at 12:00 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: My point, and that of some others is that the blunt revocation was a public demonstation of how that CA would respond to a real phishing site, thus completing your public demonstration of the problematic scenario. On 13/04/2018 02:40, James Burton wrote: We both work in the security space and yes, usually blocking a proof of concept is good practice but in this situation I feel that revoking this cert was heavy handed and unnecessary. The probability of Ian using the EV certs for deceptive purposes was extremely low. There are tons more ways of using EV certs for bad purposes. James On Thu, 12 Apr 2018 at 23:35, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 12/04/2018 21:20, James Burton wrote: Both mine and Ian's demonstrations never harmed or deceived anyone as they were proof of concept. The EV certs were properly validated to the EV guidelines. Both companies are legitimate. So what's the issue? None. In the security space, blocking a proof of concept exploit is usually considered the right thing to do. But doing so in a way that is entirely limited to the concrete example rather than the underlying problem is considered cheating. Consider, as an analogy, a hypothetical freedom of speech law whose only exception was that you must not shout "fire" in a packed theater. Then an actor standing on stage making speech about the silliness of that law and then shouting "fire", with full warning of the audience to avoid panic, should not be surprised to get charged with the specific offense, as it was a deliberate test of the law. Of cause, such an actor might deserve some leniency in the punishment, such as a $1 fine, but he should not be surprised the law is formally upheld. 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: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....
Indeed, it was a public demonstration that they'll happily issue, that their stated policies and guidelines disclaim responsibility for the content, but that they will happily revoke anything that is publicly embarassing, even if it is entirely technically correct. Or perhaps it demonstrates the arbitrary, capricious, and opaque nature of what some CAs call "phishing", such as being anything that might be seen (unreasonably so) as embarrassing to them for having issued, so they try to pretend by revocation that it never happened. On Fri, Apr 13, 2018 at 12:00 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > My point, and that of some others is that the blunt revocation was a > public demonstation of how that CA would respond to a real phishing > site, thus completing your public demonstration of the problematic > scenario. > > > On 13/04/2018 02:40, James Burton wrote: > >> We both work in the security space and yes, usually blocking a proof of >> concept is good practice but in this situation I feel that revoking this >> cert was heavy handed and unnecessary. The probability of Ian using the EV >> certs for deceptive purposes was extremely low. >> >> There are tons more ways of using EV certs for bad purposes. >> >> James >> >> >> >> >> >> On Thu, 12 Apr 2018 at 23:35, Jakob Bohm via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >> On 12/04/2018 21:20, James Burton wrote: >>> Both mine and Ian's demonstrations never harmed or deceived anyone as >>> they >>> were proof of concept. The EV certs were properly validated to the EV guidelines. Both companies are legitimate. So what's the issue? None. >>> In the security space, blocking a proof of concept exploit is usually >>> considered the right thing to do. But doing so in a way that is >>> entirely limited to the concrete example rather than the underlying >>> problem is considered cheating. >>> >>> Consider, as an analogy, a hypothetical freedom of speech law whose only >>> exception was that you must not shout "fire" in a packed theater. Then >>> an actor standing on stage making speech about the silliness of that law >>> and then shouting "fire", with full warning of the audience to avoid >>> panic, should not be surprised to get charged with the specific offense, >>> as it was a deliberate test of the law. Of cause, such an actor might >>> deserve some leniency in the punishment, such as a $1 fine, but he >>> should not be surprised the law is formally upheld. >>> >>> >>> >>> > 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 > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....
On Fri, Apr 13, 2018 at 11:53 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 13/04/2018 05:56, Ryan Sleevi wrote: > >> On Thu, Apr 12, 2018 at 11:40 PM, Matthew Hardeman via >> dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >> Wow. I’m impressed. >>> >>> Let’s Encrypt by their own declaration and by observed interactions in >>> their community help forums maintains a high value blacklist of domains. >>> >>> >> This is misrepresenting what is stated. >> >> >> It’s difficult to imagine how that list doesn’t include PayPal but did >>> include mail.ru. >>> >>> Can you repeat that test with, say, microsoft.cologne? >>> >>> Just testing a theory... >>> >>> >> I think there's sufficient discussion in the past on such theories that it >> would seriously detrimental to try to rehash or relitigate - e.g. >> https://groups.google.com/d/msg/mozilla.dev.security.policy/ >> vMrncPi3tx8/ZOqtG2DBBgAJ >> > > That link does not discuss or answer what practices any real CA uses in > complying with the high-risk list BR. The thread that followed > contained lots of policy discussion, but almost nothing about what any > real world CA does about the question posed above (are global high risk > names flagged as high risk when used as 2nd level domains or public > suffix+1 level domains). > While I am thrilled that you viewed all of the links, you will find that the past discussion of what constitutes a "High Risk Domain" is not at all aligned with the notion you or Matthew is advocating. I can understand your desire to understand what "real CAs" do, but that's not at all aligned with what is required, which is the conversation that matters - as are the reasons for revocation. The simple answer is "It doesn't matter, because they're not required to, so stop trying to make it seem like they are" - and the threads all demonstrate the various flaws with the argument being made/advocated :) While I hope it is well-intentioned questioning, the answer is irrelevant to any of the discussions. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....
My point, and that of some others is that the blunt revocation was a public demonstation of how that CA would respond to a real phishing site, thus completing your public demonstration of the problematic scenario. On 13/04/2018 02:40, James Burton wrote: We both work in the security space and yes, usually blocking a proof of concept is good practice but in this situation I feel that revoking this cert was heavy handed and unnecessary. The probability of Ian using the EV certs for deceptive purposes was extremely low. There are tons more ways of using EV certs for bad purposes. James On Thu, 12 Apr 2018 at 23:35, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 12/04/2018 21:20, James Burton wrote: Both mine and Ian's demonstrations never harmed or deceived anyone as they were proof of concept. The EV certs were properly validated to the EV guidelines. Both companies are legitimate. So what's the issue? None. In the security space, blocking a proof of concept exploit is usually considered the right thing to do. But doing so in a way that is entirely limited to the concrete example rather than the underlying problem is considered cheating. Consider, as an analogy, a hypothetical freedom of speech law whose only exception was that you must not shout "fire" in a packed theater. Then an actor standing on stage making speech about the silliness of that law and then shouting "fire", with full warning of the audience to avoid panic, should not be surprised to get charged with the specific offense, as it was a deliberate test of the law. Of cause, such an actor might deserve some leniency in the punishment, such as a $1 fine, but he should not be surprised the law is formally upheld. 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: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....
On 13/04/2018 05:56, Ryan Sleevi wrote: On Thu, Apr 12, 2018 at 11:40 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Wow. I’m impressed. Let’s Encrypt by their own declaration and by observed interactions in their community help forums maintains a high value blacklist of domains. This is misrepresenting what is stated. It’s difficult to imagine how that list doesn’t include PayPal but did include mail.ru. Can you repeat that test with, say, microsoft.cologne? Just testing a theory... I think there's sufficient discussion in the past on such theories that it would seriously detrimental to try to rehash or relitigate - e.g. https://groups.google.com/d/msg/mozilla.dev.security.policy/vMrncPi3tx8/ZOqtG2DBBgAJ That link does not discuss or answer what practices any real CA uses in complying with the high-risk list BR. The thread that followed contained lots of policy discussion, but almost nothing about what any real world CA does about the question posed above (are global high risk names flagged as high risk when used as 2nd level domains or public suffix+1 level domains). The thread did mention that at least one CA was actually doing the high risk names checks suggested by the BRs, but not if that CA looked for global high risk names in TLDs where those may not yet be established. or https://groups.google.com/d/msg/mozilla.dev.security.policy/xprGXlZb1xM/PlhtjyyRA_wJ That thread from 2011 started by asking the right questions, but all the answers were speculative what-if and what-should posts, none about what any real CA actually did at any time. or https://groups.google.com/d/msg/mozilla.dev.security.policy/4Xy1Q6PHA7Y/a8Lp442OCAAJ That thread starts out by discussing a specific Slashdot blaming of Let's Encrypt for unspecified phishing sites and devolved into yet another discussion about if CAs should refuse malicious websites in general. It doesn't discuss the question at hand about global brands and 2nd level domains etc. or https://groups.google.com/d/msg/mozilla.dev.security.policy/w5EmcPrudhs/rC9EhJthAgAJ Another thread about general policy, nothing about if any specific CA is checking 2nd level domains against their internal lists of high risk domain names that are global in nature. or ... you get the idea. Continuing to beat the dead horse is not doing science, nor will it make the horse an interesting conversation starter. 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: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....
Reposting as I accidentally sent to Mr. Mill only. On Thu, Apr 12, 2018 at 1:57 PM, Eric Mill wrote: > > > But he did not deceive users. Demonstrating that this is possible is not > itself an act of deception. > > Except that if he can't maintain a working EV certificate in a name that may deceive users, then that would make the text misleading/deceiving. In a lovely chicken/egg debate fashion, the CA managed to make his website deceptive. > As it is, this effectively censors Ian's website where he is making a >>> statement about how EV works and how it interacts with >>> trademark/registration laws, through his own registered business. That >>> statement is -- and I'm being serious -- being oppressed, based on a >>> capricious decision by a CA. >>> >> >> The only sense in which it censors his website is that he doesn't >> presently have an EV certificate on it. If he wants it to be available to >> the public again, he can get a DV certificate for it any time. >> > > No, this act took his website down immediately for reasons related to its > statement (rather than any deceptive actions). That's censorship, even if > options exist to work around this censorship. If his registrar had disabled > his DNS, would it have been okay to describe that as "well, he can just get > another registrar who doesn't think his site is deceptive! Or he can just > use an IP address!". No, that would have been a Big Deal. > > Except that by killing the certificate, the CA has demonstrated that he can't get and keep an EV certificate with a deceptive name. If his text suggests otherwise, it's now deceptive. > Of course, that would break his proof-of-concept exploit. Which is the >> right outcome. It demonstrates that an EV certificate used in a manner >> which might cause confusion will be revoked. They're not stopping him from >> publishing. He can still do that, without the benefit of an EV certificate. >> > > The stripe.ian.sh site itself is not likely to cause confusion, and was > not an exploit. Here's what stripe.ian.sh looks like right now: > > > > This is not going to confuse anyone into thinking they're interacting with > the payment processing company. Stripe, LLC, the Kentucky-registered > company owned by Ian Carroll, is perfectly free to publish the statement > above. If the payment processing company objects, their appropriate method > of redress in the US is through the judicial system, or other > government-designed arbitration processes. > The confusion that they object to is presumably that the certificate would be allowed. By not allowing it, they made that come true. > > >> Ian is now not able to maintain this public demonstration on the internet >>> in any browser (including Chrome, since it's EV), despite having committed >>> no crimes, not having engaged in any malicious behavior, and not harmed any >>> users. >>> >> >> He could always just use a DV certificate, but then he wouldn't be able >> to drag along GoDaddy's endorsement and attach it to his particular >> exercise of free speech to which GoDaddy apparently objects. >> > > GoDaddy issuing an EV certificate can't be construed as endorsing the > speech on that website (and I am sure GoDaddy's lawyers would agree with > me!). GoDaddy would hardly be able to issue many EV certificates at all if > they were constantly expected to be endorsing the website contents of those > who receive them. > > Of course they would. And for all kinds of liability reasons that should remain the official line. Having said that, it's pretty apparent that the users who do look at EV indicators do seem to rely upon it as at least an endorsement of the identity of the party you're communicating with. No doubt GoDaddy is aware of that and doesn't intend to disabuse the public of that notion. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....
If your CA is audited according ETSI 319 401, there is a clear obligation for a CA (aka TSP) "to issue to those meeting the qualifications specified" * REQ-7.1.1-02: Trust service practices under which the TSP operates shall be non-discriminatory. * REQ-7.1.1-03: The TSP should make its services accessible to all applicants whose activities fall within its declared field of operation and that agree to abide by their obligations as specified in the TSP's terms and conditions. I don't know, if WebTrust has a similar requirement. From: Matthew Hardeman via dev-security-policy > Perhaps it should be the broader question of both issuance policy and > revocation? > > For example, guidelines denote what issuance is permissible but > nowhere in the BR policies (or in any of the root programs as far as > I'm aware) is an affirmative obligation to issue to those meeting the > qualifications specified. > > > On Thu, Apr 12, 2018 at 3:46 PM, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Eric raised an issue distinct from 'the value of EV' that I think is > > important: Can certificate revocation be used as a form of censorship? > > As HTTPS becomes the default state of the web, it becomes more > > important to consider this issue and what should be done about it. I > > plan to discuss this with others at Mozilla, and I welcome more > > discussion here on the topic (perhaps in a new thread). > > > > - Wayne With best regards, Rufus Buschart Siemens AG GS IT HR 7 4 Hugo-Junkers-Str. 9 90411 Nuernberg, Germany Tel.: +49 1522 2894134 mailto:rufus.busch...@siemens.com www.siemens.com/ingenuityforlife ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....
"... don't START inventing and applying any unwritten new rules..." ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
