Re: TLS break
On Wed, Nov 11, 2009 at 10:57:04AM -0500, Jonathan Katz wrote: Anyone care to give a layman's explanation of the attack? The explanations I have seen assume a detailed knowledge of the way TLS/SSL handle re-negotiation, which is not something that is easy to come by without reading the RFC. (As opposed to the main protocol, where one can find textbook descriptions.) Not to sound like a broken record, and not to plug work I've done[*], but IMO the best tool to apply to this situation, both, to understand the problem, produce solutions, and to analyze proposed solutions, is channel binding [0]. Channel binding should be considered whenever one combines two (or more) two-peer end-to-end security protocols. In this case two instances of the same protocol are combined, with an outer/old TLS connection and an inner/new connection negotiated with the protection of the outer one. That last part, negotiated with the protection of the outer one may have led people to believe that the combination technique was safe. However, applying channel binding as an analysis technique would have made it clear that that technique was vulnerable to MITM attacks. What channel binding does not give you as an analysis technique is exploit ideas beyond try being an MITM. The nice thing about channel binding is that it allows you to avoid having to analyze the combined protocols in order to understand whether the combination is safe. As a design technique all you need to do is this: a) design a cryptographically secure name for an estabilished channel of the outer protocol, b) design a cryptographically secure facility in the inner protocol for veryfying that the applications at both ends observe the same outer channel, c) feed (a) to (b), and if the two protocols are secure and (a) and (b) are secure then you'll have a secure combination. [*] I've written an RFC on the topic, but the idea isn't mine -- it goes as far back as 1992 in IETF RFCs. I'm not promoting channel binding because I had anything to do with it, but because it's a useful technique in combining certain cryptographic protocols that I think should be more widely understood and applied. [0] On the Use of Channel Bindings to Secure Channels, RFC5056. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: TLS break
On Mon, Nov 16, 2009 at 11:30 AM, Bernie Cosell ber...@fantasyfarm.com wrote: As I understand it, this is only really a vulnerability in situations where a command to do something *precedes* the authentication to enable the command. The obvious place where this happens, of course, is with HTTPS where the command [GET or POST] comes first and the authentication [be it a cookie or form vbls] comes later. This last part is not really accurate - piggybacking the evil command onto authentication that is later presented is certainly one possible attack, but there are others, such as the Twitter POST attack and the SMTP attack outlined by Wietse Venema (which doesn't work because of implementation details, but _could_ work with a different implementation). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: TLS break
Jonathan, Anyone care to give a layman's explanation of the attack? The I find this paper to be useful: http://www.g-sec.lu/practicaltls.pdf Cheers, Stefan. -- Stefan Kelm sk...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstrasse 100 Tel: +49-721-96201-1 D-76133 Karlsruhe Fax: +49-721-96201-99 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: TLS break
Anyone care to give a layman's explanation of the attack? The explanations I have seen assume a detailed knowledge of the way TLS/SSL handle re-negotiation, which is not something that is easy to come by without reading the RFC. (As opposed to the main protocol, where one can find textbook descriptions.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: TLS break
At Tue, 10 Nov 2009 20:11:50 -0500, d...@geer.org wrote: | | This is the first attack against TLS that I consider to be | the real deal. To really fix it is going to require a change to | all affected clients and servers. Fortunately, Eric Rescorla | has a protocol extension that appears to do the job. | ...silicon... Is the relevant silicon really this unprogrammable? -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: TLS break
On Wed, Nov 11, 2009 at 10:57:04AM -0500, Jonathan Katz wrote: Anyone care to give a layman's explanation of the attack? The explanations I have seen assume a detailed knowledge of the way TLS/SSL handle re-negotiation, The re-negotiation handshake does not *commit* both parties in the new handshake to the previous cryptographic state of the TLS connection. If the man in the middle is willing to encrypt/decrypt handshake packets between a client new to the connection, and a server with which the MITM completed an earlier handshake, the MITM can transfer an existing session from himself to the client (victim), after injecting some initial data into the connection. The integrity and confidentiality properties of the origimal MITM-server connection only protect both parties if neither party is willing to compromise those properties by proxying a 3rd party into the session. The new ingredient here, is that the 3rd party can be a victim, who is unaware of the proxying. The victim's handshake with the intended server is proxied into an already established TLS session by the MITM who is privy to the session state. The solution is to *commit* the two parties to a re-negotiation handshake to the previous handshake. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: TLS break
On 11 Nov 2009 at 10:57, Jonathan Katz wrote: Anyone care to give a layman's explanation of the attack? The explanations I have seen assume a detailed knowledge of the way TLS/SSL handle re-negotiation, which is not something that is easy to come by without reading the RFC. (As opposed to the main protocol, where one can find textbook descriptions.) I had a hard time with this, too, but this PDF really clarified it for me: http://extendedsubset.com/Renegotiating_TLS_pd.pdf Let me try a layman's explanation (assuming I have it right) We start assuming the attacker can to hijack or MITM the victim's TCP connections. The attacker opens *its*own* TLS connection to the server [so that is now being encrypted by a symmetric key the attacker picked] and sticks some data into the pipe. The victim wants a TLS connection and so begins negotiating one. The attacker just MITM's that as a *renegotiation* with the server for its TLS connection. (that is, the victim thinks they're negotiating a NEW TLS connection, but the attacker proxies that into a *renegotation* on the existing TLS connection). In short order the attacker is frozen out of the connection [since it will then be encrypted by a key picked by the victim], BUT: the victim's data will ride over the TLS connection that the attacker had previously set up and pre-loaded with some data, and so the victim's data *FOLLOWS* the attacker's -- the attacker was able to inject arbitrary data *in*front* of the victim's data. As I understand it, this is only really a vulnerability in situations where a command to do something *precedes* the authentication to enable the command. The obvious place where this happens, of course, is with HTTPS where the command [GET or POST] comes first and the authentication [be it a cookie or form vbls] comes later. /bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:ber...@fantasyfarm.com Pearisburg, VA -- Too many people, too few sheep -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: TLS break
On Mon, Nov 9, 2009 at 5:08 PM, Victor Duchovni victor.ducho...@morganstanley.com wrote: attack, checking Referrer headers is no longer effective, so anti-CSRF defenses have to be more sophisticated (they *should* of course be more Checking the Referer header never was effective. It's not even guaranteed to be present, let alone true. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: TLS break
| | This is the first attack against TLS that I consider to be | the real deal. To really fix it is going to require a change to | all affected clients and servers. Fortunately, Eric Rescorla | has a protocol extension that appears to do the job. | ...silicon... --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: TLS break
On Sun, Nov 08, 2009 at 01:08:54PM -0500, Perry E. Metzger wrote: I'll point out that in the midst of several current discussions, the news of the TLS protocol bug has gone almost unnoticed, even though it is by far the most interesting news of recent months. Not entirely unnoticed: http://www.porcupine.org/postfix-mirror/wip.html#tls-renegotiation For HTTPS, it has been observed that this is not entirely different from existing CSRF attacks, but it should be noted that with the new attack, checking Referrer headers is no longer effective, so anti-CSRF defenses have to be more sophisticated (they *should* of course be more sophisticated, but they rarely are, if they are present at all). I am looking forward to analyses for other protocols. There is almost certainly a problem for FTP (over TLS), where just banning re-negotiation on the server is perhaps reasonable. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: TLS break
Perry E. Metzger wrote: I'll point out that in the midst of several current discussions, the news of the TLS protocol bug has gone almost unnoticed, even though it is by far the most interesting news of recent months. Perhaps because there have been so many false alarms over the years. Usually when I hear about an SSL MITM attack, it's really a browser UI spoofing attack with a bogus cert. This is the first attack against TLS that I consider to be the real deal. To really fix it is going to require a change to all affected clients and servers. Fortunately, Eric Rescorla has a protocol extension that appears to do the job. -- Give a man a fire and he's warm for a day, but set | Tom Weinstein him on fire and he's warm for the rest of his life.| twei...@pacbell.net - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
