[gnutls-devel] Server sends incorrect extensions for resumption handshake?
peter.dettman at bouncycastle.org
Sun Jun 30 04:52:06 CEST 2013
I'm currently adding session resumption to the BouncyCastle (Java) TLS
code, and I'm seeing what I think is incorrect behaviour from the
gnutls-serv test server. I'm using GnuTLS 3.2.1 on Win7, with command line:
gnutls-serv --http --x509cafile x509-ca.pem --x509keyfile
x509-server-key.pem --x509certfile x509-server.pem
My test client makes an initial connection to establish a session,
successfully negotiating TLS 1.1, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
secure_renegotiation = true. Note the ServerHello contains two
extensions: renegotiation_info and ec_point_formats. This connection is
closed once the handshake has completed.
The client then tries to resume this session (with essentially the same
ClientHello, excepting client_random, and with the resuming session_id).
If it ignores the errors I am about to describe, it can happily resume
the session, and make a GET request to the http server, getting the
expected page and closing cleanly. However I think the ServerHello is
wrong, specifically the server extensions.
Firstly, the ec_point_formats extension is included in the session
resumption ServerHello. This appears to violate RFC 3546 2.3. "If [...]
the older session is resumed, then the server MUST ignore extensions
appearing in the client hello, and send a server hello containing no
extensions[.]" (later RFC updates contain similar clauses) . Please
understand that the problem is probably broader than just the
ec_point_formats extension; the server shouldn't be sending any. The
only exception to that rule that I am aware of is from RFC 5746,
renegotiation_info, which appears to say that this extension is
per-connection, and can always be sent. This is the second issue I want
to raise: while gnutls-serv sends renegotiation_info during the initial
handshake, it does _not_ send it during a resumption handshake.
I am posting to the list instead of raising a bug report directly,
because it's at least true that 'openssl s_server' also sends
superfluous server extensions during resumption (it sends the
renegotiation_info correctly though) . I would appreciate if anyone can
enlighten me as to whether there is an unofficial standard in play here,
or whether this should be considered a bug.
Please contact me if you'd like replicate the problem, either via the
BouncyCastle test code itself, or in some other way.
More information about the Gnutls-devel