New atack against TLS/DTLS published

712 views
Skip to first unread message

Niklas Schnelle

unread,
Feb 4, 2013, 5:00:20 PM2/4/13
to golan...@googlegroups.com
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

unread,
Feb 4, 2013, 5:04:03 PM2/4/13
to Niklas Schnelle, golang-nuts




--
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

unread,
Feb 4, 2013, 5:10:56 PM2/4/13
to golan...@googlegroups.com, Niklas Schnelle
Now I'm impressed. Just shows how amazing the Go team really is

Dan Kortschak

unread,
Feb 4, 2013, 5:19:14 PM2/4/13
to Patrick Mylund Nielsen, Niklas Schnelle, golang-nuts
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

unread,
Feb 5, 2013, 9:51:24 AM2/5/13
to golan...@googlegroups.com
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

unread,
Feb 8, 2013, 1:54:39 AM2/8/13
to agl, golan...@googlegroups.com
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

unread,
Feb 8, 2013, 2:07:37 AM2/8/13
to Shane Hansen, Russ Cox, agl, golang-nuts
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

unread,
Feb 8, 2013, 10:11:53 AM2/8/13
to Shane Hansen, golang-nuts
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

unread,
Feb 8, 2013, 4:03:55 PM2/8/13
to Adam Langley, golang-nuts
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

unread,
Feb 8, 2013, 4:07:37 PM2/8/13
to Shane Hansen, golang-nuts
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
Reply all
Reply to author
Forward
0 new messages