* aerow...@gmail.com wrote on Tue, Jan 12, 2010 at 12:29 -0800: > On Tue, Jan 12, 2010 at 3:12 AM, Steffen DETTMER > The problem is this: > > The attacker makes a connection to a TLS-enabled server, > sending no certificate. It sends a command that, for whatever > reason, needs additional privilege (in Apache's case, Directory > and Location clauses can require additional security above what > the default VirtualHost configuration negotiates). Then, it > just starts proxying packets between the client and the server.
Yeah, strange idea that. I read that it is common to do so, but I wonder why such a feature was implemented into Apache... Did this renegiotation-to-increase-security-retroactively idea ever pass any security approval? A pitty that such an attack exists, but maybe this just prooves `never design a crypto system' - sometimes security issues are really surprising :) > One way to deal with this would be to enforce that all access > to resources on the same webserver require the same "security > cloak" -- that is, have the server demand a certificate during > the initial negotiation, so that *all* data that comes in is > authenticated as being from that identity. Yes, isn't this how TLS is intended to be used and the `add a certificate based on a directory' just some hack because the user interfaces are as they are (and that are passwords and BasicAuth when it comes to HTTP/HTTPS)? > >I thought this data injection attack fails when client > >certificates would be used correctly. > > It does, in the event that the server configuration does not allow for > non-client-certificated connections in any manner, in any way, for any > purpose. THAT is "when client certificates are used correctly". [...] > If you get rid of the 'allow non-authenticated SSL clients' > part of the policy on that server, you do away with the > problem. [...] > In fact, if this [client-] certificate is presented during the initial > negotiation, it is impossible to perform this MITM attack. ok. Thank you for clarifying that. So as you wrote in the other mail, it is the `common practice' that lead to the problem. The fix IETF is preparing maybe is less a bugfix than a new feature - protecting a bit more, even if authentication is used wrongly. > In Twitter's case, they don't require certificate > authentication. This means that they will never be able to > prevent this attack without disabling renegotiation until the > Secure Renegotiation Indicator draft standard is implemented on > both the servers and the clients. > > And yes: the problem is caused by TLS misuse, but the reason > for the misuse isn't on the server side. Yes, the MITM was never able to decrypt the password, but fooled the server to do so and to publish the result. Well... strictly speaking I think the bug is that the result (the password) was published, which I think is a server but not a TLS bug (which just happend because no one had the idea for this exploit in the past). Since summary there are many aspects that work hand-in-hand: TLS does not differentiate negiotation and subsequent re-negiotations, HTTP `assumes' always talking to the same peer and replayable passwords or clear text password as with BasicAuth, best probably is to improve TLS AND stop using BasicAuth in favor of Digest Authentication AND make a dedicated login request/response at the begin of each connection in the hope that all together increase security best :) > The point I wanted to make in that last paragraph is: the users > can't figure out how to generate keys, much less submit > requests to CAs. Maybe something simpler than CAs could be used. Now server store a password for each account, why shouldn't they be able to store a hash/signature for each account? For example, browser creates a self-signed certificate (some simple UI to fill out DN only), server receives it and stores this sig like a password? Or does this count as `design a cryptosystem' already? Also server could sent back signed cert, signed in a way that server recognized but without any trust for anyone else, like a private CA (it would not even be needed to publish its certificate, if any :))? Using (real) CAs could have disadvantages when it comes to privacy or when someone wants to use pseudonyms, I think. Difficult topic. Good to know that experts (like you) are working on it. > This reduces the provisioning of client certificates, and thus > reduces the market. What's needed is a useful mechanism and > interface for managing these things, and nobody's created that > yet. But outside SSL/TLS such things exist... Maybe in TLS world it is so uncommon because public CAs and some X.500-style `global directory ideas' are so common? > I hope I've helped you understand a bit more clearly. If you > have more questions, don't hesitate to ask. :) Yes, you helped me a lot, it was great lecture. Thank you very much that you again provided me free lessons with so many information!! oki, Steffen -- --[end of message]------------------------------------------------->8======= About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
