summaryrefslogtreecommitdiff
path: root/src/lib/libssl (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Move the read MAC key into the TLSv1.2 record layer.jsing2021-01-074-23/+20
| | | | ok inoguchi@ tb@
* Use tls13_secret_{init,cleanup}() for the finished_keytb2021-01-062-10/+10
| | | | | | | | This trades an array on the stack for a dynamically allocated secret in tls13_{client,server}_finished_send() but has the benefit of wiping out an intermediate secret on function exit. ok jsing
* Avoid local variable in tls13_secret_init().tb2021-01-051-6/+2
| | | | suggested by jsing
* Convert tls13_record_layer.c to tls13_secret_{init,cleanup}()tb2021-01-051-21/+11
| | | | ok jsing
* Convert tls13_exporter() to tls13_secret_{init,cleanup}()tb2021-01-051-8/+5
| | | | ok jsing
* Use KNF for licence commenttb2021-01-051-2/+3
| | | | ok jsing
* Move tls13_secrets_destroy() below _create()tb2021-01-051-29/+29
| | | | ok jsing
* Convert tls13_secrets_{create,destroy}() to tls13_secret_{init,cleanup}()tb2021-01-051-71/+34
| | | | ok jsing
* Add tls13_secret_{init,cleanup}()tb2021-01-052-2/+29
| | | | | | | | These are two functions that will help streamlining various functions in the TLSv1.3 code that do not need to know about the interna of this struct. input/ok jsing
* Use consistent names in tls13_{client,server}_finished_{recv,send}().jsing2021-01-052-12/+12
| | | | | | | | | In tls13_{client,server}_finished_recv() we use verify_data_len, which makes more sense than hmac_len. Use the same name in tls13_{client,server}_finished_send(), keeping things consistent between functions. ok tb@
* Use legacy verifier when building auto chains.jsing2021-01-052-2/+6
| | | | | | | | | | | | | | | | | | The new verifier builds all chains, starting with the shortest possible path. It also does not currently return partial chains. Both of these things conflict with auto chain, where we want to build the longest possible chain (to include all intermediates, and probably the root unnecessarily), as well as using an incomplete chain when a trusted chain is not known. Depending on software configuration, we can end up building a chain consisting only of a leaf certificate, rather than a longer chain. This results in auto chain not including intermediates, which is undesireable. For now, switch auto chain building to use the legacy verifier. This should resolve the issues encountered by ajacoutot@ with sendmail. ok tb@
* whitespacetb2021-01-043-10/+10
|
* Keep the various free calls of tls13_record_layer_free() in thetb2021-01-041-4/+4
| | | | | | order of the struct members for reviewability. ok jsing
* Free {alert,phh}_data in tls13_record_layer_free()tb2021-01-021-1/+4
| | | | | | | | | | | | | | httpd(8)'s incorrect tls_close() after closing the underlying socket led to a leak: tls_close()'s attempt to send out the close_notify won't work very well over a closed pipe. This resulted in alert_data still hanging off the TLSv1.3 context's record layer struct. The tls_free() call should have cleaned this up but failed to do so. The record layer's phh_data potentially has the same issue, so free it as well. This diff makes -current httpd(8) run in constant memory over hundreds of thousands TLS connections with a static site. ok inoguchi jsing
* Use natural sizes for S3I(s)->tmp's *_md arraystb2020-12-151-6/+4
| | | | | | | | | | | | | | | | | | | | It is a historical artifact that cert_verify_md[], finish_md[] and peer_finish_md[] are twice as large as they need to be. This is confusing, especially for finish_md[] and peer_finish_md[] which are copied to to previous_client_finished[] and previous_server_finished[] which are only half as large. It is easy to check that they will never get more than EVP_MAX_MD_SIZE data written to them. In 1998, EVP_MAX_MD_SIZE was 20 bytes long (for SHA-1). This got bumped to 16+20 for the SSLv3-specific md5+sha1. Apparently under the impression that EVP_MAX_MD_SIZE was still 20 bytes, someone else doubled finish_md[]'s size to EVP_MAX_MD_SIZE*2 and added /* actually only needs to be 16+20 */. A bit later finish_md[] was split up, and still a bit later the comment was amended for TLSv1. Shortly thereafter SHA-512 required a bump of EVP_MAX_MD_SIZE to 64 by a third person and we have been carrying 192 bytes of untouched memory in each of our SSLs ever since. ok inoguchi jsing (jsing had the same diff)
* Fix SSL_get{,_peer}_finished() with TLSv1.3tb2020-12-142-2/+28
| | | | | | | | | | As reported by Steffen Ullrich and bluhm, the Finished tests in p5-Net-SSLeay's t/local/43_misc_functions.t broke with with TLSv1.3. The reason for this is that we don't copy the MDs over to the SSL, so the API functions can't retrieve them. This commit fixes this part of the test (one unrelated test still fails). ok inoguchi jsing
* Switch finish{,_peer}_md_len from int to size_ttb2020-12-141-3/+3
| | | | | | | This is the natural type for these and it simplifies an upcoming commit. The few consumers have been carefully checked to be fine with this. ok inoguchi jsing
* Mark bitmask_{start,end}_values[] and g_probable_mtu[] const.tb2020-12-051-4/+4
| | | | ok jsing kn
* Mark nid_list[] const. This moves 116 bytes to .rodata.tb2020-12-051-2/+2
| | | | ok jsing kn
* grammar fixes from Varik "The Genuine Article!!!" Valefor;jmc2020-12-031-3/+3
|
* Bring back *_client_method() structstb2020-12-013-11/+200
| | | | | | | | | | | | | | | | | | | | | | | | | | The method unification broke an API promise of SSL_is_server(). According to the documentation, calling SSL_is_server() on SSL objects constructed from generic and server methods would result in 1 even before any call to SSL_set_accept_state(). This means the information needs to be available when SSL_new() is called, so must come from the method itself. Prior to the method unification, s->server would be set to 0 or 1 in SSL_new() depending on whether the accept method was undefined or not. Instead, introduce a flag to the internal structs to distinguish client methods from server and generic methods and copy that flag to s->server in SSL_new(). This problem was reported to otto due to breakage of DoH in net/dnsdist. The reason for this is that www/h2o relies on SSL_is_server() to decide whether to call SSL_accept() or SSL_connect(). Thus, the h2o server would end up responding to a ClientHello with another ClientHello, which results in a handshake failure. The bandaid applied to www/h2o can be removed once this fix has made it into snaps. No other breakage is known. This commit brings back only about half of the duplication removed in the method unification, so is preferable to a full revert. ok jsing
* fix another misleading line break and indentlibressl-v3.3.0tb2020-11-201-3/+4
|
* fix confusing line break and indenttb2020-11-201-3/+4
|
* typo & punctuation in commenttb2020-11-171-3/+3
|
* Implement exporter for TLSv1.3.jsing2020-11-164-8/+121
| | | | | | | | | This implements the key material exporter for TLSv1.3, as defined in RFC8446 section 7.5. Issue reported by nmathewson on github. ok inoguchi@ tb@
* Implement auto chain for the TLSv1.3 server.jsing2020-11-111-1/+23
| | | | | | | | | Apparently OpenLDAP relies on this craziness to provide intermediates, rather than specifying the chain directly like a normal TLS server would. Issue noted by sthen@ and Bernard Spil, who both also tested this diff. ok tb@
* Use size_t for key_block_len.jsing2020-11-112-9/+7
| | | | | | | This allows us to remove a check and will make future changes simpler. Use suitable names for tls1_generate_key_block() arguments while here. ok inoguchi@ tb@
* Only check BIO_should_read() on read and BIO_should_write() on write.jsing2020-11-031-5/+1
| | | | | | | | | | | | | | | | | | The TLSv1.3 code that drives a BIO currently checks BIO_should_read() after BIO_write() and BIO_should_write() after BIO_read(), which was modelled on SSL_get_error(). However, there are certain cases where this can confuse the caller - primarily where the same BIO is being used for both read and write and the caller is manipulating the retry flags. SSL_get_error() tends avoids this issue by relying on another layer of state tracking. Unfortunately haproxy hits this situation - it has its own BIO_METHOD, the same BIO is used for both read and write and it manipulates the retry flags - resulting in it stalling. Issued noted by Thorsten Lockert <tholo@tzecmaun.org> ok beck@ tb@
* Unbreak DTLS retransmissions for flights that include a CCS.jsing2020-10-151-7/+8
| | | | | | | | | | When retransmitting a flight that includes a CCS, the record protection from the previous epoch has to be used to send the messages up to and including the CCS, with messages after the CCS using record protection from the current epoch. The code that restores the record protection state failed to work correctly with the new TLSv1.2 record layer. ok tb@
* zap annoying stray spacestb2020-10-151-4/+4
|
* Replace SSL_IS_DTLS with SSL_is_dtls().jsing2020-10-1411-96/+92
| | | | | | Garbage collect the now unused SSL_IS_DTLS macro. ok tb@
* Provide SSL_is_dtls().jsing2020-10-142-2/+11
| | | | | | | For now this is #ifdef LIBRESSL_INTERNAL and will be exposed during the next library bump. ok tb@
* Mark DTLS methods as DTLS.jsing2020-10-142-3/+10
| | | | | | | | Rather than inferring DTLS from the method version, add a field that marks a method as specifically being DTLS. Have SSL_IS_DTLS condition on this rather than on version. ok tb@
* drop references to the SSL protocol because support was removed long ago;schwarze2020-10-121-6/+6
| | | | suggested by tb@
* List and describe the recommended methods first and relegate theschwarze2020-10-121-27/+26
| | | | | | deprecated methods to a separate table. Simplify and shorten the surrounding verbiage. Joint work with tb@.
* In ssl_methods.c rev. 1.18, jsing@ deprecated *_server_method(3)schwarze2020-10-111-11/+18
| | | | | | | and *_client_method(3). Adjust the documentation. While here, delete most of the verbiage regarding the deprecated functions SSLv23_*(3) and add the missing entry to RETURN VALUES. OK tb@
* SSL3_ENC_METHOD is just a flag word; merge it into SSL_METHOD_INTERNALguenther2020-10-115-42/+28
| | | | | | | with #defines for the per-version initializers instead of extern globals. Add SSL_USE_SHA256_PRF() to complete the abstraction. ok tb@ jsing@
* Fix an assert conditioned on DTLS1_VERSION.jsing2020-10-111-9/+4
| | | | | | | | This condition previously existed for DTLS BAD_VER, which has long been removed. Furthermore, conditioning on DTLS1_VERSION means this is broken for any newer DTLS version. While here roll up two assertions into one. ok tb@
* Grow init_buf before stashing a handshake message for the legacy stack.jsing2020-10-111-1/+3
| | | | | | | | | | | | | When transitioning from the TLSv1.3 stack to the legacy stack, grow init_buf before stashing the handshake message. The TLSv1.3 stack has already received the handshake message (potentially from multiple TLS records) and validated its size, however the default allocation is only for a single plaintext record, which can result in the handshake message failing to fit in certain cases. Issue noted by tb@ via tlsfuzzer. ok tb@
* Make profile_name const in srtp_find_profile_by_name()tb2020-10-112-7/+5
| | | | | | | | There is no reason (and there never was any) for profile_name to be non-const, it was always just passed to strncmp(). Changing this allows removing an ugly instance of casting away const. ok guenther jsing
* Condense and simplify TLS methods.jsing2020-10-117-442/+73
| | | | | | | | | | | | | | | Historically, OpenSSL has had client and server specific methods - the only difference between these is that the .ssl_connect or .ssl_accept function pointer is set to ssl_undefined_function, with the intention of reducing code size for a statically linked binary that was only a client or server. These days the difference is minimal or non-existant in many cases and we can reduce the amount of code and complexity by having single method. Internally remove all of the client and server specific methods, simplifying code in the process. The external client/server specific API remain, however these now return the same thing as TLS_method() does. ok tb@
* Constipate srtp_known_profiles, pushing it into .data.rel.roguenther2020-10-113-17/+18
| | | | ok tb@ jsing@
* Constipate ssl3_ciphers and tls1[23]_sigalgs*, pushing them intoguenther2020-10-116-32/+32
| | | | | | .data.rel.ro and .rodata respectively. ok tb@ jsing@
* A void function has no return value, so zap RETURN VALUES sectiontb2020-10-081-5/+2
| | | | | documenting that SSL_set_bio(3) cannot fail. A similar commit was made by schwarze a while ago for a few functions in libcrypto.
* grammar fix: if/when a renegotiation takeS placetb2020-10-082-6/+6
|
* fix line wrappingtb2020-10-071-3/+2
|
* Mop up various things that are now unused with the new record layer.jsing2020-10-073-32/+6
| | | | ok inoguchi@ tb@
* Include a TLS record header when switching to the legacy stack.jsing2020-10-071-9/+27
| | | | | | | | | | | | | | | | | | | | | | | | | When switching to the legacy TLS stack we previously copied any remaining handshake messages into the receive buffer, but do not include any TLS record header (largely due to the fact that we've already processed part of the TLS record that we actually received - that part is placed into the init_buf). This worked fine with the old record layer implementation, however the new record layer expects to find the TLS record header. This means that if we switch from the new stack to the legacy stack (i.e. the remote side does not support TLSv1.3) and there is more than one handshake message in the TLS plaintext record (which Microsoft's TLS stack is known to do), we now read a TLS record of zero bytes instead of getting the correct length. Fix this by generating a pseudo-TLS record header when switching from the new TLS stack to the legacy stack. Found the hard way by guenther@. Thanks to tb@ for coming up with a reproducible test case and doing much of the debugging. ok inoguchi@ tb@
* Merge d1_{clnt,srvr}.c into ssl_{clnt,srvr}.cjsing2020-10-036-359/+103
| | | | | | | The d1_{clnt,srvr}.c contain a single function each - merge these into the ssl_{clnt,srvr}.c, renaming them with an ssl3_ prefix for consistency. ok beck@ tb@
* Use TLSv1_1_enc_data instead of DTLSv1_enc_data.jsing2020-10-033-11/+6
| | | | | | | | DTLSv1 is TLSv1.1 over datagrams - there is no need for a separate SSL3_ENC_METHOD struct, just use TLSv1_1_enc_data and remove DTLSv1_enc_data entirely. ok tb@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-04-11 11:54:57 +0000