| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Signed-off-by: Tim Rühsen <tim.ruehsen@gmx.de>
|
| |
|
|
|
|
|
| |
When a key share extension is not seen under TLS1.3, send
the missing extension alert.
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
|
| |
|
|
|
|
|
|
|
| |
That is, when generating the public key based on the server's
key share, ensure that the algorithms match completely with
the key shares the client initially sent. This was detected
by the updated traces for TLS1.3 fuzzying.
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
|
| |
|
|
|
|
| |
Split combined ECC extensions into different files.
Signed-off-by: Tom Vrancken <dev@tomvrancken.nl>
|
| |
|
|
|
|
|
|
|
|
| |
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.
Resolves #440
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reason is that these ciphersuites cannot be negotiated using TLS1.3.
There is a different strategy followed for these.
* NULL ciphersuites: they are not something normally enabled and used
for debugging purposes mostly. When set both in client and server side
only TLS1.2 can be used.
* SRP ciphersuites: they are used on client side when the client is actually
performing a username-password authentication with SRP. On server side we
can have indeed a server support SRP and non-SRP. In that case we limit
both on TLS1.2. That an unfortunate restriction, but is not a regression
and IMHO these servers would most likely be phased out as very few would
want to stick to TLS1.2 connections for SRP; or we may have an SRP update
for TLS1.3 which could lift that limitation in the future.
* ANON ciphersuites: they are used in certain client/server setups where very
basic level of security is required, and in opportunistic encryption scenarios.
There is a difference in the handling of these cases. In the case of Anon-only
server/clients they provide the session with anonymous credentials structure; in
the case of opportunistic encryption they provide both certificate and anonymous
credentials. Thus we allow the protocol (TLS1.3) be in the priorities, but if we
see no certificate or PSK credentials we disable TLS1.3 negotiation.
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
That adds support for pre-shared keys with and without Diffie-Hellman
key exchange. That's a modified version of initial Ander's patch.
Resolves #414
Resolves #125
Signed-off-by: Ander Juaristi <a@juaristi.eus>
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
That is, when %SERVER_PRECEDENCE is given in the priority string make
sure that the negotiated curve of DH group respects the server's priorities.
That's very relevant under TLS1.3 as ciphersuite negotiation itself, where
%SERVER_PRECEDENCE applied, does contain only the cipher algorithm and MAC
unlike TLS1.2 which included key exchange as well.
Resolves #378
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
|
| |
|
|
|
|
|
|
| |
This is a draft-ietf-tls-tls13-23 change.
Resolves #398
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
|
| |
|
|
|
|
|
|
|
| |
That is, to reduce memory usage as these protocol cannot be used
in parallel.
Relates: #281
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
|
| |
|
|
|
|
|
| |
That is, with the view of separating the data needed for
TLS1.2 and earlier and TLS1.3.
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
That way the application can adjust the range of keys generated
during client hello attempting to guess the server's algorithm.
Applications are intentionally not given the option to select the
algorithm in the key share, but rather chose from the prioritized
list of groups, to avoid a disconnect between the prioritized
groups, and the key share sent.
Relates #284
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
|
| |
|
|
| |
Signed-off-by: Nikos Mavrogiannopoulos <nmav@gnutls.org>
|
| |
|
|
| |
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
|
| |
|
|
| |
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
|
| |
|
|
| |
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
|
| |
|
|
| |
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
|
| |
|
|
| |
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
|
| |
|
|
|
|
|
| |
That's a step towards unification of TLS-type extension handling
for TLS 1.3.
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
|
| |
|
|
| |
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
|
| |
|
|
| |
Signed-off-by: Nikos Mavrogiannopoulos <nmav@gnutls.org>
|
| |
|
|
|
|
|
|
|
| |
We were previously using the variable named 'type' to indicate the
extension ID. With TLS 1.3, extensions are also given an applicability
type (which message the extension applies to), and thus renamed the
variable for clarity.
Signed-off-by: Nikos Mavrogiannopoulos <nmav@gnutls.org>
|
|
|
This enables TLS 1.3 key exchange based on the key share extension.
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
|
