utls unconditionally sets SessionID in all ClientHellos

[rod-hynes]

While attempting to construct a TLS 1.2 parrot that omits the SessionID, I have observed via packet capture that utls always sends a SessionID in the ClientHello, regardless of whether a session ticket is attached.

I believe this is due to changes in the upstream crypto/tls when TLS 1.3 support was added.

As far as I understand it, utls calls makeClientHello here, and uses the results as the base ClientHello:

utls/u_parrots.go

Lines 494 to 500 in 4da6795

	privateHello, ecdheParams, err := uconn.makeClientHello()
	if err != nil {
	return err
	}
	uconn.HandshakeState.Hello = privateHello.getPublicPtr()
	uconn.HandshakeState.State13.EcdheParams = ecdheParams
	hello := uconn.HandshakeState.Hello

Here's where the current makeClientHello, from crypto/tls, unconditionally sets the SessionID:

utls/handshake_client.go

Lines 111 to 116 in 4da6795

	// A random session ID is used to detect when the server accepted a ticket
	// and is resuming a session (see RFC 5077). In TLS 1.3, it's always set as
	// a compatibility measure (see RFC 8446, Section 4.1.2).
	if _, err := io.ReadFull(config.rand(), hello.sessionId); err != nil {
	return nil, nil, errors.New("tls: short read from Rand: " + err.Error())
	}

This is probably desired for TLS 1.3 parrots, as my brief testing shows similar behavior in at least one browser ("compatibility" mode).

In older crypto/tls and utls, makeClientHello doesn't have this unconditional code block and the SessionID is set conditionally, when there's a session ticket, here:

utls/handshake_client.go

Lines 150 to 159 in 03d875d

	if session != nil {
	hello.sessionTicket = session.sessionTicket
	// A random session ID is used to detect when the
	// server accepted the ticket and is resuming a session
	// (see RFC 5077).
	hello.sessionId = make([]byte, 16)
	if _, err := io.ReadFull(c.config.rand(), hello.sessionId); err != nil {
	return errors.New("tls: short read from Rand: " + err.Error())
	}
	}

Has the on-the-wire format of parrots such as HelloIOS_11_1 changed since utls was upgraded to support TLS 1.3?

Of the bundled TLS 1.2 parrots, I can't tell whether the SessionID should or should not be set when there is no session ticket. I didn't find any stats regarding SessionID here, https://tlsfingerprint.io. Is this information in your raw database?

With the existing API, I don't see how to create a parrot that omits the SessionID. It appears not difficult to implement, as something like this can be added after the makeClientHello call in ApplyPreset:

if p.NoDefaultSessionID {
	uconn.HandshakeState.Hello.SessionId = nil
}

NoDefaultSessionID would be a new ClientHelloSpec boolean field that defaults to false. When a session ticket is used, other code already sets a SessionID [again] as required.

It would be simpler to skip the new field and remove the default SessionID for TLS 1.2. I'm not sure that produces correct results in all cases though?

[sergeyfrolov]

I did some manual testing, and it seems that popular browsers still generate a 32 byte SessionID, even when they don't have a ticket. The sessionID-less ClientHello you are trying to mimic: is it popular?

SessionID mechanism predates session tickets, and there are valid ClientHello messages that have SessionID, but not the ticket. Therefore "set session ID if and only if session ticket is set" may not to be the policy we want. Or maybe it is: more pcaps with captures of popular sessionID-less TLS implementations will help make a decision.

The less knobs uTLS has, easier it is to use, and I think we should strive to prevent uTLS users from shooting themselves in the foot. Ideally, users would not be required to specify whether or not their ClientHello should include SessionID, and the uTLS still should try to demonstrate a behavior that is common in the wild(perhaps based on TLS version and extensions), so finding a good default would be incredibly useful here.

I didn't find any stats regarding SessionID here, https://tlsfingerprint.io. Is this information in your raw database?

Unfortunately, no.

With the existing API, I don't see how to create a parrot that omits the SessionID.

You should be able to BuildHandshakeState(), then zero out the session id and call MarshalClientHello() to remarshal it.

[rod-hynes]

The sessionID-less ClientHello you are trying to mimic: is it popular?

It's an older TLS 1.2 ClientHello. In a certain adversarial context, it appears to be more successful than the utls ClientHellos. We don't have much information about popularity.

SessionID mechanism predates session tickets, and there are valid ClientHello messages that have SessionID, but not the ticket.

That's true. Although, hypothetically, could an adversary block all TLS 1.2 flows with ClientHellos containing a non-empty SessionID and the result would be: entirely block all TLS 1.2 clients that unconditionally include a SessionID; and just degrade performance for TLS 1.2 clients that fall back to full handshake and omit the SessionID by default when not resuming?

You should be able to BuildHandshakeState(), then zero out the session id and call MarshalClientHello() to remarshal it.

Thanks. I tested that and it does what we need. It ends up making our code a bit more complex than what I'd imagined with NoDefaultSessionID since we need to do this in several places and be careful to not do it when we have a session ticket.

I'll rename this issue since "Unable to construct a parrot that omits SessionID" is not the case. I won't close it yet, in case you think that the question about how common SessionID is in non-resuming TLS 1.2 flows warrants further consideration.

[frankwalter1301]

more pcaps with captures of popular sessionID-less TLS implementations will help make a decision.

OkHttp(the most popular java http client library) on Android sets an empty session id when it doesn't have one. I think this library should support the mimicking in an easier way.