Steffan Dettmer write: > Could it be considered that a miss-assumption about SSL/TLS > capabilities caused this situation?
Only with hindsight. > 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. > 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. > Am I wrong when I think that those level-mixing causes the > trouble? If a user (by browsers default configuration) first > accepts some sillyCA or www.malicious.com but then later does not > accept it any longer and expects the trust that initially was > given to be taken back in retroperspective and finds this failing > and unsafe (impossible), is this really a TLS weakness? No, that's not. Because in that case the client's behavior is objectively unreasonable. But looking to the state of the current connection to decide what privileges to give it is part of TLS's intended use. > 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. > Now I ask myself what happens if I connect via HTTPS and read the > crypto information as displayed by my browser and decide to > accept it - but after a renegiotation different algorithms are > used. As far as I understand, I would get absolutely no notice > about that. I could find myself suddenly using a 40 bit export > grade or even a NULL chipher to a different peer (key) without > any notice! If I understand correctly, even if I re-verify the > contents of the browsers security information pane right before > pressing a SUBMIT button, even then the data could be transferred > with different parameters if a re-negotiation happens at the > `right' time! 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. > 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. If the two endpoints negotiate a particular level of security, no attacker should be able to reduce that level of security within the connection without having to break the current level of security. 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. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
