Daiki Ueno [Fri, 1 Jun 2018 13:04:49 +0000 (15:04 +0200)]
tls13/session_ticket: don't send ticket when no common KE modes
When the server had received psk_key_exchange_modes extension which
doesn't have any overlap with the server configuration, omit to send
NewSessionTicket.
Daiki Ueno [Tue, 5 Jun 2018 12:08:26 +0000 (14:08 +0200)]
ext/psk_ke_modes: always send extension unless disabled in config
With the psk_key_exchange_modes extension, clients can restrict the
key exchange modes for use with resumption and in that case the server
shouldn't send NewSessionTicket. This patch makes use of it to avoid
receiving useless tickets, by sending the psk_key_exchange_modes
extension unless PSK is completely disabled.
A couple of tests need to be adjusted: tls13/prf to take into account
of the psk_key_exchange_modes extension sent, and tls13/no-psk-exts to
not treat the presence of the extension as error.
Daiki Ueno [Fri, 1 Jun 2018 07:54:41 +0000 (09:54 +0200)]
ext/pre_shared_key: make PSK identity parsing robuster
Previously, to determine whether a PSK identity is a ticket or a PSK
username, it relied on PskIdentity.obfuscated_ticket_age, which
"SHOULD" be 0 if the identity is a PSK username.
This patch instead checks the key name of the ticket first and then
check the constraints of the PSK username. That way, it can
distinguish tickets and PSK usernames in a more realible manner.
Tim Rühsen [Thu, 24 May 2018 10:45:32 +0000 (12:45 +0200)]
Fix more warnings in tests/
To not introduce larger code changes, these bugs are mostly
fixed by #pragma understood by gcc and clang.
A check for the minimal gcc/clang version prevents warnings about
unknown pragmas with other or older compilers.
tests: added main use-case test for gnutls_session_ticket_send()
It verifies whether a server can use gnutls_session_ticket_send()
to send a ticket after re-authentication, and whether a client
can receive that ticket and re-authenticate with it, while
its certificate is made available to server.
handshake: TLS1.3 async messages trigger the handshake hook
That is, the callback set with gnutls_handshake_set_hook_function() is
now called even on the async handshake messages received under TLS1.3,
such as key update, etc.
That is, check gnutls_session_is_resumed() is functional on server
side, whether PRF is respected on resumption, whether gnutls_certificate_get_peers()
and gnutls_certificate_get_ours() operate as expected, and whether session
resumption fails with tickets after expiration time has passed.
In addition improve function documentation by documenting the current
semantics for the functions above.
This requires a few changes to the resume.c test: because
NewSessionTicket is a post-handshake message,
gnutls_session_get_data2() needs to be called after sending the first
application data. Also, when GNUTLS_E_AGAIN, gnutls_record_recv()
needs to retry.
gnutls-cli: ignore E_AGAIN to accommodate async handshake message
When an async handshake message has arrived while no application data
is available, gnutls_record_recv() returns GNUTLS_E_AGAIN and the loop
in socket_recv() blocks. Since socket_recv() is guarded by select(),
it should be safe to ignore GNUTLS_E_AGAIN.
Ander Juaristi [Mon, 16 Apr 2018 15:13:47 +0000 (17:13 +0200)]
TLS 1.3: Introduced TLS 1.3 session resumption
This introduces session resumption under TLS 1.3. For that,
it enables the psk_ke_modes extension when we enable session
tickets. It enables sending session tickets in addition to
PSK usernames. The detection of resumption vs pure PSK is done by
comparing the indexes sent with the index received by the server.
TLS 1.3 session tickets are always sent to the peer unless the
GNUTLS_NO_TICKETS is specified.
This allows an application to open a PKCS#11 token using a URI,
and use it directly, bypassing gnutls. That is useful to take
advantage of PKCS#11 functionality not wrapped by gnutls but
still use PKCS#11 URIs to identify the token.
Martin Sucha [Thu, 17 May 2018 10:31:01 +0000 (12:31 +0200)]
certtool: use larger serial and CRL numbers
Serial/CRL numbers can be up to 20 octets in length
as per RFC 5280, so it should be possible to use
such numbers as input to certtool. certtool
only allowed to specify 63-bit numbers in
template file or interactively (even though
it generated larger numbers in batch mode
by default).
This patch allows large numbers to be specified
as a hexadecimal string. Parsing of decimal numbers
larger than native integers would require adding
dependency on libgmp directly to certtool or
extending the API exposed by GnuTLS library with parsing
functions. Since most tools (including GnuTLS) display
serial numbers in hexadecimal, it is not worth the
trouble to support large decimal numbers.
Default values are unified between batch mode and
interactive input and their size is extended.
CA/Browser forum recommends CAs to include at least
64 bits of random data in the certificate serial
numbers in Baseline Requirements[1] section 7.1, but
gnutls adds only 32 bits. Some other
implementations generate default serial numbers
with more entropy as well, here is the current state
as of May 2018:
The 20 octet field size can fit numbers up to 159 bits
since the most significant bit must be zero as numbers
in DER encoding are in two's complement and the serial
and CRL numbers must be positive.
Default serial numbers are extended to full 159 bits
allowed by the field size and are completely random,
which matches other implementations.
CRL numbers have the same size requirements, but also
need to be monotonic (RFC 5280, section 5.2.3). That's
why timestamp is used in them. The timestamp portion
is extended from 31 bits to 39 bits as 31 bits will
overflow in year 2038. The rest of the available space
up to 159 bits allowed in the 20 octet limit is filled
with random bits.
Since the new CRL numbers are larger, the requirement for them
to be monotonically increasing is preserved when upgrading to a
newer version. This does not hold the other way around though,
so after using a newer version of certtool to generate a CRL
with default number and publishing it, it's not possible
to use older version anymore to generate subsequent CRLs.
Unfortunately, there is no easy workaround for users of older
certtool, since it is not possible to specify CRL numbers
greater than 63 bits manually prior to this change.
Users intending to downgrade to older version later are advised
to specify the CRL numbers in new version of certtool
manually with values they are smaller than what would get
generated by default in the old version.
grep does not recognize CRLF line endings generated
in tests using MinGW, so we need to convert those to
LF endings for $ in the regex to match test output
correctly.
datefudge 1.21 that is present in Fedora 26
image trims the timestamp to 32 bits. That bug was
fixed in datefudge 1.22 available in the Debian image,
so we check if datefudge behaves correctly
and skip the test that uses more than 32 bits if
datefudge is broken.
handshake: do not send TLS extensions under DTLS and vice versa
That is, introduce the notion of TLS-only and DTLS-only extensions,
providing a framework to prevent sending extensions which are registered
for example for TLS 1.3, under DTLS and vice versa.
tests: testcompat-openssl: disable DSS ciphersuites under SSL3.0
Previously if openssl wouldn't support DSS, we would only disable
DSS under TLS1.0 or later, not under SSL 3.0. This fixes interoperability
with Fedora28 openssl.
post_handshake_auth: send extension irrespective of certificates being present
The feature does not necessarily require certificates to be present
and an empty cert can be presented. Furthermore, the certificates
can be set later on the credentials structure.
projects / thirdparty / gnutls.git / log
