* Kyle Hamilton wrote on Thu, Jan 14, 2010 at 15:50 -0800: > On Wed, Jan 13, 2010 at 5:58 AM, Steffen DETTMER wrote: > >> There is currently no way for even an ideal TLS implementation to > >> detect this issue. > >[...] > >> 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... > > What SSL_CTX_set_info_callback() does is tell you *when* a > renegotiation occurs. It doesn't tell you what happened before.
(assuming, that a peers identity should not change within a session - but as discussed later in this mail this could be wrong?): In the implementation of this callback, shouldn't the HTTP server in first call store the peer identity (maybe the DN value of the certificate) and abort when in a second or subsequent call suddenly another value of DN is found within the same HTTP session? Does the standard require to allow / to support chaning a DN during one TLS session? (of course, most HTTPS services don't use client certificates, so it won't help in practice) > >> > Someone could expect whenever a browers window or `tab' is > >> > operating in some extended validation mode. > > As I think I mentioned, nobody ever actually mapped out the precise > semantics of how the green bar is supposed to work. That is EV's > biggest Achilles's Heel... nobody knows what it means, the same way > nobody knew what the lock meant. I think, most people take security in a very pragmatic way. It should not cost additional efforts, but the investable efforts effectively limit the reachable security. OT: I personally would wish to be able to put a browser tab or better even a browser instance into some `secured' mode (for online banking HTTPS but not for myspace HTTPS). In this mode, flash would not work, no plug-ins installed and I would be warned when the DN of a certificate of a web page changes (now, I'm warned only if CN does not match DNS name, but I would like to be informed: "www.xyz.com now is DN=XYZ Ltd. UK but last time it was DN=XYZ Inc. US" or so). Probably there are many more nice security features that could be turned on. This would not prevent the twitter attack but maybe could make online banking attacks more expensive. With firefox, this is possible using different profiles with MOZ_NO_REMOTE but this breaks other things (today, systems seem to rely on a single running browser instance). or something like `ssh -X safeu...@localhost firefox' :) Ohh, and this would catch passwords `system modal' just like ssh-add can do. It is too bad when half of the password reaches some online chat tool just because the session manager opens tabs that were open at the point of a previous crash, giving them focus for a short time... I really really dislike firefox asking for master password while continuing in the background with optional focus change... sorry all of this is off-topic. > You cannot call an application that uses SSL/TLS "secure" any more > than you can call a network that has a firewall "secure". yes, this is very true, but I'm afraid many people assume that this `any more' is quite a lot. For example, nowadays simple packet filters alone are called firewalls (some years ago, packet filters were just a less important small layer, mostly set up because it costs almost nothing, but security was applied by a combination of proxies understanding their protocol and filtering based on its content, for example with virus-checking, and TCP wrappers etc). I think for many a `SSL secured' label on a webpage means that the running application (lets say a online banking web app) is secured. > > 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? > > ...because they didn't realize that the prior session isn't > cryptographically bound to the new session, it's a complete wiping of > the slate. It is certainly an application-design issue (defense in > depth is not just a buzzword), but it's also a TLS protocol issue as > one of the guarantees that the protocol attempted to provide was > violated. Isn't TLS requiring to use client certificates to be able to guarantee that the client remains the same? If TLS is not using client certificates, doesn't this mean that anyone is accepted? (yes, in the Twitter case the application design and using Basic Auth surely isn't highly secured) > > 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... > > If there were a standard for a USB cryptoken, someone could write a > PKCS#11 wrapper around it for every platform that supports USB. cool, the certificate to carry with :) Maybe defining some serial command interface that also works via USB would be simple. People would need to buy and manage USB crypto devices and keys. My bank offered me one, but the device neither had secured keyboard nor display and thus I felt myself unable to trust it - a trojaner on the PC can fool me. An issue here is that someone could argue that this setup is certified as legal digital signature which for me is reason enough not to accept it (I won't like to get married just because a hacker trojaned by PIN or so :)). So I think it would be a bit harder. Maybe having a cell phone or PDA with such an USB interface but not assumed high-security (e.g. on online banking, I - the user - can decide to require PIN/TAN number additionally and to limit maximum transaction amount etc). It should be cheap that I could affort to buy 10 or so and each has to support mutliple certificates which are easy to change and I have to be allowed to exchange with friends (all to protect my privacy). > > 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. > > Netscape uses SPKAC for its <keygen> tag format. Microsoft's XEnroll > or CEnroll do something else, something I don't even know. I know > that if you're on an Active Directory domain with a DC that's also a > CA, there are ways to get certificates in Windows from the CA > automagically. > > The best that anyone's come up with thus far is the CSR submit/CRT > download-install. I think that this is hideous, and it's impossible > to expect that any standard user is going to understand it. Even with > a HOWTO. Yes... maybe this is a flaw of HTTPS (if for authenthentication client certificates are needed but not supported because only BasicAuth is supported). > > Yes, but when it comes to webservers, anonymous clients are > > trusted... > > Yes. The difference is that in IPSec, the client must announce its > identity first before the server gives it a second glance, while in > TLS the Server must announce its identity before it can even ask the > client for its identity. (This is an instance of > "policy-set-in-standard", and I am opposed to it.) (I don't understand "policy-set-in-standard") Is it a problem that the server must tell its identity before the client? > > but TLS cannot be made responsible that its difficult to obtain > > certificates (using the existing applications)... > > TLS, as has been mentioned, does not require certificates or any other > authentication. (For an analogy as to how someone can expect that > authentication in-channel is equivalent to authentication of-channel, > please see the OTR protocol at http://cypherpunks.ca/otr/ . It > describes the process of creating a confidential channel between two > people, then using a secret known between them in the Socialist > Millionaire's Protocol to authenticate the person using the other end > of the channel.) I found a description of Socialist Millionaire's Protocol on the page, but it seems complicated. As I understand it verifies both sides use the same value of a data element that has to be communicated off the channel (e.g. by cell phone SMS?), correct? (BTW, wouldn't it be sufficient to sha1(random || secret) and to send random and secret to each others side?) If something like this is applied on top of TLS but TLS itself allows the peer to change at any time (e.g. because renegotiation is possible without knowing anything secret of the previous negotiation), would this help? > >> 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. (ok, now I got it, you wrote "is expected to be secure against this kind of attack, even in the case of single-side authentication.") > > 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). > > Client certificates *can* be changed in the middle of a session, and > if both sides authenticate each other then there's no way for the > prefix-injection attack to succeed. but if the DN (or whatever) would not be checked by the server, then one twitter user (with a valid certificate) could fool another twitter user to publish its HTTP request to the first users page, right? (since it would not contain BasicAuth, it would probably no interesting attack, but maybe there are other applications) > I'll note that your definition of "reasonable applications" is a > particularly sneaky and snarky way of attempting to enforce your ideas > on policy on others, who may or may not need the session identity to > stay the same during the lifetime of the session. ohh yes, I think you are right... Yes, I was assuming everyone would consider it natural that within one and the same session the peer identity remains the same. But this isn't true? > I can think of at least 2 businesses which use processes that, > when translated directly into the PKI concept, would require an > initial certificate (the POS terminal operator's) and a > different certificate (the POS terminal operator's manager, who > might need to open the drawer or authorize a particular > transaction). (TLS might not be suited best for POS terminals I think. As far as I know, PKI is great when n:m trust is needed [but still, authorisation priviledges have to be managed]. For POS terminals I think often there is one operator per terminal. I think it usually is not desired to be able to communicate securely to someone else, someone not known it advance [like a foreign terminal]) > TLS is expected to be secure against this kind of attack, even in the > case of single-side authentication. That's the guarantee that was > violated, and that's why the IETF is fixing it. > > > 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... > > My bank actually sends me an SMS each time I want to do things that > change the balances of my accounts, with a code that I have to enter > to authorize them. that sounds great (at least as long as the phone and the network is reliable and working when needed). > > 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). > > Uh, that's kinda what TLS does. It signs the channel initiation, and > then after negotiating all the cipher specs it sends ChangeCipherSpec. > The next message after that *must* be Finished, it must be under the > new cipher spec, and it must contain the hash of all the prior > handshake packets that it sent. > > I'm not sure what you mean by 'signed random number' -- a shared > secret? That's not scalable. I meant something like an SSH host key. If now known, it can be accepted. But if known from any previous session, it must match the currently used key (i.e. key cannot change). Yes, does not scale, because web servers could never change their key. Banks had to send certificate fingerprints before or so. For TLS, maybe some way to generate a new client certificate for a new page automatically done by the browser, send it to the site and that site stores the fingerprint (not using CA/PKI) as part of some account registration process. Just in case this would be better than using no certificate at all. However, also does not scale (e.g. what happens if user uses a different browser to connect to the bank?). > >> 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 > > renegotiation attack! > > This is the *absolute* fix for the renegotiation attack, for *all* > versions of SSL and TLS (presuming that the initial negotiation, or > the initial renegotiation after negotiation of a DHE cipher, is > authenticated by the client without any application data being passed > in the meantime). ahh ok. So there is an absolute fix that would instantly work, but at the moment (with given applications etc) it is not feasible in HTTPS web practice. > There are a lot of crypto apologists in the world (me included) who > have stumbled on various cryptosystems' failures. Ian Grigg, who > maintains http://www.financialcryptography.com/ , has developed a > protocol which would allow banks to know for certain that the keys > they're requesting have been generated on-chip, by having the device > manufacturer to cause a keypair to be generated, pulling the public > key, and then generating and imprinting the device's certificate -- > which would then be used to sign all requests generated by that chip. > > The downside is that there's no protocol to allow a bank (for example) > to specify that it demands hardware security for the key generation > and use process. (I think, a chip, a secured display and a secured keyboard is needed, otherwise a PC application could spoof/misuse it, right?) Couldn't this be easily ensured by generating certificates only for approved security modules? For example, by selling only completely loaded devices with individual keys + cert? > In Twitter's case, it knows that it must receive > updates over a TLS-encrypted HTTP session. (ahh yes, of course) > > Yes, I see that it explicitely forbidden to use NULL/NULL/NULL. > > Now, for the mindbender: under what circumstances might it be > appropriate to use NULL-NULL-SHA256? mmm... If the transmission link isn't reliable and might have bit errors? (since even TCP sometimes does not detect bit errors and files fetched via FTP can be damaged)... no idea... when it might be appropriate to use it? oki, Steffen 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
