| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This is needed for an upcoming change in libcrypto.
ok tb@
|
|
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
|
|
ENGINE, SSL and SSL_CTX remain even though the structs in the typedefs
don't exist as they are used as incomplete types.
feedback, ports bulk build and ok tb@
|
|
|
|
|
|
feedback and ok tb@
|
|
|
|
This information has been part of tls12_key_block_generate() for a while
now. It remained in this table because at that point SSL_CIPHER was still
public. Nothing can access algorithm2 anymore from the outside, so this is
dead weight.
ok jsing
|
|
|
|
|
|
SSL2_CF_8_BYTE_ENC was set by things such as RC4_64_WITH_MD5, which fell
victim to tedu's axe a decade ago. Zap that.
ok jsing
|
|
The way the CBB API is used, CBB_add_u16() and CBB_finish() can't actually
fail here, but if they could, cbb->base would leak. Rewrite this code with
the proper idioms to make it look right.
ok jsing
|
|
with the help of jmc
|
|
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
|
|
|
|
ok jsing
|
|
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
|
|
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@
|
|
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@
|
|
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@
|
|
While we are here refactor this to single return.
ok jsing@ tb@
|
|
ok jsing
|
|
ok jsing@
|
|
This will allow us to know the client preferences for an upcoming
change to key share processing.
ok jsing@
|
|
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@
|
|
from jsing
|
|
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@
|
|
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@
|
|
same bump as libcrypto; symbol removal and addition
|
|
The garbage truck is quite full by now. Collect the last symbol
straggler for this bump.
ok jsing
|
|
And here goes another weird-ass thing of dubious pedigree.
ok jsing
|
|
And here goes a bunch of unused macros that just had to be in two
headers so they could get out of sync. Three of these constants
are used in a single function...
ok jsing
|
|
While this undocumented API would have been much nicer and saner than
SSL_CIPHER_find(), nothing used this except for the exporter test.
Let's get rid of it again. libssl uses ssl3_get_cipher_by_{id,value}()
directly.
ok jsing
|
|
Also move the prototypes to the correct header.
Oversight reported by Frank Lichtenheld, thanks!
Fixes https://github.com/libressl/openbsd/issues/147
ok jsing
|
|
From Christian Andersen
|
|
If an error occurs in action->recv() for a handshake that needs to
downgrade to legacy TLS, the artistic exit path led to hiding the
error under TLS13_IO_USE_LEGACY. Rework the exit path to be easier
to follow, preserving behavior except that the error can no longer
be masked.
Detailed analysis and initial diff by Masaru Masuda.
Fixes https://github.com/libressl/openbsd/issues/146
ok beck
|
|
This was used for some GOST weirdness. The flag is unused in ports and
there is no user in Debian's codesearch.
ok beck
|
|
|
|
This version of GOST is old and not anywhere close to compliant with
modern GOST standards. It is also very intrusive in libssl and
makes a mess everywhere. Efforts to entice a suitably minded anyone
to care about it have been unsuccessful.
At this point it is probably best to remove this, and if someone
ever showed up who truly needed a working version, it should be
a clean implementation from scratch, and have it use something
closer to the typical API in libcrypto so it would integrate less
painfully here.
This removes it from libssl in preparation for it's removal from
libcrypto with a future major bump
ok tb@
|
|
Change SSL_shutdown() such that it will return 0 after sending a
close-notify, before potentially returning 1 (indicating that a
close-notify has been sent and received) on a subsequent call. Some
software depends on this behaviour, even though there are cases where
the first call could immediately return 1 (for example, when the peer
has already sent a close-notify prior to SSL_shutdown() being called).
ok tb@
|
|
Respect the ssl->shutdown flags rather than what has actually happened,
return -1 for all EOF errors and completely ignore the return value when
attempting to read a close-notify from the wire.
ok tb@
|
|
|
|
This will make it easier to regress test shutdown behaviour in the TLSv1.3
stack. Additionally, `openssl -msg` now shows alerts for TLSv1.3
connections.
ok tb@
|
|
It is now safe to call delete from an lhash doall callback - stop fiddling
wit hash table internals from lhash doall callers that previously has to
workaround this themselves.
ok tb@
|
|
EVP_CIPHER_type() will never return NID_gost89_cnt since it has no
associated ASN1_OBJECT. Switching to EVP_CIPHER_nid() has a slight
chance of working. Do that before beck applies the flensing knife.
ok beck
|
|
Said bug was fixed in OpenSSL 1.0.0, released 14 years ago. It is of course
unsurprising that you may accidentally increment the refcount if your idiom
for decrementing it is CRYPTO_add(&bio-references, -1, CRYPTO_LOCK_BIO)).
|
|
|
|
In order to determine whether GOST is properly enabled, libssl has various
weird dances. In this specific case, it calls EVP_PKEY_meth_find() to see
whether the relevant cipher is around. Check the same thing with an #ifdef
instead.
ok jsing
|
|
In SSL{_CTX}_use_RSAPrivateKey() switch from EVP_PKEY_assign_RSA() to
EVP_PKEY_set1_RSA() and hold on to the reference of the the pkey for
the duration of ssl_set_pkey(). Use single exit and other minor style
cleanups.
ok joshua jsing
|
