summaryrefslogtreecommitdiff
path: root/src/lib/libssl/ssl_locl.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Clean up and simplify info and msg callbacks.jsing2021-08-301-10/+17
| | | | | | | | | The info and msg callbacks result in duplication - both for code that refers to the function pointers and for the call sites. Avoid this by providing typedefs for the function pointers and pulling the calling sequences into their own functions. ok inoguchi@ tb@
* Replace DTLS r_epoch with the read epoch from the TLSv1.2 record layer.jsing2021-08-301-2/+2
| | | | ok inoguchi@ tb@
* Dedup dtls1_dispatch_alert()/ssl3_dispatch_alert().jsing2021-07-261-2/+1
| | | | | | | | The code for dtls1_dispatch_alert() and ssl3_dispatch_alert() is largely identical - with a bit of reshuffling we can use ssl3_dispatch_alert() for both protocols and remove the ssl_dispatch_alert function pointer. ok inoguchi@ tb@
* Do a first pass clean up of SSL_METHOD.jsing2021-07-031-5/+1
| | | | | | | | | 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@
* Merge SSL_METHOD_INTERNAL into SSL_METHOD.jsing2021-07-011-11/+7
| | | | | | | 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@
* Move some structs from public to private headers.jsing2021-06-301-1/+106
| | | | | | | | 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@
* Track the sigalgs used by ourselves and our peer.jsing2021-06-271-3/+6
| | | | | | | | | | | 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@
* Garbage collect prototoype for ssl_parse_serverhello_tlsext() whichtb2021-06-231-3/+1
| | | | was removed in t1_lib.c r1.141.
* Correctly handle epoch wrapping in dtls1_get_bitmap().jsing2021-06-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | 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@
* Provide the ability to set the initial DTLS epoch value.jsing2021-06-191-1/+4
| | | | | | This allows for regress to test edge cases for epoch handling. ok tb@
* Remove tls1_alert_code().jsing2021-06-131-2/+1
| | | | | | | | | | | | | | | | | | | | After running the preprocessor, this function becomes: switch (code) { case 0: return (0); case 10: return (10); case 20: return (20); ... } Its intended purpose was to prevent SSLv3 alerts being sent from TLS code, however now that we've removed "no_certificate" from LibreSSL's reach, it no longer does anything useful. ok tb@
* Absorb SSL_AEAD_CTX into struct tls12_record_protection.jsing2021-05-161-23/+1
| | | | | | | | The information contained in SSL_AEAD_CTX really belongs in the tls12_record_protection struct. Absorb SSL_AEAD_CTX, using more appropriate types in the process. ok tb@
* Move DTLS structs/definitions/prototypes to dtls_locl.h.jsing2021-05-161-109/+1
| | | | | | | | Now that the DTLS structs are opaque, add a dtls_locl.h header and move internal-only structs from dtls1.h, along with prototypes from ssl_locl.h. Only pull this header in where DTLS code actually exists. ok inoguchi@ tb@
* Avoid pulling ssl_sigalgs.h in via ssl_locl.h.jsing2021-05-161-2/+3
| | | | | Forward declare struct sigalg in ssl_locl.h and avoid including ssl_sigalgs.h. Explicitly include ssl_sigalgs.h where it is needed.
* Explicitly include <openssl/opensslconf.h> in files using OPENSSL_NO_*jsing2021-05-161-1/+2
| | | | | | Where a file references to OPENSSL_NO_* conditions, ensure that we explicitly include <openssl/opensslconf.h> before any references, rather than relying on another header to pull this in.
* Replace DTLS w_epoch with epoch from TLSv1.2 record layer.jsing2021-05-051-5/+2
| | | | ok inoguchi@ tb@
* Rewrite TLSv1.2 key block handling.jsing2021-05-051-12/+16
| | | | | | | | | | | | | For TLSv1.2 a single key block is generated, then partitioned into individual secrets for use as IVs and keys. The previous implementation splits this across two functions tls1_setup_key_block() and tls1_change_cipher_state(), which means that the IV and key sizes have to be known in multiple places. This implementation generates and partitions the key block in a single step, meaning that the secrets are then simply handed out when requested. ok inoguchi@ tb@
* Clean up tls1_change_cipher_state().jsing2021-05-021-2/+3
| | | | | | | | Replace flag gymnastics at call sites with separate read and write, functions which call the common code. Condition on s->server instead of using SSL_ST_ACCEPT, for consistency and more readable code. ok inoguchi@ tb@
* Clean up dtls1_reset_seq_numbers().jsing2021-05-021-2/+3
| | | | | | | | | | Rather than doing flag gymnastics, split dtls1_reset_seq_numbers() into separate read and write functions. Move the calls of these functions into tls1_change_cipher_state() so they directly follow the change of cipher state in the record layer, which avoids having to duplicate the calls in the client and server. ok inoguchi@ tb@
* Clean up and harden TLSv1.2 master key derivation.jsing2021-04-301-3/+3
| | | | | | | | | | | The master key and its length are only stored in one location, so it makes no sense to handle these outside of the derivation function (the current 'out' argument is unused). This simplifies the various call sites. If derivation fails for some reason, fail hard rather than continuing on and hoping that something deals with this correctly later. ok inoguchi@ tb@
* Clean up derivation of finished/peer finished.jsing2021-04-251-3/+10
| | | | | | | | Make this process more readable by having specific client/server functions, calling the correct one based on s->server. This allows to remove various SSL_ST_ACCEPT/SSL_ST_CONNECT checks, along with duplicate code. ok inoguchi@ tb@
* Clean up TLSv1.2 certificate request handshake data.jsing2021-04-211-9/+5
| | | | | | | | | | Currently cert_req is used by clients and cert_request is used by servers. Replace this by a single cert_request used by either client or server. Remove the certificate types as they are currently unused. This also fixes a bug whereby if the number of certificate types exceeds SSL3_CT_NUMBER the number of bytes read in is insufficient, which will break decoding. ok inoguchi@ tb@
* Remove new_sym_enc and new_aead.jsing2021-04-191-4/+3
| | | | | | | These can be replaced with accessors that allow this information to be retrieved from the new record layer. ok inoguchi@ tb@
* Move new_mac_secret_size into the TLSv1.2 handshake struct.jsing2021-04-191-2/+4
| | | | | | Drop the 'new_' prefix in the process. ok inoguchi@ tb@
* Move reuse_message, message_type, message_size and cert_verify into thejsing2021-04-191-8/+11
| | | | | | TLSv1.2 handshake struct. ok inoguchi@ tb@
* Move finished and peer finished to the handshake struct.jsing2021-03-291-6/+10
| | | | | | | | | This moves the finish_md and peer_finish_md from the 'tmp' struct to the handshake struct, renaming to finished and peer_finished in the process. This also allows the remaining S3I(s) references to be removed from the TLSv1.3 client and server. ok inoguchi@ tb@
* Move the TLSv1.2 record number increment into the new record layer.jsing2021-03-291-2/+1
| | | | | | | This adds checks (based on the TLSv1.3 implementation) to ensure that the TLS/DTLS sequence numbers do not wrap, as required by the respective RFCs. ok inoguchi@ tb@
* Garbage collect s->internal->typetb2021-03-271-3/+1
| | | | | | | | | | | | | | | | | | | This variable is used in the legacy stack to decide whether we are a server or a client. That's what s->server is for... The new TLSv1.3 stack failed to set s->internal->type, which resulted in hilarious mishandling of previous_{client,server}_finished. Indeed, both client and server would first store the client's verify_data in previous_server_finished and later overwrite it with the server's verify_data. Consequently, renegotiation has been completely broken for more than a year. In fact, server side renegotiation was broken during the 6.5 release cycle. Clearly, no-one uses this. This commit fixes client side renegotiation and restores the previous behavior of SSL_get_client_CA_list(). Server side renegotiation will be fixed in a later commit. ok jsing
* Rename new_cipher to cipher.jsing2021-03-241-2/+2
| | | | | | | | This is in the SSL_HANDSHAKE struct and is what we're currently negotiating, so there is really nothing more "new" about the cipher than there is the key block or other parts of the handshake data. ok inoguchi@ tb@
* Add SSL_HANDSHAKE_TLS12 for TLSv1.2 specific handshake data.jsing2021-03-241-13/+20
| | | | | | Move TLSv1.2 specific components over from SSL_HANDSHAKE. ok inoguchi@ tb@
* Move the TLSv1.3 handshake struct inside the shared handshake struct.jsing2021-03-211-40/+41
| | | | | | | | | | | | | | | | There are currently three different handshake structs that are in use - the SSL_HANDSHAKE struct (as S3I(s)->hs), the SSL_HANDSHAKE_TLS13 struct (as S3I(s)->hs_tls13 or ctx->hs in the TLSv1.3 code) and the infamous 'tmp' embedded in SSL3_STATE_INTERNAL (as S3I(s)->tmp)). This is the first step towards cleaning up the handshake structs so that shared data is in the SSL_HANDSHAKE struct, with sub-structs for TLSv1.2 and TLSv1.3 specific information. Place SSL_HANDSHAKE_TLS13 inside SSL_HANDSHAKE and change ctx->hs to refer to the SSL_HANDSHAKE struct instead of the SSL_HANDSHAKE_TLS13 struct. This allows the TLSv1.3 code to access the shared handshake data without needing the SSL struct. ok inoguchi@ tb@
* Enable DTLSv1.2.jsing2021-03-171-1/+5
| | | | | | | | This means that the DTLS_method() will now use DTLSv1.2 rather than DTLSv1. Additional DTLSv1.2 related symbols and defines will be made publicly visible in the near future. ok inoguchi@ tb@
* Remove ssl_downgrade_max_version().jsing2021-03-111-2/+1
| | | | | | | Now that we store our maximum TLS version at the start of the handshake, we can check against that directly. ok inoguchi@ tb@
* Improve internal version handling.jsing2021-03-101-6/+20
| | | | | | | | | | | | | | | | | | Add handshake fields for our minimum TLS version, our maximum TLS version and the TLS version negotiated during the handshake. Initialise our min/max versions at the start of the handshake and leave these unchanged. The negotiated TLS version is set in the client once we receive the ServerHello and in the server at the point we select the highest shared version. Provide an ssl_effective_version() function that returns the negotiated TLS version if known, otherwise our maximum TLS version - this is effectively what is stored in s->version currently. Convert most of the internal code to use one of these three version fields, which greatly simplifies code (especially in the TLS extension handling code). ok tb@
* Move handling of cipher/hash based cipher suites into the new record layer.jsing2021-02-271-18/+8
| | | | ok tb@
* Only use TLS versions internally (rather than both TLS and DTLS versions).jsing2021-02-251-14/+14
| | | | | | | | | | | | | | DTLS protocol version numbers are the 1's compliment of human readable TLS version numbers, which means that newer versions decrease in value and there is no direct mapping between TLS protocol version numbers and DTLS protocol version numbers. Rather than having to deal with this internally, only use TLS versions internally and map between DTLS and TLS protocol versions when necessary. Rename functions and variables to use 'tls_version' when they contain a TLS version (and never a DTLS version). ok tb@
* Factor out/change some of the legacy client version handling code.jsing2021-02-221-2/+4
| | | | | | | This consolidates the version handling code and will make upcoming changes easier. ok tb@
* Return a min/max version of zero if set to zero.jsing2021-02-201-3/+17
| | | | | | | | | | OpenSSL's SSL{_CTX,}_get_{min,max}_proto_version() return a version of zero if the minimum or maximum has been set to zero (which means the minimum or maximum version supported by the method). Previously we returned the minimum or maximum version supported by the method, instead of zero. Match OpenSSL's behaviour by using shadow variables. Discussed with tb@
* Absorb ssl3_get_algorithm2() into ssl_get_handshake_evp_md().jsing2021-02-071-3/+1
| | | | | | | | The mess that is ssl_get_algorithm2() only exists to upgrade the handshake MAC of a pre-TLSv1.2 cipher suite to SHA256 when used with TLSv1.2. We can readily do this in ssl_get_handshake_evp_md(), which is far more readable. ok tb@
* Factor out the legacy stack version checks.jsing2021-02-071-1/+2
| | | | | | | Also check for explicit version numbers, rather than just the major version value. ok tb@
* Move AEAD handling into the new TLSv1.2 record layer.jsing2021-01-281-9/+3
| | | | ok tb@
* Move sequence numbers into the new TLSv1.2 record layer.jsing2021-01-261-11/+2
| | | | | | | This allows for all of the DTLS sequence number save/restore code to be removed. ok inoguchi@ "whee!" tb@
* Mop up unused dtls1_build_sequence_number() function.jsing2021-01-211-3/+1
|
* Add code to handle change of cipher state in the new TLSv1.2 record layer.jsing2021-01-191-1/+11
| | | | | | | | | | This provides the basic framework for handling change of cipher state in the new TLSv1.2 record layer, creating new record protection. In the DTLS case we retain the previous write record protection and can switch back to it when retransmitting. This will allow the record layer to start owning sequence numbers and encryption/decryption state. ok inoguchi@ tb@
* Provide functions to determine if TLSv1.2 record protection is engaged.jsing2021-01-191-1/+3
| | | | | | | | | | Call these functions from code that needs to know if we've changed cipher state and enabled record protection, rather than inconsistently checking various pointers from other places in the code base. This also fixes a minor bug where the wrong pointers are checked if we're operating with AEAD. ok inoguchi@ tb@
* Provide record layer overhead for DTLS.jsing2021-01-191-1/+3
| | | | | | | | Rather than manually calculating the maximum record layer overhead in the DTLS code, have the record layer provide this information. This also makes it work correctly with AEAD ciphersuites. ok inoguchi@ tb@
* Clean up sequence number handing in the new TLSv1.2 record layer.jsing2021-01-131-3/+1
| | | | | | | | | | | | Handle protocol specific (DTLS vs TLS) sequence number differences in the open/seal record functions and propagate the sequence number through to the called functions. This means that DTLS specific knowledge is limited to two functions and also avoids building sequence numbers multiple times over. As a result, the DTLS explicit sequence number is now extracted from the record header and passed through for processing, which makes the read epoch handling redundant. ok inoguchi@ tb@
* Move the read MAC key into the TLSv1.2 record layer.jsing2021-01-071-3/+1
| | | | ok inoguchi@ tb@
* 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)
* 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
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-04-10 06:14:01 +0000