Re: Alerts on TLS Renegotiation
On Mon, 2010-04-19 at 15:10 -0500, Marsh Ray wrote: Direct your energy at the problem you want to solve. Talk to some server admins. Ask them why they are reluctant to take action. Find some real industry representatives. Ask for their help. The first thing they need from you is a convincing argument that this is real problem. Good plan, we've been at that process since last September. http://www.google.com/search?q=ssl+tls+project+mogul; Umm... I see lots of mentions of the Project Mogul name but no definitive project page giving the status of the PR effort. A more specific link, please? -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On Mon, 2010-04-19 at 14:00 -0700, Robert Relyea wrote: It's not going to look so great for Mozilla when another prominent browser vendor ships another patch which also notifies the user of the insecure connection. Mozilla is phasing in, just like Opera. You can see some in the list is violently opposed to any kind of notification. Does that mean you have accepted those people's arguments? Don't equivocate. -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 2010-04-18 21:16 PST, johnjbarton wrote: I see nothing wrong with users contacting sysadmins. I object to using the browser as a platform for badgering Web developers to contact sysadmins on your behalf. You continue to make the mistake of assuming that users have no vested self interest in having access to secure servers, and that they are merely doing a favor for some set of developers, rather than acting in their own self interest, by asking server admins to fix their servers. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 4/19/2010 1:42 AM, Nelson B Bolyard wrote: On 2010-04-18 21:16 PST, johnjbarton wrote: I see nothing wrong with users contacting sysadmins. I object to using the browser as a platform for badgering Web developers to contact sysadmins on your behalf. You continue to make the mistake of assuming that users have no vested self interest in having access to secure servers, and that they are merely doing a favor for some set of developers, rather than acting in their own self interest, by asking server admins to fix their servers. So by this argument we should warn users whenever they access pornographic sites, radical right wing sites, socialist sites, religious and atheist sites. We need to inform them, for their own self interest, that the server admins need to fix their servers. But why stop there? Users self interest surely extent beyond the browser. Should we send them messages to lobby against air pollution, poverty, government intrusion, and so on? Is it really true that CVE-2009-3555 is the only issue worthy of their attention? There are appropriate channels for advertising this problem and educating users and servers about it. The current Error Console spam campaign and the propose pop-up ads campaign are simply not appropriate actions for the browser. The browser's legitimate role here informs users on the connection they have to a server. If Firefox is presenting a user interface that shows a secure connection for https, but the connection is not secure according to the browser's security experts, then Firefox is broken. The legitimate action by browser developers is to fix their bug. jjb -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 2010/04/19 08:33 PDT, johnjbarton wrote: On 4/19/2010 1:42 AM, Nelson B Bolyard wrote: On 2010-04-18 21:16 PST, johnjbarton wrote: I see nothing wrong with users contacting sysadmins. I object to using the browser as a platform for badgering Web developers to contact sysadmins on your behalf. You continue to make the mistake of assuming that users have no vested self interest in having access to secure servers, and that they are merely doing a favor for some set of developers, rather than acting in their own self interest, by asking server admins to fix their servers. So by this argument we should warn users whenever they access pornographic sites, radical right wing sites, socialist sites, religious and atheist sites. That's silly. https doesn't protect users from site content. It protects users from interception and modification or falsification of content while in flight, provided that the client AND the server are both implementing SSL correctly. Users care about that because they don't want their passwords and other secrets stolen, as can now be done when used with broken servers. We need to inform them, for their own self interest, that the server admins need to fix their servers. Right. We've fixed the SSL code in the browser. Now it's the servers that need to be fixed. The users won't be fully protected until the servers are fixed. But why stop there? Users self interest surely extent beyond the browser. Should we send them messages to lobby against air pollution, poverty, government intrusion, and so on? Is it really true that CVE-2009-3555 is the only issue worthy of their attention? That's silly. It has nothing to do with the charter of https. The issues I'm discussing have everything to do with the charter of https. There are appropriate channels for advertising this problem and educating users and servers about it. The current Error Console spam campaign and the propose pop-up ads campaign are simply not appropriate actions for the browser. Your opinion is duly noted. The browser's legitimate role here informs users on the connection they have to a server. If Firefox is presenting a user interface that shows a secure connection for https, but the connection is not secure according to the browser's security experts, then Firefox is broken. I agree with that, too. The NSS SSL library accurately tells the browser about the reality of the situation. How the browser then informs the user of that situation is up to the browser, not up to NSS (NSS does no UI). The legitimate action by browser developers is to fix their bug. But that, by itself, does not provide the users with transport security. The industry is largely sticking its head in the sand, saying don't bother me with the facts, don't give me errors or warnings. I'd rather be ignorant of this huge security hole (and keep my users largely ignorant of it) than fix it. Someone has to watch out for the users' interest. Telling us that you'd prefer that Mozilla products kept silent about it tells us something about where you stand on the security-vs-convenience issue. It's not likely to engender much sympathy here. In this case, Mozilla has chosen to tell the users about this problem by this particular means. I'd prefer a more blatant means, but it's better than nothing. I appreciate that some effort is being made. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 4/19/2010 12:52 PM, Nelson B Bolyard wrote: On 2010/04/19 08:33 PDT, johnjbarton wrote: The legitimate action by browser developers is to fix their bug. But that, by itself, does not provide the users with transport security. Right, both the client and server have to be patched. It's not a bug in either one, but in the protocol itself. The industry is largely sticking its head in the sand, saying don't bother me with the facts, don't give me errors or warnings. I'd rather be ignorant of this huge security hole (and keep my users largely ignorant of it) than fix it. Someone has to watch out for the users' interest. I think many vendors have been quite concerned, but have been blocked on shipping a patch until the underlying library made it available. In some cases they could move faster because they wrote their own. In other cases the vendor really is taking it seriously but simply has a zillion products affected. For example, Opera was the first to ship a patch and they lead the way in accurately reflecting the security of the connection. Opera will currently decline to turn the address bar green for EV certs if the connection is vulnerable. That is a great first step, and they intend to make that more prominent over time, too. Mozilla also has the benefit of an internally developed TLS stack which implements a fix. Yet using Firefox 3.6.3 I don't see any visible indication of my https being vulnerable even in the Technical Details section of the Page Info dialog. It's not going to look so great for Mozilla when another prominent browser vendor ships another patch which also notifies the user of the insecure connection. People might legitimately ask at that point how such a prominent open source product as Mozilla ended up putting other considerations ahead of their user's security, whereas multiple commercial closed source vendors are really taking it seriously. It might be hard to come up a good answer for that one. Better start thinking about it now. - Marsh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 4/19/2010 1:32 PM, johnjbarton wrote: On 4/19/2010 10:52 AM, Nelson B Bolyard wrote: The industry is largely sticking its head in the sand, saying don't bother me with the facts, don't give me errors or warnings. I'd rather be ignorant of this huge security hole (and keep my users largely ignorant of it) than fix it. Someone has to watch out for the users' interest. You're making this up. No industry spokeperson, company representative, or unincorporated server admin has said any such thing. No, they say I'd rather keep the entire world completely ignorant of it until we have a chance to fix it in secret and release the fix in ohhow about a year from now? But suppose that in fact someone did say exactly what you quote. Why should you follow up by writing error messages in a console that no one in the industry ever sees? You saw it. I say you can make a difference! Direct your energy at the problem you want to solve. Talk to some server admins. Ask them why they are reluctant to take action. Find some real industry representatives. Ask for their help. The first thing they need from you is a convincing argument that this is real problem. Good plan, we've been at that process since last September. http://www.google.com/search?q=ssl+tls+project+mogul; Once they understand that their users are exposed to a security threat they will take prompt action. I thought so too. :-) And to their credit some have. It is for them that I think the process should be optimized. But in reality most users and admins are just stuck until they get a clean patch from their upstream vendor. The vast majority are waiting for it to be pushed down automatically. Telling us that you'd prefer that Mozilla products kept silent about it tells us something about where you stand on the security-vs-convenience issue. It's not likely to engender much sympathy here. I do not appreciate your continued misrepresentation of my comments on this newsgroup. I've had this conversation with Nelson many times. I don't think he's trying to misrepresent your comments as much as he's responding to some much more general and abstract forces. Nevertheless, to the extent that he is being specific I agree with him. I have made no comments on security-vs-convenience here. Well you're on a development list for an open source project here. The only reason I can see why you would object to the insecurity warning is that you find it 'inconvenient' to build the app for yourself with the one line that prints the warning commented out. The only sympathy I seek concerns the repeated, pointless, obscure messages that you are putting in my user interface about problems I did not cause and cannot fix. Well yeah. None of us here caused this, and none of us can fix it ourselves. We've worked hard to put together a fix to the protocol and to implement the fix in code. Now we need to get people to patch in a compatible way. I advocate informing the affected parties through whatever channels are appropriate. I think a error log message is very appropriate but do not want to stop there! I don't agree at all that such a message is pointless. I have spent huge amounts of time trying to get the accurate information out so that this very serious bug is not obscure. Obscurity only favors the bad guys here. - Marsh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 2010/04/19 11:32 PDT, johnjbarton wrote: On 4/19/2010 10:52 AM, Nelson B Bolyard wrote: On 2010/04/19 08:33 PDT, johnjbarton wrote: The browser's legitimate role here informs users on the connection they have to a server. If Firefox is presenting a user interface that shows a secure connection for https, but the connection is not secure according to the browser's security experts, then Firefox is broken. I agree with that, too. The NSS SSL library accurately tells the browser about the reality of the situation. How the browser then informs the user of that situation is up to the browser, not up to NSS (NSS does no UI). If this were true, I would not be here to complain. NSS does write to the Error Console, and that is my UI. Not true. Go find the line of code that writes to the error console. You will find that it is not in mozilla/security/NSS. But suppose that in fact someone did say exactly what you quote. Why should you follow up by writing error messages in a console that no one in the industry ever sees? Why should I? I do not, and have not. I work on NSS, a crypto library used in browsers and servers, which does no UI and calls no browser error console functions. The code about which you complain is not in NSS. You are complaining to the wrong person. Direct your energy at the problem you want to solve. Talk to some server admins. Ask them why they are reluctant to take action. Find some real industry representatives. Ask for their help. The first thing they need from you is a convincing argument that this is real problem. Once they understand that their users are exposed to a security threat they will take prompt action. I am a supplier of software. My relationship with any such people is like a person on the supplier's end of a rope. I can't get very far by pushing. The rope must be pulled. The people who will pull it from me will do so when others pull on a similar rope from them. Those others are the users. The users will pull their end of their ropes with their suppliers when they perceive they have a problem. But they don't read RFCs or CVEs where they'd see Marsh's name and mine. Someone must put this in their faces. I don't do UI. I am at the mercy of Firefox browser developers to inform the users of the problem. They have chosen to bother you about it rather than to bother the end users about it. That doesn't make me any happier than it makes you because the users who remain unaware of the problem will continue not to pull on the ropes between themselves and their server sys admins, and you complain to me, not to the Firefox developers who chose to annoy you. I repeat: In this case, Mozilla has chosen to tell the users about this problem by this particular means. I'd prefer a more blatant means, but it's better than nothing. I appreciate that some effort is being made. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On Fri, 2010-04-09 at 02:45 +0200, Kai Engert wrote: On 09.04.2010 00:41, Matt McCutchen wrote: On Thu, 2010-04-08 at 09:59 -0700, Robert Relyea wrote: The yellow larry is a good proposal, and probably implementable much sooner than noisy warnings. I'm glad you like it. I guess the next thing needed is for someone to actually implement it, perhaps me if I can figure out how. I wrote about this 3 months ago: https://bugzilla.mozilla.org/show_bug.cgi?id=535649#c3 Option (d) invent a new notification is the same as your proposal to show yellow. We'd have to do everything that I described there, related to (d), which is more work than simply switching to broken security or adding console output. In short, security level detection and GUI display are done at different layers of the software, so we'd have to add new signaling between layers. I understand. In addition, color should never be the only notification mechanism, because some people are color blind. So, if your proposed change is to only switch Larry to yellow, I believe it would be not sufficient. Users who cannot see hue may still notice the difference in brightness of the background compared to the text, at least on Linux where the blue background is dark. On Mac, I believe it is lighter. To help all users, even users who only get the text (e.g., using a screen reader), I propose to also add a question mark at the end of the text, e.g., mattmccutchen.net ? . -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On Sat, 2010-04-10 at 08:10 -0700, johnjbarton wrote: On 4/9/2010 6:06 PM, Matt McCutchen wrote: Are you saying that Mozilla shouldn't encourage users to bother their server operators because if the problem were real, the server operators would already have fixed it? I think you give the server operators way too much credit. People are lazy. I trust Mozilla much more than the average sysadmin to properly assess vulnerabilities. Your assessment of the relative commitment and competence of these two groups of people is unjustified by facts. Indeed, but do you have facts supporting the opposite conclusion? I appreciate your commitment to improving Web security. Please channel this passion in a respectful fashion. Rather than arrogantly asserting superiority over server admins and irresponsibly exhorting users to harass them, build a clearer case for the potential dangers here. Then contact the communications people in Mozilla, large international Web service companies, professional organizations of server administrators, news organizations, slash.dot, and so forth. Explain the problem and the fix. This procedure will prepare you and the people you contact for future similar problems and strengthen our entire system. A coordinated PR effort led by Mozilla would be great. However, I don't see what is wrong with users contacting their sysadmins individually to advocate that a vulnerability be patched, just as they would make any other request of the sysadmins. If the sysadmins want to make an argument that it isn't important in their particular case, fine, but the users have every right to ask. -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 4/18/2010 10:36 AM, Matt McCutchen wrote: On Sat, 2010-04-10 at 08:10 -0700, johnjbarton wrote: On 4/9/2010 6:06 PM, Matt McCutchen wrote: Are you saying that Mozilla shouldn't encourage users to bother their server operators because if the problem were real, the server operators would already have fixed it? I think you give the server operators way too much credit. People are lazy. I trust Mozilla much more than the average sysadmin to properly assess vulnerabilities. Your assessment of the relative commitment and competence of these two groups of people is unjustified by facts. Indeed, but do you have facts supporting the opposite conclusion? I assume this groups are equally committed, based on personal experience with both groups and common sense. I appreciate your commitment to improving Web security. Please channel this passion in a respectful fashion. Rather than arrogantly asserting superiority over server admins and irresponsibly exhorting users to harass them, build a clearer case for the potential dangers here. Then contact the communications people in Mozilla, large international Web service companies, professional organizations of server administrators, news organizations, slash.dot, and so forth. Explain the problem and the fix. This procedure will prepare you and the people you contact for future similar problems and strengthen our entire system. A coordinated PR effort led by Mozilla would be great. However, I don't see what is wrong with users contacting their sysadmins individually to advocate that a vulnerability be patched, just as they would make any other request of the sysadmins. If the sysadmins want to make an argument that it isn't important in their particular case, fine, but the users have every right to ask. I see nothing wrong with users contacting sysadmins. I object to using the browser as a platform for badgering Web developers to contact sysadmins on your behalf. jjb -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 4/14/2010 7:51 PM, Eddy Nigg wrote: It might be possible for the clients to ping the server if renegotiation (in old way) is supported at all. There are quite some servers out there that don't do that by default. With this, the pain could be perhaps mitigated. The claim was made here that the client software can only truly know if a server is secure in case RFC 5746 is supported. You can do a simple test with openssl's s_client utility. Connect to the server and type capital 'R'. That will tell you how the server responds client-initiated renegotiation. Unfortunately, there's no way for a client to tell if a server will ever do unsafe server-initiated renegotiation. It could be that by requesting an URL from one tiny little subdirectory on the site will cause the server to initiate renegotiation for the purpose of changing crypto requirements or requesting a client certificate. Yes, there lots of servers out there that will never renegotiate and are thus not vulnerable. Unfortunately, there's just no way for an SSLv3 or TLS client to determine this during the handshake. In the case of providing a client certificate to an HTTPS server, it's even worse. The server accepts a valid Finished message from the client and retro-actively authenticates the (attacker's) request. Because the client is required to send his Finished message before receiving the server's, the client does not have a chance to fully complete the process of strongly authenticating the server. Client cert credentials can thus be forwarded from the server to which the client intended to connect to an (unpatched) attacker-chosen server that will accept those credentials. Let's call it a duck, get everyone patched, and move on If that would have be as easy as you say it, we'd be living truly in a better world :-) Hey, somebody's gotta dream the impossible dream :-) Perhaps the best thing which will happen, is that old browsers finally will see the end of their time once most servers did upgrade. When that will happen, who knows... This is a really sticky protocol bug to fix. The worst part is that there are a lot of mitigations that seem like they would just almost work if But unfortuantely a solid fix for the general case requires a breaking protocol change. But this is not the first time a bug required everybody to patch or even migrate to a new protocol version. Yes, vendors, users, and admins will all have to use good judgment and find the tradeoff between security and compatibility for their own situation. But that is our responsibility after all, and I don't see it as necessarily bad to be having this discussion. - Marsh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 04/14/2010 02:58 AM, Marsh Ray: Here are some excerpts from http://tools.ietf.org/html/rfc5746 I tried to cut out some of the irrelevant details so as not to desensitize everybody with too much information :-) Thanks for your response here... So the RFC RECOMMENDED many times against doing things that are ultimately unsafe, but is also realistic. Perhaps quite right so... I was counting on the vendors of user agents and minimally-inspecting firewalls to inform and motivate the patching process. We need visible warnings which increase in prominence over time if we are going to dig our way out of this. It might be possible for the clients to ping the server if renegotiation (in old way) is supported at all. There are quite some servers out there that don't do that by default. With this, the pain could be perhaps mitigated. If the connection fails to provide data integrity and/or confidentiality against a demonstrable MitM, at some point we just have to admit it's not a secure connection worthy of a locked icon. The claim was made here that the client software can only truly know if a server is secure in case RFC 5746 is supported. Let's call it a duck, get everyone patched, and move on If that would have be as easy as you say it, we'd be living truly in a better world :-) Perhaps the best thing which will happen, is that old browsers finally will see the end of their time once most servers did upgrade. When that will happen, who knows... -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 12/04/2010 15:29, Eddy Nigg wrote: updated servers need updates clients and break older ones, whereas old servers will not allow new clients. I haven't seen one yet, that doesn't have a flag to accept older clients. If you set that flag, *and* disable renegotiation at least for older clients, you're safe. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 12/04/2010 15:29, Eddy Nigg wrote: updated servers need updates clients and break older ones, whereas old servers will not allow new clients. I haven't seen one yet, that doesn't have a flag to accept older clients. If you set that flag, *and* disable renegotiation at least for older clients, you're safe. Well, I think a client that doesn't implement RFC 5746 can't do renegotiation with a server that implements RFC 5746 and vice versa. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
Well, I think a client that doesn't implement RFC 5746 can't do renegotiation with a server that implements RFC 5746 and vice versa. In coming up with the wording of RFC 5746 we wanted to spell out what it would take to restore the (stated and implied) integrity guarantees offered by SSL/TLS, but we had to be a little realistic. After all, some may take the option of just not implementing it. Here are some excerpts from http://tools.ietf.org/html/rfc5746 I tried to cut out some of the irrelevant details so as not to desensitize everybody with too much information :-) [] merely because the server does not acknowledge the extension does not mean that it is vulnerable; it might choose to reject all renegotiations and simply not signal it. However, it is not possible for the client to determine purely via TLS mechanisms whether or not this is the case. If clients wish to ensure that such attacks are impossible, they need to terminate the connection immediately upon failure to receive the extension without completing the handshake. Such clients MUST [...] However, it is expected that many TLS servers that do not support renegotiation (and thus are not vulnerable) will not support this extension either, so in general, clients that implement this behavior will encounter interoperability problems. There is no set of client behaviors that will guarantee security and achieve maximum interoperability during the transition period. Clients need to choose one or the other preference when dealing with potentially un-upgraded servers. It is possible that un-upgraded servers will request that the client renegotiate. It is RECOMMENDED that clients refuse this renegotiation request. Clients that do so MUST [...] It is possible that the apparently un-upgraded server is in fact an attacker who is then allowing the client to renegotiate with a different, legitimate, upgraded server. If clients nevertheless choose to renegotiate, they MUST behave as described below. It is RECOMMENDED that servers not permit legacy renegotiation. If servers nevertheless do permit it, they MUST follow the requirements in this section. So the RFC RECOMMENDED many times against doing things that are ultimately unsafe, but is also realistic. I was counting on the vendors of user agents and minimally-inspecting firewalls to inform and motivate the patching process. We need visible warnings which increase in prominence over time if we are going to dig our way out of this. This argument about the scary page desensitizing users is a valid one, from one perspective. But that point of view only goes so far! The whole point of displaying a lock icon is that there exists a possibility that someday it does _not_ indicate the secure locked state. Failing to show the scary page when the scary page is appropriate is hardly better than a situation where some subset of users don't take it seriously (which will probably be the case regardless). If the connection fails to provide data integrity and/or confidentiality against a demonstrable MitM, at some point we just have to admit it's not a secure connection worthy of a locked icon. Let's call it a duck, get everyone patched, and move on. - Marsh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 2010-04-08 09:59 PST, Robert Relyea wrote: On 04/07/2010 09:35 PM, Nelson B Bolyard wrote: We plan on alerting users in a future update. This is fair warning to server operators and those who are debugging their sites. If this is a real threat don't users deserve a fair warning now? I fully agree! If users are vulnerable now, they should be warned now, (bug 535649 comment #15). The counterargument (comment #24) is that showing the broken SSL UI for almost all sites will quickly neutraliz[e] the awareness/protection it might offer, And that argument is now being successfully used by a lot of companies who make products that directly face the end users. They use it to avoid doing ANYTHING about this problem. They say we can't start to warn users until a majority of the servers on the net have gotten fixed, so that a minority generate the errors. And so users go unwarned, and they remain blissfully ignorant of their vulnerability. Coinsequently, they put no pressure on servers to get fixed. Consequently, there is NO pressure on servers to get fixed, and servers are not getting fixed at all rapidly. What in the world are you talking about here? You know very well what I'm talking about. The entire internet is broken right now. Correct. And intranets, too. Putting a warning dialog up now would only train users to ignore the warnings (we've seen this in the past). It will do more than that. It will alert people to the fact that the internet and all those intranets are entirely broken right now, a fact to which they are otherwise ENTIRELY IGNORANT. Case in point. I work in a small company, about 600 people. They have an IT department that uses mostly Microsoft servers. They use SSL on every server they can do so, yet all their servers are broken in this way. They are completely unaware of this problem. It will do me NO GOOD to go and tell them that all their servers are broken. They will think I'm a kook. They will say If our servers are broken, why don't all our client programs complain? That is why there is a console warning. You can still get that information from the console log, or even set the pref to disallow those connections. In any case to say that firefox is not doing ANYTHING about the problem is seriously mischaracterizing the problem. I believe our employees could not find that console report even if they were told about it and told to go look for it. It's too well buried by people who are deathly afraid of giving users a bad experience. The current response is in line with other well known and well respected browsers out there, unless you are acusing Yngve Petterson of security ignorance or laziness as well. Yngve is also begging the browser community to start sounding the alarm. The browsers are all deathly afraid of doing so. They all say we will start doing so when all the other browsers start doing so. .. The warnings will come -- WHEN? In 2010? In 2011? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 4/11/2010 7:48 PM, Nelson Bolyard wrote: On 2010-04-08 09:59 PST, Robert Relyea wrote: On 04/07/2010 09:35 PM, Nelson B Bolyard wrote: We plan on alerting users in a future update. This is fair warning to server operators and those who are debugging their sites. If this is a real threat don't users deserve a fair warning now? I fully agree! If users are vulnerable now, they should be warned now, (bug 535649 comment #15). The counterargument (comment #24) is that showing the broken SSL UI for almost all sites will quickly neutraliz[e] the awareness/protection it might offer, And that argument is now being successfully used by a lot of companies who make products that directly face the end users. They use it to avoid doing ANYTHING about this problem. They say we can't start to warn users until a majority of the servers on the net have gotten fixed, so that a minority generate the errors. And so users go unwarned, and they remain blissfully ignorant of their vulnerability. Coinsequently, they put no pressure on servers to get fixed. Consequently, there is NO pressure on servers to get fixed, and servers are not getting fixed at all rapidly. What in the world are you talking about here? You know very well what I'm talking about. The entire internet is broken right now. Correct. And intranets, too. Putting a warning dialog up now would only train users to ignore the warnings (we've seen this in the past). It will do more than that. It will alert people to the fact that the internet and all those intranets are entirely broken right now, a fact to which they are otherwise ENTIRELY IGNORANT. Case in point. I work in a small company, about 600 people. They have an IT department that uses mostly Microsoft servers. They use SSL on every server they can do so, yet all their servers are broken in this way. They are completely unaware of this problem. It will do me NO GOOD to go and tell them that all their servers are broken. They will think I'm a kook. They will say If our servers are broken, why don't all our client programs complain? They will think you are a kook if you run in yelling The Sky is Falling All you end up doing is annoying everyone. Consider a different approach. That is why there is a console warning. You can still get that information from the console log, or even set the pref to disallow those connections. In any case to say that firefox is not doing ANYTHING about the problem is seriously mischaracterizing the problem. I believe our employees could not find that console report even if they were told about it and told to go look for it. It's too well buried by people who are deathly afraid of giving users a bad experience. The current response is in line with other well known and well respected browsers out there, unless you are acusing Yngve Petterson of security ignorance or laziness as well. Yngve is also begging the browser community to start sounding the alarm. The browsers are all deathly afraid of doing so. They all say we will start doing so when all the other browsers start doing so. .. The warnings will come -- WHEN? In 2010? In 2011? When we see something more than an acorn. jjb -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 4/9/2010 6:06 PM, Matt McCutchen wrote: On Fri, 2010-04-09 at 09:34 -0700, johnjbarton wrote: On 4/8/2010 12:13 PM, Matt McCutchen wrote: On Thu, 2010-04-08 at 09:35 -0700, johnjbarton wrote: On 4/7/2010 9:35 PM, Nelson B Bolyard wrote: ... Inconveniencing the users is a NECESSARY part of getting this vulnerability fixed. Without that, the servers have NO INCENTIVE to lift a finger to fix this. ... The claim is obviously false as the recent update to Firefox 3.6.3 clearly demonstrates. If servers operators believe their users are at risk, then they will take immediate action to protect them. Firefox developers != server operators. Both groups are committed to their users and both groups will respond to realistic security threats to their users. Neither group should be blackmailed into pointless action by badgering users. Are you saying that Mozilla shouldn't encourage users to bother their server operators because if the problem were real, the server operators would already have fixed it? I think you give the server operators way too much credit. People are lazy. I trust Mozilla much more than the average sysadmin to properly assess vulnerabilities. Your assessment of the relative commitment and competence of these two groups of people is unjustified by facts. Besides, in my view, the problem is real. For better or for worse, the goal of SSL has always been to provide complete protection against a middleman who controls the network. And for certain designs of Web apps which are not intrinsically unreasonable (see my other message), it completely fails to prevent a middleman from subverting your requests. I appreciate your commitment to improving Web security. Please channel this passion in a respectful fashion. Rather than arrogantly asserting superiority over server admins and irresponsibly exhorting users to harass them, build a clearer case for the potential dangers here. Then contact the communications people in Mozilla, large international Web service companies, professional organizations of server administrators, news organizations, slash.dot, and so forth. Explain the problem and the fix. This procedure will prepare you and the people you contact for future similar problems and strengthen our entire system. jjb -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 4/8/2010 12:13 PM, Matt McCutchen wrote: On Thu, 2010-04-08 at 09:35 -0700, johnjbarton wrote: On 4/7/2010 9:35 PM, Nelson B Bolyard wrote: ... Inconveniencing the users is a NECESSARY part of getting this vulnerability fixed. Without that, the servers have NO INCENTIVE to lift a finger to fix this. ... The claim is obviously false as the recent update to Firefox 3.6.3 clearly demonstrates. If servers operators believe their users are at risk, then they will take immediate action to protect them. Firefox developers != server operators. Both groups are committed to their users and both groups will respond to realistic security threats to their users. Neither group should be blackmailed into pointless action by badgering users. jjb -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On Fri, 2010-04-09 at 09:34 -0700, johnjbarton wrote: On 4/8/2010 12:13 PM, Matt McCutchen wrote: On Thu, 2010-04-08 at 09:35 -0700, johnjbarton wrote: On 4/7/2010 9:35 PM, Nelson B Bolyard wrote: ... Inconveniencing the users is a NECESSARY part of getting this vulnerability fixed. Without that, the servers have NO INCENTIVE to lift a finger to fix this. ... The claim is obviously false as the recent update to Firefox 3.6.3 clearly demonstrates. If servers operators believe their users are at risk, then they will take immediate action to protect them. Firefox developers != server operators. Both groups are committed to their users and both groups will respond to realistic security threats to their users. Neither group should be blackmailed into pointless action by badgering users. Are you saying that Mozilla shouldn't encourage users to bother their server operators because if the problem were real, the server operators would already have fixed it? I think you give the server operators way too much credit. People are lazy. I trust Mozilla much more than the average sysadmin to properly assess vulnerabilities. Besides, in my view, the problem is real. For better or for worse, the goal of SSL has always been to provide complete protection against a middleman who controls the network. And for certain designs of Web apps which are not intrinsically unreasonable (see my other message), it completely fails to prevent a middleman from subverting your requests. -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 4/7/2010 9:35 PM, Nelson B Bolyard wrote: ... Inconveniencing the users is a NECESSARY part of getting this vulnerability fixed. Without that, the servers have NO INCENTIVE to lift a finger to fix this. ... The claim is obviously false as the recent update to Firefox 3.6.3 clearly demonstrates. If servers operators believe their users are at risk, then they will take immediate action to protect them. Using spam or pop-up ads to badger users in to lobbying on your behalf will drive them to other browsers. jjb -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 04/07/2010 09:35 PM, Nelson B Bolyard wrote: We plan on alerting users in a future update. This is fair warning to server operators and those who are debugging their sites. If this is a real threat don't users deserve a fair warning now? I fully agree! If users are vulnerable now, they should be warned now, (bug 535649 comment #15). The counterargument (comment #24) is that showing the broken SSL UI for almost all sites will quickly neutraliz[e] the awareness/protection it might offer, And that argument is now being successfully used by a lot of companies who make products that directly face the end users. They use it to avoid doing ANYTHING about this problem. They say we can't start to warn users until a majority of the servers on the net have gotten fixed, so that a minority generate the errors. And so users go unwarned, and they remain blissfully ignorant of their vulnerability. Coinsequently, they put no pressure on servers to get fixed. Consequently, there is NO pressure on servers to get fixed, and servers are not getting fixed at all rapidly. What in the world are you talking about here? The entire internet is broken right now. Putting a warning dialog up now would only train users to ignore the warnings (we've seen this in the past). That is why there is a console warning. You can still get that information from the console log, or even set the pref to disallow those connections. In any case to say that firefox is not doing ANYTHING about the problem is seriously mischaracterizing the problem. The current response is in line with other well known and well respected browsers out there, unless you are acusing Yngve Petterson of security ignorance or laziness as well... The warnings will come -- when they can have the most effect (that is pointing the user's wrath at the website rather than the browser). We are already getting action from websites from the console log warnings. AFAIK, Microsoft still has not released any renegotiation patches. NSS's patches are only 1 month old. Inconveniencing the users is a NECESSARY part of getting this vulnerability fixed. Without that, the servers have NO INCENTIVE to lift a finger to fix this. And allowing the security updates on servers to perculate out is also a necessary part. Don't worry, the hammer of noisy warnings are still in the tools shed, we just need to use it when it will do the most good. (Just before those last websites get turned off...). but I think my proposal for a yellow Larry button (comment #62) partially addresses this concern. Maybe, but you'll have to sell it to product makers who'd prefer not to annoy their users at all if their lives don't depend on it. The yellow larry is a good proposal, and probably implementable much sooner than noisy warnings. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On Thu, 2010-04-08 at 09:35 -0700, johnjbarton wrote: On 4/7/2010 9:35 PM, Nelson B Bolyard wrote: ... Inconveniencing the users is a NECESSARY part of getting this vulnerability fixed. Without that, the servers have NO INCENTIVE to lift a finger to fix this. ... The claim is obviously false as the recent update to Firefox 3.6.3 clearly demonstrates. If servers operators believe their users are at risk, then they will take immediate action to protect them. Firefox developers != server operators. -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 2010/04/08 09:35 PDT, johnjbarton wrote: On 4/7/2010 9:35 PM, Nelson B Bolyard wrote: ... Inconveniencing the users is a NECESSARY part of getting this vulnerability fixed. Without that, the servers have NO INCENTIVE to lift a finger to fix this. ... The claim is obviously false as the recent update to Firefox 3.6.3 clearly demonstrates. If servers operators believe their users are at risk, then they will take immediate action to protect them. Most server operators have not yet even HEARD of this vulnerability. In many cases the first way they ever will hear about it is from their annoyed users. Using spam or pop-up ads to badger users in to lobbying on your behalf will drive them to other browsers. On _MY_ behalf? certainly not! On their OWN behalf! Those users are the ones who stand to lose while their vulnerabilities and the vulnerabilities of the servers they use remain unfixed. It's in their own best interest to see those fixed. It is in their own interest that they will complain to their servers' admins. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On Thu, 2010-04-08 at 09:59 -0700, Robert Relyea wrote: The yellow larry is a good proposal, and probably implementable much sooner than noisy warnings. I'm glad you like it. I guess the next thing needed is for someone to actually implement it, perhaps me if I can figure out how. -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 09.04.2010 00:41, Matt McCutchen wrote: On Thu, 2010-04-08 at 09:59 -0700, Robert Relyea wrote: The yellow larry is a good proposal, and probably implementable much sooner than noisy warnings. I'm glad you like it. I guess the next thing needed is for someone to actually implement it, perhaps me if I can figure out how. I wrote about this 3 months ago: https://bugzilla.mozilla.org/show_bug.cgi?id=535649#c3 Option (d) invent a new notification is the same as your proposal to show yellow. We'd have to do everything that I described there, related to (d), which is more work than simply switching to broken security or adding console output. In short, security level detection and GUI display are done at different layers of the software, so we'd have to add new signaling between layers. In addition, color should never be the only notification mechanism, because some people are color blind. So, if your proposed change is to only switch Larry to yellow, I believe it would be not sufficient. Kai -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On Apr 3, 9:45 am, Jean-Marc Desperrier jmd...@free.fr wrote: It's the sites that need to catch on those updates. And web developers can have power to influence those sites to update. FWIW, I am a DreamHost customer and I just submitted a support ticket with them to close the vulnerability for customer sites (initially by refusing client-initiated renegotiation, eventually by implementing safe renegotiation). -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On Apr 4, 6:48 am, Eddy Nigg eddy_n...@startcom.org wrote: It's trivial from the logical point of view. That's easy for you to say. Even things that are logically trivial are easy to miss unless one goes carefully over every single step of the process. For instance, I used a little script to check certificates against private CAs for three months before I realized that validating against the CA that owns the CN is the wrong thing to do when the certificate might have matched the expected hostname using a SAN. Logically trivial, but I wasn't thinking carefully and I missed it. -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 4/4/2010 10:41 PM, Daniel Veditz wrote: On 4/3/10 9:30 AM, johnjbarton wrote: If the *users* of Firefox are truly in jeopardy, then this alert should be provided to *users*. Since this alert is not shown to users I can only assume that in fact there is no practical threat here. You're putting this message in the Error Console because you can. We plan on alerting users in a future update. This is fair warning to server operators and those who are debugging their sites. If this is a real threat don't users deserve a fair warning now? How is it ok to let users be compromised only for a while? The Firefox 3.6.3 release shows how Mozilla can react if it knows about a real threat. So I have to conclude that you believe this threat is not significant. In that case working to close this potential problem is a laudable work we all thank you for. Just please choose a more appropriate communications channel. jjb -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On Wed, 2010-04-07 at 09:55 -0700, johnjbarton wrote: On 4/4/2010 10:41 PM, Daniel Veditz wrote: On 4/3/10 9:30 AM, johnjbarton wrote: If the *users* of Firefox are truly in jeopardy, then this alert should be provided to *users*. Since this alert is not shown to users I can only assume that in fact there is no practical threat here. You're putting this message in the Error Console because you can. We plan on alerting users in a future update. This is fair warning to server operators and those who are debugging their sites. If this is a real threat don't users deserve a fair warning now? I fully agree! If users are vulnerable now, they should be warned now, (bug 535649 comment #15). The counterargument (comment #24) is that showing the broken SSL UI for almost all sites will quickly neutraliz[e] the awareness/protection it might offer, but I think my proposal for a yellow Larry button (comment #62) partially addresses this concern. -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 2010/04/07 10:43 PDT, Matt McCutchen wrote: On Wed, 2010-04-07 at 09:55 -0700, johnjbarton wrote: On 4/4/2010 10:41 PM, Daniel Veditz wrote: We plan on alerting users in a future update. This is fair warning to server operators and those who are debugging their sites. If this is a real threat don't users deserve a fair warning now? I fully agree! If users are vulnerable now, they should be warned now, (bug 535649 comment #15). The counterargument (comment #24) is that showing the broken SSL UI for almost all sites will quickly neutraliz[e] the awareness/protection it might offer, And that argument is now being successfully used by a lot of companies who make products that directly face the end users. They use it to avoid doing ANYTHING about this problem. They say we can't start to warn users until a majority of the servers on the net have gotten fixed, so that a minority generate the errors. And so users go unwarned, and they remain blissfully ignorant of their vulnerability. Coinsequently, they put no pressure on servers to get fixed. Consequently, there is NO pressure on servers to get fixed, and servers are not getting fixed at all rapidly. Inconveniencing the users is a NECESSARY part of getting this vulnerability fixed. Without that, the servers have NO INCENTIVE to lift a finger to fix this. but I think my proposal for a yellow Larry button (comment #62) partially addresses this concern. Maybe, but you'll have to sell it to product makers who'd prefer not to annoy their users at all if their lives don't depend on it. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 4/3/10 9:30 AM, johnjbarton wrote: If the *users* of Firefox are truly in jeopardy, then this alert should be provided to *users*. Since this alert is not shown to users I can only assume that in fact there is no practical threat here. You're putting this message in the Error Console because you can. We plan on alerting users in a future update. This is fair warning to server operators and those who are debugging their sites. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 2010-04-03 04:29 PST, Eddy Nigg wrote: On 04/03/2010 01:07 PM, Nelson B Bolyard: This is true because the attacker can arrange it so that the victim client's first handshake is actually a renegotiation for the server. It's NOT a renegotiation for the client, but it IS for the server. The server has previously negotiated with the attacker, and thinks that it is renegotiating with the attacker, but is actually doing a negotiation with the victim client. To the server it looks like a renegotiation. To the victim client, it looks EXACTLY like a first handshake, not a renegotiation. Whatever credentials the victim client provides in its initial request (client auth, or a cookie, or a basic auth password) will be seen by the vulnerable server as having come from the attacker, because the server thinks it's renegotiating with the attacker. That's how the attack works, and how the attacker uses the victims credentials. I can see how this can work in cases where all other data to be exploited can be prepend by the attacker. Still, those are probably very rare and unfortunate circumstances, it mustn't happen. Let me tell you about one very simple attack. (I think this is old enough now that the details are no longer big news in the hacking community.) The MITM has an account on an SMTP server on the same host as an https server. The SMTP server and the https server on that host use the same server certificate. The attacker arranges to intercept the victim client's https requests and connect them to the email server (!). The attacker first connects to the email server and sends it a set of info that looks like it's starting to send an email. He sends all the email headers, so that it appears to be sending an email to himself, and is simply awaiting the message body. Then he starts the renegotiation as seen by the server, and splices in the connection from the victim client. The victim client connects to the MITM, thinking that it is connecting to the https server, and sends its https request, with its usual https request cookie by which it authenticates itself to the https server. But this information is going into the body of an email to be mailed to the attacker. The attacker receives the email, takes the cookies out of it, and then impersonates the victim to the https server. This has been exploited more than once. Yes there are some tricks. Email message bodies are supposed to end with a line that start with a . and contains only that .. This can be arranged. I won't explain how. There are other methods. An in house attacker can get a corporate expense check issued to himself just by having someone else who is authorized to issue such checks to merely login. (What do you mean The check you requested has been issued? What check? I just logged in?!?!?) That's been exploited too. Now, the way that a [client] protects itself from a server's vulnerability is that, in the client hello message, it asks the server are you fixed? A Fixed server will answer affirmatively in its server hello message, [and later in the handshake will prove that this is true] and an unfixed old server will ignore the request. When the client gets back the server's hello message, if it doesn't contain the extension that says yes, I'm fixed, the client should drop that handshake right then and there, like a hot potato. Now I have a question I wanted to ask for a long time. Considering that this design flaw existed for some 14 years and more...how come nobody ever thought about this earlier? Isn't it amazing that such a fairly trivial exploit existed for such a long time? Yourself know the SSL protocols in and out and never thought about it? It's not so trivial. What the MITM must do to arrange this handshake that appears to the server to be a renegotiation but to the client to be a first negotiation is quite involved. No one ever though of it until last year, apparently. It seems to have eluded the entire TLS working group until last year. I did wonder about this once or twice over 13 years, but didn't see any way to exploit it and so I thought it was safe. Someone finally found a way. Thank goodness Marsh Ray wears a white hat! -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 04/04/2010 09:34 AM, Nelson B Bolyard: It's not so trivial. It's trivial from the logical point of view. I did wonder about this once or twice over 13 years, but didn't see any way to exploit it and so I thought it was safe. Someone finally found a way. Thank goodness Marsh Ray wears a white hat! Unfortunately we don't know how many times this has been used successfully. Thanks for the explanations, it broadened my understanding about its potential misuse. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 2010-04-02 14:06 PST, Eddy Nigg wrote: Hi Bob, On 04/02/2010 01:34 AM, Robert Relyea: When a client (as in our case Firefox) implements RFC 5746, the client can't be compromised and no data is leaked from the client. I propose that Firefox should support the RFC 5746 extension exclusively, but NOT block or warn on accessing servers which don't support the extension. Any renegotiation attempt to the client will be ignored and no data is leaked. Not true. Any client can be compromised as long as it accepts connections with servers that do not understand RFC 5746. A client that does SSL3 or TLS and *NEVER* renegotiates can be vulnerable. I don't have the intention to continue the argument because I've received already some answers which addressed part of my concerns. But for the better understanding I'd be interested to know how a client that doesn't renegotiate can be vulnerable. Are you saying that the client can leak data without renegotiation? Yes, Eddy. Any client that completes just a first handshake (not a renegotiation, just a first handshake) with a vulnerable server becomes vulnerable itself. The client becomes vulnerable by virtue of dealing with the vulnerable server. It's a real threat, demonstrable. It has been actually exploited. The ONLY way for a client to protect itself from this vulnerability, when dealing with a vulnerable server is to detect, early in the client's first handshake, that the server is vulnerable, and then NOT complete the first handshake because of that. If the client detects the server's vulnerability, but goes ahead and completes the handshake, the damage is done. Believe it. This is true because the attacker can arrange it so that the victim client's first handshake is actually a renegotiation for the server. It's NOT a renegotiation for the client, but it IS for the server. The server has previously negotiated with the attacker, and thinks that it is renegotiating with the attacker, but is actually doing a negotiation with the victim client. To the server it looks like a renegotiation. To the victim client, it looks EXACTLY like a first handshake, not a renegotiation. Whatever credentials the victim client provides in its initial request (client auth, or a cookie, or a basic auth password) will be seen by the vulnerable server as having come from the attacker, because the server thinks it's renegotiating with the attacker. That's how the attack works, and how the attacker uses the victims credentials. Now, the way that a protects itself from a server's vulnerability is that, in the client hello message, it asks the server are you fixed? A Fixed server will answer affirmatively in its server hello message, and an unfixed old server will ignore the request. When the client gets back the server's hello message, if it doesn't contain the extension that says yes, I'm fixed, the client should drop that handshake right then and there, like a hot potato. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 04/03/2010 01:07 PM, Nelson B Bolyard: This is true because the attacker can arrange it so that the victim client's first handshake is actually a renegotiation for the server. It's NOT a renegotiation for the client, but it IS for the server. The server has previously negotiated with the attacker, and thinks that it is renegotiating with the attacker, but is actually doing a negotiation with the victim client. To the server it looks like a renegotiation. To the victim client, it looks EXACTLY like a first handshake, not a renegotiation. Whatever credentials the victim client provides in its initial request (client auth, or a cookie, or a basic auth password) will be seen by the vulnerable server as having come from the attacker, because the server thinks it's renegotiating with the attacker. That's how the attack works, and how the attacker uses the victims credentials. I can see how this can work in cases where all other data to be exploited can be prepend by the attacker. Still, those are probably very rare and unfortunate circumstances, it mustn't happen. Now, the way that a protects itself from a server's vulnerability is that, in the client hello message, it asks the server are you fixed? A Fixed server will answer affirmatively in its server hello message, and an unfixed old server will ignore the request. When the client gets back the server's hello message, if it doesn't contain the extension that says yes, I'm fixed, the client should drop that handshake right then and there, like a hot potato. Now I have a question I wanted to ask for a long time. Considering that this design flaw existed for some 14 years and more...how come nobody ever thought about this earlier? Isn't it amazing that such a fairly trivial exploit existed for such a long time? Yourself know the SSL protocols in and out and never thought about it? -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 02/04/2010 18:25, johnjbarton wrote: The appropriate way to address this security problem starts by contacting the major providers of server software There's no need to contact them, they are well aware of the problem. AFAIK they have all already issued the necessary updates. It's the sites that need to catch on those updates. And web developers can have power to influence those sites to update. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 4/3/2010 6:45 AM, Jean-Marc Desperrier wrote: On 02/04/2010 18:25, johnjbarton wrote: The appropriate way to address this security problem starts by contacting the major providers of server software There's no need to contact them, they are well aware of the problem. AFAIK they have all already issued the necessary updates. It's the sites that need to catch on those updates. And web developers can have power to influence those sites to update. I think your assessment of the relationship between Web developers and server infrastructure is based on dated information. These days only a tiny fraction of the Web pages are served from sites where the developer even knows who runs the server. But even if there was a relationship, sending unsolicited, mass electronic communications in an effort to goad people into lobbying for your cause abuses your position of responsibility. Please reconsider. If the *users* of Firefox are truly in jeopardy, then this alert should be provided to *users*. Since this alert is not shown to users I can only assume that in fact there is no practical threat here. You're putting this message in the Error Console because you can. jjb -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
johnjbarton wrote: Closely related to bug 554594 is https://bugzilla.mozilla.org/show_bug.cgi?id=535649 Web developers using Firefox Error Console or tools like Firebug that use nsIConsoleService are now bombarded with pointless messages like: services.addons.mozilla.org : potentially vulnerable to CVE-2009-3555 No, what's closely related to this is https://bugzilla.mozilla.org/show_bug.cgi?id=555952 Implement RFC 5746 for mozilla.org SSL sites, to avoid Mozilla warning about CVE-2009-3555 As soon as the proper version of Zeus is deployed, this should be fixed. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 04/02/2010 01:37 AM, Daniel Veditz: SSL is a building-block and is supposed to guarantee an authenticated, encrypted, tamper-proof connection to the application layers above. Yes, obviously I agree with this statement entirely and RFC 5746 fixes that. You don't know that! Depends on what the client is doing and what the server is. My argument is, that you know what a client which implements RFC 5746 does. What if the attack is to make the client connect to an open redirector on the target site? The client could leak all kinds of data by sending it to the wrong site. No, that shouldn't work anymore with a RFC 5746 compliant client. SSLv2 was disabled in Firefox only a short while ago, Three and a half years ago, October 2006 (longer if you count six months of 2.0 pre-release builds). Phhhis it really that long ago already? Anyway, it took some ten years after the introduction of SSLv3 to turn it off. That's a long time. Then we would be foolish to toggle the default on that pref any time soon. Thank you, that's what I wanted to hear. Why? Those are two separate prefs. The user can easily speak to servers without rfc 5746 and still refuse unsafe renegotiation. Correct. But you know this because Minefield broke client-auth on your site with precisely these settings. What's your real point? Exactly that was a warning sign for me about how easy it can break. 99.9% of bank customers will never have their bank go out of business. Don't say never - Lehman Brothers anyone? And another couple of regional banks in the US alone during the last year, actually in the hundreds :-) But back to our subject, it also depends on what the other browser vendors will do and when. When I did the risk assessment I came to the conclusion that when using an RFC 5746 compliant client, the risk for exploiting it, is incredible low. I believe the risks of SSLv2 were higher on a practical level. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 4/2/2010 2:22 AM, Jean-Marc Desperrier wrote: johnjbarton wrote: Closely related to bug 554594 is https://bugzilla.mozilla.org/show_bug.cgi?id=535649 Web developers using Firefox Error Console or tools like Firebug that use nsIConsoleService are now bombarded with pointless messages like: services.addons.mozilla.org : potentially vulnerable to CVE-2009-3555 No, what's closely related to this is https://bugzilla.mozilla.org/show_bug.cgi?id=555952 Implement RFC 5746 for mozilla.org SSL sites, to avoid Mozilla warning about CVE-2009-3555 As soon as the proper version of Zeus is deployed, this should be fixed. Sorry, but your statement misses exactly the problem here. Bug 535649 emits a warning message for every https site you visit. The only people who can see this message are Web developers and users who have problems with Firefox. These people are almost never in a position to prevent the message. Only the people who maintain the server software itself can prevent this message, and they of course never look at the Firefox Error Console. While it is embarrassing that one hand of Mozilla would announce to developers that Mozilla sites are insecure before the other hand fixed the sites, that entirely misses the point. This obscure message comes for all https sites and is directed at the wrong people. It causes work and anxious concern among people who have no control over the problem. The appropriate way to address this security problem starts by contacting the major providers of server software. By contacting just the top 10 teams you can cover 99% of the worlds servers: http://news.netcraft.com/archives/web_server_survey.html Web server providers are very concerned about user security and they would respond promptly to any real security threat. This is not true for Web devs being spammed with this message: it's not their problem. jjb -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
Hi Bob, On 04/02/2010 01:34 AM, Robert Relyea: When a client (as in our case Firefox) implements RFC 5746, the client can't be compromised and no data is leaked from the client. I propose that Firefox should support the RFC 5746 extension exclusively, but NOT block or warn on accessing servers which don't support the extension. Any renegotiation attempt to the client will be ignored and no data is leaked. Not true. Any client can be compromised as long as it accepts connections with servers that do not understand RFC 5746. A client that does SSL3 or TLS and *NEVER* renegotiates can be vulnerable. I don't have the intention to continue the argument because I've received already some answers which addressed part of my concerns. But for the better understanding I'd be interested to know how a client that doesn't renegotiate can be vulnerable. Are you saying that the client can leak data without renegotiation? The only benefit clients have in installing RFC5746 is that servers that require renegotiation and install the update to provide safe renegotiation from the server stand point. I believe the client will also reject any renegotiation attempt according to the old protocol. There's a difference. There's a real vulnerability. Expect that time line to be accellerated for this RFC. (Probably still talk order of magnitude 1 year, not 1 decade or 1 month). Realistically that's perhaps more into a few years. Older Apache and Windows 2003 servers are still widely deployed and will most likely not be updated. Newer versions will probably receive updates, there will be always some which never update. Those will be the your certificates don't work ones we'll have to deal with... They are still talking a broken protocol, and clients need to defend themselves. It's this fact that allows us to stage deploy. The risk is pretty low of a compromise. That's my understanding as well - part of the argument. We know there are backwaters of conservative people who don't update their servers. There is a cost associated with that. If they don't update, no modern browser will be able to talk to them. From my experience even a share of 1% can prevent the advantage of better standards. Just think about non-standard domain names in CN fields or RSA key sizes above 1024 to mention only a few. This is not a mozilla unilateral decision. It's made in concert with other browser vendors. If all parties pull at the same string, this might work. So far this has seldom worked. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 03/31/2010 06:48 PM, Eddy Nigg: On 03/31/2010 04:45 PM, Kai Engert: == snip quote begin == E.g., the attacker would send: GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1 X-Ignore-This: And the server uses the victim's account to send a pizza to the attacker. === snip quote end === This attack is highly theoretical beyond believe, specially the X-Ignore-This-and-That headers. Is has no real and practical value whatsoever. Here some interesting observations and opinion by others: http://blogs.technet.com/srd/archive/2010/02/09/details-on-the-new-tls-advisory.aspx X-Abuse-Me: X-Description: I will ignore any content in Abuse-Me header X-More-Description: I accept headers also after the body part has been sent X-Conclusion: I'm vulnerable to user input and on transit -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 03/31/2010 05:26 AM, Eddy Nigg wrote: [ Please follow up to mozilla.dev.tech.crypto ] After some discussion at bug 554594 I'm following up here - the bug was unfortunately misused by me a little for the initial discussion. At https://wiki.mozilla.org/Security:Renegotiation under item 4.4 the following is proposed: security.ssl.require_safe_negotiation If set to true, a Mozilla client will reject *all* connection attempts to servers that are still using the old SSL/TLS protocol and which might be vulnerable to the attack. This issue has been debated extensively on the ieft mailing list. I suggest to read through all of those comments first. Nutshell. SSL/TLS without RFC 5746 is effectively dead. The renegotiation bug is a bug in the underlying protocol. This means the protocol needs to be patched. Everywhere. The RFC 5746 specifically states that the client must reject the connection if the extension is not present. This clause is 'watered-down' a bit because the reality is it will take time for servers to get updated. This option is for the ultra-paranoid. At some point in time it will be reasonable to turn it on. At another point in time it will be a default. Note that today it defaults to OFF. I believe this to be a mistake for various reasons, but first and foremost because an attack on a server without compromise of the client data as well, is basically useless. When a attacker induces renegotiation at the server, the attacker must have client credentials in order to act as if he were the original client. Without those credentials, the attacker would be treated as any other unauthenticated source. This is problematic for 2 reasons: 1) there not an insignificant number of servers out which are not well administered. and 2) it's impossible for clients to tell whether or not a server will be vulnerable. The underlying assumption that this is a server problem is false. It's a protocol problem. We must determine that the server is using a sufficiently advanced protocol for us to be safe. When a client (as in our case Firefox) implements RFC 5746, the client can't be compromised and no data is leaked from the client. I propose that Firefox should support the RFC 5746 extension exclusively, but NOT block or warn on accessing servers which don't support the extension. Any renegotiation attempt to the client will be ignored and no data is leaked. Not true. Any client can be compromised as long as it accepts connections with servers that do not understand RFC 5746. A client that does SSL3 or TLS and *NEVER* renegotiates can be vulnerable. The only benefit clients have in installing RFC5746 is that servers that require renegotiation and install the update to provide safe renegotiation from the server stand point. The advantage for this approach would be earlier support of RFC 5746 which would facilitate safe renegotiation with servers that support it, but still allows to support servers which don't support it. What are you talking about? The default for this option is *OFF* for precisely this reason. We need to stage deployment of RFC 5746. Both clients and servers need to deal with the world that old protocols are out there for a time. SSLv2 was disabled in Firefox only a short while ago, despite the fact that newer protocols were available for most of the last 14 years. I expect that it will take years upon years until 90% of all SSL enabled servers will support RFC 5746, not speaking about 99% or higher. Refusing to speak to servers that don't support RFC 5746 - even if the sites probably never need renegotiation - will have an undesired effect, either by breaking SSL entirely or forcing the user to accept unsafe renegotiation, which will leave the user vulnerable once again. There's a difference. There's a real vulnerability. Expect that time line to be accellerated for this RFC. (Probably still talk order of magnitude 1 year, not 1 decade or 1 month). It also must be noted that 99% or more of all SSL enabled web sites will never need renegotiation to work. A server which disabled renegotiation is at least as secure as a server supporting the new extension. Those that need it will probably patch their servers sooner or later and are not a concern IMO. They are still talking a broken protocol, and clients need to defend themselves. It's this fact that allows us to stage deploy. The risk is pretty low of a compromise. Otherwise we would have a much more aggressive schedule for deployment. We know there are backwaters of conservative people who don't update their servers. There is a cost associated with that. If they don't update, no modern browser will be able to talk to them. This is not a mozilla unilateral decision. It's made in concert with other browser vendors. bob -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 3/31/10 5:26 AM, Eddy Nigg wrote: security.ssl.require_safe_negotiation I believe this to be a mistake for various reasons, but first and foremost because an attack on a server without compromise of the client data as well, is basically useless. When a attacker induces renegotiation at the server, the attacker must have client credentials in order to act as if he were the original client. Without those credentials, the attacker would be treated as any other unauthenticated source. The client supplies the credentials. Not every server or application is equally vulnerable, not all SSL connections use the HTTP protocol. Sure, there may be specific attacks due to this flaw that could be prevented in other ways (a typical anti-CSRF nonce in a web form, say) but that is not a general defense. SSL is a building-block and is supposed to guarantee an authenticated, encrypted, tamper-proof connection to the application layers above. It was broken and turns out to allow the injection of prefix content in some situations. Whether that can lead to compromise depends on what was built above the SSL layer. When a client (as in our case Firefox) implements RFC 5746, the client can't be compromised and no data is leaked from the client. You don't know that! Depends on what the client is doing and what the server is. What if the attack is to make the client connect to an open redirector on the target site? The client could leak all kinds of data by sending it to the wrong site. SSLv2 was disabled in Firefox only a short while ago, Three and a half years ago, October 2006 (longer if you count six months of 2.0 pre-release builds). But the ability for users to choose to disable it was available for years before that. I expect that it will take years upon years until 90% of all SSL enabled servers will support RFC 5746, not speaking about 99% or higher. Then we would be foolish to toggle the default on that pref any time soon. Refusing to speak to servers that don't support RFC 5746 [... will force] the user to accept unsafe renegotiation Why? Those are two separate prefs. The user can easily speak to servers without rfc 5746 and still refuse unsafe renegotiation. But you know this because Minefield broke client-auth on your site with precisely these settings. What's your real point? It also must be noted that 99% or more of all SSL enabled web sites will never need renegotiation to work. A server which disabled renegotiation is at least as secure as a server supporting the new extension. 99.9% of bank customers will never have their bank go out of business. Why should they bother to check whether their bank is federally insured? -Dan Veditz -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Alerts on TLS Renegotiation
[ Please follow up to mozilla.dev.tech.crypto ] After some discussion at bug 554594 I'm following up here - the bug was unfortunately misused by me a little for the initial discussion. At https://wiki.mozilla.org/Security:Renegotiation under item 4.4 the following is proposed: security.ssl.require_safe_negotiation If set to true, a Mozilla client will reject *all* connection attempts to servers that are still using the old SSL/TLS protocol and which might be vulnerable to the attack. I believe this to be a mistake for various reasons, but first and foremost because an attack on a server without compromise of the client data as well, is basically useless. When a attacker induces renegotiation at the server, the attacker must have client credentials in order to act as if he were the original client. Without those credentials, the attacker would be treated as any other unauthenticated source. When a client (as in our case Firefox) implements RFC 5746, the client can't be compromised and no data is leaked from the client. I propose that Firefox should support the RFC 5746 extension exclusively, but NOT block or warn on accessing servers which don't support the extension. Any renegotiation attempt to the client will be ignored and no data is leaked. The advantage for this approach would be earlier support of RFC 5746 which would facilitate safe renegotiation with servers that support it, but still allows to support servers which don't support it. SSLv2 was disabled in Firefox only a short while ago, despite the fact that newer protocols were available for most of the last 14 years. I expect that it will take years upon years until 90% of all SSL enabled servers will support RFC 5746, not speaking about 99% or higher. Refusing to speak to servers that don't support RFC 5746 - even if the sites probably never need renegotiation - will have an undesired effect, either by breaking SSL entirely or forcing the user to accept unsafe renegotiation, which will leave the user vulnerable once again. It also must be noted that 99% or more of all SSL enabled web sites will never need renegotiation to work. A server which disabled renegotiation is at least as secure as a server supporting the new extension. Those that need it will probably patch their servers sooner or later and are not a concern IMO. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 31.03.2010 14:26, Eddy Nigg wrote: [ Please follow up to mozilla.dev.tech.crypto ] After some discussion at bug 554594 I'm following up here - the bug was unfortunately misused by me a little for the initial discussion. At https://wiki.mozilla.org/Security:Renegotiation under item 4.4 the following is proposed: security.ssl.require_safe_negotiation If set to true, a Mozilla client will reject *all* connection attempts to servers that are still using the old SSL/TLS protocol and which might be vulnerable to the attack. I believe this to be a mistake for various reasons, but first and foremost because an attack on a server without compromise of the client data as well, is basically useless. When a attacker induces renegotiation at the server, the attacker must have client credentials in order to act as if he were the original client. Without those credentials, the attacker would be treated as any other unauthenticated source. The attack that made it necessary to develop RFC 5746 is difficult to understand. The attacker doesn't need to know the credentials of the user. It's sufficient that the user's credentials will be sent by the client, after the renegotiation between MITM and server happened. The client will see it as an initial negotiation, it will encrypt the data, readable for the server only, not readable by the attacker. The attacker will pass through all unreadable encrypted data. On the server side, a request from the attacker will be combined with the credentials sent by the client. It's explained here: http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html I'm quoting the relevant example from above document: == snip quote begin == E.g., the attacker would send: GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1 X-Ignore-This: And leave the last line empty without a carriage return line feed. Then when the client makes his own request GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1 Cookie: victimscookie the two requests get glued together into: GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1 X-Ignore-This: GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1 Cookie: victimscookie And the server uses the victim's account to send a pizza to the attacker. === snip quote end === When a client (as in our case Firefox) implements RFC 5746, the client can't be compromised and no data is leaked from the client. I propose that Firefox should support the RFC 5746 extension exclusively, but NOT block or warn on accessing servers which don't support the extension. It doesn't help if the client is the only side supporting RFC 5746. Imagine the transition from USB 2.0 to USB 3.0, where the plug remains compatible, but the inner parts of the USB 3.0 plug introduces new connectors. If the client uses USB 3.0 and supports additional information, but the server still uses the older USB 2.0 plug, it won't help anyone. The data designed to be exchanged using the new USB 3.0 connectors can't flow. In other words, the parties are unable to exchange information that would help them to discover that a renegotiation from an unrelated party (a MITM) was requested. RFC 5746 requires a communication channel where both parties can speak the protocol. Any renegotiation attempt to the client will be ignored and no data is leaked. Even if the client rejects all incoming requests for renegotiation, the client has already sent out its credentials as part of a HTTP/SSL request. Yes, the credentials are not being directly leaked to the attacker, but that's not necessary. The credentials will be combined with an arbitrary request chosen by the attacker, as illustrated above. Effectively, the attacker can execute a request on behalf of the user, without needing to know the user's credentials. Kai -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 3/31/2010 5:26 AM, Eddy Nigg wrote: [ Please follow up to mozilla.dev.tech.crypto ] After some discussion at bug 554594 I'm following up here - the bug was unfortunately misused by me a little for the initial discussion. Closely related to bug 554594 is https://bugzilla.mozilla.org/show_bug.cgi?id=535649 Web developers using Firefox Error Console or tools like Firebug that use nsIConsoleService are now bombarded with pointless messages like: services.addons.mozilla.org : potentially vulnerable to CVE-2009-3555 I'm sure the person who put the code in to emit this message thought it was important. They probably did not realize that developers have to use the Error Console and console service all day, every day and these messages are a burden. Readers of this message are not in a position to prevent the message. It is not appropriate to write such a message into the error console. Even if you think it's just the most important bit of technology news you can imagine, please direct your message to the people who can actually do something about it. Thanks, jjb -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 03/31/2010 04:45 PM, Kai Engert: == snip quote begin == E.g., the attacker would send: GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1 X-Ignore-This: And the server uses the victim's account to send a pizza to the attacker. === snip quote end === This attack is highly theoretical beyond believe, specially the X-Ignore-This-and-That headers. Is has no real and practical value whatsoever. Here some interesting observations and opinion by others: http://blogs.technet.com/srd/archive/2010/02/09/details-on-the-new-tls-advisory.aspx Any renegotiation attempt to the client will be ignored and no data is leaked. Even if the client rejects all incoming requests for renegotiation, the client has already sent out its credentials as part of a HTTP/SSL request. Yes, the credentials are not being directly leaked to the attacker, but that's not necessary. Of course this is necessary and the twitter attack worked exactly and only because data was leaked from the client. Basically if the client doesn't leak any data (which it shouldn't when implementing RFC 5746, the attack is not possible (except for very bad coding of the application layer, but that doesn't count) The credentials will be combined with an arbitrary request chosen by the attacker, as illustrated above. If that attack works, no renegotiation would be necessary, such a site would be vulnerable by simpler means and would work probably in any case. Effectively, the attacker can execute a request on behalf of the user, without needing to know the user's credentials. Your assumptions are wrong and the whole thing is over-hyped as I mentioned in the bug. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
