| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
That is, we require a signing certificate when negotiating
TLS1.3, or when sending a client certificate (on all cases).
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
This only takes into account certificates in the credentials structure.
If certificates are provided in a callback, these must be checked by
the provider. For that we assume that the credentials structure is
filled when associated with a session; if not then the fallback mechanism
will not work and the handshake will fail.
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
|
|
|
|
| |
Signed-off-by: Tom Vrancken <dev@tomvrancken.nl>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
| |
Relates #400
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
|
|
|
|
|
|
| |
Resolves #285
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
|
|
|
|
| |
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
|
|
|
|
|
|
| |
This reverts commit ef44477127952c13e93d7ea88f7b549bf36602f5.
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
|
|
|
|
|
|
|
|
| |
They have been modified in the latest (yet unsupported) TLS 1.3
drafts, so prevent causes interoperability failures by keeping them
on.
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>
|
|
|
|
|
|
| |
That includes tests with RSA and RSA-PSS server and client certificates.
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
|
| |
|
| |
|
|
That is introduce separate checks for each key exchange on every TLS version.
|