History log of /openbsd/lib/libssl/ssl_tlsext.c (Results 1 – 25 of 154)
Revision Date Author Comments
# e80243f4 09-Jul-2024 beck <beck@openbsd.org>

Fix TLS key share check to not fire when using < TLS 1.3

The check was being too aggressive and was catching us when the
extension was being sent by a client which supports tls 1.3 but
the server wa

Fix TLS key share check to not fire when using < TLS 1.3

The check was being too aggressive and was catching us when the
extension was being sent by a client which supports tls 1.3 but
the server was capped at TLS 1.2. This moves the check after the
max version check, so we won't error out if we do not support
TLS 1.3

Reported by obsd@bartula.de

ok tb@

show more ...


# a2ca3e8a 26-Jun-2024 tb <tb@openbsd.org>

remove psk_idx from tlsext_randomize_build_order()

ok jsing


# 78db451b 26-Jun-2024 tb <tb@openbsd.org>

tls_extension_find(): make output index optional

suggested by jsing


# d0e64422 25-Jun-2024 tb <tb@openbsd.org>

Fix TLS extension shuffling

The diff decoupling the shuffle from the table order still relied on PSK
being last because it failed to adjust the upper bound in the for loop.

ok jsing


# 876d5c25 06-Jun-2024 tb <tb@openbsd.org>

ssl_tlsext: fix uninitialized variable warning with gcc

This is a false positive but as is well-known, gcc is terrible at
understanding conditionally initialized variables and it is tedious
to expla

ssl_tlsext: fix uninitialized variable warning with gcc

This is a false positive but as is well-known, gcc is terrible at
understanding conditionally initialized variables and it is tedious
to explain this to downstream maintainers who look at warnings.

ok miod

show more ...


# 5829f96e 16-Apr-2024 tb <tb@openbsd.org>

Fix key share negotiation in HRR case

In the ClientHello retrying the handshake after a HelloRetryRequest, the
client must send a single key share matching the group selected by the
server in the HR

Fix key share negotiation in HRR case

In the ClientHello retrying the handshake after a HelloRetryRequest, the
client must send a single key share matching the group selected by the
server in the HRR. This is not necessarily the mutually preferred group.
Incorrect logic added in ssl_tlsect.c r1.134 would potentially reject
such a key share because of that.

Instead, add logic to ensure on the server side that there is a single
share matching the group we selected in the HRR.

Fixes a regress test in p5-IO-Socket-SSL where server is configured
with P-521:P-384 and the client with P-256:P-384:P-521. Since the
client sends an initial P-256 key share, a HRR is triggered which
the faulty logic rejected because it was not the mutually preferred
P-384 but rather matching the server-selected P-521.

This will need some deduplication in subsequent commits. We may also
want to consider honoring the mutual preference and request a key
accordingly in the HRR.

reported by bluhm, fix suggested by jsing
ok beck jsing

show more ...


# 0579e8e8 04-Apr-2024 tb <tb@openbsd.org>

Recommit a better version of the removal of the F5 workaround

Unlike for previous TLS versions, TLSv1.3 servers can send the supported
groups extension to inform a client of the server's preferences

Recommit a better version of the removal of the F5 workaround

Unlike for previous TLS versions, TLSv1.3 servers can send the supported
groups extension to inform a client of the server's preferences. The
intention is that a client can adapt for subsequent commits. We ignore
this info for now, but sthen ran into java-based servers that do this.

Thus, rejecting the extension outright was incorrect. Instead, only allow
the extension in TLSv1.3 encrypted extensions. This way the F5 workaround
is also disabled, but we continue to interoperate with TLSv1.3 servers that
do follow the last paragraph of RFC 8446, section 4.2.7.

This mostly adjusts outdated/misleading comments.

ok jsing sthen

show more ...


# 5c3b91f6 02-Apr-2024 sthen <sthen@openbsd.org>

