| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
with the OID for SM2 signing with SM3.
From Daniel Wyatt
|
|
|
|
|
|
|
| |
In non-SSL_MODE_ENABLE_PARTIAL_WRITE mode we have to write out all the
things and only return success once all of the data has been sent.
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the TLS handshake has not been completed, automatically complete the
handshake as part of the read/write call, implementing the current
SSL_read()/SSL_write() behaviour.
Once the TLS handshake is completed we push a WANT_POLLIN or WANT_POLLOUT
back up to the caller, since some applications appear to incorrectly call
SSL_read() or SSL_write(), rather than repeating the previous call. This
can lead to attempts to read data that does not exist, since the
WANT_POLLIN was actually triggered as part of the handshake.
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
| |
Set the SSL state to SSL_ST_CONNECT during the TLSv1.3 handshake and to
SSL_ST_OK once the handshake completes, since some applications currently
rely on this information to function correctly.
ok inoguchi@ tb@
|
|
|
|
| |
ok inoguchi@ tb@
|
|
|
|
| |
ok tb@
|
|
|
|
|
|
|
|
|
| |
In the close notify case we need to signal EOF and in the user cancelled
case we need to return WANT_POLLIN. Returning success results in
tls13_record_layer_read_record() thinking that we have record data when
we do not, which then results in the content type check later failing.
ok tb@
|
|
|
|
| |
ok tb@
|
|
|
|
|
|
|
| |
Otherwise a TLS error (for example the remote end sent a fatal alert) is
silently ignored.
ok bluhm@ tb@
|
|
|
|
|
|
| |
repeated typedef. Found the hard way by aoyama who also tested the fix.
ok jsing
|
|
|
|
|
|
| |
SSL_HANDSHAKE_TLS13 back to ssl_locl.h.
discussed with jsing and inoguchi
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the record layer is asked to write more than fits in a plaintext record,
cap the amount at that limit. This means that we will effectively write out
a single record and return a short-write.
This behaviour matches SSL_write() with SSL_MODE_ENABLE_PARTIAL_WRITE
enabled and the non-SSL_MODE_ENABLE_PARTIAL_WRITE case will be handled
at a higher layer.
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
|
|
| |
The write traffic key needs to be changed to the client application traffic
key after the client finished message has been sent. The send handler
generates the client finished message, however we cannot switch keys at
this stage since the client finished message has not yet been protected
by the record layer.
ok tb@
|
| |
|
|
|
|
|
|
| |
This solves build error on luna88k with gcc3.
ok aoyama@ jca@ jsing@ tb@
|
|
|
|
|
|
|
|
|
| |
In the case of a dummy CCS or post-handshake handshake message, return
TLS13_WANT_POLLIN rather than using a goto internally. This allows the
caller to retry at an appropriate time and reduces the complexity within
the record layer.
ok beck@ tb@
|
|
|
|
|
|
|
|
|
|
|
| |
In most cases a TLS13_IO_WANT_POLLIN or TLS13_IO_WANT_POLLOUT will have
bubbled up from the wire callbacks, in which case the BIO retry flag will
already be set. However, if we return TLS13_IO_WANT_POLLIN or
TLS13_IO_WANT_POLLOUT from a higher layer the BIO retry flag will not be
set and that will cause SSL_get_error() to return SSL_ERROR_SYSCALL rather
than the intended SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE.
ok beck@ tb@
|
|
|
|
|
|
| |
connections between client and server implemented with LibreSSL or
OpenSSL with a fixed cipher on each side. Check the used cipher
in the session print out.
|
|
|
|
|
|
|
|
|
| |
In TLSv1.3 there are two types of alerts "closure alerts" and
"error alerts". This makes the record layer more strict and handles closure
of the read and write channels. The callback then handles the record layer to
SSL mapping/behaviour.
ok tb@
|
|
|
|
|
|
|
|
| |
There is nothing for the handler to really signal, since it cannot change
the fact that we received an alert. While here use TLS13_IO_FAILURE instead
of hardcoding -1.
ok tb@
|
| |
|
|
|
|
| |
ok jsing@ tb@
|
| |
|
| |
|
|
|
|
| |
ok tb@
|
|
|
|
|
|
|
|
|
| |
Switch the read traffic key to the server application traffic key once
the server finished message has been processed. Switch the write traffic
key to the client application traffic key after sending the client
finished message.
ok tb@
|
|
|
|
|
|
|
|
|
| |
This allows the read traffic key to be set independently of the write
traffic key. This will become necessary for KeyUpdate handling, however
also allows for switching to application traffic keys at more appropriate
stages of the handshake.
ok tb@
|
|
|
|
| |
ok tb@
|
| |
|
| |
|
|
|
|
|
|
|
| |
This adds support for processing of the server finished message and
generation of the client finished message.
ok tb@
|
|
|
|
|
|
|
|
|
| |
This implementation reduces contention because threads no longer need
to spin calling sched_yield(2) before going to sleep.
Tested by many, thanks!
ok visa@, pirofti@
|
| |
|
|
|
|
|
|
|
| |
This allows the TLS 1.3 client to process the certificates that the server
has sent and verify that the server has possession of the private key.
ok tb@
|
|
|
|
| |
sign error during arm regress.
|
|
|
|
|
|
|
| |
instead
From Pamela Mosiejczuk, many thanks!
OK phessler@ deraadt@
|
|
|
|
|
|
|
|
|
| |
There are various points where we need the hash of all messages prior to
the current message. Support this by having the handshake code preserve
the transcript hash prior to recording the current message, which avoids
the need to sprinkle this throughout multiple handlers.
ok inoguchi@ tb@
|
|
|
|
| |
ok jsing@ tb@
|
|
|
|
| |
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
|
| |
While handshake hash is correct (in as far as it is a hash of handshake
messages), using tls1_transcript_hash*() aligns them with the naming of the
tls1_transcript*() functions. Additionally, the TLSv1.3 specification uses
Transcript-Hash and "transcript hash", which this matches.
ok inoguchi@ tb@
|
|
|
|
|
|
|
| |
This allows ctx->hs to be used throughout the TLSv1.3 code, rather than
S3I(ctx->ssl)->hs_tls13.
ok inoguchi@ tb@
|
|
|
|
| |
ok tb@ jsing@
|
|
|
|
| |
ok bcook@ tb@
|
|
|
|
|
| |
suggested by jsing@
ok tb@
|
|
|
|
| |
ok jsing@
|
|
|
|
| |
ok tb@
|
|
|
|
| |
ok tb@
|
|
|
|
| |
ok jsing, "looks good!" jmc
|
| |
|
|
|
|
| |
ok beck@ inoguchi@ tb@
|