summaryrefslogtreecommitdiff
path: root/src/lib/libssl/ssl_versions.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Disable TLS 1.0 and TLS 1.1 in libsslbeck2023-07-021-10/+2
| | | | | | | | | | | | Their time has long since past, and they should not be used. This change restricts ssl to versions 1.2 and 1.3, and changes the regression tests to understand we no longer speak the legacy protocols. For the moment the magical "golden" byte for byte comparison tests of raw handshake values are disabled util jsing fixes them. ok jsing@ tb@
* Make internal header file names consistenttb2022-11-261-2/+2
| | | | | | | | | | | | | | | | Libcrypto currently has a mess of *_lcl.h, *_locl.h, and *_local.h names used for internal headers. Move all these headers we inherited from OpenSSL to *_local.h, reserving the name *_internal.h for our own code. Similarly, move dtls_locl.h and ssl_locl.h to dtls_local and ssl_local.h. constant_time_locl.h is moved to constant_time.h since it's special. Adjust all .c files in libcrypto, libssl and regress. The diff is mechanical with the exception of tls13_quic.c, where #include <ssl_locl.h> was fixed manually. discussed with jsing, no objection bcook
* Get rid of SSL_CTX_INTERNAL and SSL_INTERNAL.jsing2022-10-021-5/+5
| | | | | | | | These are no longer necessary due to SSL_CTX and SSL now being fully opaque. Merge SSL_CTX_INTERNAL back into SSL_CTX and SSL_INTERNAL back into SSL. Prompted by tb@
* Enforce the minimum TLS version requirement for QUIC.jsing2022-09-111-1/+9
| | | | ok tb@
* Add checks to ensure we do not initiate or negotiate handshakes withtb2022-06-301-3/+9
| | | | | | versions below the minimum required by the security level. input & ok jsing
* Bye bye S3I.jsing2022-02-051-5/+5
| | | | | | | | S3I has served us well, however now that libssl is fully opaque it is time to say goodbye. Aside from removing the calloc/free/memset, the rest is mechanical sed. ok inoguchi@ tb@
* Provide a way to determine our maximum legacy version.jsing2021-10-231-1/+19
| | | | | | | | | | | | | | With the introduction of TLSv1.3, we need the ability to determine our maximum legacy version and to track our peer's maximum legacy version. This is needed for both the TLS record layer when using TLSv1.3, plus it is needed for RSA key exhange in TLS prior to TLSv1.3, where the maximum legacy version is incorporated in the pre-master secret to avoid downgrade attacks. This unbreaks RSA KEX for the TLS client when the non-version specific method is used with TLSv1.0 or TLSv1.1 (clearly no one does this). ok tb@
* Merge SSL_METHOD_INTERNAL into SSL_METHOD.jsing2021-07-011-11/+10
| | | | | | | 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@
* 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.
* Undo previous. As pointed out by jsing I clearly wasn't fully awake...tb2021-03-191-2/+2
|
* fix whitespace nit in previoustb2021-03-171-2/+2
|
* Add support for DTLSv1.2 version handling.jsing2021-03-171-45/+117
| | | | | | | | This teaches the version functions that handle protocol versions about DTLSv1.2 and the SSL_OP_NO_DTLS* options. We effectively convert between TLS and TLS protocol versions where necessary. ok inoguchi@ tb@
* Remove ssl_downgrade_max_version().jsing2021-03-111-33/+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-1/+25
| | | | | | | | | | | | | | | | | | 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@
* Only use TLS versions internally (rather than both TLS and DTLS versions).jsing2021-02-251-42/+56
| | | | | | | | | | | | | | 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-1/+28
| | | | | | | 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-5/+7
| | | | | | | | | | 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@
* Handle DTLS1_2_VERSION in various places.jsing2021-02-201-2/+2
| | | | ok tb@
* Factor out the legacy stack version checks.jsing2021-02-071-1/+11
| | | | | | | Also check for explicit version numbers, rather than just the major version value. ok tb@
* whitespacetb2021-01-041-3/+3
|
* Replace SSL_IS_DTLS with SSL_is_dtls().jsing2020-10-141-4/+4
| | | | | | Garbage collect the now unused SSL_IS_DTLS macro. ok tb@
* Replace ssl_max_server_version() with ssl_downgrade_max_version()jsing2020-05-311-25/+1
| | | | | | | Replace the only occurrence of ssl_max_server_version() with a call to ssl_downgrade_max_version() and remove ssl_max_server_version(). ok beck@ tb@
* Correct downgrade sentinels when a version pinned method is in use.jsing2020-05-311-1/+33
| | | | | | | | | Previously only the enabled protocol versions were considered, however we also have to consider the method in use which may be version pinned. Found the hard way by danj@ with haproxy and force-tlsv12. ok beck@ inoguchi@ tb@
* Include TLSv1.3 in version handling code.jsing2018-11-061-3/+9
| | | | | | | This is effectively a no-op, since most of the code clamps to the maximum version supported by the TLS method (which are still at TLSv1.2). ok beck@ bluhm@ tb@
* Provide SSL{,_CTX}_set_{min,max}_proto_version() functions.jsing2017-05-061-1/+47
| | | | | | Rides minor bump. ok beck@
* Add missing $OpenBSD$ tags.jsing2017-05-061-0/+1
|
* Move relatively new version range code from ssl_lib.c into a separatejsing2017-01-261-0/+172
ssl_versions.c file. ok beck@