Re: DNS fragmentation attack subverts DV, 5 public CAs vulnerable
On Tuesday, December 11, 2018 at 11:27:52 AM UTC-6, Hector Martin 'marcan' wrote: > On 12/12/2018 01.47, Ryan Sleevi via dev-security-policy wrote: > > Is this new from the past discussion? > > I think what's new is someone actually tried this, and found 5 CAs that > are vulnerable and for which this attack works in practice. > > > https://groups.google.com/d/msg/mozilla.dev.security.policy/KvQc102ZTPw/iLQLKfbbAwAJ > > Looking back, this attack is also documented in the paper linked in that > thread, but unfortunately it's not open access. I get the feeling this > may be why that discussion didn't really proceed further in that thread. > I certainly missed it. > > The paper does list the vulnerable CAs, which are: > > > • COMODO, InstantSSL, NetworkSolutions, SSL.com: these CAs > > use the same MX email server mcmail1.mcr.colo.comodo.net > > which uses the same caching DNS resolver. The results from our > > cache overwriting methods indicates that the DNS resolver software > > is New BIND 9.x with DNSSEC-validation. I want to clarify that the only DNS mappings to Comodo from SSL.com are crl and crt CNAMEs for UserTrust issued SSL.com SubCAs operated and maintained wholly by Sectigo. The SSL.com Root CA, which is operated and maintained by SSL.com, does not have any dependency on the Comodo/Sectigo DNS and therefore should not be listed as one of the vulnerable CAs. Regards, Leo Grove SSL.com ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar
> > See also the screenshot I posted earlier. That was from a black-market web > site selling EV certificates to anyone with the stolen credit cards to pay for > them. These are legit EV certs issued to legit companies, available off the > shelf for criminals to use. For a little extra payment you can get ones with > high SmartShield scores so your malware is instantly trusted by the victim's > PC. > Peter, Are you referring to EV Code Signing certificates? I agree that needs to be addressed in another forum, but this discussion in on EV SSL/TLS and their value (or lack thereof) in the browser UI. Browsers do not support EV Code Signing in the UI as far as I know. It's been documented that EV Code Signing certificates are on the black market. Did you see the same thing for EV SSL/TLS? Leo > >The burden is not on the web browsers to prove that EV is detrimental to > >security - the burden is on third parties to prove that EV is beneficial. > > Yup, as per my previous post. We've got a vast amounts of data on this, if > there was a benefit to users then it shouldn't be hard to show that from the > data. > > Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar
On Sunday, August 18, 2019 at 12:15:58 AM UTC-5, Matt Palmer wrote: > On Fri, Aug 16, 2019 at 10:03:53PM -0700, Leo Grove via dev-security-policy > wrote: > > However, as a user I support EV SSL. I personally have never come across > > a scam site that displayed an EV SSL (I'm not saying they don't exist). > > Has anyone else come across a "scam site" displaying EV that's not part of > > an academic exercise? > > Counter-question: why does that matter? > > - Matt It matters because someone on this discussion claimed to be able to buy an EV SSL on the black market and used it as a supporting argument against EV. I'd honestly like to know if anyone has seen one in "in the wild" so to speak. My write-up was from the perspective of a user so I'd like to know if I've been putting too much faith in EV SSL since there may be scam sites employing these pirated certificates. Deploying a Stripe Inc EV SSL from a state other than CA is one thing, but using an EV SSL in conjunction with a domain name and website with the true intent to dupe potential customers is another matter. I'm trying to get past the theoretical and get to real world instances. Leo ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar
I don't know about other CAs, but at SSL.com we issue a very limited number of EV SSL certificates in comparison to other certificates so it's not a big revenue driver. However, as a user I support EV SSL. I personally have never come across a scam site that displayed an EV SSL (I'm not saying they don't exist). Has anyone else come across a "scam site" displaying EV that's not part of an academic exercise? An EV SSL only connects the site domain to its registered owner, nothing more. After that, I can decide whether to trust that company or if more research is warranted. At the end of the day, the user must make a decision based on the information they are given. This includes reviewing the EV SSL, domain name, site contents and third party reviews and listings. With the removal of EV from the browser UI, that's one less signal users can rely on. For instance, my inbox receives increasingly sophisticated spam and phishing mailers that require me to do double and triple takes. This results in legitimate emails potentially being flagged as spam. One of the signals I use to verify linked sites within the emails is if they display EV certificates. I do not entirely rely on EV, but it helps to build a subconscious trust profile of that site along with the domain, content, site reviews and search listings. As a result, I've determined on a number of occasions that the emails were indeed authentic in part because of the EV. In this business, paranoia is survival. Recently a neighbor asked me to verify a shoe site that he just purchased loafers from. Several red flags (ie Chanel header banner, unfamiliar domain name, etc) and no EV SSL prompted me to recommend he dispute the charge. Weeks later he confirmed it was indeed a scam site. Had the site displayed an EV SSL, I would have investigated more knowing the extra effort required to pass EV validation. But since no EV SSL appeared on the site, I didn't feel the need to waste any more time on the site. I can't be the only person whose aunt, neighbor or spouse asks me to help verify a site. This tells me that they do not understand how to properly read the EV information, not that EV SSL is bad or ineffective. I'm confounded why anyone would want less independently verified information on a site as opposed to more for fear EV doesn't perfectly suit their expectations. Well-known sites like google.com and amazon.com might not need EV as much as less well-known sites, but there are only a small number of these well-known sites. In comparison, the vast majority of sites are lesser-known and could benefit from as many validation signals as possible. I would think a local hospital or credit union who are increasingly targeted by phishing scams might argue an EV certificate would be one of the tools to help combat these types of scams. No single solution is perfect to eliminate online scams including EV SSL, but by removing the EV UI, the proverbial baby bath water comes to mind. I think the original intent of EV was and still remains noble. We should try to improve upon it, not discard it or relegate it to a virtually useless state. Scammers are a wily bunch, and they will always find some success in gaming or circumventing any system where human trust is involved. Let's try to make if harder for them, not throw our hands in the air and give up. At a minimum, consider keeping a color coded lock that would not take up any additional browser real estate and would give users "in the know" the EV signal. Otherwise, if the browsers have finalized their collective decisions on the matter, I do hope something better comes along that will benefit everyone. Treating all SSL/TLS certs as DV I think is a step backwards to 2007 when there was no EV, but we all knew something more than DV or OV was needed. Leo ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Intent to Ship: Move Extended Validation Information out of the URL bar
> > There are also opportunities for browsers here. I have to admit I > primarily use Google Chrome, rather than Firefox, so my observations may be > a little tainted, but I see various places where signals far more valuable > than the green lock could be implemented. Consider that most browsers > recognize credit card entry fields -- wouldn't it be great if clicking on > one on an EV site showed a little drop down under the input box that said > "[CA name here] has certified that [EV info here] is receiving your credit > card information"? > I like this idea, but putting my browser UI designer hat on, I would ask myself some questions. Would these indicators appear in input and textarea html tags? Or should it be at the form tag level? What about form elements that completely hide the native appearance via css? What about ajax and/or reactive apps? Then I would think it's just simpler to put the EV UI in the address bar. I'm curious if the browser developers went through this process, and we all ended up with what we have now. It might be time to (re)examine this. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Intent to Ship: Move Extended Validation Information out of the URL bar
On Thursday, August 29, 2019 at 5:26:55 PM UTC-5, Kirk Hall wrote: > On Thursday, August 29, 2019 at 3:10:49 PM UTC-7, Ryan Sleevi wrote: > > On Thu, Aug 29, 2019 at 5:18 PM Kirk Hall via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > > > > > > Don't argue with me, argue with the browser phishing filters and > > > anti-phishing services who do, in fact, use EV website information to > > > protect users as I described. Presumably they know what they are doing. > > > > > > Sorry that it sounded like I'm arguing. I'm just trying to understand the > > premise, since it so obviously has security holes that would make EV > > certificates more dangerous for any user who relied on such services. > > > > Could you point to the browsing phishing filters and anti-phishing services > > that do? It might be an opportunity for you to find out how they deal with > > this, and report back, so we don't have to presume anything. > > Let's hear directly from the experts - can you get someone from Google Safe > Browsing to post to this list, and then we can all ask him or her our > questions and get the definitive answers. Thanks. Kirk, What you are implying about GSB (and possibly other phishing filters) using the information contained within EV SSL certificates as part of their algorithm changes the reliance of EV SSL/TLS in fundamental ways. The end result of removing the EV UI is that the decision to trust a website based on EV is practically transferred from the user to GSB and other phishing filters since the user cannot see the EV UI. The user is still impacted by the EV information depending on how GSB interprets it along with other signals. If GSB does factor in EV, I'm curious to learn how they use the jurisdiction information in the EV certificates as well as other information. Some posters on this thread advocate doing away with the EV UI due to issues discussed previously, but I wonder if they are aware that this information still might be used to block certain websites or influence the user's behavior without the user ever knowing that the EV information was used. Will CAs market EV SSL as a way for sites to increase their "scores" with GSB and other phishing filters? Leo ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Intent to Ship: Move Extended Validation Information out of the URL bar
On Thursday, August 22, 2019 at 5:50:35 PM UTC-5, Ronald Crane wrote: > On 8/22/2019 1:43 PM, kirkhalloregon--- via dev-security-policy wrote: > > I can tell you that anti-phishing services and browser phishing filters > > have also have concluded that EV sites are very unlikely to be phishing > > sites and so are safer for users. > > Whatever the merits of EV (and perhaps there are some -- I'm not > convinced either way) this data is negligible evidence of them. A DV > cert is sufficient for phishing, so there's no reason for a phisher to > obtain an EV cert, hence very few phishing sites use them, hence EV > sites are (at present) mostly not phishing sites. > > -R So you agree it's safe to assume with high probability that when I come across a site displaying an EV SSL, it's not a phishing site. I think that is one of the purposes of EV. Or should we remove the EV bling because phishing sites prefer to use DV? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Website owner survey data on identity, browser UIs, and the EV UI
On Tuesday, October 8, 2019 at 10:36:19 PM UTC-5, Matt Palmer wrote: > On Tue, Oct 08, 2019 at 07:16:59PM -0700, Paul Walsh via dev-security-policy > wrote: > > Why isn’t anyone’s head blowing up over the Let’s Encrypt stats? > > Because those stats don't show anything worth blowing up ones head over. I > don't see anything in them that indicates that those 14,000 certificates -- > or even one certificate, for that matter --was issued without validating > control over the domain name(s) indicated in the certificates. > Validation compliance is not the topic of this thread. Stripe Inc was able to get their EV certificate in a compliant way after all. It sounds like since 14k DV certs were issued to phishing sites in a compliant way, everything is a-ok? What are your thoughts if those 14k certs were EV? > EV and DV serve different purposes, and while DV is more-or-less solving the > problem it sets out to solve, the credible evidence presented shows that EV > does not solve any problem that browsers are interested in. > > > If people think “EV is broken” they must think DV is stuck in hell with > > broken legs. > > Alternately, people realise that EV and DV serve different purposes through > different methods, and thus cannot be compared in the trivial and flippant > way you suggest. > > - Matt You've mentioned "EV and DV serve different purposes" twice and I think that is misleading. EV requires DV validation as well, and they both serve to authenticate and encrypt. However, EV goes beyond authenticating only the domain name which is where DV stops. EV attempts to bind the domain name to an actual owner. People deploying EV expect to get DV and something more. When the browsers stop displaying the EV UI, it will be indistinguishable from DV on cursory glance. To me, this shows EV and DV serve similar purposes, but EV attempts to go further in the context of authentication. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Welcome Ben Wilson to Mozilla!
Congrats Ben! Looking forward to working with you. Regards, Leo On Monday, April 13, 2020 at 1:32:42 PM UTC-5, Ben Wilson wrote: > Thanks, Kathleen > > I'm really excited to begin working with all of you! > > Cheers and stay safe, > > Ben Wilson > > On Mon, Apr 13, 2020 at 11:07 AM Kathleen Wilson via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > All, > > > > I am pleased to announce that Ben Wilson has joined Mozilla as a CA > > Program Manager! > > > > Ben has worked in PKI security, compliance, and policy since 1998. > > Previously, he worked at DigiCert in various roles, including VP of PKI > > Operations, VP of Compliance, and Chair of DigiCert’s Policy Authority > > team to develop and communicate policies and practices for internal and > > external stakeholders. Ben has also been very involved in the CA/Browser > > Forum. He is a former Chair of the CA/Browser Forum and of the American > > Bar Association’s Information Security Committee. Over the years, Ben > > has also participated in this mozilla.dev.security.policy forum. > > > > Here are some of the things that Ben will be responsible for: > > + Steps 3 through 9 of Mozilla’s root inclusion process[1], which > > includes the detailed CP/CPS reviews[2] and the public discussion phase[3] > > + CA Incident Bugs[4] > > + Updates to Mozilla’s Root Store Policy[5] and the Common CCADB > > Policy[6], including prioritizing potential changes[7] and leading > > discussions to determine the actual changes > > + Represent Mozilla in the CA/Browser Forum, along with Wayne > > > > I have added Ben to the Policy_Participants wiki page[8], and updated > > Wayne's entry. > > > > Welcome, Ben! > > > > Thanks, > > Kathleen > > > > [1] https://wiki.mozilla.org/CA/Application_Process > > [2] https://wiki.mozilla.org/CA/Application_Verification#Detailed_Review > > [3] https://wiki.mozilla.org/CA/Application_Verification#Public_Discussion > > [4] https://wiki.mozilla.org/CA/Incident_Dashboard > > [5] > > > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ > > [6] https://www.ccadb.org/policy > > [7] https://github.com/mozilla/pkipolicy/issues > > [8] https://wiki.mozilla.org/CA/Policy_Participants > > ___ > > 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
