crypto/tls: add DHE support

[gopherbot]

by stalkr:

ECDHE is supported but not DHE. It would be nice to support it so it could be added to
existing cipher suites.

Server https://developers.databox.com only support DHE ciphers:
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA256
DHE-RSA-AES256-SHA
DHE-RSA-CAMELLIA256-SHA
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-SHA256
DHE-RSA-AES128-SHA
DHE-RSA-SEED-SHA

Which makes Go fail: Get https://developers.databox.com: remote error: handshake failure

Reference: https://groups.google.com/forum/#!topic/golang-nuts/hqm_ssUNUtI

[gopherbot]

Comment 1 by frank@runscope.com:

I'm also seeing errors in the CA chain for 
Get https://api.moip.com.br/: x509: certificate signed by unknown authority (possibly
because of "x509: cannot verify signature: algorithm unimplemented" while trying to
verify candidate authority certificate "COMODO RSA Certification Authority")
It seems like everyone reissuing/updating certificates with the recent Heartbleed
announcement are getting new certificates that aren't fully supported by crypto/tls.

[gopherbot]

Comment 2 by stalkr:

re #1: as replied on go-nuts this is a separate issue, crypto/sha512 is not imported by
default (see also https://golang.org/cl/84700045).

[gopherbot]

Comment 4 by stalkr:

re #2: crypto/sha512 is now imported by default https://golang.org/cl/87670045

[ianlancetaylor]

Comment 5:

Labels changed: added repo-main, release-none.

[mstoykov]

Is this being worked on?

Or does anyone know how to work around this?

[bradfitz]

@MStoykov, I would ask on the golang-nuts mailing list. But I don't know of anybody working on this.

[ghost]

What's the status on this?

[bradfitz]

@emansom, doesn't look like. Does this affect you? For which site?

@agl, is it your intention to ever implement this? If not, please close with a reason.

[agl]

DHE is slow, has compatibility issues over 1024 bits and is getting removed in browsers. No plans to support it.

[mark-kubacki]

For sites and networks where nistp* curves are banned, it's either DHE or implementing one of the alternative curves or curve families.

@MStoykov If you still need DHE support, drop me a line. I can point you to vendors that share (sell) customizations.

[mstoykov]

@wmark Thanks, but as this was an internal (apache) server we just reconfigured it to support modern algorithms :)

[mordyovits]

I have implemented the DHE ciphersuites (well, just the AES ones) in my fork of crypto/tls . It works well, and includes both client and server support for: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA

(Why only RSA? Because if you have an EC server cert you probably will just use ECDH. Right?)

I don't yet know how to go about getting it merged into mainline, but before I go through the effort to learn, is there any official interesting in including it?

Some arguments in its favor: 1) It's needed by some people. Me, for example, which is why I wrote it and why tickets such as this one were opened.

2) It's default off (flag suiteDefaultOff). Any client or server code that does not explicitly set Config.CipherSuites to include the DHE ciphers will never use it.

3) It's low priority, just above the (also default off) RC4.

Thanks. I'd really love the chance to have my code reviewed and to contribute this functionality.

[bradfitz]

@mordyovits, this issue was already closed with a decision by @agl.

[mordyovits]

@bradfitz @agl Can that be reconsidered? The code is written and working. The added ciphers default off. That means there currently exists zero Go code in world that when compiled would cause DHE to be used, since no code could have explicitly configured it. To my mind, that's a good argument: only future code that goes out of its way to ask for it will ever use it.

The issues with DHE are compatibility and speed, not security (given acceptable key size). Therefore, I think default off DHE ciphersuites should be acceptable.

[mordyovits]

Also, I've added PSK and DHE_PSK ciphersuites. I'd like to have those considered for inclusion, but I think that should be its own issue, because it required deeper surgery to remove assumptions about there always being a server cert.

[bradfitz]

There's also an ongoing maintenance cost (refactoring, security) and binary size you didn't include in your list of counterarguments.

[mordyovits]

Sure, but the point of crypto/tls is to implement TLS for people who use Go. People who want to use these ciphers in Go will have to go elsewhere. Not everything is Chrome or a Google webserver. Why not make Go usable for as many kinds of things as possible? Especially since the code is structured so that no one can expose it by accident.

As for maintenance & binary size, it's a small patch. The diffstat for everything including DHE, PSK and DHE_PSK, but not _test is:

alert.go | 2 cipher_suites.go | 87 ++++++- common.go | 28 ++ handshake_client.go | 129 ++++++----- handshake_server.go | 75 +++--- key_agreement.go | 598 +++++++++++++++++++++++++++++++++++++ tls.go | 71 +++++-

Thanks for considering it.

[mordyovits]

You can find my fork with DHE ciphersuite support here: https://github.com/mordyovits/golang-crypto-tls

[mark-kubacki]

@mordyovits Reading your code for literary one minute I have spotted two flaws, in key_agreement.go: Not mitigating the small subgroup attack; not checking if the agreed-upon value is large enough.

[mordyovits]

@wmark Thanks! I've emailed you to discuss it.