On Mon, 28 Nov 2016, Lucas Pardue wrote:

>> Sorry but no, libcurl will only try to reuse session IDs for connections
>> done to the same name, port and protocol as used previously.
>
> I find this topic really interesting. Are the rules you describe just for
> libcurl or is that how all (good) TLS clients are supposed to behave? I've
> searched for a definitive, simple answer to session ID reuse but it has so
> far escaped me. Session reuse is talked about in the various RFCs I have
> come across but when SNI is thrown into the mix I'm unsure as to the answer.

I'm not aware of any good such guidelines so I am equally in the mist as you.
I suppose our friends working on HTTPS in browsers might have something to
teach us on this topic.

But libcurl does TCP connection reuse based on the name + port and we don't
keep for example the list of SAN names around so we really only have names +
port (and protocol) to use for comparisons.

> The reason I ask is because if it is allowed by the specs, this may be
> something we wish to explore implementing in the codebase. If this is
> something the specs recommend not to do, then it should certainly not be
> implemented.

The TLS 1.2 spec (https://tools.ietf.org/html/rfc5246#appendix-F.1.4) doesn't
say much more than:

    Sessions cannot be resumed unless both the client and server agree.
    If either party suspects that the session may have been compromised,
    or that certificates may have expired or been revoked, it should
    force a full handshake.

... so there's really nothing _forbidding_ attempting to reuse the IDs more
widely than on a per-name basis.

But to be fair, it might also be a bit of an edge case where you actually want
to and can resume a connection to another host name than what you just used.

> To expand on some of the detail Sam provided. We have a Wireshark trace
> where the old libcurl client (CentOS 7 libcurl/7.29.0 and NSS/3.19.1) makes
> several requests to different names on the same host. We observe the client
> reusing a session ID like so: (sanitsation-wise we have host example.net and
> certificate SAN example.net and *.example.net)

Right, NSS has its own session-ID logic that I'm not very well versed in, so I
can't tell exactly how that works. Or worked, as Samuel said it doesn't work
like that anymore.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html