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

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

Comments

@zfLQ2qx2
Copy link

@zfLQ2qx2 zfLQ2qx2 commented Oct 23, 2019

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

This comment has been minimized.

Copy link
Contributor

@agnivade agnivade commented Oct 23, 2019

@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

This comment has been minimized.

Copy link
Member

@FiloSottile FiloSottile commented Oct 23, 2019

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

This comment has been minimized.

Copy link
Author

@zfLQ2qx2 zfLQ2qx2 commented Oct 23, 2019

@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

This comment has been minimized.

Copy link
Member

@FiloSottile FiloSottile commented Oct 23, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.