Hi, thank you very much for all your explanation and to give me one more free training :)
* Kyle Hamilton wrote on Tue, Jan 12, 2010 at 13:33 -0800: > > 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. > > about:config, search for 'ssl' and 'tls'. By default, Firefox > 3.0+ disable 40- and 56-bit ciphers, and I know that either > Firefox 3.0 or 3.5 disabled SSLv2 by default. SSLv3 and TLSv1 > do not use those ciphers. Ohh great, thanks for this information. I checked that also my Firefox 3 and Firefox 2 has 40 and 56 bit ciphers disabled and have `security.enable_ssl2 = false'. > > Is it possible for an application to use an ideal TLS > > implementation in a way to at least detect this? > > There is currently no way for even an ideal TLS implementation to > detect this issue. This is why the IETF is working on the Secure > Renegotiation Indication TLS extension, which is close to finally > being released. > > > 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? > > Yes. Please see SSL_CTX_set_info_callback(3ssl). hum, now I'm confused, I think your last both answers contradict each other... If an application can use e.g. SSL_CTX_set_info_callback to reliably avoid this, I have to read more on what the IETF is working on. If there are webservers `trusting' peers without certificates (allowing pre-injection) what should stop people to ignore whatever extension as well... (well, of course in case of the renegiotation attack the main point probably is just that no one had this nice idea before :-)) > > Someone could expect whenever a browers window or `tab' is > > operating in some extended validation mode. > > Personal opinion here: EV was what Verisign *used* to require and > provide, back in 1995 when they were the first and only CA that > Netscape included in Navigator betas. > > The problem is that SSL and TLS are *far* too useful and general to > require the services of a public, commercial CA. I could imagine that the hyped success of SSL/TLS lead to weaknesses, because today someone can often hear `we are based on SSL/TLS and thus are secure'. Also interesting is when specifications require minimum RSA key lengths but don't tell anything about certification policies (requirements to CSPs) or require AES256 but no certificates (DH)... Which, BTW, in case of an MITM has the funny effect that it is cryptographically ensured that only the attacker can decrypt the traffic lol > > 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. > > This is correct *only* if mutual authentication is done on the initial > negotiation. Otherwise, the server accepts an anonymous connection, > receives anonymous bytes that translate into a request for a resource > that's protected, sends a renegotiation request to the client, the > client provides its certificate, and the anonymously-injected data -- > in the case of Twitter, a prefix of an entire header list -- is > processed as though it's under the security cloak of the client. I think this is a server (configuration) bug but no TLS bug. How can someone assume it would be safe for preinjection when accepting anonymous connections? It's also strange that SSL + BasicAuth seems to be so common. For many web services, users register and receive some confirmation mail with a password or alike. Why isn't it standard practice that users get a client certificate? Of course, this makes it difficult to use internet caffee, hotel or airport computers to login, but for those who use the password manager function anyway there should be not a big difference... It would not even be needed to buy at some CA certificate or reasonable authenticate when considering such a special purpose (i.e. when the site trust email which is used now, why shouldn't it trust certificates, too?). But as far as I know Browsers have no simple-to-use CSR generation, transferring CSR and importing CRT is more complicated than reading a password mail -- but I think this is nothing TLS can be blamed for. > > ...IPSec... > > If you configure an IPsec stack to allow anonymous clients, you > can't trust them. What you can do is trust the security > properties of other actions performed *within* those tunnels, > since they have different characteristics. Yes, but when it comes to webservers, anonymous clients are trusted... > > So with TLS, why do webservers assume the tunnel (layer) is > > secure and authenticated if they received a e.g. password via it? > > Because client certificates are too difficult for users to obtain, and > once the Secure Renegotiation RFC is published it (appears that it) > can be. but TLS cannot be made responsible that its difficult to obtain certificates (using the existing applications)... > > Isn't this mixing levels/layers/responsibilities in an forbidden way? > > "In theory, there's no difference between theory and reality. In > reality, there is." > > Technically, TLS is supposed to ensure that the endpoint that you were > talking with cannot change without collusion between the initial > endpoint and the final endpoint, sharing key and state data. This > guarantee was violated, so they're fixing it. Ahh ok. Thank you for clarifying that. I thought this was not supposed to be ensured (e.g. client certificates could be changed during a session technically, but reasonable applications would check this and for example would not accept changes in DN or maybe only accept key and serial number changes or alike). I'm not sure if it is reasonable to use TLS without client authentication (client certificates), then putting some client authentication (BasicAuth) on top and then expecting /TLS/ to be secure (instead of requiring BasicAuth to be secure, which certainly is not very strong). I hope I understood correctly and that really was what Twitter is using. Online banking often also uses no client certificates (and if they use client certificates, most banks here then also want chip card readers, which IMHO reduces the acceptance horribly because this is expensive). However, online banking (hopefully) uses some session IDs... > Twitter uses HTTP Basic authentication, over TLS. This is one of the > weakest forms of authentication I know of. However, the twitter > attack worked because client certificates are not well-used, and > because TLS has a flaw that allowed for the guarantee of "one endpoint > unless collusion occurs" to be violated. Ahh ok, yes. I think there are applications (maybe not using TLS but other means) that (maybe even automatically) generate some cryptographically protected identity (I think a signed random number is suffcient to know to talk always with the same entity). > I want to change this so that client certificates are amazingly > simple to obtain, Yes, I think this sounds like beeing the fix for the renegiotation attack! If Browsers had a `Generate ID for this site and upload'-Button [gen-CSR] and a mean to transfer it and the certificate back, which surely is complex to design and develop and opens many questions, then this would be a great way. Except initial setup this would be much stronger than todays passwords (which probably usually are much weaker than the applied block cipher). Browsers could manage the retrieved certificates similar to passwords stored by the password manager. I think this is not as X.509 (or X.500 here?) was intended, but I think in practice this `trust a foreigner when a common trust anchor tells it' makes not much sense when working anonymously (or `pseudonymously', in case this forms something like a understandable english term :)) in register-for-free networks. Maybe we'll see something like this in future? > (Really, please go read RFC 2246. It seems to be a very well-written specification. BTW: `The fundamental rule is that higher levels must be cognizant of what their security requirements are and never transmit information over a channel less secure than what they require.' so no BasicAuth :) Yes, I see that it explicitely forbidden to use NULL/NULL/NULL. 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
