summaryrefslogtreecommitdiff
path: root/src/lib (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* define OPENSSL_NO_SSL_TRACE in opensslfeatures.hinoguchi2020-08-291-1/+1
| | | | ok jsing@ tb@
* Send an unexpected message alert if no valid content type is found.jsing2020-08-111-2/+5
| | | | | | | | | When record protection is engaged, the plaintext must be followed by a non-zero content type and optional zero padding. If the plaintext is zero length or only consists of zero bytes then it is not a valid message, since the content type is unspecified. ok tb@
* Increment the epoch in the same place for both read and write.jsing2020-08-111-3/+3
| | | | ok inoguchi@ tb@
* Use 0 instead of 0x00 for memset() calls.jsing2020-08-112-8/+8
| | | | ok inoguchi@ tb@
* Use SSL3_SEQUENCE_SIZE for last_write_sequence[] rather than hardcoding.jsing2020-08-111-2/+2
| | | | ok inoguchi@ tb@
* In SSL_new() just 'goto err' on allocation failure.jsing2020-08-111-11/+6
| | | | | | The error path does the same as the currently duplicated code. ok inoguchi@ tb@
* Avoid passing -1 to freezero.tb2020-08-101-9/+10
| | | | | | | | If a peer sends a bogus record consisting of all-zero plaintext, the content_len would be decremented to -1 and cause a crash in freezero. ok inoguchi jsing
* Fix some wrapping/indent.jsing2020-08-091-4/+3
|
* Add P-521 to the list of curves supported by default in the client.jsing2020-08-091-5/+18
| | | | | | | | | | | | | | | A certain VPN provider appears to have configured their servers to only accept P-521 for TLSv1.3 key exchange. The particular VPN software in use also does not currently allow for the TLSv1.3 key share groups to be configured, which means that there is no way to easily use LibreSSL in this situation. Include P-521 in the list of curves that are supported by default in the client, in order to increase interoperability. Discussed at length with beck@, inoguchi@ and tb@. ok tb@
* Use CBB more correctly when writing SSL3/DTLS records.jsing2020-08-092-66/+92
| | | | | | | | | | | | Previously we used CBB to build the record headers, but not the entire record. Use CBB_init_fixed() upfront, then build the record header and add space for the record content. However, in order to do this we need to determine the length of the record upfront. This simplifies the code, removes a number of manual bounds checks and makes way for further improvements. ok inoguchi@ tb@
* Make the explicit IV length handling in DTLS the same as SSL3/TLS.jsing2020-08-091-8/+13
| | | | ok inoguchi@ tb@
* delete another word to improve the wording; suggested by jmc@schwarze2020-08-061-2/+2
|
* Explain the purpose of CMAC_resume(3) in more detail.schwarze2020-08-061-3/+9
| | | | | | | | Triggered by jmc@ apparently misunderstanding the intention of the text and fixing a grammatical error in a way that wasn't ideal, so i guess he wouldn't have been the only one to find the previous version hard to understand. OK jmc@
* Cleanup aead_ctxinoguchi2020-08-041-1/+3
| | | | ok jsing@ tb@
* Only parse a client's status_request in the CHtb2020-08-031-1/+4
| | | | | | | | A client should only send a status_request as part of the CH. Pointed out by Michael Forney ok inoguchi jsing
* Ensure clients only send a status_request in the CHtb2020-08-031-3/+7
| | | | | | | | | | The current code might cause a client to send a status_request containing a CertificateStatusRequest with its certificate. This makes no sense. Pointed out by Michael Forney ok inoguchi jsing
* Correctly handle server requests for an OCSP responsetb2020-08-031-1/+12
| | | | | | | | | | | | | | | | | According to RFC 8446, 4.4.2.1, a server may request that a client present an OCSP response with its certificate by sending an empty status_request extension as part of the certificate request. The current code expects a full CertificateStatus structure, which is only sent if the server sends an OCSP response with its certificate. This causes interoperability issues with Go's TLS server and with newer GnuTLS where we would abort the handshake with a decode_error alert and length mismatch error. Issue reported and diagnosed by Michael Forney Problem also found by Mikolaj Kucharski and inoguchi. ok inoguchi jsing
* Check the return value of tls1_enc() in the write path.jsing2020-08-022-6/+6
| | | | | | | | | The write path can return a failure in the AEAD path and there is no reason not to check a return value. Spotted by tb@ during another review. ok tb@
* Clean up/simplify more of the dtls1/ssl3 record writing code:jsing2020-08-012-73/+34
| | | | | | | | | | | | - Make the DTLS code much more consistent with the ssl3 code. - Avoid assigning wr->input and wr->length just so they can be used as arguments to memcpy(). - Remove the arc4random_buf() call for the explicit IV, since tls1_enc() already does this for us. ok tb@
* Pull record version selection code up and pass it as an argument tojsing2020-08-011-15/+15
| | | | | | ssl3_create_record(). ok tb@
* Have ssl_init_wbio_buffer() push the buffering BIO rather than doing itjsing2020-07-301-5/+2
| | | | | | ourselves. Spotted by tb@ during a previous review.
* Clean up and simplify some of the SSL3/DTLS1 record writing code.jsing2020-07-302-76/+72
| | | | | | | | | | | This will allow for further changes to be made with less complexity and easier review. In particular, decide if we need an empty fragment early on and only do the alignment calculation once (rather than in two separate parts of the function. ok tb@ inoguchi@
* Add minimal info callback support for TLSv1.3tb2020-07-303-3/+32
| | | | | | | | | | | | | | As abieber@ found the hard way, some python frameworks (twisted, synapse) thought it a great idea to use the info callback mechanism (designed to get state information about SSL objects) to modify state information such as setting and verifying the SNI. The switch of TLS_method() to default to TLSv1.3 broke these contraptions. Further bits of the info callback mechanism will likely metastasize throughout the TLSv1.3 stack if we need them, so we only do what's really necessary now. Lots of debugging, crucial hint and testing by abieber input & ok jsing
* Handle SSL_MODE_AUTO_RETRY being changed during a TLSv1.3 session.jsing2020-07-251-1/+4
| | | | | | | | | | | | | | | Both Perl's HTTP::Tiny and IO::Socket::SSL know about SSL_MODE_AUTO_RETRY and try to work around the fact that OpenSSL enabled it by default. However, this can lead to the mode being disabled prior to the TLSv1.3 handshake and then enabled after the handshake has completed. In order to handle this correctly we have to check the mode and inform the record layer prior to every read. Issue reported and test case provided by Nathanael Rensen <nathanael@polymorpheus.com>. ok inoguchi@ tb@
* remove half a dozen "goto" statements and a labelschwarze2020-07-251-14/+1
| | | | | that change nothing whatsoever, except making the code harder to read; OK tb@
* tweak previous;jmc2020-07-241-4/+4
|
* document PEM_X509_INFO_read(3) and PEM_X509_INFO_read_bio(3)schwarze2020-07-237-14/+207
| | | | OK tb@
* Fix a bug in PEM_X509_INFO_read_bio(3) that is very likely to causeschwarze2020-07-231-21/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | use-after-free and double-free issues in calling programs. The bug was introduced in SSLeay-0.6.0 released on June 21, 1996 and has been present since OpenBSD 2.4. I found the bug while documenting the function. The bug could bite in two ways that looked quite different from the perspective of the calling code: * If a stack was passed in that already contained some X509_INFO objects and an error occurred, all the objects passed in would be freed, but without removing the freed pointers from the stack, so the calling code would probable continue to access the freed pointers and eventually free them a second time. * If the input BIO contained at least two valid PEM objects followed by at least one PEM object causing an error, at least one freed pointer would be put onto the stack, even though the function would return NULL rather than the stack. But the calling code would still have a pointer to the stack, so it would be likely to access the new bogus pointers sooner or later. Fix all this by remembering the size of the input stack on entry and cutting it back to exactly that size when exiting due to an error, but no further. While here, do some related cleanup: * Garbage collect the automatic variables "error" and "i" which were only used at one single place each. * Use NULL rather than 0 for pointers. I like bugfixes that make the code four lines shorter, reduce the number of variables by one, reduce the number of brace-blocks by one, reduce the number if if-statements by one, and reduce the number of else-clauses by one. Tweaks and OK tb@.
* Dedup the use legacy stack code.jsing2020-07-141-56/+25
| | | | ok inoguchi@ tb@
* Revert the TLSv1.3 version switching fix/hack.jsing2020-07-141-10/+1
| | | | | | | | This is no longer necessary since the TLS_method() now supports TLSv1.3. Reverts r1.211 of ssl_lib.c. ok beck@ inoguchi@ tb@
* Remove some unnecessary function pointers from SSL_METHOD_INTERNAL.jsing2020-07-075-64/+17
| | | | | | ssl_version is completely unused and get_timeout is the same everywhere. ok beck@ inoguchi@ tb@
* Enable TLSv1.3 for the generic TLS_method().jsing2020-07-072-5/+52
| | | | | | This can be done now that we have both TLSv1.3 client and server. ok beck@ inoguchi@ tb@
* Add support for timeconting in userland.pirofti2020-07-062-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | This diff exposes parts of clock_gettime(2) and gettimeofday(2) to userland via libc eliberating processes from the need for a context switch everytime they want to count the passage of time. If a timecounter clock can be exposed to userland than it needs to set its tc_user member to a non-zero value. Tested with one or multiple counters per architecture. The timing data is shared through a pointer found in the new ELF auxiliary vector AUX_openbsd_timekeep containing timehands information that is frequently updated by the kernel. Timing differences between the last kernel update and the current time are adjusted in userland by the tc_get_timecount() function inside the MD usertc.c file. This permits a much more responsive environment, quite visible in browsers, office programs and gaming (apparently one is are able to fly in Minecraft now). Tested by robert@, sthen@, naddy@, kmos@, phessler@, and many others! OK from at least kettenis@, cheloha@, naddy@, sthen@
* zap trailing whitespace on one linetb2020-07-031-2/+2
|
* Make the message type available to the extension functionstb2020-07-032-167/+181
| | | | | | | | | | | | | | Some TLS extensions need to be treated differently depending on the handshake message they appear in. Over time, various workarounds and hacks were used to deal with the unavailability of the message type in these functions, but this is getting fragile and unwieldy. Having the message type available will enable us to clean this code up and will allow simple fixes for a number of bugs in our handling of the status_request extension reported by Michael Forney. This approach was suggested a while ago by jsing. ok beck jsing
* Improve argument order for the internal tlsext APItb2020-07-038-39/+39
| | | | | | | | Move is_server and msg_type right after the SSL object so that CBS and CBB and alert come last. This brings these functions more in line with other internal functions and separates state from data. requested by jsing
* Disable assembly code for powerpc64; more work is needed to make it work.kettenis2020-06-291-8/+9
|
* Switch back to bn_mul_mont_int since the bn_mul_mont_fpu64 code isn'tkettenis2020-06-281-3/+3
| | | | | hooked up and the lack of a bn_mul_mont_int implementation results in undefined references.
* Accidentally doubled these files on first commit. Correcting.drahn2020-06-262-194/+1
|
* Switch the order of the two tests in tls13_client_hello_required_extensionstb2020-06-251-9/+9
| | | | to match the order they are listed in the RFC. No functional change.
* Intial attempt at powerpc64 libcrypto pieces.drahn2020-06-252-0/+386
| | | | just commit this kettenis@
* Properly document the return values of EVP_PKEY_base_id(3)schwarze2020-06-244-70/+152
| | | | | | | | and EVP_PKEY_id(3), then describe the "type" parameters of various functions more precisely referencing that information. In particular, document X509_get_signature_type(3) which was so far missing. OK tb@
* use n-bit <noun> consistently; ok schwarze for the principal of the idea,jmc2020-06-246-28/+28
| | | | and for flagging which pages to check;
* Make tls13_legacy_shutdown() match ssl3_shutdown() semantics.jsing2020-06-241-21/+22
| | | | | | | | | | | | | When first called, queue and send a close notify, before returning 0 or 1 to indicate if a close notify has already been received from the peer. If called again only attempt to read a close notify if there is no pending application data and only read one record from the wire. In particular, this avoids continuing to read application data where the peer continues to send application data. Issue noted by naddy@ with ftp(1). ok jca@ tb@
* new manual page ChaCha(3);schwarze2020-06-243-2/+257
| | | | OK tb@
* new manual page CMAC_Init(3);schwarze2020-06-245-7/+298
| | | | OK tb@
* Document eight additional pre-OpenSSL-1.1 accessor functions that areschwarze2020-06-241-21/+122
| | | | | | | | | | still widely used according to code searches on the web, so people reading existing code will occasionally want to look them up. While here, correct the return type of X509_CRL_get0_lastUpdate(3) and X509_CRL_get0_nextUpdate(3), which return const pointers. Also, add some precision regarding RETURN VALUES.
* Enforce restrictions for ClientHello extensionstb2020-06-241-1/+44
| | | | | | | | | | | | | | | RFC 8446 section 9.2 imposes some requirements on the extensions sent in the ClientHello: key_share and supported_groups must either both be present or both be absent. If no pre_shared_key was sent, the CH must contain both signature_algorithms and supported_groups. If either of these conditions is violated, servers must abort the handshake with a missing_extensions alert. Add a function that enforces this. If we are going to enforce that clients send an SNI, we can also do this in this function. Fixes failing test case in tlsfuzzer's test-tls13-keyshare-omitted.py ok beck inoguchi jsing
* We inherited the constant time CBC padding removal from BoringSSL, buttb2020-06-191-4/+4
| | | | | | | | | | | missed a subsequent fix for an off-by-one in that code. If the first byte of a CBC padding of length 255 is mangled, we don't detect that. Adam Langley's BoringSSL commit 80842bdb44855dd7f1dde64a3fa9f4e782310fc7 Fixes the failing tlsfuzzer lucky 13 test case. ok beck inoguchi
* mark the functions documented in des_read_pw(3) as deprecatedschwarze2020-06-192-6/+11
| | | | | and point to UI_UTIL_read_pw(3) instead; tb@ agrees with the general direction
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-28 14:17:05 +0000