crypto/tls: handshake failure with www.ksecurity.or.kr

[Rohsichan]

Go version

go version go1.20.11 linux/amd64

Reproducibility

• Does this issue reproduce with the latest release?

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

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/root/go/pkg/mod"
GOOS="linux"
GOPATH="/root/go"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.20.11"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build896829207=/tmp/go-build -gno-record-gcc-switches"

What did you do?

https://go.dev/play/p/tpcoHIgSxNp

I created a program to access https://www.ksecurity.or.kr

What did you expect to see?

I looked forward to receiving your response normally.

What did you see instead?

I checked that tls 1.3 communication is made with the browser and curl commands.
If Golang supports only tls 1.2, I checked the normal connection.

[mengzhuo]

cc @neild

FYI This site supports TLS 1.0/1.1/1.2

https://www.ssllabs.com/ssltest/analyze.html?d=www.ksecurity.or.kr

[seankhliao]

cc @golang/security

[drakkan]

Hello,

it works if you set the max tls version to 1.2 like this

client := &http.Client{
		Timeout: time.Second * 30,
		Transport: &http.Transport{
			TLSClientConfig: &tls.Config{
				MaxVersion: tls.VersionTLS12,
			},
		},
	}

I'll try to better investigate in the next few days

[Jorropo]

Interestingly the remote is sending the handshake failure.

[Goclipse27]

Adding few more findings that will help

Chrome ============
IN chrome > developer tools > security

• www.ksecurity.or.kr it says under security section it is encrypted & authenticated using tls1.3 -
• https://tls-v1-2.badssl.com/ supports tls1.2 and responds 200 ok
• ===========
  In golang code, I did some deep down debug and found this , for www.ksecurity.or.kr, golang > crypto > tls throws an alert recordTypeAlert - 21 in handshake and the unicode character that was under check is "U+0015" - NAK.

where as tls1.2 site responds to http client 200 ok needless to say about other common tls1.3 sites.

I am wondering what is the response from the site brings the character in TLS record.

[Goclipse27]

@Rohsichan - Is this RSA-PSS , if the Key is tool small we may encountered this handshake failure in tls1.3?

[Rohsichan]

@raghvenders I don't know much about that.
I'm not the owner of that server.
I found out while accidentally accessing it.

[Goclipse27]

@Rohsichan - Looks lit it is - RSA-PSS attached screenshot from chrome -

It is similar to example.com except ksecurity is AES_128 in the cipher.

Can you try example.com, it works.

Both are tls1.3 conformant - https://datatracker.ietf.org/doc/html/rfc8446#page-41 - TLS_AES_128_GCM_SHA256

[Rohsichan]

I've been to a lot of www.example.om sites. The tls connection is good.

[Goclipse27]

@Rohsichan @cc @golang/security - Figured Out the issue. Working on the Fix.

[Goclipse27]

It is not working for www.ksecurity.or.kr because of this - https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.9

A client MUST provide a "psk_key_exchange_modes" extension if it
offers a "pre_shared_key" extension. If clients offer
"pre_shared_key" without a "psk_key_exchange_modes" extension,
servers MUST abort the handshake.

However this I have not encountered for other sites - example.com or some other sites.(Needs to be investigated)

currently it is skipped based on PSK Key Exchange Modes and other ClientSessionCache or SessionTicketsDisabled.

After I set - PSK - Exchange Mode , It works - 200 OK.

@rolandshoemaker @golang/security - Can somebody give some more insight on this.

[varianone]

The same issue can be also observed with https://www.aeroportodinapoli.it works with CURL but not with golang client. If golang set to MaxVersion to be TLS1.2 it works, but not with TLS 1.3.

@raghvenders can you please share more details on the changes you did to make it work with golang?

Update
looks like setting ClientSessionCache: tls.NewLRUClientSessionCache(2) in the tls.Config works around this issue.

figured based on this:

func (c *Conn) loadSession(hello *clientHelloMsg) (
	session *SessionState, earlySecret, binderKey []byte, err error) {
	if c.config.SessionTicketsDisabled || c.config.ClientSessionCache == nil {
		return nil, nil, nil, nil
	}