summaryrefslogtreecommitdiffstats
path: root/lib/libssl (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* 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 indenttb2020-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@
* Reimplement the TLSv1.2 record handling for the read side.jsing2020-10-036-605/+426
| | | | | | | | | | | | This is the next step in replacing the TLSv1.2 record layer. The existing record handling code does decryption and processing in place, which is not ideal for various reasons, however it is retained for now as other code depends on this behaviour. Additionally, CBC requires special handling to avoid timing oracles - for now the existing timing safe code is largely retained. ok beck@ inoguchi@ tb@
* Rename tls13_record_layer_alert() to tls13_record_layer_enqueue_alert()jsing2020-10-031-3/+4
| | | | | | | This avoids naming confusion with an upcoming TLSv1.2 record layer change and is more descriptive of this function. Requested by tb@
* Make dtls1_copy_record() take a DTLS1_RECORD_DATA_INTERNAL *.jsing2020-10-031-10/+4
| | | | | | This removes the need for extra variables and casts. ok inoguchi@ tb@
* Inline two macros that are only used in one place each.jsing2020-10-031-16/+6
| | | | | | | This improves readability - while here also add a missing return value check (although it cannot currently fail). ok inoguchi@ tb@
* Call dtls1_hm_fragment_free() from dtls1_drain_fragments()jsing2020-09-262-8/+7
| | | | | | | | Currently dtls1_drain_fragments() has a incomplete handrolled version of dtls1_hm_fragment_free(), which has the potential to leak memory. Replace the handrolled free with a call to dtls1_hm_fragment_free(). ok inoguchi@ tb@
* Have dtls1_new() call dtls1_free() on failure.jsing2020-09-261-36/+22
| | | | | | | | Allocate into the appropriate structures and call dtls1_free() on failure, rather than allocating into local variables and then remembering to free various things on failure. ok tb@
* Have dtls1_hm_fragment_new() call dtls1_hm_fragment_free() on failure.jsing2020-09-261-26/+17
| | | | | | | | | | Rather than using local variables and having to remember which things need to be freed upon a failure at a certain point, simply allocate into the hm_fragment struct and call dtls1_hm_fragment_free() on failure. Also use calloc() to ensure memory is appropriately zeroed/initialised. ok tb@
* Refactor dtls1_clear_queues()tb2020-09-261-25/+26
| | | | | | | | | | An upcoming cleanup diff by jsing needs dtls1_clear_queues() to be able to handle NULL pqueues. While one can easily add a NULL check to pqueue_pop(), this does not really fit in with the rest of the code. There are two kinds of while loops in dtls1_clear_queues that drain pqueues, so add two helper functions with a NULL check each. ok jsing
* Simplify the cleanup of init_buf via a ssl3_release_init_buffer() function.jsing2020-09-245-16/+22
| | | | ok beck@ inoguchi@ tb@
* Release read and write buffers using freezero().jsing2020-09-244-21/+26
| | | | | | | | | Provide a ssl3_release_buffer() function that correctly frees a buffer and call it from the appropriate locations. While here also change ssl3_release_{read,write}_buffer() to void since they cannot fail and no callers check the return value currently. ok beck@ inoguchi@ tb@
* Comment out SSL_get0_peername(3) for the OpenBSD 6.8 releaseschwarze2020-09-221-4/+18
| | | | | because tb@ decided to not enable it before the release. OK tb@
* reword ambiguous title line;schwarze2020-09-221-3/+3
| | | | issue noticed by and patch OK by jsing@
* s/before the handshake is complete/during the handshake/gschwarze2020-09-211-8/+7
| | | | | because that is both shorter and more precise; wording suggested by jsing@
* two wording tweaks suggested by jsing@, adding clarityschwarze2020-09-211-5/+4
|
* In ssl.h rev. 1.174 to 1.176, tb@ added some stubs related to 0-RTT data.schwarze2020-09-213-4/+183
| | | | | | | | | | Write documentation from scratch explaining why we don't support 0-RTT but how we stub it out instead. Tweaks and OK tb@. ... and beck@ pointed out that this OpenSSL API is akin to adding a laser sighting system to a giant blackpowder cannon that one keeps blowing one's own feet to mangled scraps with ...
* Document the public function SSL_set_SSL_CTX(3) from scratch,schwarze2020-09-203-3/+72
| | | | | | | which is undocumented in OpenSSL but mentioned in passing in one OpenSSL manual page, and which was recently mentioned by jsing@ when working on SSL_set_ciphersuites(3). With corrections from and OK inoguchi@.
* Add guards around SSL_get0_peername that were accidentally omitted.tb2020-09-201-1/+3
|
* Prepare to provide SSL_get0_peernametb2020-09-192-2/+9
| | | | | | | | | This is a convenience reacharound to libcrypto that trivially wraps X509_VERIFY_PARAM_get0_peername(). It is used by unbound 1.11.0 for better logging. As it's part of the API that landed with OpenSSL's DANE, more recent postfix snapshots use it as well. ok beck inoguchi jsing
* Prepare to provide stubbed out versions for reading/writing 0-RTT datatb2020-09-192-2/+41
| | | | | | | | | | | We do not support this feature but need to provide OpenSSL's API since software assumes it's available whenever TLS1_3_VERSION is available. These are minimal stubs that should have a decent chance to interact reasonably with software expecting the tricky upstream semantics, but this will have to be sorted out with runtime testing, so will likely have to be refined and revisited. ok beck jsing
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.