Backout previous commit (intending that libressl client rejects a supported
groups extension from the server). It triggers 'CONNECT_CR_SRVR_HELLO:tlsv1
alert decode error' when connecting to a (moder

Backout previous commit (intending that libressl client rejects a supported
groups extension from the server). It triggers 'CONNECT_CR_SRVR_HELLO:tlsv1
alert decode error' when connecting to a (modern) java server (tomcat 10.1.18
on openjdk 17.0.10).

"please revert" tb@

show more ...


# 130ddb11 28-Mar-2024 beck <beck@openbsd.org>

Stop pandering to the loadbalancer industrial complex.

So we initially kept this hack around for f5 boxes that
should have been patched in 2014, and were not as of 2017.

The f5 article for the bug

Stop pandering to the loadbalancer industrial complex.

So we initially kept this hack around for f5 boxes that
should have been patched in 2014, and were not as of 2017.

The f5 article for the bug archived on their web site,
and any of these devices on the public internet will have
since been upgraded to deal with a host of record layer, TLS,
and other bugs, or they likely won't be talking to modern
stacks, since as of this point the software with the bug
would not have been updated in 10 years.

So just make this spec compliant and reject a supported groups
extension that should not have been sent by a server.

ok tb@ jsing@

show more ...


# be89428c 27-Mar-2024 beck <beck@openbsd.org>

Fix up server processing of key shares.

Ensure that the client can not provide a duplicate key share
for any group, or send more key shares than groups they support.

Ensure that the key shares must

Fix up server processing of key shares.

Ensure that the client can not provide a duplicate key share
for any group, or send more key shares than groups they support.

Ensure that the key shares must be provided in the same order
as the client preference order specified in supported_groups.

Ensure we only will choose to use a key share that is for the
most preferred group by the client that we also support,
to avoid the client being downgraded by sending a less preferred
key share. If we do not end up with a key share for the most preferred
mutually supported group, will then do a hello retry request
selecting that group.

Add regress for this to regress/tlsext/tlsexttest.c

ok jsing@

show more ...


# 8a1cf7ee 27-Mar-2024 beck <beck@openbsd.org>

Do not allow duplicate groups in supported groups.

While we are here refactor this to single return.

ok jsing@ tb@


# 031ce3c5 26-Mar-2024 beck <beck@openbsd.org>

Add an indicator that an extension has been processed.

ok jsing@


# b7f937c4 26-Mar-2024 beck <beck@openbsd.org>

Process supported groups before key share.

This will allow us to know the client preferences for an upcoming
change to key share processing.

ok jsing@


# e792b603 25-Mar-2024 jsing <jsing@openbsd.org>

Simplify TLS extension parsing and processing.

Rather than having a separate parse and process step for each TLS
extension, do a first pass that parses all of the TLS outer extensions and
retains th

Simplify TLS extension parsing and processing.

Rather than having a separate parse and process step for each TLS
extension, do a first pass that parses all of the TLS outer extensions and
retains the extension data, before running a second pass that calls the TLS
extension processing code.

ok beck@ tb@

show more ...


# b0797933 25-Mar-2024 tb <tb@openbsd.org>

Fix typo msg_types -> msg_type

from jsing


# 3258ebf1 25-Mar-2024 jsing <jsing@openbsd.org>

Split TLS extension parsing from processing.

The TLS extension parsing and processing order is currently dependent on
the order of the extensions in the handshake message. This means that the
proces

Split TLS extension parsing from processing.

The TLS extension parsing and processing order is currently dependent on
the order of the extensions in the handshake message. This means that the
processing order (and callback order) is not under our control. Split the
parsing from the processing such that the processing (and callbacks) are
run in a defined order.

Convert ALPN to the new model - other extensions will be split into
separate parse/process in following diffs.

ok beck@ tb@

show more ...


# 2b2534fd 25-Mar-2024 jsing <jsing@openbsd.org>

Decouple TLS extension table order from tlsext_randomize_build_order()

