summaryrefslogtreecommitdiff
path: root/src (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Propagate record overflows to the record layer and alert.jsing2020-05-113-6/+8
| | | | ok beck@ tb@
* Add record version checks.jsing2020-05-113-18/+28
| | | | | | | | When legacy version is below TLSv1.2 ensure that the record version is SSL3/TLS, however when the legacy version is set to TLSv1.2 require this specifically. ok beck@ tb@
* Set the record layer legacy version from the TLSv1.3 server.jsing2020-05-111-1/+5
| | | | | | This will be used to handle record version checks. ok tb@
* Provide an alert sent record layer callback.jsing2020-05-114-8/+29
| | | | | | | | Use this to push an error on to the SSL error stack so that we report the details of the alert that we sent, rather than failing with an unknown error. ok tb@
* Move the record layer callbacks into a struct.jsing2020-05-113-35/+33
| | | | | | | | This makes the code more readable, requires less code churn when adding a new callback and is likely to avoid bugs due to function argument ordering. ok beck@ inoguchi@ tb@
* Use ssl_get_new_session() in the TLSv1.3 server.jsing2020-05-111-4/+3
| | | | | | | | This correctly handles session being non-NULL and sets up a few more things, including ssl_version. Also stop setting the ssl_version to the server_version, as this is only used on the client side. ok tb@
* Make openssl X509 handle the failure case return code from X509_time_cmp.beck2020-05-101-5/+16
| | | | | | While we are in here also make it notice if time values in a certificate are bogus, and say so in the output. ok bcook@ jsing@
* Send dummy ChangeCipherSpec messages from the TLSv1.3 servertb2020-05-103-3/+41
| | | | | | | | | | | | | | | If the client has requested middle box compatibility mode by sending a non-empty legacy_session_id, the server must send a dummy CCS right after its first handshake message. This means right after ServerHello or HelloRetryRequest. Two important improvements over the backed-out diffr: make sure that First: client and server can send their dummy CCS at the correct moment (right before the next flight or right after the current flight). Second: as jsing noted, we also need to deal with the corner case that tls13_send_dummy_ccs() can return TLS13_IO_WANT_POLLOUT. with/ok jsing
* Honour SSL_VERIFY_FAIL_IF_NO_PEER_CERT in the TLSv1.3 server.jsing2020-05-103-8/+16
| | | | ok beck@
* Provide alert defines for TLSv1.3 and use in the TLSv1.3 code.jsing2020-05-107-65/+97
| | | | | | | | Rather than using a mess of SSL_AL_*, SSL_AD_*, SSL3_AD_* and TLS1_AD_* defines, provide our own TLS13_ALERT_* defines and use those. This also provides the alerts that are new to TLSv1.3. ok beck@
* Conditionalize sleep-before-retry in server code to only be done whenbeck2020-05-101-3/+5
| | | | | | | debug is on. otherwise, just retry. Fixes problems this creates in testing. ok jsing@ tb@
* Provide an easy way to get debug information from TLSv1.3 handshakes.jsing2020-05-102-3/+61
| | | | | | This makes it easier to debug TLSv1.3 handshake failures. "Yes please!" tb@, ok beck@
* Use size_t for OCSP response length.jsing2020-05-108-27/+35
| | | | | | | | | The OCSP response length is currently an integer, which is overloaded with -1 meaning "unset". Use a size_t for the OCSP response length and infer unset from the OCSP response being NULL. This makes code more readable, simpler and less error prone. ok beck@
* Only reset TLS extension state when parsing client hello or server hello.jsing2020-05-101-5/+7
| | | | | | | | With TLSv1.3 we end up parsing extensions from more than just these two messages. This can result in variables (like the selected alpn) being freed when things still need them. ok tb@
* Correct tlsext_ocsp_resplen check.jsing2020-05-101-2/+2
| | | | | | | This variable is currently overloaded - a value of -1 means that it is "unset" and any other value is a length. ok tb@
* Back out server side CCS sending. It breaks TLSv1.3 client communicationtb2020-05-093-34/+3
| | | | | | | | with TLSv1.2 servers, since it makes clients send their dummy CCS too early... There's an obvious but dirty bandaid which I can't bring myself to applying - this business is already disgusting enough. Issue found the hard way by sthen
* Forcibly ensure that only PSS may be used with RSA in TLS 1.3.beck2020-05-091-2/+8
| | | | | | | This prevents us from incorrectly choosing a PKCS1 based signature if the client advertises support for them but also prefers them to PSS such as appears to be the case with gnuTLS. ok jsing@
* Send dummy ChangeCipherSpec messages from the TLSv1.3 servertb2020-05-093-3/+34
| | | | | | | | | If the client has requested middle box compatibility mode by sending a non-empty legacy_session_id, the server must send a dummy CCS right after its first handshake message. This means right after ServerHello or HelloRetryRequest. ok jsing
* Send dummy ChangeCipherSpec messages from the TLSv1.3 client.jsing2020-05-094-6/+45
| | | | | | | | When operating in middlebox compatibility mode, the TLSv1.3 client needs to send a dummy ChangeCipherSpec message immediately before its second flight of handshake messages (when early data is not offered). ok tb@
* Correct return value check to handle TLS13_IO_EOF case.jsing2020-05-091-2/+2
|
* Add a middlebox_compat flag and condition session ID randomisation on it.jsing2020-05-093-4/+7
| | | | ok tb@
* catch the other place this needs to changebeck2020-05-091-2/+2
|
* now that 3.1.1 is out the door as a stable release bump the developmentbeck2020-05-091-2/+2
| | | | version to 3.2.0
* Add support for certificate status requests in TLS 1.3 clientbeck2020-05-094-12/+81
| | | | ok jsing@, tb@, inoguchi@
* Make the test for the legacy_compression_method vector in the ClientHellotb2020-05-091-12/+7
| | | | | | | | stricter. Previously, we would accept any vector if it advertised the "null" compression method. RFC 8446 4.1.2 specifies that the only legal vector has length one and contains a zero byte for the null method. ok jsing
* Drop a redundant test. It's effectively doing the same test twicetb2020-05-091-3/+2
| | | | | | | and if the two lengths differed, the later CBS_write_bytes() would correctly fail anyway. Discussed with jsing
* On receiving an overlong session ID terminate with an illegal_parametertb2020-05-091-1/+6
| | | | | | alert. Found with tlsfuzzer. ok jsing
* Add support for HelloRetryRequests in the TLSv1.3 server.jsing2020-05-092-10/+73
| | | | ok inoguchi@ tb@
* crazy whitespace on one linetb2020-05-091-2/+2
|
* Pull the sending of alerts up into tls13_handshake_perform().jsing2020-05-091-14/+11
| | | | | | | | | | This fixes the case where a send function signals that an alert should be sent, then returns failure. Previously the failure would be propagated up, without the alert being sent. Issued noted by tb@ ok tb@
* Refactor tls13_server_hello_sent().jsing2020-05-091-30/+36
| | | | | | | | | Split the record protection engagement code into a separate tls13_server_engage_record_protection() function and call this from tls13_server_hello_sent(). Also move some functions around to keep the logical ordering/grouping. ok inoguchi@ tb@ (as part of a larger diff)
* On receiving a handshake or alert record with empty inner plaintext,tb2020-05-071-1/+11
| | | | | | | | | terminate the connection with an unexpected_message alert. See RFC 8446 section 5.4. Found with tlsfuzzer hint/ok jsing
* Bump LibreSSL version to 3.1.1tb2020-05-061-3/+3
| | | | ok bcook inoguchi deraadt
* Use a larger (2048 bit) RSA test key.jsing2020-05-041-1/+63
| | | | Otherwise we fail to do PSS signatures since the key size is too small.
* Fix out-of-bounds access in tables[][] that was exposed in bluhm'stb2020-05-041-6/+8
| | | | | | regress on i386 after inoguchi moved some symbols to const. ok inoguchi jsing deraadt
* Accept two ChangeCipherSpec messages during a TLSv1.3 handshake.jsing2020-05-031-3/+3
| | | | | | | | | | | | | | | | | | | | | In compatibility mode, a TLSv1.3 server MUST send a dummy CCS message immediately after its first handshake message. This is normally after the ServerHello message, but it can be after the HelloRetryRequest message. As such we accept one CCS message from the server during the handshake. However, it turns out that in the HelloRetryRequest case, Facebook's fizz TLSv1.3 stack sends CCS messages after both the HelloRetryRequest message and the ServerHello message. This is unexpected and as far as I'm aware, no other TLSv1.3 implementation does this. Unfortunately the RFC is rather ambiguous here, which probably means it is not strictly an RFC violation. Relax the CCS message handling to allow two dummy CCS messages during a TLSv1.3. This makes our TLSv1.3 client work with Facebook Fizz when HRR is triggered. Issue discovered by inoguchi@ and investigated by tb@. ok deraadt@ tb@
* Add const to TLS1.3 internal vectorsinoguchi2020-05-022-14/+14
| | | | ok tb@
* Disallow setting the AES-GCM IV length to 0tb2020-04-301-1/+5
| | | | | | | It is possible to do this by abusing the EVP_CTRL_INIT API. Pointed out by jsing. ok inoguchi jsing (as part of a larger diff)
* tls13_record_layer internal functions to static in libsslinoguchi2020-04-291-4/+4
| | | | | | | We might remove static again for further regress around record layer in the future. ok jsing@ tb@
* tls13_handshake internal functions to static in libsslinoguchi2020-04-291-11/+12
| | | | ok jsing@ tb@
* Move legacy stack interfacing functions into tls13_legacy.c.jsing2020-04-284-199/+206
| | | | | | No functional change. ok inoguchi@ tb@
* Rename tls13_client_synthetic_handshake_message() and move to tls13_lib.c.jsing2020-04-283-47/+48
| | | | | | | | The server-side will need to use the same function. No functional change. ok inoguchi@ tb@
* Shuffle some functions around.jsing2020-04-272-329/+328
| | | | | | | | | | Move functions so that they are in the order that the TLSv1.3 messages are processed. While here, also move tls13_client_end_of_early_data_send() from tls13_client.c to tls13_server.c. No functional change. ok beck@ tb@
* Fix two bugs in the AES-CBC-PKCS5 tests that didn't hide failing tests:tb2020-04-271-3/+3
| | | | | 1. Use the correct slice for comparing the cipher output 2. Fix logic error similar to the one in AES-GCM in the previous commit
* Fix a logic error that hid the failing ZeroLengthIv tests.tb2020-04-271-3/+3
| | | | This issue was fixed in lib/libcrypto/evp/e_aes.c r1.40.
* Disallow the use of zero length IVs in AES-GCM viatb2020-04-273-3/+15
| | | | | | | | | | | EVP_AEAD_CTX_{open,seal}, as this leaks the authentication key. Issue reported and fix tested by Guido Vranken. ok beck, jsing This commit adds a constant to a public header despite library lock, as discussed with deraadt and sthen.
* Minimal maintenance to make this mess slightly less confusing:schwarze2020-04-261-10/+10
| | | | | | | queue -> list; mention "intrusive"; element -> member at one place; delete a bogus remark that maybe referred to a long-gone implementation in VAX assembly code. Much more could be improved, but i don't want to waste too much time here.
* fix the description; from andras farkasjmc2020-04-261-5/+4
| | | | | | ok schwarze kill a Tn while here...
* Display TLSv1.3 extension type with openssl(1) -tlsextdebuginoguchi2020-04-261-7/+49
| | | | | | | | Add TLSv1.3 extension type, and sort by the definition order in tls1.h. This helps that openssl(1) s_server and s_client with -tlsextdebug displays the TLS extension type instead of "unknown". ok beck@ jsing@ tb@
* s_client: fix use of possibly uninitialized valuesinoguchi2020-04-261-2/+2
| | | | | | | | | | Set initial value to variable 'p' and 'pending'. Reported and fix requested from leonklingele by GitHub pull request. https://github.com/libressl-portable/portable/issues/577 https://github.com/libressl-portable/openbsd/pull/114 ok bcook@ jsing@ tb@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-25 06:08:44 +0000