Re: Nation State MITM CA's ?
I agree a persistent indicator is a good idea. From what I understand Firefox does already have an indicator hidden in the site information box that appears when you click the lock icon in the address bar ( https://bugzilla.mozilla.org/show_bug.cgi?id=1549605 ). This should be more visible in my opinion. Maybe add an asterisk next to the lock icon or something. Beyond that, I also think the work Mozilla is doing with Project Fusion ( https://wiki.mozilla.org/Security/Fusion ) is a good first step towards combating this type of surveillance (to the extent that's even possible given that this is a technological solution to a social problem). I'd also like to suggest that once Tor proxy integration _does_ come to fruition in Firefox, that a button to activate it be added to the "MITM Indicator" mentioned in my previous paragraph. It might also make sense to integrate a more traditional VPN client into Firefox with similar UI nudges for users experiencing government MITM attacks. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Pre-Incident Report - GoDaddy Serial Number Entropy
Perhaps the solution should be to amend the BRs to allow for more flexible handling of situations such as this. I understand that'd be rather difficult to formalize, since we can't just trust the CAs to decide for themselves when mass revocation doesn't make sense (as they have a vested interest in not revoking), and security impact isn't something that's easy to objectively quantify. However, the current status quo where millions of certs need to be revoked due to a technicality that has practically no impact on actual security seems silly. Remember that the security impact of revoking still-in-use certificates that do not actually pose a security risk is negative, as it leads to warning fatigue. Users who frequently encounter warnings about revoked certificates are more likely to bypass those warnings in the future. Not to mention the negative impact on the CA system as a whole, with increased operating costs for CAs and customers alike resulting from the additional work required to replace certificates. On Friday, March 15, 2019 at 12:11:40 AM UTC-5, Ryan Sleevi wrote: > On Fri, Mar 15, 2019 at 12:36 AM Jaime Hablutzel via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Could you please provide me a link to a previous discussion where the > > negative was stated, maybe by the module owner?. But note that I'm not > > asking for a bespoke or improvised exception for the current issue but for > > the possibility to introduce a procedure to handle any type of low > > breach/high disruption violations now and in the future?. > > > > "However, Mozilla does not grant exceptions to the BR revocation > requirements." [1] > "In my opinion, Mozilla should not get in to the business of granting > one-off exceptions ..." [2] > > [1] https://wiki.mozilla.org/CA/Responding_To_An_Incident > [2] > https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/HNDX5LaZCAAJ > (That's this thread, one week ago) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Allowing WebExtensions to Override Certificate Trust Decisions
On Wednesday, February 28, 2018 at 7:32:27 PM UTC-6, Ryan Hurst wrote: > On Wednesday, February 28, 2018 at 10:42:25 AM UTC-8, Alex Gaynor wrote: > > If the "fail verification only" option is not viable, I personally think we > > shouldn't expose this to extensions. > > > > I agree, there are far too many ways this will be abused and the cases in > which it would be useful are not worth the negative consequences to the > average browser user, at least in my opinion. > > Ryan Hurst What new risks would this expose users to that they are not already exposed to via the webRequest permission and the https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/tabs/executeScript API? It seems to me that extensions can already get pretty much full control of the user's browsing experience. Is possibly enabling MITM _really_ any worse than that? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)
On Thursday, December 21, 2017 at 7:38:59 PM UTC-5, Matthew Hardeman wrote: > Far too many do it. I think the technique is repugnant garbage that the > browsers themselves should solve. > > Spotify historically did this, too. > > The idea is that rich-client software on the PC has a daemon running in the > background on one of a number of chosen TCP ports. Usually it implements > WebSockets. > > When a user in a regular browser comes across an appropriate website, that > website is able to cause the browser to load resources from the daemon on > the localhost system. They use this for things like determining whether > the rich-client is installed and if so, what version. Also for exercising > simple control over the software on the PC. > > These certs started being used because Chrome would not allow WSS > connections on non-https. > > It would be incredible if a page that loads from a URI not resolving to an > IP endpoint on the local host were unable to load any sub-resources, any > time, under any further conditions via connections to any IP endpoint on > the local host. > > That change to the browser will kill the use case that keeps causing > software companies to get certificates like this. > > It will also kill of a lot of use cases that should probably be killed. > > For example, is there ever a legitimate reason that visiting a website > should be able to quietly access services running on various TCP sockets on > your PC? (Yes, theoretically there are, but the risks seem to way outweigh > the reward.) > > On Thu, Dec 21, 2017 at 9:18 AM, Hanno Böck via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Hi, > > > > Tavis Ormandy recently tweeted this: > > https://twitter.com/taviso/status/938503794098180096 > > > > What's happening here: The software battle.net by Blizzard has a domain > > localbattle.net that points to localhost, allowing the software to > > serve content there. The content is served via HTTPS with a valid cert, > > making it obvious that the private key is part of the software. > > > > I talked to Tavis, reported the issue to the CA and to Mozilla's > > bugtracker. I learned that there's a practically identical issue with > > EAs origin.net software. > > I also heard a claim that "everyone does this", however this seemed to > > refer to examples from the past that are already known. I briefly > > checked other gaming software (steam, uplay), but didn't find anything > > alike. (Which doesn't mean it's not there - but I didn't see open > > ports after running the software that were served with TLS.) > > > > Both certificates have been revoked. I don't have any detailed > > information about what these local connections were used for, if they > > changed anything and if anything broke due to the revocations, but I > > haven't seen any reports of breakage (I checked twitter for signs of > > it). > > I also was not able to extract the private keys with simple methods > > (grep), but it is almost certainly possible. (Full disclosure: Doing > > anything on a Windows system is not my strength.) > > > > In any case: If you are aware of other software doing something alike > > please report it. This is a key compromise. > > > > Bug EA: > > https://bugzilla.mozilla.org/show_bug.cgi > > Cert EA: > > https://crt.sh/?id=54134792 > > > > Bug Blizzard: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1425166 > > Cert Blizzard: > > https://crt.sh/?id=26142 > > > > -- > > Hanno Böck > > https://hboeck.de/ > > > > mail/jabber: ha...@hboeck.de > > GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 > > > > ___ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > >For example, is there ever a legitimate reason that visiting a website should be able to quietly access services running on various TCP sockets on your PC? Yes, there is and isn't this entirely the point of CORS/RFC1918? Nonetheless, web applications that offer remote desktop capabilities are going to need to eventually access resources on a local network. It is possible to do this properly. Building a PKI around Lets Encrypt is exactly how we avoided contributing to this mess; the suggestion of breaking websockets and removing all ability to connect to local resources in the name of "security" is pretty backwards. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)
For the record: Blizzard's response to these certs being revoked was to deploy a software update which installs their own root CA on their customer's computers: https://www.reddit.com/r/heroesofthestorm/comments/7lb8vq/hey_blizzard_whats_the_deal_with_this_sneaky_root/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: On the value of EV
On Monday, December 18, 2017 at 3:09:31 PM UTC-6, Wayne Thayer wrote: > Thank you Ryan for raising this question, and to everyone who has been > contributing in a constructive manner to the discussion. A number of > excellent points have been raised on the effectiveness of EV in general and > on the practicality of solving the problems that exist with EV. > > While we have concerns about the value of EV as well as the potential for > EV to actually harm users, Mozilla currently has no definite plans to > remove the EV UI from Firefox. At the very least, we want to see > Certificate Transparency required for all certificates before making any > change that is likely to reduce the use of EV certificates. > > Is Google planning to remove the EV UI from desktop Chrome? If so, how does > that relate to the plan to mark HTTP sites as ‘Not secure’ [1]? Does this > imply the complete removal of HTTPS UI? > > While we agree that improvements to EV validation won’t remove many of the > underlying issues that have been raised here, we hope that CAs will move > quickly to make the EV Subject information displayed in the address bar > more reliable and less confusing. > > - Wayne > > [1] > https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html So, given that Mozilla has no immediate plans to remove the EV UI from Firefox, perhaps the UI should be adjusted to include the state the Subject is registered in on the EV badge. No reason for that text to be any more misleading than necessary. (I assume this is something we can pretty much all agree on, yes?) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: On the value of EV
As I see it, there are essentially two entirely different forms of identity assurance that TLS certificates are intended to provide: - To assure the user that the domain name displayed in the address bar is controlled by the same entity who controls the server they are communicating with (Domain Validation) - To assure the user that the name displayed in EV certificate UI represents the real-world entity who controls the server they are communicating with (Extended Validation) Depending on the type of information the user intends to share with the site they are accessing, the user may care more about one of these forms of identity assurance or the other: - If the user is simply commenting on a blog or cataloging their favorite pie recipes, then they may only care that the entity they are communicating with today is the same as the one they were communicating with yesterday (Domain Validation) - If the user is entering real-world information like their street address, SSN, or bank details, then the main thing they care about is whether the entity they are communicating with is the same entity they already know and trust from real life (Extended Validation) And in-turn, each of these forms of identity assurance can be manipulated to potentially confuse users: - A malicious actor can craft a URL which appears to match the user's expectations, but in reality does not. (E.g. https://www.faceboook.com/, https://www.facebook.com.secure.site/, https://other.site.com/www.facebook.com) - A malicious actor can register a business which appears to match the user's expectations, but in reality does not. (Stripe in Kentucky vs. Stripe in California) Correct me if I'm wrong, but isn't the sole argument for removing EV UI based on the premise that attack #2 in the list above is worse than attack #1? So much worse in fact, that rather than try to mitigate #2, we should just remove Extended Validation entirely? I disagree with that premise. What is it about a user mistaking Stripe in Kentucky for Stripe in California that is so much worse than a user mistaking facebook.net for facebook.com? Is it just the fact that the name of the state the business is registered in is currently not visible in the UI? If that's the case, why is simply showing that information in the UI not a valid solution to the problem? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: On the value of EV
On Friday, December 15, 2017 at 4:06:02 PM UTC-6, Ryan Sleevi wrote: > It also perpetuates the myopic and flawed view as a phishing mitigation, > whose reliance is upon users checking it (again, user hostile) Ryan, several times now you've characterized the expectation that users check that the name listed on an EV certificate matches their expectations as "user-hostile". Could you clarify why it is you believe this practice is user-hostile while at the same time, expecting users to check the domain name listed in the URL bar is not? (Or perhaps you believe that both practices are user-hostile?) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: PROCERT decision
On Thursday, September 21, 2017 at 11:23:28 AM UTC-5, Gervase Markham wrote: > The CA Certificates module owner and peers have come to a decision > regarding our investigations into the activities of the CA "PROCERT". > > A large number of issues were raised regarding the operations and > practices of this CA: > https://wiki.mozilla.org/CA:PROCERT_Issues > > Considering them, it seems clear to us that PROCERT have not been, and > continue not to be, adequately aware of the requirements placed upon > them by various RFCs, the CA/Browser Forum's Baseline Requirements, and > Mozilla Root Store Policy. They have not demonstrated sufficient control > of their issuance pipeline or sufficient checking of the results to > avoid regularly creating certificates which violate the requirements of > one or more of those documents. PROCERT have also made assurances to us, > via responses to CA Communications, that certain things were true which > are manifestly not so (e.g. that they were using properly-randomized > serial numbers). > > In addition, PROCERT's response to these issues was inadequate. While > they revoked (most, but not all, of) the certificates which were flagged > as problematic, their written responses have been limited in number and > are very superficial. In some cases, it is clear that they have not > understood the issue that was raised. They have not, to our knowledge, > performed any root cause analysis which might allow us to have some > confidence that problems of this or a similar nature will not recur. We > have very little insight into their systems and what, if any, safeguards > they have in place. > > It seems that PROCERT's belief is that revocation is an adequate remedy > for all of the problems listed. We disagree. Therefore, we feel we can > no longer trust PROCERT, and plan to proceed with removing their > "PSPProcert" certificate from our root program and root store. > > Kathleen Wilson > Gervase Markham > Ryan Sleevi Will there be any sort of deprecation period for PROCERT certificates as with StartCom/Wosign & Symantec? Or is PROCERT small enough that you believe it's feasible to just immediately distrust them without any significant negative impact on the overall web ecosystem? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