The PSK extension must be the last extension in the client hello. This is
currently implemented by relying on the fact that it

Decouple TLS extension table order from tlsext_randomize_build_order()

The PSK extension must be the last extension in the client hello. This is
currently implemented by relying on the fact that it is the last extension
in the TLS extension table. Remove this dependency so that we can reorder
the table as needed.

ok tb@

show more ...


# 580585a9 28-Apr-2023 tb <tb@openbsd.org>

Too many stupid things whine about these being used uninitialized
(which they aren't), so appease them.


# 71517d29 27-Apr-2023 tb <tb@openbsd.org>

ssl_tlsext.c: Add an accessor for the tls extension type.

Needed for the tlsexttest.c

ok jsing


# 4250ba74 25-Apr-2023 tb <tb@openbsd.org>

Fix allocation size

Reported by anton


# 2454fc3a 24-Apr-2023 tb <tb@openbsd.org>

Free and calloc() the tlsext_build_order and remember its length

Aligns tlsext_randomize_build_order() with tlsext_linearize_build_order()
and will help regression testing.

ok jsing


# 74b62d9a 24-Apr-2023 tb <tb@openbsd.org>

Use TLSEXT_TYPE_alpn instead of the stupid long one


# f45f5ef6 23-Apr-2023 tb <tb@openbsd.org>

Randomize the order of TLS extensions

On creation of an SSL using SSL_new(), randomize the order in which the
extensions will be sent. There are several constraints: the PSK extension
must always co

Randomize the order of TLS extensions

On creation of an SSL using SSL_new(), randomize the order in which the
extensions will be sent. There are several constraints: the PSK extension
must always come last. The order cannot be randomized on a per-message
basis as the strict interpretation of the standard chosen in the CH hashing
doesn't allow changing the order between first and second ClientHello.

Another constraint is that the current code calls callbacks directly on
parsing an extension, which means that the order callbacks are called
depends on the order in which the peer sent the extensions. This results
in breaking apache-httpd setups using virtual hosts with full ranomization
because virtual hosts don't work if the SNI is unknown at the time the
ALPN callback is called. So for the time being, we ensure that SNI always
precedes ALPN to avoid issues until this issue is fixed.

This is based on an idea by David Benjamin
https://boringssl-review.googlesource.com/c/boringssl/+/48045

Input & ok jsing

show more ...


# c9675a23 26-Nov-2022 tb <tb@openbsd.org>

Make internal header file names consistent

Libcrypto currently has a mess of *_lcl.h, *_locl.h, and *_local.h names
used for internal headers. Move all these headers we inherited from
OpenSSL to *_l

Make internal header file names consistent

Libcrypto currently has a mess of *_lcl.h, *_locl.h, and *_local.h names
used for internal headers. Move all these headers we inherited from
OpenSSL to *_local.h, reserving the name *_internal.h for our own code.
Similarly, move dtls_locl.h and ssl_locl.h to dtls_local and ssl_local.h.
constant_time_locl.h is moved to constant_time.h since it's special.

Adjust all .c files in libcrypto, libssl and regress.

The diff is mechanical with the exception of tls13_quic.c, where
#include <ssl_locl.h> was fixed manually.

discussed with jsing,
no objection bcook

show more ...


# 6f7f653b 02-Oct-2022 jsing <jsing@openbsd.org>

Get rid of SSL_CTX_INTERNAL and SSL_INTERNAL.

These are no longer necessary due to SSL_CTX and SSL now being fully
opaque. Merge SSL_CTX_INTERNAL back into SSL_CTX and SSL_INTERNAL back
into SSL.

P

Get rid of SSL_CTX_INTERNAL and SSL_INTERNAL.

These are no longer necessary due to SSL_CTX and SSL now being fully
opaque. Merge SSL_CTX_INTERNAL back into SSL_CTX and SSL_INTERNAL back
into SSL.

Prompted by tb@

show more ...


1234567