| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This does the following:
1) Adds a second key share prediction to the TLS 1.3 handshake.
We only add one as we are unlikely to want to send more than
one PQ one, and one classical one and are unlikely to waste
bytes on a second PQ algorithm (anything that wants something
else that we support can HRR to get it)
2) Adds X25519MLKEM768 (4588) to our list of supported groups.
We add this to our preferred client and server key shares for TLS 1.3
and we now have a separate list for TLS 1.2 which does not do this,
cleaning up the old "full list" from the comments.
3) Updates the golden magic numbers in the regression tests to allow
for the above two things changing the handshake, so the regress
tests pass.
With this you can successfully hybrid PQ with servers and clients
that support it.
ok tb@ kenjiro@
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This implements the currently in use MLKEM768_X25519 hybrid
key share as outlined in
https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/
This commit does not yet wire this up to anything, that is done
in follow on changes.
ok tb@ jsing@ kenjiro@
|
| |
|
|
|
|
|
|
| |
There's no need to pass in the hrr parameter as it is redundant with
the tls13.hrr flag. This avoids boolean blindness in the caller and
removes a leftover from before we had tls13.hrr.
ok jsing kenjiro
|
| | |
|
| | |
|
| |
|
|
| |
ok kenjiro
|
| |
|
|
|
|
|
| |
As reported by ajacoutot and sthen, an update to net/neon is blocked on
that missing symbol.
ok kenjiro
|
| |
|
|
|
|
|
|
|
| |
This allows a const correct SSL_SESSION_dup() implementation at the cost
of casting away const due to the const incorrect CRYPTO_dup_ex_data()...
(I should look into fixing that, but things like rust-openssl make that
hard at this point in the release cycle.)
ok kenjiro (as part of a larger diff)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When processing the client supported groups and key shares extensions,
the group selection is currently based on client preference. However,
when building a HRR the preferred group is identified by calling
tls1_get_supported_group(). If SSL_OP_CIPHER_SERVER_PREFERENCE is enabled,
group selection will be based on server instead of client preference. This
in turn can result in the server sending a HRR for a group that the client
has already provided a key share for, violating the RFC.
Avoid this issue by storing the client preferred group when processing
the key share extension, then using this group when creating the HRR.
Thanks to dzwdz for identifying and reporting the issue.
ok beck@ tb@
|
| | |
|
| |
|
|
| |
Removes another patch in portable
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adapt the tests to use this API.
This does not yet make the symbols public in Symbols.list
which will happen shortly with a bump.
This includes some partial rototilling of the non-public
interfaces which will be shortly continued when the internal
code is deduplicated to not have multiple copies for ML-KEM
768 and ML-KEM 1024 (which is just an artifact of unravelling
the boring C++ code).
ok jsing@, tb@
|
| | |
|
| |
|
|
|
|
|
| |
10% of our manual pages using this macro employed useless quoting anyway.
Remove these quotes such that they do not incite fear, uncertainty,
and doubt in developers who happen to look at these pages.
jmc@ and tb@ agree with the direction.
|
| |
|
|
|
| |
reported by smatch via jsg
ok beck
|
| | |
|
| |
|
|
|
| |
that no longer exists, and add .Lb libssl libcrypto;
OK tb@
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Switch argument order and use sizeof(*ctx) rather than sizeof(struct ...).
ok jsg
|
| |
|
|
| |
ok jsg
|
| |
|
|
| |
found with smatch, ok tb@
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
SSL_alert_desc_string() is only used by our good old friends M2Crypto
and Net::SSLeay. While some of the two-letter combinations can be made
sense of without looking at the switch, I guess, this is just a
completely useless interface. The same level of uselessness can be
acchieved in a single line matching BoringSSL.
ok joshua kenjiro
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is a precursor to adding new group ids for post quantum
stuff which are up in the 4000 range, so using the array index
as the group id will be silly. Instead we just add the group
id to the structure and we walk the list to find it.
This should never be a very large list for us, so no need
to do anything cuter than linear search for now.
ok jsing@, joshua@
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Makes upcoming changes in regress less ugly.
|
| |
|
|
|
|
|
|
|
|
|
| |
All supported releases of LibreSSL ensure that the corresponding callbacks
are called in a predefined order rather than honoring the order in which a
client sends its extensions. Therefore the ALPN callback for apache-httpd's
virtual host setups can rely on SNI information being available and we no
longer need to work around this on hte client side. Cuts the amount of code
needed for tlsext randomization in half.
ok jsing
|
| | |
|
| |
|
|
| |
ok jsing
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
code #ifdef'ing these and compiled with new headers won't work as expected on
earlier libraries
minor libtls bump to match libssl bump
ok tb@
|
| |
|
|
| |
ok miod
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In January 2017 we added SSL_OP_NO_CLIENT_RENEGOTIATION, which results in a
SSL_AD_NO_RENEGOTIATION fatal alert if a ClientHello message is seen on an
active connection (client initiated renegotation). Then in May 2017 OpenSSL
added SSL_OP_NO_RENEGOTIATION, which results in a SSL_AD_NO_RENEGOTIATION
warning alert if a server receives a ClientHello on an active connection
(client initiated renegotation), or a client receives a HelloRequest
(server requested renegotation). This option also causes calls to
SSL_renegotiate() and SSL_renegotiate_abbreviated() to fail. Then in 2021,
OpenSSL also added SSL_OP_ALLOW_CLIENT_RENEGOTIATION, which trumps
SSL_OP_NO_RENEGOTIATION but only for incoming ClientHello messages
(apparently unsetting SSL_OP_NO_RENEGOTIATION is too hard).
Provide SSL_OP_NO_RENEGOTIATION and SSL_OP_ALLOW_CLIENT_RENEGOTIATION,
primarily to make life easier for ports. If SSL_OP_NO_CLIENT_RENEGOTIATION
is set it will take precedence and render SSL_OP_ALLOW_CLIENT_RENEGOTIATION
ineffective. The rest of the behaviour should match OpenSSL, with the
exception of ClientHellos triggering fatal alerts instead of warnings.
ok tb@
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Various ports throw a warning since their tls_session_secret_cb's
signature doesn't match what we expect. Aligns us with OpenSSL 1.1.
This is only useful for RFC 4851 EAP-FAST implementations and
surprisingly it's undocumented.
ok jsing
|
| |
|
|
|
|
|
|
|
|
| |
Some people are concerned that leaking a user name is a privacy issue.
Allow disabling the __FILE__ and __LINE__ argument in the error stack
to avoid this. This can be improved a bit in tree.
From Viktor Szakats in https://github.com/libressl/portable/issues/761
ok bcook jsing
|
| | |
|
| |
|
|
|
|
|
| |
It doesn't need to have optional arguments anymore, so we can pass
in values and don't need NULL checks and dereferencing.
ok jsing
|
| | |
|
| |
|
|
| |
ok cc + sha256
|