Re: [Discuss] root CA bloat
On Mon, Nov 24, 2014 at 09:35:16PM -0500, Richard Pieri wrote: On 11/24/2014 3:20 PM, Derek Martin wrote: It is a practical impossibility for you (or your organization) to actually truly authenticate each and every entity with whom you do business on the Internet. I don't agree with the base assertion. [described solution snipped.] Yes, I'm aware that this does not solve the initial trust problem. And therein lies the problem. The initial trust problem is, I assert without conclusive proof, intractable. All I can offer is an analogy to illustrate the problem, with the caveat that this very quickly dives into the depths of philosophy. Let's say I meet you on the street, and you tell me you are Steven Smith, and produce very good fake ID to that effect. As it happens (in this scenario) I am exceptionally good at spotting fake ID. I prove that your ID is fake. This does not prove to me who you are--it only proves to me one identity whom you are not. The fact is, though my resources are limited and I could not afford to do the required research to minimize my uncertainty of your identity (the practical problem), there is actually no way for ME to ever prove conclusively that you are who you are (nevermind who you say you are). I believe this is a fundamental truth, because your identity truly lies almost solely in your own mind. Other people may recognize you, but they can not, in fact, prove beyond a shadow of a doubt that you are not just some exceptionally clever imposter, or that your identity isn't a complete fabrication that you have adeptly developed and maintained since before they met you. For businesses, the problem is in some ways better, and in some ways worse. There is no real identity at all, except that which is defined by commercial law. You can't ever really know whom you are trusting, because it can change in the blink of an eye. You perhaps can, given enough research, prove that legally the person you are dealing with who purports to represent the corporation, actually does. But I don't know anyone whom actually does that, or ever would... The cost of doing that is prohibitive. All you can ever do is improve your certainty; you can not guarantee it. Ever. And one of the properties of humanity that never ceases to amuse me is that you can be absolutely certain of something... and still be wrong. It happens to me more and more as I get older. ;-) Like I wrote above, I don't believe it is impossible to solve, only that nobody has put the effort into solving it (or if they have then their work has largely been ignored). I don't believe that is true. It's widely recognized as a problem and none of the great minds of our time have put forth anything resembling a real solution, practical or otherwise. There are a number of solutions that are aimed specifically at trusting entities such as on-line retailers. But they don't actually solve the problem; they just minimize it. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] root CA bloat
On 11/25/2014 1:15 PM, Derek Martin wrote: Let's say I meet you on the street, and you tell me you are Steven Smith, and produce very good fake ID to that effect. As it happens (in this scenario) I am exceptionally good at spotting fake ID. I prove that your ID is fake. This does not prove to me who you are--it only proves to me one identity whom you are not. It proves that I'm that particular guy you met on the street. You may not know my real identity but you still have a piece of information -- a fingerprint if you will -- that is uniquely mine. If that fingerprint is used then you know that it's the guy you met on the street with Steven Smith fake ID #32. That's all you need if you want to communicate with fake Steven Smith #32. At which point a web of trust or hybrid web and chain can be used if you need more than that. It's not an unsolvable problem. It's already been solved: social networks. What is your friends list on Facebook? It's a web of trust. What is a like on Facebook? It's someone in your web of trust endorsing some bit of information that you will see in your news feed given enough endorsements. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] root CA bloat
On Tue, Nov 25, 2014 at 02:52:47PM -0500, Richard Pieri wrote: On 11/25/2014 1:15 PM, Derek Martin wrote: Let's say I meet you on the street, and you tell me you are Steven Smith, and produce very good fake ID to that effect. As it happens (in this scenario) I am exceptionally good at spotting fake ID. I prove that your ID is fake. This does not prove to me who you are--it only proves to me one identity whom you are not. It proves that I'm that particular guy you met on the street. You may not know my real identity but you still have a piece of information -- a fingerprint if you will -- that is uniquely mine. This misses the point: we're talking about authenticating (essentially) anonymous parties on the internet for (essentially) trusting them with your money and/or secrets. The above was only an analogy to illustrate the problem. Though your response sort of makes my point for me sort of. Having met fake Steven Smith #32 I would certainly trust him with neither my money nor my secrets. If that fingerprint is used then you know that it's the guy you met on the street with Steven Smith fake ID #32. That's all you need if you want to communicate with fake Steven Smith #32. I have no use to communicate with fake Steven Smith #32... my goal is to trust that the website behind certificate XYZ actually belongs to my brokerage house, rather than some fake Steven Smith #32 who fully intends to abscond with my nest egg. The fingerprint of fake Steven Smith #32 has no value to me (or, I dare say, anyone), and I would not bother attempting to secure my communications with that person. At which point a web of trust or hybrid web and chain can be used if you need more than that. It's not an unsolvable problem. It's already been solved: social networks. Oh, right, just like the web of trusted certificate authorities. It's a solved problem, so we really don't need to continue this discussion! -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] root CA bloat
On 11/25/2014 3:56 PM, Derek Martin wrote: Oh, right, just like the web of trusted certificate authorities. It's a solved problem, so we really don't need to continue this discussion! Certificate authorities are not webs of trust. They are the opposite of webs of trust. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] root CA bloat
On Tue, Nov 25, 2014 at 04:18:34PM -0500, Richard Pieri wrote: On 11/25/2014 3:56 PM, Derek Martin wrote: Oh, right, just like the web of trusted certificate authorities. It's a solved problem, so we really don't need to continue this discussion! Certificate authorities are not webs of trust. They are the opposite of webs of trust. Yes, that was my point. Social networks are not either... unless you think someone who has over 1,000 friends on facebook actually completely trusts every one of them. The problem is not solved. It is just ignored by most people. Webs of trust also only go so far, and it is one thing to be someone's friend, and a very different thing to trust them with all of your money. And even if I might trust particular friends with all my money, that does not constitute a good reason for YOU to trust them with all of YOUR money. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] root CA bloat
On 11/25/2014 4:31 PM, Derek Martin wrote: Yes, that was my point. Social networks are not either... unless you think someone who has over 1,000 friends on facebook actually completely trusts every one of them. You don't need to completely trust every one of them. You just need to trust a sufficient number of them enough that the aggregate trust is meaningful to you. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] root CA bloat
From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss- bounces+blu=nedharvey@blu.org] On Behalf Of John Abreau Replacing X.509 requires that every site you want to visit switch away from X.509 as well. Convincing the whole world to embrace a crypto flag day is an enormously bigger task than bolting kludges onto an established standard. Nobody's talking about replacing X509 except RP, who doesn't seem to be following the conversation. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] root CA bloat
On Sun, Nov 23, 2014 at 08:33:11PM -0500, Richard Pieri wrote: What I don't understand -- and maybe don't want to understand -- is why you are jumping through hoops to bolt kludges onto X.509 instead of working to replace X.509 with something that has verifiable trust baked in. I think the concept of verifiable trust is fundamentally flawed. Not to seem too cynical, but I believe it is a truism that you literally can trust no one 100%--not even yourself. Anyone can experience difficulty sufficient to become desperate, and you can't trust desperate people. But, more practically speaking: It is a practical impossibility for you (or your organization) to actually truly authenticate each and every entity with whom you do business on the Internet. The problem is compounded by the needs of business, which include that the solution must be easy and efficient to implement, and must be flexible enough that it still works when, at the whim of management, the policies and practices of the business change (e.g. when politics or punitive policy prevents them from continuing to do business with their current certificate authority). I mention the latter because some of the proposed solutions include the idea of maintaining some sort of a catalog of certificates. This penalizes new certificates signed by new authorities, AND requires that you trust the catalog... All it really does is move the problem, not solve it. For very large entities (like a fortune 500 company) there are most likely literally dozens of people who have access to the canonical authentication token (in this case, their certificate's private key), ranging from the guy who generates the CSR, to (possibly) the employees of the CA which signs it (if they escrow the private key), to the people who manage the servers on which the certificate ultimately resides, all of which may be different people or entirely different companies, any one of which may use it for their own nefarious purposes, given sufficient motivation (which will of course vary from person to person). Ed previously touched upon the problem of initial trust... Even with PGP, where you can do key signing parties requiring participants to show ID, you still have at least a couple of problems: People you've never met can proffer false identification credentials, and in the case of a corporate entity, the best you can do is to receive the credentials of an agent of the entity, who may or may not be trustworthy. There are likely more, and more subtle problems too. This problem exists at very nearly every level and flavor of authentication: If you don't actually have longstanding knowledge of the person you are attempting to authenticate, you can never really be sure... and sometimes even when you do have longstanding knowledge. It would not be hard for you to find reports of long cons where someone gained the trust of another over a period of time, in order to gain access to their money, etc.. It's not quite the same as what we're discussing, but it's a flavor of it. A more relevant example is the Comodo fraud incident. Of course, the risk of any given attack varies greatly depending on what is being protected and the cost of protecting it... So, I think the reason you aren't seeing much clamoring for improvements in the system is that practically speaking, the improvements to be made, when compared to the cost of trying something new (which is very high), are rather minimal. For the entities who matter most (wealthy corporations) it very likely is not remotely worth the practical gains in security... And that's whom you have to convince, since by and large it's them with whom you are conducting business transactions that you (or they) want to protect. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] root CA bloat
On 11/24/2014 3:20 PM, Derek Martin wrote: It is a practical impossibility for you (or your organization) to actually truly authenticate each and every entity with whom you do business on the Internet. The problem is compounded by the needs of I don't agree with the base assertion. I don't believe that it is an impossibility, practical or otherwise. Means to do it exist. Kerberos does it on a small scale. Make something like Kerberos realms integral to web browsers. Make doing business with Amazon a matter of creating a principal for Amazon in your browser profile. There you have it: verifiable, mutual authentication across the entire Internet. No, that's not intended to be the solution. It's me noodling about one way to go about it. Yes, I'm aware that this does not solve the initial trust problem. Like I wrote above, I don't believe it is impossible to solve, only that nobody has put the effort into solving it (or if they have then their work has largely been ignored). It wouldn't require a flag day. It's something that browser makers could implement and deploy in parallel with the existing X.509 PKI currently in use. X.509 could then be deprecated once the new system achieves a critical mass. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] root CA bloat
On Sun, Nov 23, 2014 at 1:15 AM, Richard Pieri richard.pi...@gmail.com wrote: On 11/22/2014 4:15 PM, Bill Bogstad wrote: I already mentioned part of this in my first note. They would have to do it by changing the nameserver entries for the microsoft.com domain at the .com DNS servers which I'm pretty sure they don't run. MarkMonitor owns the microsoft.com and msft.net domains along with a slew of variations of those domain names. As owner of the domain, MarkMonitor could have VeriSign change the top level registration. It would not be bad data because MarkMonitor is the owner of the domain. Would it be visible? Sure. Any change in a public space is visible. Would MarkMonitor's customers care? Absolutely. MM would be doing what it is being paid to do: protect its customers' trademarks and copyrights without resorting to raids like the NoIP raid. Would the world notice? Probably not. MarkMonitor has been doing it for going on 15 years. If they did something that Microsoft hadn't requested then I'm pretty sure somebody would both notice AND care. This is all in the context of attacking the security of Internet communications via a MITM attack. If Microsoft (one of the two parties communicating in this example) authorized it, then it isn't MITM. Whether it ishttp://en.wikipedia.org/wiki/Off-the-Record_Messaging done via Microsoft directly disclosing my communications or via allowing some other third party agent to do so is not really relevant to me. As far as I can tell that is the risk that you are now describing. The risk is in every talking to them at all and I don't see how technology can really solve that. Even Off the Record Messaging (http://en.wikipedia.org/wiki/Off-the-Record_Messaging) doesn't keep the other party from disclosing the contents. It just stops them from proving that I'm the person who said it. Bill Bogstad ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] root CA bloat
On 11/23/2014 3:26 AM, Bill Bogstad wrote: If they did something that Microsoft hadn't requested then I'm pretty sure somebody would both notice AND care. This is all in the context of attacking the security of Internet communications via a MITM attack. If Microsoft (one of the two parties communicating in this example) authorized it, then it isn't MITM. Whether it Ahh. I see what you mean, now. Your argument, that because Microsoft /did/ authorize MarkMonitor to act as an intermediary makes any interception not MITM since it's not an unauthorized party listening in, has merit. But then, the NSA is authorized by law to do the same thing. Right now, almost the entirety of Internet communications is controlled by a handful of corporate entities which have even more power than the NSA to eavesdrop on communications. The biggest concern that I have isn't that MarkMonitor and its competitors will eavesdrop. It's that they'll receive national security letters ordering them to shut everything down. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] root CA bloat
On Sun, Nov 23, 2014 at 3:53 PM, Richard Pieri richard.pi...@gmail.com wrote: On 11/23/2014 3:26 AM, Bill Bogstad wrote: If they did something that Microsoft hadn't requested then I'm pretty sure somebody would both notice AND care. This is all in the context of attacking the security of Internet communications via a MITM attack. If Microsoft (one of the two parties communicating in this example) authorized it, then it isn't MITM. Whether it Ahh. I see what you mean, now. Your argument, that because Microsoft /did/ authorize MarkMonitor to act as an intermediary makes any interception not MITM since it's not an unauthorized party listening in, has merit. Almost... Microsoft didn't authorize MarkMonitor to monitor their communications (as far as I know). They authorized them to provide DNS related services. So if MarkMonitor did this, then I would call it a MITM attack. My point is more that if they did do it, I believe that it would be very public that something funny was happening. The cost to MarkMonitor for doing this would be so high that I don't see them doing it voluntarily. Now if this was really end of the world type stuff, someone might convince/force them to do it anyway. In that case though, I think the parities involved would just go to Microsoft and get copies from them. Much less likely for anyone to ever know. An alternative scenario where someone breaks into MM and does this is worth considering. By using MM, Microsoft is increasing the attack scope on their communications. Of course, Microsoft is also dependent on the security of all CAs, top level DNS servers, etc. The problems with CA delegation seem much more significant then this one though. Until we get a solution to that problem, I'm not going to worry about this one. Bill Bogstad ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] root CA bloat
From: Tom Metro [mailto:tmetro+...@gmail.com] I think what would be practical is not eliminating all the obscure CAs, but having the cert validation area on the address bar show orange or yellow or something to indicate that a valid cert was found, but that it was issued by a less known provider, I would be in favor of eliminating the Chinese government from the CA list. The color indicator indicating how much I trust some particular CA isn't practical, but the problem extends a little further - There are class 1 and class 2 certs, and higher, but of course there's no differentiation client-side. It's simply Ok or Not Ok. So the question of how much I trust some particular cert is an interesting question - extending not just to which CA issued the cert, but other factors as well, including the class of the cert, the cipherspec, key strength, etc. It would be interesting to come up with some meaningful indicator or behavioral difference client-side, based on level of trust for a given cert. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] root CA bloat
On 11/23/2014 11:13 AM, Bill Bogstad wrote: Almost... Microsoft didn't authorize MarkMonitor to monitor their communications (as far as I know). They authorized them to provide The concern isn't what MM is doing at the moment; it's what MM is capable of doing being a trusted CA and a trusted DNS registrar and the owner of record for Microsoft's domains. Don't focus exclusively on Microsoft here. All of the big data and social media players are using MarkMonitor's and CSC's services. security of all CAs, top level DNS servers, etc. The problems with CA delegation seem much more significant then this one though. Until we get a solution to that problem, I'm not going to worry about this one. Like I wrote before, CA delegation cannot be fixed because it isn't broken. It's operating exactly the way it was designed to operate. If you want to eliminate the problem with the lack of verifiable trust in the CAs and their delegates then you have to throw out X.509 PKI and replace it with something that has verifiable trust mechanisms. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] root CA bloat
Edward Ned Harvey (blu) wrote: There are class 1 and class 2 certs, and higher, but of course there's no differentiation client-side. It's simply Ok or Not Ok. So the question of how much I trust some particular cert is an interesting question - extending not just to which CA issued the cert, but other factors as well, including the class of the cert, the cipherspec, key strength, etc. True, it is a spectrum...so how abut this: The extension provides a dialog where you configure which factors to consider and how to weigh them, with reasonable defaults to get you started. It takes into account the cert class and whether it is an EV cert. It could use the SSL encryption options as additional factors. Using an old encryption algorithm? Down-ranked. Not using perfect forward secrecy? Down-ranked. (See https://www.ssllabs.com/ssltest/) It provides CAs grouped into collections, and lets you assign trust levels to those groups. So if you want to trust the CAs in your home country more than foreign countries, you can do that. If you want to assign a high trust the CAs used by sites ranked in the Alexia top 1000, you can do that. (The groups get recomputed and downloaded periodically.) It provides a way to apply exceptions to the list of CAs that are in a group. So if you want to moderately trust Asian CAs in general, but not the Hong Kong Post Office, you can kick it out of the group. It provides a crowd-sourced rating mechanism, so end-users can report CA incidents against a CA and down-rank it. (If you make use of downloaded groups and crowd sourced rankings, you've shifted some of your trust to a 3rd party, so now you have to decide how much you trust the extension that the people managing it.) Then in the browser UI, instead of displaying a single color, you get a bargraph that shows the aggregate value of all the trust metrics with shades from red (untrusted) to green (fully trusted), or the whole thing grayed out for no cert. -Tom -- Tom Metro The Perl Shop, Newton, MA, USA Predictable On-demand Perl Consulting. http://www.theperlshop.com/ ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] root CA bloat
On 11/23/2014 7:33 PM, Tom Metro wrote: The extension provides a dialog where you configure which factors to consider and how to weigh them, with reasonable defaults to get you started. What I don't understand -- and maybe don't want to understand -- is why you are jumping through hoops to bolt kludges onto X.509 instead of working to replace X.509 with something that has verifiable trust baked in. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] root CA bloat
On Sat, Nov 22, 2014 at 2:30 AM, Richard Pieri richard.pi...@gmail.com wrote: On 11/21/2014 6:19 PM, Tom Metro wrote: Has anyone created an extension for Firefox that trims down the cert list to something like the top 50 cert providers? ... It gets better. Do a whois lookup on google.com. Then do one for yahoo.com. Now bing.com, microsoft.com, amazon.com, verizon.com, netflix.com, apple.com, comcast.com, att.com. Hell, any major commercial service or content provider. Chances are you'll see the same names: MarkMonitor and Corporation Service Company. These two companies are top-level CAs that control the DNS for most of the big-name players in the game. Which is to You are conflating DNS and Certificate Authorities. When I look at the certificate used for www.microsoft.com, it appears to be signed by Symantec via Verisign. In any case, controlling someone's DNS is not the same thing as being able to sign an SSL certificate that will be accepted. And is far as DNS is concerned, I don't see how you could do anything other then a world wide MITM attack via the whois entry because the whois database is not queried in realtime. While doable, I would expect it to be noticed. The important thing for actual DNS queries is the chain of recursive and authoritative DNS servers involved. If a DNS attacker is on your physical path to these servers, (or he manages to pollute the right DNS cache), attacks are relatively easy. If you are using DNSSEC (you probably aren't) then things get harder again. To be clear, I'm not saying that there aren't problems here. I'm just saying that whois data isn't the game over that you seem to be implying. Bill Bogstad ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] root CA bloat
On 11/22/2014 5:33 AM, Bill Bogstad wrote: You are conflating DNS and Certificate Authorities. When I look at the certificate used for www.microsoft.com, it appears to be signed by Symantec via Verisign. In any case, controlling someone's DNS is not the same thing as being able to sign an SSL certificate that will be accepted. MarkMonitor is a trusted CA. If they generate a certificate for microsoft.com then your browser will trust it. MarkMonitor is authoritative for the microsoft.com domain. They can change all microsoft.com hosts to point to their servers and you will trust them because their DNSSEC signatures are good and valid. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] root CA bloat
On Sat, Nov 22, 2014 at 4:17 PM, Richard Pieri richard.pi...@gmail.com wrote: On 11/22/2014 5:33 AM, Bill Bogstad wrote: You are conflating DNS and Certificate Authorities. When I look at the certificate used for www.microsoft.com, it appears to be signed by Symantec via Verisign. In any case, controlling someone's DNS is not the same thing as being able to sign an SSL certificate that will be accepted. MarkMonitor is a trusted CA. If they generate a certificate for microsoft.com then your browser will trust it. MarkMonitor is authoritative for the microsoft.com domain. They can change all microsoft.com hosts to point to their servers and you will trust them because their DNSSEC signatures are good and valid. I already mentioned part of this in my first note. They would have to do it by changing the nameserver entries for the microsoft.com domain at the .com DNS servers which I'm pretty sure they don't run. This would be visible to the whole world. So yes, they could do this; but I'm pretty sure it would be found out because the bad data would be sitting in everybody's caching servers as well as the databases at the .com servers which are run by multiple organizations. I'm pretty sure they would then lose every customer they had within a few days or weeks. This is not a scenario that I'm going to lose sleep over. If you have some other scenario that doesn't involve putting MarkMonitor out of business please provide details. Bill ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] root CA bloat
On 11/22/2014 4:15 PM, Bill Bogstad wrote: I already mentioned part of this in my first note. They would have to do it by changing the nameserver entries for the microsoft.com domain at the .com DNS servers which I'm pretty sure they don't run. MarkMonitor owns the microsoft.com and msft.net domains along with a slew of variations of those domain names. As owner of the domain, MarkMonitor could have VeriSign change the top level registration. It would not be bad data because MarkMonitor is the owner of the domain. Would it be visible? Sure. Any change in a public space is visible. Would MarkMonitor's customers care? Absolutely. MM would be doing what it is being paid to do: protect its customers' trademarks and copyrights without resorting to raids like the NoIP raid. Would the world notice? Probably not. MarkMonitor has been doing it for going on 15 years. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] root CA bloat
Edward Ned Harvey (blu) wrote: Look at the list of CA's on Mozilla's list, and look at their process for accepting CA's (and read that link about Honest Achmed, which is hilarious https://bugzilla.mozilla.org/show_bug.cgi?id=647959 ) Heh. It's a joke application to add a root certificate for Honest Achmed's Used Cars and Certificates, which includes this: Achmed's business plan is to sell a sufficiently large number of certificates as quickly as possible in order to become too big to fail (see regulatory capture), at which point most of the rest of this application will become irrelevant. (The ticket was marked resolved invalid.) Mozilla and Apple are basically the sluts of CA's. They take any damn thing from anybody. Has anyone created an extension for Firefox that trims down the cert list to something like the top 50 cert providers? I think what would be practical is not eliminating all the obscure CAs, but having the cert validation area on the address bar show orange or yellow or something to indicate that a valid cert was found, but that it was issued by a less known provider, so if you are connection to your US-based bank, or Amazon, or Google and you see this this, then you should be cautious. -Tom -- Tom Metro The Perl Shop, Newton, MA, USA Predictable On-demand Perl Consulting. http://www.theperlshop.com/ ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] root CA bloat
On 11/21/2014 6:19 PM, Tom Metro wrote: Has anyone created an extension for Firefox that trims down the cert list to something like the top 50 cert providers? Who's to say what those top 50 are? And in fact, pruning to the top 50 would only remove about a dozen of the top level certificate authorities from Firefox's (v33.1.1) list. A huge problem is subordinate authorities. Subordinates are chained to the roots so that you don't need to have their certificates distributed with the browsers. When you hit a site like the Bavarian National Library, your browser looks at the designated CA and follows the chain to the anchor. https://opacplus.bsb-muenchen.de/ Which is to say that if you trust the number 1 root CA in the world then you automatically trust any subordinate CA that the number 1 root delegates. And you automatically trust any subordinate CA that the the delegate delegates. And so forth. This can't be fixed because it's not broken; it's how the X.509 trust chain was designed to operate. And if you expunge delegated authority certificates from your browser, well, they'll just get reloaded the next time you visit sites with delegated certificates AND you'll blow away any benefit that pinning those certs might have provided since you unpinned and erased them. It gets better. Do a whois lookup on google.com. Then do one for yahoo.com. Now bing.com, microsoft.com, amazon.com, verizon.com, netflix.com, apple.com, comcast.com, att.com. Hell, any major commercial service or content provider. Chances are you'll see the same names: MarkMonitor and Corporation Service Company. These two companies are top-level CAs that control the DNS for most of the big-name players in the game. Which is to say that they have the tools necessary to perform MITM against huge swaths of Internet traffic. And you have little choice but to trust them, even when their business model is abusing that trust in order to identify and prosecute IP infringement, because Apple and Amazon and Netflix and Google and all the rest would stop working if you revoke that trust. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
