Hi all! I miss something around the Re-negotiation flaw and fail to understand why it is a flaw in TLS. I hope I miss just a small piece. Could anyone please enlight me?
* Kyle Hamilton wrote on Thu, Jan 07, 2010 at 16:22 -0800: > It is also, though, undeniably a flaw in the TLS specification > that's amplified by the clients of the libraries that implement > it -- because the clients don't understand the concept of > "security veil", the TLS implementations tend to provide a raw > stream of bytes (akin to a read()/write() pair) without the > application necessarily being aware of the change. Could it be considered that a miss-assumption about SSL/TLS capabilities caused this situation? 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. 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... 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? It seems it is, so what do I miss / where is my mistake in thinking? I also wondered a lot about the Extended Validation attack from last year; I had assumed that in `EV mode' a browsers tab is completely isolated against all others and second no other connectivity is possible as with the locked EV parameters, but as it turned out this is not the case. Everything can change but the green indicator remains. Strange... 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! 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? 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
