summaryrefslogtreecommitdiff
path: root/src/lib (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* While the traditional OpenSSL return value and behaviour of BIO_dump(3)beck2021-07-112-31/+17
| | | | | | | | | | | is pure comedy gold, and now documented as such, sadly this bit of pure Muppet genius can't really in good consience stay in the tree as is. Change BIO_dump to always return the number of bytes printed on success and to stop printing and return -1 on failure if a writing function fails. ok tb@, jsing@
* new manual page ASN1_parse_dump(3)schwarze2021-07-115-7/+222
|
* document ASN1_get_object(3)schwarze2021-07-114-5/+207
|
* Fix a read buffer overrun in X509_CERT_AUX_print(3),schwarze2021-07-101-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | which by implication also affects X509_print(3). The ASN1_STRING_get0_data(3) manual explitely cautions the reader that the data is not necessarily NUL-terminated, and the function X509_alias_set1(3) does not sanitize the data passed into it in any way either, so we must assume the alias->data field is merely a byte array and not necessarily a string in the sense of the C language. I found this bug while writing manual pages for these functions. OK tb@ As an aside, note that the function still produces incomplete and misleading results when the data contains a NUL byte in the middle and that error handling is consistently absent throughout, even though the function provides an "int" return value obviously intended to be 1 for success and 0 for failure, and even though this function is called by another function that also wants to return 1 for success and 0 for failure and even does so in many of its code paths, though not in others. But let's stay focussed. Many things would be nice to have in the wide wild world, but a buffer overflow must not be allowed to remain in our backyard.
* new manual page BIO_dump(3)schwarze2021-07-103-3/+149
|
* Add a bunch of workarond in the verifier to support partial chains andbeck2021-07-102-16/+135
| | | | | | | | | the saving of the first error case so that the "autochain" craziness from openssl will work with the new verifier. This should allow the new verification code to work with a bunch of the autochain using cases in some software. (and should allow us to stop using the legacy verifier with autochain) ok tb@
* Fix mixup between localKeyID and friendlyName.tb2021-07-091-3/+3
| | | | "please commit" schwarze
* KNF: remove whitespace between functions and parenthesestb2021-07-096-28/+28
|
* new manual page for X509_keyid_set1(3), X509_keyid_get0(3),schwarze2021-07-095-9/+184
| | | | X509_alias_set1(3), X509_alias_get0(3)
* document X509_add1_reject_object(3) and X509_reject_clear(3)schwarze2021-07-081-7/+24
|
* add new manual page for X509_add1_trust_object(3) and X509_trust_clear(3)schwarze2021-07-083-3/+87
|
* document X509_signature_dump(3) and X509_signature_print(3)schwarze2021-07-065-9/+97
|
* Fix a bug in X509_print_ex(3).schwarze2021-07-061-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If the user set nmflags == X509_FLAG_COMPAT and X509_NAME_print_ex(3) failed, the error return value of 0 was misinterpreted as an indicator of success, causing X509_print_ex(3) to ignore the error, continue printing, and potentially return successfully even though not all the content of the certificate was printed. The X509_NAME_print_ex(3) manual page explains that this function indicates failure by returning 0 if nmflags == X509_FLAG_COMPAT and by returning -1 if nmflags != X509_FLAG_COMPAT. That's definitely atrocious API design (witnessed by the complexity of the code needed for correct error checking), but changing the API contract and becoming incompatible with OpenSSL would make matters even worse. Note that just checking for <= 0 in all cases would not be correct either because X509_NAME_print_ex(3) returns 0 to indicate that it successfully printed zero bytes in some cases, for example when all three of the following conditions hold: 1. nmflags != X509_FLAG_COMPAT 2. indent == 0 (which X509_print_ex(3) does use in some cases) 3. the name object is NULL or empty I found the bug by code inspection and proposed an incomplete patch, then jsing@ proposed this improved version of the patch. OK jsing@.
* document i2a_ASN1_OBJECT(3)schwarze2021-07-051-8/+61
|
* document X509_find_by_subject(3) and X509_find_by_issuer_and_serial(3)schwarze2021-07-043-3/+74
|
* Bugfix: when X509_NAME_dup(3) failed, X509_NAME_set(3) indicated successschwarze2021-07-041-14/+8
| | | | | | | | | | | | | | | | | even though it did not actually set the name. Instead, indicate failure in this case. This commit sneaks in a small, unrelated change in behaviour. If the first argument of X509_NAME_set(3) was NULL, the function used to return failure. Now it crashes the program by accessing the NULL pointer, for compatibility with the same change in OpenSSL. This merges the following two commits from the OpenSSL-1.1.1 branch, which is still available under a free license: 1. 180794c5 Rich Salz Sep 3 11:33:34 2017 -0400 2. c1c1783d Richard Levitte May 17 09:53:14 2018 +0200 OK tb@
* Document X509_NAME_set(3).schwarze2021-07-031-3/+41
| | | | | | It is not particularly well-designed and sets a number of traps for the unwary, but it is a public API function in both OpenSSL and LibreSSL and used at various places.
* Do a first pass clean up of SSL_METHOD.jsing2021-07-034-103/+14
| | | | | | | | | The num_ciphers, get_cipher_by_char and put_cipher_by_char function pointers use the same function for all methods - call ssl3_num_ciphers() directly, absorb ssl3_get_cipher_by_char() into SSL_CIPHER_find() and remove the unused ssl3_put_cipher_by_char() code. ok inoguchi@ tb@
* Document the read-only (sic!) accessor function X509_NAME_ENTRY_set(3).schwarze2021-07-021-9/+77
| | | | | While here, stress that X509_NAME objects cannot share X509_NAME_ENTRY objects, and polish a few misleading wordings.
* Add a roff comment saying that X509_certificate_type(3) is intentionallyschwarze2021-07-021-2/+5
| | | | | | undocumented. It is archaic and practically unused and unusable. tb@ and jsing@ agree with marking it as undocumented. Put the comment here because EVP_PKEY_base_id(3) is a viable alternative.
* call the API function X509_NAME_cmp(3) instead of the obsolete,schwarze2021-07-021-2/+2
| | | | | | undocumented macro alias X509_name_cmp(3); no change to the assembler code generated by the compiler; OK tb@
* Add a roff comment saying that X509_name_cmp(3) is intentionallyschwarze2021-07-021-2/+4
| | | | | undocumented because it is almost unused in real-world code. OK tb@
* Merge SSL_METHOD_INTERNAL into SSL_METHOD.jsing2021-07-0115-195/+126
| | | | | | | Now that SSL_METHOD is opaque and in internal headers, we can remove SSL_METHOD_INTERNAL by merging it back into SSL_METHOD. ok tb@
* Prepare to provide SSL_get_signature_nid() and friends.jsing2021-06-302-2/+81
| | | | | | | | | | | This adds functionality for SSL_get_signature_nid(), SSL_get_peer_signature_nid(), SSL_get_signature_type_nid() and SSL_get_peer_signature_type_nid(). This is not currently publicly visible and will be exposed at a later date. ok inoguchi@ tb@
* Move some structs from public to private headers.jsing2021-06-303-125/+108
| | | | | | | | Move struct ssl_cipher_st, struct ssl_method_st, struct ssl_session_st and struct ssl3_state_st from public to private headers. These are already under #ifdef LIBRESSL_INTERNAL and are no longer publicly visible. ok inoguchi@ tb@
* document and deprecate the macros X509_extract_key(3)schwarze2021-06-301-6/+35
| | | | and X509_REQ_extract_key(3), using feedback from tb@ and jsing@
* Correct sigalg hash usage when signing content for client verify.jsing2021-06-301-3/+2
| | | | This was inadvertently broken during sigalgs refactoring.
* Pull sigalg selection up into ssl3_send_client_verify().jsing2021-06-291-14/+11
| | | | | | | | This means that we do sigalg selection for all cases, including those where are are not sending sigalgs. This is needed in order to track our signature type in legacy cases. ok tb@
* Track sigalg used by ourselves and our peer in the legacy stack.jsing2021-06-292-2/+6
| | | | This is needed for upcoming API additions.
* Pull up and dedup the TLS version check in ssl_sigalg_pkey_ok().jsing2021-06-291-5/+6
| | | | Suggested by tb@
* Simplify RSA PSS key size comment.jsing2021-06-291-5/+2
| | | | Wording provided by tb@
* Use appropriate TLS version when building client sigalg extensions.jsing2021-06-291-2/+6
| | | | | | | | Only use the minimum TLS version to when building a signature algorithms extension for a ClientHello - in all other cases we should be using the negotiated TLS version. ok inoguchi@ tb@
* Change ssl_sigalg_from_value() to take SSL * instead of a TLS version.jsing2021-06-291-7/+6
| | | | | | | This simplifies callers, as only the negotiated TLS version needs to be used here. Requested by tb@
* Make various sigalg functions static now that they're only used internally.jsing2021-06-292-10/+5
|
* Convert legacy stack server to ssl_sigalg_for_peer().jsing2021-06-291-47/+29
| | | | ok inoguchi@ tb@
* Convert legacy stack client to ssl_sigalg_for_peer().jsing2021-06-291-34/+12
| | | | ok inoguchi@ tb@
* Provide a ssl_sigalg_for_peer() function and use in the TLSv1.3 code.jsing2021-06-294-15/+33
| | | | | | | | | | | | Provide an ssl_sigalg_for_peer() function that knows how to figure out which signature algorithm should be used for a peer provided signature, performing appropriate validation to ensure that the peer provided value is suitable for the protocol version and key in use. In the TLSv1.3 code, this replaces the need for separate calls to lookup the sigalg from the peer provided value, then perform validation. ok inoguchi@ tb@
* Move the RSA-PSS check for TLSv1.3 to ssl_sigalg_pkey_ok().jsing2021-06-296-34/+29
| | | | | | | | Also, rather than passing in a check_curve flag, pass in the SSL * and handle version checks internally to ssl_sigalg_pkey_ok(), simplifying the callers. ok inoguchi@ tb@
* Factor out handling of legacy default signature algorithms.jsing2021-06-291-32/+27
| | | | | | | | In the case of TLSv1.0 and TLSv1.1 there is no signature algorithms extension and default signature algorithms are used - similar applies to TLSv1.2 when the signature algorithms extension has been omitted. ok inoguchi@ tb@
* Mop up now unused variables.jsing2021-06-291-7/+2
|
* Require a ServerHello following a HelloRetryRequest to use the same cipher.jsing2021-06-291-2/+11
| | | | | | | | | RFC 8446 section 4.1.4 requires that the client ensure the cipher suite in the TLSv1.3 HelloRetryRequest and subsequent ServerHello is the same. Reported via GitHub issue #675. ok inoguchi@ tb@
* Reject zero-length non-application data fragments in the legacy stack.jsing2021-06-291-1/+11
| | | | | | | | | Per RFC 5246 section 6.2.1, zero-length fragments are only permitted for application data - reject all others. Reported via GitHub issue #675. ok inoguchi@ tb@
* Use the order action->sender == ctx->mode everywhere for consistency.tb2021-06-281-3/+3
|
* ctx->alert is not a boolean, so compare it explicitly against 0.tb2021-06-281-3/+3
|
* The state machine now takes care of setting the legacy state,tb2021-06-281-11/+1
| | | | | | | so it is no longer necessary in to do this by hand in various places of the code interfacing with the legacy stack. ok jsing
* Expand info callback support for TLSv1.3tb2021-06-282-7/+187
| | | | | | | | | | | | | During the TLSv1.3 handshake, update the legacy state and call the info callback at the appropriate moment. This is done by mapping the TLSv1.3 states to the states in the old state machine whenever that is possible. The callbacks are called at the beginning and end of the handshake, and just before the state machine advances. This should fix a periodic warning in logs of tor relays about a variable that wasn't set although it should have been. input/ok jsing, ok inoguchi (early version)
* Track the sigalgs used by ourselves and our peer.jsing2021-06-273-9/+14
| | | | | | | | | | | Move the sigalg pointer from SSL_HANDSHAKE_TLS13 to SSL_HANDSHAKE, naming it our_sigalg, adding an equivalent peer_sigalg. Adjust the TLSv1.3 code that records our signature algorithm. Add code to record the signature algorithm used by our peer. Needed for upcoming API additions. ok tb@
* Have ssl3_send_client_verify() pass *pkey to called functions.jsing2021-06-271-22/+11
| | | | | | ssl3_send_client_verify() already has a pointer to the EVP_PKEY for the certificate - pass this as an argument to the functions that it calls, rather than duplicating code/variable declarations.
* Change ssl_sigalgs_from_value() to perform sigalg list selection.jsing2021-06-276-32/+31
| | | | | | | | | Rather that passing in a sigalg list at every call site, pass in the appropriate TLS version and have ssl_sigalgs_from_value() perform the sigalg list selection itself. This allows the sigalg lists to be made internal to the sigalgs code. ok tb@
* Rename ssl_sigalg() to ssl_sigalg_from_value().jsing2021-06-276-17/+18
| | | | | | | This makes the code more self-documenting and avoids the ambiguity between ssl_sigalg the struct and ssl_sigalg the function. ok tb@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-05-06 21:40:11 +0000