proposal: crypto/tls: support DHE

[swanandt]

What version of Go are you using (go version)?

$ go version
go1.9.2

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
linux/amd64

What did you do?

Work for NOKIA and we are planning to develop API Gateway with go for Telecom Apps.

What did you expect to see?

We want that go-lang to support following cipher suites as well. I have read one reply that DHE is slow and support is dis-continued in browser but I think now go is not only about browser but because of cloud-native drive even telecom clouds will use REST based apps and I see that go plays important role as it has enriched eco-system. The traditional model use openssl and it supports all these ciphers already. I want to see go-lang also be in par with openssl as it shall not just about Browsers anymore :-)

For Telco Cloud Apps these are still good to have instead of just only ECDHE as to be feature-Parity. I assume K8S [ which also seems in go ] and creating foot-prints in telco cloud having such support in golang is not only good but also appears more like "shall have " :-)

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (DH 2048)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (DH 2048)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (DH 2048)
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (DH 2048)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (DH 2048)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (DH 2048)
TLS_RSA_WITH_AES_256_CBC_SHA256 (RSA 2048)

What did you see instead?

No Support for DHE

[dominikh]

The traditional model use openssl and it supports all these ciphers already. I want to see go-lang also be in par with openssl as it shall not just about Browsers anymore

For Telco Cloud Apps these are still good to have instead of just only ECDHE as to be feature-Parity

Feature parity in itself isn't a goal. What stops "Telco Cloud" from using modern ciphers instead?

[swanandt]

Hi I think the point is not more specifically about feature parity but more about accommodative solution offering. If some solution offers only latest the vast investment and vast volume of solution on the field can be invalidated because of new better ciphers. Even if you check openssl which is more like standard for crypto also did not invalidated these ciphers .... I see this way go is going to be more accommodative like openssl and enrich further it's offering in crypto package... I see there was one fork made in some earlier response for such request but I think it will be better if such support can be added natively from go lang community... Also how much is the effort do you see to add it... Thanks in advance Swan

…

On Thu, 9 May, 2019, 18:28 Dominik Honnef, ***@***.***> wrote: The traditional model use openssl and it supports all these ciphers already. I want to see go-lang also be in par with openssl as it shall not just about Browsers anymore For Telco Cloud Apps these are still good to have instead of just only ECDHE as to be feature-Parity Feature parity in itself isn't a goal. What stops "Telco Cloud" from using modern ciphers instead? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#31933 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALI63UW26DQCJK6JB6LKXADPUQNVPANCNFSM4HLX36BA> .

[jamie-digital]

OpenSSL has historically implemented almost every available feature, which has resulted in a bloated and complex implementation with several vulnerabilities. Go is taking the approach of implementing the (slightly more than minimum) necessary functionality to be useful so that the codebase is reasonably easy to understand and thus much less likely to be vulnerable.

DHE as implemented in TLS is a massive footgun, as there's no enforced standardisation of groups. I think there would need to be a pretty compelling reason to add new functionality which is arguably less secure than what's already present.

[swanandt]

Hi

The more compelling reason, I can think is ROI for each customer who has vast volumes of deployment. If the new solution completely makes them unusable then it is big business loss to them and cant compel upgrade if they dont wish to . For telco eco-system it is more a "business loss"

I have few questions now
Q: If no TLS Config is not passed to go-lang net/http Server which uses ListenAndServeTLS, will it accept the client connection with ciphers not mentioned in cipher_suites ?

Q: If we still wish to add support for
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA256
DHE-RSA-AES256-SHA
AES256-GCM-SHA384
AES256-SHA256
AES256-SHA
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-SHA256
DHE-RSA-AES128-SHA
AES128-GCM-SHA256
AES128-SHA256
AES128-SHA

What does it mean ? only adding those constants and test stub for it OR
It means complex implementation for these apart from what you already have in crypto/tls ?

Q: As I mentioned about the business case, do you have any suggestion what is best way to do it if we still wish to lock on crypto/tls or move to other fork ?

Q: Also if we set following flag to false will the clients preferred list will be used and basically override default ciphers-suite of Server which is using crypto/tls package ? Can using this flag we can support what I have mentioned above ?
PreferServerCipherSuites

Thanks
Swan

[swanandt]

Any Comments on above questions ?? Can we use external TLS stack with net/http ?

[jamie-digital]

Provided the external TLS stack has the same overall behaviour (transparently and automatically performing a handshake) and has a net.Listener interface then you can use it easily enough with a server:

srv := &http.Server{ /* ... */ }
ln, err := tls.Listen( /* ... */ )
if err != nil { /* handle error */ }
srv.Serve(ln)

Supporting an external TLS stack with an HTTP client would be a little more involved but you'd essentially create a new http.Transport and override DialTLS with a function dialing using the TLS package.

[swanandt]

Our source Code is something like

 s.server = &http.Server{ Addr:         address, Handler:      handler,
	ReadTimeout:  s.globalConfig.RespondingTimeouts.ReadTimeout,
	WriteTimeout: s.globalConfig.RespondingTimeouts.WriteTimeout,
	IdleTimeout:  s.globalConfig.RespondingTimeouts.IdleTimeout,
}
listener, err := net.Listen("tcp4", address
....
...
s.server.ServeTLS(listener, s.globalConfig.TLS.CertFile, s.globalConfig.TLS.KeyFile)

We are not using tls.Config which is part of http Server Structure member.

Q: If in server instantiation if we dont use tls.Config will it still using go-lang specific crypto implementation in ServeTLS code ?
Q: In the crypto/tls package there is a note " Package tls partially implements TLS 1.2, as specified in RFC 5246" What are exceptions from RFC 5246 which is not supported by this package ??

Quick search results in:
https://godoc.org/github.com/spacemonkeygo/openssl#NewListener

Looks like this can be used as wrapper around if we wish to use openssl TLS stack.