Ryan, If you said “Mozilla is making this change and there’s nothing you can say or do to change that” I would accept those words, as I did with Ben’s response. But you engaged after Ben’s response, so I’d like to respond to your comments.
Here’s some common ground… we both believe that there are security implications that are NOT related to phishing. BOOM! We agree on something. Dear Mozilla, and this wonderful community, I’m not debating this change. I accept it is happening irrespective of what other stakeholders might think. I am simply responding to Ryan’s comments :-)) Back to Ryan… Mozilla provides 3 reasons for its decision. "1. Agility” No comment. I will defer to the people who know way more than me. There are lots of people who know more than me on the subject of phishing-related security risks too and I learn from them. But it’s an area in which I have an extremely deep understanding and appreciation for so it might be a good idea to try to understand where I’m coming from. It’s pretty much all I work on every day. Phishing is all about how humans interact with URIs and web documents based on whatever UI they use. If there’s dedicated UI that provides additional context for URIs and web documents, that too will impact their actions. My research into UI and metadata for providing additional context for URIs started before I co-founded the first ever W3C Incubator Activity (with Phil Archer from) - to create a new method of URL Classification and Content Labeling, which later replaced PICS as a Full Recomendation in 2009. The W3C Mobile Web Initiative was going to mandate compliance with best practices using the outcome of this initiative (a trustmark in the form of metadata) - coincidentally, I was one of the original seven founders of the W3C MWI and was on the Steering Council for the first year. I digress with a humblebrag because I don’t have the Google or Mozilla brand behind me to automatically assert credibility. Here’s one of the first browser extensions that provided additional UI for URIs, to help make the web easier to navigate for people with accessibility considerations as well as security and privacy related information: https://www.w3.org/2001/sw/sweo/public/UseCases/Segala/ <https://www.w3.org/2001/sw/sweo/public/UseCases/Segala/> I was the founder and CEO of Segala. (For anyone who’s moderately interested in phishing, please look up “reverse-proxy phishing” as it will scare the pants off you.) So… "2. Limit exposure to compromise" Keys valid for longer than one year have greater exposure to compromise, and a compromised key could enable an attacker to intercept secure communications and/or ***impersonate a website*** until the TLS certificate expires.” “Impersonate a website” = phishing. This is a security risk. “Security risk” and “phishing” are not interchangeable and I never said they were. It’s preferable that you don’t quote me with words that I didn’t use. "3. TLS Certificates Outliving Domain Ownership" TLS certificates provide authentication, meaning that you can be sure that you are sending information to the correct server and ***not to an imposter trying to steal your information***." “Imposter” on the Internet = phishing. "If the owner of the domain changes or the cloud service provider changes, the holder of the TLS certificate’s private key (e.g. the previous owner of the domain or the previous cloud service provider) ***can impersonate the website*** until that TLS certificate expires." “can impersonate the website” = you guessed what I’m about to say… “PHISHING”. It doesn’t matter if you don’t call this phishing, in the same way that it doesn’t matter if you don’t call the things that are used to reduce the risk of pedestrians being hit by speeding traffic, “speed bumps”. You could argue that they’re not called “speed bumps” but are in fact, called “speed breakers” - but they all refer to the same thing. So, even if you personally don’t call this phishing, it is phishing in the eyes of the security world and every single phishing expert in the universe. I had to encourage the MWI team not to redefine the meaning of “webpage” because everyone just knew what it was. There’s no point in taking about documents and URIs to consumers. So rather than teach them the real words, we should talk to them in the language they understand. Separately... I previously ignored the fact that the post says “you can be sure that you are sending information to the correct server and not to an imposter trying to steal your information”, because I didn’t want an EV conversation to take away from the above. I’ll bring it up now for the sake of the record though. If “you can be sure" refers to ‘consumers', this statement is fundamentally wrong because it does not reference EV. If it’s not referring to consumers, who is it referring to and in what context? It’s a very strange sentence that could have different meanings. I suggest an edit to be more clear and concise. Now that I have proven beyond a shadow of a doubt that we are talking about phishing, feel free to debate the merits of my points raised in my original email. Regards, Paul > On Jul 9, 2020, at 3:35 PM, Ryan Sleevi <r...@sleevi.com> wrote: > > I’m not sure how that answered my question? Nothing about the post seems to > be about phishing, which is not surprising, since certificates have nothing > to do with phishing, but your response just talks more about phishing. > > It seems you may be misinterpreting “security risks” as “phishing“, since you > state they’re interchangeable. Just like Firefox’s sandbox isn’t about > phishing, nor is the same-origin policy about phishing, nor is Rust’s memory > safety about phishing, it seems like certificate security is also completely > unrelated to phishing, and the “security risks” unrelated to phishing. > > On Thu, Jul 9, 2020 at 2:48 PM Paul Walsh <p...@metacert.com > <mailto:p...@metacert.com>> wrote: > Good question. And I can see why you might ask that question. > > The community lead of PhishTank mistakenly said that submissions should only > be made for URLs that are used to steal' credentials. This helps to > demonstrate a misconception. While this might have been ok in the past, it’s > not today. > > Phishing is a social engineering technique, used to trick consumers into > trusting URLs / websites so they can do bad things - including but not > limited to, man-in-the-middle attacks. Mozilla references this attack vector > as one of the main reasons for wanting to reduce the life of a cert. They > didn’t call it “phishing” but that’s precisely what it is. > > We can remove all of my references to “phishing” and replace it with > “security risks” or “social engineering” if it makes this conversation a > little easier. > > And, according to every single security company in the world that focuses on > this problem, certificates are absolutely used by bad actors - if only to > make sure they don’t see a “Not Secure” warning. > > I’m not talking about EV or identity related info here as it’s not related. > I’m talking about the risk of a bad actor caring to use a cert that was > issued to someone else when all they have to do is get a new one for free. > > I don’t see the risk that some people see. Hoping to be corrected because the > alternative is that browsers are about to make life harder and more expensive > for website owners with little to no upside - outside that of a researchers > lab. > > Warmest regards, > Paul > > >> On Jul 9, 2020, at 11:26 AM, Ryan Sleevi <r...@sleevi.com >> <mailto:r...@sleevi.com>> wrote: >> >> >> >> On Thu, Jul 9, 2020 at 1:04 PM Paul Walsh via dev-security-policy >> <dev-security-policy@lists.mozilla.org >> <mailto:dev-security-policy@lists.mozilla.org>> wrote: >> >> According to Google, spear phishing >> >> I didn't see phishing mentioned in Mozilla's post, which is unsurprising, >> since certificates have nothing to do with phishing. Did I overlook >> something saying it was about phishing? >> >> It seems reasonable to read it as it was written, which doesn't mention >> phishing, which isn't surprising, because certificates have never been able >> to address phishing. > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
