| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
EVP_Digest() can fail, so handle failure appropriately and prepare
switch of session_id_length to a size_t.
ok jsing
|
|
|
|
|
|
| |
respectively
ok jsing
|
|
|
|
|
|
| |
redundant parentheses.
ok jsing
|
|
|
|
|
|
|
| |
is deliberately reduced to an unsigned int. Since the session_id is at
most 32 bytes, this is not a concern.
ok jsing
|
| |
|
|
|
|
| |
ok jsing (who informs me he had the same diff in his jungle)
|
|
|
|
| |
ok jsing
|
|
|
|
|
|
|
| |
Now that master_key_length is a size_t, we no longer have to fiddle with
data_len. We can rather pass a pointer to it to CBS_write_bytes().
ok jsing
|
|
|
|
| |
ok jsing
|
|
|
|
| |
ok jsing
|
|
|
|
|
|
|
|
|
|
|
| |
Failure of this undocumented callback was previously silently ignored.
Follow OpenSSL's behavior and throw an internal error (for lack of a
better choice) if the callback failed or if it set the master_key_length
to a negative number.
Unindent the success path and clean up some strange idioms.
ok jsing
|
|
|
|
|
|
| |
SSLv2 remnants.
ok jsing
|
|
|
|
| |
ok jsing
|
|
|
|
|
|
|
| |
Wrap long lines and fix a bug where the wrong struct member was checked
for NULL.
ok jsing
|
|
|
|
|
| |
Apparently 60 * 5 + 4 seconds is 5 minutes. Presumably this is the case
with sufficiently potent crack, which would explain a few things in here.
|
|
|
|
|
| |
The fallback to SHA-1 if SHA-256 is disabled fell victim to tedu many
moons ago when this file was still called s3_clnt.c and had no RCS ID.
|
| |
|
|
|
|
|
|
| |
Found by anton with tlsfuzzer
ok anton
|
| |
|
|
|
|
| |
ok jsing
|
|
|
|
| |
ok jsing
|
|
|
|
|
|
|
| |
This will be used to indicate client side support for DHE key
establishment.
ok jsing
|
|
|
|
|
|
| |
key exchange mode extension, as required by RFC 8446, 4.2.9.
ok jsing
|
|
|
|
| |
ok jsing
|
|
|
|
|
|
|
|
|
| |
The handshake state machine does not handle key updates since that's a
post-handshake handshake message. This is code under #ifdef TLS13_DEBUG
and if it is ever to be reused in tls13_handshake_msg.c, that will have
to be revisited.
ok inoguchi jsing
|
|
|
|
|
|
|
| |
jmc@ dislikes a comma before "then" in a conditional, so leave those
untouched.
ok jmc@
|
|
|
|
| |
ok jmc@ schwarze@
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Now that {dtls1,ssl3}_read_bytes() have been refactored, do a clean up
pass - this cleans up various parts of the code and reduces differences
between these two functions.
ok = 1; *(&(ok)) tb@
ok inoguchi@
|
|
|
|
|
|
|
|
| |
The code that handles each record type already has appropriate length
checks. Furthermore, the handling of application data here is likely
incorrect and bypasses the normal state checks at the end of this function.
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
|
| |
The asn1test depends on asn1_mac.h which had a date with the bitbucket a
few years back (and the test "isn't meant to run particularly, it's just
to test type checking"). methtest.c tests an API that was never present
in OpenSSL's git history. r160test.c is nothing but a licence.
"nuke away" jsing
|
|
|
|
| |
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
|
| |
Rewrite the code that handles unexpected handshake messages in the legacy
DTLS stack. Parse the DTLS message header up front, then process it based
on the message type. Overall the code should be more strict and we should
reject various invalid messages that would have previously been accepted.
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rewrite the code that handles unexpected handshake messages in the legacy
TLS stack. Parse the TLS message header up front, then process it based on
the message type. Overall the code should be more strict and we should
reject various invalid messages that would have previously been accepted.
I also reviewed steve's experimental code and fixed the bug that it
contained.
ok inoguchi@ tb@
|
|
|
|
| |
ok inoguchi@ tb@
|
|
|
|
|
|
|
| |
This function populates the passed *out argument, hence it should not be
marked const.
ok tb@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The TLS record layer has to be able to handle unexpected handshake messages
that result when it has been asked to read application data. The way that
this is currently done in the legacy stack is a layering violation - the
record layer knows about DTLS/TLS handshake messages, parsing them and then
deciding what action to take. This is further complicated by the need to
handle handshake message fragments.
For now, factor this code out with minimal changes - since it is a layering
violation we have to retain separate code for DTLS and TLS.
ok beck@ inoguchi@ tb@
|
|
|
|
|
|
|
|
| |
Factor out the code that handles the processing of a change cipher spec
message that has been read in the legacy stack, deduplicating code in the
DTLS stack.
ok inoguchi@ tb@
|
|
|
|
| |
OK tb@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pull out the code that processes incoming alerts - a chunk of the
complexity is due to the fact that in TLSv1.2 and earlier, alerts can be
fragmented across multiple records or multiple alerts can be delivered
in a single record.
In DTLS there is no way that we can reassemble fragmented alerts (although
the RFC is silent on this), however we could have multiple alerts in the
same record. This change means that we will handle this situation more
appropriately and if we encounter a fragmented alert we will now treat this
as a decode error (instead of silently ignoring it).
ok beck@ tb@
|
|
|
|
|
|
|
|
| |
person. Rewrite or use singular they.
ok thfr@ sthen@ daniel@ ian@ job@ kmos@ jcs@ ratchov@ phessler@ and
others I'm likely missing on an earlier version.
feedback tj@, feedback and ok jmc@
|
|
|
|
|
|
|
|
|
|
|
| |
In order for SSL_get_error() to work with SSL_read_ex() and SSL_write_ex()
the error handling needs to be performed without checking i <= 0. This is
effectively part of OpenSSL 8051ab2b6f8 and should bring the behaviour of
SSL_get_error() largely inline with OpenSSL 1.1.
Issue reported by Johannes Nixdorf.
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the legaacy stack, it is possible to do a zero byte SSL_read() or
SSL_write() that triggers the handshake, but then returns zero without
SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE being flagged. This currently
works in the TLSv1.3 stack by returning TLS_IO_WANT_POLLIN or
TLS_IO_WANT_POLLOUT, which is then hidden by SSL_get_error().
However, due to upcoming changes to SSL_get_error() this will no longer be
the case. In order to maintain the existing legacy behaviour, explicitly
handle zero byte reads and writes in the TLSv1.3 stack, following
completion of a handshake.
ok inoguchi@ tb@
|
|
|
|
| |
ok jmc@ sthen@ millert@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OpenSSL chose to break the previous naming convention for ciphers and
to adopt TLS_* "RFC" names instead. Unfortunately, these names are
exposed in several APIs and some language bindings test for these
non-standard names instead of cipher values, which is ... unfortunate
(others would say "plain crazy").
We currently have to maintain patches in regress and ports (p5-Net-SSLeay,
openssl-ruby-tests - which means that Ruby will pick this up at some point)
to work around this difference and that's just not worth the effort.
The old AEAD- names will become aliases and continue to work, but in
openssl ciphers and netcat output the TLS_* names will now be displayed.
"I would be very happy if this gets committed" bluhm
ok beck inoguchi, begrudgingly ok jsing
|
|
|
|
|
|
|
|
| |
S3I has served us well, however now that libssl is fully opaque it is time
to say goodbye. Aside from removing the calloc/free/memset, the rest is
mechanical sed.
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LibreSSL's pc files effectively hardcode the version to 1.0.0 since
LibreSSL exists. That probably never made much sense. This causes
some pain for ports that "need 'openssl' ['>= +1.1.0'] found '1.0.0'"
or similar while they would build perfectly fine with LibreSSL.
This only affects OpenBSD. We do not put the actual LibreSSL version
in there since it may cause trouble
Discussed with sthen, millert, inoguchi, beck over the past year.
Diff from/ok sthen
|
|
|
|
|
|
|
|
| |
Remove the X509 argument as it is unused - this was passed so that
ssl_cert_type() can get the public key from the X509 object if the
EVP_PKEY argument is NULL, however this is never the case.
ok tb@
|
|
|
|
|
|
| |
CID 118976 118979
ok tb@
|
|
|
|
|
|
| |
CID 24838
comment and ok tb@
|