crypto/tls: access to TLS Session ID

[laszlohordos]

I'd like to implement a secure TLS session and make sure both party has the same TLS Session ID but Go does not allow access to that information. I'm using DNS Sec and other Crypto methods to protect against Man-in-the-middle attack and this would be one of the pillar of protection. I described my sample here but I didn't find any other way except to patch the Go so I attached my four line changes.

I'm using Go 1.7.4 with environment

GOBIN=""
GOEXE=""
GOHOSTARCH="arm"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/iot/gopath"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_arm"
CC="gcc"
GOGCCFLAGS="-fPIC -marm -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build546925034=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"

Patch

I used the release-branch.go1.7 branch to make it available.

diff --git a/src/crypto/tls/common.go b/src/crypto/tls/common.go
index 9fc7420..798a3c5 100644
--- a/src/crypto/tls/common.go
+++ b/src/crypto/tls/common.go
@@ -167,6 +167,7 @@ type ConnectionState struct {
 	VerifiedChains              [][]*x509.Certificate // verified chains built from PeerCertificates
 	SignedCertificateTimestamps [][]byte              // SCTs from the server, if any
 	OCSPResponse                []byte                // stapled OCSP response from server, if any
+	TLSSessionID                string                // https://tools.ietf.org/html/rfc4507#section-3.4
 
 	// TLSUnique contains the "tls-unique" channel binding value (see RFC
 	// 5929, section 3). For resumed sessions this value will be nil
diff --git a/src/crypto/tls/conn.go b/src/crypto/tls/conn.go
index 77fd6d3..b40667d 100644
--- a/src/crypto/tls/conn.go
+++ b/src/crypto/tls/conn.go
@@ -71,6 +71,7 @@ type Conn struct {
 	clientFinished [12]byte
 	serverFinished [12]byte
 
+	sessionId              string
 	clientProtocol         string
 	clientProtocolFallback bool
 
@@ -1295,6 +1296,7 @@ func (c *Conn) ConnectionState() ConnectionState {
 		state.ServerName = c.serverName
 		state.SignedCertificateTimestamps = c.scts
 		state.OCSPResponse = c.ocspResponse
+		state.TLSSessionID = c.sessionId
 		if !c.didResume {
 			if c.clientFinishedIsFirst {
 				state.TLSUnique = c.clientFinished[:]
diff --git a/src/crypto/tls/handshake_client.go b/src/crypto/tls/handshake_client.go
index f789e6f..5d6a14b 100644
--- a/src/crypto/tls/handshake_client.go
+++ b/src/crypto/tls/handshake_client.go
@@ -250,6 +250,7 @@ NextCipherSuite:
 		sessionCache.Put(cacheKey, hs.session)
 	}
 
+	c.sessionId = hs.serverHello.sessionId
 	c.didResume = isResume
 	c.handshakeComplete = true
 	c.cipherSuite = suite.id
diff --git a/src/crypto/tls/handshake_server.go b/src/crypto/tls/handshake_server.go
index 1aac729..7d92022 100644
--- a/src/crypto/tls/handshake_server.go
+++ b/src/crypto/tls/handshake_server.go
@@ -105,6 +105,7 @@ func (c *Conn) serverHandshake() error {
 		}
 	}
 	c.handshakeComplete = true
+	c.sessionId = hs.hello.sessionId
 
 	return nil
 }

[bradfitz]

To @agl for decision.

[agl]

The TLS Finished hash closes over the session ID so, if the connection is successful, you don't need to check that they match.

[laszlohordos]

I may not expressed the issue well by judging your answer. The TLS session is established and I have it between the Client and one Server. Hopefully with the right server and hope there is no Man-in-the-middle but how can I be sure? I have to do a DNS-Sec + using the Certificate pinning and hope the private key of other party is not corrupted. This is an IoT use case where devices communicating with each other and those hardwares may not capable to protect their key pair in Go environment. I'm using the GlobalPlatform but unfortunately the TLS Session may be made from the OS which is untrusted so I'd like to add extra security and from a Trusted Environment ensure I'm using the very same TLS Session to exchange the data with the correct other party. In Go language it's impossible because of these 4 lines missing. I'm open to discuss the use case further and with a good reason accept if it's denied but I just want to be sure it's Closed because of good reason and not because not clearly understand the problem.

There is and Active TLS Session where I'm exchanging multiple HTTP or MQTT messages and part of the authentication I'd like to HMAC the sessionId with a secret PSK and add it to the message so I can be sure the communication is not intercepted by any third-party. I may use a Secure Element Applet to do so but this is really a blocking issue for me now.

[minux]

Sorry, I don't understand the feature request. If the client is not capable of keeping the private key secure, then anyone that gets hold of the private key can impersonate that client (it might not be able to do MITM if the client has certificate pinning, but being able to impersonate a client already means the security between that (client, server) pair is already compromised. I don't think you can do anything better in this situation with TLS alone.

[agl]

It sounds like you want a value that identifies the TLS connection and that you can have the two sides authenticate at a higher level to ensure that they are both seeing the same connection, and not two different connections that have a MITM proxying messages between them.

The session ID is not that value; it does not identify the connection in the way that I think you want. Rather you want the TLSUnique field in the crypto/tls.ConnectionState struct. Due to weaknesses in the TLS protocol you either need to disable resumption or else ensure that both ends of the connection implement extended master secrets. (See docs.)

[laszlohordos]

Thank you Adam. This is what I really want to achieve. I used the TLSUnique in Go before but unfortunately I was not aware of the limitation of Java Servlet which only exposes the SessionId and I was advised to use that. After doing my research I really need something like The Token Binding Protocol Version 1.0 in the future. I found your explanation very helpful and it makes complete sense. Now I see the TLSSessionID next to TLSUnique would server only debugging purpose nothing more.