Comments on The Secure Goose: TLS renegotiation vulnerability (CVE-2009-3555)

The ssl diagnos application does some tests for CV...

2010-12-03T22:10:48.588+01:00

The ssl diagnos application does some tests for CVE-2009-3555:

See:
http://sourceforge.net/projects/ssldiagnos

Hi there, I'm getting the message "potent...

2010-04-18T15:24:37.717+02:00

Hi there, I'm getting the message "potentially vulnerable to CVE-2009-3555" - do I need to get my provider to patch my server or is this a code issue? I force SSL over the whole of my sote and I'm now getting pretty worried. Any ideas?

It does answer the question, thanks.

2010-01-24T23:35:03.257+01:00

It does answer the question, thanks.

OAuth and TLS have very different uses and if the ...

2010-01-24T23:25:56.615+01:00

OAuth and TLS have very different uses and if the question is whether, in general, the use of OAuth would mitigate the vulnerability, the answer is no. However, OAuth would indeed prevent disclosing the user's credentials to the attacker in the case of the twitter API here, but so would using Digest instead of Basic authorization. Does that answer your question?

I'm curious: would OAuth be better than simply...

2010-01-21T06:36:41.920+01:00

I'm curious: would OAuth be better than simply base64'ing the user's password?

Hi! Nice blog thx

2009-12-25T21:06:53.549+01:00

Hi!

Nice blog

thx

Right; I think it's valuable to separate the t...

2009-11-17T18:52:34.606+01:00

Right; I think it's valuable to separate the two different attack cases more explicitly:

1) Bad guy plays chosen transaction under authentication of good guy;

2) Bad guy reveals good guy's plaintext through posting under bad guys' credentials.

We had considered both, but we thought #1 was the more serious flaw, and more directly illustrated the actual protocol flaw.

-Steve Dispensa

Hi Joe, Thanks for the comment, this is my point ...

2009-11-17T11:31:49.984+01:00

Hi Joe,

Thanks for the comment, this is my point of view as well. Token based CSRF won't be of any use - in the specific way of exploiting the TLS bug here - to prevent the attacker from posting... authenticated as himself.

The comparison with CSRF though is based on the initial "X-ignore" trick, which led to basically the same result that you would get from a CSRF, making CSRF protections more relevant in that case.

I still don't see why this is anything like a ...

2009-11-17T02:28:07.713+01:00

I still don't see why this is anything like a CSRF at all.

The attacker doesn't need to convince the service provider to trust the user's request. The attacker doesn't try to impersonate the user at all!

The attacker only needs to convince the service provider to trust the *attacker's request*. He can use his own login credentials. He can provide whatever CSRF-protection cookies the service requires. All he has to do is construct *some* valid request that ends with the user's original HTTP request as *some* valid payload that the service provider will eventually make available to him.

In other words, the service provider only sees the attacker logging in normally, following a normal sequence of web forms, and posting a message with a funny-looking body. No CSRF.

@Anonymous2: Renegotiation: cssl->ssl-&...

2009-11-16T18:36:24.970+01:00
@Anonymous2:
Renegotiation:

cssl->ssl->method->ssl3_enc->change_cipher_state = bogus_change_cipher_state;
rec_write(cssl, buf, l);

Also, CSRF starts with "Cross Site". There is only one web server involved here.

This isn't a renegotiation exploit at all. Thi...

2009-11-16T18:10:36.657+01:00
This isn't a renegotiation exploit at all. This is just a CSRF leveraging MitM. The attack doesn't even cause a renegotiation. While the attack is certainly clever, it is misleading to call it a renegotiation exploit.

@Anonymous: RichieB and I were referring to the RE...

2009-11-16T13:54:30.423+01:00
@Anonymous: RichieB and I were referring to the RESTful API (no token there)

CSRF doesn't work on Twitter during a POST bec...

2009-11-16T10:44:12.418+01:00
CSRF doesn't work on Twitter during a POST because of the protection provided by the rails authenticity token.

Thanks RichieB for your comment, I agree this is n...

2009-11-13T14:37:25.081+01:00
Thanks RichieB for your comment, I agree this is not vey clear in my post.

Do you agree with the following: if you were to try to exploit the twitter API through a CSRF, you would not be able to perform this attack.
The reason is related to the one you mentioned: this is a single request that has to contain the user's credentials. If the CSRF POST would include the attacker's credentials (I'm not sure whether this would actually work, but I'd guess so, with some javascript), the attacker has no way to access the victim's credentials and post them. Nor his twitter.com cookies.

Therefore, it is possible to perform attacks with this vulnerability that you could not with some CSRF.

Please note that the RESTful API is not (and canno...

2009-11-13T12:21:05.583+01:00
Please note that the RESTful API is not (and cannot) protected against CSRF because it is a single request. In the GET /transact.php?value=evil case CSRF protection can be defeated if it uses an HTTP header, but not if it uses a URL parameter. In the POST /forum/send.php case CSRF protection is never defeated.

So, the impact of this SSL flaw is still similar to CSRF. You just pointed out a case where CSRF is not implemented.

UPDATE: it appears twitter has patched its webserv...

2009-11-11T22:44:31.469+01:00
UPDATE: it appears twitter has patched its webserver and the TLS renegotiation vulnerability does not work anymore. Until yesterday (10/11), it was working fine. I guess their admins are doing a good job!