summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* 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@
* Disable some code that reaches into libssl internals.jsing2021-06-301-0/+7
| | | | This should be moved to a dedicated regress test.
* Disable some tests that probably no longer make sense.jsing2021-06-301-0/+5
| | | | We'll either fix these or remove them in the near future.
* Pull in ssl_locl.h to allow for move of struct ssl_session_st.jsing2021-06-302-2/+5
|
* 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@
* Change ssl_sigalgs_build() to perform sigalg list selection.jsing2021-06-274-28/+29
| | | | | | | | | Rather that doing sigalg list selection at every call site, pass in the appropriate TLS version and have ssl_sigalgs_build() perform the sigalg list selection itself. This reduces code duplication, simplifies the calling code and is the first step towards internalising the sigalg lists. ok tb@
* Tidy some comments and simplify some code.jsing2021-06-271-15/+7
| | | | ok tb@
* Keep sigalg initialiser order consistent - key type, then hash.jsing2021-06-272-20/+20
| | | | | | This matches the order that sigalgs are specified in. ok tb@
* Add test coverage for TLSv1.3 client hellos.jsing2021-06-271-13/+166
| | | | | | This is a little bit clunky due to the number of things that vary (largely thanks to middlebox compatibility mode, along with the versions and key share extensions), however it works and can be improved at a later date.
* Add test coverage for DTLSv1.2 client hellos.jsing2021-06-271-7/+102
|
* Improve test coverage for SSL_OP_NO_DTLSv1.jsing2021-06-271-1/+9
|
* Correct handling of SSL_OP_NO_DTLSv1.jsing2021-06-271-3/+3
| | | | | | When converting to TLS flags, we need to also include SSL_OP_NO_TLSv1, otherwise the TLS equivalent of SSL_OP_NO_DTLSv1 is TLSv1.0 only, which does not work so well when we try to switch back to DTLS versions.
* Teach hexdump() how to identify differing bytes.jsing2021-06-271-9/+13
| | | | | This allows differences between the received data and the test data to be more readily identified.
* More appropriately set cipher_list_len when AES acceleration is available.jsing2021-06-271-5/+6
|
* Tweak some data types and sprinkle some const.jsing2021-06-271-15/+15
|
* Fix .Xr order. From mandoc -Tlint.tb2021-06-262-7/+7
|
* Garbage collect prototoype for ssl_parse_serverhello_tlsext() whichtb2021-06-231-3/+1
| | | | was removed in t1_lib.c r1.141.
* zap wonky commas;jmc2021-06-221-5/+5
|
* Clarify tls_config_set_*_file() file I/O semanticskn2021-06-221-13/+11
| | | | | | | | | | | | | | | | | | | | | | | | tls_config_set_*_file(3) do not just set the file paths like tls_config_set_*_path(3) do, they do load the given file(s) into memory directly using tls_config_load_file(). This distinction is important because it means a later tls_connect(3) will not do any file I/O (at least wrt. those files), which is relevant when for example pleding without "[rwc]path" after loading files into memory and before doing tls_connect(3). The manual's current wording made me use the following due to above way of pledging a program: tls_load_file() tls_config_set_ca_mem() tls_unload_file() While in fact a single tls_config_set_ca_file() call does the same. tls_config.c r1.26 (Aug 2016) change the code but forgot to amend the manual as noted by tb, thanks. Feedback OK tb
* Add GnuTLS interoperability test in appstest.shinoguchi2021-06-211-1/+109
|
* zap trailing whitespacetb2021-06-191-4/+7
|
* Correctly handle epoch wrapping in dtls1_get_bitmap().jsing2021-06-192-4/+5
| | | | | | | | | | | | | | | | | | | | | | Due to a type bug that has been present in DTLS since the code was first committed in 2005, dtls1_get_bitmap() fails to handle next epoch correctly when the epoch is currently 0xffff (and wraps to zero). For various reasons unknown, the epoch field in the SSL3_RECORD_INTERNAL (formerly SSL3_RECORD) was added as unsigned long (even though the value is an unsigned 16 bit value on the wire, hence cannot exceed 0xffff), however was added to other code as unsigned short. Due to integer promotion, the r_epoch value is incremented by one to become 0x10000, before being cast to an unsigned long and compared to the value pulled from the DTLS record header (which is zero). Strangely 0x10000 != 0, meaning that we drop the DTLS record, instead of queueing it for the next epoch. Fix this issue by using more appropriate types and pulling up the calculation of the next epoch value for improved readability. ok inoguchi@ tb@
* Add DTLS test cases that use non-zero initial epochs.jsing2021-06-192-5/+44
| | | | | | In particular, test handling of 0xfffe and 0xffff - the latter results in wrapping to zero for the next epoch. One of these tests triggers a known bug in libssl, which will be fixed following this commit.
* Provide the ability to set the initial DTLS epoch value.jsing2021-06-194-7/+29
| | | | | | This allows for regress to test edge cases for epoch handling. ok tb@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-29 07:06:52 +0000