Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

crypto/tls: TLS 1.3 only negotiates weakest possible cipher #35096

Closed
zfLQ2qx2 opened this issue Oct 23, 2019 · 4 comments
Closed

crypto/tls: TLS 1.3 only negotiates weakest possible cipher #35096

zfLQ2qx2 opened this issue Oct 23, 2019 · 4 comments
Labels
FrozenDueToAge

Comments

@zfLQ2qx2
Copy link

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

go version go1.13.3 darwin/amd64

Does this issue reproduce with the latest release?

yes

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

MacOS darwin/amd64

What did you do?

Received TLS 1.3 connection

What did you expect to see?

Connection negotiated with TLS_CHACHA20_POLY1305_SHA256 or TLS_AES_256_GCM_SHA384 cipher

What did you see instead?

Connection was negotiated with TLS_AES_128_GCM_SHA256 cipher

So someone went through a lot of trouble to make ciphers non-configurable under TLS 1.3, however by default it negotiates the weakest cipher. I don't see why the stronger ciphers are not selected if both sides support them, or why its not configurable if someone feels strongly that the weakest cipher is good enough - why not allow people to opt in to preferring the stronger ciphers.
@agnivade
Copy link
Contributor

@FiloSottile

@FiloSottile FiloSottile changed the title TLS 1.3 only negotiates weakest possible cipher crypto/tls: TLS 1.3 only negotiates weakest possible cipher Oct 23, 2019
@FiloSottile
Copy link
Contributor

Without PreferServerCihersuites the preference order is based on the client's preference. The server side preference order is based on the hardware support, to optimize for the best performance, as all cipher suites provide plenty of security margin. crypto/tls doesn't let applications configure a number of things (like signature algorithms) when a safe choice can be made by the library, cipher suites are no different.

@zfLQ2qx2
Copy link
Author

@FiloSottile can you point me to where the decision is made in crypto/tls? I would like to see if my client is purposefully picking the weakest cipher or just taking the first one the server offers. It is closed source so I can’t see what it’s logic is.

@FiloSottile
Copy link
Contributor

go/src/crypto/tls/handshake_server_tls13.go

Lines 150 to 170 in 0fb95e7

var preferenceList, supportedList []uint16
if c.config.PreferServerCipherSuites {
preferenceList = defaultCipherSuitesTLS13()
supportedList = hs.clientHello.cipherSuites
} else {
preferenceList = hs.clientHello.cipherSuites
supportedList = defaultCipherSuitesTLS13()
}
for _, suiteID := range preferenceList {
hs.suite = mutualCipherSuiteTLS13(supportedList, suiteID)
if hs.suite != nil {
break
}
}
if hs.suite == nil {
c.sendAlert(alertHandshakeFailure)
return errors.New("tls: no cipher suite supported by both client and server")
}
c.cipherSuite = hs.suite.id
hs.hello.cipherSuite = hs.suite.id
hs.transcript = hs.suite.hash.New()

@golang golang locked and limited conversation to collaborators Oct 22, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@FiloSottile @agnivade @gopherbot @zfLQ2qx2