Hi, thank you for your detailed explanations.
The main thing I still not understood is whether TLS by design enforces the `bad behavior', meaning TLS cannot be used securely at all by anyone, - or - if TLS just does not enforce to use is securely, meaning that TLS relies on application code implementing and using it correctly and reasonable. I moved this topic up to have this question first (or almost first, following right after this paragraph) in the hope to get an answer to it; the rest of this mail unfortunately got so long that it cannot be read because probably it's a waste of time :( [move up from the end] * David Schwartz wrote on Mon, Jan 11, 2010 at 09:06 -0800: > > If this would be true, this means the information firefox shows > > up when clicking the lock icon does not tell anything about the > > data I will sent; at most it can tell about the past, how the > > page was loaded, but not reliable, because maybe it changed for > > the last part of the page. > > > > Where is my mistaking in thinking? > > Correct, and to the extent TLS permits a renegotiation to > reduce the security parameters without confirming the intention > to reduce those parameters at the current level, TLS is broken. Is TLS broken or is it just used in an unreasonable way? With OpenSSL, for example, I could configure to accept only SHA1 and 3DES (or stronger) and I would be safe to renegotiate to 40 bit something. Isn't it a bug in the application when it does not allow me (its user) to configure it? As far as I know there is no way to tell Firefox i.e. not to accept 40 bit. > That is, if the two ends negotiate 1,024-bit RSA and 256-bit > AES, then an attacker should not be able to renegotiate a lower > (or different) security within that connection without having > to break either 1,024-bit RSA, 256-bit AES, or one of the hard > algorithms inside TLS itself (such as SHA1). TLS permitted an > attacker to do this, and so was deemed broken. Is it possible for an application to use an ideal TLS implementation in a way to at least detect this? Like having some OpenSSL callback be called reliably on (right after?) each renegiotation - where a webserver could force to shutdown the connection if the new parameters are not acceptable? [original start of mail] * David Schwartz wrote on Mon, Jan 11, 2010 at 09:06 -0800: > > I think since TLS should be considered a layer, its payload > > should not make any assumptions to it (or vice versa). But in the > > moment some application `looks to the TLS state' and tries to > > associate this information to some data in some buffer, I think > > it makes a mistake. > > Well then TLS is basically useless. A secure connection whose > properties I cannot trust is not particularly useful. If I > receive "foo" over the connection and cannot ever know where > the middle "o" came from, what can I do with the "foo"? Anser > -- nothing. I think `trust' is not an absolute but a relative thing. Someone may trust rapidSSL certified 40 bit key connections sufficient to login into myspace via her own Wifi network, but not at all sufficient for online banking. Someone could expect whenever a browers window or `tab' is operating in some extended validation mode. If a server uses TLS to authenticate a client, a client certificate is needed. If the server delegates the authentication and authorisation both to TLS (which means, that such a server or HTTPS server port could not be used without a valid client certificate), as far as I understood no renegiotation attack would be possible. Did I understand correctly (or could client-certificate-based authentication be attacked as well)? As far as I understood the renegiotation attack bases on the fact that the server does not TLS-authenticate the client but relies on the assumption that it will talk to the same client during the whole connection / HTTP session. (I assume that the server is able to detect when a client certificate changes within renegiotation, if a client certificate change is possible at all - and is able to refuse that. So if a server does not perform client authenticate [using client certificates as TLS offers] the server cannot know the the middle "o" came from.). I think with TLS-authentication this type or renegiotation attack won't work or would at least be detectable because the client certificates Subject/CN or key changes. Is this correct? > > When using HTTP over IPSec, I think no one ever had the idea to > > open or block URLs based on the currently used IPSec > > certificate... > > I'm not sure I get the point of your analogy. ohh sorry. I hope I wasn't too confused. Or I'm just wrong. Unfortunately I need a longer explanation trying to tell what I mean: Similar, as I understood, the idea to the requirement for a client certificate on an existing connection when the higher layer protocol or higher application level demands that, for example, when HTTP browsing a specific sub directory. As I understand it, this is like trying to add security retroactively. Similar for IPSec. If I would configure my IPSec client/stack to accept anonymous clients I cannot trust connection to them, even if over this insecure (not authenticated) connection some authentication was transmitted - especially when it is even possible to replay this authentication mean. For example even if a valid high-secure SSH login happend over this insecure (not authenticated) IPSec tunnel, from this it cannot be concluded that the IPSec tunnel itself is secure and authenticated. It is not. So with TLS, why do webservers assume the tunnel (layer) is secure and authenticated if they received a e.g. password via it? Isn't this mixing levels/layers/responsibilities in an forbidden way? I have to admit that I did not study the `twitter attack', but I assume it works because the client authentication, probably some password or even HTTP protocol AuthType mean, is not bound to any random number or other client/session identification. By this, I assume, it also would be open for replay attacks (e.g. by a client-local trojan horse or so). The analogy I see here is that as a valid SSH connection over an unauthenticated IPSec tunnel does not mean all other things via this tunnel are also secure so a valid password over an unauthenticated TLS also does not mean the wohle HTTPS session is secure. Does my analogy make any sense or do I mix things up again? > > Am I wrong when I think [...] is this really a TLS weakness? > > No, that's not. Because in that case the client's behavior is > objectively unreasonable. ahh sure, yes, this makes no sense. I mixed that up. > > It seems it is, so what do I miss / where is my mistake in > > thinking? > > The mistake is in thinking that any security protocol is useful > as a security measure on end A if the security parameters can > be changed by end B at any time with no notification to higher > levels on end A. Ohh, is it? But when such a change is possible, couldn't an attacker then fool by some way to use very weak security parameters, for instance by MITM or inject or whatever to renegiotate a weak cipher and brute force it - or even disable security? (as far as I know theoretically SSL can be operated without encryption using a nullcipher) > > I could find myself suddenly using a 40 bit export grade or > > even a NULL chipher to a different peer (key) without any > > notice! > > That could be argued to be a bug. Ideally, a renegotiation > should not be permitted to reduce the security parameters > unless, at absolute minimum, the intention to renegotiate is > confirmed at both ends using at least the security level > already negotiated. ahh ok. So I assume I'm not the only one who dislikes that firefox displays a lock icon on 40 bit connections :) > [section that followed here moved to top] (ohh thanks if anyone made it through all my long text) 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
