New atack against TLS/DTLS published

[Niklas Schnelle]

Hello fellow Gophers,

just found this anouncement http://www.isg.rhul.ac.uk/tls/ of a new atack on TLS. According to the info GnuTLS has just released patches while OpenSSL is still pending.
It doesn't seem like it takes some effort to exploit but it's a real vulnerability none the less. So I guess someone with the needed skills should look into the Go TLS implementation.

Greetings Niklasa

[Patrick Mylund Nielsen]

http://www.imperialviolet.org/2013/02/04/luckythirteen.html

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Niklas Schnelle]

Now I'm impressed. Just shows how amazing the Go team really is

[Dan Kortschak]

I walk amongst giants!


agl Wed Dec 15 11:49:55 2010 -0500: ... // note that we still have a timing side-channel in the
agl Wed Dec 15 11:49:55 2010 -0500: // MAC check, below. An attacker can align the record
agl Wed Dec 15 11:49:55 2010 -0500: // so that a correct padding will cause one less hash
agl Wed Dec 15 11:49:55 2010 -0500: // block to be calculated. Then they can iteratively
agl Wed Dec 15 11:49:55 2010 -0500: // decrypt a record by breaking each byte. See
agl Wed Dec 15 11:49:55 2010 -0500: // "Password Interception in a SSL/TLS Channel", Brice
agl Wed Dec 15 11:49:55 2010 -0500: // Canvel et al.
agl Wed Dec 15 11:49:55 2010 -0500: //
robert Wed May 18 13:14:56 2011 -0400: // However, our behavior matches OpenSSL, so we leak
agl Wed Dec 15 11:49:55 2010 -0500: // only as much as they do.

[agl]

On Monday, February 4, 2013 5:00:20 PM UTC-5, Niklas Schnelle wrote:

just found this anouncement http://www.isg.rhul.ac.uk/tls/ of a new atack on TLS. According to the info GnuTLS has just released patches while OpenSSL is still pending.
It doesn't seem like it takes some effort to exploit but it's a real vulnerability none the less. So I guess someone with the needed skills should look into the Go TLS implementation.

Thanks, I had meant to post something about this yesterday.

Go is affected by this but I don't actually plan on fixing it, oddly enough.

There's CipherSuites and PreferServerCipherSuites in tls.Config which can be used to prioritise RC4, which works around the issue. But fixing CBC mode is going to make a complete mess of the code and APIs. I would rather put effort into implementing TLS 1.2 and AES-GCM support than trying to make CBC workable.

That's obviously of somewhat theoretical value if no clients implement AES-GCM, but I'm working on that from the other direction for Firefox and Chrome.

As folks may have noticed, I have shamefully little time to work on Go these days so I can't promise TLS 1.2 support in the immediate future. (Although patches are, of course, welcome!) It also seems to be a good time to reiterate that I'm not aware of any substantial security review of the Go TLS code and that I'm not perfect. It's quite possible that some brown-paper-bag bugs exist in there. If you instead run Go servers behind OpenSSL for terminating SSL/TLS then OpenSSL will be making a release soon that includes a CBC fix that I was involved with.

Cheers

AGL

[Shane Hansen]

I know it's low priority,

But is there any interest from the code go team in supporting AES-GCM?

Would a patch be accepted and make it into 1.1?

Thanks,

--Shane

--

[Patrick Mylund Nielsen]

> But is there any interest from the code go team in supporting AES-GCM?

Yes, TLS 1.2.

> Would a patch be accepted and make it into 1.1?

There is a feature freeze, but given that it's the best alternative to RC4 and CBC (as implemented), which are both bad, maybe. OTOH, it won't be mainstream in the near future anyway.

+rsc

[Adam Langley]

On Fri, Feb 8, 2013 at 1:54 AM, Shane Hansen <shanem...@gmail.com> wrote:
> But is there any interest from the code go team in supporting AES-GCM?

Yes. Bonus points for using AES-NI for GHASH and doing the generic
version of GHASH so that it doesn't leak timing-information like a
sieve. (Neither are needed for a first pass.)

I wrote a simple GHASH for Chromium here:
http://src.chromium.org/viewvc/chrome/trunk/src/crypto/ghash.cc?view=markup

It could certainly be quicker and more secure, but it works. I was
planning on porting to Go at some point.

> Would a patch be accepted and make it into 1.1?

I don't think it would make 1.1


Cheers

AGL

[Shane Hansen]

I'd love to take that on once my tar commit makes it through.

I have AES-NI hardware I'm interested in trying out the assembly version on.

I'd love to see go ahead of the curve when it comes to security and performance.

Should I create an issue and see if it get's accepted, or just go to town?

[Adam Langley]

On Fri, Feb 8, 2013 at 4:03 PM, Shane Hansen <shanem...@gmail.com> wrote:
> Should I create an issue and see if it get's accepted, or just go to town?

I think creating a bug is fine. Since we're in feature freeze for 1.1,
I suggest working on a ghash package in go.crypto at first.

Don't go completely to town all at once. I would do a simple, pure go
version of GHASH first.


Cheers

AGL