Re: MITM in the wild
Eddy Nigg wrote: On 11/15/2008 05:18 PM, Ian G: Eddy Nigg wrote: On 11/12/2008 05:21 PM, Ian G: Not sure why, but your posting arrived just only now... I was offline / travelling. There is this little lightbulb on the bottom left side of Thunderbird that we can click, and then the emails cache up until net is restored. What is clear is that the name is not really the essence of the process, it is just one part. So if we are claiming the full essence of getting people to court, we need to do other things; We'd rather prefer to remain out of court, but that's the ultimate option. The fact that identification details are listed in a certificate usually is a prevention measure itself. Yes, these things are true statements in and of themselves. However, they are what we would call outsiders views of the law and not necessarily useful or positive or helpful. if we are just doing the Name, we should avoid talking about the courts purpose unless we can point to the other things as well, and show how it fits in. But not only the name is validated usually, but address, locality as well. The street address is many times not listed for non-EV certs, but it would by court order possible to be disclosed. Sure. This is the classical approach. Provide more info, and hope that helps. Just be careful to not claim that is why and the point because in court, the other side's lawyer might hold you to it, and ask some simple questions that might leave your case in tatters. You can, sure. But would you? Would you dare to masquerade as another person, and do some harm? It's not about me, but anybody who dares. Many do as your own junk folder can provide evidence of. It's the easiest thing in order to perform fraud. The people are all rhetorical, sure. Does anyone dare? Most won't. And those people will be stopped because they are being asked to lie or defraud, and they don't do that, so it is an easy fix. However, if we are talking about someone who can and will defraud, then they will also happily defraud to get a cert. Or any of a number of other things that are needed. Let's say you do that, and then the summons arrives to your email address. You see the summons. What are you going to do? LOL! That's really naive thinking! Do you really believe that somebody disguising his identity will bluntly use his own real IP address. :-) (Actually, yes. This is the most common thing. The number of people who have exposed themselves doing dirty behaviour and used their own real IP address in doing it is quite high. Most people don't even know what it means, and even experts like ourselves have difficulty in identifying how to protect our IP addresses. E.g., right this very moment, I don't know if you can trace me from IP address or not. And if it is a dynamic IP#, likely you can't trace it further anyway.) But that's not the point. The point is that the way our society works is that it exposes honest people to a lot of different little steps to show that they are honest; then we do business. This works, and it works on the net too. Ebay etc. In contrast, our societal system doesn't keep out people who are good at lying to people and defrauding systems. Certs don't change that. Certs themselves, and current secure browsing, has little effect on this all. At least one reason: fraud is complicated, it operates at different layers to crypto, e.g., socially engineered. Certs try and compress all fraud into a single claim in a little crypto box. Real fraudsters don't see that they want to be boxed in by the crypto, so they bypass. Hence, although your claims may be true they may also be worth nothing. Do you dare defy the court and not present yourself? If you do that, then you are toast. If they (a claimant and a real bill gates) come looking for you and find you, then not only have you committed a species of deception, you've tried to ignore the courts. Not only is your case compromised, but you've probably committed something against the court. The problem is, nobody will ever know that it was me... Until you make a mistake. Until the court chases you. Until the victim decides it is his life mission to track you down ... until a whole lot of things. Let me give you a real world example: some guy did some evil by using a nym to spread slander and lies about competitors in a community. After months of cross-referencing and so forth, we finally found an IP# that matched to his home address because he had forgotten to change over to his hop that one time ... but it still wasn't good enough because he said oh, that might have been my brother, who is psychologically unreliable... But, we eventually matched it by discovering that his laptop keyboard had a twitch in it, and the same twitch was in both emails from him and from this nym. Which is to say, real fraud and real anti-fraud is done in different ways to
Re: MITM in the wild
Eddy Nigg wrote: On 11/12/2008 05:21 PM, Ian G: No it's not. You just need the person, not their identity. LOL, you are funny...and how exactly do you get the person if you don't know who it is that you need? This is what the (verified real) identity details in certificates are here for... Wel... the system of courts isn't quite funny although there are some non-understandable aspects, and lots of myths about it. People often believe crazy things about how the courts act, like they are fair and just and they will protect you against bad people. In order to get someone to court, it generally depends on the jurisdiction you are in. In the english common law tradition, papers have to be served to the person. So you have to find the person, some way or other. (Having the name is useful, but what is more useful is knowing how to find the person, such as the physical address.) In other jurisdictions, it works other ways. In modern day cases, judges will often accept you emailing the papers to the person, if the email address is the only one you know, and this will work as long as your case is good. In civil code jurisdictions (Europe) the process is different, and I don't really understand it. (Bear in mind normal IANAL caveats :) What is clear is that the name is not really the essence of the process, it is just one part. So if we are claiming the full essence of getting people to court, we need to do other things; if we are just doing the Name, we should avoid talking about the courts purpose unless we can point to the other things as well, and show how it fits in. If you need to get someone in court, they either come willingly, in which case nothing is needed, or you need to find the person. You still need to know who it is that you want to get to court... In US court, you can file against John Doe, and the court can then help you find the body (by means of a real name or by other means). In other places they insist on at least a name of some form, although it might not be the real name. Known aliases and a.k.a. for example. courts will these days accept an email address if the circumstances are appropriate (e.g., that's how he closest you got when doing business). Most likely not. I can be [EMAIL PROTECTED] any time I want. You can, sure. But would you? Would you dare to masquerade as another person, and do some harm? Let's say you do that, and then the summons arrives to your email address. You see the summons. What are you going to do? Do you dare defy the court and not present yourself? If you do that, then you are toast. If they (a claimant and a real bill gates) come looking for you and find you, then not only have you committed a species of deception, you've tried to ignore the courts. Not only is your case compromised, but you've probably committed something against the court. You will likely lose that case. Default judgment or worse. Instead, because you are a wiser person than that, you will simply appear before the court, and say, It is I, using that nym, but my real name is Bob Smith. And the court will proceed to hear the case. At least in english common law, it is OK to use any name you like, as long as it isn't for fraudulent purposes. Because if you claim that it is needed to resolve disputes, then this may be deceptive. (At the least, you should figure out why it is needed and use that reason.) What's new here? If a claim is made by CAs that the Name is needed to pursue someone in the courts, this is more or less deceptive. It is like a claim that anti-wrinkle cream will make you younger. To the extent that anti-wrinkle cream makes you feel younger, that's kinda-ok because fashion is like that, we don't as a society apply high standards in that market. But it is not acceptable to build any regulated or mandated product on such an unfounded claim, and it is not acceptable in a security market. If we accept that (and we are in a security market, regulated by audits and/or vendors) then we should stop making that claim. Unfortunately, this then creates a big hole in the process: what was the Name there for? If it hasn't got a serious purpose, then it is a fashion accessory. If it is a fashion accessory then we don't need stringent controls. Fashion is choice, not regulation. Or, if it has got a serious purpose, what is that? Then, we can look at how to regulate that. (One thing should be clear: if a Name is in the cert, the CA is making a claim about that name. If it issues you a cert with Bill Gates, we might validly ask what then is the claim?) According to my preference I may freely decide in order to give somebody access to certain resources which are truly under my control, I may require a verified identity too. It's about the risk assessment of each of us, being it private or corporate. OK, I buy that. Would you sign to that as a principle? I think so, yes. It's
Re: MITM in the wild
On 11/15/2008 05:18 PM, Ian G: Eddy Nigg wrote: On 11/12/2008 05:21 PM, Ian G: Not sure why, but your posting arrived just only now... What is clear is that the name is not really the essence of the process, it is just one part. So if we are claiming the full essence of getting people to court, we need to do other things; We'd rather prefer to remain out of court, but that's the ultimate option. The fact that identification details are listed in a certificate usually is a prevention measure itself. if we are just doing the Name, we should avoid talking about the courts purpose unless we can point to the other things as well, and show how it fits in. But not only the name is validated usually, but address, locality as well. The street address is many times not listed for non-EV certs, but it would by court order possible to be disclosed. You can, sure. But would you? Would you dare to masquerade as another person, and do some harm? It's not about me, but anybody who dares. Many do as your own junk folder can provide evidence of. It's the easiest thing in order to perform fraud. Let's say you do that, and then the summons arrives to your email address. You see the summons. What are you going to do? LOL! That's really naive thinking! Do you really believe that somebody disguising his identity will bluntly use his own real IP address. :-) Do you dare defy the court and not present yourself? If you do that, then you are toast. If they (a claimant and a real bill gates) come looking for you and find you, then not only have you committed a species of deception, you've tried to ignore the courts. Not only is your case compromised, but you've probably committed something against the court. The problem is, nobody will ever know that it was me... Instead, because you are a wiser person than that, you will simply appear before the court, and say, It is I, using that nym, but my real name is Bob Smith. And the court will proceed to hear the case. At least in english common law, it is OK to use any name you like, as long as it isn't for fraudulent purposes. Or if there aren't such intentions in first place use a validated digital certificate. These days an unsigned mail should be always consumed with a grain of salt... If a claim is made by CAs that the Name is needed to pursue someone in the courts, this is more or less deceptive. Ha? Can you explain that? Here some example details strait from a certificate: E = [EMAIL PROTECTED] CN = Eddy Nigg L = Eilat ST = South C = IL What's deceptive here? Additionally the CA has more information about the subject such as the address and phone number. If we accept that (and we are in a security market, regulated by audits and/or vendors) then we should stop making that claim. There is no claim to stop! The quality of the verification performed may vary, but as a general rule, a verified certificate is sufficient to reach the person in question (by court order or else). Of course a crook may change address, but courts and law enforcement officials have their tools to locate somebody sooner or later. Provided that the persona in question is identified correctly. OK. So the principle is that everyone may make their own risk assessments, whether private or corporate. We may freely decide to allocate our resources and make our decisions. As I said, resources which are truly under my control, I may require a verified identity too! I didn't meant a browser here, but rather other resources, like a web site or mail server. It would also mean that a vendor was free to experiment and choose different security models c.f. Gerv's much lamented yellow bar and Jonathon's 4-click process. Isn't that what happened really? Not seeing your point. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DNSSEC? Re: MITM in the wild
* Alaric Dailey: DNSSEC is an assertion of validitity of the DNS. EV certs assert that the business behind the cert is legit. Only that a legal entity exists (whether its legitimate is not checked). EV certificates are routinely issued to organizations which do not run the business which eventually uses the certificate. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DNSSEC? Re: MITM in the wild
On 11/15/2008 05:19 PM, Florian Weimer: * Alaric Dailey: DNSSEC is an assertion of validitity of the DNS. EV certs assert that the business behind the cert is legit. Only that a legal entity exists (whether its legitimate is not checked). EV certificates are routinely issued to organizations which do not run the business which eventually uses the certificate. Can you please back up your claim and provide us with a few examples? Since this happens routinely, I'm sure you won't have a problem providing us with some... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DNSSEC? Re: MITM in the wild
Eddy Nigg wrote: On 11/15/2008 05:19 PM, Florian Weimer: * Alaric Dailey: DNSSEC is an assertion of validitity of the DNS. EV certs assert that the business behind the cert is legit. Only that a legal entity exists (whether its legitimate is not checked). EV certificates are routinely issued to organizations which do not run the business which eventually uses the certificate. Can you please back up your claim and provide us with a few examples? Since this happens routinely, I'm sure you won't have a problem providing us with some... Businesses are bought and sold all the time. A good reputation is a fungible asset that is often part of the valuation process in the sale of a business. The extreme example is the bustout, where organized crime takes over a business with a good reputation and uses it as a platform for criminal activities (a favorite is stock brokerage.) It's happened a number of times online. There's the old scheme of the crook who finds an eBay merchant with an excellent feedback score, buys his ID and his computer (getting all the cookies and MAC address etc. with it) and sells a thousand imaginary laptops. There are companies like Toysmart.com, a good company that ran into trouble in the dotcom bust and sold itself to some mysterious entity that was out to make interesting use of customer information, disregarding of course all of Toysmart's privacy statements. Some good investigative journalism shined the spotlight on one of Toysmart's stockholders, Disney, which bought it out at the last minute and killed it to protect their own reputation. Businesses with good reputations and EV certificates can get into trouble. When that happens, the reputation and certificates become a very visible asset to buyers with money and bad reputations. WK ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DNSSEC? Re: MITM in the wild
On 11/15/2008 05:57 PM, Wes Kussmaul: Eddy Nigg wrote: On 11/15/2008 05:19 PM, Florian Weimer: * Alaric Dailey: DNSSEC is an assertion of validitity of the DNS. EV certs assert that the business behind the cert is legit. Only that a legal entity exists (whether its legitimate is not checked). EV certificates are routinely issued to organizations which do not run the business which eventually uses the certificate. Can you please back up your claim and provide us with a few examples? Since this happens routinely, I'm sure you won't have a problem providing us with some... Businesses are bought and sold all the time. A good reputation is a fungible asset that is often part of the valuation process in the sale of a business. The extreme example is the bustout, where organized crime takes over a business with a good reputation and uses it as a platform for criminal activities (a favorite is stock brokerage.) It's happened a number of times online. There's the old scheme of the crook who finds an eBay merchant with an excellent feedback score, buys his ID and his computer (getting all the cookies and MAC address etc. with it) and sells a thousand imaginary laptops. There are companies like Toysmart.com, a good company that ran into trouble in the dotcom bust and sold itself to some mysterious entity that was out to make interesting use of customer information, disregarding of course all of Toysmart's privacy statements. Some good investigative journalism shined the spotlight on one of Toysmart's stockholders, Disney, which bought it out at the last minute and killed it to protect their own reputation. Businesses with good reputations and EV certificates can get into trouble. When that happens, the reputation and certificates become a very visible asset to buyers with money and bad reputations. Your argument might be valid or not, but it's not related to the claim Florian made. I'd like to see real evidence concerning the claim made about EV certificates. Ebay merchants may be bought by crooks, I don't know and is out of the scope of digital certification. Lets stay focused! I want to see an EV certificate securing a web site not belonging to the organization to which it was issued, please. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DNSSEC? Re: MITM in the wild
At 8:20 PM +0200 11/15/08, Eddy Nigg wrote: Lets stay focused! This thread started off with a purported newbie having a problem with seeing self-signed certs where she shouldn't have. It then morphed into a discussion of security UI design. Then it went to what users shold and should not be told about. Then it went back to how to design the UI for encountering self-signed certs. Then there was a long, somewhat defensive discussion about the value added by certificate authorities. Then it went to DNSSEC. Then it went to EV certs. Which of those did you want to focus on? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DNSSEC? Re: MITM in the wild
On 11/15/2008 10:04 PM, Paul Hoffman: At 8:20 PM +0200 11/15/08, Eddy Nigg wrote: Lets stay focused! This thread started off with a purported newbie having a problem with seeing self-signed certs where she shouldn't have. It then morphed into a discussion of security UI design. Then it went to what users shold and should not be told about. Then it went back to how to design the UI for encountering self-signed certs. Then there was a long, somewhat defensive discussion about the value added by certificate authorities. Then it went to DNSSEC. Then it went to EV certs. That is what makes this place truly interesting :-) Of course we could/should change the subject once in a while, but not everybody is familiar with this practice... Which of those did you want to focus on? Right now about the claim made by Florian. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
On 11/12/2008 05:21 PM, Ian G: No it's not. You just need the person, not their identity. LOL, you are funny...and how exactly do you get the person if you don't know who it is that you need? This is what the (verified real) identity details in certificates are here for... If you need to get someone in court, they either come willingly, in which case nothing is needed, or you need to find the person. You still need to know who it is that you want to get to court... courts will these days accept an email address if the circumstances are appropriate (e.g., that's how he closest you got when doing business). Most likely not. I can be [EMAIL PROTECTED] any time I want. Because if you claim that it is needed to resolve disputes, then this may be deceptive. (At the least, you should figure out why it is needed and use that reason.) What's new here? According to my preference I may freely decide in order to give somebody access to certain resources which are truly under my control, I may require a verified identity too. It's about the risk assessment of each of us, being it private or corporate. OK, I buy that. Would you sign to that as a principle? I think so, yes. It's applied already today in some forms. It can be done better... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Eddy Nigg wrote: Nope, just eliminating an assumption or two: identity required for court. Once these are eliminated, life becomes much easier. Real identity is required for court, No it's not. You just need the person, not their identity. The identity is useful for eliminating mistakes, of course, and the court will look at that aspect. That's its job. If you need to get someone in court, they either come willingly, in which case nothing is needed, or you need to find the person. This requires either a physical address and a service of summons to the person, or in webcommerce, courts will these days accept an email address if the circumstances are appropriate (e.g., that's how he closest you got when doing business). So, if you were looking at resolving disputes -- are you? -- then you would look at how to get the person into a forum of dispute resolution. If that is the service that you are looking to offer the person, then it needs to be tuned to do that. why eliminate it? Because if you claim that it is needed to resolve disputes, then this may be deceptive. (At the least, you should figure out why it is needed and use that reason.) According to my preference I may freely decide in order to give somebody access to certain resources which are truly under my control, I may require a verified identity too. It's about the risk assessment of each of us, being it private or corporate. OK, I buy that. Would you sign to that as a principle? iang PS: longer reply later, no time today, apologies. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
On 11/12/2008 08:32 AM, Ian G: eBay users seems to survive without them? Because a different body governs them. Or lets make some comparison to transportation, where one in order to drive a car must undergo some training and carry a license. I could imagine something similar applied to the Internet, where one carries a license in order to drive on the network. Anybody without a license can't drive along. Sure. This is nothing to do with *identity* tho, all it has to do with is ones tested ability to drive safely. Try this thought experiment: would a driver's licence without a name on it, but with a photo on it, work as well? No, because the license is tied to the person. His identity details are part of the license document. Right, certs without names or with nicknames achieve that. It might not be possible to see the name, but seeing the issuer is sufficient to say something. If a trail is all that is required, this can simplify things a lot. Right, if the issuer could confirm that the subscriber has disclosed his details and was confirmed by the issuer (whatever procedure is not imported for this exercise) and this is his identification number (some random number issued by the issuer), it could be sufficient for most operations. The protection is still real even though the certification doesn't include the details of the subscriber. Well, except there isn't much in the way of use cases. On the roads, bad drivers keep bumping into each other. Of course. Actually we aren't concerned about bad drivers and accidents on the net, but about deliberate damage. This includes also spam etc. Of course. There shall be no difference from when I walk into their shop or buy from the web site. Ah, but there is, that is the point. Well, for the legal system there is very little difference, it's your ability to pursue which is limited. The point is: do CAs require this so-called legal identity? Obviously that's the way to reach an entity, being it a private person or company. Let's call it for sake of discussion a privacy issue. If so, then it should not be required unless needed. I think that's correct and is also applied today (i.e. your web log doesn't require to disclose your identity, hence DV would be perfectly fine). If the answer is, so relying party can take the subscriber to court, then we have a problem: it won't work that easily, indeed it is bordering on useless, because the more borders we cross, the more the transaction costs go up. And everything should be with reason. Nope, just eliminating an assumption or two: identity required for court. Once these are eliminated, life becomes much easier. Real identity is required for court, why eliminate it? According to my preference I may freely decide in order to give somebody access to certain resources which are truly under my control, I may require a verified identity too. It's about the risk assessment of each of us, being it private or corporate. And, for a dispute, you do not need the verified identity. You need to find some way to get the person into court. ...and how do you get the person into court if you don't know who the entity is? I don't understand what exactly you discovered? -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
No. There is no consensus. There are opposing camps. One camp believes that the solution is to drop all self-signed certs. Another camp believes that Key Continuity Management is the answer. Yet a third camp believes that user training has to be done, and the UI needs a little tweaking, is all. A fourth camp has written off SSL / secure browsing as irrepairably flawed. A fifth camp believes that only protocol bugs and the number of bits is security, the rest is outside purview. A sixth camp believes this is not a technical issue at all, and will be solved by the lawyers. If we look over the hill, we'll see other camps, hear much muttering, and in the end, we all return to our cups and mutter on... How about a consensus that there is no consensus? [camp A] NO! [camp B] NEVER! Thanks for the nuanced answers Ian G and the rest, I've enjoyed this chat. I'm not sure exactly what I had hoped to contribute, but I've certainly educated myself. You want a cup of wine with your muttering? :) 1994 Urbina Gran Reserva Rioja if you please. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
On 11/11/2008 03:54 PM, Ian G: And, in particular, the PKI industry's obsession with some concept that you refer to as legal identity is ruining its own market. I personally don't perceive it as such nor do I think that there is such an obsession. I *do* believe that more verified identities may be good for the Internet in general - which would allow to view unverified ones with a grain of suspicion. Or lets make some comparison to transportation, where one in order to drive a car must undergo some training and carry a license. I could imagine something similar applied to the Internet, where one carries a license in order to drive on the network. Anybody without a license can't drive along. However - and this might be interesting for the other camp - one doesn't stick the drivers license in bold letters onto the rear window for everybody to see, instead you've got license plates for the car. In some way, the driver remains anonymous to some extend. Applying this to the Internet, I'd know that you've got a license and I'd even know the number. I still don't know your personal details - which I could request from you if I wanted to. It would be known by an authority should need arise (in case of unlawful actions like malware distribution). Now of course this is some form of reducing the freedom of the individual, but on the other hand would bring some piece of mind (with malware and fraud removed, children clearly protected and so forth). Similar to the transportation system where not every individual can do as he likes. In such a network where drivers hold licenses to drive, one could according to preferences and policies apply rules, for example require a license to send mail to a server, or to view some private content, or publish software etc. Where it's permissible, no license should be required like posting a message on an anonymous blog. Don't eat me alive here, it's a possible solution to solve a problem differently (instead of arming ourselves with anti-spam, anti-viruses, anti-malware etc. a game which never can be won). :-) Sure, that's a claim that is frequently made, albeit *only in PKI circles*. Really? That's what that whole CN is about. Some name that is fairly clear, and an implied CA claim that there really is only one Paypal in its list of certs, so you can rely that this is the one. There is one in San Jose, CA, USA. The claim is that of Paypal that they hold the trademark, there is a difference. Then there is the one between the end user and the website business. This might or might not be the one that is central in the dispute. Then there are other agreements that pop in and out in the normal course of business. Of course. There shall be no difference from when I walk into their shop or buy from the web site. Confirmations of CAs provide the verified information (like a Notary as I said earlier). CAs don't interfere in the handling of their respective businesses nor legal system. I think this is very clear. I have the feeling you are trying to create a problem where there isn't one and make something up which never was claimed. And there is no sand castle either... Yes, you are almost there. The purpose is to resolve a dispute. Duuuh? -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
On 11/11/2008 04:58 AM, Ian G: Yes, you are confirming and reinforcing his point: the dominant paridigm -- to push a concept of a binding of legal name to key -- is making it difficult for advocates of crypto to gain traction. It serves a purpose, it's not the only form in current applied PKI on the web. An email address or domain name is a valid binding too. We've said that already. One reason (there are many) is that there is no legal identity in existence, so efforts to push it run into invisible barriers. Your examples don't work, because many courts simply don't care so much about the name, only about the body: habeus corpus. The names in passports are not legally given as you suggest, they are just names in passports. E.g., over at CAcert there is a statistic that something like 1% of passports have errors in them; it is not a perfectly reliable document. That's because passports are evidence of citizenship, and the inclusion of a name there is more an attempt to narrow down frauds on citizenship; passports are not intended for other purposes, and they are not necessarily an accurate representation of any name of the person. IOW, the issuer doesn't care. Also, bear in mind that ones mother is a better authority on names than the government, generally, and all other things are derivative. And, different cultures do different things Granted, the name of an organisation registered at the creation authority is likely a better bet as to the name, but that is only when the registry is also the creation entity. Even then there are things like trading names, wholly owned companies, foreign registrations, multiple rights to the same trading name, etc, which are fine, legally, before the court, depending. The court is happy when it has the right guy, name or not. You can't even identify an entity uniquely by insisting on an ID number, as some countries don't issue numbers, and some issue more than one. Oh reallyI expect better from you! We all know what legal identities are, we aren't in the kindergarten anymore, right? There are enough reasons when a relying party needs to know which entity or identity he/she/it is. The authority is that of the respective, governing country. the courts system and legislative is that of the respective authority (governing country). I believe that you don't have any better alternative binding than the legal system set up by the respective authority! The purpose is to identify a person or company up to the extend that he/she/it can be found and charged if needed. I think that's about it... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Sorry, rushed reply! Eddy Nigg wrote: On 11/11/2008 04:58 AM, Ian G: Yes, you are confirming and reinforcing his point: the dominant paridigm -- to push a concept of a binding of legal name to key -- is making it difficult for advocates of crypto to gain traction. It serves a purpose, it's not the only form in current applied PKI on the web. An email address or domain name is a valid binding too. We've said that already. Right, so a binding of a claim in a cert can be one with many forms of data. Whether there is any better or lesser data is a question, in general the most popular things seem to be descriptive names or domain/email addresses. And, in particular, the PKI industry's obsession with some concept that you refer to as legal identity is ruining its own market. It's a fairly simple point he is making. One reason (there are many) is that there is no legal identity in existence, so efforts to push it run into invisible barriers. [snip] Oh reallyI expect better from you! We all know what legal identities are, we aren't in the kindergarten anymore, right? If we are, then it's he said, she said. If we are not, you can define this term of yours. :) There are enough reasons when a relying party needs to know which entity or identity he/she/it is. Sure, that's a claim that is frequently made, albeit *only in PKI circles*. That's what that whole CN is about. Some name that is fairly clear, and an implied CA claim that there really is only one Paypal in its list of certs, so you can rely that this is the one. (We don't need to go into that whole true-registered-name thing -- Inc/holding/state/... -- that can be done later, offline, if needed in a real dispute.) The authority is that of the respective, governing country. the courts system and legislative is that of the respective authority (governing country). I believe that you don't have any better alternative binding than the legal system set up by the respective authority! Sadly, this is not how it works. I guess you are talking about disputing something, right? The forum of dispute resolution is the one listed in the agreement. The choice of law is the one listed in the agreement. (I guess you are thinking of one of those two when you say authority ...) Next: there are probably multiple agreements. There is one between the CA and the end-user, which permits the end-user to be a relying party. E.g., as you have agreed to the Verisign RPA, you may look at the green bar on the Paypal website ;) Then there is the one between the end user and the website business. This might or might not be the one that is central in the dispute. Then there are other agreements that pop in and out in the normal course of business. Next: because we are assuming the net (we are, right?) there are often multiple jurisdictions involved. This might change the nature of the agreements; although businesses tend to prefer their own courts law and so forth, some laws and forums (authorities) don't like that, and may modify the forums and choices of law, as well as the contracts. There are also transaction costs, but let's not destroy the sandcastle before it is built. The purpose is to identify a person or company up to the extend that he/she/it can be found and charged if needed. I think that's about it... Yes, you are almost there. The purpose is to resolve a dispute. The rest may or may not follow. iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
On 09.11.2008, at 16:25, Ian G wrote: Eddy Nigg wrote: Now I'm interested in getting rid of self-signed certificates if possible. They undermine legitimate certificates and put the majority of users under an unneeded risk. That's one of my goals today! It seems that Eddy and Nelson are in the anti-self-signed-certs camp, and I would join Kyle in the pro-self-signed-certs camp. Do others have strong-enough feelings? I'm searching for a way here to show one side or the other which way the wind is blowing. I'm in the camp of giving the user an option to make her own trust decisions - be it self signed or CA certificates. And in the camp of tearing down the current business model of trust on the internet. Pre-made decisions which is the 'we decide which is best for you' in the form of 'trusted root certificates' and 'go away, you get killed' style dialogs on unknown root certs in Firefox are bad. For example, in Estonia we could choose to get a business registrar verified certificate for a web service that targets Estonian ID-card holders, so it could be a nice closed loop: national CA, national CA issued client certificates on the smart card, national CA issued and verified web server certificate. But we run with 20$ domain verified godaddy and see no difference and the key here is that our users see no difference either. They don't care if the address bar turns red or green or purple, if it doesn't nag then it's OK. In our case the decision to trust our system is based on other factors than the certificate. I believe that fixing broken PKI with EV certs and such is a dead end (yet a good money maker for some) and it has little to do with giving better trust decision making options to the end user. Currently there are two (generalized) options for an average joe: have no control over trust decisions made based on certificates (the ~50 pre-defined CAs in authority list built into firefox make the decision), or be scared the hell out with the 'add trust exception' (why not 'add explicit trust'). -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
On Tue, Nov 11, 2008 at 9:06 AM, Eddy Nigg [EMAIL PROTECTED] wrote: On 11/11/2008 03:54 PM, Ian G: And, in particular, the PKI industry's obsession with some concept that you refer to as legal identity is ruining its own market. I personally don't perceive it as such nor do I think that there is such an obsession. I *do* believe that more verified identities may be good for the Internet in general - which would allow to view unverified ones with a grain of suspicion. Or lets make some comparison to transportation, where one in order to drive a car must undergo some training and carry a license. I could imagine something similar applied to the Internet, where one carries a license in order to drive on the network. Anybody without a license can't drive along. I have absolutely no problem with verified identities -- what I do have a problem with is that public, general-purpose CAs limit the range of identities which can be verified. The 'legal identity' concept is the mechanism for using name and metadata associated with that name to refer to the entity in some context which nearly everyone can be referred to within, and thus can be used nearly universally to resolve disputes which relate to things which violate the law in some context. (The 'legal name' is the primary search key to be able to reference records associated with the 'legal identity'.) However... this identity is only truly useful when you're dealing with things that the law covers. I love the idea of comparing data transportation to physical transportation... except the analogy breaks down rather terribly for several reasons, not the least of which is that governments have allowed for licensure of individuals to be able to operate physically-dangerous machinery on governmentally-funded roads, and there is no such governmental licensure for individuals to exercise technologies used to share information. (In the US, such a licensing policy would be illegal under the Constitution as an unlawful prior restraint on free speech -- since speech is protected more than conduct when said conduct involves physical objects that can cause harm or death if they're mishandled.) One of the things that I want to see is the ability for individual communities to be able to assure identities in their own contexts -- their own usernames, their own primary keys to look up records associated with those identities (passwords, number of posts made, date of joining, etc). These records may not have any bearing outside the community that holds them, but they are still identities -- two individuals with identities in a community who meet each other in the flesh still share membership in at least one common community. Two individuals with identities in a community who bump into each other on IRC or such still share community membership. I'd like to be able to make knowledge of membership something that doesn't have to be broadcast or promiscuously offered. (TLS operates with the server identifying itself through presentation of a certificate as the first stage. Unless an ephemeral key agreement is used to negotiate unauthenticated encryption before the certificate presentation, the plain-text form of the certificate and thus all information therein is transmitted across an unencrypted channel, allowing for eavesdropping. IPsec is a bit different, in that the client must identify itself before the server chooses to create a security association -- and it must do this before it gets knowledge of the server's identity. Both identification models are useful in some circumstances, and useless in other circumstances.) However - and this might be interesting for the other camp - one doesn't stick the drivers license in bold letters onto the rear window for everybody to see, instead you've got license plates for the car. In some way, the driver remains anonymous to some extend. Applying this to the Internet, I'd know that you've got a license and I'd even know the number. I still don't know your personal details - which I could request from you if I wanted to. It would be known by an authority should need arise (in case of unlawful actions like malware distribution). Realistically, any certificate which is bound by a private party who was paid to bind the identity has a paper trail -- if nothing else, the method of payment. Regardless of any illusory feeling of safety provided by someone choosing to do the electronic equivalent of branding of their software (like they would brand their cattle), the fact is that the user is the one who makes the decision to run it. This would be the equivalent of taking a cow that was already branded home. Regardless of whether the cow is rabid or cantankerous or the sweetest, most lovable creature in the world. There is another mischaracterization in your statement. In the currently-dominant X.509 paradigm combined with the application of TLS, anyone who runs a server (their vehicle) must hang their
Re: MITM in the wild
Eddy Nigg wrote: On 11/11/2008 03:54 PM, Ian G: And, in particular, the PKI industry's obsession with some concept that you refer to as legal identity is ruining its own market. I personally don't perceive it as such nor do I think that there is such an obsession. I *do* believe that more verified identities may be good for the Internet in general - which would allow to view unverified ones with a grain of suspicion. eBay users seems to survive without them? Or lets make some comparison to transportation, where one in order to drive a car must undergo some training and carry a license. I could imagine something similar applied to the Internet, where one carries a license in order to drive on the network. Anybody without a license can't drive along. Sure. This is nothing to do with *identity* tho, all it has to do with is ones tested ability to drive safely. Try this thought experiment: would a driver's licence without a name on it, but with a photo on it, work as well? However - and this might be interesting for the other camp - one doesn't stick the drivers license in bold letters onto the rear window for everybody to see, instead you've got license plates for the car. In some way, the driver remains anonymous to some extend. Applying this to the Internet, I'd know that you've got a license and I'd even know the number. I still don't know your personal details - which I could request from you if I wanted to. It would be known by an authority should need arise (in case of unlawful actions like malware distribution). Right, certs without names or with nicknames achieve that. It might not be possible to see the name, but seeing the issuer is sufficient to say something. If a trail is all that is required, this can simplify things a lot. Now of course this is some form of reducing the freedom of the individual, but on the other hand would bring some piece of mind (with malware and fraud removed, children clearly protected and so forth). Similar to the transportation system where not every individual can do as he likes. Well, except there isn't much in the way of use cases. On the roads, bad drivers keep bumping into each other. When enough innocents have been slaughtered, we demand licensing and testing. On the net, bad users keep destroying their own email. I don't think we need to licence people to destroy their own email... yet... because they seem to have a limitless fountain of it. Sure, that's a claim that is frequently made, albeit *only in PKI circles*. Really? OK, you're right, it is also frequently made in press articles :) That's what that whole CN is about. Some name that is fairly clear, and an implied CA claim that there really is only one Paypal in its list of certs, so you can rely that this is the one. There is one in San Jose, CA, USA. The claim is that of Paypal that they hold the trademark, there is a difference. Sure. Trademarks are actually divided by sector, so one can be Apple and another can be Apple. They have courts for these things; as long as the two companies do not compete in some area (like Apple :) ) then there is no issue. So the thing above would be to make sure that each site for Apple identified which one it really was. Asking the CA to get into branding is a little fraught. (Although I frequently suggest it in another context). What is a CA going to do about this? So far, a CN still covers it: Apple Records as opposed to Apple Computers. Then there is the one between the end user and the website business. This might or might not be the one that is central in the dispute. Then there are other agreements that pop in and out in the normal course of business. Of course. There shall be no difference from when I walk into their shop or buy from the web site. Ah, but there is, that is the point. Confirmations of CAs provide the verified information (like a Notary as I said earlier). CAs don't interfere in the handling of their respective businesses nor legal system. I think this is very clear. The point is: do CAs require this so-called legal identity? If so, why? Let's call it for sake of discussion a privacy issue. If so, then it should not be required unless needed. In privacy, we have to establish a compelling need for the info; or we have to stop keeping it. If the answer is, so relying party can take the subscriber to court, then we have a problem: it won't work that easily, indeed it is bordering on useless, because the more borders we cross, the more the transaction costs go up. I have the feeling you are trying to create a problem where there isn't one and make something up which never was claimed. And there is no sand castle either... Nope, just eliminating an assumption or two: identity required for court. Once these are eliminated, life becomes much easier. Yes, you are almost there. The purpose is to resolve a dispute.
Re: MITM in the wild
Eddy Nigg wrote: On 11/10/2008 02:11 AM, Kyle Hamilton: On Sun, Nov 9, 2008 at 7:26 AM, Eddy Nigg[EMAIL PROTECTED] wrote: Since there's a fairly argumentative tone going on, I think I should explain what my viewpoint is: Kyle, your reply was highly interesting! Nevertheless I'll cut down my response to a few highlights only... (after writing my reply I realized that's more than expected). I also find myself unaccustomed to dealing with other people's long replies ;) But this point struck me: 10) However, the dominant paradigm of cryptographically binding an identity to a key (but only as long as the identity that's bound is the legal identity) makes it difficult for advocates of cryptography to gain any traction in those environments. [EMAIL PROTECTED] is hardly a legal identity... That's because there is no such thing as a legal identity. (If you think this is wrong then please provide a definition on same, preferably one that is useful for us.) By trying to appear 'legitimate' the authority which you created falls into the same problems which plague every other authority. I don't sense the problem really. Legitimacy is 99% marketing. If the 99% believe you are legit, then you are. If not, then not. (If you need to ask what the other 1% is, you're in trouble.) iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DNSSEC? Re: MITM in the wild
Anders Rundgren wrote: I haven't followed this lengthy discussion in detail but I have for a long time wondered how DNSSEC and SSL-CA-Certs should coexist. Which one will be the most authoritative? Could DNSSEC (if it finally succeeds) be the end of SSL-CA-certs? DNSSEC only attempts to ensure that you get the (a) correct IP address. It does absolutely nothing to ensure that you actually are connected to the site you wanted. It doesn't obviate SSL or PKI at all. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DNSSEC? Re: MITM in the wild
On 11/10/2008 09:52 PM, Nelson Bolyard: Anders Rundgren wrote: I haven't followed this lengthy discussion in detail but I have for a long time wondered how DNSSEC and SSL-CA-Certs should coexist. Which one will be the most authoritative? Could DNSSEC (if it finally succeeds) be the end of SSL-CA-certs? DNSSEC only attempts to ensure that you get the (a) correct IP address. It does absolutely nothing to ensure that you actually are connected to the site you wanted. It doesn't obviate SSL or PKI at all. I believe it would only strengthen domain and email validation procedures as the CA has means to verify DNS response better. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DNSSEC? Re: MITM in the wild
Nelson Bolyard wrote: I haven't followed this lengthy discussion in detail but I have for a long time wondered how DNSSEC and SSL-CA-Certs should coexist. Which one will be the most authoritative? Could DNSSEC (if it finally succeeds) be the end of SSL-CA-certs? DNSSEC only attempts to ensure that you get the (a) correct IP address. It does absolutely nothing to ensure that you actually are connected to the site you wanted. It doesn't obviate SSL or PKI at all. Is DNSSEC secure enough to make the statement DNS name www.example.com is signed by CA with fingerprint ABCD? If so, a website can publish the expected CA that signed the cert for that website, giving an out of band method to confirm whether the cert presented to the client is legitimate or not. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
RE: DNSSEC? Re: MITM in the wild
DNSSEC is an assertion of validitity of the DNS. EV certs assert that the business behind the cert is legit. Certs regardless of the class enables encryption. Thus DNSSEC would, in theory, prevent a cert from being stolen. So rather than replacing, or weakening CAs and PKI, it would enhance reliability, and close the threat of a blended (and undetectable) attack of a compromised cert and pharming. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anders Rundgren Sent: Monday, November 10, 2008 1:25 AM To: mozilla's crypto code discussion list Subject: DNSSEC? Re: MITM in the wild I haven't followed this lengthy discussion in detail but I have for a long time wondered how DNSSEC and SSL-CA-Certs should coexist. Which one will be the most authoritative? Could DNSSEC (if it finally succeeds) be the end of SSL-CA-certs? Anders ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DNSSEC? Re: MITM in the wild
At 11:52 AM -0800 11/10/08, Nelson Bolyard wrote: DNSSEC only attempts to ensure that you get the (a) correct IP address. s/only/only currently/ You can stick any data you want in the DNS. Currently the most popular data is the A record (IP address) associated with a domain name, but is it quite possible to put other data associated with a domain name in the DNS as well. DNSSEC cryptographically protects any type of DNS data, including assertions that a DNS name is associated with a public key. There are strong pros and strong cons of using the DNS as a reliable public key association mechanism. This has been discussed ad nauseam for over a decade by the people designing the DNS. Here's just one of many problems: there is no way for a browser to know whether the public key data it is getting from the DNS is signed by DNSSEC, much less validated all the way to a trust anchor. Whoopsie. DNS folks often have their religious views even more entrenched than security folks. There is no strong consensus in the DNS community on this topic. Saying it can be done is quite different than saying it should be done. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Eddy Nigg wrote: On 11/10/2008 04:31 PM, Ian G: Eddy Nigg wrote: [EMAIL PROTECTED] is hardly a legal identity... That's because there is no such thing as a legal identity. I think he meant with legal your legally given name as listed in your passport for example or an organization as registered and authorized to perform trade in the respective country. Yes, you are confirming and reinforcing his point: the dominant paridigm -- to push a concept of a binding of legal name to key -- is making it difficult for advocates of crypto to gain traction. One reason (there are many) is that there is no legal identity in existence, so efforts to push it run into invisible barriers. Your examples don't work, because many courts simply don't care so much about the name, only about the body: habeus corpus. The names in passports are not legally given as you suggest, they are just names in passports. E.g., over at CAcert there is a statistic that something like 1% of passports have errors in them; it is not a perfectly reliable document. That's because passports are evidence of citizenship, and the inclusion of a name there is more an attempt to narrow down frauds on citizenship; passports are not intended for other purposes, and they are not necessarily an accurate representation of any name of the person. IOW, the issuer doesn't care. Also, bear in mind that ones mother is a better authority on names than the government, generally, and all other things are derivative. And, different cultures do different things Granted, the name of an organisation registered at the creation authority is likely a better bet as to the name, but that is only when the registry is also the creation entity. Even then there are things like trading names, wholly owned companies, foreign registrations, multiple rights to the same trading name, etc, which are fine, legally, before the court, depending. The court is happy when it has the right guy, name or not. You can't even identify an entity uniquely by insisting on an ID number, as some countries don't issue numbers, and some issue more than one. Naming is not an exact science. There is no one true name :) By trying to appear 'legitimate' the authority which you created falls into the same problems which plague every other authority. I don't sense the problem really. Legitimacy is 99% marketing. If the 99% believe you are legit, then you are. If not, then not. I don't agree. Legitimate in the way I use it usually it means legitimate from the software vendor point of view. Legitimate may be also in the point of view of a country and their legal system. It may be even legitimate in the point of view of the user (as you call it marketing), however in the context we discuss it here usually it's certainly the browser. Legitimate is what we call a loaded term. It is used to push a certain viewpoint without inviting serious analysis, that is, where the analysis would reveal obvious flaws. Consider it this way. Say we are deciding whether police are to carry weapons or not (something that is debated in many countries). We conduct a survey that asks [1]: Do you believe that police should carry guns for legitimate uses? The obvious answer is YES because of the loaded term. You can't disagree because the alternate is to say that even for legitimate purposes, police shouldn't carry guns. An alternate reverse-loaded question would be: Do you believe that police should carry guns, even if we know that 99% of our police never need them? Just as loaded, and easier to spot. Any time the word legitimate is used, the red flags should go up! It should be clear from the above that there is no inherent legitimacy in what you describe, and only a hope that we don't question your term. (If you need to ask what the other 1% is, you're in trouble.) LOL iang [1] this was an actual survey conducted by the NY police. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
On 11/09/2008 08:38 AM, Kyle Hamilton: Because you're assuming that everything that occurs in this world exists in a corporate environment, Eddy. Well, I didn't meant only the corporate, but also any hobbyist geek. Those are, which lament against PKI in general and promote self-signed certs. I don't care who you are, what interests you represent -- I represent the interests of anybody seeking a secure Internet and better reliance and productivity. I personally invested time and money to provide the services StartCom does and the way it does, mainly because I realized that an alternative to the established CAs must be offered in order to improve overall security and reliability. The StartCom CA wasn't established with the goal to further facilitate the establishment and their cause, but to provide an alternative. Just as a reminder, in 2004/5 digital certificates weren't so cheaply available as today... Now I'm interested in getting rid of self-signed certificates if possible. They undermine legitimate certificates and put the majority of users under an unneeded risk. That's one of my goals today! Do you really think that I or anyone else am going to be willing to limit our behavior to those things which an entity which isn't even a government is willing to assign authority for? Browser vendors effectively govern CAs and with it all digital certificates. It's a fact and it's in their hand what they do with it. I recognized that power very early and planned accordingly. You can bang your head against a wall - it won't help. Personally I feel that they do it quite right and have reasonable requirements - first and foremost Mozilla. (And since it's as easy to generate a client certificate which is signed by the user's self-signed CA certificate, you can't simply say that you would let any certificate that wasn't signed by itself have something of a pass in the trust evaluation -- it would chain to an unknown root, which would present the same issue as a self-signed root.) No! It's much better than that, because it requires you to explicitly ask the user to trust the CA root. This way users can self-organize their own networks as you requested earlier. Anybody willing to trust you or any other CA can install the root, benefit from your decisions and procedures and you even have the ability to revoke issued certificates. No UI will prevent the install of the root and no error screen will appear thereafter. And that's much better than having to trust a self-signed certificate on-the-fly because somebody got directed to a certain URL. BTW, the only certificates which should be self-signed should be roots, as you quite well know - that's how PKI is implemented. And roots shouldn't be used to secure web sites or to sign email's. Actually it would also show something about the least capabilities of the issuer of the cert... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Eddy Nigg wrote: Now I'm interested in getting rid of self-signed certificates if possible. They undermine legitimate certificates and put the majority of users under an unneeded risk. That's one of my goals today! Well, all the arguments have been heard on this already, and positions are fairly entrenched. It seems futile to have the debate over and over, and I for one would like to point out that it is uncomfortable to treat it like a political campaign. Perhaps a vote? It seems that Eddy and Nelson are in the anti-self-signed-certs camp, and I would join Kyle in the pro-self-signed-certs camp. Do others have strong-enough feelings? I'm searching for a way here to show one side or the other which way the wind is blowing. iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
On 11/09/2008 04:25 PM, Ian G: Well, all the arguments have been heard on this already, and positions are fairly entrenched. It seems futile to have the debate over and over, and I for one would like to point out that it is uncomfortable to treat it like a political campaign. Well, Kyle stated that he doesn't care who I am nor which interests I represent. This was a short statement about what I did and which interests I represent (including obviously my personal preference) :-) Perhaps I should have added, that I'm coming from the same grass-root camp as Kyle and others. WE have/had some very similar goals... however I actually did something in order to establish an alternative. I was the thriving force behind the establishing of a legitimate authority where the commercial aspects aren't the primary goal and where certification isn't bound to the financial capabilities of the subscriber. For some reason, advocates like Kyle are opponents to us today and needless to mention that the hard-core CAcert crowd isn't happy with what we do and achieved either - first we were ignored, then publicly laughed at, then publicly decried. Go figure... Today I'm afraid that for those I don't have much sympathy left either and continue to serve those who appreciate it. Perhaps a vote? Vote on what? It's a process which has started a while ago. It's usually not discussed here, but by the UI designers and other forums. It seems that Eddy and Nelson are in the anti-self-signed-certs camp, and I would join Kyle in the pro-self-signed-certs camp. I think that's way too simple... Do others have strong-enough feelings? I'm searching for a way here to show one side or the other which way the wind is blowing. You don't have to search a lotjust visit Paypal and look at your browser. That's the way the wind is blowing. And if regular certificates are further circumvented and devalued, this is what you'll be left with in the end. Think about it! -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
On Sun, Nov 9, 2008 at 7:26 AM, Eddy Nigg [EMAIL PROTECTED] wrote: On 11/09/2008 04:25 PM, Ian G: Well, all the arguments have been heard on this already, and positions are fairly entrenched. It seems futile to have the debate over and over, and I for one would like to point out that it is uncomfortable to treat it like a political campaign. Well, Kyle stated that he doesn't care who I am nor which interests I represent. This was a short statement about what I did and which interests I represent (including obviously my personal preference) :-) Since there's a fairly argumentative tone going on, I think I should explain what my viewpoint is: 0) First and foremost, I'm a citizen and resident of the United States of America, educated in the public school system in the 1980s to early 1990s. This means that I was brought up with a particular set of beliefs (most notably that only governmental authority is proscriptive, and there is no generally-applicable prescriptive authority). This colors every value judgement that I make, most importantly the following... 1) I believe that users who own their own machines are sovereign. The USER, not the CA, is the root of all trust on that user's machine. (Families are different, but only in that the actual owner of the machine -- usually a parent -- is the root of all trust for the kids who use it. There are many rights which corporations have that family owners don't, including the right to capture and log keystroke, video output, audio output, and network activity on the machine.) 2) I believe that CAs which have been audited against their CPs and CPSes have a severe disincentive against making new types of certificates available. 3) I believe that CAs which have been audited against their CPs and CPSes have a severe disincentive against binding different types of identities (other than legal identity) to public keys. The reason for this is that CAs must adhere to their CPs, and thus far none of them have brought any expression of non-legal identities (this is different from 'illegal identities', which include identities that people take on for the purpose of defrauding another or any identity used for an illegal purpose) into their certificate policies. 4) I believe that CAs which have been audited against their CPs and CPSes have a severe disincentive against placing user-requested extensions in their certificates, because these extensions can mean anything and be interpreted as anything. 5) I believe the disincentive against placing user-requested extensions in certificates reduces the incentive for general-purpose PKIX clients to properly handle arbitrary extensions -- the information doesn't exist, so there's no implementation thereof. If there's no implementation thereof, there's no pressure to provide the implementation. 6) I believe that the USA has a chartered requirement to not infringe on anyone's right of free association. (Among other things, a person can associate with gays -- and one of the more deeply-held beliefs in the gay community is that if you know that someone's gay, you do not under any circumstances make that group membership known -- it is the individual's decision when (or if) to come out of the closet, i.e. make their own group membership known. I have other examples to suggest that this is an appropriate view to take, but I cannot express them without betraying my own associations in ways that I wish not to.) 7) Because of #1, I believe that users have the right to use their computers as tools they can work in any manner, for communications they wish to share in any manner, and with pseudonyms as they may require or desire -- not simply with the de facto legal identity information embedded in ways that CAs currently require. Also because of #1, I believe that assigning ultimate trust to any CA that is not run according to the need of the user is a violation of the user's sovereignity. 8) in light of #2, 3, 4, and 5, I conclude that trying to get any audited CA to embed a non-legal identity or group-membership extension is pointless. 9) in light of the interactions between #3 and 6, and the conclusion in #8, I conclude that using the current CAs for anything outside of the top-down, hierarchal, legal-identity declaration that they currently are is pointless. 10) I believe that there are many, many applications that would benefit from the application of cryptography. However, the dominant paradigm of cryptographically binding an identity to a key (but only as long as the identity that's bound is the legal identity) makes it difficult for advocates of cryptography to gain any traction in those environments. In addition, regarding your desire to do away with self-signed certificates as website identification... unfortunately, I can't see a way within a strict reading of X.509 to do that. I do believe it would be good practice, but it just seems to be... well, dogmatically prohibited. As far as I've been able to figure
Re: MITM in the wild
Well, all the arguments have been heard on this already, and positions are fairly entrenched. It seems futile to have the debate over and over, and I for one would like to point out that it is uncomfortable to treat it like a political campaign. Perhaps a vote? Not for me, but perhaps a design competition. It seems that Eddy and Nelson are in the anti-self-signed-certs camp, and I would join Kyle in the pro-self-signed-certs camp. Do others have strong-enough feelings? I would like to see self-signed certs allowed, but not in the way that they have been in the past, and not with the UI they are now. My design would be: a) Firefox keep track of every TLS site you have ever visited. If they ever have used an externally trusted cert, they can never use a self-signed cert. Never here means that there is no way in the UI to get to the site over HTTPS after a backwards transition: you get a long error message, but not a choice. b) Mozilla keeps track of every TLS site known to have used an externally trusted cert. It does this by its own probes, possibly with help from its friends like Google or the CAs. This information is optionally used in the calculation from (a), with the default being to use it. c) When you first get to a site that is self-signed that does not trigger a failure above, you get an informational (not scary) explanation of what is going on; this message has the SHA-256 fingerprint of the public key. You are told that you can go there just this once, or you can have Firefox remember this self-signed cert. If the site had a previously-memorized self-signed cert that is different than the one now, you get a different warning explaining the situation that asks if you are sure that the site has changed its self-signed cert; this message is half-ominous, but clickable through. This system works without (b), but works much more safely with it. Using such a system, all other cert errors can now have more useful warnings that will not be confused with those for sights that self-sign. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
On 11/10/2008 02:11 AM, Kyle Hamilton: On Sun, Nov 9, 2008 at 7:26 AM, Eddy Nigg[EMAIL PROTECTED] wrote: Since there's a fairly argumentative tone going on, I think I should explain what my viewpoint is: Kyle, your reply was highly interesting! Nevertheless I'll cut down my response to a few highlights only... (after writing my reply I realized that's more than expected). 1) I believe that users who own their own machines are sovereign. The USER, not the CA, is the root of all trust on that user's machine. In principal I agree with this statement and I believe this is in fact the case. 2) I believe that CAs which have been audited against their CPs and CPSes have a severe disincentive against making new types of certificates available I agree with most if not all points up to here... 6) I believe that the USA has a chartered requirement to not infringe on anyone's right of free association. I don't think that anything prevents you from doing so. 7) Because of #1, I believe that users have the right to use their computers as tools they can work in any manner, for communications they wish to share in any manner, and with pseudonyms as they may require or desire -- not simply with the de facto legal identity information embedded in ways that CAs currently require. Also because of #1, I believe that assigning ultimate trust to any CA that is not run according to the need of the user is a violation of the user's sovereignity. You have the freedom to embed your own CA, remove existing CAs etc. Nobody violates the users sovereignty if he cares. Also ways exists (mainly domain/email validated certificates) without really having to disclose who you are publicly. However the same right also exists for the software vendor who has the freedom to decide what's in the best interest of the average user. Also its own interests are legitimate up to a certain extend (depending on the position in the market and other factors). 10) However, the dominant paradigm of cryptographically binding an identity to a key (but only as long as the identity that's bound is the legal identity) makes it difficult for advocates of cryptography to gain any traction in those environments. [EMAIL PROTECTED] is hardly a legal identity... By trying to appear 'legitimate' the authority which you created falls into the same problems which plague every other authority. I don't sense the problem really. As well, since the 'authority' that you run does not issue the credentials which can be used to authenticate a legal identity, your 'authority' is not 'authoritative'. Doesn't this depend on the type of verification done? I agree that CAs resemble much more a Notary Public than the authority governing the real legal identities. but a general-purpose certificate issuer is only authoritative on 'the entities which have chosen to request issuance of a certificate from it' Obviously. Nobody forces anybody into it. What I do have issue with, though, is that you seem to think that the service you created is a panacea No it's not. As I stated - besides being legitimate and similar - we provide an alternative and remove the financial barrier. This is a big hurdle for many still which prevents adoption by the masses of (legitimate) digital certificates (not the only one, but one of them - ease of use is another one). that the concept of monetary exchange is the only thing which prevents people from using the services of the general-purpose CAs. It's not. Of course not. But I can't serve you otherwise. But we should recognize that the context we are discussing here is hundreds of millions of users (of the browser), potentially millions of web sites, a handful of CAs and a few browsers. There are various goals we try to achieve with PKI, starting from preventing eavesdropping, reliance (mainly for business purpose?), prevent fraud (phishing) if possible etc. In this context, PKI makes a lot of sense...it may not for your (other) alternative networks, affiliations and software. (Among other things, you issue end-user certificates, which cannot themselves issue other certificates. Of course not. Would be the same as self-authorized. This means that a user cannot use the certificate you issue to issue certificates to his router, his PC, to his friends, to any services that he chooses to run -- all he can issue are proxy certificates, which cannot be used for identity; they can only be used for delegation of the permission that an end-user certificate has. Since end-user certificates cannot be used to identify servers, the end-user still has an artificial barrier to entry if he wants to, say, protect his home network with ipsec.) Mmmhh...can you explain that again? Get the right certificate for the right purpose then...nothing prevents you from doing that. and the fact that there is no centrally-searchable database is what allows for certificates to be mis-issued by
DNSSEC? Re: MITM in the wild
I haven't followed this lengthy discussion in detail but I have for a long time wondered how DNSSEC and SSL-CA-Certs should coexist. Which one will be the most authoritative? Could DNSSEC (if it finally succeeds) be the end of SSL-CA-certs? Anders ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Kyle Hamilton wrote: The basic idea for querying this would be as follows: hash the Subject and each/all SANs in the certificate, and query for that hash (perhaps to a web service). If there's a match, Would I as an attacker use a perfect Subject / SAN that would leave itself easily matchable by software? ensure it's signed by a CA in the default db; Does this mean, on examining each cert, we would have to go to each CA to see if it records that Subject / SANs ? if it isn't, conclude that it's an MITM. If there isn't a match, pop up a small notification (like the 'Firefox has blocked this download' notification) that Firefox can't authenticate the certificate, and they proceed at their own risk. (If they add the certificate to their store, the notification can say You've manually accepted the certificate for this site, Firefox didn't do it automatically?) Yes, certs that the user has accepted should be shown differently. They have a different trust chain. I would have no problem with changing the chrome when people step outside of the assurances that Firefox tries to provide. I /do/ have a problem with removing the ability for users to try to self-organize their own networks. (The threat model is different, the policies are different, and the fact that everyone on this list is talking about removing the ability for self-signed roots to be used at all is an extremely counterproductive and cartel-supporting view.) I don't think it is everyone although there is a loud minority against self-signed certs. As far as I can see, there is no consensus to drop them from Firefox, and my understanding is that Firefox is still planning to enhance the KCM in future generations. Also, Firefox isn't discussed on this group, this is dev-tech-crypto. (I could be wrong, but I'm not a developer so there is not a lot I can do about it ... either being wrong or doing the code :) ). iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
On 11/08/2008 10:50 PM, Kyle Hamilton: I would have no problem with changing the chrome when people step outside of the assurances that Firefox tries to provide. I /do/ have a problem with removing the ability for users to try to self-organize their own networks. (The threat model is different, the policies are different, and the fact that everyone on this list is talking about removing the ability for self-signed roots to be used at all is an extremely counterproductive and cartel-supporting view.) Kyle, why don't you do that the proper way, specially for corporate networks? Creating a root and distributing the root is the proper way to go, not some lousy self-signed crap you never ever will verify anyway. I'm not against somebody being his own CA - not wanting to depend on others, but I'm against risking others by their actions. I think by creating your own root and by distributing it throughout your network and affected circles, you provide a certain protection level self-signed can't. You may even issue CRLs. Others which encounter a site without having imported the root (currently) still can accept the cert. There is open source software out there which provide excellent support for setting up a corporate CA which requires minimum effort. I suggest to enable users self-organize their own networks correctly, mitigating even their own risks! Think about it... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
On 11/07/2008 05:18 AM, Kyle Hamilton: So, essentially, what you're saying is that it was a targeted attack against a user, instead of an attack targeted against a server? What is an attack targeted against a server in the context of browsers and MITMs? -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
If we create an error display that says No kidding, this absolutely is an attack and we're stopping you cold to protect you from it. it seems unavoidable that users will learn to treat the absence of such an unbypassable error display as proof to the contrary, proof that the site is genuine and verified. Do we want to train them that way? I don't think that this is an issue. I believe most users likely never see a MITM attack in their browsing carer - indeed this rarity of real MITM attacks is the reason why real attacks are interpreted as false positives, it's just the most likely explanation for a cert error screen. If a MITM detection service could be designed that gave no false negatives, most users would never see it, so would not learn to associate the existing cert error screen with an all clear. I have no idea if MITM attacks are generally targeted at users, as in the case of this thread, or against servers. If MITM attackls are targeted at servers, I accept that there is very little that Firefox can do to stop this. If the attack is targeting a user, surely there is an opportunity for Firefox to help the user realise that they are being MITM'd? This could be a sustained attack, lasting days or weeks, slowly collecting all of the user's passwords. The idea of it makes me shudder! Any solution will be an imperfect trade-off, but is it really the consensus that there's no better trade- off than the current situation? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Eddy Nigg wrote: On 11/07/2008 05:18 AM, Kyle Hamilton: So, essentially, what you're saying is that it was a targeted attack against a user, instead of an attack targeted against a server? What is an attack targeted against a server in the context of browsers and MITMs? Possibly, it is much closer to the user, so one user gets the full effect, across all her services. As opposed to being much closer to the server, so one server gets the full effect, across all its users. Using the word targetting is possibly a stretch :) iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Bernie Sumption wrote: Graham, Nelson, Eddy, you all make good points. I'll take your word for it that it's impossible to detect MITM attacks with 100% reliability, as I said I'm not a security expert. How about an MITM detection service that gives no false positives, but might give false negatives? If you positively identify an MITM attack, you can present users with a much more definite UI saying this *is* an MITM attack and giving advice about what to do in the event of an MITM. This is what we have now, sort of. It detects any certificate MITMs. It also treats any misconfigurations or use of non-CA certs as potential attacks. It pretty much picks up all real cert-based attacks on the browser. The problem here is that the real MITMs are almost non-existent, the false negatives are routine, and there is no real way to tell the difference. What then is displayed is (generally) not an attack, the users known (generall) that it is not an attack, so the users believe the display to be wrong (fairly). Click-thru syndrome. This part is well known. What is less easy is what to do about it. It all depends on ones commercial or structural or security viewpoint. What is clear is that there are no easy answers. Solution A will offend group X, solution B will offend group Y, etc. The only solution that seems not to be offensive is to do much more TLS so that much more attention can be fixed on the problem. Attention at all levels: user, developer, LAMPs, ... But, this is currently blocked by two factors: the absence of TLS/SNI in servers, and the difficulty of getting certs into servers. Both situations are slowly getting better, but aren't really the subject of here. (I'm talking high level here. Please don't respond with the normal self-serving low level message.) I'm not talking about fixing all the problems for all the users, just a real improvement for a proportion of users. For example, can one give site owners a way of specifying that their domain must not be accessed if it presents a self-signed certificate. Paypal.com would no doubt take this option, as would any large bank. If the method is made easy enough, so might other sites like facebook. Yes, this is the solution known hereabouts as Key Continuity Management. (With a twist.) Two possible methods that don't require a detection service (mitm.mozilla.org) might be a DNS record (doesn't work if the attacker has compromised DNS) or a subdomain naming convention (i.e. secure.example.com requires a valid certificate - presents adoption issues for existing sites). This would likely have stopped the original bug poster from revealing her password. Easily defeated with secure2.example.com ? The problem with technical solutions (only) is that the attack is not at the technical level, it is at the interface between the tech and the human. Adi Shamir puts it well in his 3rd law: Cryptography is typically bypassed, not penetrated. The corollary to this is that it is typically wrong to improve the crypto. E.g., think about all the efforts to move from 40bits to 256bits ... Security Architecture is about expanding the security model, and integrating the human into it, not improving the bits bobs. Introducing a new screen that has a far lower rate of false positives seems a reasonable thing to try. Yes, but that is fundamentally impossible without a massive increase in the number of actual MITMs (won't happen for many and various reasons) or a massive decrease in the number of other cert errors (won't happen for many various reasons). As far as the false positives versus false negatives is concerned, we are fundamentally stuck with the current balance. Although, I agree with one point. The screen should analyse the self-signed cert and show it is self-signed. It is easy enough to say look, Mate, this would never be done on a big ecommerce site or a bank, but it might be done on a hobbyist or sysadm site. iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Bernie Sumption wrote: If we create an error display that says No kidding, this absolutely is an attack and we're stopping you cold to protect you from it. it seems unavoidable that users will learn to treat the absence of such an unbypassable error display as proof to the contrary, proof that the site is genuine and verified. Do we want to train them that way? I don't think that this is an issue. I believe most users likely never see a MITM attack in their browsing carer - indeed this rarity of real MITM attacks is the reason why real attacks are interpreted as false positives, it's just the most likely explanation for a cert error screen. Yes. If a MITM detection service could be designed that gave no false negatives, most users would never see it, so would not learn to associate the existing cert error screen with an all clear. It is kind of plausible to design any service that does something and there are a few examples. But there are difficulties. Firstly, the existing service already promises it, so what went wrong, and what will happen when you bypass it? Are we breaking the existing service? Are we just adding in more complications? Secondly, recall Adi's 3rd law: the attacker typically bypasses. This means that any service has to consider whether it is trivially bypassed, and/or whether there are better attacks outside its boundary already. The answer at this level is probably, yes, c.f., phishing. At which point, it then becomes less valuable, even if it is right technically, and it is likely to become more costly than the benefits it delivers. See above. Thirdly, there isn't really any hope of no false negatives ... because the service isn't really close enough to the two players to be absolutely sure. It can only create that absolutism by mandating that everyone believes its viewpoint, which is a trick that isn't easy to pull off, and is wrong. I have no idea if MITM attacks are generally targeted at users, as in the case of this thread, or against servers. We have too little data to answer that. In this case, it was a wireless attack. In the past, we have predicted that wireless would lead to an increase in MITMs of this nature, but we were wrong, there are still only isolated cases. These MITMs are just too rare. (Why that is, and what to do about it are interesting questions...) But the fact is, real anti-cert MITMs are too rare. If MITM attackls are targeted at servers, I accept that there is very little that Firefox can do to stop this. If the attack is targeting a user, surely there is an opportunity for Firefox to help the user realise that they are being MITM'd? This could be a sustained attack, lasting days or weeks, slowly collecting all of the user's passwords. The idea of it makes me shudder! LOL... Did someone tell you that browsing was safe? Any solution will be an imperfect trade-off, but is it really the consensus that there's no better trade- off than the current situation? No. There is no consensus. There are opposing camps. One camp believes that the solution is to drop all self-signed certs. Another camp believes that Key Continuity Management is the answer. Yet a third camp believes that user training has to be done, and the UI needs a little tweaking, is all. A fourth camp has written off SSL / secure browsing as irrepairably flawed. A fifth camp believes that only protocol bugs and the number of bits is security, the rest is outside purview. A sixth camp believes this is not a technical issue at all, and will be solved by the lawyers. If we look over the hill, we'll see other camps, hear much muttering, and in the end, we all return to our cups and mutter on... There is no consensus! Sorry about that... you want a cup of wine with your muttering? :) iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Bernie Sumption wrote: If we create an error display that says No kidding, this absolutely is an attack and we're stopping you cold to protect you from it. it seems unavoidable that users will learn to treat the absence of such an unbypassable error display as proof to the contrary, proof that the site is genuine and verified. Do we want to train them that way? I don't think that this is an issue. I believe most users likely never see a MITM attack in their browsing carer - indeed this rarity of real MITM attacks is the reason why real attacks are interpreted as false positives, it's just the most likely explanation for a cert error screen. I think this has been historically true... even though we know there are holes in DNS, the ability to generally exploit those holes have been difficult. That is no longer the case in the wireless world. The NSS team has been worried about this kind of attack for a while, which is why we pushed for changes in the UI. In some sense the bug report we saw spoke to a partial success. The UI was annoying enough the user wrote a bug about the problem, allowing the user to find out that they were potentially hacked. With our old UI, the user would have dismissed the warning dialog and proceeded. We know from experience users train themselves to dismiss those dialogs without even seeing them. In that case no bug would have been written up. Where the new UI failed was the user was able to proceed without the sophistication needed to evaluate that she was being attacked. These attacks are easy to produce, and with a large number of mobile, wireless devices out there (including laptops), potentially profitable. I think if we don't take steps to protect the user, like was done in FF 3, the rate of these attacks will likely increase. bob smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Iang wrote, On 2008-11-07 08:22: Bernie Sumption wrote: How about an MITM detection service that gives no false positives, but might give false negatives? If you positively identify an MITM attack, you can present users with a much more definite UI saying this *is* an MITM attack and giving advice about what to do in the event of an MITM. This is what we have now, sort of. It detects any certificate MITMs. It also treats any misconfigurations or use of non-CA certs as potential attacks. It pretty much picks up all real cert-based attacks on the browser. The problem here is that the real MITMs are almost non-existent, the false negatives are routine, and there is no real way to tell the difference. What then is displayed is (generally) not an attack, the users known (generall) that it is not an attack, so the users believe the display to be wrong (fairly). Click-thru syndrome. This part is well known. What is less easy is what to do about it. It all depends on ones commercial or structural or security viewpoint. What is clear is that there are no easy answers. Solution A will offend group X, solution B will offend group Y, etc. The only solution that seems not to be offensive is to do much more TLS so that much more attention can be fixed on the problem. Attention at all levels: user, developer, LAMPs, ... But, this is currently blocked by two factors: the absence of TLS/SNI in servers, and the difficulty of getting certs into servers. Both situations are slowly getting better, but aren't really the subject of here. (I'm talking high level here. Please don't respond with the normal self-serving low level message.) Ian, I agree with all that you wrote, quoted above. I will add that, while MITMs have historically been very rare, they are on the upswing. I see two broad areas where MITM attacks are on the increase, and they're both directed at the user, not the server. 1) ISPs who want to intercept their customers' traffic, ostensibly to alter URLs for links and images to point to advertisements of their choosing, rather than to advertisements chosen by the content provider. (Note that this is what cable TV companies have done on cable channels for decades, substituting their own ads for the ads coming from the cable channel's content feed. So this seems perfectly natural to them. But defeating secrecy and authenticity measures is a real threat.) 2) software that runs on the user's own PC, and intercepts and modifies his https traffic. In some cases, this is installed by the user himself, ostensibly to block advertisements and certain scripts, and/or do virus detection and prevention. In other cases, it is attack software, malware, plain and simple. In the cases where the user has consciously installed it, the software has merely claimed that it would stop advertisements, and has not explained that it would intercept secure traffic, and defeat all (or most) MITM warnings, to do so. The ISP MITM phenomenon is on the rise, just getting started now. I would encourage users to periodically examine their systems for trusted root CA certs that belong to their ISP, because such certs make it EASY for the ISP to do MITM. (Hint: there's one ISP with roots in FF) ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
On 11/07/2008 11:21 PM, Nelson B Bolyard: I will add that, while MITMs have historically been very rare, they are on the upswing. I see two broad areas where MITM attacks are on the increase, and they're both directed at the user, not the server. One must recognize the fact that MITM attacks were in the past rather expensive when compared to other options to deceive a user. However due to better anti-phishing measures and on some operating systems also anti-viruses and with the rise of wireless, MITM attacks have become more attractive. Obviously such attacks can be performed cheaper as well, by simply redirecting to regular http protocol, for which I suggest to set browser.identity.ssl_domain_display to 1. It should be the default setting IMO since it raises awareness and by my own account I've become quite used to it (after the switch from the yellow address bar). The ISP MITM phenomenon is on the rise, just getting started now. I would encourage users to periodically examine their systems for trusted root CA certs that belong to their ISP, because such certs make it EASY for the ISP to do MITM. (Hint: there's one ISP with roots in FF) Actually the attack which started this thread might have been simply a router which creates the certs on the fly... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Graham, Nelson, Eddy, you all make good points. I'll take your word for it that it's impossible to detect MITM attacks with 100% reliability, as I said I'm not a security expert. How about an MITM detection service that gives no false positives, but might give false negatives? If you positively identify an MITM attack, you can present users with a much more definite UI saying this *is* an MITM attack and giving advice about what to do in the event of an MITM. I'm not talking about fixing all the problems for all the users, just a real improvement for a proportion of users. For example, can one give site owners a way of specifying that their domain must not be accessed if it presents a self-signed certificate. Paypal.com would no doubt take this option, as would any large bank. If the method is made easy enough, so might other sites like facebook. Two possible methods that don't require a detection service (mitm.mozilla.org) might be a DNS record (doesn't work if the attacker has compromised DNS) or a subdomain naming convention (i.e. secure.example.com requires a valid certificate - presents adoption issues for existing sites). This would likely have stopped the original bug poster from revealing her password. If you could implement a perfect MITM detection service, that would be of some value. But an imperfect MITM detection service simply becomes the favorite new target of attackers. A perfect MITM detection service is useful in that if it detects an MITM then that might be a basis upon which to stop the client cold. But in the absence of such detection, there is still no proof that the cert accurately identifies the party it claims to identify. Trouble is, users will learn to treat the absence of a definitive MITM detection as if it WAS proof of the server's identity. I can see how there are philosophical reasons to avoid any MITM detection even if it gave no false positives, because a false negative would be interpreted as an all clear. However, if the user who filed the bug report is anything to go by, people are already misinterpreting real MITM attacks as false positives. Making the error screen scarier for all errors won't fix this because users will just learn that the new scarier screen is what false positives now look like. Introducing a new screen that has a far lower rate of false positives seems a reasonable thing to try. I know you brought it up somewhere on Bugzillago ahead and implement it. Implement what? There's no proposal yet, I'm just trying to start a constructive discussion. If there is interest in implementing something resembling my suggestions, I'll pitch in as much as my schedule and ability allow. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Bernie Sumption wrote, On 2008-11-06 03:57: Graham, Nelson, Eddy, you all make good points. I'll take your word for it that it's impossible to detect MITM attacks with 100% reliability, as I said I'm not a security expert. How about an MITM detection service that gives no false positives, but might give false negatives? I don't think that's possible, either. It is possible in the Internet to setup different physical servers around the globe, all of which appear to users on different parts of the Internet to be the same server. This technology can be used for good or for evil. It is my understanding that this is how Content Distribution Networks like Akamai work. But obviously it can also be used to perform MITM attacks. The only difference between a CDN server and an MITM attacker is the presence or absence of authorization given to the alternative site operator by the true rightful owner of the site. I doubt that the presence of that authorization can be detected by the likes of perspectives. If you positively identify an MITM attack, you can present users with a much more definite UI saying this *is* an MITM attack and giving advice about what to do in the event of an MITM. If we create an error display that says No kidding, this absolutely is an attack and we're stopping you cold to protect you from it. it seems unavoidable that users will learn to treat the absence of such an unbypassable error display as proof to the contrary, proof that the site is genuine and verified. Do we want to train them that way? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
What curious things do you notice about these certs? Certificate: Data: Version: 3 (0x2) Serial Number: 1224169969 (0x48f759f1) Signature Algorithm: PKCS #1 MD5 With RSA Encryption Issuer: CN=unaportal.una.edu,O=University of North Alabama Validity: Not Before: Fri May 18 00:00:00 2007 Not After : Sun May 17 23:59:59 2009 Subject: CN=unaportal.una.edu,O=University of North Alabama Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: b3:7a:4d:3d:3b:5d:1a:55:52:90:ca:45:0b:40:d4:c9: ce:ba:95:64:3a:e7:0f:bc:a7:98:00:15:b7:46:d8:3f: ae:0a:0c:53:92:b2:56:96:4e:bb:2e:95:ab:1f:cd:c5: b2:1b:ca:d5:dd:58:89:ac:b9:7e:93:f6:81:ac:e2:ab: 71:fc:2f:42:8f:84:e4:f1:b7:18:6e:73:5f:cc:33:b2: 8d:6c:b2:d3:5a:aa:7f:79:4a:82:33:81:84:7d:1c:bb: 04:88:aa:8e:ab:f2:0c:4f:21:f8:58:89:45:42:95:6d: 3d:4b:a9:97:f1:4a:3b:1e:6f:84:3d:40:d5:c6:88:e3 Exponent: 65537 (0x10001) Signature Algorithm: PKCS #1 MD5 With RSA Encryption Signature: 24:58:0b:ec:78:87:81:c4:d5:25:8b:b1:3e:30:a6:0f: ae:02:8a:d0:e9:5e:15:b8:ba:37:e2:b0:70:1e:3d:f5: 3f:31:b1:fe:af:b7:dc:e4:c2:9c:9d:fb:f1:80:8e:18: 7c:e8:3b:d4:00:24:28:1f:7f:43:e5:53:ea:40:39:44: 68:af:9e:10:94:c6:c2:31:d6:04:84:a9:1c:ef:a8:9e: 47:19:c1:2c:29:a8:3f:14:2c:2c:4f:49:f1:85:27:06: a3:85:73:3b:18:70:87:11:aa:02:43:f1:64:ee:41:80: 27:e3:a3:95:34:22:10:26:ce:9f:21:db:32:eb:66:ee === Certificate: Data: Version: 3 (0x2) Serial Number: 1225207685 (0x49072f85) Signature Algorithm: PKCS #1 MD5 With RSA Encryption Issuer: CN=*.govdelivery.com,O=GovDelivery, Inc Validity: Not Before: Sat Feb 24 00:00:00 2007 Not After : Mon Feb 23 23:59:59 2009 Subject: CN=*.govdelivery.com,O=GovDelivery, Inc Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: b3:7a:4d:3d:3b:5d:1a:55:52:90:ca:45:0b:40:d4:c9: ce:ba:95:64:3a:e7:0f:bc:a7:98:00:15:b7:46:d8:3f: ae:0a:0c:53:92:b2:56:96:4e:bb:2e:95:ab:1f:cd:c5: b2:1b:ca:d5:dd:58:89:ac:b9:7e:93:f6:81:ac:e2:ab: 71:fc:2f:42:8f:84:e4:f1:b7:18:6e:73:5f:cc:33:b2: 8d:6c:b2:d3:5a:aa:7f:79:4a:82:33:81:84:7d:1c:bb: 04:88:aa:8e:ab:f2:0c:4f:21:f8:58:89:45:42:95:6d: 3d:4b:a9:97:f1:4a:3b:1e:6f:84:3d:40:d5:c6:88:e3 Exponent: 65537 (0x10001) Signature Algorithm: PKCS #1 MD5 With RSA Encryption Signature: 90:67:64:97:95:11:35:4b:43:30:19:ba:24:69:3a:03: 23:6f:33:ac:0f:bc:2c:52:7b:b8:81:8d:e9:51:c5:f8: 72:db:bf:54:5d:c1:3d:dd:42:75:89:c8:a4:c7:0d:5a: 38:23:d8:70:5e:85:a0:7d:80:e6:a1:38:e5:97:48:a3: c2:28:90:6b:ef:7c:9d:20:89:b2:30:04:e4:67:36:01: c9:05:b9:1b:eb:3c:9f:7c:ec:94:c8:4d:04:9e:ff:9b: 68:3d:a5:72:9a:a8:8f:73:b5:41:0e:e8:fe:2e:d5:3a: 29:80:0b:32:3f:c7:64:9a:05:f8:e2:49:36:bc:c2:87 === Certificate: Data: Version: 3 (0x2) Serial Number: 1224197811 (0x48f7c6b3) Signature Algorithm: PKCS #1 MD5 With RSA Encryption Issuer: CN=login.yahoo.com,O=Yahoo! Inc. Validity: Not Before: Wed Jan 04 17:09:06 2006 Not After : Tue Jan 04 17:09:06 2011 Subject: CN=login.yahoo.com,O=Yahoo! Inc. Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: b3:7a:4d:3d:3b:5d:1a:55:52:90:ca:45:0b:40:d4:c9: ce:ba:95:64:3a:e7:0f:bc:a7:98:00:15:b7:46:d8:3f: ae:0a:0c:53:92:b2:56:96:4e:bb:2e:95:ab:1f:cd:c5: b2:1b:ca:d5:dd:58:89:ac:b9:7e:93:f6:81:ac:e2:ab: 71:fc:2f:42:8f:84:e4:f1:b7:18:6e:73:5f:cc:33:b2: 8d:6c:b2:d3:5a:aa:7f:79:4a:82:33:81:84:7d:1c:bb: 04:88:aa:8e:ab:f2:0c:4f:21:f8:58:89:45:42:95:6d: 3d:4b:a9:97:f1:4a:3b:1e:6f:84:3d:40:d5:c6:88:e3 Exponent: 65537 (0x10001) Signature Algorithm: PKCS #1 MD5 With RSA Encryption Signature: 07:33:d2:77:35:11:10:31:72:6c:01:65:46:59:36:8a: 1d:d1:2d:fd:61:74:3a:50:c2:0c:a7:3d:3d:29:7e:3a: 01:64:28:92:a6:98:64:a8:23:64:55:d4:cf:5c:c3:df: dd:6e:21:a9:59:02:9d:ec:be:bc:86:eb:18:54:63:85: f8:de:65:c1:e4:44:92:e3:6f:97:f8:f8:34:eb:97:58: f1:0e:5f:d8:3c:7e:b0:91:62:d3:56:f6:90:35:9f:55:
Re: MITM in the wild
Nelson B Bolyard wrote: What curious things do you notice about these certs? Only one key? All have same Issuer + Subject? iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Aside from the fact that they all claim to be issued by themselves, but the key modulus is the same across all of them? Perhaps the fact that they're all version 3 certificates that don't show any version 3 extensions, such as keyUsage and extendedKeyUsage? Should there be a check to make sure that disparate sites aren't using the same public key modulus/exponent? -Kyle H On Thu, Nov 6, 2008 at 12:41 PM, Nelson B Bolyard [EMAIL PROTECTED] wrote: What curious things do you notice about these certs? Certificate: Data: Version: 3 (0x2) Serial Number: 1224169969 (0x48f759f1) Signature Algorithm: PKCS #1 MD5 With RSA Encryption Issuer: CN=unaportal.una.edu,O=University of North Alabama Validity: Not Before: Fri May 18 00:00:00 2007 Not After : Sun May 17 23:59:59 2009 Subject: CN=unaportal.una.edu,O=University of North Alabama Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: b3:7a:4d:3d:3b:5d:1a:55:52:90:ca:45:0b:40:d4:c9: ce:ba:95:64:3a:e7:0f:bc:a7:98:00:15:b7:46:d8:3f: ae:0a:0c:53:92:b2:56:96:4e:bb:2e:95:ab:1f:cd:c5: b2:1b:ca:d5:dd:58:89:ac:b9:7e:93:f6:81:ac:e2:ab: 71:fc:2f:42:8f:84:e4:f1:b7:18:6e:73:5f:cc:33:b2: 8d:6c:b2:d3:5a:aa:7f:79:4a:82:33:81:84:7d:1c:bb: 04:88:aa:8e:ab:f2:0c:4f:21:f8:58:89:45:42:95:6d: 3d:4b:a9:97:f1:4a:3b:1e:6f:84:3d:40:d5:c6:88:e3 Exponent: 65537 (0x10001) Signature Algorithm: PKCS #1 MD5 With RSA Encryption Signature: 24:58:0b:ec:78:87:81:c4:d5:25:8b:b1:3e:30:a6:0f: ae:02:8a:d0:e9:5e:15:b8:ba:37:e2:b0:70:1e:3d:f5: 3f:31:b1:fe:af:b7:dc:e4:c2:9c:9d:fb:f1:80:8e:18: 7c:e8:3b:d4:00:24:28:1f:7f:43:e5:53:ea:40:39:44: 68:af:9e:10:94:c6:c2:31:d6:04:84:a9:1c:ef:a8:9e: 47:19:c1:2c:29:a8:3f:14:2c:2c:4f:49:f1:85:27:06: a3:85:73:3b:18:70:87:11:aa:02:43:f1:64:ee:41:80: 27:e3:a3:95:34:22:10:26:ce:9f:21:db:32:eb:66:ee === Certificate: Data: Version: 3 (0x2) Serial Number: 1225207685 (0x49072f85) Signature Algorithm: PKCS #1 MD5 With RSA Encryption Issuer: CN=*.govdelivery.com,O=GovDelivery, Inc Validity: Not Before: Sat Feb 24 00:00:00 2007 Not After : Mon Feb 23 23:59:59 2009 Subject: CN=*.govdelivery.com,O=GovDelivery, Inc Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: b3:7a:4d:3d:3b:5d:1a:55:52:90:ca:45:0b:40:d4:c9: ce:ba:95:64:3a:e7:0f:bc:a7:98:00:15:b7:46:d8:3f: ae:0a:0c:53:92:b2:56:96:4e:bb:2e:95:ab:1f:cd:c5: b2:1b:ca:d5:dd:58:89:ac:b9:7e:93:f6:81:ac:e2:ab: 71:fc:2f:42:8f:84:e4:f1:b7:18:6e:73:5f:cc:33:b2: 8d:6c:b2:d3:5a:aa:7f:79:4a:82:33:81:84:7d:1c:bb: 04:88:aa:8e:ab:f2:0c:4f:21:f8:58:89:45:42:95:6d: 3d:4b:a9:97:f1:4a:3b:1e:6f:84:3d:40:d5:c6:88:e3 Exponent: 65537 (0x10001) Signature Algorithm: PKCS #1 MD5 With RSA Encryption Signature: 90:67:64:97:95:11:35:4b:43:30:19:ba:24:69:3a:03: 23:6f:33:ac:0f:bc:2c:52:7b:b8:81:8d:e9:51:c5:f8: 72:db:bf:54:5d:c1:3d:dd:42:75:89:c8:a4:c7:0d:5a: 38:23:d8:70:5e:85:a0:7d:80:e6:a1:38:e5:97:48:a3: c2:28:90:6b:ef:7c:9d:20:89:b2:30:04:e4:67:36:01: c9:05:b9:1b:eb:3c:9f:7c:ec:94:c8:4d:04:9e:ff:9b: 68:3d:a5:72:9a:a8:8f:73:b5:41:0e:e8:fe:2e:d5:3a: 29:80:0b:32:3f:c7:64:9a:05:f8:e2:49:36:bc:c2:87 === Certificate: Data: Version: 3 (0x2) Serial Number: 1224197811 (0x48f7c6b3) Signature Algorithm: PKCS #1 MD5 With RSA Encryption Issuer: CN=login.yahoo.com,O=Yahoo! Inc. Validity: Not Before: Wed Jan 04 17:09:06 2006 Not After : Tue Jan 04 17:09:06 2011 Subject: CN=login.yahoo.com,O=Yahoo! Inc. Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: b3:7a:4d:3d:3b:5d:1a:55:52:90:ca:45:0b:40:d4:c9: ce:ba:95:64:3a:e7:0f:bc:a7:98:00:15:b7:46:d8:3f: ae:0a:0c:53:92:b2:56:96:4e:bb:2e:95:ab:1f:cd:c5: b2:1b:ca:d5:dd:58:89:ac:b9:7e:93:f6:81:ac:e2:ab: 71:fc:2f:42:8f:84:e4:f1:b7:18:6e:73:5f:cc:33:b2: 8d:6c:b2:d3:5a:aa:7f:79:4a:82:33:81:84:7d:1c:bb: 04:88:aa:8e:ab:f2:0c:4f:21:f8:58:89:45:42:95:6d: 3d:4b:a9:97:f1:4a:3b:1e:6f:84:3d:40:d5:c6:88:e3 Exponent: 65537
Re: MITM in the wild
...and they're all using MD5? -Kyle H On Thu, Nov 6, 2008 at 12:48 PM, Ian G [EMAIL PROTECTED] wrote: Nelson B Bolyard wrote: What curious things do you notice about these certs? Only one key? All have same Issuer + Subject? iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Kyle, Kyle Hamilton wrote: Should there be a check to make sure that disparate sites aren't using the same public key modulus/exponent? That would be fairly hard to implement reliably. Currently, we don't persist end-entity certs of web sites in general in PSM. Even if we did, what is the likelihood for one individual browser to have visited all those sites and be able to detect them ? Those are problems that should be dealt with by revocation, which is not a process that works for self-signed certs. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Ian G wrote, On 2008-11-06 12:48: Nelson B Bolyard wrote: What curious things do you notice about these certs? Only one key? Yup. That's the biggie. It allows the MITM to get by with just a single private key. All have same Issuer + Subject? Yeah, all self signed. All DNs consist of CN=something,O=something attributes, in that order, and the values of those attributes come from the real https server's cert Subject name. All other attributes from the real server's cert subject name are lost. The Validity period dates also come straight from the real server cert. The 32-bit serial numbers are actually Unix time_t's (count of seconds since midnight Jan 1, 1970 UTC). I believe they show the time the cert was created. 1224115668 Wed Oct 15 17:07:48 2008 1224127195 Wed Oct 15 20:19:55 2008 1224169923 Thu Oct 16 08:12:03 2008 1224169969 Thu Oct 16 08:12:49 2008 1224170001 Thu Oct 16 08:13:21 2008 1224197811 Thu Oct 16 15:56:51 2008 1224211462 Thu Oct 16 19:44:22 2008 1225207685 Tue Oct 28 08:28:05 2008 1225208188 Tue Oct 28 08:36:28 2008 1225208630 Tue Oct 28 08:43:50 2008 1225288698 Wed Oct 29 06:58:18 2008 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Nelson B Bolyard wrote: Ian G wrote, On 2008-11-06 12:48: Nelson B Bolyard wrote: What curious things do you notice about these certs? Only one key? Yup. That's the biggie. It allows the MITM to get by with just a single private key. OK. We can of course all imagine ways to exploit that weakness, but it seems rather pointless to me. In that, if any defence worked, the attacker would just start using different keys. How long does it take to generate a pool of thousands of keys? How many million machines on your botnet? Is this a real live attack? Any other details? Or is this K's attack as per current thread? iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Kyle, Kyle Hamilton wrote: So, essentially, what you're saying is that it was a targeted attack against a user, instead of an attack targeted against a server? Apparently, keeping track of keys in certificates placed individually into NSS might be a good idea regardless. The attacker absolutely didn't have to reuse the same key for this attack. He could have regenerated a new key on the fly for every site the user visited. Remember that there are plenty of cases where it's perfectly valid to reuse the same keypair - cases like cross-certification. Even if we detected duplicate public keys between certs in NSS, that is not necessarily something we want to fail on. We would have to know that the keys have been assigned to completely different entities, as in the example Nelson posted. Sometimes it may be unclear, for example if somebody changes CA, or changes domain and happens to reuse the same private key for 2 different certs. This kind of attack is easily mitigated - the certs were self-signed. That's a dead giveaway that the user shouldn't accept them. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Bernie Sumption wrote, On 2008-11-04 04:04: Is removal of the ability to override bad certs the ONLY effective protection for such users? No. If we can detect MITM attacks, the problem goes away. It does? Absence of an incomplete MITM attack does not prove the identity of the server. There are ways of detecting MITM attacks, There are ways of detecting SOME MITM attacks on SOME server, those that affect only a limited portion of the Internet against servers that are not part of content distribution networks. The methods currently proposed also have the problem that they interfere with so-called content distribution networks (like Akamai, for one). They may detect MITMs when no MITM is in effect, simply because different servers rightfully act as www.foo.com in different parts of the Internet. The important thing is that we recognise that some kind of MITM detection is essential, no matter how hard it might be to implement, because if you show the same UI for a MITM attack as you show for a misconfigured/homebrew web server, even quite savvy users are going to assume that a real MITM is a misconfiguration/homebrew. If you could implement a perfect MITM detection service, that would be of some value. But an imperfect MITM detection service simply becomes the favorite new target of attackers. A perfect MITM detection service is useful in that if it detects an MITM then that might be a basis upon which to stop the client cold. But in the absence of such detection, there is still no proof that the cert accurately identifies the party it claims to identify. Trouble is, users will learn to treat the absence of a definitive MITM detection as if it WAS proof of the server's identity. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Is removal of the ability to override bad certs the ONLY effective
protection for such users?
No. If we can detect MITM attacks, the problem goes away. There are
ways of detecting MITM attacks, but first of all, this is why we need
to do it:
The problem as I see it is that the same warning UI is shown whenever
there is a less than perfect certificate. Let us assume that 99.99% of
the time, this either a misconfigured web server or a homebrew site
that is using self-signed certs because they only care about
encryption, not authentication. 0.01% of the time it is a MITM
attack.In the MITM scenario the UI is not harsh enough. In the common
case it is too harsh.
The important thing is that we recognise that some kind of MITM
detection is essential, no matter how hard it might be to implement,
because if you show the same UI for a MITM attack as you show for a
misconfigured/homebrew web server, even quite savvy users are going to
assume that a real MITM is a misconfiguration/homebrew.
In the event of a MITM attack, the user should be shown a huge red
warning, like the phishing and malware warnings, stating that Firefox
has detected a man-in-the-middle attack: we think that an attacker is
intercepting your connection. Whether you let users override this can
be debated.
In the event of a misconfigured web server / homebrew site, the user
could be shown a more qualified warning that this site uses
encryption, but can't be identified because {$REASON}. It is
difficult, but not impossible, for an attacker to see any data you
send or receive. If you use this site for important communications or
financial transactions you should not use it. Please contact the site
owners and let them know about this problem.
Here's one idea for detecting MITM attacks, but I'm not a security
expert so please don't jump on me and call me an idiot. If this way
doesn't work for some reason, I'm sure that there are other ways:
The browser could send all self-signed or invalid certificates to a
trusted MITM detection service, say https://mitm.mozilla.com. A MITM
on this site is impossible because it would have a valid certificate.
This site could inspect the certificate and use a variety of
heuristics to detect MITM attacks:
* The service could connect to the same site and check that it has the
same certificate, which obviously only works if the attacker is not in
a position to MITM the trusted server too (if the attacker is on the
same network as the host, they can MITM any client on the Internet).
* The service could use a community based approach as used by phishing
detection to report MITM attacks so close to the target host that they
can MITM the entire Internet.
* There could be some kind of opt-in way (through a DNS record?) of a
site specifying a MITM policy, so banks could state that anything but
a properly signed certificate is treatede as an MITM.
* Any other ideas?
Care would need to be taken with privacy, but if this approach works
with phishing, why now MITM?
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Ian G wrote, On 2008-10-20 22:41: Nelson B Bolyard wrote: It is widely agreed that, since KCM has no central revocation facility, KCM is not central, period. Talking about revocation is a strawman. I should have said central revocation SERVICE. Sadly, it DOES have a central revocation facility now, a central source for that awful 10MB file that every KCM user must now use. Further, new KCM keys should be tested against those files before being added to the user's trusted list. This has given rise to the proposal to add code to do that to the browser. But the prospect of adding such enormous CKLs to browser downloads seems to be unacceptable to nearly everyone in Mozilla land. What has this got to do with KCM? Is KCM being used to create keys now? Or are you saying that the KCM module has to now test all the PKI keys too? If you're going to have the browser use KCM for SSL servers, then the browser has need of a revocation method for KCM, just like SSH does, and that presently means dragging around that 10MB file. I think that says that KCM really must be relegated to the uses that really don't care about MITM, not even in the least tiny little bit. Nelson, you sound really bitter about this. SSH has protected people for a decade or more. If you can't see why that is, well, perhaps you can at least see that people are not abandoning it, and it will be protecting for another decade. I know that lots of SSH users have still never downloaded the 10MB file+program package and run it locally. Yes, I know why they cling to SSH, even though they do not use the Debian Key Finding program/file. It's because they don't understand the danger, and simply like the warm and fuzzy feeling they have from using SSH in blissful ignorance. Personally, I have no such uses. I have no need for encryption that is vulnerable to MITM, but evidently lots of people think they do. If your choice is to pay that cost, yourself, that's fine. Pay? Just what is that cost? The cost of a cert from a free CA? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Ian G: Nelson B Bolyard wrote: It is widely agreed that, since KCM has no central revocation facility, KCM is not central, period. Talking about revocation is a strawman. I think that's the point he is making. What's your point? Sounds to me like most of the last 1000 security bugs. Patch it, or remain vulnerable? Patching is fine, they did. However the (SSH) keys don't have a validity period attached to them, nor can they be revoked. At least CAs could revoke the vulnerable keys, which CAs really did. If you encounter a cert from StartCom today you can be assured that it's not a weak key. You can't do that with KCM (easily) nor is there an authority who cares and takes responsibility. Nor would Mozilla be in the situation to take over the role of CAs. The idea of scanning for weak keys was not feasible. What has this got to do with KCM? Is KCM being used to create keys now? Or are you saying that the KCM module has to now test all the PKI keys too? Compare that to the above and you understand the little difference between having a third party and KCM. Beside that the self-signed certs don't provide any value... Nelson, you sound really bitter about this. SSH has protected people for a decade or more. You can use PKI with SSH. Not many uses it, but that's not SSH's fault. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Graham Leggett wrote: David E. Ross wrote: [...] I have also visited sites with incorrectly configured site certificates. [...]. I definitely do not want to be locked out of these sites either. This is the classic balance between convenience and security. inconvenience != security. inconvenience == unsecurity. In chernobyl, the security was implemented in a very inconvenient way. The prime reason why occidental nuclear power plant are most secure is not that they have more security than Tchernobyl. It's that their security is much more convenient, and that's probably the number one lesson people got out of chernobyl. Recheck every security procedure and make sure it's easy enough to use that people won't switch it out. The chernobyl disaster happened after people had switched out almost every security mechanism because they were so broken and inconvenient. It very hard to find a solution that's both convenient and secure. But that's the only way. Inconvenient solutions are strongly unsecure. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Nelson B Bolyard wrote: [...] This incident has shown that FF3, with its all-too-easy-to-defeat MITM reporting, is NOT suitable for high-value web transactions such as online banking. You know Nelson the reason why you are taking this the wrong way is that you have *no* direct experience of how average users interact with broken ssl sites. Let me explain how I had the revelation FX 3 is broken *because* it tries too much to block acces to web sites with invalid certificates. It happened when one of my collegue came to me to talk about this new FX 3 browser. He told me it was nice but SSL support was broken. Broken ? Yes, instead of accessing to the web site, he got some error screen, and had to run IE instead. This was a developer with already around two years of writing SSL related softwares. Since then I'm definetively convinced the current firefox method is broken *and makes the average joe unsecure* because it blocks access to the site (and just not only the average joe, but a lot many users who should know better). Now, the answer about what to do next is not easy. But it's *not* to block even more access to those web sites. Whilst I have no magic bullet, it definetively lies in the line of finding a way to *explain* to the user *what* is broken exactly, and provide him an effective and easy way to check if it's an error or an attack. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Jean-Marc Desperrier: Eddy Nigg wrote: [...] When the visitor statistics suddenly goes down, web site owners will take action.[...] It will not go down. It's only the percentage of user using Firefox that will go down. Can you please backup your assumptions? MY sources show clearly that both web sites using legitimate certificates and market share of Firefox has gone up. This is correct in real number and relative percentage wise. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Jean-Marc Desperrier: Broken ? Yes, instead of accessing to the web site, he got some error screen, and had to run IE instead. Oh yes, and IE let him just through, no errors and no red address bar and no We recommend not to visit this site, right? This was a developer with already around two years of writing SSL related softwares. Which SSL software does he write so I can avoid it? Now, the answer about what to do next is not easy. But it's *not* to block even more access to those web sites. At least one shortcoming must be fixed and it's the fetching of missing CA certificates in the chain. Sites which are unfortunately not configured correctly, but otherwise use a perfect certificate shouldn't be blocked and the browser should try to build the chain by fetching the missing CA certificates. Whilst I have no magic bullet, it definetively lies in the line of finding a way to *explain* to the user *what* is broken exactly, and provide him an effective and easy way to check if it's an error or an attack. Here I agree with you completly. Education is a very important part of what we must do. I've been thinking that allowing users to click through warnings was very bad from an educational point of view. One of the problems is that users simply don't read, they don't care until their passwords are stolen and credit cards emptied. I also agree with you that there is no magic bullet - except that we've tried it the current way of presenting warnings, errors screens etc. for years. Maybe we should try it otherwise, because SSL does protect against MITM attacks - that's one of its major tasks. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Ian G: Curious! Eddy, how did you learn how to go to all that inconvenience? LOL Because I'm a security expert I guess :-) -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Jean-Marc Desperrier wrote: Eddy Nigg wrote: [...] Every time I come from shopping it's very inconvenient to put down the shopping bags, grab for my keys and open the front door of my house. Then pick up my bags again. After entering I have to lock the door again (by convenience, if I want). But overall, what an inconvenience...why did they put a door and lock there? [...] *Many* people do not lock their door after entering because the perceived level of risk is lower than the inconvenience. After writing that, I realized that there's a specific reason why I don't lock my door after entering. It's that someone else has perceived that problem (people who don't value the security brought by locking their door after entering more than the inconvenience of locking the door) and has found a smart way to mitigate it. The door of my appartement doesnt' have an ouside handle. You can't enter without using the key. This is a very smart solution, because if I'm outside the appartement and want to enter, most of the time there's nobody else inside and I anyway would have locked the door, so needed the key to open it. If there's someone inside and I find it inconvenient to search for the key, probably I can just call the person and ask him to open the door. But if no one had cared about the problem, and just said if people aren't stupid, they'll lock the door, I might find myself in the same situation as when I was younger in the house of my parents, where there was an outside handle, and very often the door was unlocked, despite that it did happen that we were all in the other side of the house and someone really could have stolen something without us noticing. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Jean-Marc Desperrier: The pratical result of inconvenience is a threshold level that depends of two factor : the inconvenience and the perceived threat. I agree with every word you said in this mail! Risk assessment is important! I believe that we just don't agree (yet) where to draw the line. But if we believe that we should get to the point to prevent users from clicking through errors (because of the risk involved) than we are very close already. Implementation proposals may vary, but I think that with providing better security for the AVERAGE user, overall usability of the Internet will improve and facilitate more business on the Internet in every respect (not only financial transactions, but getting applications from the OS to the Internet and many other conveniences. Therefore, the current inconvenience will be balanced by far greater gains in other fields, making it a great investment instead a burden. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Eddy Nigg wrote: [...] Despite that, http://www.xitimonitor.com/ has testimony to a growing market share of Firefox in Europe, including Germany. Go figure... I *never* claimed that this problem would lower the *general* use of Firefox. The SSL use case is small enough that it has *no* weight when compared to global web usage. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Eddy Nigg wrote: [...] MY sources show clearly that both web sites using legitimate certificates and market share of Firefox has gone up. This is correct in real number and relative percentage wise. The second number hardly actually proves anything. In what I describe, users will continue to use Firefox most of the time, and switch to IE only for broken SSL sites. The first number is more interesting, you actually got a statistically significant percentage of people correcting their site after the Fx 3 release ? But even if you prove me wrong by showing this happened as a significant phenomen, I still be worried by the phenomen of people who are switching to IE to view those sites. My personnal evidence might be anecdotical but it's massive. Thorsten Becker had actual numbers showing the decline in ff usage and that switching the browser was the number 1 reactions of users in http://groups.google.fr/group/mozilla.dev.tech.crypto/msg/7e1680e605ab8228 You see, saying this results in some site correcting their ssl use is not the end of the story if it also has the result that many users will just use IE. Because the second case can lead to some very vicious attacks. You could see a pirate who wants to propagate a malware that is only able to attack IE deliberately put a version of his site behind a broken SSL so to get many usual Firefox users to use IE to access it and be infected. Also, saying that we need to find a way so that the number one reaction of the average user is not to switch to IE *does not* mean we won't try to do as much as possible so that site owner will be convinced to correct their site. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Eddy Nigg wrote: Jean-Marc Desperrier: Graham Leggett wrote: This is the classic balance between convenience and security. inconvenience != security. inconvenience == unsecurity. Every time I come from shopping it's very inconvenient to put down the shopping bags, grab for my keys and open the front door of my house. Then pick up my bags again. After entering I have to lock the door again (by convenience, if I want). But overall, what an inconvenience...why did they put a door and lock there? Curious! Eddy, how did you learn how to go to all that inconvenience? iang smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Jean-Marc Desperrier wrote, On 2008-10-20 01:50: Eddy Nigg wrote: Ian G: Nelson B Bolyard wrote: Despite all the additional obstacles that FF3 put in her way, and all the warnings about legitimate sites will never ask you to do this, she persisted in overriding every error, and thus giving away most of her valuable passwords to her attacker. Yep, no surprise. FF3 tries too hard, way too hard, imho. Quite the opposite...just imagine Firefox wouldn't have made it that hard and annoying, she wouldn't have filed a bug report and we wouldn't know. As has *already* been reported on this group, *many*, *many*, *many* users did not fill a bug report until now and switched browser instead. You have found the very single user knowledgeable enough to fill a bug report instead of switching browser. The mozilla community absolutly *needs* to understand this is *not* the standard behaviour until now. The standard behaviour of users has always been to switch browser and not report anything. So, what's your point, Jean Marc? Do you argue that Firefox should ignore bad cert errors, or make them utterly trivial to override, so that users will continue to use Firefox, even if it means that they will be *owned*, as the user of bug 460374 was? Perhaps Firefox should not even bother to report bad cert errors, then? That would be consistent with caring only about keeping users, and not caring about user security. Is that what you advocate? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Everybody take a deep breath. If we start treating this as black-and-white extremes, it is unlikely that most users will get the best security and usability. Few if any of us active in this thread are HCI experts. Few of us have anything more than small amounts of anecdotal evidence. Many of us strongly-held religions about what users should want for the security we offer them. It is quite clear that almost anything that is wanted along the spectrum of easy-and-insecure to cumbersome-and-very-secure is implementable in NSS and in software that uses NSS. It also is likely that NSS could embody many points along that spectrum and let the software decide; it would be our responsibility to choose those points wisely and to document them very well. My personal religion would have more points on the cumbersome-and-very-secure side, FWIW, but I know that there is a whole lot that I don't know. This discussion is an important one, but it is one that should involve way more than just us. In fact, maybe we should be only minor players in the discussion, better adept at implementing what others want than to try to lead them to the best solution for the users. I don't see the expertise here for any of us to be stating the One True Solution. --Paul Hoffman ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Jean-Marc Desperrier wrote, On 2008-10-20 05:33: Jean-Marc Desperrier wrote: I realized that there's a specific reason why I don't lock my door after entering. [...] The door of my appartement doesnt' have an ouside handle. You can't enter without using the key. In other words, you don't have a choice. You don't need to lock your door after entering, because your door is always locked after entering. There is no easy way around using a key to enter. You could replace your door with one that works differently, but you have not apparently chosen to do so. You seem to like it. You described it as This is a very smart solution, This is exactly analogous to what Eddy has proposed for Firefox. Yet you object vociferously to doing for Firefox what you do for your own front door. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
On Mon, Oct 20, 2008 at 4:49 AM, Eddy Nigg [EMAIL PROTECTED] wrote: Jean-Marc Desperrier: Graham Leggett wrote: This is the classic balance between convenience and security. inconvenience != security. inconvenience == unsecurity. Every time I come from shopping it's very inconvenient to put down the shopping bags, grab for my keys and open the front door of my house. Then pick up my bags again. After entering I have to lock the door again (by convenience, if I want). But overall, what an inconvenience...why did they put a door and lock there? To keep honest people honest, and to inconvenience you in a visible way that gives you a false sense of security. If someone really wants to steal something from your home, they'll break a window -- which is a much more expensive replacement than a lock or door, and much less secure. -Kyle H ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Nelson B Bolyard wrote: Jean-Marc Desperrier wrote, On 2008-10-20 05:33: Jean-Marc Desperrier wrote: I realized that there's a specific reason why I don't lock my door after entering. [...] The door of my appartement doesnt' have an ouside handle. You can't enter without using the key. In other words, you don't have a choice. You don't need to lock your door after entering, because your door is always locked after entering. There is no easy way around using a key to enter. You could replace your door with one that works differently, but you have not apparently chosen to do so. You seem to like it. You described it as This is a very smart solution, This is exactly analogous to what Eddy has proposed for Firefox. One side is exactly analogous: the defence side. Lock it up! The threat side is not analogous. The difference here is that Jean-Marc's lock is in place because there is a lot of experience with what is an appropriate, cost effective way to deal with burglars. This has evolved over centuries, and we really do know how to do this -- as a society. The lock on his door is far more subtle than just a lock. It is a lot easier because of the history, also because of the tangibility of the crime. When something goes missing, the average person can draw a line from the missing spot ... to the door ... to the perpetrator in a far off place. When the user forgets to lock the door ... eventually someone discovers that it is easy to have the door locked when it is only in locked state. Therefore we must all carry keys. However, with the attack we face here, few -- and certainly not the users -- have the first clue what is happening or how to fix it. (e.g., we do agree that we'd like to write something that says for high value commerce, use ... except we don't know what is.) Yet you object vociferously to doing for Firefox what you do for your own front door. Yes. E.g., did you know that the point of a good lock on a door is *not* to stop a burglar getting in, but to stop him getting out? That's why it is called a deadbolt. The burglar can always get in, the game is to stop him getting out the front door, carrying your stuff. Now, if we install a deadbolt in Firefox, that means ... something like one quarter of websites with SSL cannot be accessed. We might agree that the state of the world today is annoying, but we should also be able to see that such a drastic change will cause more trouble than it is worth. iang PS: https://financialcryptography.com/ for one will be deadbolted You may laugh, but will you have made me or my readers more secure? No chance. Will you have caused mass confusion and a move across to IE? Probably. smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Kyle Hamilton wrote: On Mon, Oct 20, 2008 at 4:49 AM, Eddy Nigg [EMAIL PROTECTED] wrote: Jean-Marc Desperrier: Graham Leggett wrote: This is the classic balance between convenience and security. inconvenience != security. inconvenience == unsecurity. Every time I come from shopping it's very inconvenient to put down the shopping bags, grab for my keys and open the front door of my house. Then pick up my bags again. After entering I have to lock the door again (by convenience, if I want). But overall, what an inconvenience...why did they put a door and lock there? To keep honest people honest, and to inconvenience you in a visible way that gives you a false sense of security. If someone really wants to steal something from your home, they'll break a window -- which is a much more expensive replacement than a lock or door, and much less secure. Ahhh... it's more subtle than that. The purpose of a good lock is *not* to keep the burgler out. It is more subtle; it is to *stop the burgler getting out*. This is because the theory of burglary is that the crook can always get in, but he needs to carry heavy stuff out. Sure he can break a window to get in. But can he climb out the window carrying a TV? Most burglaries are conducted by entering through the window and leaving through the front door. Hence, deadbolts. (You might validly ask then how Jean-Marc's lock works. I'm guessing that it also has a mode to lock it dead on exiting, which is easy to unlock on entering.) iang smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Ian G wrote, On 2008-10-20 13:28: Yes. E.g., did you know that the point of a good lock on a door is *not* to stop a burglar getting in, but to stop him getting out? That's why it is called a deadbolt. The burglar can always get in, the game is to stop him getting out the front door, carrying your stuff. I think you are using the term deadbolt to describe locks that require a key on both the inside and the outside to lock or unlock them. I think that is not the definition of deadbolt common used in the USA. I wonder if that is a regional thing, US English vs UK, or something. In the USA, a deadbolt lock is any lock whose bolt must be explicitly locked each time the door is closed, or else it remains unlocked. While such locks are common, typically they have a simple handle on the inside, and require a key only on the outside. I suppose that makes them not good locks by your definition, and I agree that the typical US deadbolt lock does not hinder egress, but only hinders ingress. (e.g., we do agree that we'd like to write something that says for high value commerce, use ... except we don't know what is.) I keep wondering about that. Lots of people seem to agree that they want some kind of half-vast SSL, providing some encryption, but no assurance that the party to whom they're connected is who they intended it to be. No protection against MITM, just a warm fuzzy feeling that well, at least we're using encryption. I think the term security theater applies. How do we give them that in a way that clearly distinguishes between that and real authenticated connections? I think there are (at least) two parts to the puzzle: a) some way to convey to the browser that the EXPECTED amount of security is low, so the browser won't try to impose all the usual high security requirements on the connection (e.g. not impose strong authentication requiremetns) and hence won't show any warnings. I'm thinking we need an alterantive to https for this. httpst:// (security theater) maybe? or httpwf:// (warm fuzzy) or mitm:// b) some unmistakeable blatantly obvious way to show the user that this site is not using security that's good enough for banking but, well, is pretty good security theater. Flashing pink chrome? Empty wallet icon? The whistling sounds associated with falling things? http://www.sounds.beachware.com/2illionzayp3may/dhy/BOMBFALL.mp3 With such an alternative to regular https, we could raise the bar on https certs (stop allowing overrides) while still offering an alternative for those who want it. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Nelson B Bolyard: httpst:// (security theater) maybe? or httpwf:// (warm fuzzy) or mitm:// LOLI can't hold myself on the chair anymore...I'm laughing myself kaput! Because of you I had to change my shirt and clean the keyboard from coffee stainsCan you warn me next time upfront not to drink?! That's the best comment I've seen for a long time! I'd vote for mitm:// :-) With such an alternative to regular https, we could raise the bar on https certs (stop allowing overrides) while still offering an alternative for those who want it. Even if it sounds really funny, but maybe this isn't such a bad idea at all. Just please allow me to disable the usage of mitm:// at all. I don't mind editing about:config -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Nelson B Bolyard wrote: b) some unmistakeable blatantly obvious way to show the user that this site is not using security that's good enough for banking but, well, is pretty good security theater. Flashing pink chrome? Empty wallet icon? The whistling sounds associated with falling things? http://www.sounds.beachware.com/2illionzayp3may/dhy/BOMBFALL.mp3 http://new.wavlist.com/movies/325/strk1-intrdra.wav Chrome turns flashing red and yellow;). bob smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
OK, I was too flippant, but I'm serious about wanting an alternative to https, something that means security not good enough for financial transactions, but OK for your private home router/server. Nelson B Bolyard wrote, On 2008-10-20 15:07: Ian G wrote, On 2008-10-20 13:28: (e.g., we do agree that we'd like to write something that says for high value commerce, use ... except we don't know what is.) I keep wondering about that. Lots of people seem to agree that they want some kind of half-vast SSL, providing some encryption, but no assurance that the party to whom they're connected is who they intended it to be. No protection against MITM, just a warm fuzzy feeling that well, at least we're using encryption. I think the term security theater applies. How do we give them that in a way that clearly distinguishes between that and real authenticated connections? I think there are (at least) two parts to the puzzle: a) some way to convey to the browser that the EXPECTED amount of security is low, so the browser won't try to impose all the usual high security requirements on the connection (e.g. not impose strong authentication requiremetns) and hence won't show any warnings. I'm thinking we need an alterantive to https for this. serious alternatives to https wanted. b) some unmistakeable blatantly obvious way to show the user that this site is not using security that's good enough for banking but, Serious chrome ideas wanted. With such an alternative to regular https, we could raise the bar on https certs (stop allowing overrides) while still offering an alternative for those who want it. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Nelson B Bolyard wrote: Ian G wrote, On 2008-10-20 19:24: There are possibilities. One is the server-side self-signed certs, which would generally prefer KCM to be useful, so add Petnames. This is ok for small sites, small communities, but valuable there as compromised boxes are a pain. The Debian OpenSSL fiasco caused the creation of 3*65536 bad keys of each and every conceivable size (e.g., 1024 bit, 1025 bit, 1026 bit ...). A file was created that contained all those keys for two popular sizes, 1024 bit and 2048 bit, and when compressed, that file is about the size of the entire browser download. It is widely agreed that, since KCM has no central revocation facility, KCM is not central, period. Talking about revocation is a strawman. the only way to effectively handle revocation is for individual KCM clients and servers, which is to say, users, to download those enormous files of bad keys, and check their sets of trusted keys against those files. Tools for doing that are available to SSH users now. Users who don't do that, who don't download and use those enormous compromised key lists (CKLs) and their checking programs, will be forever vulnerable to those compromised keys. What's your point? Sounds to me like most of the last 1000 security bugs. Patch it, or remain vulnerable? It seems like you are searching for any reason to stick that stake in the heart of KCM. Problem is, it has to be an honest stake; the concept doesn't care if you don't like it. Further, new KCM keys should be tested against those files before being added to the user's trusted list. This has given rise to the proposal to add code to do that to the browser. But the prospect of adding such enormous CKLs to browser downloads seems to be unacceptable to nearly everyone in Mozilla land. What has this got to do with KCM? Is KCM being used to create keys now? Or are you saying that the KCM module has to now test all the PKI keys too? I think that says that KCM really must be relegated to the uses that really don't care about MITM, not even in the least tiny little bit. Nelson, you sound really bitter about this. SSH has protected people for a decade or more. If you can't see why that is, well, perhaps you can at least see that people are not abandoning it, and it will be protecting for another decade. Personally, I have no such uses. I have no need for encryption that is vulnerable to MITM, but evidently lots of people think they do. If your choice is to pay that cost, yourself, that's fine. Just be careful that you are not one of the ones who dictate to others how much they will pay for your choices. iang smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
David E. Ross wrote: I visit some Web sites with self-signed certificates. None of those sites request any input from me. The only reason they have site certificates is that the site owners want to show off how technically astute they are. Hah! However, those sites do indeed contain information that I want. I definitely do not want to be locked out of them. For a scary example of exactly this, read the following thread: http://lists.gnucash.org/pipermail/gnucash-user/2008-October/027009.html (Of course, you have to accept the self signed certificate to do so). The page http://wiki.gnucash.org/wiki/Mailing_Lists is covered in little padlocks giving the user the impression that some level of security exists, when in reality there is none. If admins are telling users that self signed certs are ok, what hope does a user have if they are not clued up on security? I have also visited sites with incorrectly configured site certificates. In at least one situation, the owner decided to change the domain name without getting a new certificate for the new domain. In several cases, intermediate certificates were not installed, contrary to explicit instructions from the certificate authorities. I definitely do not want to be locked out of these sites either. This is the classic balance between convenience and security. If the next door neighbour's kid can jimmy the computer so that you can see the sites you want to see, even though the security is broken, then the site has no incentive to fix their security issue. In one case a while back, a business banking portal I use ran with an expired certificate for some months. Customers who called their helpdesk were cheerfully told how to systematically switch off all the security in IE6, which allowed their site to work. I was the only customer to complain. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Steffen Schulz wrote: On 081018 at 20:30, Nelson B Bolyard wrote: FF3 had utterly failed to convey to her any understanding that she was under attack. The mere fact that the browser provided a way to override the error was enough to convince her that the errors were not serious. I find it amazing that someone shows this level of ignorance but then manages to file a bugreport... :-) And ... reformat drive, play with compilers, flags, build own browser, switch between versions, bum off others' wireless, maintain a login at bugzilla, make a near-perfect bug report ... This is not your average end-user. I'll bet you a dime to a dollar she knew precisely what the certificates are for. The general excuse of users are stupid isn't going to work this time :) The question is: how can FF3+ *effectively* protect users like her from MITM attackers better than FF3 has already done? Personally, I like the idea of a 'safe mode' in the browser. Safe-mode is very visible, provides limited scripting and https-only to a defined set of sites. If mom wants to go banking, she's been told she has to activate safe-mode. Otherwise banking is insecure. I have thought about that too, and I don't think it is going to work for the general users. Originally I thought it would, but I think we have crossed that Rubicon already. I run NoScript which cuts away about 95% of the crap on most sites, and actually makes FF run nicely, because it isn't struggling under all that javascript crap. (It is worth it for that alone.) However, it breaks a lot of ecommerce sites that use credit cards. Three times now I've found that certain (big) ecommerce sites that use credit cards totally break in the actual payment phase. I have to close the browser, restart, retype in the transaction from scratch, and use the nuclear button on NoScript: Allow scripts *Globally* (Dangerous!) before the transaction goes live. Then it goes through. I don't know what these sites are doing, but this is far too regular. And, NoScript is as good as it gets atm (so I am told, opinions welcome). It is some action that the user initiates, she tells the program when some critical operation starts and ends. If she has to exit safe-mode to go to a bank then that is a very obvious decision to test her luck. This unfortunately will be the case, and too many times. I have to permit all scripting for my online bank. What is the combined sum of these messages: Bank uses scripting, NoScript turns off scripting because it is dangerous, User has to turn off NoScript ? We have a mess. Users have a right to be confused if this is forced on them... Is removal of the ability to override bad certs the ONLY effective protection for such users? No. Vista/IE7 seems to ship with various scripting deactivated by default. So what happens? The page worked before, now it doesn't. Thats clearly a problem of the stupid new computer. So we ask the neighbour's kid to solve this and everything 'works'... Right. That's reality. I do though would like some sane alternative for people who are aware of the certificate stuff. The possibility to chose Yes/No/Ignore with one click and to optionally display certiciate details plus KCM info instead of a verbose warning. I would definately like to see the KCM deployed. Both of KCM and the CA-pki model work well enough when nothing is happening; now stuff is happening, and we need more. Use every tool we can, hopefully they can work together. Other than that, I would like to figure out a nice story that says use Firefox for all your general browsing ... but use for your online bank. I just don't know what is. I liked the google Chrome approach of separate VMs for each tab/page. There are definate limits to how we can expect a general user app like Firefox to firewall itself with quality code without general overflow protection ... putting hard boundaries around the virtual site within the browser is a very good idea, I think. Some people maintain separate Firefox installs. I've tried using fast user switching in MacOSX. But these are too hard to expect ordinary users to follow them. iang smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Ian G wrote: Steffen Schulz wrote: I find it amazing that someone shows this level of ignorance but then manages to file a bugreport... :-) [...] play with compilers, flags, build own browser, To provide the output shown at the end of https://bugzilla.mozilla.org/show_bug.cgi?id=460374#c0, typing about:buildconfig and copy-pasting is absolutely sufficient. This is not your average end-user. I'll bet you a dime to a dollar she knew precisely what the certificates are for. I don't think so. Kaspar ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Ian G wrote, On 2008-10-19 05:09: Ian G wrote: Nelson B Bolyard wrote: KCM would not have helped. I agree, KCM would not have helped. In both cases, the warnings are delivered, and the user is given the responsibility for the overrides. I was thinking about this, and actually, KCM would have helped here. No, it couldn't have. In fact, it could have been hurtful. If you look at the two cert viewers side by side, then there is a clear difference: https://bugzilla.mozilla.org/attachment.cgi?id=343662 https://bugzilla.mozilla.org/attachment.cgi?id=343663 Now, this info and the difference is available to the browser, which operating in KCM mode. It would be an easy thing to display the two certs, and the differences highlighted, perhaps in red or somesuch. This was a brand new installation. Formatted hard drive, reinstalled OS, installed browser. FIRST contact with every https site produced the self-signed cert warning. There simply were no other certs with which to compare. KCM would have accepted those certs without any complaint. THEN, later, if and when she came upon the REAL server certs from the real server, KCM would have warned her away! It would have said Wait, don't trust this new cert! And don't forget the Debian key generator. It showed us that a serious flaw in KCM is the complete lack of any revocation mechanism. I want to drive a stake through the heart of something, too. Can you guess what it is? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Eddy Nigg wrote, On 2008-10-18 20:10: Requiring a change to about:config would facilitate your needs (because you have the knowledge to do both - change the config and know what it means), while still protecting the standard user who neither cares about security nor has any clue what certificates are. Isn't that just a few more clicks? There are already lots of web pages telling users how to set up security exceptions, to work around the bug in FF3. Do you imagine that such pages would not also quickly arise for an about:config setting? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Nelson B Bolyard: Eddy Nigg wrote, On 2008-10-18 20:10: Requiring a change to about:config would facilitate your needs (because you have the knowledge to do both - change the config and know what it means), while still protecting the standard user who neither cares about security nor has any clue what certificates are. Isn't that just a few more clicks? There are already lots of web pages telling users how to set up security exceptions, to work around the bug in FF3. Do you imagine that such pages would not also quickly arise for an about:config setting? Yes, but the ones doing that must have a better knowledge about the browser. It still would effectively - I mean really effectively - prevent the other 99% from accessing such a site. Just think about the pain to search and understand what exactly to do in about:config. This isn't something my parents, wife and children would do, it's something _ME_ and _YOU_ would do. The ones who really need it belong either to the crowd which prefers to use self-signed certificates by all means or professionals, which are unfortunate enough to configure routers and other administrative sites and applications. However both of the groups know about the dangers involved (the former don't care and mostly never understood the meaning of certificates anyway, the later might be aware about the complications). -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Nelson B Bolyard wrote: Ian G wrote, On 2008-10-19 05:09: Ian G wrote: Nelson B Bolyard wrote: KCM would not have helped. I agree, KCM would not have helped. In both cases, the warnings are delivered, and the user is given the responsibility for the overrides. I was thinking about this, and actually, KCM would have helped here. No, it couldn't have. In fact, it could have been hurtful. If you look at the two cert viewers side by side, then there is a clear difference: https://bugzilla.mozilla.org/attachment.cgi?id=343662 https://bugzilla.mozilla.org/attachment.cgi?id=343663 Now, this info and the difference is available to the browser, which operating in KCM mode. It would be an easy thing to display the two certs, and the differences highlighted, perhaps in red or somesuch. This was a brand new installation. Formatted hard drive, reinstalled OS, installed browser. FIRST contact with every https site produced the self-signed cert warning. There simply were no other certs with which to compare. Lol... Yes, you are right, I missed that completely. KCM can not use the user's original validation if there was none before. (I commented on the bug about where our views diverge so I won't repeat that here.) KCM would have accepted those certs without any complaint. Ahhh, not exactly! With KCM, it is not up to it to accept any certs any time: unfamiliar certs are passed up to the user for validation. If the user does not validate, then she has done a bad thing. Yes, KCM would be at its weakest at that point, but no software tool is perfect; at some stage we have to ask the user, and then by definition the software is weak, dependent on the user. THEN, later, if and when she came upon the REAL server certs from the real server, KCM would have warned her away! It would have said Wait, don't trust this new cert! Right, that too ! Although, what I suggested above is a little better than disaster in this scenario. It would have presented her both certificates. If she had marked the self-signed one as good and then noticed that the new CA-signed bad one is superior because it has a brand name sig on it, this better info displayed would still have given her enough to deal with her upgrade attack. And don't forget the Debian key generator. It showed us that a serious flaw in KCM is the complete lack of any revocation mechanism. Not sure about that one? Do you mean all the SSH servers that were exposed to compromise because of the Debian OpenSSL random snafu? http://xkcd.com/424/ Sure, but the comparison is of chalk and cheese. In practice, the SSH community takes what it is given for free, and wouldn't trade that for all the revocation in the world. Even the nice low $$$ cost of a Startcom cert -- free! -- isn't going to wrest them away from their precious KCM, and for good reason: for that particular application, revocation isn't worth the costs that it would add to the solution. (Funnily enough, I used telnet with SSL support for a year or so back in 1995 :) I want to drive a stake through the heart of something, too. Can you guess what it is? This one I can guess [1] :) However, bear in mind that KCM still requires: the user has to validate the first time. If the user does not validate, then we have a potential problem. Compare and contrast: CA-signed models ask the user to validate when the certificates don't make sense to the algorithms. If the user does not validate, or validates badly, then the world will eventually drift to failures. Assuming that there is a requirement to validate, built into the system, then no tool can protect against a failure to validate. It's part of the system. iang [1] but I couldn't guess the one in your essay! smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Ian G: If the user does not validate, then she has done a bad thing. Yes, KCM would be at its weakest at that point, but no software tool is perfect; at some stage we have to ask the user, and then by definition the software is weak, dependent on the user. Chiming in here PKI wasn't meant to facilitate certificates issued from random. PKI is mean disallow anything it doesn't know and doesn't chain to the root. In the browser we have many roots, but it's the browser fault to allow the user to ignore and click all th way through to heaven...or hell. :-) PKI is mean to be strict (avoiding the word perfect)! It's not meant to be maybe valid, possibly chained to a root and likely not an MITM. It's meant to provide a clear YES/NO answer. PKI provides what KCM can not accomplish. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Eddy Nigg: PKI wasn't meant to facilitate certificates issued from random. PKI is mean disallow anything it doesn't know and doesn't chain to the root. In the browser we have many roots, but it's the browser fault to allow the user to ignore and click all th way through to heaven...or hell. :-) PKI is mean to be strict (avoiding the word perfect)! It's not meant to be maybe valid, possibly chained to a root and likely not an MITM. It's meant to provide a clear YES/NO answer. PKI provides what KCM can not accomplish. Arrg.../PKI is mean disallow/PKI is meant to disallow/ -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Ian G wrote, On 2008-10-19 15:17: Nelson B Bolyard wrote: KCM would have accepted those certs without any complaint. Ahhh, not exactly! With KCM, it is not up to it to accept any certs any time: unfamiliar certs are passed up to the user for validation. Yes, but the users are conditioned to accept all certs upon initial presentation. I used to think SSH's KCM model was pretty good, until someone (it was You, actually) opened my eyes to the fact that users do not attempt to verify key correctness, do not attempt to do out-of-band verification of key thumbprints or any other reasonable verification, but instead merely always assume that the key they get is valid, the first time they connect to the server. When I learned that, I contacted many people who were SSH aficionados, and they all confirmed the truth of that situation that had been too horrible for me to even imagine until it was told to me. So, today, I equate KCM with accepting all keys at face value, upon first contact. That's just what the victim in bug 460374 did. I would not say that it served her well. If the user does not validate, then she has done a bad thing. Um, er, well, in this case, she would have done a GOOD thing, no? And don't forget the Debian key generator. It showed us that a serious flaw in KCM is the complete lack of any revocation mechanism. Not sure about that one? Do you mean all the SSH servers that were exposed to compromise because of the Debian OpenSSL random snafu? Yes. And the 10MB file that SSH users must now drag around containing all those bad keys, since there is no service to which they can turn for revocation help. Even the nice low $$$ cost of a Startcom cert -- free! -- isn't going to wrest them away from their precious KCM, and for good reason: for that particular application, revocation isn't worth the costs that it would add to the solution. That 10MB file that they all must drag around now is an ongoing cost of the solution. It's a back breaker for browsers, more than doubling the size of the browser download to include that file. I want to drive a stake through the heart of something, too. Can you guess what it is? This one I can guess [1] :) [1] but I couldn't guess the one in your essay! I'm quite curious! What would you guess instead? If the user does not validate, or validates badly, then the world will eventually drift to failures. And you have taught me well that users simply do not validate, but merely accept all server keys at face value on initial contact. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Ian G wrote, On 2008-10-18 12:32: This is the pathological problem with MITM protection that has existed from day 1 of SSL: it was a solution in advance of a problem. Given that the solution was theoretical, and the problem had no practical existence (until recently), the solution could never be trialled against a real attacker. Add in some complexity, hello brittleness, meet shatter! Be careful not to confuse and conflict the MITM detection properties of SSL with the MITM resistance properties of the browser UI. As we see in this case, SSL did not fail to detect a single one of the attacks, but the browser UI allowed the value of that detection to be lost. Failure of browser UI is not a bad reflection on SSL, except to the extent that people who write about this confuse the two. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Ian G wrote, On 2008-10-19 05:50: [...] I would like to figure out a nice story that says use Firefox for all your general browsing ... but use for your online bank. I just don't know what is. As much as it pains me to say it, I agree. That is what is needed. This incident has shown that FF3, with its all-too-easy-to-defeat MITM reporting, is NOT suitable for high-value web transactions such as online banking. I wish (and have wished for a decade now) that Mozilla browsers WERE those browsers that were trustworthy enough to be relied upon for high value online transactions, such as online banking, but they are not. If I could find a product that was suitable, I would seek to work on it. I have little, and decreasing, desire to continue to invest in strong security for a product that discards that security for the masses, in exchange for acceptance by a very small number of people whose intense desire to be entirely self reliant causes them to insist on unverifiable security measures. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Nelson B Bolyard wrote, On 2008-10-19 19:03: Be careful not to confuse and conflict the MITM detection properties of SSL with the MITM resistance properties of the browser UI. s/conflict/conflate/ :( ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Nelson B Bolyard: This incident has shown that FF3, with its all-too-easy-to-defeat MITM reporting, is NOT suitable for high-value web transactions such as online banking. FF3 is suitable for people on this list. It appears that it's not yet suitable for the average user. At least FF3 succeeded in having the user complain about the broken browser, which is at least a step forward. The question which remains is perhaps, how many undetected and unreported events exist. Incidentally I'm browsing with browser.identity.ssl_domain_display set to 1, even though I'm perhaps one of the last persons needing it really. Instead the average user has to do without it...quite odd. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Nelson B Bolyard wrote: In bug https://bugzilla.mozilla.org/show_bug.cgi?id=460374 the reporter complained about how difficult it is to override bad cert errors in FF3. She complained because she was getting bad cert errors on EVERY https site she visited. ALL the https sites she visited were apparently presenting self-signed certs. The example for which she provided evidence was www.paypal.com. By the time she filed the bug, she had already overridden the bad cert errors for all the major https sites that she visited with any frequency, including facebook, myspace, hotmail, her college's network servers, and more. In hacker speak, she was *owned*. (Please discuss this here, not in that bug.) Despite all the additional obstacles that FF3 put in her way, and all the warnings about legitimate sites will never ask you to do this, she persisted in overriding every error, and thus giving away most of her valuable passwords to her attacker. Yep, no surprise. FF3 tries too hard, way too hard, imho. None of this had triggered any suspicion in the victim. She was merely upset that the browser made it so difficult for her to get to the sites she wanted to visit. She was complaining about the browser. FF3 had utterly failed to convey to her any understanding that she was under attack. I would say it slightly differently: it was clear that in her mind, the problem was the browser, not anything else. This is because for the last 14 years, and for the last 99.999% of times this has happened, it is the browser that is stopping her (and everyone like her) getting to the place she wanted to go. The mere fact that the browser provided a way to override the error was enough to convince her that the errors were not serious. History provided her the confidence that the errors were browser problems, not anything else. https://paypal.com/ Overrides didn't effect that situation. OTOH if you had removed the overrides she would have switched browser. Also note, she is pretty savvy, she compiles her own stuff it seems. I submit that the user received no real protection whatsoever from FF3 in this case. I agree. KCM would not have helped. I agree, KCM would not have helped. In both cases, the warnings are delivered, and the user is given the responsibility for the overrides. If anything, it would have reduced the pain of overriding those errors to the point where the victim would never have cried for help, and never would have learned of the attack to which she was a victim. Not sure about that, but it's probably moot :) The question is: how can FF3+ *effectively* protect users like her from MITM attackers better than FF3 has already done? It cannot. Note the above assumption that she made: there is no MITM, there cannot be an attack, this stupid UI is something made up by crazy people to annoy me. And, to a very high confidence level, she had a good assumption. I think there is a Bayesian logic that explains this fallacy somewhere, to do with what happens when the false negatives rate is too high. The only way any tool can protect her is if the assumption itself -- that the tool is broken -- is challenged. She needs to learn that there are MITMs. (Which she has now learnt. And, now, she will work with the UIs ...) Now, the broader question is about the wider public, and the wider MITMs. Will MITMs now become a regular enough topic to be a suitable learning experience? Will the wider public get a wider lesson? Only time will tell, and more data; one data point doesn't do more than tease us. Until that time, FF3's security UI is a skyscraper built on sand. This is the pathological problem with MITM protection that has existed from day 1 of SSL: it was a solution in advance of a problem. Given that the solution was theoretical, and the problem had no practical existence (until recently), the solution could never be trialled against a real attacker. Add in some complexity, hello brittleness, meet shatter! Which is to say, everything that has been done until now may have to be re-thought ... as it moves from theoretical to practical ... because now we face a real attacker. Assuming her attacker becomes common, only now can we find the right balance between overrides, convenience and protections, and losses. (Yes, we will face losses. Real security is about losses.) Is removal of the ability to override bad certs the ONLY effective protection for such users? No: in this case, removal of the overrides will (I speculate) convince her to switch browser. Yes: but only if you redesign the web to follow the principles of security architecture ;) The evolution of that UI is under discussion in bug https://bugzilla.mozilla.org/show_bug.cgi?id=431826 Nice case study! What would be wonderful is if you could ask her to go out and publicise her trauma. iang smime.p7s Description: S/MIME Cryptographic Signature
Re: MITM in the wild
Ian G: Nelson B Bolyard wrote: Despite all the additional obstacles that FF3 put in her way, and all the warnings about legitimate sites will never ask you to do this, she persisted in overriding every error, and thus giving away most of her valuable passwords to her attacker. Yep, no surprise. FF3 tries too hard, way too hard, imho. Quite the opposite...just imagine Firefox wouldn't have made it that hard and annoying, she wouldn't have filed a bug report and we wouldn't know. I would say it slightly differently: it was clear that in her mind, the problem was the browser, not anything else. This is because... ...she never saw how Firefox behaves with really secured web sites. for the last 14 years, and for the last 99.999% of times this has happened, it is the browser that is stopping her (and everyone like her) getting to the place she wanted to go. If that were true, we wouldn't have the problems today! But it's not true and the browser must convince the user that something is wrong. Otherwise not let to connect at all! The mere fact that the browser provided a way to override the error was enough to convince her that the errors were not serious. Nelson: Yes History provided her the confidence that the errors were browser problems, not anything else. https://paypal.com/ Paypal uses an EV certificate and wild cards are not allowed. However Paypal could fix this by adding paypal.com to the SAN. It's their shortcoming, not that of the browser. I submit that the user received no real protection whatsoever from FF3 in this case. Nelson: Only either because she was playing around with her own build and/or she never saw it functioning without being MITM'd. If anything, it would have reduced the pain of overriding those errors to the point where the victim would never have cried for help, and never would have learned of the attack to which she was a victim. Nelson: Correct! Not sure about that, but it's probably moot :) Not moot at all... The question is: how can FF3+ *effectively* protect users like her from MITM attackers better than FF3 has already done? Allow connecting to such sites only after modifying about:config It cannot. Note the above assumption that she made: there is no MITM, there cannot be an attack, this stupid UI is something made up by crazy people to annoy me. Where exactly did she say that? This is YOUR assumption, not hers. Is removal of the ability to override bad certs the ONLY effective protection for such users? Nelson: Yes, require editing of about:config Nice case study! What would be wonderful is if you could ask her to go out and publicise her trauma. I did that for here: http://www.linuxtoday.com/news_story.php3?ltsn=2008-10-18-012-35-OS-CY-NT -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
On 081018 at 20:30, Nelson B Bolyard wrote: FF3 had utterly failed to convey to her any understanding that she was under attack. The mere fact that the browser provided a way to override the error was enough to convince her that the errors were not serious. I find it amazing that someone shows this level of ignorance but then manages to file a bugreport... :-) KCM would not have helped. If anything, it would have reduced the pain of overriding those errors to the point where the victim would never have cried for help, and never would have learned of the attack to which she was a victim. The question is: how can FF3+ *effectively* protect users like her from MITM attackers better than FF3 has already done? Personally, I like the idea of a 'safe mode' in the browser. Safe-mode is very visible, provides limited scripting and https-only to a defined set of sites. If mom wants to go banking, she's been told she has to activate safe-mode. Otherwise banking is insecure. It is some action that the user initiates, she tells the program when some critical operation starts and ends. If she has to exit safe-mode to go to a bank then that is a very obvious decision to test her luck. Is removal of the ability to override bad certs the ONLY effective protection for such users? No. Vista/IE7 seems to ship with various scripting deactivated by default. So what happens? The page worked before, now it doesn't. Thats clearly a problem of the stupid new computer. So we ask the neighbour's kid to solve this and everything 'works'... I do though would like some sane alternative for people who are aware of the certificate stuff. The possibility to chose Yes/No/Ignore with one click and to optionally display certiciate details plus KCM info instead of a verbose warning. /steffen ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
On 10/18/2008 11:22 AM, Nelson B Bolyard wrote [in part]: Is removal of the ability to override bad certs the ONLY effective protection for such users? I visit some Web sites with self-signed certificates. None of those sites request any input from me. The only reason they have site certificates is that the site owners want to show off how technically astute they are. Hah! However, those sites do indeed contain information that I want. I definitely do not want to be locked out of them. I have also visited sites with incorrectly configured site certificates. In at least one situation, the owner decided to change the domain name without getting a new certificate for the new domain. In several cases, intermediate certificates were not installed, contrary to explicit instructions from the certificate authorities. I definitely do not want to be locked out of these sites either. -- David E. Ross http://www.rossde.com/ Go to Mozdev at http://www.mozdev.org/ for quick access to extensions for Firefox, Thunderbird, SeaMonkey, and other Mozilla-related applications. You can access Mozdev much more quickly than you can Mozilla Add-Ons. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
David E. Ross: I visit some Web sites with self-signed certificates. None of those sites request any input from me. The only reason they have site certificates is that the site owners want to show off how technically astute they are. Hah! However, those sites do indeed contain information that I want. I definitely do not want to be locked out of them. Connect to plain text then. I have also visited sites with incorrectly configured site certificates. In at least one situation, the owner decided to change the domain name without getting a new certificate for the new domain. In several cases, intermediate certificates were not installed, contrary to explicit instructions from the certificate authorities. I definitely do not want to be locked out of these sites either. When the visitor statistics suddenly goes down, web site owners will take action. Besides that I think Firefox MUST do a better job in case of missing CA certificates in the chain (yes, I'd prefer it also otherwise, but it's a too common error to ignore). In the end of the day, 98% of the time you'll be able to connect in plain http. For the other 2% there must be a way to visit that site - for you and other savvy users. Not for 99.9% of the users however. They should not visit such sites because they don't have the knowledge to differentiate between an attack and carelessness. Requiring a change to about:config would facilitate your needs (because you have the knowledge to do both - change the config and know what it means), while still protecting the standard user who neither cares about security nor has any clue what certificates are. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
