You are right to point out that many of those scenarios could be accomplished with a self-signed cert or indeed no cert at all. The decision to use a good cert or the likelihood of a good cert being used in any given scenario is not necessarily that important. What matters is that once we find a good cert has been used, what should we do about that cert?
I don't think we should absolve CA's of any responsibility or involvement when something "bad" comes along but neither do I think it falls entirely to them to figure out what to do. Getting the right balance will be tricky but I think it's worth fleshing out if people are interested. Original Message From: Nick Lamb Sent: Thursday, May 26, 2016 1:25 PM On Thursday, 26 May 2016 15:40:35 UTC+1, Peter Kurrasch wrote: > I might use a perfectly good cert in a "bad" way: Maybe it's worthwhile to consider what happens instead if we live under a regime (whether legally enforced or just de facto because of choices made by browser vendors) where you can't get a "perfectly good cert" for these scenarios. But in some cases I might not be clear what you propose. > * Create a phishing site to harvest login credentials from unsuspecting > people. For this I might create my own bogus domain or piggyback off an > existing, legitimate domain. Either way, I can use the cert to help create > the illusion of legitimacy to a victim while I steal his or her info You don't need your own "perfectly good" cert, the legitimate domain has one, which you retain. To stop this we must prevent legitimate domains obtaining certificates. There is precedent for this as an anti-crime strategy - don't try to arrest criminals, instead go after victims, with their prey thinning the criminals will starve. It's not terribly... nice, though is it? > * Use a server to distribute malware via online adverts (malvertising). > Having a cert helps make it look more legit and is required by some > advertising services. Again, it is much cheaper to use somebody else's servers. Since you're a criminal it hardly matters that this is illegal. > * Set up a spam email server and use the cert for my login page to the > control panel. The cert wouldn't be used on the email side of things but > controlling access to a server that lets me do bad stuff. A self-signed certificate works for this purpose too. To prevent this we could perhaps outlaw encryption? Or email? > * Use a server to distribute malware via downloads. When I launch a spam > campaign I'll attach an infected document with some dropper malware in it. > The dropper malware then contacts my server to get the real malware, be it > ransomware or a banking trojan or remote desktop control or general zombie > code or.... Whatever the case may be I can use certs to encrypt the malware > download making it harder for people to figure out what's really going on. Again, self-signed certificates work fine. Indeed they are already widely used for this purpose. > * Sign my malware code so that Windows or MacOS will happily install it. As with web browsers the Dancing Pigs problem applies. Users will happily click past the "not signed, danger of death" dialog so long as they think they're getting nude pictures of a celebrity rather than having their bank account emptied. We know the CA role isn't relevant here because in the Android ecosystem where there is no third party proof of identity users instead click past the (OS enforced) capabilities warnings, authorising an app to spend their money or spam their friends in the hope that this way they get to see the Dancing Pigs. > * Set up a command and control server and use certs to send encrypted > messages between the malware on the devices I've pwnd and my server. Self-signed certs work really well here. > * Set up a media server so that people can download some great movies that I > pilfered from someone else. Self-signed certs are very popular in this role as far as I understand > * Create a forum so people can talk about things their government does that > really bugs them and how to evade the different law enforcement agencies. > Obviously I'm using certs to make it harder for those agencies to snoop on > the forum participants. If you want to attract people who really care which type of foil is best then judging from openbsd-misc you should dismiss TLS altogether, they don't trust it at all. They will want a web-of-trust type setup, although (due to dancing pigs) they won't actually check any of the signatures so plaintext HTTP would also work (www.openbsd.org didn't do TLS until this month). > * Set up an online marketplace to swap/buy/trade any compromised keys and the > certs that go with them. Naturally I'd have a place to discuss which CA's > have the easiest security measures to bypass. It seems like the choice of certificate for the site itself is an implicit endorsement of one CA at least, is it not? But certainly such a group could use a self-signed certificate if they wanted, it's hardly as though they lack the sophistication. > * And sometimes it's just fun to park outside a hotel and setup a free WiFi > network to do some MITM. People do some crazy things when they think no one > is watching, and certs keep people from getting suspicious that anything is > amiss. Have you actually tried this? Inside a corporation, with Group Policy and suchlike on your side, TLS MITM breaks all sorts of unexpected things still, causing our users to be quite irate (I'm on their side, but it's a big corporation...). I can't believe it would work even one tenth part so well with an unauthorised MITM these days with HSTS and so on. And I don't see how a few "bad" certificates from a public CA really contribute at all. > * Oh, and Lenovo and Dell demonstrated some out of the box thinking with all > the Superfish stuff. Superfish is about adding an untrustworthy CA to the root store, is it not? That's an actual trust scenario. We don't trust Superfish, so they shouldn't be a CA. But end-entity (non-CA) certificates aren't about trust, they're about identity. _______________________________________________ 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
