upstream/haproxy
1
0
Fork 0
mirror of https://github.com/haproxy/haproxy.git synced 2026-04-23 07:08:06 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 3
haproxy/src/ssl_sock.c

7753 lines
229 KiB
C
Raw Normal View History

MEDIUM: ssl: Added support for creating SSL_CTX with multiple certs Added ability for users to specify multiple certificates that all relate a single server. Users do this by specifying certificate "cert_name.pem" but having "cert_name.pem.rsa", "cert_name.pem.dsa" and/or "cert_name.pem.ecdsa" in the directory. HAProxy will now intelligently search for those 3 files and try combine them into as few SSL_CTX's as possible based on CN/SAN. This will allow HAProxy to support multiple ciphersuite key algorithms off a single SSL_CTX. This change integrates into the existing architecture of SNI lookup and multiple SNI's can point to the same SSL_CTX, which can support multiple key_types.
2015-12-02 13:01:29 -05:00
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
/*
REORG: connection: rename the data layer the "transport layer" While working on the changes required to make the health checks use the new connections, it started to become obvious that some naming was not logical at all in the connections. Specifically, it is not logical to call the "data layer" the layer which is in charge for all the handshake and which does not yet provide a data layer once established until a session has allocated all the required buffers. In fact, it's more a transport layer, which makes much more sense. The transport layer offers a medium on which data can transit, and it offers the functions to move these data when the upper layer requests this. And it is the upper layer which iterates over the transport layer's functions to move data which should be called the data layer. The use case where it's obvious is with embryonic sessions : an incoming SSL connection is accepted. Only the connection is allocated, not the buffers nor stream interface, etc... The connection handles the SSL handshake by itself. Once this handshake is complete, we can't use the data functions because the buffers and stream interface are not there yet. Hence we have to first call a specific function to complete the session initialization, after which we'll be able to use the data functions. This clearly proves that SSL here is only a transport layer and that the stream interface constitutes the data layer. A similar change will be performed to rename app_cb => data, but the two could not be in the same commit for obvious reasons.
2012-10-02 18:19:48 -04:00
* SSL/TLS transport layer over SOCK_STREAM sockets
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
*
* Copyright (C) 2012 EXCELIANCE, Emeric Brun <ebrun@exceliance.fr>
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*
DOC: add a special acknowledgement for the stud project Really, the quality of their code deserves it, it would have been much harder to figure how to get all the things right at once without looking there from time to time !
2012-09-10 03:43:09 -04:00
* Acknowledgement:
* We'd like to specially thank the Stud project authors for a very clean
* and well documented code which helped us understand how the OpenSSL API
* ought to be used in non-blocking mode. This is one difficult part which
* is not easy to get from the OpenSSL doc, and reading the Stud code made
* it much more obvious than the examples in the OpenSSL package. Keep up
* the good works, guys !
*
* Stud is an extremely efficient and scalable SSL/TLS proxy which combines
* particularly well with haproxy. For more info about this project, visit :
* https://github.com/bumptech/stud
*
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
*/
CLEANUP: ssl: never include openssl/*.h outside of openssl-compat.h anymore Since we're providing a compatibility layer for multiple OpenSSL implementations and their derivatives, it is important that no C file directly includes openssl headers but only passes via openssl-compat instead. As a bonus this also gets rid of redundant complex rules for inclusion of certain files (engines etc).
2019-05-10 03:35:00 -04:00
/* Note: do NOT include openssl/xxx.h here, do it in openssl-compat.h */
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
#define _GNU_SOURCE
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
#include <ctype.h>
#include <dirent.h>
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
#include <string.h>
#include <unistd.h>
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
#include <sys/socket.h>
#include <sys/stat.h>
#include <sys/types.h>
MEDIUM: ssl: Add options to forge SSL certificates With this patch, it is possible to configure HAProxy to forge the SSL certificate sent to a client using the SNI servername. We do it in the SNI callback. To enable this feature, you must pass following BIND options: * ca-sign-file <FILE> : This is the PEM file containing the CA certitifacte and the CA private key to create and sign server's certificates. * (optionally) ca-sign-pass <PASS>: This is the CA private key passphrase, if any. * generate-certificates: Enable the dynamic generation of certificates for a listener. Because generating certificates is expensive, there is a LRU cache to store them. Its size can be customized by setting the global parameter 'tune.ssl.ssl-ctx-cache-size'.
2015-06-09 11:29:50 -04:00
#include <netdb.h>
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
#include <netinet/tcp.h>
CLEANUP: include: tree-wide alphabetical sort of include files This patch fixes all the leftovers from the include cleanup campaign. There were not that many (~400 entries in ~150 files) but it was definitely worth doing it as it revealed a few duplicates.
2020-06-09 03:07:15 -04:00
#include <import/ebpttree.h>
#include <import/ebsttree.h>
MEDIUM: ssl: Add options to forge SSL certificates With this patch, it is possible to configure HAProxy to forge the SSL certificate sent to a client using the SNI servername. We do it in the SNI callback. To enable this feature, you must pass following BIND options: * ca-sign-file <FILE> : This is the PEM file containing the CA certitifacte and the CA private key to create and sign server's certificates. * (optionally) ca-sign-pass <PASS>: This is the CA private key passphrase, if any. * generate-certificates: Enable the dynamic generation of certificates for a listener. Because generating certificates is expensive, there is a LRU cache to store them. Its size can be customized by setting the global parameter 'tune.ssl.ssl-ctx-cache-size'.
2015-06-09 11:29:50 -04:00
#include <import/lru.h>
CLEANUP: include: tree-wide alphabetical sort of include files This patch fixes all the leftovers from the include cleanup campaign. There were not that many (~400 entries in ~150 files) but it was definitely worth doing it as it revealed a few duplicates.
2020-06-09 03:07:15 -04:00
#include <haproxy/api.h>
CLEANUP: ssl/cli: stop using ctx.cli.i0/i1/p0 for "show tls-keys" This creates a local context of type show_keys_ctx which contains the equivalent fields with more natural names.
2022-05-05 02:50:17 -04:00
#include <haproxy/applet.h>
CLEANUP: include: tree-wide alphabetical sort of include files This patch fixes all the leftovers from the include cleanup campaign. There were not that many (~400 entries in ~150 files) but it was definitely worth doing it as it revealed a few duplicates.
2020-06-09 03:07:15 -04:00
#include <haproxy/arg.h>
#include <haproxy/base64.h>
REORG: include: move channel.h to haproxy/channel{,-t}.h The files were moved with no change. The callers were cleaned up a bit and a few of them had channel.h removed since not needed.
2020-06-04 15:07:02 -04:00
#include <haproxy/channel.h>
REORG: include: move common/chunk.h to haproxy/chunk.h No change was necessary, it was already properly split.
2020-06-02 04:22:45 -04:00
#include <haproxy/chunk.h>
REORG: include: move cli.h to haproxy/cli{,-t}.h Almost no change except moving the cli_kw struct definition after the defines. Almost all users had both types&proto included, which is not surprizing since this code is old and it used to be the norm a decade ago. These places were cleaned.
2020-06-04 14:19:54 -04:00
#include <haproxy/cli.h>
REORG: include: move connection.h to haproxy/connection{,-t}.h The type file is becoming a mess, half of it is for the proxy protocol, another good part describes conn_streams and mux ops, it would deserve being split again. At least it was reordered so that elements are easier to find, with the PP-stuff left at the end. The MAX_SEND_FD macro was moved to compat.h as it's said to be the value for Linux.
2020-06-04 12:02:10 -04:00
#include <haproxy/connection.h>
CLEANUP: include: tree-wide alphabetical sort of include files This patch fixes all the leftovers from the include cleanup campaign. There were not that many (~400 entries in ~150 files) but it was definitely worth doing it as it revealed a few duplicates.
2020-06-09 03:07:15 -04:00
#include <haproxy/dynbuf.h>
REORG: include: move base64.h, errors.h and hash.h from common to to haproxy/ These ones do not depend on any other file. One used to include haproxy/api.h but that was solely for stddef.h.
2020-05-27 10:10:29 -04:00
#include <haproxy/errors.h>
CLEANUP: include: tree-wide alphabetical sort of include files This patch fixes all the leftovers from the include cleanup campaign. There were not that many (~400 entries in ~150 files) but it was definitely worth doing it as it revealed a few duplicates.
2020-06-09 03:07:15 -04:00
#include <haproxy/fd.h>
#include <haproxy/freq_ctr.h>
REORG: include: move frontend.h to haproxy/frontend.h There was no type file for this one, it only contains frontend_accept().
2020-06-04 05:23:07 -04:00
#include <haproxy/frontend.h>
REORG: include: split global.h into haproxy/global{,-t}.h global.h was one of the messiest files, it has accumulated tons of implicit dependencies and declares many globals that make almost all other file include it. It managed to silence a dependency loop between server.h and proxy.h by being well placed to pre-define the required structs, forcing struct proxy and struct server to be forward-declared in a significant number of files. It was split in to, one which is the global struct definition and the few macros and flags, and the rest containing the functions prototypes. The UNIX_MAX_PATH definition was moved to compat.h.
2020-06-04 11:05:57 -04:00
#include <haproxy/global.h>
REORG: include: move http_rules.h to haproxy/http_rules.h There was no include file. This one still includes types/proxy.h.
2020-06-04 05:40:28 -04:00
#include <haproxy/http_rules.h>
REORG: include: move log.h to haproxy/log{,-t}.h The current state of the logging is a real mess. The main problem is that almost all files include log.h just in order to have access to the alert/warning functions like ha_alert() etc, and don't care about logs. But log.h also deals with real logging as well as log-format and depends on stream.h and various other things. As such it forces a few heavy files like stream.h to be loaded early and to hide missing dependencies depending where it's loaded. Among the missing ones is syslog.h which was often automatically included resulting in no less than 3 users missing it. Among 76 users, only 5 could be removed, and probably 70 don't need the full set of dependencies. A good approach would consist in splitting that file in 3 parts: - one for error output ("errors" ?). - one for log_format processing - and one for actual logging.
2020-06-04 16:01:04 -04:00
#include <haproxy/log.h>
REORG: include: move openssl-compat.h from common/ to haproxy/ This file is to openssl what compat.h is to the libc, so it makes sense to move it to haproxy/. It could almost be part of api.h but given the amount of openssl stuff that gets loaded I fear it could increase the build time. Note that this file contains lots of inlined functions. But since it does not depend on anything else in haproxy, it remains safe to keep all that together.
2020-05-27 10:26:00 -04:00
#include <haproxy/openssl-compat.h>
REORG: include: move pattern.h to haproxy/pattern{,-t}.h It was moved as-is, except for extern declaration of pattern_reference. A few C files used to include it but didn't need it anymore after having been split apart so this was cleaned.
2020-06-04 09:06:28 -04:00
#include <haproxy/pattern-t.h>
CLEANUP: include: tree-wide alphabetical sort of include files This patch fixes all the leftovers from the include cleanup campaign. There were not that many (~400 entries in ~150 files) but it was definitely worth doing it as it revealed a few duplicates.
2020-06-09 03:07:15 -04:00
#include <haproxy/proto_tcp.h>
REORG: include: move proxy.h to haproxy/proxy{,-t}.h This one is particularly difficult to split because it provides all the functions used to manipulate a proxy state and to retrieve names or IDs for error reporting, and as such, it was included in 73 files (down to 68 after cleanup). It would deserve a small cleanup though the cut points are not obvious at the moment given the number of structs involved in the struct proxy itself.
2020-06-04 16:29:18 -04:00
#include <haproxy/proxy.h>
CLEANUP: quic: create a dedicated quic_conn module xprt_quic module was too large and did not reflect the true architecture by contrast to the other protocols in haproxy. Extract code related to XPRT layer and keep it under xprt_quic module. This code should only contains a simple API to communicate between QUIC lower layer and connection/MUX. The vast majority of the code has been moved into a new module named quic_conn. This module is responsible to the implementation of QUIC lower layer. Conceptually, it overlaps with TCP kernel implementation when comparing QUIC and HTTP1/2 stacks of haproxy. This should be backported up to 2.6.
2022-09-30 12:11:13 -04:00
#include <haproxy/quic_conn.h>
BUG/MINOR: quic: Missing call to TLS message callbacks This bug impacts only the QUIC OpenSSL compatibility module (USE_QUIC_OPENSSL_COMPAT). The TLS capture of information from client hello enabled by tune.ssl.capture-buffer-size could not work with USE_QUIC_OPENSSL_COMPAT. This is due to the fact the callback set for this feature was replaced by quic_tls_compat_msg_callback(). In fact this called must be registered by ssl_sock_register_msg_callback() as this done for the TLS client hello capture. A call to this function appends the function passed as parameter to a list of callbacks to be called when the TLS stack parse a TLS message. quic_tls_compat_msg_callback() had to be modified to return if it is called for a non-QUIC TLS session. Must be backported to 2.8.
2023-12-21 10:11:35 -05:00
#include <haproxy/quic_openssl_compat.h>
MINOR: quic: QUIC transport parameters split. Make the transport parameters be standlone as much as possible as it consists only in encoding/decoding data into/from buffers. Reduce the size of xprt_quic.h. Unfortunalety, I think we will have to continue to include <xprt_quic-t.h> to use the trace API into this module.
2022-05-21 17:58:40 -04:00
#include <haproxy/quic_tp.h>
BUG/MINOR: quic: Missing call to TLS message callbacks This bug impacts only the QUIC OpenSSL compatibility module (USE_QUIC_OPENSSL_COMPAT). The TLS capture of information from client hello enabled by tune.ssl.capture-buffer-size could not work with USE_QUIC_OPENSSL_COMPAT. This is due to the fact the callback set for this feature was replaced by quic_tls_compat_msg_callback(). In fact this called must be registered by ssl_sock_register_msg_callback() as this done for the TLS client hello capture. A call to this function appends the function passed as parameter to a list of callbacks to be called when the TLS stack parse a TLS message. quic_tls_compat_msg_callback() had to be modified to return if it is called for a non-QUIC TLS session. Must be backported to 2.8.
2023-12-21 10:11:35 -05:00
#include <haproxy/sample.h>
#include <haproxy/sc_strm.h>
REORG: include: move server.h to haproxy/server{,-t}.h extern struct dict server_name_dict was moved from the type file to the main file. A handful of inlined functions were moved at the bottom of the file. Call places were updated to use server-t.h when relevant, or to simply drop the entry when not needed.
2020-06-04 17:20:13 -04:00
#include <haproxy/server.h>
REORG: include: move shctx to haproxy/shctx{,-t}.h Minor cleanups were applied, some includes were missing from the types file and some were incorrect in a few C files (duplicated or not using path).
2020-06-03 12:38:48 -04:00
#include <haproxy/shctx.h>
REORG: include: move ssl_ckch.h to haproxy/ssl_ckch{,-t}.h buf-t and ebmbtree were included.
2020-06-04 08:25:47 -04:00
#include <haproxy/ssl_ckch.h>
REORG: move ssl_crtlist.h to haproxy/ssl_crtlist{,-t}.h These files were already clean as well. Just added ebptnode which is needed in crtlist_entry.
2020-06-04 08:29:23 -04:00
#include <haproxy/ssl_crtlist.h>
REORG: ssl: move 'generate-certificates' code to ssl_gencert.c A lot of code specific to the 'generate-certificates' option was left in ssl_sock.c. Move the code to 'ssl_gencert.c' and 'ssl_gencert.h'
2024-01-12 09:23:49 -05:00
#include <haproxy/ssl_gencert.h>
REORG: include: move ssl_sock.h to haproxy/ssl_sock{,-t}.h Almost nothing changed, just moved a static inline at the end and moved an export from the types to the main file.
2020-06-04 14:30:20 -04:00
#include <haproxy/ssl_sock.h>
REORG: include: move ssl_utils.h to haproxy/ssl_utils.h Just added buf-t and openssl-compat for the missing types that appear in the prototypes.
2020-06-04 08:21:22 -04:00
#include <haproxy/ssl_utils.h>
MINOR: ssl: instantiate stats module This module is responsible for providing statistics for ssl. It allocates counters for frontend/backend/listener/server objects.
2020-11-03 11:10:00 -05:00
#include <haproxy/stats.h>
REORG: stconn: rename conn_stream.{c,h} to stconn.{c,h} There's no more reason for keepin the code and definitions in conn_stream, let's move all that to stconn. The alphabetical ordering of include files was adjusted.
2022-05-27 03:47:12 -04:00
#include <haproxy/stconn.h>
REORG: include: move stream.h to haproxy/stream{,-t}.h This one was not easy because it was embarking many includes with it, which other files would automatically find. At least global.h, arg.h and tools.h were identified. 93 total locations were identified, 8 additional includes had to be added. In the rare files where it was possible to finalize the sorting of includes by adjusting only one or two extra lines, it was done. But all files would need to be rechecked and cleaned up now. It was the last set of files in types/ and proto/ and these directories must not be reused anymore.
2020-06-04 17:46:14 -04:00
#include <haproxy/stream-t.h>
REORG: include: move task.h to haproxy/task{,-t}.h The TASK_IS_TASKLET() macro was moved to the proto file instead of the type one. The proto part was a bit reordered to remove a number of ugly forward declaration of static inline functions. About a tens of C and H files had their dependency dropped since they were not using anything from task.h.
2020-06-04 11:25:40 -04:00
#include <haproxy/task.h>
REORG: include: move common/ticks.h to haproxy/ticks.h Nothing needed to be changed, there are no exported types.
2020-06-02 12:15:32 -04:00
#include <haproxy/ticks.h>
REORG: include: move time.h from common/ to haproxy/ This one is included almost everywhere and used to rely on a few other .h that are not needed (unistd, stdlib, standard.h). It could possibly make sense to split it into multiple parts to distinguish operations performed on timers and the internal time accounting, but at this point it does not appear much important.
2020-06-01 05:05:15 -04:00
#include <haproxy/time.h>
CLEANUP: include: tree-wide alphabetical sort of include files This patch fixes all the leftovers from the include cleanup campaign. There were not that many (~400 entries in ~150 files) but it was definitely worth doing it as it revealed a few duplicates.
2020-06-09 03:07:15 -04:00
#include <haproxy/tools.h>
REORG: include: move vars.h to haproxy/vars{,-t}.h A few includes (sessions.h, stream.h, api-t.h) were added for arguments that were first declared in function prototypes.
2020-06-04 10:25:31 -04:00
#include <haproxy/vars.h>
CLEANUP: Add haproxy/xxhash.h to avoid modifying import/xxhash.h This solves setting XXH_INLINE_ALL in a cleaner way, because the imported header is not modified, easing future updates. see 6f7cc11e6dd0f01b437fba893da2edd2362660a2
2021-09-11 11:51:13 -04:00
#include <haproxy/xxhash.h>
BUG/MINOR: ssl: Remove empty lines from "show ssl ocsp-response <id>" output There were empty lines in the output of the CLI's "show ssl ocsp-response <id>" command. The plain "show ssl ocsp-response" command (without parameter) was already managed in commit cc750efbc5c2180ed63b222a51029609ea96d0f7. This patch adds an extra space to those lines so that the only existing empty lines actually mark the end of the output. This requires to post-process the buffer filled by OpenSSL's OCSP_RESPONSE_print function (which produces the output of the "openssl ocsp -respin <ocsp.pem>" command). This way the output of our command still looks the same as openssl's one. Must be backported in 2.5.
2022-01-11 04:11:10 -05:00
#include <haproxy/istbuf.h>
MINOR: ssl: Move OCSP code to a dedicated source file This is a simple cleanup that moves OCSP related code to a dedicated file instead of interlacing it in some pure ssl connection code.
2022-12-20 05:11:17 -05:00
#include <haproxy/ssl_ocsp.h>
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
REORG: ssl: move some OpenSSL defines from ssl_sock to openssl-compat Some defines like OPENSSL_VERSION or X509_getm_notBefore() have nothing to do in ssl_sock and must move to openssl-compat.h so that they are consistently shared by the whole code. A warning in the code was added against wild additions of macros there.
2019-05-10 03:22:53 -04:00
/* ***** READ THIS before adding code here! *****
*
* Due to API incompatibilities between multiple OpenSSL versions and their
* derivatives, it's often tempting to add macros to (re-)define certain
* symbols. Please do not do this here, and do it in common/openssl-compat.h
* exclusively so that the whole code consistently uses the same macros.
*
* Whenever possible if a macro is missing in certain versions, it's better
* to conditionally define it in openssl-compat.h than using lots of ifdefs.
*/
BUG/MEDIUM: ssl engines: Fix async engines fds were not considered to fix fd limit automatically. The number of async fd is computed considering the maxconn, the number of sides using ssl and the number of engines using async mode. This patch should be backported on haproxy 1.8
2017-12-06 07:51:49 -05:00
int nb_engines = 0;
MEDIUM: ssl: protect against client-initiated renegociation CVE-2009-3555 suggests that client-initiated renegociation should be prevented in the middle of data. The workaround here consists in having the SSL layer notify our callback about a handshake occurring, which in turn causes the connection to be marked in the error state if it was already considered established (which means if a previous handshake was completed). The result is that the connection with the client is immediately aborted and any pending data are dropped.
2012-09-03 14:36:47 -04:00
CLEANUP: ssl: move issuer_chain tree and definition Move the cert_issuer_tree outside the global_ssl structure since it's not a configuration variable. And move the declaration of the issuer_chain structure in types/ssl_sock.h
2020-02-25 08:53:06 -05:00
static struct eb_root cert_issuer_tree = EB_ROOT; /* issuers tree from "issuers-chain-path" */
REORG: ssl: move macros and structure definitions to ssl_sock.h The ssl_sock.c file contains a lot of macros and structure definitions that should be in a .h. Move them to the more appropriate types/ssl_sock.h file.
2020-05-07 09:20:43 -04:00
struct global_ssl global_ssl = {
CLEANUP: ssl: move most ssl-specific global settings to ssl_sock.c Historically a lot of SSL global settings were stored into the global struct, but we've reached a point where there are 3 ifdefs in it just for this, and others in haproxy.c to initialize it. This patch moves all the private fields to a new struct "global_ssl" stored in ssl_sock.c. This includes : char *crt_base; char *ca_base; char *listen_default_ciphers; char *connect_default_ciphers; int listen_default_ssloptions; int connect_default_ssloptions; int tune.sslprivatecache; /* Force to use a private session cache even if nbproc > 1 */ unsigned int tune.ssllifetime; /* SSL session lifetime in seconds */ unsigned int tune.ssl_max_record; /* SSL max record size */ unsigned int tune.ssl_default_dh_param; /* SSL maximum DH parameter size */ int tune.ssl_ctx_cache; /* max number of entries in the ssl_ctx cache. */ The "tune" part was removed (useless here) and the occasional "ssl" prefixes were removed as well. Thus for example instead of global.tune.ssl_default_dh_param we now have : global_ssl.default_dh_param A few initializers were present in the constructor, they could be brought back to the structure declaration. A few other entries had to stay in global for now. They concern memory calculationn (used in haproxy.c) and stats (used in stats.c). The code is already much cleaner now, especially for global.h and haproxy.c which become readable.
2016-12-22 17:12:01 -05:00
#ifdef LISTEN_DEFAULT_CIPHERS
.listen_default_ciphers = LISTEN_DEFAULT_CIPHERS,
#endif
#ifdef CONNECT_DEFAULT_CIPHERS
.connect_default_ciphers = CONNECT_DEFAULT_CIPHERS,
MEDIUM: ssl: add support for ciphersuites option for TLSv1.3 OpenSSL released support for TLSv1.3. It also added a separate function SSL_CTX_set_ciphersuites that is used to set the ciphers used in the TLS 1.3 handshake. This change adds support for that new configuration option by adding a ciphersuites configuration variable that works essentially the same as the existing ciphers setting. Note that it should likely be backported to 1.8 in order to ease usage of the now released openssl-1.1.1.
2018-09-14 05:14:21 -04:00
#endif
BUILD: SSL: guard TLS13 ciphersuites with HAVE_SSL_CTX_SET_CIPHERSUITES HAVE_SSL_CTX_SET_CIPHERSUITES is newly defined macro set in openssl-compat.h, which helps to identify ssl libs (currently OpenSSL-1.1.1 only) that supports TLS13 cipersuites manipulation on TLS13 context
2020-11-21 04:37:34 -05:00
#ifdef HAVE_SSL_CTX_SET_CIPHERSUITES
MEDIUM: ssl: add support for ciphersuites option for TLSv1.3 OpenSSL released support for TLSv1.3. It also added a separate function SSL_CTX_set_ciphersuites that is used to set the ciphers used in the TLS 1.3 handshake. This change adds support for that new configuration option by adding a ciphersuites configuration variable that works essentially the same as the existing ciphers setting. Note that it should likely be backported to 1.8 in order to ease usage of the now released openssl-1.1.1.
2018-09-14 05:14:21 -04:00
.listen_default_ciphersuites = LISTEN_DEFAULT_CIPHERSUITES,
.connect_default_ciphersuites = CONNECT_DEFAULT_CIPHERSUITES,
CLEANUP: ssl: move most ssl-specific global settings to ssl_sock.c Historically a lot of SSL global settings were stored into the global struct, but we've reached a point where there are 3 ifdefs in it just for this, and others in haproxy.c to initialize it. This patch moves all the private fields to a new struct "global_ssl" stored in ssl_sock.c. This includes : char *crt_base; char *ca_base; char *listen_default_ciphers; char *connect_default_ciphers; int listen_default_ssloptions; int connect_default_ssloptions; int tune.sslprivatecache; /* Force to use a private session cache even if nbproc > 1 */ unsigned int tune.ssllifetime; /* SSL session lifetime in seconds */ unsigned int tune.ssl_max_record; /* SSL max record size */ unsigned int tune.ssl_default_dh_param; /* SSL maximum DH parameter size */ int tune.ssl_ctx_cache; /* max number of entries in the ssl_ctx cache. */ The "tune" part was removed (useless here) and the occasional "ssl" prefixes were removed as well. Thus for example instead of global.tune.ssl_default_dh_param we now have : global_ssl.default_dh_param A few initializers were present in the constructor, they could be brought back to the structure declaration. A few other entries had to stay in global for now. They concern memory calculationn (used in haproxy.c) and stats (used in stats.c). The code is already much cleaner now, especially for global.h and haproxy.c which become readable.
2016-12-22 17:12:01 -05:00
#endif
.listen_default_ssloptions = BC_SSL_O_NONE,
.connect_default_ssloptions = SRV_SSL_O_NONE,
MEDIUM: ssl: ssl_methods implementation is reworked and factored for min/max tlsxx Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. This patch introduce internal min/max and replace force-tlsxx implementation. SSL method configuration is store in 'struct tls_version_filter'. SSL method configuration to openssl setting is abstract in 'methodVersions' table. With openssl < 1.1.0, SSL_CTX_set_ssl_version is used for force (min == max). With openssl >= 1.1.0, SSL_CTX_set_min/max_proto_version is used.
2017-03-30 13:19:37 -04:00
.listen_default_sslmethods.flags = MC_SSL_O_ALL,
.listen_default_sslmethods.min = CONF_TLSV_NONE,
.listen_default_sslmethods.max = CONF_TLSV_NONE,
.connect_default_sslmethods.flags = MC_SSL_O_ALL,
.connect_default_sslmethods.min = CONF_TLSV_NONE,
.connect_default_sslmethods.max = CONF_TLSV_NONE,
CLEANUP: ssl: move most ssl-specific global settings to ssl_sock.c Historically a lot of SSL global settings were stored into the global struct, but we've reached a point where there are 3 ifdefs in it just for this, and others in haproxy.c to initialize it. This patch moves all the private fields to a new struct "global_ssl" stored in ssl_sock.c. This includes : char *crt_base; char *ca_base; char *listen_default_ciphers; char *connect_default_ciphers; int listen_default_ssloptions; int connect_default_ssloptions; int tune.sslprivatecache; /* Force to use a private session cache even if nbproc > 1 */ unsigned int tune.ssllifetime; /* SSL session lifetime in seconds */ unsigned int tune.ssl_max_record; /* SSL max record size */ unsigned int tune.ssl_default_dh_param; /* SSL maximum DH parameter size */ int tune.ssl_ctx_cache; /* max number of entries in the ssl_ctx cache. */ The "tune" part was removed (useless here) and the occasional "ssl" prefixes were removed as well. Thus for example instead of global.tune.ssl_default_dh_param we now have : global_ssl.default_dh_param A few initializers were present in the constructor, they could be brought back to the structure declaration. A few other entries had to stay in global for now. They concern memory calculationn (used in haproxy.c) and stats (used in stats.c). The code is already much cleaner now, especially for global.h and haproxy.c which become readable.
2016-12-22 17:12:01 -05:00
#ifdef DEFAULT_SSL_MAX_RECORD
.max_record = DEFAULT_SSL_MAX_RECORD,
#endif
MINOR: ssl: add a new global option "tune.ssl.hard-maxrecord" Low footprint client machines may not have enough memory to download a complete 16KB TLS record at once. With the new option the maximum record size can be defined on the server side. Note: Before limiting the the record size on the server side, a client should consider using the TLS Maximum Fragment Length Negotiation Extension defined in RFC6066. This patch fixes GitHub issue #1679.
2022-04-27 07:04:54 -04:00
.hard_max_record = 0,
CLEANUP: ssl: move most ssl-specific global settings to ssl_sock.c Historically a lot of SSL global settings were stored into the global struct, but we've reached a point where there are 3 ifdefs in it just for this, and others in haproxy.c to initialize it. This patch moves all the private fields to a new struct "global_ssl" stored in ssl_sock.c. This includes : char *crt_base; char *ca_base; char *listen_default_ciphers; char *connect_default_ciphers; int listen_default_ssloptions; int connect_default_ssloptions; int tune.sslprivatecache; /* Force to use a private session cache even if nbproc > 1 */ unsigned int tune.ssllifetime; /* SSL session lifetime in seconds */ unsigned int tune.ssl_max_record; /* SSL max record size */ unsigned int tune.ssl_default_dh_param; /* SSL maximum DH parameter size */ int tune.ssl_ctx_cache; /* max number of entries in the ssl_ctx cache. */ The "tune" part was removed (useless here) and the occasional "ssl" prefixes were removed as well. Thus for example instead of global.tune.ssl_default_dh_param we now have : global_ssl.default_dh_param A few initializers were present in the constructor, they could be brought back to the structure declaration. A few other entries had to stay in global for now. They concern memory calculationn (used in haproxy.c) and stats (used in stats.c). The code is already much cleaner now, especially for global.h and haproxy.c which become readable.
2016-12-22 17:12:01 -05:00
.default_dh_param = SSL_DEFAULT_DH_PARAM,
.ctx_cache = DEFAULT_SSL_CTX_CACHE,
MEDIUM: config: Deprecate tune.ssl.capture-cipherlist-size Deprecate tune.ssl.capture-cipherlist-size in favor of tune.ssl.capture-buffer-size which better describes the purpose of the setting.
2021-07-13 13:04:24 -04:00
.capture_buffer_size = 0,
MINOR: ssl: ssl-load-extra-files configure loading of files This new setting in the global section alters the way HAProxy will look for unspecified files (.ocsp, .sctl, .issuer, bundles) during the loading of the SSL certificates. By default, HAProxy discovers automatically a lot of files not specified in the configuration, and you may want to disable this behavior if you want to optimize the startup time. This patch sets flags in global_ssl.extra_files and then check them before trying to load an extra file.
2020-02-03 11:15:52 -05:00
.extra_files = SSL_GF_ALL,
MINOR: ssl: 'ssl-load-extra-del-ext' removes the certificate extension In issue #785, users are reporting that it's not convenient to load a ".crt.key" when the configuration contains a ".crt". This option allows to remove the extension of the certificate before trying to load any extra SSL file (.key, .ocsp, .sctl, .issuer etc.) The patch changes a little bit the way ssl_sock_load_files_into_ckch() looks for the file.
2020-10-20 11:36:46 -04:00
.extra_files_noext = 0,
BUILD: make tune.ssl.keylog available again Since commit 04a5a44 ("BUILD: ssl: use HAVE_OPENSSL_KEYLOG instead of OpenSSL versions") the "tune.ssl.keylog" feature is broken because HAVE_OPENSSL_KEYLOG does not exist. Replace this by a HAVE_SSL_KEYLOG which is defined in openssl-compat.h. Also add an error when not built with the right openssl version. Must be backported as far as 2.3.
2021-06-09 10:46:12 -04:00
#ifdef HAVE_SSL_KEYLOG
MINOR: ssl: Add global options to modify ocsp update min/max delay The minimum and maximum delays between two automatic updates of a given OCSP response can now be set via global options. It allows to limit the update rate of OCSP responses for configurations that use many frontend certificates with the ocsp-update option set if the updates are deemed too costly.
2023-02-28 11:46:29 -05:00
.keylog = 0,
#endif
MEDIUM: ssl: allow to change the OpenSSL security level from global section The new "ssl-security-level" option allows one to change the OpenSSL security level without having to change the openssl.cnf global file of your distribution. This directives applies on every SSL_CTX context. People sometimes change their security level directly in the ciphers directive, however there are some cases when the security level change is not applied in the right order (for example when applying a DH param). Before this patch, it was to possible to trick by using a specific openssl.cnf file and start haproxy this way: OPENSSL_CONF=./openssl.cnf ./haproxy -f bug-2468.cfg Values for the security level can be found there: https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_security_level.html This was discussed in github issue #2468.
2024-03-12 11:22:34 -04:00
.security_level = -1,
MINOR: ssl: Add global options to modify ocsp update min/max delay The minimum and maximum delays between two automatic updates of a given OCSP response can now be set via global options. It allows to limit the update rate of OCSP responses for configurations that use many frontend certificates with the ocsp-update option set if the updates are deemed too costly.
2023-02-28 11:46:29 -05:00
#ifndef OPENSSL_NO_OCSP
.ocsp_update.delay_max = SSL_OCSP_UPDATE_DELAY_MAX,
.ocsp_update.delay_min = SSL_OCSP_UPDATE_DELAY_MIN,
MEDIUM: ssl: Add 'tune.ssl.ocsp-update.mode' global option This option can be used to set a default ocsp-update mode for all certificates of a given conf file. It allows to activate ocsp-update on certificates without the need to create separate crt-lists. It can still be superseded by the crt-list 'ocsp-update' option. It takes either "on" or "off" as value and defaults to "off". Since setting this new parameter to "on" would mean that we try to enable ocsp-update on any certificate, and also certificates that don't have an OCSP URI, the checks performed in ssl_sock_load_ocsp were softened. We don't systematically raise an error when trying to enable ocsp-update on a certificate that does not have an OCSP URI, be it via the global option or the crt-list one. We will still raise an error when a user tries to load a certificate that does have an OCSP URI but a missing issuer certificate (if ocsp-update is enabled).
2024-03-25 11:50:25 -04:00
.ocsp_update.mode = SSL_SOCK_OCSP_UPDATE_DFLT,
WIP/MINOR: ssl: add sample fetches for keylog in frontend OpenSSL 1.1.1 provides a callback registering function SSL_CTX_set_keylog_callback, which allows one to receive a string containing the keys to deciphers TLSv1.3. Unfortunately it is not possible to store this data in binary form and we can only get this information using the callback. Which means that we need to store it until the connection is closed. This patches add 2 pools, the first one, pool_head_ssl_keylog is used to store a struct ssl_keylog which will be inserted as a ex_data in a SSL *. The second one is pool_head_ssl_keylog_str which will be used to store the hexadecimal strings. To enable the capture of the keys, you need to set "tune.ssl.keylog on" in your configuration. The following fetches were implemented: ssl_fc_client_early_traffic_secret, ssl_fc_client_handshake_traffic_secret, ssl_fc_server_handshake_traffic_secret, ssl_fc_client_traffic_secret_0, ssl_fc_server_traffic_secret_0, ssl_fc_exporter_secret, ssl_fc_early_exporter_secret
2020-07-06 05:41:30 -04:00
#endif
CLEANUP: ssl: move most ssl-specific global settings to ssl_sock.c Historically a lot of SSL global settings were stored into the global struct, but we've reached a point where there are 3 ifdefs in it just for this, and others in haproxy.c to initialize it. This patch moves all the private fields to a new struct "global_ssl" stored in ssl_sock.c. This includes : char *crt_base; char *ca_base; char *listen_default_ciphers; char *connect_default_ciphers; int listen_default_ssloptions; int connect_default_ssloptions; int tune.sslprivatecache; /* Force to use a private session cache even if nbproc > 1 */ unsigned int tune.ssllifetime; /* SSL session lifetime in seconds */ unsigned int tune.ssl_max_record; /* SSL max record size */ unsigned int tune.ssl_default_dh_param; /* SSL maximum DH parameter size */ int tune.ssl_ctx_cache; /* max number of entries in the ssl_ctx cache. */ The "tune" part was removed (useless here) and the occasional "ssl" prefixes were removed as well. Thus for example instead of global.tune.ssl_default_dh_param we now have : global_ssl.default_dh_param A few initializers were present in the constructor, they could be brought back to the structure declaration. A few other entries had to stay in global for now. They concern memory calculationn (used in haproxy.c) and stats (used in stats.c). The code is already much cleaner now, especially for global.h and haproxy.c which become readable.
2016-12-22 17:12:01 -05:00
};
MEDIUM: ssl: provide our own BIO. Instead of letting the OpenSSL code handle the file descriptor directly, provide a custom BIO, that will use the underlying XPRT to send/recv data. This will let us implement QUIC later, and probably clean the upper layer, if/when the SSL code provide its own subscribe code, so that the upper layers won't have to care if we're still waiting for the handshake to complete or not.
2019-04-07 16:00:38 -04:00
static BIO_METHOD *ha_meth;
CLEANUP: pool/tree-wide: remove suffix "_pool" from certain pool names A curious practise seems to have started long ago and contaminated various code areas, consisting in appending "_pool" at the end of the name of a given pool. That makes no sense as the name is only used to name the pool in diags such as "show pools", and since names are truncated there, this adds some confusion when analysing the dump outputs. Let's just clean all of them at once. there were essentially in SSL and QUIC.
2022-06-23 05:02:08 -04:00
DECLARE_STATIC_POOL(ssl_sock_ctx_pool, "ssl_sock_ctx", sizeof(struct ssl_sock_ctx));
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
CLEANUP: pool/tree-wide: remove suffix "_pool" from certain pool names A curious practise seems to have started long ago and contaminated various code areas, consisting in appending "_pool" at the end of the name of a given pool. That makes no sense as the name is only used to name the pool in diags such as "show pools", and since names are truncated there, this adds some confusion when analysing the dump outputs. Let's just clean all of them at once. there were essentially in SSL and QUIC.
2022-06-23 05:02:08 -04:00
DECLARE_STATIC_POOL(ssl_sock_client_sni_pool, "ssl_sock_client_sni", TLSEXT_MAXLEN_host_name + 1);
BUG/MINOR: ssl: Store client SNI in SSL context in case of ClientHello error If an error is raised during the ClientHello callback on the server side (ssl_sock_switchctx_cbk), the servername callback won't be called and the client's SNI will not be saved in the SSL context. But since we use the SSL_get_servername function to return this SNI in the ssl_fc_sni sample fetch, that means that in case of error, such as an SNI mismatch with a frontend having the strict-sni option enabled, the sample fetch would not work (making strict-sni related errors hard to debug). This patch fixes that by storing the SNI as an ex_data in the SSL context in case the ClientHello callback returns an error. This way the sample fetch can fallback to getting the SNI this way. It will still first call the SSL_get_servername function first since it is the proper way of getting a client's SNI when the handshake succeeded. In order to avoid memory allocations are runtime into this highly used runtime function, a new memory pool was created to store those client SNIs. Its entry size is set to 256 bytes since SNIs can't be longer than 255 characters. This fixes GitHub #1484. It can be backported in 2.5.
2022-01-07 11:12:01 -05:00
MINOR: ssl: instantiate stats module This module is responsible for providing statistics for ssl. It allocates counters for frontend/backend/listener/server objects.
2020-11-03 11:10:00 -05:00
/* ssl stats module */
enum {
MINOR: ssl: add counters for ssl sessions Add counters for newly established and resumed sessions.
2020-11-03 11:10:02 -05:00
SSL_ST_SESS,
SSL_ST_REUSED_SESS,
MEDIUM: stats: add counters for failed handshake Report on ssl stats the total number of handshakes terminated in a failure.
2020-11-13 10:05:00 -05:00
SSL_ST_FAILED_HANDSHAKE,
MINOR: ssl: count client hello for stats Add a counter for ssl client_hello received on frontends.
2020-11-03 11:10:01 -05:00
MINOR: ssl: instantiate stats module This module is responsible for providing statistics for ssl. It allocates counters for frontend/backend/listener/server objects.
2020-11-03 11:10:00 -05:00
SSL_ST_STATS_COUNT /* must be the last member of the enum */
};
static struct name_desc ssl_stats[] = {
MEDIUM: stats: add counters for failed handshake Report on ssl stats the total number of handshakes terminated in a failure.
2020-11-13 10:05:00 -05:00
[SSL_ST_SESS] = { .name = "ssl_sess",
.desc = "Total number of ssl sessions established" },
[SSL_ST_REUSED_SESS] = { .name = "ssl_reused_sess",
.desc = "Total number of ssl sessions reused" },
[SSL_ST_FAILED_HANDSHAKE] = { .name = "ssl_failed_handshake",
.desc = "Total number of failed handshake" },
MINOR: ssl: instantiate stats module This module is responsible for providing statistics for ssl. It allocates counters for frontend/backend/listener/server objects.
2020-11-03 11:10:00 -05:00
};
static struct ssl_counters {
MINOR: ssl: add counters for ssl sessions Add counters for newly established and resumed sessions.
2020-11-03 11:10:02 -05:00
long long sess;
long long reused_sess;
MEDIUM: stats: add counters for failed handshake Report on ssl stats the total number of handshakes terminated in a failure.
2020-11-13 10:05:00 -05:00
long long failed_handshake;
MINOR: ssl: instantiate stats module This module is responsible for providing statistics for ssl. It allocates counters for frontend/backend/listener/server objects.
2020-11-03 11:10:00 -05:00
} ssl_counters;
MEDIUM: stats: Be able to access a specific field into a stats module It is now possible to selectively retrieve extra counters from stats modules. H1, H2, QUIC and H3 fill_stats() callback functions are updated to return a specific counter.
2024-01-29 10:35:19 -05:00
static int ssl_fill_stats(void *data, struct field *stats, unsigned int *selected_field)
MINOR: ssl: instantiate stats module This module is responsible for providing statistics for ssl. It allocates counters for frontend/backend/listener/server objects.
2020-11-03 11:10:00 -05:00
{
MINOR: ssl: count client hello for stats Add a counter for ssl client_hello received on frontends.
2020-11-03 11:10:01 -05:00
struct ssl_counters *counters = data;
MEDIUM: stats: Be able to access a specific field into a stats module It is now possible to selectively retrieve extra counters from stats modules. H1, H2, QUIC and H3 fill_stats() callback functions are updated to return a specific counter.
2024-01-29 10:35:19 -05:00
unsigned int current_field = (selected_field != NULL ? *selected_field : 0);
for (; current_field < SSL_ST_STATS_COUNT; current_field++) {
struct field metric = { 0 };
switch (current_field) {
case SSL_ST_SESS:
metric = mkf_u64(FN_COUNTER, counters->sess);
break;
case SSL_ST_REUSED_SESS:
metric = mkf_u64(FN_COUNTER, counters->reused_sess);
break;
case SSL_ST_FAILED_HANDSHAKE:
metric = mkf_u64(FN_COUNTER, counters->failed_handshake);
break;
default:
/* not used for frontends. If a specific metric
* is requested, return an error. Otherwise continue.
*/
if (selected_field != NULL)
return 0;
continue;
}
stats[current_field] = metric;
if (selected_field != NULL)
break;
}
return 1;
MINOR: ssl: instantiate stats module This module is responsible for providing statistics for ssl. It allocates counters for frontend/backend/listener/server objects.
2020-11-03 11:10:00 -05:00
}
static struct stats_module ssl_stats_module = {
.name = "ssl",
.fill_stats = ssl_fill_stats,
.stats = ssl_stats,
.stats_count = SSL_ST_STATS_COUNT,
.counters = &ssl_counters,
.counters_size = sizeof(ssl_counters),
.domain_flags = MK_STATS_PROXY_DOMAIN(STATS_PX_CAP_FE|STATS_PX_CAP_LI|STATS_PX_CAP_BE|STATS_PX_CAP_SRV),
.clearable = 1,
};
INITCALL1(STG_REGISTER, stats_register_module, &ssl_stats_module);
CLEANUP: ssl/cli: stop using ctx.cli.i0/i1/p0 for "show tls-keys" This creates a local context of type show_keys_ctx which contains the equivalent fields with more natural names.
2022-05-05 02:50:17 -04:00
/* CLI context for "show tls-keys" */
struct show_keys_ctx {
struct tls_keys_ref *next_ref; /* next reference to be dumped */
int names_only; /* non-zero = only show file names */
int next_index; /* next index to be dumped */
CLEANUP: ssl/cli: add a new "dump_entries" field to "show_keys_ref" This gets rid of a ugly hack consisting in checking the IO handler's address while one is defined as an inline function calling the second.
2022-05-05 02:59:17 -04:00
int dump_entries; /* dump entries also */
CLEANUP: ssl/cli: make "show tlskeys" not use appctx->st2 anymore A new "state" enum was added to "show_keys_ctx" for this, and only 3 states are needed.
2022-05-05 03:03:44 -04:00
enum {
SHOW_KEYS_INIT = 0,
SHOW_KEYS_LIST,
SHOW_KEYS_DONE,
} state; /* phase of the current dump */
CLEANUP: ssl/cli: stop using ctx.cli.i0/i1/p0 for "show tls-keys" This creates a local context of type show_keys_ctx which contains the equivalent fields with more natural names.
2022-05-05 02:50:17 -04:00
};
MINOR: xprt/mux: export all *_io_cb functions so that "show fd" resolves them In FD dumps it's often very important to figure what upper layer function is going to be called. Let's export the few I/O callbacks that appear as tasklet functions so that "show fd" can resolve them instead of printing a pointer relative to main. For example: 1028 : st=0x21(R:rA W:Ra) ev=0x01(heopI) [lc] tmask=0x2 umask=0x2 owner=0x7f00b889b200 iocb=0x65b638(sock_conn_iocb) back=0 cflg=0x00001300 fe=recv mux=H2 ctx=0x7f00c8824de0 h2c.st0=FRH .err=0 .maxid=795 .lastid=-1 .flg=0x0000 .nbst=0 .nbcs=0 .fctl_cnt=0 .send_cnt=0 .tree_cnt=0 .orph_cnt=0 .sub=1 .dsi=795 .dbuf=0@(nil)+0/0 .msi=-1 .mbuf=[1..1|32],h=[0@(nil)+0/0],t=[0@(nil)+0/0] xprt=SSL xprt_ctx=0x7f00c86d0750 xctx.st=0 .xprt=RAW .wait.ev=1 .subs=0x7f00c88252e0(ev=1 tl=0x7f00a07d1aa0 tl.calls=1047 tl.ctx=0x7f00c8824de0 tl.fct=h2_io_cb) .sent_early=0 .early_in=0
2021-01-20 08:55:01 -05:00
/* ssl_sock_io_cb is exported to see it resolved in "show fd" */
MEDIUM: task: extend the state field to 32 bits It's been too short for quite a while now and is now full. It's still time to extend it to 32-bits since we have room for this without wasting any space, so we now gained 16 new bits for future flags. The values were not reassigned just in case there would be a few hidden u16 or short somewhere in which these flags are placed (as it used to be the case with stream->pending_events). The patch is tagged MEDIUM because this required to update the task's process() prototype to use an int instead of a short, that's quite a bunch of places.
2021-03-02 10:09:26 -05:00
struct task *ssl_sock_io_cb(struct task *, void *, unsigned int);
MINOR: ssl: Make ssl_sock_handshake() static. ssl_sock_handshake is now only used by the ssl code itself, there's no need to export it anymore, so make it static.
2019-05-23 08:45:12 -04:00
static int ssl_sock_handshake(struct connection *conn, unsigned int flag);
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
MEDIUM: ssl: provide our own BIO. Instead of letting the OpenSSL code handle the file descriptor directly, provide a custom BIO, that will use the underlying XPRT to send/recv data. This will let us implement QUIC later, and probably clean the upper layer, if/when the SSL code provide its own subscribe code, so that the upper layers won't have to care if we're still waiting for the handshake to complete or not.
2019-04-07 16:00:38 -04:00
/* Methods to implement OpenSSL BIO */
static int ha_ssl_write(BIO *h, const char *buf, int num)
{
struct buffer tmpbuf;
struct ssl_sock_ctx *ctx;
MINOR: ssl-sock: pass the CO_SFL_MSG_MORE info down the stack Despite having replaced the SSL BIOs to use our own raw_sock layer, we still didn't exploit the CO_SFL_MSG_MORE flag which is pretty useful to avoid sending incomplete packets. It's particularly important for SSL since the extra overhead almost guarantees that each send() will be followed by an incomplete (and often odd-sided) segment. We already have an xprt_st set of flags to pass info to the various layers, so let's just add a new one, SSL_SOCK_SEND_MORE, that is set or cleared during ssl_sock_from_buf() to transfer the knowledge of CO_SFL_MSG_MORE. This way we can recover this information and pass it to raw_sock. This alone is sufficient to increase by ~5-10% the H2 bandwidth over SSL when multiple streams are used in parallel.
2023-03-17 11:13:05 -04:00
uint flags;
MEDIUM: ssl: provide our own BIO. Instead of letting the OpenSSL code handle the file descriptor directly, provide a custom BIO, that will use the underlying XPRT to send/recv data. This will let us implement QUIC later, and probably clean the upper layer, if/when the SSL code provide its own subscribe code, so that the upper layers won't have to care if we're still waiting for the handshake to complete or not.
2019-04-07 16:00:38 -04:00
int ret;
ctx = BIO_get_data(h);
tmpbuf.size = num;
tmpbuf.area = (void *)(uintptr_t)buf;
tmpbuf.data = num;
tmpbuf.head = 0;
MINOR: ssl-sock: pass the CO_SFL_MSG_MORE info down the stack Despite having replaced the SSL BIOs to use our own raw_sock layer, we still didn't exploit the CO_SFL_MSG_MORE flag which is pretty useful to avoid sending incomplete packets. It's particularly important for SSL since the extra overhead almost guarantees that each send() will be followed by an incomplete (and often odd-sided) segment. We already have an xprt_st set of flags to pass info to the various layers, so let's just add a new one, SSL_SOCK_SEND_MORE, that is set or cleared during ssl_sock_from_buf() to transfer the knowledge of CO_SFL_MSG_MORE. This way we can recover this information and pass it to raw_sock. This alone is sufficient to increase by ~5-10% the H2 bandwidth over SSL when multiple streams are used in parallel.
2023-03-17 11:13:05 -04:00
flags = (ctx->xprt_st & SSL_SOCK_SEND_MORE) ? CO_SFL_MSG_MORE : 0;
ret = ctx->xprt->snd_buf(ctx->conn, ctx->xprt_ctx, &tmpbuf, num, flags);
BUG/MAJOR: ssl_sock: Always clear retry flags in read/write functions It has been found that under some rare error circumstances, SSL_do_handshake() could return with SSL_ERROR_WANT_READ without even trying to call the read function, causing permanent wakeups that prevent the process from sleeping. It was established that this only happens if the retry flags are not systematically cleared in both directions upon any I/O attempt, but, given the lack of documentation on this topic, it is hard to say if this rather strange behavior is expected or not, otherwise why wouldn't the library always clear the flags by itself before proceeding? In addition, this only seems to affect OpenSSL 1.1.0 and above, and does not affect wolfSSL nor aws-lc. A bisection on haproxy showed that this issue was first triggered by commit a8955d57ed ("MEDIUM: ssl: provide our own BIO."), which means that OpenSSL's socket BIO does not have this problem. And this one does always clear the flags before proceeding. So let's just proceed the same way. It was verified that it properly fixes the problem, does not affect other implementations, and doesn't cause any freeze nor spurious wakeups either. Many thanks to Valentn Gutirrez for providing a network capture showing the incident as well as a reproducer. This is GH issue #2403. This patch needs to be backported to all versions that include the commit above, i.e. as far as 2.0.
2024-01-27 16:58:29 -05:00
BIO_clear_retry_flags(h);
BUG/MEDIUM: ssl: Don't pretend we can retry a recv/send if we got a shutr/w. In ha_ssl_write() and ha_ssl_read(), don't pretend we can retry a read/write if we got a shutr/shutw, or we will never properly shutdown the connection.
2019-05-01 11:24:36 -04:00
if (ret == 0 && !(ctx->conn->flags & (CO_FL_ERROR | CO_FL_SOCK_WR_SH))) {
MEDIUM: ssl: provide our own BIO. Instead of letting the OpenSSL code handle the file descriptor directly, provide a custom BIO, that will use the underlying XPRT to send/recv data. This will let us implement QUIC later, and probably clean the upper layer, if/when the SSL code provide its own subscribe code, so that the upper layers won't have to care if we're still waiting for the handshake to complete or not.
2019-04-07 16:00:38 -04:00
BIO_set_retry_write(h);
BUG/MEDIUM: ssl: Return -1 on recv/send if we got EAGAIN. In ha_ssl_read()/ha_ssl_write(), if we couldn't send/receive data because we got EAGAIN, return -1 and not 0, as older SSL versions expect that. This should fix the problems with OpenSSL < 1.1.0.
2019-04-24 06:04:36 -04:00
ret = -1;
BUG/MAJOR: ssl_sock: Always clear retry flags in read/write functions It has been found that under some rare error circumstances, SSL_do_handshake() could return with SSL_ERROR_WANT_READ without even trying to call the read function, causing permanent wakeups that prevent the process from sleeping. It was established that this only happens if the retry flags are not systematically cleared in both directions upon any I/O attempt, but, given the lack of documentation on this topic, it is hard to say if this rather strange behavior is expected or not, otherwise why wouldn't the library always clear the flags by itself before proceeding? In addition, this only seems to affect OpenSSL 1.1.0 and above, and does not affect wolfSSL nor aws-lc. A bisection on haproxy showed that this issue was first triggered by commit a8955d57ed ("MEDIUM: ssl: provide our own BIO."), which means that OpenSSL's socket BIO does not have this problem. And this one does always clear the flags before proceeding. So let's just proceed the same way. It was verified that it properly fixes the problem, does not affect other implementations, and doesn't cause any freeze nor spurious wakeups either. Many thanks to Valentn Gutirrez for providing a network capture showing the incident as well as a reproducer. This is GH issue #2403. This patch needs to be backported to all versions that include the commit above, i.e. as far as 2.0.
2024-01-27 16:58:29 -05:00
}
MEDIUM: ssl: provide our own BIO. Instead of letting the OpenSSL code handle the file descriptor directly, provide a custom BIO, that will use the underlying XPRT to send/recv data. This will let us implement QUIC later, and probably clean the upper layer, if/when the SSL code provide its own subscribe code, so that the upper layers won't have to care if we're still waiting for the handshake to complete or not.
2019-04-07 16:00:38 -04:00
return ret;
}
static int ha_ssl_gets(BIO *h, char *buf, int size)
{
return 0;
}
static int ha_ssl_puts(BIO *h, const char *str)
{
return ha_ssl_write(h, str, strlen(str));
}
static int ha_ssl_read(BIO *h, char *buf, int size)
{
struct buffer tmpbuf;
struct ssl_sock_ctx *ctx;
int ret;
ctx = BIO_get_data(h);
tmpbuf.size = size;
tmpbuf.area = buf;
tmpbuf.data = 0;
tmpbuf.head = 0;
ret = ctx->xprt->rcv_buf(ctx->conn, ctx->xprt_ctx, &tmpbuf, size, 0);
BUG/MAJOR: ssl_sock: Always clear retry flags in read/write functions It has been found that under some rare error circumstances, SSL_do_handshake() could return with SSL_ERROR_WANT_READ without even trying to call the read function, causing permanent wakeups that prevent the process from sleeping. It was established that this only happens if the retry flags are not systematically cleared in both directions upon any I/O attempt, but, given the lack of documentation on this topic, it is hard to say if this rather strange behavior is expected or not, otherwise why wouldn't the library always clear the flags by itself before proceeding? In addition, this only seems to affect OpenSSL 1.1.0 and above, and does not affect wolfSSL nor aws-lc. A bisection on haproxy showed that this issue was first triggered by commit a8955d57ed ("MEDIUM: ssl: provide our own BIO."), which means that OpenSSL's socket BIO does not have this problem. And this one does always clear the flags before proceeding. So let's just proceed the same way. It was verified that it properly fixes the problem, does not affect other implementations, and doesn't cause any freeze nor spurious wakeups either. Many thanks to Valentn Gutirrez for providing a network capture showing the incident as well as a reproducer. This is GH issue #2403. This patch needs to be backported to all versions that include the commit above, i.e. as far as 2.0.
2024-01-27 16:58:29 -05:00
BIO_clear_retry_flags(h);
BUG/MEDIUM: ssl: Don't pretend we can retry a recv/send if we got a shutr/w. In ha_ssl_write() and ha_ssl_read(), don't pretend we can retry a read/write if we got a shutr/shutw, or we will never properly shutdown the connection.
2019-05-01 11:24:36 -04:00
if (ret == 0 && !(ctx->conn->flags & (CO_FL_ERROR | CO_FL_SOCK_RD_SH))) {
MEDIUM: ssl: provide our own BIO. Instead of letting the OpenSSL code handle the file descriptor directly, provide a custom BIO, that will use the underlying XPRT to send/recv data. This will let us implement QUIC later, and probably clean the upper layer, if/when the SSL code provide its own subscribe code, so that the upper layers won't have to care if we're still waiting for the handshake to complete or not.
2019-04-07 16:00:38 -04:00
BIO_set_retry_read(h);
BUG/MEDIUM: ssl: Return -1 on recv/send if we got EAGAIN. In ha_ssl_read()/ha_ssl_write(), if we couldn't send/receive data because we got EAGAIN, return -1 and not 0, as older SSL versions expect that. This should fix the problems with OpenSSL < 1.1.0.
2019-04-24 06:04:36 -04:00
ret = -1;
BUG/MAJOR: ssl_sock: Always clear retry flags in read/write functions It has been found that under some rare error circumstances, SSL_do_handshake() could return with SSL_ERROR_WANT_READ without even trying to call the read function, causing permanent wakeups that prevent the process from sleeping. It was established that this only happens if the retry flags are not systematically cleared in both directions upon any I/O attempt, but, given the lack of documentation on this topic, it is hard to say if this rather strange behavior is expected or not, otherwise why wouldn't the library always clear the flags by itself before proceeding? In addition, this only seems to affect OpenSSL 1.1.0 and above, and does not affect wolfSSL nor aws-lc. A bisection on haproxy showed that this issue was first triggered by commit a8955d57ed ("MEDIUM: ssl: provide our own BIO."), which means that OpenSSL's socket BIO does not have this problem. And this one does always clear the flags before proceeding. So let's just proceed the same way. It was verified that it properly fixes the problem, does not affect other implementations, and doesn't cause any freeze nor spurious wakeups either. Many thanks to Valentn Gutirrez for providing a network capture showing the incident as well as a reproducer. This is GH issue #2403. This patch needs to be backported to all versions that include the commit above, i.e. as far as 2.0.
2024-01-27 16:58:29 -05:00
}
MEDIUM: ssl: provide our own BIO. Instead of letting the OpenSSL code handle the file descriptor directly, provide a custom BIO, that will use the underlying XPRT to send/recv data. This will let us implement QUIC later, and probably clean the upper layer, if/when the SSL code provide its own subscribe code, so that the upper layers won't have to care if we're still waiting for the handshake to complete or not.
2019-04-07 16:00:38 -04:00
return ret;
}
static long ha_ssl_ctrl(BIO *h, int cmd, long arg1, void *arg2)
{
int ret = 0;
switch (cmd) {
case BIO_CTRL_DUP:
case BIO_CTRL_FLUSH:
ret = 1;
break;
}
return ret;
}
static int ha_ssl_new(BIO *h)
{
BIO_set_init(h, 1);
BIO_set_data(h, NULL);
BIO_clear_flags(h, ~0);
return 1;
}
static int ha_ssl_free(BIO *data)
{
return 1;
}
CLEANUP: ssl: remove 57 occurrences of useless tests on LIBRESSL_VERSION_NUMBER They were all check to comply with the advertised openssl version. Now that libressl doesn't pretend to be a more recent openssl anymore, we can simply rely on the regular openssl version tests without having to deal with exceptions for libressl.
2019-05-09 08:13:35 -04:00
#if defined(USE_THREAD) && (HA_OPENSSL_VERSION_NUMBER < 0x10100000L)
MINOR: threads: Use __decl_hathreads to declare locks This macro should be used to declare variables or struct members depending on the USE_THREAD compile option. It avoids the encapsulation of such declarations between #ifdef/#endif. It is used to declare all lock variables.
2017-11-13 04:34:01 -05:00
MAJOR: threads/ssl: Make SSL part thread-safe First, OpenSSL is now initialized to be thread-safe. This is done by setting 2 callbacks. The first one is ssl_locking_function. It handles the locks and unlocks. The second one is ssl_id_function. It returns the current thread id. During the init step, we create as much as R/W locks as needed, ie the number returned by CRYPTO_num_locks function. Next, The reusable SSL session in the server context is now thread-local. Shctx is now also initialized if HAProxy is started with several threads. And finally, a global lock has been added to protect the LRU cache used to store generated certificates. The function ssl_sock_get_generated_cert is now deprecated because the retrieved certificate can be removed by another threads in same time. Instead, a new function has been added, ssl_sock_assign_generated_cert. It must be used to search a certificate in the cache and set it immediatly if found.
2017-06-15 10:37:39 -04:00
static HA_RWLOCK_T *ssl_rwlocks;
unsigned long ssl_id_function(void)
{
return (unsigned long)tid;
}
void ssl_locking_function(int mode, int n, const char * file, int line)
{
if (mode & CRYPTO_LOCK) {
if (mode & CRYPTO_READ)
BUILD: threads: Rename SPIN/RWLOCK macros using HA_ prefix This remove any name conflicts, especially on Solaris.
2017-11-07 04:42:54 -05:00
HA_RWLOCK_RDLOCK(SSL_LOCK, &ssl_rwlocks[n]);
MAJOR: threads/ssl: Make SSL part thread-safe First, OpenSSL is now initialized to be thread-safe. This is done by setting 2 callbacks. The first one is ssl_locking_function. It handles the locks and unlocks. The second one is ssl_id_function. It returns the current thread id. During the init step, we create as much as R/W locks as needed, ie the number returned by CRYPTO_num_locks function. Next, The reusable SSL session in the server context is now thread-local. Shctx is now also initialized if HAProxy is started with several threads. And finally, a global lock has been added to protect the LRU cache used to store generated certificates. The function ssl_sock_get_generated_cert is now deprecated because the retrieved certificate can be removed by another threads in same time. Instead, a new function has been added, ssl_sock_assign_generated_cert. It must be used to search a certificate in the cache and set it immediatly if found.
2017-06-15 10:37:39 -04:00
else
BUILD: threads: Rename SPIN/RWLOCK macros using HA_ prefix This remove any name conflicts, especially on Solaris.
2017-11-07 04:42:54 -05:00
HA_RWLOCK_WRLOCK(SSL_LOCK, &ssl_rwlocks[n]);
MAJOR: threads/ssl: Make SSL part thread-safe First, OpenSSL is now initialized to be thread-safe. This is done by setting 2 callbacks. The first one is ssl_locking_function. It handles the locks and unlocks. The second one is ssl_id_function. It returns the current thread id. During the init step, we create as much as R/W locks as needed, ie the number returned by CRYPTO_num_locks function. Next, The reusable SSL session in the server context is now thread-local. Shctx is now also initialized if HAProxy is started with several threads. And finally, a global lock has been added to protect the LRU cache used to store generated certificates. The function ssl_sock_get_generated_cert is now deprecated because the retrieved certificate can be removed by another threads in same time. Instead, a new function has been added, ssl_sock_assign_generated_cert. It must be used to search a certificate in the cache and set it immediatly if found.
2017-06-15 10:37:39 -04:00
}
else {
if (mode & CRYPTO_READ)
BUILD: threads: Rename SPIN/RWLOCK macros using HA_ prefix This remove any name conflicts, especially on Solaris.
2017-11-07 04:42:54 -05:00
HA_RWLOCK_RDUNLOCK(SSL_LOCK, &ssl_rwlocks[n]);
MAJOR: threads/ssl: Make SSL part thread-safe First, OpenSSL is now initialized to be thread-safe. This is done by setting 2 callbacks. The first one is ssl_locking_function. It handles the locks and unlocks. The second one is ssl_id_function. It returns the current thread id. During the init step, we create as much as R/W locks as needed, ie the number returned by CRYPTO_num_locks function. Next, The reusable SSL session in the server context is now thread-local. Shctx is now also initialized if HAProxy is started with several threads. And finally, a global lock has been added to protect the LRU cache used to store generated certificates. The function ssl_sock_get_generated_cert is now deprecated because the retrieved certificate can be removed by another threads in same time. Instead, a new function has been added, ssl_sock_assign_generated_cert. It must be used to search a certificate in the cache and set it immediatly if found.
2017-06-15 10:37:39 -04:00
else
BUILD: threads: Rename SPIN/RWLOCK macros using HA_ prefix This remove any name conflicts, especially on Solaris.
2017-11-07 04:42:54 -05:00
HA_RWLOCK_WRUNLOCK(SSL_LOCK, &ssl_rwlocks[n]);
MAJOR: threads/ssl: Make SSL part thread-safe First, OpenSSL is now initialized to be thread-safe. This is done by setting 2 callbacks. The first one is ssl_locking_function. It handles the locks and unlocks. The second one is ssl_id_function. It returns the current thread id. During the init step, we create as much as R/W locks as needed, ie the number returned by CRYPTO_num_locks function. Next, The reusable SSL session in the server context is now thread-local. Shctx is now also initialized if HAProxy is started with several threads. And finally, a global lock has been added to protect the LRU cache used to store generated certificates. The function ssl_sock_get_generated_cert is now deprecated because the retrieved certificate can be removed by another threads in same time. Instead, a new function has been added, ssl_sock_assign_generated_cert. It must be used to search a certificate in the cache and set it immediatly if found.
2017-06-15 10:37:39 -04:00
}
}
static int ssl_locking_init(void)
{
int i;
ssl_rwlocks = malloc(sizeof(HA_RWLOCK_T)*CRYPTO_num_locks());
if (!ssl_rwlocks)
return -1;
for (i = 0 ; i < CRYPTO_num_locks() ; i++)
BUILD: threads: Rename SPIN/RWLOCK macros using HA_ prefix This remove any name conflicts, especially on Solaris.
2017-11-07 04:42:54 -05:00
HA_RWLOCK_INIT(&ssl_rwlocks[i]);
MAJOR: threads/ssl: Make SSL part thread-safe First, OpenSSL is now initialized to be thread-safe. This is done by setting 2 callbacks. The first one is ssl_locking_function. It handles the locks and unlocks. The second one is ssl_id_function. It returns the current thread id. During the init step, we create as much as R/W locks as needed, ie the number returned by CRYPTO_num_locks function. Next, The reusable SSL session in the server context is now thread-local. Shctx is now also initialized if HAProxy is started with several threads. And finally, a global lock has been added to protect the LRU cache used to store generated certificates. The function ssl_sock_get_generated_cert is now deprecated because the retrieved certificate can be removed by another threads in same time. Instead, a new function has been added, ssl_sock_assign_generated_cert. It must be used to search a certificate in the cache and set it immediatly if found.
2017-06-15 10:37:39 -04:00
CRYPTO_set_id_callback(ssl_id_function);
CRYPTO_set_locking_callback(ssl_locking_function);
return 0;
}
MINOR: threads: Use __decl_hathreads to declare locks This macro should be used to declare variables or struct members depending on the USE_THREAD compile option. It avoids the encapsulation of such declarations between #ifdef/#endif. It is used to declare all lock variables.
2017-11-13 04:34:01 -05:00
MAJOR: threads/ssl: Make SSL part thread-safe First, OpenSSL is now initialized to be thread-safe. This is done by setting 2 callbacks. The first one is ssl_locking_function. It handles the locks and unlocks. The second one is ssl_id_function. It returns the current thread id. During the init step, we create as much as R/W locks as needed, ie the number returned by CRYPTO_num_locks function. Next, The reusable SSL session in the server context is now thread-local. Shctx is now also initialized if HAProxy is started with several threads. And finally, a global lock has been added to protect the LRU cache used to store generated certificates. The function ssl_sock_get_generated_cert is now deprecated because the retrieved certificate can be removed by another threads in same time. Instead, a new function has been added, ssl_sock_assign_generated_cert. It must be used to search a certificate in the cache and set it immediatly if found.
2017-06-15 10:37:39 -04:00
#endif
CLEANUP: thread: rename __decl_hathreads() to __decl_thread() I can never figure whether it takes an "s" or not, and in the end it's better if it matches the file's naming, so let's call it "__decl_thread".
2020-06-05 02:40:51 -04:00
__decl_thread(HA_SPINLOCK_T ckch_lock);
MAJOR: threads/ssl: Make SSL part thread-safe First, OpenSSL is now initialized to be thread-safe. This is done by setting 2 callbacks. The first one is ssl_locking_function. It handles the locks and unlocks. The second one is ssl_id_function. It returns the current thread id. During the init step, we create as much as R/W locks as needed, ie the number returned by CRYPTO_num_locks function. Next, The reusable SSL session in the server context is now thread-local. Shctx is now also initialized if HAProxy is started with several threads. And finally, a global lock has been added to protect the LRU cache used to store generated certificates. The function ssl_sock_get_generated_cert is now deprecated because the retrieved certificate can be removed by another threads in same time. Instead, a new function has been added, ssl_sock_assign_generated_cert. It must be used to search a certificate in the cache and set it immediatly if found.
2017-06-15 10:37:39 -04:00
MINOR: ssl/cli: rework 'set ssl cert' as 'set/commit' This patch splits the 'set ssl cert' CLI command into 2 commands. The previous way of updating the certificate on the CLI was limited with the bundles. It was only able to apply one of the tree part of the certificate during an update, which mean that we needed 3 updates to update a full 3 certs bundle. It was also not possible to apply atomically several part of a certificate with the ability to rollback on error. (For example applying a .pem, then a .ocsp, then a .sctl) The command 'set ssl cert' will now duplicate the certificate (or bundle) and update it in a temporary transaction.. The second command 'commit ssl cert' will commit all the changes made during the transaction for the certificate. This commit breaks the ability to update a certificate which was used as a unique file and as a bundle in the HAProxy configuration. This way of using the certificates wasn't making any sense. Example: // For a bundle: $ echo -e "set ssl cert localhost.pem.rsa <<\n$(cat kikyo.pem.rsa)\n" | socat /tmp/sock1 - Transaction created for certificate localhost.pem! $ echo -e "set ssl cert localhost.pem.dsa <<\n$(cat kikyo.pem.dsa)\n" | socat /tmp/sock1 - Transaction updated for certificate localhost.pem! $ echo -e "set ssl cert localhost.pem.ecdsa <<\n$(cat kikyo.pem.ecdsa)\n" | socat /tmp/sock1 - Transaction updated for certificate localhost.pem! $ echo "commit ssl cert localhost.pem" | socat /tmp/sock1 - Committing localhost.pem. Success!
2019-10-29 18:48:19 -04:00
MINOR: ssl: deduplicate ca-file Typically server line like: 'server-template srv 1-1000 *:443 ssl ca-file ca-certificates.crt' load ca-certificates.crt 1000 times and stay duplicated in memory. Same case for bind line: ca-file is loaded for each certificate. Same 'ca-file' can be load one time only and stay deduplicated in memory. As a corollary, this will prevent file access for ca-file when updating a certificate via CLI.
2019-10-24 05:32:47 -04:00
/* mimic what X509_STORE_load_locations do with store_ctx */
static int ssl_set_cert_crl_file(X509_STORE *store_ctx, char *path)
{
BUILD/MINOR: ssl: Fix compilation with SSL enabled The CA/CRL hot update patches did not compile on some targets of the CI (mainly gcc + ssl). This patch should fix almost all of them. It adds missing variable initializations and return value checks to the BIO_reset calls in show_crl_detail.
2021-05-17 05:45:55 -04:00
X509_STORE *store = NULL;
MEDIUM: ssl: Chain ckch instances in ca-file entries Each ca-file entry of the tree will now hold a list of the ckch instances that use it so that we can iterate over them when updating the ca-file via a cli command. Since the link between the SSL contexts and the CA file tree entries is only built during the ssl_sock_prepare_ctx function, which are called after all the ckch instances are created, we need to add a little post processing after each ssl_sock_prepare_ctx that builds the link between the corresponding ckch instance and CA file tree entries. In order to manage the ca-file and ca-verify-file options, any ckch instance can be linked to multiple CA file tree entries and any CA file entry can link multiple ckch instances. This is done thanks to a dedicated list of ckch_inst references stored in the CA file tree entries over which we can iterate (during an update for instance). We avoid having one of those instances go stale by keeping a list of references to those references in the instances. When deleting a ckch_inst, we can then remove all the ckch_inst_link instances that reference it, and when deleting a cafile_entry, we iterate over the list of ckch_inst reference and clear the corresponding entry in their own list of ckch_inst_link references.
2021-02-19 11:41:55 -05:00
struct cafile_entry *ca_e = ssl_store_get_cafile_entry(path, 0);
if (ca_e)
store = ca_e->ca_store;
MINOR: ssl: deduplicate ca-file Typically server line like: 'server-template srv 1-1000 *:443 ssl ca-file ca-certificates.crt' load ca-certificates.crt 1000 times and stay duplicated in memory. Same case for bind line: ca-file is loaded for each certificate. Same 'ca-file' can be load one time only and stay deduplicated in memory. As a corollary, this will prevent file access for ca-file when updating a certificate via CLI.
2019-10-24 05:32:47 -04:00
if (store_ctx && store) {
int i;
X509_OBJECT *obj;
STACK_OF(X509_OBJECT) *objs = X509_STORE_get0_objects(store);
for (i = 0; i < sk_X509_OBJECT_num(objs); i++) {
obj = sk_X509_OBJECT_value(objs, i);
switch (X509_OBJECT_get_type(obj)) {
case X509_LU_X509:
X509_STORE_add_cert(store_ctx, X509_OBJECT_get0_X509(obj));
break;
case X509_LU_CRL:
X509_STORE_add_crl(store_ctx, X509_OBJECT_get0_X509_CRL(obj));
break;
default:
break;
}
}
return 1;
}
return 0;
}
CLEANUP: assorted typo fixes in the code and comments These are mostly comments in the code. A few error messages were fixed and are of low enough importance not to deserve a backport. Some regtests were also fixed.
2020-03-10 03:06:11 -04:00
/* SSL_CTX_load_verify_locations substitute, internally call X509_STORE_load_locations */
MINOR: ssl: deduplicate ca-file Typically server line like: 'server-template srv 1-1000 *:443 ssl ca-file ca-certificates.crt' load ca-certificates.crt 1000 times and stay duplicated in memory. Same case for bind line: ca-file is loaded for each certificate. Same 'ca-file' can be load one time only and stay deduplicated in memory. As a corollary, this will prevent file access for ca-file when updating a certificate via CLI.
2019-10-24 05:32:47 -04:00
static int ssl_set_verify_locations_file(SSL_CTX *ctx, char *path)
{
X509_STORE *store_ctx = SSL_CTX_get_cert_store(ctx);
return ssl_set_cert_crl_file(store_ctx, path);
}
MINOR: ssl: compute ca-list from deduplicate ca-file ca-list can be extracted from ca-file already loaded in memory. This patch set ca-list from deduplicated ca-file when needed and share it in ca-file tree. As a corollary, this will prevent file access for ca-list when updating a certificate via CLI.
2019-10-24 12:08:51 -04:00
/*
Extract CA_list from CA_file already in tree.
Duplicate ca_name is tracking with ebtree. It's simplify openssl compatibility.
Return a shared ca_list: SSL_dup_CA_list must be used before set it on SSL_CTX.
*/
static STACK_OF(X509_NAME)* ssl_get_client_ca_file(char *path)
{
struct ebmb_node *eb;
struct cafile_entry *ca_e;
eb = ebst_lookup(&cafile_tree, path);
if (!eb)
return NULL;
ca_e = ebmb_entry(eb, struct cafile_entry, node);
if (ca_e->ca_list == NULL) {
int i;
unsigned long key;
struct eb_root ca_name_tree = EB_ROOT;
struct eb64_node *node, *back;
struct {
struct eb64_node node;
X509_NAME *xname;
} *ca_name;
STACK_OF(X509_OBJECT) *objs;
STACK_OF(X509_NAME) *skn;
X509 *x;
X509_NAME *xn;
skn = sk_X509_NAME_new_null();
/* take x509 from cafile_tree */
objs = X509_STORE_get0_objects(ca_e->ca_store);
for (i = 0; i < sk_X509_OBJECT_num(objs); i++) {
x = X509_OBJECT_get0_X509(sk_X509_OBJECT_value(objs, i));
if (!x)
continue;
xn = X509_get_subject_name(x);
if (!xn)
continue;
/* Check for duplicates. */
key = X509_NAME_hash(xn);
for (node = eb64_lookup(&ca_name_tree, key), ca_name = NULL;
node && ca_name == NULL;
node = eb64_next(node)) {
ca_name = container_of(node, typeof(*ca_name), node);
if (X509_NAME_cmp(xn, ca_name->xname) != 0)
ca_name = NULL;
}
/* find a duplicate */
if (ca_name)
continue;
ca_name = calloc(1, sizeof *ca_name);
xn = X509_NAME_dup(xn);
if (!ca_name ||
!xn ||
!sk_X509_NAME_push(skn, xn)) {
free(ca_name);
X509_NAME_free(xn);
sk_X509_NAME_pop_free(skn, X509_NAME_free);
sk_X509_NAME_free(skn);
skn = NULL;
break;
}
ca_name->node.key = key;
ca_name->xname = xn;
eb64_insert(&ca_name_tree, &ca_name->node);
}
ca_e->ca_list = skn;
/* remove temporary ca_name tree */
node = eb64_first(&ca_name_tree);
while (node) {
ca_name = container_of(node, typeof(*ca_name), node);
back = eb64_next(node);
eb64_delete(node);
free(ca_name);
node = back;
}
}
return ca_e->ca_list;
}
MINOR: pool: move pool declarations to read_mostly All pool heads are accessed via a pointer and should not be shared with highly written variables. Move them to the read_mostly section.
2021-04-10 11:23:00 -04:00
struct pool_head *pool_head_ssl_capture __read_mostly = NULL;
REORG: ssl: move sample fetches to src/ssl_sample.c Move all SSL sample fetches to src/ssl_sample.c.
2020-05-14 18:25:08 -04:00
int ssl_capture_ptr_index = -1;
MINOR: ssl: Export definitions required by QUIC. QUIC needs to initialize its BIO and SSL session the same way as for SSL over TCP connections. It needs also to use the same ClientHello callback. This patch only exports functions and variables shared between QUIC and SSL/TCP connections.
2020-11-23 05:19:04 -05:00
int ssl_app_data_index = -1;
MEDIUM: quic/ssl: add new ex data for quic_conn Allow to register quic_conn as ex-data in SSL callbacks. A new index is used to identify it as ssl_qc_app_data_index. Replace connection by quic_conn as SSL ex-data when initializing the QUIC SSL session. When using SSL callbacks in QUIC context, the connection is now NULL. Used quic_conn instead to retrieve the required parameters. Also clean up The same changes are conducted inside the QUIC SSL methods of xprt-quic : connection instance usage is replaced by quic_conn.
2022-01-19 04:03:30 -05:00
#ifdef USE_QUIC
int ssl_qc_app_data_index = -1;
#endif /* USE_QUIC */
CLEANUP: ssl: move most ssl-specific global settings to ssl_sock.c Historically a lot of SSL global settings were stored into the global struct, but we've reached a point where there are 3 ifdefs in it just for this, and others in haproxy.c to initialize it. This patch moves all the private fields to a new struct "global_ssl" stored in ssl_sock.c. This includes : char *crt_base; char *ca_base; char *listen_default_ciphers; char *connect_default_ciphers; int listen_default_ssloptions; int connect_default_ssloptions; int tune.sslprivatecache; /* Force to use a private session cache even if nbproc > 1 */ unsigned int tune.ssllifetime; /* SSL session lifetime in seconds */ unsigned int tune.ssl_max_record; /* SSL max record size */ unsigned int tune.ssl_default_dh_param; /* SSL maximum DH parameter size */ int tune.ssl_ctx_cache; /* max number of entries in the ssl_ctx cache. */ The "tune" part was removed (useless here) and the occasional "ssl" prefixes were removed as well. Thus for example instead of global.tune.ssl_default_dh_param we now have : global_ssl.default_dh_param A few initializers were present in the constructor, they could be brought back to the structure declaration. A few other entries had to stay in global for now. They concern memory calculationn (used in haproxy.c) and stats (used in stats.c). The code is already much cleaner now, especially for global.h and haproxy.c which become readable.
2016-12-22 17:12:01 -05:00
BUILD: make tune.ssl.keylog available again Since commit 04a5a44 ("BUILD: ssl: use HAVE_OPENSSL_KEYLOG instead of OpenSSL versions") the "tune.ssl.keylog" feature is broken because HAVE_OPENSSL_KEYLOG does not exist. Replace this by a HAVE_SSL_KEYLOG which is defined in openssl-compat.h. Also add an error when not built with the right openssl version. Must be backported as far as 2.3.
2021-06-09 10:46:12 -04:00
#ifdef HAVE_SSL_KEYLOG
WIP/MINOR: ssl: add sample fetches for keylog in frontend OpenSSL 1.1.1 provides a callback registering function SSL_CTX_set_keylog_callback, which allows one to receive a string containing the keys to deciphers TLSv1.3. Unfortunately it is not possible to store this data in binary form and we can only get this information using the callback. Which means that we need to store it until the connection is closed. This patches add 2 pools, the first one, pool_head_ssl_keylog is used to store a struct ssl_keylog which will be inserted as a ex_data in a SSL *. The second one is pool_head_ssl_keylog_str which will be used to store the hexadecimal strings. To enable the capture of the keys, you need to set "tune.ssl.keylog on" in your configuration. The following fetches were implemented: ssl_fc_client_early_traffic_secret, ssl_fc_client_handshake_traffic_secret, ssl_fc_server_handshake_traffic_secret, ssl_fc_client_traffic_secret_0, ssl_fc_server_traffic_secret_0, ssl_fc_exporter_secret, ssl_fc_early_exporter_secret
2020-07-06 05:41:30 -04:00
int ssl_keylog_index = -1;
MINOR: pool: move pool declarations to read_mostly All pool heads are accessed via a pointer and should not be shared with highly written variables. Move them to the read_mostly section.
2021-04-10 11:23:00 -04:00
struct pool_head *pool_head_ssl_keylog __read_mostly = NULL;
struct pool_head *pool_head_ssl_keylog_str __read_mostly = NULL;
WIP/MINOR: ssl: add sample fetches for keylog in frontend OpenSSL 1.1.1 provides a callback registering function SSL_CTX_set_keylog_callback, which allows one to receive a string containing the keys to deciphers TLSv1.3. Unfortunately it is not possible to store this data in binary form and we can only get this information using the callback. Which means that we need to store it until the connection is closed. This patches add 2 pools, the first one, pool_head_ssl_keylog is used to store a struct ssl_keylog which will be inserted as a ex_data in a SSL *. The second one is pool_head_ssl_keylog_str which will be used to store the hexadecimal strings. To enable the capture of the keys, you need to set "tune.ssl.keylog on" in your configuration. The following fetches were implemented: ssl_fc_client_early_traffic_secret, ssl_fc_client_handshake_traffic_secret, ssl_fc_server_handshake_traffic_secret, ssl_fc_client_traffic_secret_0, ssl_fc_server_traffic_secret_0, ssl_fc_exporter_secret, ssl_fc_early_exporter_secret
2020-07-06 05:41:30 -04:00
#endif
MEDIUM: ssl: Keep a reference to the client's certificate for use in logs Most of the SSL sample fetches related to the client certificate were based on the SSL_get_peer_certificate function which returns NULL when the verification process failed. This made it impossible to use those fetches in a log format since they would always be empty. The patch adds a reference to the X509 object representing the client certificate in the SSL structure and makes use of this reference in the fetches. The reference can only be obtained in ssl_sock_bind_verifycbk which means that in case of an SSL error occurring before the verification process ("no shared cipher" for instance, which happens while processing the Client Hello), we won't ever start the verification process and it will be impossible to get information about the client certificate. This patch also allows most of the ssl_c_XXX fetches to return a usable value in case of connection failure (because of a verification error for instance) by making the "conn->flags & CO_FL_WAIT_XPRT" test (which requires a connection to be established) less strict. Thanks to this patch, a log-format such as the following should return usable information in case of an error occurring during the verification process : log-format "DN=%{+Q}[ssl_c_s_dn] serial=%[ssl_c_serial,hex] \ hash=%[ssl_c_sha1,hex]" It should answer to GitHub issue #693.
2021-08-19 12:06:30 -04:00
int ssl_client_crt_ref_index = -1;
BUG/MINOR: ssl: Store client SNI in SSL context in case of ClientHello error If an error is raised during the ClientHello callback on the server side (ssl_sock_switchctx_cbk), the servername callback won't be called and the client's SNI will not be saved in the SSL context. But since we use the SSL_get_servername function to return this SNI in the ssl_fc_sni sample fetch, that means that in case of error, such as an SNI mismatch with a frontend having the strict-sni option enabled, the sample fetch would not work (making strict-sni related errors hard to debug). This patch fixes that by storing the SNI as an ex_data in the SSL context in case the ClientHello callback returns an error. This way the sample fetch can fallback to getting the SNI this way. It will still first call the SSL_get_servername function first since it is the proper way of getting a client's SNI when the handshake succeeded. In order to avoid memory allocations are runtime into this highly used runtime function, a new memory pool was created to store those client SNIs. Its entry size is set to 256 bytes since SNIs can't be longer than 255 characters. This fixes GitHub #1484. It can be backported in 2.5.
2022-01-07 11:12:01 -05:00
/* Used to store the client's SNI in case of ClientHello callback error */
int ssl_client_sni_index = -1;
MEDIUM: Add support for updating TLS ticket keys via socket Until now, HAproxy needed to be restarted to change the TLS ticket keys. With this patch, the TLS keys can be updated on a per-file basis using the admin socket. Two new socket commands have been introduced: "show tls-keys" and "set ssl tls-keys". Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
2015-05-09 02:46:01 -04:00
#if (defined SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB && TLS_TICKETS_NO > 0)
struct list tlskeys_reference = LIST_HEAD_INIT(tlskeys_reference);
#endif
BUILD: ssl: add USE_ENGINE and disable the openssl engine by default The OpenSSL engine API is deprecated starting with OpenSSL 3.0. In order to have a clean build this feature is now disabled by default. It can be reactivated with USE_ENGINE=1 on the build line.
2022-04-11 12:41:24 -04:00
#if defined(USE_ENGINE) && !defined(OPENSSL_NO_ENGINE)
REORG: ssl: move ssl configuration to cfgparse-ssl.c Move all the configuration parsing of the ssl keywords in cfgparse-ssl.c
2020-05-14 11:47:32 -04:00
unsigned int openssl_engines_initialized;
MEDIUM: ssl: add basic support for OpenSSL crypto engine This patch adds the global 'ssl-engine' keyword. First arg is an engine identifier followed by a list of default_algorithms the engine will operate. If the openssl version is too old, an error is reported when the option is used.
2017-01-20 20:10:18 -05:00
struct list openssl_engines = LIST_HEAD_INIT(openssl_engines);
struct ssl_engine_list {
struct list list;
ENGINE *e;
};
BUILD: ssl: fix build with OPENSSL_NO_ENGINE Build is broken with openssl library without support of engin (like boringssl). Add OPENSSL_NO_ENGINE flag to fix that.
2017-05-29 08:36:20 -04:00
#endif
MEDIUM: ssl: add basic support for OpenSSL crypto engine This patch adds the global 'ssl-engine' keyword. First arg is an engine identifier followed by a list of default_algorithms the engine will operate. If the openssl version is too old, an error is reported when the option is used.
2017-01-20 20:10:18 -05:00
MINOR: ssl: Add 'ssl-provider' global option When HAProxy is linked to an OpenSSLv3 library, this option can be used to load a provider during init. You can specify multiple ssl-provider options, which will be loaded in the order they appear. This does not prevent OpenSSL from parsing its own configuration file in which some other providers might be specified. A linked list of the providers loaded from the configuration file is kept so that all those providers can be unloaded during cleanup. The providers loaded directly by OpenSSL will be freed by OpenSSL.
2022-05-16 10:24:33 -04:00
#ifdef HAVE_SSL_PROVIDERS
struct list openssl_providers = LIST_HEAD_INIT(openssl_providers);
struct ssl_provider_list {
struct list list;
OSSL_PROVIDER *provider;
};
#endif
BUG/MEDIUM: ssl: Fix a memory leak in DHE key exchange OpenSSL does not free the DH * value returned by the callback specified with SSL_CTX_set_tmp_dh_callback(), leading to a memory leak for SSL/TLS connections using Diffie Hellman Ephemeral key exchange. This patch fixes the leak by allocating the DH * structs holding the DH parameters once, at configuration time. Note: this fix must be backported to 1.5.
2014-07-15 05:36:40 -04:00
#ifndef OPENSSL_NO_DH
BUG/MEDIUM: ssl: fix tune.ssl.default-dh-param value being overwritten Herv Commowick reported that the logic used to avoid complaining about ssl-default-dh-param not being set when static DH params are present in the certificate file was clearly wrong when more than one sni_ctx is used. This patch stores whether static DH params are being used for each SSL_CTX individually, and does not overwrite the value of tune.ssl.default-dh-param.
2015-05-28 10:23:00 -04:00
static int ssl_dh_ptr_index = -1;
MEDIUM: ssl: Replace all DH objects by EVP_PKEY on OpenSSLv3 (via HASSL_DH type) DH structure is a low-level one that should not be used anymore with OpenSSLv3. All functions working on DH were marked as deprecated and this patch replaces the ones we used with new APIs recommended in OpenSSLv3, be it in the migration guide or the multiple new manpages they created. This patch replaces all mentions of the DH type by the HASSL_DH one, which will be replaced by EVP_PKEY with OpenSSLv3 and will remain DH on older versions. It also uses all the newly created helper functions that enable for instance to load DH parameters from a file into an EVP_PKEY, or to set DH parameters into an SSL_CTX for use in a DHE negotiation. The following deprecated functions will effectively disappear when building with OpenSSLv3 : DH_set0_pqg, PEM_read_bio_DHparams, DH_new, DH_free, DH_up_ref, SSL_CTX_set_tmp_dh.
2022-02-11 06:04:55 -05:00
static HASSL_DH *global_dh = NULL;
static HASSL_DH *local_dh_1024 = NULL;
static HASSL_DH *local_dh_2048 = NULL;
static HASSL_DH *local_dh_4096 = NULL;
BUG/MEDIUM: ssl: Fix a memory leak in DHE key exchange OpenSSL does not free the DH * value returned by the callback specified with SSL_CTX_set_tmp_dh_callback(), leading to a memory leak for SSL/TLS connections using Diffie Hellman Ephemeral key exchange. This patch fixes the leak by allocating the DH * structs holding the DH parameters once, at configuration time. Note: this fix must be backported to 1.5.
2014-07-15 05:36:40 -04:00
#endif /* OPENSSL_NO_DH */
MEDIUM: ssl: Added support for Multi-Cert OCSP Stapling Enabled loading of OCSP staple responses (.ocsp files) when processing a bundled certificate with multiple keytypes.
2015-12-10 15:07:30 -05:00
/* The order here matters for picking a default context,
* keep the most common keytype at the bottom of the list
*/
const char *SSL_SOCK_KEYTYPE_NAMES[] = {
"dsa",
"ecdsa",
"rsa"
};
BUG/MEDIUM: ssl: don't allocate shctx several time The shctx_init() function does not check anymore if the pointer is not NULL, this check must be done is the caller. The consequence was to allocate one shctx per ssl bind. Bug introduced by 4f45bb9 ("MEDIUM: shctx: separate ssl and shctx") Thanks to Maciej Zdeb for reporting this bug. Must be backported to 1.8.
2017-11-28 05:04:43 -05:00
static struct shared_context *ssl_shctx = NULL; /* ssl shared session cache */
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
static struct eb_root *sh_ssl_sess_tree; /* ssl shared session tree */
MEDIUM: ssl: split ssl_sock_msgcbk() and use a new callback mechanism Make use of ssl_sock_register_msg_callback(). Function ssl_sock_msgcbk() is now split into two dedicated functions for heartbeat and clienthello. They are both registered by using a new callback mechanism for SSL/TLS protocol messages.
2020-05-11 09:51:45 -04:00
/* Dedicated callback functions for heartbeat and clienthello.
*/
#ifdef TLS1_RT_HEARTBEAT
static void ssl_sock_parse_heartbeat(struct connection *conn, int write_p, int version,
int content_type, const void *buf, size_t len,
SSL *ssl);
#endif
static void ssl_sock_parse_clienthello(struct connection *conn, int write_p, int version,
int content_type, const void *buf, size_t len,
SSL *ssl);
BUILD: make tune.ssl.keylog available again Since commit 04a5a44 ("BUILD: ssl: use HAVE_OPENSSL_KEYLOG instead of OpenSSL versions") the "tune.ssl.keylog" feature is broken because HAVE_OPENSSL_KEYLOG does not exist. Replace this by a HAVE_SSL_KEYLOG which is defined in openssl-compat.h. Also add an error when not built with the right openssl version. Must be backported as far as 2.3.
2021-06-09 10:46:12 -04:00
#ifdef HAVE_SSL_KEYLOG
WIP/MINOR: ssl: add sample fetches for keylog in frontend OpenSSL 1.1.1 provides a callback registering function SSL_CTX_set_keylog_callback, which allows one to receive a string containing the keys to deciphers TLSv1.3. Unfortunately it is not possible to store this data in binary form and we can only get this information using the callback. Which means that we need to store it until the connection is closed. This patches add 2 pools, the first one, pool_head_ssl_keylog is used to store a struct ssl_keylog which will be inserted as a ex_data in a SSL *. The second one is pool_head_ssl_keylog_str which will be used to store the hexadecimal strings. To enable the capture of the keys, you need to set "tune.ssl.keylog on" in your configuration. The following fetches were implemented: ssl_fc_client_early_traffic_secret, ssl_fc_client_handshake_traffic_secret, ssl_fc_server_handshake_traffic_secret, ssl_fc_client_traffic_secret_0, ssl_fc_server_traffic_secret_0, ssl_fc_exporter_secret, ssl_fc_early_exporter_secret
2020-07-06 05:41:30 -04:00
static void ssl_init_keylog(struct connection *conn, int write_p, int version,
int content_type, const void *buf, size_t len,
SSL *ssl);
#endif
MEDIUM: ssl: allow to register callbacks for SSL/TLS protocol messages This patch adds the ability to register callbacks for SSL/TLS protocol messages by using the function ssl_sock_register_msg_callback(). All registered callback functions will be called when observing received or sent SSL/TLS protocol messages.
2020-05-08 12:30:00 -04:00
/* List head of all registered SSL/TLS protocol message callbacks. */
struct list ssl_sock_msg_callbacks = LIST_HEAD_INIT(ssl_sock_msg_callbacks);
/* Registers the function <func> in order to be called on SSL/TLS protocol
* message processing. It will return 0 if the function <func> is not set
* or if it fails to allocate memory.
*/
int ssl_sock_register_msg_callback(ssl_sock_msg_callback_func func)
{
struct ssl_sock_msg_callback *cbk;
if (!func)
return 0;
cbk = calloc(1, sizeof(*cbk));
if (!cbk) {
ha_alert("out of memory in ssl_sock_register_msg_callback().\n");
return 0;
}
cbk->func = func;
CLEANUP: lists/tree-wide: rename some list operations to avoid some confusion The current "ADD" vs "ADDQ" is confusing because when thinking in terms of appending at the end of a list, "ADD" naturally comes to mind, but here it does the opposite, it inserts. Several times already it's been incorrectly used where ADDQ was expected, the latest of which was a fortunate accident explained in 6fa922562 ("CLEANUP: stream: explain why we queue the stream at the head of the server list"). Let's use more explicit (but slightly longer) names now: LIST_ADD -> LIST_INSERT LIST_ADDQ -> LIST_APPEND LIST_ADDED -> LIST_INLIST LIST_DEL -> LIST_DELETE The same is true for MT_LISTs, including their "TRY" variant. LIST_DEL_INIT keeps its short name to encourage to use it instead of the lazier LIST_DELETE which is often less safe. The change is large (~674 non-comment entries) but is mechanical enough to remain safe. No permutation was performed, so any out-of-tree code can easily map older names to new ones. The list doc was updated.
2021-04-21 01:32:39 -04:00
LIST_APPEND(&ssl_sock_msg_callbacks, &cbk->list);
MEDIUM: ssl: allow to register callbacks for SSL/TLS protocol messages This patch adds the ability to register callbacks for SSL/TLS protocol messages by using the function ssl_sock_register_msg_callback(). All registered callback functions will be called when observing received or sent SSL/TLS protocol messages.
2020-05-08 12:30:00 -04:00
return 1;
}
MEDIUM: ssl: split ssl_sock_msgcbk() and use a new callback mechanism Make use of ssl_sock_register_msg_callback(). Function ssl_sock_msgcbk() is now split into two dedicated functions for heartbeat and clienthello. They are both registered by using a new callback mechanism for SSL/TLS protocol messages.
2020-05-11 09:51:45 -04:00
/* Used to register dedicated SSL/TLS protocol message callbacks.
*/
static int ssl_sock_register_msg_callbacks(void)
{
#ifdef TLS1_RT_HEARTBEAT
if (!ssl_sock_register_msg_callback(ssl_sock_parse_heartbeat))
return ERR_ABORT;
#endif
MEDIUM: config: Deprecate tune.ssl.capture-cipherlist-size Deprecate tune.ssl.capture-cipherlist-size in favor of tune.ssl.capture-buffer-size which better describes the purpose of the setting.
2021-07-13 13:04:24 -04:00
if (global_ssl.capture_buffer_size > 0) {
MEDIUM: ssl: split ssl_sock_msgcbk() and use a new callback mechanism Make use of ssl_sock_register_msg_callback(). Function ssl_sock_msgcbk() is now split into two dedicated functions for heartbeat and clienthello. They are both registered by using a new callback mechanism for SSL/TLS protocol messages.
2020-05-11 09:51:45 -04:00
if (!ssl_sock_register_msg_callback(ssl_sock_parse_clienthello))
return ERR_ABORT;
}
BUILD: make tune.ssl.keylog available again Since commit 04a5a44 ("BUILD: ssl: use HAVE_OPENSSL_KEYLOG instead of OpenSSL versions") the "tune.ssl.keylog" feature is broken because HAVE_OPENSSL_KEYLOG does not exist. Replace this by a HAVE_SSL_KEYLOG which is defined in openssl-compat.h. Also add an error when not built with the right openssl version. Must be backported as far as 2.3.
2021-06-09 10:46:12 -04:00
#ifdef HAVE_SSL_KEYLOG
WIP/MINOR: ssl: add sample fetches for keylog in frontend OpenSSL 1.1.1 provides a callback registering function SSL_CTX_set_keylog_callback, which allows one to receive a string containing the keys to deciphers TLSv1.3. Unfortunately it is not possible to store this data in binary form and we can only get this information using the callback. Which means that we need to store it until the connection is closed. This patches add 2 pools, the first one, pool_head_ssl_keylog is used to store a struct ssl_keylog which will be inserted as a ex_data in a SSL *. The second one is pool_head_ssl_keylog_str which will be used to store the hexadecimal strings. To enable the capture of the keys, you need to set "tune.ssl.keylog on" in your configuration. The following fetches were implemented: ssl_fc_client_early_traffic_secret, ssl_fc_client_handshake_traffic_secret, ssl_fc_server_handshake_traffic_secret, ssl_fc_client_traffic_secret_0, ssl_fc_server_traffic_secret_0, ssl_fc_exporter_secret, ssl_fc_early_exporter_secret
2020-07-06 05:41:30 -04:00
if (global_ssl.keylog > 0) {
if (!ssl_sock_register_msg_callback(ssl_init_keylog))
return ERR_ABORT;
}
#endif
BUG/MINOR: quic: Missing call to TLS message callbacks This bug impacts only the QUIC OpenSSL compatibility module (USE_QUIC_OPENSSL_COMPAT). The TLS capture of information from client hello enabled by tune.ssl.capture-buffer-size could not work with USE_QUIC_OPENSSL_COMPAT. This is due to the fact the callback set for this feature was replaced by quic_tls_compat_msg_callback(). In fact this called must be registered by ssl_sock_register_msg_callback() as this done for the TLS client hello capture. A call to this function appends the function passed as parameter to a list of callbacks to be called when the TLS stack parse a TLS message. quic_tls_compat_msg_callback() had to be modified to return if it is called for a non-QUIC TLS session. Must be backported to 2.8.
2023-12-21 10:11:35 -05:00
#ifdef USE_QUIC_OPENSSL_COMPAT
if (!ssl_sock_register_msg_callback(quic_tls_compat_msg_callback))
return ERR_ABORT;
#endif
WIP/MINOR: ssl: add sample fetches for keylog in frontend OpenSSL 1.1.1 provides a callback registering function SSL_CTX_set_keylog_callback, which allows one to receive a string containing the keys to deciphers TLSv1.3. Unfortunately it is not possible to store this data in binary form and we can only get this information using the callback. Which means that we need to store it until the connection is closed. This patches add 2 pools, the first one, pool_head_ssl_keylog is used to store a struct ssl_keylog which will be inserted as a ex_data in a SSL *. The second one is pool_head_ssl_keylog_str which will be used to store the hexadecimal strings. To enable the capture of the keys, you need to set "tune.ssl.keylog on" in your configuration. The following fetches were implemented: ssl_fc_client_early_traffic_secret, ssl_fc_client_handshake_traffic_secret, ssl_fc_server_handshake_traffic_secret, ssl_fc_client_traffic_secret_0, ssl_fc_server_traffic_secret_0, ssl_fc_exporter_secret, ssl_fc_early_exporter_secret
2020-07-06 05:41:30 -04:00
CLEANUP: config: Return ERR_NONE from config callbacks instead of 0 Return ERR_NONE instead of 0 on success for all config callbacks that should return ERR_* codes. There is no change because ERR_NONE is a macro equals to 0. But this makes the return value more explicit.
2020-11-06 09:24:23 -05:00
return ERR_NONE;
MEDIUM: ssl: split ssl_sock_msgcbk() and use a new callback mechanism Make use of ssl_sock_register_msg_callback(). Function ssl_sock_msgcbk() is now split into two dedicated functions for heartbeat and clienthello. They are both registered by using a new callback mechanism for SSL/TLS protocol messages.
2020-05-11 09:51:45 -04:00
}
MEDIUM: ssl: allow to register callbacks for SSL/TLS protocol messages This patch adds the ability to register callbacks for SSL/TLS protocol messages by using the function ssl_sock_register_msg_callback(). All registered callback functions will be called when observing received or sent SSL/TLS protocol messages.
2020-05-08 12:30:00 -04:00
/* Used to free all SSL/TLS protocol message callbacks that were
* registered by using ssl_sock_register_msg_callback().
*/
static void ssl_sock_unregister_msg_callbacks(void)
{
struct ssl_sock_msg_callback *cbk, *cbkback;
list_for_each_entry_safe(cbk, cbkback, &ssl_sock_msg_callbacks, list) {
CLEANUP: lists/tree-wide: rename some list operations to avoid some confusion The current "ADD" vs "ADDQ" is confusing because when thinking in terms of appending at the end of a list, "ADD" naturally comes to mind, but here it does the opposite, it inserts. Several times already it's been incorrectly used where ADDQ was expected, the latest of which was a fortunate accident explained in 6fa922562 ("CLEANUP: stream: explain why we queue the stream at the head of the server list"). Let's use more explicit (but slightly longer) names now: LIST_ADD -> LIST_INSERT LIST_ADDQ -> LIST_APPEND LIST_ADDED -> LIST_INLIST LIST_DEL -> LIST_DELETE The same is true for MT_LISTs, including their "TRY" variant. LIST_DEL_INIT keeps its short name to encourage to use it instead of the lazier LIST_DELETE which is often less safe. The change is large (~674 non-comment entries) but is mechanical enough to remain safe. No permutation was performed, so any out-of-tree code can easily map older names to new ones. The list doc was updated.
2021-04-21 01:32:39 -04:00
LIST_DELETE(&cbk->list);
MEDIUM: ssl: allow to register callbacks for SSL/TLS protocol messages This patch adds the ability to register callbacks for SSL/TLS protocol messages by using the function ssl_sock_register_msg_callback(). All registered callback functions will be called when observing received or sent SSL/TLS protocol messages.
2020-05-08 12:30:00 -04:00
free(cbk);
}
}
MEDIUM: ssl: improve retrieval of ssl_sock_ctx and SSL detection Historically there was a single way to have an SSL transport on a connection, so detecting if the transport layer was SSL and a context was present was sufficient to detect SSL. With QUIC, things have changed because QUIC also relies on SSL, but the context is embedded inside the quic_conn and the transport layer doesn't match expectations outside, making it difficult to detect that SSL is in use over the connection. The approach taken here to improve this consists in adding a new method at the transport layer, get_ssl_sock_ctx(), to retrieve this often needed ssl_sock_ctx, and to use this to detect the presence of SSL. This will even allow some simplifications and cleanups to be made in the SSL code itself, and QUIC will be able to provide one to export its ssl_sock_ctx.
2022-04-11 04:43:28 -04:00
static struct ssl_sock_ctx *ssl_sock_get_ctx(struct connection *conn)
{
if (!conn || conn->xprt != xprt_get(XPRT_SSL) || !conn->xprt_ctx)
return NULL;
return (struct ssl_sock_ctx *)conn->xprt_ctx;
}
MINOR: ssl: add a new function ssl_sock_get_ssl_object() This one can be used later to get a SSL object from connection. It will return NULL if connection is not established over SSL.
2020-05-11 11:17:06 -04:00
SSL *ssl_sock_get_ssl_object(struct connection *conn)
{
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
struct ssl_sock_ctx *ctx = conn_get_ssl_sock_ctx(conn);
MINOR: ssl: add a new function ssl_sock_get_ssl_object() This one can be used later to get a SSL object from connection. It will return NULL if connection is not established over SSL.
2020-05-11 11:17:06 -04:00
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
return ctx ? ctx->ssl : NULL;
MINOR: ssl: add a new function ssl_sock_get_ssl_object() This one can be used later to get a SSL object from connection. It will return NULL if connection is not established over SSL.
2020-05-11 11:17:06 -04:00
}
BUILD: ssl: fix to build (again) with boringssl Limitations: . disable force-ssl/tls (need more work) should be set earlier with SSL_CTX_new (SSL_CTX_set_ssl_version is removed) . disable generate-certificates (need more work) introduce SSL_NO_GENERATE_CERTIFICATES to disable generate-certificates. Cleanup some #ifdef and type related to boringssl env.
2017-01-13 11:48:18 -05:00
/*
* This function gives the detail of the SSL error. It is used only
* if the debug mode and the verbose mode are activated. It dump all
* the SSL error until the stack was empty.
*/
BUG/MINOR: quic: Possible crash when verifying certificates This verification is done by ssl_sock_bind_verifycbk() which is set at different locations in the ssl_sock.c code . About QUIC connections, there are a lot of chances the connection object is not initialized when entering this function. What must be accessed is the SSL object to retrieve the connection or quic_conn objects, then the bind_conf object of the listener. If the connection object is not found, we try to find the quic_conn object. Modify ssl_sock_dump_errors() interface which takes a connection object as parameter to also passed a quic_conn object as parameter. Again this function try first to access the connection object if not NULL or the quic_conn object if not. There is a remaining thing to do for QUIC: store the certificate verification error code as it is currently stored in the connection object. This error code is at least used by the "bc_err" and "fc_err" sample fetches. There are chances this bug is in relation with GH #1851. Thank you to @tasavis for the report. Must be merged into 2.6.
2022-09-06 13:37:08 -04:00
static forceinline void ssl_sock_dump_errors(struct connection *conn,
struct quic_conn *qc)
BUILD: ssl: fix to build (again) with boringssl Limitations: . disable force-ssl/tls (need more work) should be set earlier with SSL_CTX_new (SSL_CTX_set_ssl_version is removed) . disable generate-certificates (need more work) introduce SSL_NO_GENERATE_CERTIFICATES to disable generate-certificates. Cleanup some #ifdef and type related to boringssl env.
2017-01-13 11:48:18 -05:00
{
unsigned long ret;
if (unlikely(global.mode & MODE_DEBUG)) {
while(1) {
MINOR: ssl: Remove call to ERR_func_error_string with OpenSSLv3 ERR_func_error_string does not return anything anymore with OpenSSLv3, it can be replaced by ERR_peek_error_func which did not exist on previous versions.
2022-02-11 06:04:44 -05:00
const char *func = NULL;
ERR_peek_error_func(&func);
BUILD: ssl: fix to build (again) with boringssl Limitations: . disable force-ssl/tls (need more work) should be set earlier with SSL_CTX_new (SSL_CTX_set_ssl_version is removed) . disable generate-certificates (need more work) introduce SSL_NO_GENERATE_CERTIFICATES to disable generate-certificates. Cleanup some #ifdef and type related to boringssl env.
2017-01-13 11:48:18 -05:00
ret = ERR_get_error();
if (ret == 0)
return;
BUG/MINOR: quic: Possible crash when verifying certificates This verification is done by ssl_sock_bind_verifycbk() which is set at different locations in the ssl_sock.c code . About QUIC connections, there are a lot of chances the connection object is not initialized when entering this function. What must be accessed is the SSL object to retrieve the connection or quic_conn objects, then the bind_conf object of the listener. If the connection object is not found, we try to find the quic_conn object. Modify ssl_sock_dump_errors() interface which takes a connection object as parameter to also passed a quic_conn object as parameter. Again this function try first to access the connection object if not NULL or the quic_conn object if not. There is a remaining thing to do for QUIC: store the certificate verification error code as it is currently stored in the connection object. This error code is at least used by the "bc_err" and "fc_err" sample fetches. There are chances this bug is in relation with GH #1851. Thank you to @tasavis for the report. Must be merged into 2.6.
2022-09-06 13:37:08 -04:00
if (conn) {
fprintf(stderr, "fd[%#x] OpenSSL error[0x%lx] %s: %s\n",
conn_fd(conn), ret,
func, ERR_reason_error_string(ret));
}
#ifdef USE_QUIC
else {
/* TODO: we are not sure <conn> is always initialized for QUIC connections */
fprintf(stderr, "qc @%p OpenSSL error[0x%lx] %s: %s\n", qc, ret,
func, ERR_reason_error_string(ret));
}
#endif
BUILD: ssl: fix to build (again) with boringssl Limitations: . disable force-ssl/tls (need more work) should be set earlier with SSL_CTX_new (SSL_CTX_set_ssl_version is removed) . disable generate-certificates (need more work) introduce SSL_NO_GENERATE_CERTIFICATES to disable generate-certificates. Cleanup some #ifdef and type related to boringssl env.
2017-01-13 11:48:18 -05:00
}
}
}
MEDIUM: ssl: Added support for Multi-Cert OCSP Stapling Enabled loading of OCSP staple responses (.ocsp files) when processing a bundled certificate with multiple keytypes.
2015-12-10 15:07:30 -05:00
BUILD: ssl: add USE_ENGINE and disable the openssl engine by default The OpenSSL engine API is deprecated starting with OpenSSL 3.0. In order to have a clean build this feature is now disabled by default. It can be reactivated with USE_ENGINE=1 on the build line.
2022-04-11 12:41:24 -04:00
#if defined(USE_ENGINE) && !defined(OPENSSL_NO_ENGINE)
REORG: ssl: move ssl configuration to cfgparse-ssl.c Move all the configuration parsing of the ssl keywords in cfgparse-ssl.c
2020-05-14 11:47:32 -04:00
int ssl_init_single_engine(const char *engine_id, const char *def_algorithms)
MEDIUM: ssl: add basic support for OpenSSL crypto engine This patch adds the global 'ssl-engine' keyword. First arg is an engine identifier followed by a list of default_algorithms the engine will operate. If the openssl version is too old, an error is reported when the option is used.
2017-01-20 20:10:18 -05:00
{
int err_code = ERR_ABORT;
ENGINE *engine;
struct ssl_engine_list *el;
/* grab the structural reference to the engine */
engine = ENGINE_by_id(engine_id);
if (engine == NULL) {
CLEANUP: log: Rename Alert/Warning in ha_alert/ha_warning
2017-11-24 10:50:31 -05:00
ha_alert("ssl-engine %s: failed to get structural reference\n", engine_id);
MEDIUM: ssl: add basic support for OpenSSL crypto engine This patch adds the global 'ssl-engine' keyword. First arg is an engine identifier followed by a list of default_algorithms the engine will operate. If the openssl version is too old, an error is reported when the option is used.
2017-01-20 20:10:18 -05:00
goto fail_get;
}
if (!ENGINE_init(engine)) {
/* the engine couldn't initialise, release it */
CLEANUP: log: Rename Alert/Warning in ha_alert/ha_warning
2017-11-24 10:50:31 -05:00
ha_alert("ssl-engine %s: failed to initialize\n", engine_id);
MEDIUM: ssl: add basic support for OpenSSL crypto engine This patch adds the global 'ssl-engine' keyword. First arg is an engine identifier followed by a list of default_algorithms the engine will operate. If the openssl version is too old, an error is reported when the option is used.
2017-01-20 20:10:18 -05:00
goto fail_init;
}
if (ENGINE_set_default_string(engine, def_algorithms) == 0) {
CLEANUP: log: Rename Alert/Warning in ha_alert/ha_warning
2017-11-24 10:50:31 -05:00
ha_alert("ssl-engine %s: failed on ENGINE_set_default_string\n", engine_id);
MEDIUM: ssl: add basic support for OpenSSL crypto engine This patch adds the global 'ssl-engine' keyword. First arg is an engine identifier followed by a list of default_algorithms the engine will operate. If the openssl version is too old, an error is reported when the option is used.
2017-01-20 20:10:18 -05:00
goto fail_set_method;
}
el = calloc(1, sizeof(*el));
BUG/MINOR: ssl: Missing calloc return value check in ssl_init_single_engine A memory allocation failure happening during ssl_init_single_engine would have resulted in a crash. This function is only called during init. It was raised in GitHub issue #1233. It could be backported to all stable branches.
2021-05-12 11:45:21 -04:00
if (!el)
goto fail_alloc;
MEDIUM: ssl: add basic support for OpenSSL crypto engine This patch adds the global 'ssl-engine' keyword. First arg is an engine identifier followed by a list of default_algorithms the engine will operate. If the openssl version is too old, an error is reported when the option is used.
2017-01-20 20:10:18 -05:00
el->e = engine;
CLEANUP: lists/tree-wide: rename some list operations to avoid some confusion The current "ADD" vs "ADDQ" is confusing because when thinking in terms of appending at the end of a list, "ADD" naturally comes to mind, but here it does the opposite, it inserts. Several times already it's been incorrectly used where ADDQ was expected, the latest of which was a fortunate accident explained in 6fa922562 ("CLEANUP: stream: explain why we queue the stream at the head of the server list"). Let's use more explicit (but slightly longer) names now: LIST_ADD -> LIST_INSERT LIST_ADDQ -> LIST_APPEND LIST_ADDED -> LIST_INLIST LIST_DEL -> LIST_DELETE The same is true for MT_LISTs, including their "TRY" variant. LIST_DEL_INIT keeps its short name to encourage to use it instead of the lazier LIST_DELETE which is often less safe. The change is large (~674 non-comment entries) but is mechanical enough to remain safe. No permutation was performed, so any out-of-tree code can easily map older names to new ones. The list doc was updated.
2021-04-21 01:32:39 -04:00
LIST_INSERT(&openssl_engines, &el->list);
BUG/MEDIUM: ssl engines: Fix async engines fds were not considered to fix fd limit automatically. The number of async fd is computed considering the maxconn, the number of sides using ssl and the number of engines using async mode. This patch should be backported on haproxy 1.8
2017-12-06 07:51:49 -05:00
nb_engines++;
if (global_ssl.async)
global.ssl_used_async_engines = nb_engines;
MEDIUM: ssl: add basic support for OpenSSL crypto engine This patch adds the global 'ssl-engine' keyword. First arg is an engine identifier followed by a list of default_algorithms the engine will operate. If the openssl version is too old, an error is reported when the option is used.
2017-01-20 20:10:18 -05:00
return 0;
BUG/MINOR: ssl: Missing calloc return value check in ssl_init_single_engine A memory allocation failure happening during ssl_init_single_engine would have resulted in a crash. This function is only called during init. It was raised in GitHub issue #1233. It could be backported to all stable branches.
2021-05-12 11:45:21 -04:00
fail_alloc:
MEDIUM: ssl: add basic support for OpenSSL crypto engine This patch adds the global 'ssl-engine' keyword. First arg is an engine identifier followed by a list of default_algorithms the engine will operate. If the openssl version is too old, an error is reported when the option is used.
2017-01-20 20:10:18 -05:00
fail_set_method:
/* release the functional reference from ENGINE_init() */
ENGINE_finish(engine);
fail_init:
/* release the structural reference from ENGINE_by_id() */
ENGINE_free(engine);
fail_get:
return err_code;
}
BUILD: ssl: fix build with OPENSSL_NO_ENGINE Build is broken with openssl library without support of engin (like boringssl). Add OPENSSL_NO_ENGINE flag to fix that.
2017-05-29 08:36:20 -04:00
#endif
MEDIUM: ssl: add basic support for OpenSSL crypto engine This patch adds the global 'ssl-engine' keyword. First arg is an engine identifier followed by a list of default_algorithms the engine will operate. If the openssl version is too old, an error is reported when the option is used.
2017-01-20 20:10:18 -05:00
MINOR: ssl: Add 'ssl-provider' global option When HAProxy is linked to an OpenSSLv3 library, this option can be used to load a provider during init. You can specify multiple ssl-provider options, which will be loaded in the order they appear. This does not prevent OpenSSL from parsing its own configuration file in which some other providers might be specified. A linked list of the providers loaded from the configuration file is kept so that all those providers can be unloaded during cleanup. The providers loaded directly by OpenSSL will be freed by OpenSSL.
2022-05-16 10:24:33 -04:00
#ifdef HAVE_SSL_PROVIDERS
int ssl_init_provider(const char *provider_name)
{
int err_code = ERR_ABORT;
struct ssl_provider_list *prov = NULL;
prov = calloc(1, sizeof(*prov));
if (!prov) {
ha_alert("ssl-provider %s: memory allocation failure\n", provider_name);
goto error;
}
if ((prov->provider = OSSL_PROVIDER_load(NULL, provider_name)) == NULL) {
ha_alert("ssl-provider %s: unknown provider\n", provider_name);
goto error;
}
LIST_INSERT(&openssl_providers, &prov->list);
return 0;
error:
ha_free(&prov);
return err_code;
}
#endif /* HAVE_SSL_PROVIDERS */
BUILD: ssl: use SSL_MODE_ASYNC macro instead of OPENSSL_VERSION
2020-11-13 15:56:34 -05:00
#ifdef SSL_MODE_ASYNC
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
/*
* openssl async fd handler
*/
MINOR: ssl/cli: async fd io-handlers printable on show fd This patch exports the async fd iohandlers and make them printable doing a 'show fd' on cli.
2019-04-19 11:15:28 -04:00
void ssl_async_fd_handler(int fd)
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
{
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
struct ssl_sock_ctx *ctx = fdtab[fd].owner;
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
/* fd is an async enfine fd, we must stop
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
* to poll this fd until it is requested
*/
BUG/MINOR: ssl: do not call directly the conn_fd_handler from async_fd_handler This patch modifies the way to re-enable the connection from the async fd handler calling conn_update_sock_polling instead of the conn_fd_handler. It also ensures that the polling is really stopped on the async fd.
2017-06-02 11:54:06 -04:00
fd_stop_recv(fd);
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
fd_cant_recv(fd);
/* crypto engine is available, let's notify the associated
* connection that it can pursue its processing.
*/
BUG/MEDIUM: ssl: Don't call ssl_sock_io_cb() directly. In the SSL code, when we were waiting for the availability of the crypto engine, once it is ready and its fd's I/O handler is called, don't call ssl_sock_io_cb() directly, instead, call tasklet_wakeup() on the ssl_sock_ctx's tasklet. We were calling ssl_sock_io_cb() with NULL as a tasklet, which used to be fine, but it is no longer true since the fd takeover changes. We could just provide the tasklet, but let's just wake the tasklet, as is done for other FDs, for fairness. This should fix github issue #856. This should be backported into 2.2.
2020-09-15 16:16:02 -04:00
tasklet_wakeup(ctx->wait_event.tasklet);
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
}
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
/*
* openssl async delayed SSL_free handler
*/
MINOR: ssl/cli: async fd io-handlers printable on show fd This patch exports the async fd iohandlers and make them printable doing a 'show fd' on cli.
2019-04-19 11:15:28 -04:00
void ssl_async_fd_free(int fd)
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
{
SSL *ssl = fdtab[fd].owner;
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
OSSL_ASYNC_FD all_fd[32];
size_t num_all_fds = 0;
int i;
/* We suppose that the async job for a same SSL *
* are serialized. So if we are awake it is
* because the running job has just finished
* and we can remove all async fds safely
*/
SSL_get_all_async_fds(ssl, NULL, &num_all_fds);
if (num_all_fds > 32) {
send_log(NULL, LOG_EMERG, "haproxy: openssl returns too many async fds. It seems a bug. Process may crash\n");
return;
}
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
SSL_get_all_async_fds(ssl, all_fd, &num_all_fds);
BUG/MEDIUM: ssl/fd: unexpected fd close using async engine Before 2.3, after an async crypto processing or on session close, the engine async file's descriptors were removed from the fdtab but not closed because it is the engine which has created the file descriptor, and it is responsible for closing it. In 2.3 the fd_remove() call was replaced by fd_stop_both() which stops the polling but does not remove the fd from the fdtab and the fd remains indefinitively in the fdtab. A simple replacement by fd_delete() is not a valid fix because fd_delete() removes the fd from the fdtab but also closes the fd. And the fd will be closed twice: by the haproxy's core and by the engine itself. Instead, let's set FD_DISOWN on the FD before calling fd_delete() which will take care of not closing it. This patch must be backported on branches >= 2.3, and it relies on this previous patch: MINOR: fd: add a new FD_DISOWN flag to prevent from closing a deleted FD As mentioned in the patch above, a different flag will be needed in 2.3.
2022-07-01 11:36:50 -04:00
for (i=0 ; i < num_all_fds ; i++) {
/* We want to remove the fd from the fdtab
* but we flag it to disown because the
* close is performed by the engine itself
*/
fdtab[all_fd[i]].state |= FD_DISOWN;
fd_delete(all_fd[i]);
}
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
/* Now we can safely call SSL_free, no more pending job in engines */
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
SSL_free(ssl);
REORG: ssl-sock: move the sslconns/totalsslconns counters to global These two counters were the only ones not in the global struct, while the SSL freq counters or the req counts are already in it, this forces stats.c to include ssl_sock just to know about them. Let's move them over there with their friends. This reduces from 408 to 384 the number of includes of opensslconf.h.
2021-10-06 06:15:18 -04:00
_HA_ATOMIC_DEC(&global.sslconns);
CLEANUP: atomic/tree-wide: replace single increments/decrements with inc/dec This patch replaces roughly all occurrences of an HA_ATOMIC_ADD(&foo, 1) or HA_ATOMIC_SUB(&foo, 1) with the equivalent HA_ATOMIC_INC(&foo) and HA_ATOMIC_DEC(&foo) respectively. These are 507 changes over 45 files.
2021-04-06 07:53:36 -04:00
_HA_ATOMIC_DEC(&jobs);
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
}
/*
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
* function used to manage a returned SSL_ERROR_WANT_ASYNC
* and enable/disable polling for async fds
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
*/
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
static inline void ssl_async_process_fds(struct ssl_sock_ctx *ctx)
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
{
MINOR: fd: pass the iocb and owner to fd_insert() fd_insert() is currently called just after setting the owner and iocb, but proceeding like this prevents the operation from being atomic and requires a lock to protect the maxfd computation in another thread from meeting an incompletely initialized FD and computing a wrong maxfd. Fortunately for now all fdtab[].owner are set before calling fd_insert(), and the first lock in fd_insert() enforces a memory barrier so the code is safe. This patch moves the initialization of the owner and iocb to fd_insert() so that the function will be able to properly arrange its operations and remain safe even when modified to become lockless. There's no other change beyond the internal API.
2018-01-25 01:22:13 -05:00
OSSL_ASYNC_FD add_fd[32];
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
OSSL_ASYNC_FD del_fd[32];
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
SSL *ssl = ctx->ssl;
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
size_t num_add_fds = 0;
size_t num_del_fds = 0;
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
int i;
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
SSL_get_changed_async_fds(ssl, NULL, &num_add_fds, NULL,
&num_del_fds);
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
if (num_add_fds > 32 || num_del_fds > 32) {
send_log(NULL, LOG_EMERG, "haproxy: openssl returns too many async fds. It seems a bug. Process may crash\n");
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
return;
}
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
SSL_get_changed_async_fds(ssl, add_fd, &num_add_fds, del_fd, &num_del_fds);
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
/* We remove unused fds from the fdtab */
BUG/MEDIUM: ssl/fd: unexpected fd close using async engine Before 2.3, after an async crypto processing or on session close, the engine async file's descriptors were removed from the fdtab but not closed because it is the engine which has created the file descriptor, and it is responsible for closing it. In 2.3 the fd_remove() call was replaced by fd_stop_both() which stops the polling but does not remove the fd from the fdtab and the fd remains indefinitively in the fdtab. A simple replacement by fd_delete() is not a valid fix because fd_delete() removes the fd from the fdtab but also closes the fd. And the fd will be closed twice: by the haproxy's core and by the engine itself. Instead, let's set FD_DISOWN on the FD before calling fd_delete() which will take care of not closing it. This patch must be backported on branches >= 2.3, and it relies on this previous patch: MINOR: fd: add a new FD_DISOWN flag to prevent from closing a deleted FD As mentioned in the patch above, a different flag will be needed in 2.3.
2022-07-01 11:36:50 -04:00
for (i=0 ; i < num_del_fds ; i++) {
/* We want to remove the fd from the fdtab
* but we flag it to disown because the
* close is performed by the engine itself
*/
fdtab[del_fd[i]].state |= FD_DISOWN;
fd_delete(del_fd[i]);
}
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
/* We add new fds to the fdtab */
for (i=0 ; i < num_add_fds ; i++) {
MEDIUM: fd: make fd_insert() take local thread masks fd_insert() was already given a thread group ID and a global thread mask. Now we're changing the few callers to take the group-local thread mask instead. It's passed directly into the FD's thread mask. Just like for previous commit, it must not change anything when a single group is configured.
2022-07-07 02:29:00 -04:00
fd_insert(add_fd[i], ctx, ssl_async_fd_handler, tgid, ti->ltid_bit);
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
}
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
num_add_fds = 0;
SSL_get_all_async_fds(ssl, NULL, &num_add_fds);
if (num_add_fds > 32) {
send_log(NULL, LOG_EMERG, "haproxy: openssl returns too many async fds. It seems a bug. Process may crash\n");
return;
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
}
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
/* We activate the polling for all known async fds */
SSL_get_all_async_fds(ssl, add_fd, &num_add_fds);
BUG/MAJOR: ssl: fix segfault on connection close using async engines. This patch ensure that the ASYNC fd handlers won't be wake up too early, disabling the event cache for this fd on connection close and when a WANT_ASYNC is rised by Openssl. The calls to SSL_read/SSL_write/SSL_do_handshake before rising a real read event from the ASYNC fd, generated an EAGAIN followed by a context switch for some engines, or a blocked read for the others. On connection close it resulted in a too early call to SSL_free followed by a segmentation fault.
2017-05-31 06:02:53 -04:00
for (i=0 ; i < num_add_fds ; i++) {
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
fd_want_recv(add_fd[i]);
BUG/MAJOR: ssl: fix segfault on connection close using async engines. This patch ensure that the ASYNC fd handlers won't be wake up too early, disabling the event cache for this fd on connection close and when a WANT_ASYNC is rised by Openssl. The calls to SSL_read/SSL_write/SSL_do_handshake before rising a real read event from the ASYNC fd, generated an EAGAIN followed by a context switch for some engines, or a blocked read for the others. On connection close it resulted in a too early call to SSL_free followed by a segmentation fault.
2017-05-31 06:02:53 -04:00
/* To ensure that the fd cache won't be used
* We'll prefer to catch a real RD event
* because handling an EAGAIN on this fd will
* result in a context switch and also
* some engines uses a fd in blocking mode.
*/
fd_cant_recv(add_fd[i]);
}
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
}
#endif
MINOR: ssl: Remove call to HMAC_Init_ex with OpenSSLv3 HMAC_Init_ex being a function that acts on a low-level HMAC_CTX structure was marked as deprecated in OpenSSLv3. This patch replaces this call by EVP_MAC_CTX_set_params, as advised in the migration_guide, and uses the new OSSL_PARAM mechanism to configure the MAC context, as described in the EVP_MAC and EVP_MAC-HMAC manpages.
2022-02-08 11:45:59 -05:00
/*
* Initialize an HMAC context <hctx> using the <key> and <md> parameters.
* Returns -1 in case of error, 1 otherwise.
*/
static int ssl_hmac_init(MAC_CTX *hctx, unsigned char *key, int key_len, const EVP_MD *md)
{
#ifdef HAVE_OSSL_PARAM
OSSL_PARAM params[3];
params[0] = OSSL_PARAM_construct_octet_string(OSSL_MAC_PARAM_KEY, key, key_len);
params[1] = OSSL_PARAM_construct_utf8_string(OSSL_MAC_PARAM_DIGEST, (char*)EVP_MD_name(md), 0);
params[2] = OSSL_PARAM_construct_end();
if (EVP_MAC_CTX_set_params(hctx, params) == 0)
return -1; /* error in mac initialisation */
#else
HMAC_Init_ex(hctx, key, key_len, md, NULL);
#endif
return 1;
}
MEDIUM: Add support for configurable TLS ticket keys Until now, the TLS ticket keys couldn't have been configured and shared between multiple instances or multiple servers running HAproxy. The result was that if a request got a TLS ticket from one instance/server and it hits another one afterwards, it will have to go through the full SSL handshake and negotation. This patch enables adding a ticket file to the bind line, which will be used for all SSL contexts created from that bind line. We can use the same file on all instances or servers to mitigate this issue and have consistent TLS tickets assigned. Clients will no longer have to negotiate every time they change the handling process. Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
2015-02-27 13:56:49 -05:00
#if (defined SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB && TLS_TICKETS_NO > 0)
MINOR: ssl: Remove call to SSL_CTX_set_tlsext_ticket_key_cb with OpenSSLv3 SSL_CTX_set_tlsext_ticket_key_cb was deprecated on OpenSSLv3 because it uses an HMAC_pointer which is deprecated as well. According to the v3's manpage it should be replaced by SSL_CTX_set_tlsext_ticket_key_evp_cb which uses a EVP_MAC_CTX pointer. This new callback was introduced in OpenSSLv3 so we need to keep the two calls in the source base and to split the usage depending on the OpenSSL version.
2022-02-08 11:45:58 -05:00
static int ssl_tlsext_ticket_key_cb(SSL *s, unsigned char key_name[16], unsigned char *iv, EVP_CIPHER_CTX *ectx, MAC_CTX *hctx, int enc)
MEDIUM: Add support for configurable TLS ticket keys Until now, the TLS ticket keys couldn't have been configured and shared between multiple instances or multiple servers running HAproxy. The result was that if a request got a TLS ticket from one instance/server and it hits another one afterwards, it will have to go through the full SSL handshake and negotation. This patch enables adding a ticket file to the bind line, which will be used for all SSL contexts created from that bind line. We can use the same file on all instances or servers to mitigate this issue and have consistent TLS tickets assigned. Clients will no longer have to negotiate every time they change the handling process. Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
2015-02-27 13:56:49 -05:00
{
BUG/MINOR: quic: Possible crash with "tls-ticket-keys" on QUIC bind lines ssl_tlsext_ticket_key_cb() is called when "tls-ticket-keys" option is used on a "bind" line. It needs to have an access to the TLS ticket keys which have been stored into the listener bind_conf struct. The fix consists in nitializing the <ref> variable (references to TLS secret keys) the correct way when this callback is called for a QUIC connection. The bind_conf struct is store into the quic_conn object (QUIC connection). This issue may be in relation with GH #1851. Thank you for @tasavis for the report. Must be backported to 2.6.
2022-09-06 11:04:55 -04:00
struct tls_keys_ref *ref = NULL;
MINOR: ssl: add support of aes256 bits ticket keys on file and cli. Openssl switched from aes128 to aes256 since may 2016 to compute tls ticket secrets used by default. But Haproxy still handled only 128 bits keys for both tls key file and CLI. This patch permit the user to set aes256 keys throught CLI or the key file (80 bytes encoded in base64) in the same way that aes128 keys were handled (48 bytes encoded in base64): - first 16 bytes for the key name - next 16/32 bytes for aes 128/256 key bits key - last 16/32 bytes for hmac 128/256 bits Both sizes are now supported (but keys from same file must be of the same size and can but updated via CLI only using a key of the same size). Note: This feature need the fix "dec func ignores padding for output size checking."
2019-01-10 11:51:55 -05:00
union tls_sess_key *keys;
MEDIUM: Add support for configurable TLS ticket keys Until now, the TLS ticket keys couldn't have been configured and shared between multiple instances or multiple servers running HAproxy. The result was that if a request got a TLS ticket from one instance/server and it hits another one afterwards, it will have to go through the full SSL handshake and negotation. This patch enables adding a ticket file to the bind line, which will be used for all SSL contexts created from that bind line. We can use the same file on all instances or servers to mitigate this issue and have consistent TLS tickets assigned. Clients will no longer have to negotiate every time they change the handling process. Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
2015-02-27 13:56:49 -05:00
int head;
int i;
BUG/MINOR: ssl/threads: Make management of the TLS ticket keys files thread-safe A TLS ticket keys file can be updated on the CLI and used in same time. So we need to protect it to be sure all accesses are thread-safe. Because updates are infrequent, a R/W lock has been used. This patch must be backported in 1.8
2018-02-16 05:23:49 -05:00
int ret = -1; /* error by default */
BUG/MINOR: quic: Possible crash with "tls-ticket-keys" on QUIC bind lines ssl_tlsext_ticket_key_cb() is called when "tls-ticket-keys" option is used on a "bind" line. It needs to have an access to the TLS ticket keys which have been stored into the listener bind_conf struct. The fix consists in nitializing the <ref> variable (references to TLS secret keys) the correct way when this callback is called for a QUIC connection. The bind_conf struct is store into the quic_conn object (QUIC connection). This issue may be in relation with GH #1851. Thank you for @tasavis for the report. Must be backported to 2.6.
2022-09-06 11:04:55 -04:00
struct connection *conn = SSL_get_ex_data(s, ssl_app_data_index);
#ifdef USE_QUIC
struct quic_conn *qc = SSL_get_ex_data(s, ssl_qc_app_data_index);
#endif
if (conn)
ref = __objt_listener(conn->target)->bind_conf->keys_ref;
#ifdef USE_QUIC
else if (qc)
ref = qc->li->bind_conf->keys_ref;
#endif
if (!ref) {
/* must never happen */
ABORT_NOW();
}
MEDIUM: Add support for configurable TLS ticket keys Until now, the TLS ticket keys couldn't have been configured and shared between multiple instances or multiple servers running HAproxy. The result was that if a request got a TLS ticket from one instance/server and it hits another one afterwards, it will have to go through the full SSL handshake and negotation. This patch enables adding a ticket file to the bind line, which will be used for all SSL contexts created from that bind line. We can use the same file on all instances or servers to mitigate this issue and have consistent TLS tickets assigned. Clients will no longer have to negotiate every time they change the handling process. Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
2015-02-27 13:56:49 -05:00
BUG/MINOR: ssl/threads: Make management of the TLS ticket keys files thread-safe A TLS ticket keys file can be updated on the CLI and used in same time. So we need to protect it to be sure all accesses are thread-safe. Because updates are infrequent, a R/W lock has been used. This patch must be backported in 1.8
2018-02-16 05:23:49 -05:00
HA_RWLOCK_RDLOCK(TLSKEYS_REF_LOCK, &ref->lock);
keys = ref->tlskeys;
head = ref->tls_ticket_enc_index;
MEDIUM: Add support for configurable TLS ticket keys Until now, the TLS ticket keys couldn't have been configured and shared between multiple instances or multiple servers running HAproxy. The result was that if a request got a TLS ticket from one instance/server and it hits another one afterwards, it will have to go through the full SSL handshake and negotation. This patch enables adding a ticket file to the bind line, which will be used for all SSL contexts created from that bind line. We can use the same file on all instances or servers to mitigate this issue and have consistent TLS tickets assigned. Clients will no longer have to negotiate every time they change the handling process. Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
2015-02-27 13:56:49 -05:00
if (enc) {
memcpy(key_name, keys[head].name, 16);
if(!RAND_pseudo_bytes(iv, EVP_MAX_IV_LENGTH))
BUG/MINOR: ssl/threads: Make management of the TLS ticket keys files thread-safe A TLS ticket keys file can be updated on the CLI and used in same time. So we need to protect it to be sure all accesses are thread-safe. Because updates are infrequent, a R/W lock has been used. This patch must be backported in 1.8
2018-02-16 05:23:49 -05:00
goto end;
MEDIUM: Add support for configurable TLS ticket keys Until now, the TLS ticket keys couldn't have been configured and shared between multiple instances or multiple servers running HAproxy. The result was that if a request got a TLS ticket from one instance/server and it hits another one afterwards, it will have to go through the full SSL handshake and negotation. This patch enables adding a ticket file to the bind line, which will be used for all SSL contexts created from that bind line. We can use the same file on all instances or servers to mitigate this issue and have consistent TLS tickets assigned. Clients will no longer have to negotiate every time they change the handling process. Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
2015-02-27 13:56:49 -05:00
MINOR: ssl: add support of aes256 bits ticket keys on file and cli. Openssl switched from aes128 to aes256 since may 2016 to compute tls ticket secrets used by default. But Haproxy still handled only 128 bits keys for both tls key file and CLI. This patch permit the user to set aes256 keys throught CLI or the key file (80 bytes encoded in base64) in the same way that aes128 keys were handled (48 bytes encoded in base64): - first 16 bytes for the key name - next 16/32 bytes for aes 128/256 key bits key - last 16/32 bytes for hmac 128/256 bits Both sizes are now supported (but keys from same file must be of the same size and can but updated via CLI only using a key of the same size). Note: This feature need the fix "dec func ignores padding for output size checking."
2019-01-10 11:51:55 -05:00
if (ref->key_size_bits == 128) {
MEDIUM: Add support for configurable TLS ticket keys Until now, the TLS ticket keys couldn't have been configured and shared between multiple instances or multiple servers running HAproxy. The result was that if a request got a TLS ticket from one instance/server and it hits another one afterwards, it will have to go through the full SSL handshake and negotation. This patch enables adding a ticket file to the bind line, which will be used for all SSL contexts created from that bind line. We can use the same file on all instances or servers to mitigate this issue and have consistent TLS tickets assigned. Clients will no longer have to negotiate every time they change the handling process. Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
2015-02-27 13:56:49 -05:00
MINOR: ssl: add support of aes256 bits ticket keys on file and cli. Openssl switched from aes128 to aes256 since may 2016 to compute tls ticket secrets used by default. But Haproxy still handled only 128 bits keys for both tls key file and CLI. This patch permit the user to set aes256 keys throught CLI or the key file (80 bytes encoded in base64) in the same way that aes128 keys were handled (48 bytes encoded in base64): - first 16 bytes for the key name - next 16/32 bytes for aes 128/256 key bits key - last 16/32 bytes for hmac 128/256 bits Both sizes are now supported (but keys from same file must be of the same size and can but updated via CLI only using a key of the same size). Note: This feature need the fix "dec func ignores padding for output size checking."
2019-01-10 11:51:55 -05:00
if(!EVP_EncryptInit_ex(ectx, EVP_aes_128_cbc(), NULL, keys[head].key_128.aes_key, iv))
goto end;
MINOR: ssl: Remove call to HMAC_Init_ex with OpenSSLv3 HMAC_Init_ex being a function that acts on a low-level HMAC_CTX structure was marked as deprecated in OpenSSLv3. This patch replaces this call by EVP_MAC_CTX_set_params, as advised in the migration_guide, and uses the new OSSL_PARAM mechanism to configure the MAC context, as described in the EVP_MAC and EVP_MAC-HMAC manpages.
2022-02-08 11:45:59 -05:00
if (ssl_hmac_init(hctx, keys[head].key_128.hmac_key, 16, TLS_TICKET_HASH_FUNCT()) < 0)
goto end;
MINOR: ssl: add support of aes256 bits ticket keys on file and cli. Openssl switched from aes128 to aes256 since may 2016 to compute tls ticket secrets used by default. But Haproxy still handled only 128 bits keys for both tls key file and CLI. This patch permit the user to set aes256 keys throught CLI or the key file (80 bytes encoded in base64) in the same way that aes128 keys were handled (48 bytes encoded in base64): - first 16 bytes for the key name - next 16/32 bytes for aes 128/256 key bits key - last 16/32 bytes for hmac 128/256 bits Both sizes are now supported (but keys from same file must be of the same size and can but updated via CLI only using a key of the same size). Note: This feature need the fix "dec func ignores padding for output size checking."
2019-01-10 11:51:55 -05:00
ret = 1;
}
else if (ref->key_size_bits == 256 ) {
if(!EVP_EncryptInit_ex(ectx, EVP_aes_256_cbc(), NULL, keys[head].key_256.aes_key, iv))
goto end;
MINOR: ssl: Remove call to HMAC_Init_ex with OpenSSLv3 HMAC_Init_ex being a function that acts on a low-level HMAC_CTX structure was marked as deprecated in OpenSSLv3. This patch replaces this call by EVP_MAC_CTX_set_params, as advised in the migration_guide, and uses the new OSSL_PARAM mechanism to configure the MAC context, as described in the EVP_MAC and EVP_MAC-HMAC manpages.
2022-02-08 11:45:59 -05:00
if (ssl_hmac_init(hctx, keys[head].key_256.hmac_key, 32, TLS_TICKET_HASH_FUNCT()) < 0)
goto end;
MINOR: ssl: add support of aes256 bits ticket keys on file and cli. Openssl switched from aes128 to aes256 since may 2016 to compute tls ticket secrets used by default. But Haproxy still handled only 128 bits keys for both tls key file and CLI. This patch permit the user to set aes256 keys throught CLI or the key file (80 bytes encoded in base64) in the same way that aes128 keys were handled (48 bytes encoded in base64): - first 16 bytes for the key name - next 16/32 bytes for aes 128/256 key bits key - last 16/32 bytes for hmac 128/256 bits Both sizes are now supported (but keys from same file must be of the same size and can but updated via CLI only using a key of the same size). Note: This feature need the fix "dec func ignores padding for output size checking."
2019-01-10 11:51:55 -05:00
ret = 1;
}
MEDIUM: Add support for configurable TLS ticket keys Until now, the TLS ticket keys couldn't have been configured and shared between multiple instances or multiple servers running HAproxy. The result was that if a request got a TLS ticket from one instance/server and it hits another one afterwards, it will have to go through the full SSL handshake and negotation. This patch enables adding a ticket file to the bind line, which will be used for all SSL contexts created from that bind line. We can use the same file on all instances or servers to mitigate this issue and have consistent TLS tickets assigned. Clients will no longer have to negotiate every time they change the handling process. Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
2015-02-27 13:56:49 -05:00
} else {
for (i = 0; i < TLS_TICKETS_NO; i++) {
if (!memcmp(key_name, keys[(head + i) % TLS_TICKETS_NO].name, 16))
goto found;
}
BUG/MINOR: ssl/threads: Make management of the TLS ticket keys files thread-safe A TLS ticket keys file can be updated on the CLI and used in same time. So we need to protect it to be sure all accesses are thread-safe. Because updates are infrequent, a R/W lock has been used. This patch must be backported in 1.8
2018-02-16 05:23:49 -05:00
ret = 0;
goto end;
MEDIUM: Add support for configurable TLS ticket keys Until now, the TLS ticket keys couldn't have been configured and shared between multiple instances or multiple servers running HAproxy. The result was that if a request got a TLS ticket from one instance/server and it hits another one afterwards, it will have to go through the full SSL handshake and negotation. This patch enables adding a ticket file to the bind line, which will be used for all SSL contexts created from that bind line. We can use the same file on all instances or servers to mitigate this issue and have consistent TLS tickets assigned. Clients will no longer have to negotiate every time they change the handling process. Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
2015-02-27 13:56:49 -05:00
BUG/MINOR: ssl/threads: Make management of the TLS ticket keys files thread-safe A TLS ticket keys file can be updated on the CLI and used in same time. So we need to protect it to be sure all accesses are thread-safe. Because updates are infrequent, a R/W lock has been used. This patch must be backported in 1.8
2018-02-16 05:23:49 -05:00
found:
MINOR: ssl: add support of aes256 bits ticket keys on file and cli. Openssl switched from aes128 to aes256 since may 2016 to compute tls ticket secrets used by default. But Haproxy still handled only 128 bits keys for both tls key file and CLI. This patch permit the user to set aes256 keys throught CLI or the key file (80 bytes encoded in base64) in the same way that aes128 keys were handled (48 bytes encoded in base64): - first 16 bytes for the key name - next 16/32 bytes for aes 128/256 key bits key - last 16/32 bytes for hmac 128/256 bits Both sizes are now supported (but keys from same file must be of the same size and can but updated via CLI only using a key of the same size). Note: This feature need the fix "dec func ignores padding for output size checking."
2019-01-10 11:51:55 -05:00
if (ref->key_size_bits == 128) {
MINOR: ssl: Remove call to HMAC_Init_ex with OpenSSLv3 HMAC_Init_ex being a function that acts on a low-level HMAC_CTX structure was marked as deprecated in OpenSSLv3. This patch replaces this call by EVP_MAC_CTX_set_params, as advised in the migration_guide, and uses the new OSSL_PARAM mechanism to configure the MAC context, as described in the EVP_MAC and EVP_MAC-HMAC manpages.
2022-02-08 11:45:59 -05:00
if (ssl_hmac_init(hctx, keys[(head + i) % TLS_TICKETS_NO].key_128.hmac_key, 16, TLS_TICKET_HASH_FUNCT()) < 0)
goto end;
MINOR: ssl: add support of aes256 bits ticket keys on file and cli. Openssl switched from aes128 to aes256 since may 2016 to compute tls ticket secrets used by default. But Haproxy still handled only 128 bits keys for both tls key file and CLI. This patch permit the user to set aes256 keys throught CLI or the key file (80 bytes encoded in base64) in the same way that aes128 keys were handled (48 bytes encoded in base64): - first 16 bytes for the key name - next 16/32 bytes for aes 128/256 key bits key - last 16/32 bytes for hmac 128/256 bits Both sizes are now supported (but keys from same file must be of the same size and can but updated via CLI only using a key of the same size). Note: This feature need the fix "dec func ignores padding for output size checking."
2019-01-10 11:51:55 -05:00
if(!EVP_DecryptInit_ex(ectx, EVP_aes_128_cbc(), NULL, keys[(head + i) % TLS_TICKETS_NO].key_128.aes_key, iv))
goto end;
/* 2 for key renewal, 1 if current key is still valid */
ret = i ? 2 : 1;
}
else if (ref->key_size_bits == 256) {
MINOR: ssl: Remove call to HMAC_Init_ex with OpenSSLv3 HMAC_Init_ex being a function that acts on a low-level HMAC_CTX structure was marked as deprecated in OpenSSLv3. This patch replaces this call by EVP_MAC_CTX_set_params, as advised in the migration_guide, and uses the new OSSL_PARAM mechanism to configure the MAC context, as described in the EVP_MAC and EVP_MAC-HMAC manpages.
2022-02-08 11:45:59 -05:00
if (ssl_hmac_init(hctx, keys[(head + i) % TLS_TICKETS_NO].key_256.hmac_key, 32, TLS_TICKET_HASH_FUNCT()) < 0)
goto end;
MINOR: ssl: add support of aes256 bits ticket keys on file and cli. Openssl switched from aes128 to aes256 since may 2016 to compute tls ticket secrets used by default. But Haproxy still handled only 128 bits keys for both tls key file and CLI. This patch permit the user to set aes256 keys throught CLI or the key file (80 bytes encoded in base64) in the same way that aes128 keys were handled (48 bytes encoded in base64): - first 16 bytes for the key name - next 16/32 bytes for aes 128/256 key bits key - last 16/32 bytes for hmac 128/256 bits Both sizes are now supported (but keys from same file must be of the same size and can but updated via CLI only using a key of the same size). Note: This feature need the fix "dec func ignores padding for output size checking."
2019-01-10 11:51:55 -05:00
if(!EVP_DecryptInit_ex(ectx, EVP_aes_256_cbc(), NULL, keys[(head + i) % TLS_TICKETS_NO].key_256.aes_key, iv))
goto end;
/* 2 for key renewal, 1 if current key is still valid */
ret = i ? 2 : 1;
}
MEDIUM: Add support for configurable TLS ticket keys Until now, the TLS ticket keys couldn't have been configured and shared between multiple instances or multiple servers running HAproxy. The result was that if a request got a TLS ticket from one instance/server and it hits another one afterwards, it will have to go through the full SSL handshake and negotation. This patch enables adding a ticket file to the bind line, which will be used for all SSL contexts created from that bind line. We can use the same file on all instances or servers to mitigate this issue and have consistent TLS tickets assigned. Clients will no longer have to negotiate every time they change the handling process. Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
2015-02-27 13:56:49 -05:00
}
MINOR: ssl: add support of aes256 bits ticket keys on file and cli. Openssl switched from aes128 to aes256 since may 2016 to compute tls ticket secrets used by default. But Haproxy still handled only 128 bits keys for both tls key file and CLI. This patch permit the user to set aes256 keys throught CLI or the key file (80 bytes encoded in base64) in the same way that aes128 keys were handled (48 bytes encoded in base64): - first 16 bytes for the key name - next 16/32 bytes for aes 128/256 key bits key - last 16/32 bytes for hmac 128/256 bits Both sizes are now supported (but keys from same file must be of the same size and can but updated via CLI only using a key of the same size). Note: This feature need the fix "dec func ignores padding for output size checking."
2019-01-10 11:51:55 -05:00
BUG/MINOR: ssl/threads: Make management of the TLS ticket keys files thread-safe A TLS ticket keys file can be updated on the CLI and used in same time. So we need to protect it to be sure all accesses are thread-safe. Because updates are infrequent, a R/W lock has been used. This patch must be backported in 1.8
2018-02-16 05:23:49 -05:00
end:
HA_RWLOCK_RDUNLOCK(TLSKEYS_REF_LOCK, &ref->lock);
return ret;
MEDIUM: Add support for configurable TLS ticket keys Until now, the TLS ticket keys couldn't have been configured and shared between multiple instances or multiple servers running HAproxy. The result was that if a request got a TLS ticket from one instance/server and it hits another one afterwards, it will have to go through the full SSL handshake and negotation. This patch enables adding a ticket file to the bind line, which will be used for all SSL contexts created from that bind line. We can use the same file on all instances or servers to mitigate this issue and have consistent TLS tickets assigned. Clients will no longer have to negotiate every time they change the handling process. Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
2015-02-27 13:56:49 -05:00
}
MEDIUM: Add support for updating TLS ticket keys via socket Until now, HAproxy needed to be restarted to change the TLS ticket keys. With this patch, the TLS keys can be updated on a per-file basis using the admin socket. Two new socket commands have been introduced: "show tls-keys" and "set ssl tls-keys". Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
2015-05-09 02:46:01 -04:00
struct tls_keys_ref *tlskeys_ref_lookup(const char *filename)
{
struct tls_keys_ref *ref;
list_for_each_entry(ref, &tlskeys_reference, list)
if (ref->filename && strcmp(filename, ref->filename) == 0)
return ref;
return NULL;
}
struct tls_keys_ref *tlskeys_ref_lookupid(int unique_id)
{
struct tls_keys_ref *ref;
list_for_each_entry(ref, &tlskeys_reference, list)
if (ref->unique_id == unique_id)
return ref;
return NULL;
}
CLEANUP: assorted typo fixes in the code and comments These are mostly comments in the code. A few error messages were fixed and are of low enough importance not to deserve a backport. Some regtests were also fixed.
2020-03-10 03:06:11 -04:00
/* Update the key into ref: if keysize doesn't
MINOR: ssl: add support of aes256 bits ticket keys on file and cli. Openssl switched from aes128 to aes256 since may 2016 to compute tls ticket secrets used by default. But Haproxy still handled only 128 bits keys for both tls key file and CLI. This patch permit the user to set aes256 keys throught CLI or the key file (80 bytes encoded in base64) in the same way that aes128 keys were handled (48 bytes encoded in base64): - first 16 bytes for the key name - next 16/32 bytes for aes 128/256 key bits key - last 16/32 bytes for hmac 128/256 bits Both sizes are now supported (but keys from same file must be of the same size and can but updated via CLI only using a key of the same size). Note: This feature need the fix "dec func ignores padding for output size checking."
2019-01-10 11:51:55 -05:00
* match existing ones, this function returns -1
* else it returns 0 on success.
*/
int ssl_sock_update_tlskey_ref(struct tls_keys_ref *ref,
MAJOR: chunks: replace struct chunk with struct buffer Now all the code used to manipulate chunks uses a struct buffer instead. The functions are still called "chunk*", and some of them will progressively move to the generic buffer handling code as they are cleaned up.
2018-07-13 05:56:34 -04:00
struct buffer *tlskey)
BUG/MINOR: ssl/threads: Make management of the TLS ticket keys files thread-safe A TLS ticket keys file can be updated on the CLI and used in same time. So we need to protect it to be sure all accesses are thread-safe. Because updates are infrequent, a R/W lock has been used. This patch must be backported in 1.8
2018-02-16 05:23:49 -05:00
{
MINOR: ssl: add support of aes256 bits ticket keys on file and cli. Openssl switched from aes128 to aes256 since may 2016 to compute tls ticket secrets used by default. But Haproxy still handled only 128 bits keys for both tls key file and CLI. This patch permit the user to set aes256 keys throught CLI or the key file (80 bytes encoded in base64) in the same way that aes128 keys were handled (48 bytes encoded in base64): - first 16 bytes for the key name - next 16/32 bytes for aes 128/256 key bits key - last 16/32 bytes for hmac 128/256 bits Both sizes are now supported (but keys from same file must be of the same size and can but updated via CLI only using a key of the same size). Note: This feature need the fix "dec func ignores padding for output size checking."
2019-01-10 11:51:55 -05:00
if (ref->key_size_bits == 128) {
if (tlskey->data != sizeof(struct tls_sess_key_128))
return -1;
}
else if (ref->key_size_bits == 256) {
if (tlskey->data != sizeof(struct tls_sess_key_256))
return -1;
}
else
return -1;
BUG/MINOR: ssl/threads: Make management of the TLS ticket keys files thread-safe A TLS ticket keys file can be updated on the CLI and used in same time. So we need to protect it to be sure all accesses are thread-safe. Because updates are infrequent, a R/W lock has been used. This patch must be backported in 1.8
2018-02-16 05:23:49 -05:00
HA_RWLOCK_WRLOCK(TLSKEYS_REF_LOCK, &ref->lock);
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
memcpy((char *) (ref->tlskeys + ((ref->tls_ticket_enc_index + 2) % TLS_TICKETS_NO)),
tlskey->area, tlskey->data);
BUG/MINOR: ssl/threads: Make management of the TLS ticket keys files thread-safe A TLS ticket keys file can be updated on the CLI and used in same time. So we need to protect it to be sure all accesses are thread-safe. Because updates are infrequent, a R/W lock has been used. This patch must be backported in 1.8
2018-02-16 05:23:49 -05:00
ref->tls_ticket_enc_index = (ref->tls_ticket_enc_index + 1) % TLS_TICKETS_NO;
HA_RWLOCK_WRUNLOCK(TLSKEYS_REF_LOCK, &ref->lock);
MINOR: ssl: add support of aes256 bits ticket keys on file and cli. Openssl switched from aes128 to aes256 since may 2016 to compute tls ticket secrets used by default. But Haproxy still handled only 128 bits keys for both tls key file and CLI. This patch permit the user to set aes256 keys throught CLI or the key file (80 bytes encoded in base64) in the same way that aes128 keys were handled (48 bytes encoded in base64): - first 16 bytes for the key name - next 16/32 bytes for aes 128/256 key bits key - last 16/32 bytes for hmac 128/256 bits Both sizes are now supported (but keys from same file must be of the same size and can but updated via CLI only using a key of the same size). Note: This feature need the fix "dec func ignores padding for output size checking."
2019-01-10 11:51:55 -05:00
return 0;
BUG/MINOR: ssl/threads: Make management of the TLS ticket keys files thread-safe A TLS ticket keys file can be updated on the CLI and used in same time. So we need to protect it to be sure all accesses are thread-safe. Because updates are infrequent, a R/W lock has been used. This patch must be backported in 1.8
2018-02-16 05:23:49 -05:00
}
MAJOR: chunks: replace struct chunk with struct buffer Now all the code used to manipulate chunks uses a struct buffer instead. The functions are still called "chunk*", and some of them will progressively move to the generic buffer handling code as they are cleaned up.
2018-07-13 05:56:34 -04:00
int ssl_sock_update_tlskey(char *filename, struct buffer *tlskey, char **err)
BUG/MINOR: ssl/threads: Make management of the TLS ticket keys files thread-safe A TLS ticket keys file can be updated on the CLI and used in same time. So we need to protect it to be sure all accesses are thread-safe. Because updates are infrequent, a R/W lock has been used. This patch must be backported in 1.8
2018-02-16 05:23:49 -05:00
{
MEDIUM: Add support for updating TLS ticket keys via socket Until now, HAproxy needed to be restarted to change the TLS ticket keys. With this patch, the TLS keys can be updated on a per-file basis using the admin socket. Two new socket commands have been introduced: "show tls-keys" and "set ssl tls-keys". Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
2015-05-09 02:46:01 -04:00
struct tls_keys_ref *ref = tlskeys_ref_lookup(filename);
if(!ref) {
memprintf(err, "Unable to locate the referenced filename: %s", filename);
return 1;
}
MINOR: ssl: add support of aes256 bits ticket keys on file and cli. Openssl switched from aes128 to aes256 since may 2016 to compute tls ticket secrets used by default. But Haproxy still handled only 128 bits keys for both tls key file and CLI. This patch permit the user to set aes256 keys throught CLI or the key file (80 bytes encoded in base64) in the same way that aes128 keys were handled (48 bytes encoded in base64): - first 16 bytes for the key name - next 16/32 bytes for aes 128/256 key bits key - last 16/32 bytes for hmac 128/256 bits Both sizes are now supported (but keys from same file must be of the same size and can but updated via CLI only using a key of the same size). Note: This feature need the fix "dec func ignores padding for output size checking."
2019-01-10 11:51:55 -05:00
if (ssl_sock_update_tlskey_ref(ref, tlskey) < 0) {
memprintf(err, "Invalid key size");
return 1;
}
MEDIUM: Add support for updating TLS ticket keys via socket Until now, HAproxy needed to be restarted to change the TLS ticket keys. With this patch, the TLS keys can be updated on a per-file basis using the admin socket. Two new socket commands have been introduced: "show tls-keys" and "set ssl tls-keys". Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
2015-05-09 02:46:01 -04:00
return 0;
}
/* This function finalize the configuration parsing. Its set all the
CLEANUP: ssl: move tlskeys_finalize_config() to a post_check callback tlskeys_finalize_config() was the only reason for haproxy.c to still require ifdef and includes for ssl_sock. This one fits perfectly well in the late initializers so it was changed to be registered with hap_register_post_check().
2016-12-22 16:46:15 -05:00
* automatic ids. It's called just after the basic checks. It returns
* 0 on success otherwise ERR_*.
MEDIUM: Add support for updating TLS ticket keys via socket Until now, HAproxy needed to be restarted to change the TLS ticket keys. With this patch, the TLS keys can be updated on a per-file basis using the admin socket. Two new socket commands have been introduced: "show tls-keys" and "set ssl tls-keys". Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
2015-05-09 02:46:01 -04:00
*/
CLEANUP: ssl: move tlskeys_finalize_config() to a post_check callback tlskeys_finalize_config() was the only reason for haproxy.c to still require ifdef and includes for ssl_sock. This one fits perfectly well in the late initializers so it was changed to be registered with hap_register_post_check().
2016-12-22 16:46:15 -05:00
static int tlskeys_finalize_config(void)
MEDIUM: Add support for updating TLS ticket keys via socket Until now, HAproxy needed to be restarted to change the TLS ticket keys. With this patch, the TLS keys can be updated on a per-file basis using the admin socket. Two new socket commands have been introduced: "show tls-keys" and "set ssl tls-keys". Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
2015-05-09 02:46:01 -04:00
{
int i = 0;
struct tls_keys_ref *ref, *ref2, *ref3;
struct list tkr = LIST_HEAD_INIT(tkr);
list_for_each_entry(ref, &tlskeys_reference, list) {
if (ref->unique_id == -1) {
/* Look for the first free id. */
while (1) {
list_for_each_entry(ref2, &tlskeys_reference, list) {
if (ref2->unique_id == i) {
i++;
break;
}
}
if (&ref2->list == &tlskeys_reference)
break;
}
/* Uses the unique id and increment it for the next entry. */
ref->unique_id = i;
i++;
}
}
/* This sort the reference list by id. */
list_for_each_entry_safe(ref, ref2, &tlskeys_reference, list) {
CLEANUP: lists/tree-wide: rename some list operations to avoid some confusion The current "ADD" vs "ADDQ" is confusing because when thinking in terms of appending at the end of a list, "ADD" naturally comes to mind, but here it does the opposite, it inserts. Several times already it's been incorrectly used where ADDQ was expected, the latest of which was a fortunate accident explained in 6fa922562 ("CLEANUP: stream: explain why we queue the stream at the head of the server list"). Let's use more explicit (but slightly longer) names now: LIST_ADD -> LIST_INSERT LIST_ADDQ -> LIST_APPEND LIST_ADDED -> LIST_INLIST LIST_DEL -> LIST_DELETE The same is true for MT_LISTs, including their "TRY" variant. LIST_DEL_INIT keeps its short name to encourage to use it instead of the lazier LIST_DELETE which is often less safe. The change is large (~674 non-comment entries) but is mechanical enough to remain safe. No permutation was performed, so any out-of-tree code can easily map older names to new ones. The list doc was updated.
2021-04-21 01:32:39 -04:00
LIST_DELETE(&ref->list);
MEDIUM: Add support for updating TLS ticket keys via socket Until now, HAproxy needed to be restarted to change the TLS ticket keys. With this patch, the TLS keys can be updated on a per-file basis using the admin socket. Two new socket commands have been introduced: "show tls-keys" and "set ssl tls-keys". Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
2015-05-09 02:46:01 -04:00
list_for_each_entry(ref3, &tkr, list) {
if (ref->unique_id < ref3->unique_id) {
CLEANUP: lists/tree-wide: rename some list operations to avoid some confusion The current "ADD" vs "ADDQ" is confusing because when thinking in terms of appending at the end of a list, "ADD" naturally comes to mind, but here it does the opposite, it inserts. Several times already it's been incorrectly used where ADDQ was expected, the latest of which was a fortunate accident explained in 6fa922562 ("CLEANUP: stream: explain why we queue the stream at the head of the server list"). Let's use more explicit (but slightly longer) names now: LIST_ADD -> LIST_INSERT LIST_ADDQ -> LIST_APPEND LIST_ADDED -> LIST_INLIST LIST_DEL -> LIST_DELETE The same is true for MT_LISTs, including their "TRY" variant. LIST_DEL_INIT keeps its short name to encourage to use it instead of the lazier LIST_DELETE which is often less safe. The change is large (~674 non-comment entries) but is mechanical enough to remain safe. No permutation was performed, so any out-of-tree code can easily map older names to new ones. The list doc was updated.
2021-04-21 01:32:39 -04:00
LIST_APPEND(&ref3->list, &ref->list);
MEDIUM: Add support for updating TLS ticket keys via socket Until now, HAproxy needed to be restarted to change the TLS ticket keys. With this patch, the TLS keys can be updated on a per-file basis using the admin socket. Two new socket commands have been introduced: "show tls-keys" and "set ssl tls-keys". Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
2015-05-09 02:46:01 -04:00
break;
}
}
if (&ref3->list == &tkr)
CLEANUP: lists/tree-wide: rename some list operations to avoid some confusion The current "ADD" vs "ADDQ" is confusing because when thinking in terms of appending at the end of a list, "ADD" naturally comes to mind, but here it does the opposite, it inserts. Several times already it's been incorrectly used where ADDQ was expected, the latest of which was a fortunate accident explained in 6fa922562 ("CLEANUP: stream: explain why we queue the stream at the head of the server list"). Let's use more explicit (but slightly longer) names now: LIST_ADD -> LIST_INSERT LIST_ADDQ -> LIST_APPEND LIST_ADDED -> LIST_INLIST LIST_DEL -> LIST_DELETE The same is true for MT_LISTs, including their "TRY" variant. LIST_DEL_INIT keeps its short name to encourage to use it instead of the lazier LIST_DELETE which is often less safe. The change is large (~674 non-comment entries) but is mechanical enough to remain safe. No permutation was performed, so any out-of-tree code can easily map older names to new ones. The list doc was updated.
2021-04-21 01:32:39 -04:00
LIST_APPEND(&tkr, &ref->list);
MEDIUM: Add support for updating TLS ticket keys via socket Until now, HAproxy needed to be restarted to change the TLS ticket keys. With this patch, the TLS keys can be updated on a per-file basis using the admin socket. Two new socket commands have been introduced: "show tls-keys" and "set ssl tls-keys". Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
2015-05-09 02:46:01 -04:00
}
/* swap root */
BUILD: ssl: buggy -Werror=dangling-pointer since gcc 13.0 GCC complains about swapping 2 heads list, one local and one global. gcc -Iinclude -O2 -g -Wall -Wextra -Wundef -Wdeclaration-after-statement -Wfatal-errors -Wtype-limits -Wshift-negative-value -Wshift-overflow=2 -Wduplicated-cond -Wnull-dereference -fwrapv -Wno-address-of-packed-member -Wno-unused-label -Wno-sign-compare -Wno-unused-parameter -Wno-clobbered -Wno-missing-field-initializers -Wno-cast-function-type -Wno-string-plus-int -Wno-atomic-alignment -Werror -DDEBUG_STRICT -DDEBUG_MEMORY_POOLS -DUSE_EPOLL -DUSE_NETFILTER -DUSE_POLL -DUSE_THREAD -DUSE_BACKTRACE -DUSE_TPROXY -DUSE_LINUX_TPROXY -DUSE_LINUX_SPLICE -DUSE_LIBCRYPT -DUSE_CRYPT_H -DUSE_GETADDRINFO -DUSE_OPENSSL -DUSE_SSL -DUSE_LUA -DUSE_ACCEPT4 -DUSE_ZLIB -DUSE_CPU_AFFINITY -DUSE_TFO -DUSE_NS -DUSE_DL -DUSE_RT -DUSE_MATH -DUSE_SYSTEMD -DUSE_PRCTL -DUSE_THREAD_DUMP -DUSE_QUIC -DUSE_SHM_OPEN -DUSE_PCRE -DUSE_PCRE_JIT -I/github/home/opt/include -I/usr/include -DCONFIG_HAPROXY_VERSION=\"2.8-dev8-7d23e8d1a6db\" -DCONFIG_HAPROXY_DATE=\"2023/04/24\" -c -o src/ssl_sample.o src/ssl_sample.c In file included from include/haproxy/pool.h:29, from include/haproxy/chunk.h:31, from include/haproxy/dynbuf.h:33, from include/haproxy/channel.h:27, from include/haproxy/applet.h:29, from src/ssl_sock.c:47: src/ssl_sock.c: In function 'tlskeys_finalize_config': include/haproxy/list.h:48:88: error: storing the address of local variable 'tkr' in 'tlskeys_reference.p' [-Werror=dangling-pointer=] 48 | #define LIST_INSERT(lh, el) ({ (el)->n = (lh)->n; (el)->n->p = (lh)->n = (el); (el)->p = (lh); (el); }) | ~~~~~~~~^~~~~~ src/ssl_sock.c:1086:9: note: in expansion of macro 'LIST_INSERT' 1086 | LIST_INSERT(&tkr, &tlskeys_reference); | ^~~~~~~~~~~ compilation terminated due to -Wfatal-errors. This appears with gcc 13.0. The fix uses LIST_SPLICE() instead of inserting the head of the local list in the global list. Should fix issue #2136 .
2023-05-09 08:15:57 -04:00
LIST_SPLICE(&tlskeys_reference, &tkr);
CLEANUP: config: Return ERR_NONE from config callbacks instead of 0 Return ERR_NONE instead of 0 on success for all config callbacks that should return ERR_* codes. There is no change because ERR_NONE is a macro equals to 0. But this makes the return value more explicit.
2020-11-06 09:24:23 -05:00
return ERR_NONE;
MEDIUM: Add support for updating TLS ticket keys via socket Until now, HAproxy needed to be restarted to change the TLS ticket keys. With this patch, the TLS keys can be updated on a per-file basis using the admin socket. Two new socket commands have been introduced: "show tls-keys" and "set ssl tls-keys". Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
2015-05-09 02:46:01 -04:00
}
MEDIUM: Add support for configurable TLS ticket keys Until now, the TLS ticket keys couldn't have been configured and shared between multiple instances or multiple servers running HAproxy. The result was that if a request got a TLS ticket from one instance/server and it hits another one afterwards, it will have to go through the full SSL handshake and negotation. This patch enables adding a ticket file to the bind line, which will be used for all SSL contexts created from that bind line. We can use the same file on all instances or servers to mitigate this issue and have consistent TLS tickets assigned. Clients will no longer have to negotiate every time they change the handling process. Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
2015-02-27 13:56:49 -05:00
#endif /* SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB */
BUG/MINOR: ssl: fix OCSP build with BoringSSL 246c024 broke the build of the OCSP code with BoringSSL. Rework it a little so it could load the OCSP buffer of the ckch. Issue #322.
2019-10-14 08:51:41 -04:00
BUG/MINOR: disable dynamic OCSP load with BoringSSL it was accidently enabled on BoringSSL while actually it is not supported wla: Fix part of the issue mentionned in #895. It fixes build of boringSSL versions prior to commit https://boringssl.googlesource.com/boringssl/+/49e9f67d8b7cbeb3953b5548ad1009d15947a523 Must be backported in 2.2. Signed-off-by: William Lallemand <wlallemand@haproxy.org>
2020-10-18 00:11:50 -04:00
#if ((defined SSL_CTRL_SET_TLSEXT_STATUS_REQ_CB && !defined OPENSSL_NO_OCSP) && !defined OPENSSL_IS_BORINGSSL)
MEDIUM: ssl: basic OCSP stapling support. The support is all based on static responses. This doesn't add any request / response logic to HAProxy, but allows a way to update information through the socket interface. Currently certificates specified using "crt" or "crt-list" on "bind" lines are loaded as PEM files. For each PEM file, haproxy checks for the presence of file at the same path suffixed by ".ocsp". If such file is found, support for the TLS Certificate Status Request extension (also known as "OCSP stapling") is automatically enabled. The content of this file is optional. If not empty, it must contain a valid OCSP Response in DER format. In order to be valid an OCSP Response must comply with the following rules: it has to indicate a good status, it has to be a single response for the certificate of the PEM file, and it has to be valid at the moment of addition. If these rules are not respected the OCSP Response is ignored and a warning is emitted. In order to identify which certificate an OCSP Response applies to, the issuer's certificate is necessary. If the issuer's certificate is not found in the PEM file, it will be loaded from a file at the same path as the PEM file suffixed by ".issuer" if it exists otherwise it will fail with an error. It is possible to update an OCSP Response from the unix socket using: set ssl ocsp-response <response> This command is used to update an OCSP Response for a certificate (see "crt" on "bind" lines). Same controls are performed as during the initial loading of the response. The <response> must be passed as a base64 encoded string of the DER encoded response from the OCSP server. Example: openssl ocsp -issuer issuer.pem -cert server.pem \ -host ocsp.issuer.com:80 -respout resp.der echo "set ssl ocsp-response $(base64 -w 10000 resp.der)" | \ socat stdio /var/run/haproxy.stat This feature is automatically enabled on openssl 0.9.8h and above. This work was performed jointly by Dirkjan Bussink of GitHub and Emeric Brun of HAProxy Technologies.
2014-06-16 12:36:30 -04:00
/*
* This function enables the handling of OCSP status extension on 'ctx' if a
MINOR: ssl: load the ocsp in/from the ckch Don't try to load the files containing the issuer and the OCSP response each time we generate a SSL_CTX. The .ocsp and the .issuer are now loaded in the struct cert_key_and_chain only once and then loaded from this structure when creating a SSL_CTX.
2019-10-11 02:59:13 -04:00
* ocsp_response buffer was found in the cert_key_and_chain. To enable OCSP
* status extension, the issuer's certificate is mandatory. It should be
* present in ckch->ocsp_issuer.
MEDIUM: ssl: basic OCSP stapling support. The support is all based on static responses. This doesn't add any request / response logic to HAProxy, but allows a way to update information through the socket interface. Currently certificates specified using "crt" or "crt-list" on "bind" lines are loaded as PEM files. For each PEM file, haproxy checks for the presence of file at the same path suffixed by ".ocsp". If such file is found, support for the TLS Certificate Status Request extension (also known as "OCSP stapling") is automatically enabled. The content of this file is optional. If not empty, it must contain a valid OCSP Response in DER format. In order to be valid an OCSP Response must comply with the following rules: it has to indicate a good status, it has to be a single response for the certificate of the PEM file, and it has to be valid at the moment of addition. If these rules are not respected the OCSP Response is ignored and a warning is emitted. In order to identify which certificate an OCSP Response applies to, the issuer's certificate is necessary. If the issuer's certificate is not found in the PEM file, it will be loaded from a file at the same path as the PEM file suffixed by ".issuer" if it exists otherwise it will fail with an error. It is possible to update an OCSP Response from the unix socket using: set ssl ocsp-response <response> This command is used to update an OCSP Response for a certificate (see "crt" on "bind" lines). Same controls are performed as during the initial loading of the response. The <response> must be passed as a base64 encoded string of the DER encoded response from the OCSP server. Example: openssl ocsp -issuer issuer.pem -cert server.pem \ -host ocsp.issuer.com:80 -respout resp.der echo "set ssl ocsp-response $(base64 -w 10000 resp.der)" | \ socat stdio /var/run/haproxy.stat This feature is automatically enabled on openssl 0.9.8h and above. This work was performed jointly by Dirkjan Bussink of GitHub and Emeric Brun of HAProxy Technologies.
2014-06-16 12:36:30 -04:00
*
MINOR: ssl: load the ocsp in/from the ckch Don't try to load the files containing the issuer and the OCSP response each time we generate a SSL_CTX. The .ocsp and the .issuer are now loaded in the struct cert_key_and_chain only once and then loaded from this structure when creating a SSL_CTX.
2019-10-11 02:59:13 -04:00
* In addition, the ckch->ocsp_reponse buffer is loaded as a DER format of an
* OCSP response. If file is empty or content is not a valid OCSP response,
* OCSP status extension is enabled but OCSP response is ignored (a warning is
* displayed).
MEDIUM: ssl: basic OCSP stapling support. The support is all based on static responses. This doesn't add any request / response logic to HAProxy, but allows a way to update information through the socket interface. Currently certificates specified using "crt" or "crt-list" on "bind" lines are loaded as PEM files. For each PEM file, haproxy checks for the presence of file at the same path suffixed by ".ocsp". If such file is found, support for the TLS Certificate Status Request extension (also known as "OCSP stapling") is automatically enabled. The content of this file is optional. If not empty, it must contain a valid OCSP Response in DER format. In order to be valid an OCSP Response must comply with the following rules: it has to indicate a good status, it has to be a single response for the certificate of the PEM file, and it has to be valid at the moment of addition. If these rules are not respected the OCSP Response is ignored and a warning is emitted. In order to identify which certificate an OCSP Response applies to, the issuer's certificate is necessary. If the issuer's certificate is not found in the PEM file, it will be loaded from a file at the same path as the PEM file suffixed by ".issuer" if it exists otherwise it will fail with an error. It is possible to update an OCSP Response from the unix socket using: set ssl ocsp-response <response> This command is used to update an OCSP Response for a certificate (see "crt" on "bind" lines). Same controls are performed as during the initial loading of the response. The <response> must be passed as a base64 encoded string of the DER encoded response from the OCSP server. Example: openssl ocsp -issuer issuer.pem -cert server.pem \ -host ocsp.issuer.com:80 -respout resp.der echo "set ssl ocsp-response $(base64 -w 10000 resp.der)" | \ socat stdio /var/run/haproxy.stat This feature is automatically enabled on openssl 0.9.8h and above. This work was performed jointly by Dirkjan Bussink of GitHub and Emeric Brun of HAProxy Technologies.
2014-06-16 12:36:30 -04:00
*
* Returns 1 if no ".ocsp" file found, 0 if OCSP status extension is
CLEANUP: fix typos in the ssl_sock subsystem Fix some typos found in the code comments of the ssl_sock subsystem.
2018-11-15 12:07:59 -05:00
* successfully enabled, or -1 in other error case.
MEDIUM: ssl: basic OCSP stapling support. The support is all based on static responses. This doesn't add any request / response logic to HAProxy, but allows a way to update information through the socket interface. Currently certificates specified using "crt" or "crt-list" on "bind" lines are loaded as PEM files. For each PEM file, haproxy checks for the presence of file at the same path suffixed by ".ocsp". If such file is found, support for the TLS Certificate Status Request extension (also known as "OCSP stapling") is automatically enabled. The content of this file is optional. If not empty, it must contain a valid OCSP Response in DER format. In order to be valid an OCSP Response must comply with the following rules: it has to indicate a good status, it has to be a single response for the certificate of the PEM file, and it has to be valid at the moment of addition. If these rules are not respected the OCSP Response is ignored and a warning is emitted. In order to identify which certificate an OCSP Response applies to, the issuer's certificate is necessary. If the issuer's certificate is not found in the PEM file, it will be loaded from a file at the same path as the PEM file suffixed by ".issuer" if it exists otherwise it will fail with an error. It is possible to update an OCSP Response from the unix socket using: set ssl ocsp-response <response> This command is used to update an OCSP Response for a certificate (see "crt" on "bind" lines). Same controls are performed as during the initial loading of the response. The <response> must be passed as a base64 encoded string of the DER encoded response from the OCSP server. Example: openssl ocsp -issuer issuer.pem -cert server.pem \ -host ocsp.issuer.com:80 -respout resp.der echo "set ssl ocsp-response $(base64 -w 10000 resp.der)" | \ socat stdio /var/run/haproxy.stat This feature is automatically enabled on openssl 0.9.8h and above. This work was performed jointly by Dirkjan Bussink of GitHub and Emeric Brun of HAProxy Technologies.
2014-06-16 12:36:30 -04:00
*/
MINOR: ssl: Add certificate's path to certificate_ocsp structure In order to have some information about the frontend certificate when dumping the contents of the ocsp update tree from the cli, we could either keep a reference to a ckch_store in the certificate_ocsp structure, which might cause some dangling reference problems, or simply copy the path to the certificate in the ocsp response structure. This latter solution was chosen because of its simplicity.
2023-03-01 10:11:50 -05:00
static int ssl_sock_load_ocsp(const char *path, SSL_CTX *ctx, struct ckch_data *data, STACK_OF(X509) *chain)
MEDIUM: ssl: basic OCSP stapling support. The support is all based on static responses. This doesn't add any request / response logic to HAProxy, but allows a way to update information through the socket interface. Currently certificates specified using "crt" or "crt-list" on "bind" lines are loaded as PEM files. For each PEM file, haproxy checks for the presence of file at the same path suffixed by ".ocsp". If such file is found, support for the TLS Certificate Status Request extension (also known as "OCSP stapling") is automatically enabled. The content of this file is optional. If not empty, it must contain a valid OCSP Response in DER format. In order to be valid an OCSP Response must comply with the following rules: it has to indicate a good status, it has to be a single response for the certificate of the PEM file, and it has to be valid at the moment of addition. If these rules are not respected the OCSP Response is ignored and a warning is emitted. In order to identify which certificate an OCSP Response applies to, the issuer's certificate is necessary. If the issuer's certificate is not found in the PEM file, it will be loaded from a file at the same path as the PEM file suffixed by ".issuer" if it exists otherwise it will fail with an error. It is possible to update an OCSP Response from the unix socket using: set ssl ocsp-response <response> This command is used to update an OCSP Response for a certificate (see "crt" on "bind" lines). Same controls are performed as during the initial loading of the response. The <response> must be passed as a base64 encoded string of the DER encoded response from the OCSP server. Example: openssl ocsp -issuer issuer.pem -cert server.pem \ -host ocsp.issuer.com:80 -respout resp.der echo "set ssl ocsp-response $(base64 -w 10000 resp.der)" | \ socat stdio /var/run/haproxy.stat This feature is automatically enabled on openssl 0.9.8h and above. This work was performed jointly by Dirkjan Bussink of GitHub and Emeric Brun of HAProxy Technologies.
2014-06-16 12:36:30 -04:00
{
MINOR: ssl: resolve ocsp_issuer later The goal is to use the ckch to store data from PEM files or <payload> and only for that. This patch adresses the ckch->ocsp_issuer case. It finds issuers chain if no chain is present in the ckch in ssl_sock_put_ckch_into_ctx(), filling the ocsp_issuer from the chain must be done after. It changes the way '.issuer' is managed: it tries to load '.issuer' in ckch->ocsp_issuer first and then look for the issuer in the chain later (in ssl_sock_load_ocsp() ). "ssl-load-extra-files" without the "issuer" parameter can negate extra '.issuer' file check.
2020-02-18 09:56:39 -05:00
X509 *x, *issuer;
MEDIUM: ssl: basic OCSP stapling support. The support is all based on static responses. This doesn't add any request / response logic to HAProxy, but allows a way to update information through the socket interface. Currently certificates specified using "crt" or "crt-list" on "bind" lines are loaded as PEM files. For each PEM file, haproxy checks for the presence of file at the same path suffixed by ".ocsp". If such file is found, support for the TLS Certificate Status Request extension (also known as "OCSP stapling") is automatically enabled. The content of this file is optional. If not empty, it must contain a valid OCSP Response in DER format. In order to be valid an OCSP Response must comply with the following rules: it has to indicate a good status, it has to be a single response for the certificate of the PEM file, and it has to be valid at the moment of addition. If these rules are not respected the OCSP Response is ignored and a warning is emitted. In order to identify which certificate an OCSP Response applies to, the issuer's certificate is necessary. If the issuer's certificate is not found in the PEM file, it will be loaded from a file at the same path as the PEM file suffixed by ".issuer" if it exists otherwise it will fail with an error. It is possible to update an OCSP Response from the unix socket using: set ssl ocsp-response <response> This command is used to update an OCSP Response for a certificate (see "crt" on "bind" lines). Same controls are performed as during the initial loading of the response. The <response> must be passed as a base64 encoded string of the DER encoded response from the OCSP server. Example: openssl ocsp -issuer issuer.pem -cert server.pem \ -host ocsp.issuer.com:80 -respout resp.der echo "set ssl ocsp-response $(base64 -w 10000 resp.der)" | \ socat stdio /var/run/haproxy.stat This feature is automatically enabled on openssl 0.9.8h and above. This work was performed jointly by Dirkjan Bussink of GitHub and Emeric Brun of HAProxy Technologies.
2014-06-16 12:36:30 -04:00
int i, ret = -1;
struct certificate_ocsp *ocsp = NULL, *iocsp;
char *warn = NULL;
unsigned char *p;
MEDIUM: ssl: add minimal WolfSSL support with OpenSSL compatibility mode This adds a USE_OPENSSL_WOLFSSL option, wolfSSL must be used with the OpenSSL compatibility layer. This must be used with USE_OPENSSL=1. WolfSSL build options: ./configure --prefix=/opt/wolfssl --enable-haproxy HAProxy build options: USE_OPENSSL=1 USE_OPENSSL_WOLFSSL=1 WOLFSSL_INC=/opt/wolfssl/include/ WOLFSSL_LIB=/opt/wolfssl/lib/ ADDLIB='-Wl,-rpath=/opt/wolfssl/lib' Using at least the commit 54466b6 ("Merge pull request #5810 from Uriah-wolfSSL/haproxy-integration") from WolfSSL. (2022-11-23). This is still to be improved, reg-tests are not supported yet, and more tests are to be done. Signed-off-by: William Lallemand <wlallemand@haproxy.org>
2022-11-23 10:41:25 -05:00
#ifndef USE_OPENSSL_WOLFSSL
BUILD: ssl: Build with new cryptographic library AWS-LC This adds a new option for the Makefile USE_OPENSSL_AWSLC, and update the documentation with instructions to use HAProxy with AWS-LC. Update the type of the OCSP callback retrieved with SSL_CTX_get_tlsext_status_cb with the actual type for libcrypto versions greater than 1.0.2. This doesn't affect OpenSSL which casts the callback to void* in SSL_CTX_ctrl.
2023-07-06 18:41:46 -04:00
#if (HA_OPENSSL_VERSION_NUMBER >= 0x10101000L)
int (*callback) (SSL *, void *);
#else
MEDIUM: ssl: Add support for OpenSSL 1.1.0 In the last release a lot of the structures have become opaque for an end user. This means the code using these needs to be changed to use the proper functions to interact with these structures instead of trying to manipulate them directly. This does not fix any deprecations yet that are part of 1.1.0, it only ensures that it can be compiled against that version and is still compatible with older ones. [wt: openssl-0.9.8 doesn't build with it, there are conflicts on certain function prototypes which we declare as inline here and which are defined differently there. But openssl-0.9.8 is not supported anymore so probably it's OK to go without it for now and we'll see later if some users still need it. Emeric has reviewed this change and didn't spot anything obvious which requires special care. Let's try it for real now]
2016-08-29 07:26:37 -04:00
void (*callback) (void);
BUILD: ssl: Build with new cryptographic library AWS-LC This adds a new option for the Makefile USE_OPENSSL_AWSLC, and update the documentation with instructions to use HAProxy with AWS-LC. Update the type of the OCSP callback retrieved with SSL_CTX_get_tlsext_status_cb with the actual type for libcrypto versions greater than 1.0.2. This doesn't affect OpenSSL which casts the callback to void* in SSL_CTX_ctrl.
2023-07-06 18:41:46 -04:00
#endif
MEDIUM: ssl: add minimal WolfSSL support with OpenSSL compatibility mode This adds a USE_OPENSSL_WOLFSSL option, wolfSSL must be used with the OpenSSL compatibility layer. This must be used with USE_OPENSSL=1. WolfSSL build options: ./configure --prefix=/opt/wolfssl --enable-haproxy HAProxy build options: USE_OPENSSL=1 USE_OPENSSL_WOLFSSL=1 WOLFSSL_INC=/opt/wolfssl/include/ WOLFSSL_LIB=/opt/wolfssl/lib/ ADDLIB='-Wl,-rpath=/opt/wolfssl/lib' Using at least the commit 54466b6 ("Merge pull request #5810 from Uriah-wolfSSL/haproxy-integration") from WolfSSL. (2022-11-23). This is still to be improved, reg-tests are not supported yet, and more tests are to be done. Signed-off-by: William Lallemand <wlallemand@haproxy.org>
2022-11-23 10:41:25 -05:00
#else
tlsextStatusCb callback;
#endif
MEDIUM: ssl: Insert ocsp responses in update tree when needed When 'ocsp-update' is enabled for a given certificate, we need to insert the certificate_ocsp member of this certificate in the OCSP update tree as well as the already existing OCSP response tree. For such an entry to be created, the certificate needs to contain an "OCSP URI" field, and we also need to know the certificate's issuer, that is used to build the OCSP_CERTID. When no OCSP response is known for a given certificate, an empty certificate_ocsp object gets created so that it can be inserted in the ocsp update tree. The entry is inserted on the first spot of the update tree since its expire time is 0. Then whenever the update task is started, it will try to get responses for those certificates first. In order for the update process to work, we also need to store some information relative to the main certificate into the certificate_ocsp structure. This avoids having to keep a reference to a ckch in an ocsp tree entry. This patch adds a reference to the certificate chain as well as the ocsp issuer that might have been filled during init into the certificate_ocsp object. It also gets the ocsp uri at this time since it is contained in the server's certificate. We only take the first uri that might be contained in the certificate though. Those fields are only filled when ocsp auto update is enabled for the concerned certificate.
2022-12-20 05:11:12 -05:00
struct buffer *ocsp_uri = get_trash_chunk();
MINOR: ssl: Use ocsp update task for "update ssl ocsp-response" command Instead of having a dedicated httpclient instance and its own code decorrelated from the actual auto update one, the "update ssl ocsp-response" will now use the update task in order to perform updates. Since the cli command allows to update responses that were never included in the auto update tree, a new flag was added to the certificate_ocsp structure so that the said entry can be inserted into the tree "by hand" and it won't be reinserted back into the tree after the update process is performed. The 'update_once' flag "stole" a bit from the 'fail_count' counter since it is the one less likely to reach UINT_MAX among the ocsp counters of the certificate_ocsp structure. This new logic required that every certificate_ocsp entry contained all the ocsp-related information at all time since entries that are not supposed to be configured automatically can still be updated through the cli. The logic of the ssl_sock_load_ocsp was changed accordingly.
2023-03-13 10:56:32 -04:00
char *err = NULL;
CLEANUP: ocsp: do no use strpcy() to copy a path! strcpy() is quite nasty but tolerable to copy constants, but here it copies a variable path into a node in a code path that's not trivial to follow given that it takes the node as the result of a tree lookup. Let's get rid of it and mention where the entry is retrieved.
2023-04-07 11:49:37 -04:00
size_t path_len;
BUG/MAJOR: ocsp: Separate refcount per instance and per store With the current way OCSP responses are stored, a single OCSP response is stored (in a certificate_ocsp structure) when it is loaded during a certificate parsing, and each SSL_CTX that references it increments its refcount. The reference to the certificate_ocsp is kept in the SSL_CTX linked to each ckch_inst, in an ex_data entry that gets freed when the context is freed. One of the downsides of this implementation is that if every ckch_inst referencing a certificate_ocsp gets detroyed, then the OCSP response is removed from the system. So if we were to remove all crt-list lines containing a given certificate (that has an OCSP response), and if all the corresponding SSL_CTXs were destroyed (no ongoing connection using them), the OCSP response would be destroyed even if the certificate remains in the system (as an unused certificate). In such a case, we would want the OCSP response not to be "usable", since it is not used by any ckch_inst, but still remain in the OCSP response tree so that if the certificate gets reused (via an "add ssl crt-list" command for instance), its OCSP response is still known as well. But we would also like such an entry not to be updated automatically anymore once no instance uses it. An easy way to do it could have been to keep a reference to the certificate_ocsp structure in the ckch_store as well, on top of all the ones in the ckch_instances, and to remove the ocsp response from the update tree once the refcount falls to 1, but it would not work because of the way the ocsp response tree keys are calculated. They are decorrelated from the ckch_store and are the actual OCSP_CERTIDs, which is a combination of the issuer's name hash and key hash, and the certificate's serial number. So two copies of the same certificate but with different names would still point to the same ocsp response tree entry. The solution that answers to all the needs expressed aboved is actually to have two reference counters in the certificate_ocsp structure, one actual reference counter corresponding to the number of "live" pointers on the certificate_ocsp structure, incremented for every SSL_CTX using it, and one for the ckch stores. If the ckch_store reference counter falls to 0, the corresponding certificate must have been removed via CLI calls ('set ssl cert' for instance). If the actual refcount falls to 0, then no live SSL_CTX uses the response anymore. It could happen if all the corresponding crt-list lines were removed and there are no live SSL sessions using the certificate anymore. If any of the two refcounts becomes 0, we will always remove the response from the auto update tree, because there's no point in spending time updating an OCSP response that no new SSL connection will be able to use. But the certificate_ocsp object won't be removed from the tree unless both refcounts are 0. Must be backported up to 2.8. Wait a little bit before backporting.
2024-03-14 10:38:30 -04:00
int inc_refcount_store = 0;
MEDIUM: ssl: Add 'tune.ssl.ocsp-update.mode' global option This option can be used to set a default ocsp-update mode for all certificates of a given conf file. It allows to activate ocsp-update on certificates without the need to create separate crt-lists. It can still be superseded by the crt-list 'ocsp-update' option. It takes either "on" or "off" as value and defaults to "off". Since setting this new parameter to "on" would mean that we try to enable ocsp-update on any certificate, and also certificates that don't have an OCSP URI, the checks performed in ssl_sock_load_ocsp were softened. We don't systematically raise an error when trying to enable ocsp-update on a certificate that does not have an OCSP URI, be it via the global option or the crt-list one. We will still raise an error when a user tries to load a certificate that does have an OCSP URI but a missing issuer certificate (if ocsp-update is enabled).
2024-03-25 11:50:25 -04:00
int enable_auto_update = (data->ocsp_update_mode == SSL_SOCK_OCSP_UPDATE_ON ||
(data->ocsp_update_mode == SSL_SOCK_OCSP_UPDATE_DFLT &&
global_ssl.ocsp_update.mode == SSL_SOCK_OCSP_UPDATE_ON));
MEDIUM: ssl: basic OCSP stapling support. The support is all based on static responses. This doesn't add any request / response logic to HAProxy, but allows a way to update information through the socket interface. Currently certificates specified using "crt" or "crt-list" on "bind" lines are loaded as PEM files. For each PEM file, haproxy checks for the presence of file at the same path suffixed by ".ocsp". If such file is found, support for the TLS Certificate Status Request extension (also known as "OCSP stapling") is automatically enabled. The content of this file is optional. If not empty, it must contain a valid OCSP Response in DER format. In order to be valid an OCSP Response must comply with the following rules: it has to indicate a good status, it has to be a single response for the certificate of the PEM file, and it has to be valid at the moment of addition. If these rules are not respected the OCSP Response is ignored and a warning is emitted. In order to identify which certificate an OCSP Response applies to, the issuer's certificate is necessary. If the issuer's certificate is not found in the PEM file, it will be loaded from a file at the same path as the PEM file suffixed by ".issuer" if it exists otherwise it will fail with an error. It is possible to update an OCSP Response from the unix socket using: set ssl ocsp-response <response> This command is used to update an OCSP Response for a certificate (see "crt" on "bind" lines). Same controls are performed as during the initial loading of the response. The <response> must be passed as a base64 encoded string of the DER encoded response from the OCSP server. Example: openssl ocsp -issuer issuer.pem -cert server.pem \ -host ocsp.issuer.com:80 -respout resp.der echo "set ssl ocsp-response $(base64 -w 10000 resp.der)" | \ socat stdio /var/run/haproxy.stat This feature is automatically enabled on openssl 0.9.8h and above. This work was performed jointly by Dirkjan Bussink of GitHub and Emeric Brun of HAProxy Technologies.
2014-06-16 12:36:30 -04:00
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
x = data->cert;
MEDIUM: ssl: basic OCSP stapling support. The support is all based on static responses. This doesn't add any request / response logic to HAProxy, but allows a way to update information through the socket interface. Currently certificates specified using "crt" or "crt-list" on "bind" lines are loaded as PEM files. For each PEM file, haproxy checks for the presence of file at the same path suffixed by ".ocsp". If such file is found, support for the TLS Certificate Status Request extension (also known as "OCSP stapling") is automatically enabled. The content of this file is optional. If not empty, it must contain a valid OCSP Response in DER format. In order to be valid an OCSP Response must comply with the following rules: it has to indicate a good status, it has to be a single response for the certificate of the PEM file, and it has to be valid at the moment of addition. If these rules are not respected the OCSP Response is ignored and a warning is emitted. In order to identify which certificate an OCSP Response applies to, the issuer's certificate is necessary. If the issuer's certificate is not found in the PEM file, it will be loaded from a file at the same path as the PEM file suffixed by ".issuer" if it exists otherwise it will fail with an error. It is possible to update an OCSP Response from the unix socket using: set ssl ocsp-response <response> This command is used to update an OCSP Response for a certificate (see "crt" on "bind" lines). Same controls are performed as during the initial loading of the response. The <response> must be passed as a base64 encoded string of the DER encoded response from the OCSP server. Example: openssl ocsp -issuer issuer.pem -cert server.pem \ -host ocsp.issuer.com:80 -respout resp.der echo "set ssl ocsp-response $(base64 -w 10000 resp.der)" | \ socat stdio /var/run/haproxy.stat This feature is automatically enabled on openssl 0.9.8h and above. This work was performed jointly by Dirkjan Bussink of GitHub and Emeric Brun of HAProxy Technologies.
2014-06-16 12:36:30 -04:00
if (!x)
goto out;
MINOR: ssl: Use ocsp update task for "update ssl ocsp-response" command Instead of having a dedicated httpclient instance and its own code decorrelated from the actual auto update one, the "update ssl ocsp-response" will now use the update task in order to perform updates. Since the cli command allows to update responses that were never included in the auto update tree, a new flag was added to the certificate_ocsp structure so that the said entry can be inserted into the tree "by hand" and it won't be reinserted back into the tree after the update process is performed. The 'update_once' flag "stole" a bit from the 'fail_count' counter since it is the one less likely to reach UINT_MAX among the ocsp counters of the certificate_ocsp structure. This new logic required that every certificate_ocsp entry contained all the ocsp-related information at all time since entries that are not supposed to be configured automatically can still be updated through the cli. The logic of the ssl_sock_load_ocsp was changed accordingly.
2023-03-13 10:56:32 -04:00
ssl_ocsp_get_uri_from_cert(x, ocsp_uri, &err);
BUG/MINOR: ssl: OCSP callback only registered for first SSL_CTX If multiple SSL_CTXs use the same certificate that has an OCSP response file on the filesystem, only the first one will have the OCSP callback set. This bug was introduced by "cc346678d MEDIUM: ssl: Add ocsp_certid in ckch structure and discard ocsp buffer early" which cleared the ocsp_response from the ckch_data after it was inserted in the tree, which prevented subsequent contexts from having the callback registered. This patch should be backported to 2.8.
2023-07-21 11:21:15 -04:00
if (!data->ocsp_response && !data->ocsp_cid) {
MEDIUM: ssl: Add 'tune.ssl.ocsp-update.mode' global option This option can be used to set a default ocsp-update mode for all certificates of a given conf file. It allows to activate ocsp-update on certificates without the need to create separate crt-lists. It can still be superseded by the crt-list 'ocsp-update' option. It takes either "on" or "off" as value and defaults to "off". Since setting this new parameter to "on" would mean that we try to enable ocsp-update on any certificate, and also certificates that don't have an OCSP URI, the checks performed in ssl_sock_load_ocsp were softened. We don't systematically raise an error when trying to enable ocsp-update on a certificate that does not have an OCSP URI, be it via the global option or the crt-list one. We will still raise an error when a user tries to load a certificate that does have an OCSP URI but a missing issuer certificate (if ocsp-update is enabled).
2024-03-25 11:50:25 -04:00
/* In case of ocsp update mode set to 'on', this function might
* be called with no known ocsp response. If no ocsp uri can be
* found in the certificate, nothing needs to be done here. */
if (!enable_auto_update || b_data(ocsp_uri) == 0) {
MEDIUM: ssl: Insert ocsp responses in update tree when needed When 'ocsp-update' is enabled for a given certificate, we need to insert the certificate_ocsp member of this certificate in the OCSP update tree as well as the already existing OCSP response tree. For such an entry to be created, the certificate needs to contain an "OCSP URI" field, and we also need to know the certificate's issuer, that is used to build the OCSP_CERTID. When no OCSP response is known for a given certificate, an empty certificate_ocsp object gets created so that it can be inserted in the ocsp update tree. The entry is inserted on the first spot of the update tree since its expire time is 0. Then whenever the update task is started, it will try to get responses for those certificates first. In order for the update process to work, we also need to store some information relative to the main certificate into the certificate_ocsp structure. This avoids having to keep a reference to a ckch in an ocsp tree entry. This patch adds a reference to the certificate chain as well as the ocsp issuer that might have been filled during init into the certificate_ocsp object. It also gets the ocsp uri at this time since it is contained in the server's certificate. We only take the first uri that might be contained in the certificate though. Those fields are only filled when ocsp auto update is enabled for the concerned certificate.
2022-12-20 05:11:12 -05:00
ret = 0;
goto out;
}
MEDIUM: ssl: Add 'tune.ssl.ocsp-update.mode' global option This option can be used to set a default ocsp-update mode for all certificates of a given conf file. It allows to activate ocsp-update on certificates without the need to create separate crt-lists. It can still be superseded by the crt-list 'ocsp-update' option. It takes either "on" or "off" as value and defaults to "off". Since setting this new parameter to "on" would mean that we try to enable ocsp-update on any certificate, and also certificates that don't have an OCSP URI, the checks performed in ssl_sock_load_ocsp were softened. We don't systematically raise an error when trying to enable ocsp-update on a certificate that does not have an OCSP URI, be it via the global option or the crt-list one. We will still raise an error when a user tries to load a certificate that does have an OCSP URI but a missing issuer certificate (if ocsp-update is enabled).
2024-03-25 11:50:25 -04:00
} else {
/* If we have an OCSP response provided and the ocsp auto update
* enabled, we must raise an error if no OCSP URI was found. */
if (data->ocsp_update_mode == SSL_SOCK_OCSP_UPDATE_ON && b_data(ocsp_uri) == 0)
goto out;
MEDIUM: ssl: Insert ocsp responses in update tree when needed When 'ocsp-update' is enabled for a given certificate, we need to insert the certificate_ocsp member of this certificate in the OCSP update tree as well as the already existing OCSP response tree. For such an entry to be created, the certificate needs to contain an "OCSP URI" field, and we also need to know the certificate's issuer, that is used to build the OCSP_CERTID. When no OCSP response is known for a given certificate, an empty certificate_ocsp object gets created so that it can be inserted in the ocsp update tree. The entry is inserted on the first spot of the update tree since its expire time is 0. Then whenever the update task is started, it will try to get responses for those certificates first. In order for the update process to work, we also need to store some information relative to the main certificate into the certificate_ocsp structure. This avoids having to keep a reference to a ckch in an ocsp tree entry. This patch adds a reference to the certificate chain as well as the ocsp issuer that might have been filled during init into the certificate_ocsp object. It also gets the ocsp uri at this time since it is contained in the server's certificate. We only take the first uri that might be contained in the certificate though. Those fields are only filled when ocsp auto update is enabled for the concerned certificate.
2022-12-20 05:11:12 -05:00
}
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
issuer = data->ocsp_issuer;
MINOR: ssl: resolve ocsp_issuer later The goal is to use the ckch to store data from PEM files or <payload> and only for that. This patch adresses the ckch->ocsp_issuer case. It finds issuers chain if no chain is present in the ckch in ssl_sock_put_ckch_into_ctx(), filling the ocsp_issuer from the chain must be done after. It changes the way '.issuer' is managed: it tries to load '.issuer' in ckch->ocsp_issuer first and then look for the issuer in the chain later (in ssl_sock_load_ocsp() ). "ssl-load-extra-files" without the "issuer" parameter can negate extra '.issuer' file check.
2020-02-18 09:56:39 -05:00
/* take issuer from chain over ocsp_issuer, is what is done historicaly */
if (chain) {
/* check if one of the certificate of the chain is the issuer */
for (i = 0; i < sk_X509_num(chain); i++) {
X509 *ti = sk_X509_value(chain, i);
if (X509_check_issued(ti, x) == X509_V_OK) {
issuer = ti;
break;
}
}
}
MINOR: ssl: load the ocsp in/from the ckch Don't try to load the files containing the issuer and the OCSP response each time we generate a SSL_CTX. The .ocsp and the .issuer are now loaded in the struct cert_key_and_chain only once and then loaded from this structure when creating a SSL_CTX.
2019-10-11 02:59:13 -04:00
if (!issuer)
goto out;
MEDIUM: ssl: basic OCSP stapling support. The support is all based on static responses. This doesn't add any request / response logic to HAProxy, but allows a way to update information through the socket interface. Currently certificates specified using "crt" or "crt-list" on "bind" lines are loaded as PEM files. For each PEM file, haproxy checks for the presence of file at the same path suffixed by ".ocsp". If such file is found, support for the TLS Certificate Status Request extension (also known as "OCSP stapling") is automatically enabled. The content of this file is optional. If not empty, it must contain a valid OCSP Response in DER format. In order to be valid an OCSP Response must comply with the following rules: it has to indicate a good status, it has to be a single response for the certificate of the PEM file, and it has to be valid at the moment of addition. If these rules are not respected the OCSP Response is ignored and a warning is emitted. In order to identify which certificate an OCSP Response applies to, the issuer's certificate is necessary. If the issuer's certificate is not found in the PEM file, it will be loaded from a file at the same path as the PEM file suffixed by ".issuer" if it exists otherwise it will fail with an error. It is possible to update an OCSP Response from the unix socket using: set ssl ocsp-response <response> This command is used to update an OCSP Response for a certificate (see "crt" on "bind" lines). Same controls are performed as during the initial loading of the response. The <response> must be passed as a base64 encoded string of the DER encoded response from the OCSP server. Example: openssl ocsp -issuer issuer.pem -cert server.pem \ -host ocsp.issuer.com:80 -respout resp.der echo "set ssl ocsp-response $(base64 -w 10000 resp.der)" | \ socat stdio /var/run/haproxy.stat This feature is automatically enabled on openssl 0.9.8h and above. This work was performed jointly by Dirkjan Bussink of GitHub and Emeric Brun of HAProxy Technologies.
2014-06-16 12:36:30 -04:00
BUG/MAJOR: ocsp: Separate refcount per instance and per store With the current way OCSP responses are stored, a single OCSP response is stored (in a certificate_ocsp structure) when it is loaded during a certificate parsing, and each SSL_CTX that references it increments its refcount. The reference to the certificate_ocsp is kept in the SSL_CTX linked to each ckch_inst, in an ex_data entry that gets freed when the context is freed. One of the downsides of this implementation is that if every ckch_inst referencing a certificate_ocsp gets detroyed, then the OCSP response is removed from the system. So if we were to remove all crt-list lines containing a given certificate (that has an OCSP response), and if all the corresponding SSL_CTXs were destroyed (no ongoing connection using them), the OCSP response would be destroyed even if the certificate remains in the system (as an unused certificate). In such a case, we would want the OCSP response not to be "usable", since it is not used by any ckch_inst, but still remain in the OCSP response tree so that if the certificate gets reused (via an "add ssl crt-list" command for instance), its OCSP response is still known as well. But we would also like such an entry not to be updated automatically anymore once no instance uses it. An easy way to do it could have been to keep a reference to the certificate_ocsp structure in the ckch_store as well, on top of all the ones in the ckch_instances, and to remove the ocsp response from the update tree once the refcount falls to 1, but it would not work because of the way the ocsp response tree keys are calculated. They are decorrelated from the ckch_store and are the actual OCSP_CERTIDs, which is a combination of the issuer's name hash and key hash, and the certificate's serial number. So two copies of the same certificate but with different names would still point to the same ocsp response tree entry. The solution that answers to all the needs expressed aboved is actually to have two reference counters in the certificate_ocsp structure, one actual reference counter corresponding to the number of "live" pointers on the certificate_ocsp structure, incremented for every SSL_CTX using it, and one for the ckch stores. If the ckch_store reference counter falls to 0, the corresponding certificate must have been removed via CLI calls ('set ssl cert' for instance). If the actual refcount falls to 0, then no live SSL_CTX uses the response anymore. It could happen if all the corresponding crt-list lines were removed and there are no live SSL sessions using the certificate anymore. If any of the two refcounts becomes 0, we will always remove the response from the auto update tree, because there's no point in spending time updating an OCSP response that no new SSL connection will be able to use. But the certificate_ocsp object won't be removed from the tree unless both refcounts are 0. Must be backported up to 2.8. Wait a little bit before backporting.
2024-03-14 10:38:30 -04:00
if (!data->ocsp_cid) {
BUG/MINOR: ssl: Fix OCSP_CERTID leak when same certificate is used multiple times If a given certificate is used multiple times in a configuration, the ocsp_cid field would have been overwritten during each ssl_sock_load_ocsp call even if it was previously filled. This patch does not need to be backported.
2023-01-09 06:02:47 -05:00
data->ocsp_cid = OCSP_cert_to_id(0, x, issuer);
BUG/MAJOR: ocsp: Separate refcount per instance and per store With the current way OCSP responses are stored, a single OCSP response is stored (in a certificate_ocsp structure) when it is loaded during a certificate parsing, and each SSL_CTX that references it increments its refcount. The reference to the certificate_ocsp is kept in the SSL_CTX linked to each ckch_inst, in an ex_data entry that gets freed when the context is freed. One of the downsides of this implementation is that if every ckch_inst referencing a certificate_ocsp gets detroyed, then the OCSP response is removed from the system. So if we were to remove all crt-list lines containing a given certificate (that has an OCSP response), and if all the corresponding SSL_CTXs were destroyed (no ongoing connection using them), the OCSP response would be destroyed even if the certificate remains in the system (as an unused certificate). In such a case, we would want the OCSP response not to be "usable", since it is not used by any ckch_inst, but still remain in the OCSP response tree so that if the certificate gets reused (via an "add ssl crt-list" command for instance), its OCSP response is still known as well. But we would also like such an entry not to be updated automatically anymore once no instance uses it. An easy way to do it could have been to keep a reference to the certificate_ocsp structure in the ckch_store as well, on top of all the ones in the ckch_instances, and to remove the ocsp response from the update tree once the refcount falls to 1, but it would not work because of the way the ocsp response tree keys are calculated. They are decorrelated from the ckch_store and are the actual OCSP_CERTIDs, which is a combination of the issuer's name hash and key hash, and the certificate's serial number. So two copies of the same certificate but with different names would still point to the same ocsp response tree entry. The solution that answers to all the needs expressed aboved is actually to have two reference counters in the certificate_ocsp structure, one actual reference counter corresponding to the number of "live" pointers on the certificate_ocsp structure, incremented for every SSL_CTX using it, and one for the ckch stores. If the ckch_store reference counter falls to 0, the corresponding certificate must have been removed via CLI calls ('set ssl cert' for instance). If the actual refcount falls to 0, then no live SSL_CTX uses the response anymore. It could happen if all the corresponding crt-list lines were removed and there are no live SSL sessions using the certificate anymore. If any of the two refcounts becomes 0, we will always remove the response from the auto update tree, because there's no point in spending time updating an OCSP response that no new SSL connection will be able to use. But the certificate_ocsp object won't be removed from the tree unless both refcounts are 0. Must be backported up to 2.8. Wait a little bit before backporting.
2024-03-14 10:38:30 -04:00
inc_refcount_store = 1;
}
MEDIUM: ssl: Add ocsp_certid in ckch structure and discard ocsp buffer early The ocsp_response member of the cert_key_and_chain structure is only used temporarily. During a standard init process where an ocsp response is provided, this ocsp file is first copied into the ocsp_response buffer without any ocsp-related parsing (see ssl_sock_load_ocsp_response_from_file), and then the contents are actually interpreted and inserted into the actual ocsp tree (cert_ocsp_tree) later in the process (see ssl_sock_load_ocsp). If the response was deemed valid, it is then copied into the actual ocsp_response structure's 'response' field (see ssl_sock_load_ocsp_response). From this point, the ocsp_response field of the cert_key_and_chain object could be discarded since actual ocsp operations will be based of the certificate_ocsp object. The only remaining runtime use of the ckch's ocsp_response field was in the CLI, and more precisely in the 'show ssl cert' mechanism. This constraint could be removed by adding an OCSP_CERTID directly in the ckch because the buffer was only used to get this id. This patch then adds the OCSP_CERTID pointer in the ckch, it clears the ocsp_response buffer early and simplifies the ckch_store_build_certid function.
2022-12-20 05:11:08 -05:00
if (!data->ocsp_cid)
MEDIUM: ssl: basic OCSP stapling support. The support is all based on static responses. This doesn't add any request / response logic to HAProxy, but allows a way to update information through the socket interface. Currently certificates specified using "crt" or "crt-list" on "bind" lines are loaded as PEM files. For each PEM file, haproxy checks for the presence of file at the same path suffixed by ".ocsp". If such file is found, support for the TLS Certificate Status Request extension (also known as "OCSP stapling") is automatically enabled. The content of this file is optional. If not empty, it must contain a valid OCSP Response in DER format. In order to be valid an OCSP Response must comply with the following rules: it has to indicate a good status, it has to be a single response for the certificate of the PEM file, and it has to be valid at the moment of addition. If these rules are not respected the OCSP Response is ignored and a warning is emitted. In order to identify which certificate an OCSP Response applies to, the issuer's certificate is necessary. If the issuer's certificate is not found in the PEM file, it will be loaded from a file at the same path as the PEM file suffixed by ".issuer" if it exists otherwise it will fail with an error. It is possible to update an OCSP Response from the unix socket using: set ssl ocsp-response <response> This command is used to update an OCSP Response for a certificate (see "crt" on "bind" lines). Same controls are performed as during the initial loading of the response. The <response> must be passed as a base64 encoded string of the DER encoded response from the OCSP server. Example: openssl ocsp -issuer issuer.pem -cert server.pem \ -host ocsp.issuer.com:80 -respout resp.der echo "set ssl ocsp-response $(base64 -w 10000 resp.der)" | \ socat stdio /var/run/haproxy.stat This feature is automatically enabled on openssl 0.9.8h and above. This work was performed jointly by Dirkjan Bussink of GitHub and Emeric Brun of HAProxy Technologies.
2014-06-16 12:36:30 -04:00
goto out;
MEDIUM: ssl: Add ocsp_certid in ckch structure and discard ocsp buffer early The ocsp_response member of the cert_key_and_chain structure is only used temporarily. During a standard init process where an ocsp response is provided, this ocsp file is first copied into the ocsp_response buffer without any ocsp-related parsing (see ssl_sock_load_ocsp_response_from_file), and then the contents are actually interpreted and inserted into the actual ocsp tree (cert_ocsp_tree) later in the process (see ssl_sock_load_ocsp). If the response was deemed valid, it is then copied into the actual ocsp_response structure's 'response' field (see ssl_sock_load_ocsp_response). From this point, the ocsp_response field of the cert_key_and_chain object could be discarded since actual ocsp operations will be based of the certificate_ocsp object. The only remaining runtime use of the ckch's ocsp_response field was in the CLI, and more precisely in the 'show ssl cert' mechanism. This constraint could be removed by adding an OCSP_CERTID directly in the ckch because the buffer was only used to get this id. This patch then adds the OCSP_CERTID pointer in the ckch, it clears the ocsp_response buffer early and simplifies the ckch_store_build_certid function.
2022-12-20 05:11:08 -05:00
i = i2d_OCSP_CERTID(data->ocsp_cid, NULL);
MEDIUM: ssl: basic OCSP stapling support. The support is all based on static responses. This doesn't add any request / response logic to HAProxy, but allows a way to update information through the socket interface. Currently certificates specified using "crt" or "crt-list" on "bind" lines are loaded as PEM files. For each PEM file, haproxy checks for the presence of file at the same path suffixed by ".ocsp". If such file is found, support for the TLS Certificate Status Request extension (also known as "OCSP stapling") is automatically enabled. The content of this file is optional. If not empty, it must contain a valid OCSP Response in DER format. In order to be valid an OCSP Response must comply with the following rules: it has to indicate a good status, it has to be a single response for the certificate of the PEM file, and it has to be valid at the moment of addition. If these rules are not respected the OCSP Response is ignored and a warning is emitted. In order to identify which certificate an OCSP Response applies to, the issuer's certificate is necessary. If the issuer's certificate is not found in the PEM file, it will be loaded from a file at the same path as the PEM file suffixed by ".issuer" if it exists otherwise it will fail with an error. It is possible to update an OCSP Response from the unix socket using: set ssl ocsp-response <response> This command is used to update an OCSP Response for a certificate (see "crt" on "bind" lines). Same controls are performed as during the initial loading of the response. The <response> must be passed as a base64 encoded string of the DER encoded response from the OCSP server. Example: openssl ocsp -issuer issuer.pem -cert server.pem \ -host ocsp.issuer.com:80 -respout resp.der echo "set ssl ocsp-response $(base64 -w 10000 resp.der)" | \ socat stdio /var/run/haproxy.stat This feature is automatically enabled on openssl 0.9.8h and above. This work was performed jointly by Dirkjan Bussink of GitHub and Emeric Brun of HAProxy Technologies.
2014-06-16 12:36:30 -04:00
if (!i || (i > OCSP_MAX_CERTID_ASN1_LENGTH))
goto out;
CLEANUP: ocsp: do no use strpcy() to copy a path! strcpy() is quite nasty but tolerable to copy constants, but here it copies a variable path into a node in a code path that's not trivial to follow given that it takes the node as the result of a tree lookup. Let's get rid of it and mention where the entry is retrieved.
2023-04-07 11:49:37 -04:00
path_len = strlen(path);
ocsp = calloc(1, sizeof(*ocsp) + path_len + 1);
MEDIUM: ssl: basic OCSP stapling support. The support is all based on static responses. This doesn't add any request / response logic to HAProxy, but allows a way to update information through the socket interface. Currently certificates specified using "crt" or "crt-list" on "bind" lines are loaded as PEM files. For each PEM file, haproxy checks for the presence of file at the same path suffixed by ".ocsp". If such file is found, support for the TLS Certificate Status Request extension (also known as "OCSP stapling") is automatically enabled. The content of this file is optional. If not empty, it must contain a valid OCSP Response in DER format. In order to be valid an OCSP Response must comply with the following rules: it has to indicate a good status, it has to be a single response for the certificate of the PEM file, and it has to be valid at the moment of addition. If these rules are not respected the OCSP Response is ignored and a warning is emitted. In order to identify which certificate an OCSP Response applies to, the issuer's certificate is necessary. If the issuer's certificate is not found in the PEM file, it will be loaded from a file at the same path as the PEM file suffixed by ".issuer" if it exists otherwise it will fail with an error. It is possible to update an OCSP Response from the unix socket using: set ssl ocsp-response <response> This command is used to update an OCSP Response for a certificate (see "crt" on "bind" lines). Same controls are performed as during the initial loading of the response. The <response> must be passed as a base64 encoded string of the DER encoded response from the OCSP server. Example: openssl ocsp -issuer issuer.pem -cert server.pem \ -host ocsp.issuer.com:80 -respout resp.der echo "set ssl ocsp-response $(base64 -w 10000 resp.der)" | \ socat stdio /var/run/haproxy.stat This feature is automatically enabled on openssl 0.9.8h and above. This work was performed jointly by Dirkjan Bussink of GitHub and Emeric Brun of HAProxy Technologies.
2014-06-16 12:36:30 -04:00
if (!ocsp)
goto out;
p = ocsp->key_data;
MEDIUM: ssl: Add ocsp_certid in ckch structure and discard ocsp buffer early The ocsp_response member of the cert_key_and_chain structure is only used temporarily. During a standard init process where an ocsp response is provided, this ocsp file is first copied into the ocsp_response buffer without any ocsp-related parsing (see ssl_sock_load_ocsp_response_from_file), and then the contents are actually interpreted and inserted into the actual ocsp tree (cert_ocsp_tree) later in the process (see ssl_sock_load_ocsp). If the response was deemed valid, it is then copied into the actual ocsp_response structure's 'response' field (see ssl_sock_load_ocsp_response). From this point, the ocsp_response field of the cert_key_and_chain object could be discarded since actual ocsp operations will be based of the certificate_ocsp object. The only remaining runtime use of the ckch's ocsp_response field was in the CLI, and more precisely in the 'show ssl cert' mechanism. This constraint could be removed by adding an OCSP_CERTID directly in the ckch because the buffer was only used to get this id. This patch then adds the OCSP_CERTID pointer in the ckch, it clears the ocsp_response buffer early and simplifies the ckch_store_build_certid function.
2022-12-20 05:11:08 -05:00
ocsp->key_length = i2d_OCSP_CERTID(data->ocsp_cid, &p);
MEDIUM: ssl: basic OCSP stapling support. The support is all based on static responses. This doesn't add any request / response logic to HAProxy, but allows a way to update information through the socket interface. Currently certificates specified using "crt" or "crt-list" on "bind" lines are loaded as PEM files. For each PEM file, haproxy checks for the presence of file at the same path suffixed by ".ocsp". If such file is found, support for the TLS Certificate Status Request extension (also known as "OCSP stapling") is automatically enabled. The content of this file is optional. If not empty, it must contain a valid OCSP Response in DER format. In order to be valid an OCSP Response must comply with the following rules: it has to indicate a good status, it has to be a single response for the certificate of the PEM file, and it has to be valid at the moment of addition. If these rules are not respected the OCSP Response is ignored and a warning is emitted. In order to identify which certificate an OCSP Response applies to, the issuer's certificate is necessary. If the issuer's certificate is not found in the PEM file, it will be loaded from a file at the same path as the PEM file suffixed by ".issuer" if it exists otherwise it will fail with an error. It is possible to update an OCSP Response from the unix socket using: set ssl ocsp-response <response> This command is used to update an OCSP Response for a certificate (see "crt" on "bind" lines). Same controls are performed as during the initial loading of the response. The <response> must be passed as a base64 encoded string of the DER encoded response from the OCSP server. Example: openssl ocsp -issuer issuer.pem -cert server.pem \ -host ocsp.issuer.com:80 -respout resp.der echo "set ssl ocsp-response $(base64 -w 10000 resp.der)" | \ socat stdio /var/run/haproxy.stat This feature is automatically enabled on openssl 0.9.8h and above. This work was performed jointly by Dirkjan Bussink of GitHub and Emeric Brun of HAProxy Technologies.
2014-06-16 12:36:30 -04:00
MINOR: ssl: Add a lock to the OCSP response tree The tree that contains OCSP responses is never locked despite being used at runtime for OCSP stapling as well as the CLI through "set ssl cert" and "set ssl ocsp-response" commands. Everything works though because the certificate_ocsp structure is refcounted and the tree's entries are cleaned up when SSL_CTXs are destroyed (thanks to an ex_data entry in which the certificate_ocsp pointer is stored). This new lock will come to use when the OCSP auto update mechanism is fully implemented because this new feature will be based on another tree that stores the same certificate_ocsp members and updates their contents periodically.
2022-12-20 05:11:02 -05:00
HA_SPIN_LOCK(OCSP_LOCK, &ocsp_tree_lock);
MEDIUM: ssl: basic OCSP stapling support. The support is all based on static responses. This doesn't add any request / response logic to HAProxy, but allows a way to update information through the socket interface. Currently certificates specified using "crt" or "crt-list" on "bind" lines are loaded as PEM files. For each PEM file, haproxy checks for the presence of file at the same path suffixed by ".ocsp". If such file is found, support for the TLS Certificate Status Request extension (also known as "OCSP stapling") is automatically enabled. The content of this file is optional. If not empty, it must contain a valid OCSP Response in DER format. In order to be valid an OCSP Response must comply with the following rules: it has to indicate a good status, it has to be a single response for the certificate of the PEM file, and it has to be valid at the moment of addition. If these rules are not respected the OCSP Response is ignored and a warning is emitted. In order to identify which certificate an OCSP Response applies to, the issuer's certificate is necessary. If the issuer's certificate is not found in the PEM file, it will be loaded from a file at the same path as the PEM file suffixed by ".issuer" if it exists otherwise it will fail with an error. It is possible to update an OCSP Response from the unix socket using: set ssl ocsp-response <response> This command is used to update an OCSP Response for a certificate (see "crt" on "bind" lines). Same controls are performed as during the initial loading of the response. The <response> must be passed as a base64 encoded string of the DER encoded response from the OCSP server. Example: openssl ocsp -issuer issuer.pem -cert server.pem \ -host ocsp.issuer.com:80 -respout resp.der echo "set ssl ocsp-response $(base64 -w 10000 resp.der)" | \ socat stdio /var/run/haproxy.stat This feature is automatically enabled on openssl 0.9.8h and above. This work was performed jointly by Dirkjan Bussink of GitHub and Emeric Brun of HAProxy Technologies.
2014-06-16 12:36:30 -04:00
iocsp = (struct certificate_ocsp *)ebmb_insert(&cert_ocsp_tree, &ocsp->key, OCSP_MAX_CERTID_ASN1_LENGTH);
if (iocsp == ocsp)
ocsp = NULL;
MEDIUM: ssl: Add support for OpenSSL 1.1.0 In the last release a lot of the structures have become opaque for an end user. This means the code using these needs to be changed to use the proper functions to interact with these structures instead of trying to manipulate them directly. This does not fix any deprecations yet that are part of 1.1.0, it only ensures that it can be compiled against that version and is still compatible with older ones. [wt: openssl-0.9.8 doesn't build with it, there are conflicts on certain function prototypes which we declare as inline here and which are defined differently there. But openssl-0.9.8 is not supported anymore so probably it's OK to go without it for now and we'll see later if some users still need it. Emeric has reviewed this change and didn't spot anything obvious which requires special care. Let's try it for real now]
2016-08-29 07:26:37 -04:00
#ifndef SSL_CTX_get_tlsext_status_cb
# define SSL_CTX_get_tlsext_status_cb(ctx, cb) \
*cb = (void (*) (void))ctx->tlsext_status_cb;
#endif
SSL_CTX_get_tlsext_status_cb(ctx, &callback);
BUG/MAJOR: ocsp: Separate refcount per instance and per store With the current way OCSP responses are stored, a single OCSP response is stored (in a certificate_ocsp structure) when it is loaded during a certificate parsing, and each SSL_CTX that references it increments its refcount. The reference to the certificate_ocsp is kept in the SSL_CTX linked to each ckch_inst, in an ex_data entry that gets freed when the context is freed. One of the downsides of this implementation is that if every ckch_inst referencing a certificate_ocsp gets detroyed, then the OCSP response is removed from the system. So if we were to remove all crt-list lines containing a given certificate (that has an OCSP response), and if all the corresponding SSL_CTXs were destroyed (no ongoing connection using them), the OCSP response would be destroyed even if the certificate remains in the system (as an unused certificate). In such a case, we would want the OCSP response not to be "usable", since it is not used by any ckch_inst, but still remain in the OCSP response tree so that if the certificate gets reused (via an "add ssl crt-list" command for instance), its OCSP response is still known as well. But we would also like such an entry not to be updated automatically anymore once no instance uses it. An easy way to do it could have been to keep a reference to the certificate_ocsp structure in the ckch_store as well, on top of all the ones in the ckch_instances, and to remove the ocsp response from the update tree once the refcount falls to 1, but it would not work because of the way the ocsp response tree keys are calculated. They are decorrelated from the ckch_store and are the actual OCSP_CERTIDs, which is a combination of the issuer's name hash and key hash, and the certificate's serial number. So two copies of the same certificate but with different names would still point to the same ocsp response tree entry. The solution that answers to all the needs expressed aboved is actually to have two reference counters in the certificate_ocsp structure, one actual reference counter corresponding to the number of "live" pointers on the certificate_ocsp structure, incremented for every SSL_CTX using it, and one for the ckch stores. If the ckch_store reference counter falls to 0, the corresponding certificate must have been removed via CLI calls ('set ssl cert' for instance). If the actual refcount falls to 0, then no live SSL_CTX uses the response anymore. It could happen if all the corresponding crt-list lines were removed and there are no live SSL sessions using the certificate anymore. If any of the two refcounts becomes 0, we will always remove the response from the auto update tree, because there's no point in spending time updating an OCSP response that no new SSL connection will be able to use. But the certificate_ocsp object won't be removed from the tree unless both refcounts are 0. Must be backported up to 2.8. Wait a little bit before backporting.
2024-03-14 10:38:30 -04:00
if (inc_refcount_store)
iocsp->refcount_store++;
MEDIUM: ssl: Add support for OpenSSL 1.1.0 In the last release a lot of the structures have become opaque for an end user. This means the code using these needs to be changed to use the proper functions to interact with these structures instead of trying to manipulate them directly. This does not fix any deprecations yet that are part of 1.1.0, it only ensures that it can be compiled against that version and is still compatible with older ones. [wt: openssl-0.9.8 doesn't build with it, there are conflicts on certain function prototypes which we declare as inline here and which are defined differently there. But openssl-0.9.8 is not supported anymore so probably it's OK to go without it for now and we'll see later if some users still need it. Emeric has reviewed this change and didn't spot anything obvious which requires special care. Let's try it for real now]
2016-08-29 07:26:37 -04:00
if (!callback) {
BUG/MEDIUM: ssl: check OCSP calloc in ssl_sock_load_ocsp() Check the return of the calloc in ssl_sock_load_ocsp() which could lead to a NULL dereference. This was introduced by commit be2774d ("MEDIUM: ssl: Added support for Multi-Cert OCSP Stapling"). Could be backported as far as 1.7.
2020-07-31 05:43:20 -04:00
struct ocsp_cbk_arg *cb_arg;
BUG/MINOR: ssl: EVP_PKEY must be freed after X509_get_pubkey usage "X509_get_pubkey() attempts to decode the public key for certificate x. If successful it returns the public key as an EVP_PKEY pointer with its reference count incremented: this means the returned key must be freed up after use."
2017-01-06 06:57:46 -05:00
EVP_PKEY *pkey;
MEDIUM: ssl: Added support for Multi-Cert OCSP Stapling Enabled loading of OCSP staple responses (.ocsp files) when processing a bundled certificate with multiple keytypes.
2015-12-10 15:07:30 -05:00
BUG/MEDIUM: ssl: check OCSP calloc in ssl_sock_load_ocsp() Check the return of the calloc in ssl_sock_load_ocsp() which could lead to a NULL dereference. This was introduced by commit be2774d ("MEDIUM: ssl: Added support for Multi-Cert OCSP Stapling"). Could be backported as far as 1.7.
2020-07-31 05:43:20 -04:00
cb_arg = calloc(1, sizeof(*cb_arg));
if (!cb_arg)
goto out;
MEDIUM: ssl: Added support for Multi-Cert OCSP Stapling Enabled loading of OCSP staple responses (.ocsp files) when processing a bundled certificate with multiple keytypes.
2015-12-10 15:07:30 -05:00
cb_arg->is_single = 1;
cb_arg->s_ocsp = iocsp;
BUG/MAJOR: ssl/ocsp: crash with ocsp when old process exit or using ocsp CLI This patch reverts 2 fixes that were made in an attempt to fix the ocsp-update feature used with the 'commit ssl cert' command. The patches crash the worker when doing a soft-stop when the 'set ssl ocsp-response' command was used, or during runtime if the ocsp-update was used. This was reported in issue #2462 and #2442. The last patch reverted is the associated reg-test. Revert "BUG/MEDIUM: ssl: Fix crash when calling "update ssl ocsp-response" when an update is ongoing" This reverts commit 5e66bf26ecbf6439fafc8ef8857abe22e0874f4d. Revert "BUG/MEDIUM: ocsp: Separate refcount per instance and per store" This reverts commit 04b77f84d1b52185fc64735d7d81137479d68b00. Revert "REGTESTS: ssl: Add OCSP related tests" This reverts commit acd1b85d3442fc58164bd0fb96e72f3d4b501d15.
2024-02-26 11:53:02 -05:00
iocsp->refcount++;
MEDIUM: ssl: Add support for OpenSSL 1.1.0 In the last release a lot of the structures have become opaque for an end user. This means the code using these needs to be changed to use the proper functions to interact with these structures instead of trying to manipulate them directly. This does not fix any deprecations yet that are part of 1.1.0, it only ensures that it can be compiled against that version and is still compatible with older ones. [wt: openssl-0.9.8 doesn't build with it, there are conflicts on certain function prototypes which we declare as inline here and which are defined differently there. But openssl-0.9.8 is not supported anymore so probably it's OK to go without it for now and we'll see later if some users still need it. Emeric has reviewed this change and didn't spot anything obvious which requires special care. Let's try it for real now]
2016-08-29 07:26:37 -04:00
BUG/MINOR: ssl: EVP_PKEY must be freed after X509_get_pubkey usage "X509_get_pubkey() attempts to decode the public key for certificate x. If successful it returns the public key as an EVP_PKEY pointer with its reference count incremented: this means the returned key must be freed up after use."
2017-01-06 06:57:46 -05:00
pkey = X509_get_pubkey(x);
cb_arg->single_kt = EVP_PKEY_base_id(pkey);
EVP_PKEY_free(pkey);
MEDIUM: ssl: Added support for Multi-Cert OCSP Stapling Enabled loading of OCSP staple responses (.ocsp files) when processing a bundled certificate with multiple keytypes.
2015-12-10 15:07:30 -05:00
SSL_CTX_set_tlsext_status_cb(ctx, ssl_sock_ocsp_stapling_cbk);
BUG/MEDIUM: ssl: memory leak of ocsp data at SSL_CTX_free() This bug affects all version of HAProxy since the OCSP data is not free in the deinit(), but leaking on exit() is not really an issue. However, when doing dynamic update of certificates over the CLI, those data are not free'd upon the free of the SSL_CTX. 3 leaks are happening, the first leak is the one of the ocsp_arg structure which serves the purpose of containing the pointers in the case of a multi-certificate bundle. The second leak is the one ocsp struct. And the third leak is the one of the struct buffer in the ocsp_struct. The problem lies with SSL_CTX_set_tlsext_status_arg() which does not provide a way to free the argument upon an SSL_CTX_free(). This fix uses ex index functions instead of registering a tlsext_status_arg(). This is really convenient because it allows to register a free callback which will free the ex index content upon a SSL_CTX_free(). A refcount was also added to the ocsp_response structure since it is stored in a tree and can be reused in another SSL_CTX. Should fix part of the issue #746. This must be backported in 2.2 and 2.1.
2020-08-04 11:41:39 -04:00
SSL_CTX_set_ex_data(ctx, ocsp_ex_index, cb_arg); /* we use the ex_data instead of the cb_arg function here, so we can use the cleanup callback to free */
MEDIUM: ssl: Added support for Multi-Cert OCSP Stapling Enabled loading of OCSP staple responses (.ocsp files) when processing a bundled certificate with multiple keytypes.
2015-12-10 15:07:30 -05:00
} else {
/*
* If the ctx has a status CB, then we have previously set an OCSP staple for this ctx
* Update that cb_arg with the new cert's staple
*/
MEDIUM: ssl: Add support for OpenSSL 1.1.0 In the last release a lot of the structures have become opaque for an end user. This means the code using these needs to be changed to use the proper functions to interact with these structures instead of trying to manipulate them directly. This does not fix any deprecations yet that are part of 1.1.0, it only ensures that it can be compiled against that version and is still compatible with older ones. [wt: openssl-0.9.8 doesn't build with it, there are conflicts on certain function prototypes which we declare as inline here and which are defined differently there. But openssl-0.9.8 is not supported anymore so probably it's OK to go without it for now and we'll see later if some users still need it. Emeric has reviewed this change and didn't spot anything obvious which requires special care. Let's try it for real now]
2016-08-29 07:26:37 -04:00
struct ocsp_cbk_arg *cb_arg;
MEDIUM: ssl: Added support for Multi-Cert OCSP Stapling Enabled loading of OCSP staple responses (.ocsp files) when processing a bundled certificate with multiple keytypes.
2015-12-10 15:07:30 -05:00
struct certificate_ocsp *tmp_ocsp;
int index;
MEDIUM: ssl: Add support for OpenSSL 1.1.0 In the last release a lot of the structures have become opaque for an end user. This means the code using these needs to be changed to use the proper functions to interact with these structures instead of trying to manipulate them directly. This does not fix any deprecations yet that are part of 1.1.0, it only ensures that it can be compiled against that version and is still compatible with older ones. [wt: openssl-0.9.8 doesn't build with it, there are conflicts on certain function prototypes which we declare as inline here and which are defined differently there. But openssl-0.9.8 is not supported anymore so probably it's OK to go without it for now and we'll see later if some users still need it. Emeric has reviewed this change and didn't spot anything obvious which requires special care. Let's try it for real now]
2016-08-29 07:26:37 -04:00
int key_type;
BUG/MINOR: ssl: EVP_PKEY must be freed after X509_get_pubkey usage "X509_get_pubkey() attempts to decode the public key for certificate x. If successful it returns the public key as an EVP_PKEY pointer with its reference count incremented: this means the returned key must be freed up after use."
2017-01-06 06:57:46 -05:00
EVP_PKEY *pkey;
MEDIUM: ssl: Add support for OpenSSL 1.1.0 In the last release a lot of the structures have become opaque for an end user. This means the code using these needs to be changed to use the proper functions to interact with these structures instead of trying to manipulate them directly. This does not fix any deprecations yet that are part of 1.1.0, it only ensures that it can be compiled against that version and is still compatible with older ones. [wt: openssl-0.9.8 doesn't build with it, there are conflicts on certain function prototypes which we declare as inline here and which are defined differently there. But openssl-0.9.8 is not supported anymore so probably it's OK to go without it for now and we'll see later if some users still need it. Emeric has reviewed this change and didn't spot anything obvious which requires special care. Let's try it for real now]
2016-08-29 07:26:37 -04:00
BUG/MEDIUM: ssl: memory leak of ocsp data at SSL_CTX_free() This bug affects all version of HAProxy since the OCSP data is not free in the deinit(), but leaking on exit() is not really an issue. However, when doing dynamic update of certificates over the CLI, those data are not free'd upon the free of the SSL_CTX. 3 leaks are happening, the first leak is the one of the ocsp_arg structure which serves the purpose of containing the pointers in the case of a multi-certificate bundle. The second leak is the one ocsp struct. And the third leak is the one of the struct buffer in the ocsp_struct. The problem lies with SSL_CTX_set_tlsext_status_arg() which does not provide a way to free the argument upon an SSL_CTX_free(). This fix uses ex index functions instead of registering a tlsext_status_arg(). This is really convenient because it allows to register a free callback which will free the ex index content upon a SSL_CTX_free(). A refcount was also added to the ocsp_response structure since it is stored in a tree and can be reused in another SSL_CTX. Should fix part of the issue #746. This must be backported in 2.2 and 2.1.
2020-08-04 11:41:39 -04:00
cb_arg = SSL_CTX_get_ex_data(ctx, ocsp_ex_index);
MEDIUM: ssl: Added support for Multi-Cert OCSP Stapling Enabled loading of OCSP staple responses (.ocsp files) when processing a bundled certificate with multiple keytypes.
2015-12-10 15:07:30 -05:00
/*
* The following few lines will convert cb_arg from a single ocsp to multi ocsp
* the order of operations below matter, take care when changing it
*/
tmp_ocsp = cb_arg->s_ocsp;
index = ssl_sock_get_ocsp_arg_kt_index(cb_arg->single_kt);
cb_arg->s_ocsp = NULL;
cb_arg->m_ocsp[index] = tmp_ocsp;
cb_arg->is_single = 0;
cb_arg->single_kt = 0;
BUG/MINOR: ssl: EVP_PKEY must be freed after X509_get_pubkey usage "X509_get_pubkey() attempts to decode the public key for certificate x. If successful it returns the public key as an EVP_PKEY pointer with its reference count incremented: this means the returned key must be freed up after use."
2017-01-06 06:57:46 -05:00
pkey = X509_get_pubkey(x);
key_type = EVP_PKEY_base_id(pkey);
EVP_PKEY_free(pkey);
MEDIUM: ssl: Add support for OpenSSL 1.1.0 In the last release a lot of the structures have become opaque for an end user. This means the code using these needs to be changed to use the proper functions to interact with these structures instead of trying to manipulate them directly. This does not fix any deprecations yet that are part of 1.1.0, it only ensures that it can be compiled against that version and is still compatible with older ones. [wt: openssl-0.9.8 doesn't build with it, there are conflicts on certain function prototypes which we declare as inline here and which are defined differently there. But openssl-0.9.8 is not supported anymore so probably it's OK to go without it for now and we'll see later if some users still need it. Emeric has reviewed this change and didn't spot anything obvious which requires special care. Let's try it for real now]
2016-08-29 07:26:37 -04:00
index = ssl_sock_get_ocsp_arg_kt_index(key_type);
BUG/MEDIUM: ssl: memory leak of ocsp data at SSL_CTX_free() This bug affects all version of HAProxy since the OCSP data is not free in the deinit(), but leaking on exit() is not really an issue. However, when doing dynamic update of certificates over the CLI, those data are not free'd upon the free of the SSL_CTX. 3 leaks are happening, the first leak is the one of the ocsp_arg structure which serves the purpose of containing the pointers in the case of a multi-certificate bundle. The second leak is the one ocsp struct. And the third leak is the one of the struct buffer in the ocsp_struct. The problem lies with SSL_CTX_set_tlsext_status_arg() which does not provide a way to free the argument upon an SSL_CTX_free(). This fix uses ex index functions instead of registering a tlsext_status_arg(). This is really convenient because it allows to register a free callback which will free the ex index content upon a SSL_CTX_free(). A refcount was also added to the ocsp_response structure since it is stored in a tree and can be reused in another SSL_CTX. Should fix part of the issue #746. This must be backported in 2.2 and 2.1.
2020-08-04 11:41:39 -04:00
if (index >= 0 && !cb_arg->m_ocsp[index]) {
MEDIUM: ssl: Added support for Multi-Cert OCSP Stapling Enabled loading of OCSP staple responses (.ocsp files) when processing a bundled certificate with multiple keytypes.
2015-12-10 15:07:30 -05:00
cb_arg->m_ocsp[index] = iocsp;
BUG/MAJOR: ssl/ocsp: crash with ocsp when old process exit or using ocsp CLI This patch reverts 2 fixes that were made in an attempt to fix the ocsp-update feature used with the 'commit ssl cert' command. The patches crash the worker when doing a soft-stop when the 'set ssl ocsp-response' command was used, or during runtime if the ocsp-update was used. This was reported in issue #2462 and #2442. The last patch reverted is the associated reg-test. Revert "BUG/MEDIUM: ssl: Fix crash when calling "update ssl ocsp-response" when an update is ongoing" This reverts commit 5e66bf26ecbf6439fafc8ef8857abe22e0874f4d. Revert "BUG/MEDIUM: ocsp: Separate refcount per instance and per store" This reverts commit 04b77f84d1b52185fc64735d7d81137479d68b00. Revert "REGTESTS: ssl: Add OCSP related tests" This reverts commit acd1b85d3442fc58164bd0fb96e72f3d4b501d15.
2024-02-26 11:53:02 -05:00
iocsp->refcount++;
BUG/MEDIUM: ssl: memory leak of ocsp data at SSL_CTX_free() This bug affects all version of HAProxy since the OCSP data is not free in the deinit(), but leaking on exit() is not really an issue. However, when doing dynamic update of certificates over the CLI, those data are not free'd upon the free of the SSL_CTX. 3 leaks are happening, the first leak is the one of the ocsp_arg structure which serves the purpose of containing the pointers in the case of a multi-certificate bundle. The second leak is the one ocsp struct. And the third leak is the one of the struct buffer in the ocsp_struct. The problem lies with SSL_CTX_set_tlsext_status_arg() which does not provide a way to free the argument upon an SSL_CTX_free(). This fix uses ex index functions instead of registering a tlsext_status_arg(). This is really convenient because it allows to register a free callback which will free the ex index content upon a SSL_CTX_free(). A refcount was also added to the ocsp_response structure since it is stored in a tree and can be reused in another SSL_CTX. Should fix part of the issue #746. This must be backported in 2.2 and 2.1.
2020-08-04 11:41:39 -04:00
}
MEDIUM: ssl: Added support for Multi-Cert OCSP Stapling Enabled loading of OCSP staple responses (.ocsp files) when processing a bundled certificate with multiple keytypes.
2015-12-10 15:07:30 -05:00
}
MINOR: ssl: Add a lock to the OCSP response tree The tree that contains OCSP responses is never locked despite being used at runtime for OCSP stapling as well as the CLI through "set ssl cert" and "set ssl ocsp-response" commands. Everything works though because the certificate_ocsp structure is refcounted and the tree's entries are cleaned up when SSL_CTXs are destroyed (thanks to an ex_data entry in which the certificate_ocsp pointer is stored). This new lock will come to use when the OCSP auto update mechanism is fully implemented because this new feature will be based on another tree that stores the same certificate_ocsp members and updates their contents periodically.
2022-12-20 05:11:02 -05:00
HA_SPIN_UNLOCK(OCSP_LOCK, &ocsp_tree_lock);
MEDIUM: ssl: basic OCSP stapling support. The support is all based on static responses. This doesn't add any request / response logic to HAProxy, but allows a way to update information through the socket interface. Currently certificates specified using "crt" or "crt-list" on "bind" lines are loaded as PEM files. For each PEM file, haproxy checks for the presence of file at the same path suffixed by ".ocsp". If such file is found, support for the TLS Certificate Status Request extension (also known as "OCSP stapling") is automatically enabled. The content of this file is optional. If not empty, it must contain a valid OCSP Response in DER format. In order to be valid an OCSP Response must comply with the following rules: it has to indicate a good status, it has to be a single response for the certificate of the PEM file, and it has to be valid at the moment of addition. If these rules are not respected the OCSP Response is ignored and a warning is emitted. In order to identify which certificate an OCSP Response applies to, the issuer's certificate is necessary. If the issuer's certificate is not found in the PEM file, it will be loaded from a file at the same path as the PEM file suffixed by ".issuer" if it exists otherwise it will fail with an error. It is possible to update an OCSP Response from the unix socket using: set ssl ocsp-response <response> This command is used to update an OCSP Response for a certificate (see "crt" on "bind" lines). Same controls are performed as during the initial loading of the response. The <response> must be passed as a base64 encoded string of the DER encoded response from the OCSP server. Example: openssl ocsp -issuer issuer.pem -cert server.pem \ -host ocsp.issuer.com:80 -respout resp.der echo "set ssl ocsp-response $(base64 -w 10000 resp.der)" | \ socat stdio /var/run/haproxy.stat This feature is automatically enabled on openssl 0.9.8h and above. This work was performed jointly by Dirkjan Bussink of GitHub and Emeric Brun of HAProxy Technologies.
2014-06-16 12:36:30 -04:00
ret = 0;
warn = NULL;
MEDIUM: ssl: Insert ocsp responses in update tree when needed When 'ocsp-update' is enabled for a given certificate, we need to insert the certificate_ocsp member of this certificate in the OCSP update tree as well as the already existing OCSP response tree. For such an entry to be created, the certificate needs to contain an "OCSP URI" field, and we also need to know the certificate's issuer, that is used to build the OCSP_CERTID. When no OCSP response is known for a given certificate, an empty certificate_ocsp object gets created so that it can be inserted in the ocsp update tree. The entry is inserted on the first spot of the update tree since its expire time is 0. Then whenever the update task is started, it will try to get responses for those certificates first. In order for the update process to work, we also need to store some information relative to the main certificate into the certificate_ocsp structure. This avoids having to keep a reference to a ckch in an ocsp tree entry. This patch adds a reference to the certificate chain as well as the ocsp issuer that might have been filled during init into the certificate_ocsp object. It also gets the ocsp uri at this time since it is contained in the server's certificate. We only take the first uri that might be contained in the certificate though. Those fields are only filled when ocsp auto update is enabled for the concerned certificate.
2022-12-20 05:11:12 -05:00
if (data->ocsp_response && ssl_sock_load_ocsp_response(data->ocsp_response, iocsp, data->ocsp_cid, &warn)) {
MINOR: ssl: OCSP functions can load from file or buffer The ssl_sock_load_ocsp_response_from_file() function was modified to fill directly a struct cert_key_and_chain. The function prototype was normalized in order to be used with the CLI payload parser. This function either read a base64 from a buffer or read a binary file on the filesystem. It fills the ocsp_response buffer of the struct cert_key_and_chain.
2019-10-16 12:05:05 -04:00
memprintf(&warn, "Loading: %s. Content will be ignored", warn ? warn : "failure");
CLEANUP: log: Rename Alert/Warning in ha_alert/ha_warning
2017-11-24 10:50:31 -05:00
ha_warning("%s.\n", warn);
MEDIUM: ssl: basic OCSP stapling support. The support is all based on static responses. This doesn't add any request / response logic to HAProxy, but allows a way to update information through the socket interface. Currently certificates specified using "crt" or "crt-list" on "bind" lines are loaded as PEM files. For each PEM file, haproxy checks for the presence of file at the same path suffixed by ".ocsp". If such file is found, support for the TLS Certificate Status Request extension (also known as "OCSP stapling") is automatically enabled. The content of this file is optional. If not empty, it must contain a valid OCSP Response in DER format. In order to be valid an OCSP Response must comply with the following rules: it has to indicate a good status, it has to be a single response for the certificate of the PEM file, and it has to be valid at the moment of addition. If these rules are not respected the OCSP Response is ignored and a warning is emitted. In order to identify which certificate an OCSP Response applies to, the issuer's certificate is necessary. If the issuer's certificate is not found in the PEM file, it will be loaded from a file at the same path as the PEM file suffixed by ".issuer" if it exists otherwise it will fail with an error. It is possible to update an OCSP Response from the unix socket using: set ssl ocsp-response <response> This command is used to update an OCSP Response for a certificate (see "crt" on "bind" lines). Same controls are performed as during the initial loading of the response. The <response> must be passed as a base64 encoded string of the DER encoded response from the OCSP server. Example: openssl ocsp -issuer issuer.pem -cert server.pem \ -host ocsp.issuer.com:80 -respout resp.der echo "set ssl ocsp-response $(base64 -w 10000 resp.der)" | \ socat stdio /var/run/haproxy.stat This feature is automatically enabled on openssl 0.9.8h and above. This work was performed jointly by Dirkjan Bussink of GitHub and Emeric Brun of HAProxy Technologies.
2014-06-16 12:36:30 -04:00
}
MEDIUM: ssl: Insert ocsp responses in update tree when needed When 'ocsp-update' is enabled for a given certificate, we need to insert the certificate_ocsp member of this certificate in the OCSP update tree as well as the already existing OCSP response tree. For such an entry to be created, the certificate needs to contain an "OCSP URI" field, and we also need to know the certificate's issuer, that is used to build the OCSP_CERTID. When no OCSP response is known for a given certificate, an empty certificate_ocsp object gets created so that it can be inserted in the ocsp update tree. The entry is inserted on the first spot of the update tree since its expire time is 0. Then whenever the update task is started, it will try to get responses for those certificates first. In order for the update process to work, we also need to store some information relative to the main certificate into the certificate_ocsp structure. This avoids having to keep a reference to a ckch in an ocsp tree entry. This patch adds a reference to the certificate chain as well as the ocsp issuer that might have been filled during init into the certificate_ocsp object. It also gets the ocsp uri at this time since it is contained in the server's certificate. We only take the first uri that might be contained in the certificate though. Those fields are only filled when ocsp auto update is enabled for the concerned certificate.
2022-12-20 05:11:12 -05:00
MINOR: ssl: Use ocsp update task for "update ssl ocsp-response" command Instead of having a dedicated httpclient instance and its own code decorrelated from the actual auto update one, the "update ssl ocsp-response" will now use the update task in order to perform updates. Since the cli command allows to update responses that were never included in the auto update tree, a new flag was added to the certificate_ocsp structure so that the said entry can be inserted into the tree "by hand" and it won't be reinserted back into the tree after the update process is performed. The 'update_once' flag "stole" a bit from the 'fail_count' counter since it is the one less likely to reach UINT_MAX among the ocsp counters of the certificate_ocsp structure. This new logic required that every certificate_ocsp entry contained all the ocsp-related information at all time since entries that are not supposed to be configured automatically can still be updated through the cli. The logic of the ssl_sock_load_ocsp was changed accordingly.
2023-03-13 10:56:32 -04:00
/* Do not insert the same certificate_ocsp structure in the
* update tree more than once. */
if (!ocsp) {
/* Issuer certificate is not included in the certificate
* chain, it will have to be treated separately during
* ocsp response validation. */
if (issuer == data->ocsp_issuer) {
iocsp->issuer = issuer;
X509_up_ref(issuer);
}
if (data->chain)
iocsp->chain = X509_chain_up_ref(data->chain);
iocsp->uri = calloc(1, sizeof(*iocsp->uri));
if (!chunk_dup(iocsp->uri, ocsp_uri)) {
ha_free(&iocsp->uri);
goto out;
}
MEDIUM: ssl: Insert ocsp responses in update tree when needed When 'ocsp-update' is enabled for a given certificate, we need to insert the certificate_ocsp member of this certificate in the OCSP update tree as well as the already existing OCSP response tree. For such an entry to be created, the certificate needs to contain an "OCSP URI" field, and we also need to know the certificate's issuer, that is used to build the OCSP_CERTID. When no OCSP response is known for a given certificate, an empty certificate_ocsp object gets created so that it can be inserted in the ocsp update tree. The entry is inserted on the first spot of the update tree since its expire time is 0. Then whenever the update task is started, it will try to get responses for those certificates first. In order for the update process to work, we also need to store some information relative to the main certificate into the certificate_ocsp structure. This avoids having to keep a reference to a ckch in an ocsp tree entry. This patch adds a reference to the certificate chain as well as the ocsp issuer that might have been filled during init into the certificate_ocsp object. It also gets the ocsp uri at this time since it is contained in the server's certificate. We only take the first uri that might be contained in the certificate though. Those fields are only filled when ocsp auto update is enabled for the concerned certificate.
2022-12-20 05:11:12 -05:00
CLEANUP: ocsp: do no use strpcy() to copy a path! strcpy() is quite nasty but tolerable to copy constants, but here it copies a variable path into a node in a code path that's not trivial to follow given that it takes the node as the result of a tree lookup. Let's get rid of it and mention where the entry is retrieved.
2023-04-07 11:49:37 -04:00
/* Note: if we arrive here, ocsp==NULL because iocsp==ocsp
* after the ebmb_insert(), which indicates that we've
* just inserted this new node and that it's the one for
* which we previously allocated enough room for path_len+1
* chars.
*/
memcpy(iocsp->path, path, path_len + 1);
MINOR: ssl: Add certificate's path to certificate_ocsp structure In order to have some information about the frontend certificate when dumping the contents of the ocsp update tree from the cli, we could either keep a reference to a ckch_store in the certificate_ocsp structure, which might cause some dangling reference problems, or simply copy the path to the certificate in the ocsp response structure. This latter solution was chosen because of its simplicity.
2023-03-01 10:11:50 -05:00
MEDIUM: ssl: Add 'tune.ssl.ocsp-update.mode' global option This option can be used to set a default ocsp-update mode for all certificates of a given conf file. It allows to activate ocsp-update on certificates without the need to create separate crt-lists. It can still be superseded by the crt-list 'ocsp-update' option. It takes either "on" or "off" as value and defaults to "off". Since setting this new parameter to "on" would mean that we try to enable ocsp-update on any certificate, and also certificates that don't have an OCSP URI, the checks performed in ssl_sock_load_ocsp were softened. We don't systematically raise an error when trying to enable ocsp-update on a certificate that does not have an OCSP URI, be it via the global option or the crt-list one. We will still raise an error when a user tries to load a certificate that does have an OCSP URI but a missing issuer certificate (if ocsp-update is enabled).
2024-03-25 11:50:25 -04:00
if (enable_auto_update) {
MEDIUM: ssl: Insert ocsp responses in update tree when needed When 'ocsp-update' is enabled for a given certificate, we need to insert the certificate_ocsp member of this certificate in the OCSP update tree as well as the already existing OCSP response tree. For such an entry to be created, the certificate needs to contain an "OCSP URI" field, and we also need to know the certificate's issuer, that is used to build the OCSP_CERTID. When no OCSP response is known for a given certificate, an empty certificate_ocsp object gets created so that it can be inserted in the ocsp update tree. The entry is inserted on the first spot of the update tree since its expire time is 0. Then whenever the update task is started, it will try to get responses for those certificates first. In order for the update process to work, we also need to store some information relative to the main certificate into the certificate_ocsp structure. This avoids having to keep a reference to a ckch in an ocsp tree entry. This patch adds a reference to the certificate chain as well as the ocsp issuer that might have been filled during init into the certificate_ocsp object. It also gets the ocsp uri at this time since it is contained in the server's certificate. We only take the first uri that might be contained in the certificate though. Those fields are only filled when ocsp auto update is enabled for the concerned certificate.
2022-12-20 05:11:12 -05:00
ssl_ocsp_update_insert(iocsp);
BUG/MINOR: ssl: Fix ocsp-update when using "add ssl crt-list" When adding a new certificate through the CLI and appending it to a crt-list with the 'ocsp-update' option set, the new certificate would not be added to the OCSP response update list. The only thing that was missing was the copy of the ocsp_update mode from the ssl_bind_conf into the ckch_store's object. An extra wakeup of the update task also needed to happen in case the newly inserted entry needs to be updated before the next wakeup of the task. This patch does not need to be backported.
2023-03-02 09:49:53 -05:00
/* If we are during init the update task is not
* scheduled yet so a wakeup won't do anything.
* Otherwise, if the OCSP was added through the CLI, we
* wake the task up to manage the case of a new entry
* that needs to be updated before the previous first
BUG/MINOR: ssl: Reenable ocsp auto-update after an "add ssl crt-list" If a certificate that has an OCSP uri is unused and gets added to a crt-list with the ocsp auto update option "on", it would not have been inserted into the auto update tree because this insertion was only working on the first call of the ssl_sock_load_ocsp function. If the configuration used a crt-list like the following: cert1.pem * cert2.pem [ocsp-update on] * Then calling "del ssl crt-list" on the second line and then reverting the delete by calling "add ssl crt-list" with the same line, then the cert2.pem would not appear in the ocsp update list (can be checked thanks to "show ssl ocsp-updates" command). This patch ensures that in such a case we still perform the insertion in the update tree. This patch can be backported up to branch 2.8.
2024-02-07 10:38:45 -05:00
* entry.
*/
if (ocsp_update_task)
task_wakeup(ocsp_update_task, TASK_WOKEN_MSG);
}
MEDIUM: ssl: Add 'tune.ssl.ocsp-update.mode' global option This option can be used to set a default ocsp-update mode for all certificates of a given conf file. It allows to activate ocsp-update on certificates without the need to create separate crt-lists. It can still be superseded by the crt-list 'ocsp-update' option. It takes either "on" or "off" as value and defaults to "off". Since setting this new parameter to "on" would mean that we try to enable ocsp-update on any certificate, and also certificates that don't have an OCSP URI, the checks performed in ssl_sock_load_ocsp were softened. We don't systematically raise an error when trying to enable ocsp-update on a certificate that does not have an OCSP URI, be it via the global option or the crt-list one. We will still raise an error when a user tries to load a certificate that does have an OCSP URI but a missing issuer certificate (if ocsp-update is enabled).
2024-03-25 11:50:25 -04:00
} else if (iocsp->uri && enable_auto_update) {
BUG/MINOR: ssl: Reenable ocsp auto-update after an "add ssl crt-list" If a certificate that has an OCSP uri is unused and gets added to a crt-list with the ocsp auto update option "on", it would not have been inserted into the auto update tree because this insertion was only working on the first call of the ssl_sock_load_ocsp function. If the configuration used a crt-list like the following: cert1.pem * cert2.pem [ocsp-update on] * Then calling "del ssl crt-list" on the second line and then reverting the delete by calling "add ssl crt-list" with the same line, then the cert2.pem would not appear in the ocsp update list (can be checked thanks to "show ssl ocsp-updates" command). This patch ensures that in such a case we still perform the insertion in the update tree. This patch can be backported up to branch 2.8.
2024-02-07 10:38:45 -05:00
/* This unlikely case can happen if a series of "del ssl
* crt-list" / "add ssl crt-list" commands are made on the CLI.
* In such a case, the OCSP response tree entry will be created
* prior to the activation of the ocsp auto update and in such a
* case we must "force" insertion in the auto update tree.
*/
if (iocsp->next_update.node.leaf_p == NULL) {
ssl_ocsp_update_insert(iocsp);
/* If we are during init the update task is not
* scheduled yet so a wakeup won't do anything.
* Otherwise, if the OCSP was added through the CLI, we
* wake the task up to manage the case of a new entry
* that needs to be updated before the previous first
BUG/MINOR: ssl: Fix ocsp-update when using "add ssl crt-list" When adding a new certificate through the CLI and appending it to a crt-list with the 'ocsp-update' option set, the new certificate would not be added to the OCSP response update list. The only thing that was missing was the copy of the ocsp_update mode from the ssl_bind_conf into the ckch_store's object. An extra wakeup of the update task also needed to happen in case the newly inserted entry needs to be updated before the next wakeup of the task. This patch does not need to be backported.
2023-03-02 09:49:53 -05:00
* entry.
*/
if (ocsp_update_task)
task_wakeup(ocsp_update_task, TASK_WOKEN_MSG);
MEDIUM: ssl: Insert ocsp responses in update tree when needed When 'ocsp-update' is enabled for a given certificate, we need to insert the certificate_ocsp member of this certificate in the OCSP update tree as well as the already existing OCSP response tree. For such an entry to be created, the certificate needs to contain an "OCSP URI" field, and we also need to know the certificate's issuer, that is used to build the OCSP_CERTID. When no OCSP response is known for a given certificate, an empty certificate_ocsp object gets created so that it can be inserted in the ocsp update tree. The entry is inserted on the first spot of the update tree since its expire time is 0. Then whenever the update task is started, it will try to get responses for those certificates first. In order for the update process to work, we also need to store some information relative to the main certificate into the certificate_ocsp structure. This avoids having to keep a reference to a ckch in an ocsp tree entry. This patch adds a reference to the certificate chain as well as the ocsp issuer that might have been filled during init into the certificate_ocsp object. It also gets the ocsp uri at this time since it is contained in the server's certificate. We only take the first uri that might be contained in the certificate though. Those fields are only filled when ocsp auto update is enabled for the concerned certificate.
2022-12-20 05:11:12 -05:00
}
}
MEDIUM: ssl: basic OCSP stapling support. The support is all based on static responses. This doesn't add any request / response logic to HAProxy, but allows a way to update information through the socket interface. Currently certificates specified using "crt" or "crt-list" on "bind" lines are loaded as PEM files. For each PEM file, haproxy checks for the presence of file at the same path suffixed by ".ocsp". If such file is found, support for the TLS Certificate Status Request extension (also known as "OCSP stapling") is automatically enabled. The content of this file is optional. If not empty, it must contain a valid OCSP Response in DER format. In order to be valid an OCSP Response must comply with the following rules: it has to indicate a good status, it has to be a single response for the certificate of the PEM file, and it has to be valid at the moment of addition. If these rules are not respected the OCSP Response is ignored and a warning is emitted. In order to identify which certificate an OCSP Response applies to, the issuer's certificate is necessary. If the issuer's certificate is not found in the PEM file, it will be loaded from a file at the same path as the PEM file suffixed by ".issuer" if it exists otherwise it will fail with an error. It is possible to update an OCSP Response from the unix socket using: set ssl ocsp-response <response> This command is used to update an OCSP Response for a certificate (see "crt" on "bind" lines). Same controls are performed as during the initial loading of the response. The <response> must be passed as a base64 encoded string of the DER encoded response from the OCSP server. Example: openssl ocsp -issuer issuer.pem -cert server.pem \ -host ocsp.issuer.com:80 -respout resp.der echo "set ssl ocsp-response $(base64 -w 10000 resp.der)" | \ socat stdio /var/run/haproxy.stat This feature is automatically enabled on openssl 0.9.8h and above. This work was performed jointly by Dirkjan Bussink of GitHub and Emeric Brun of HAProxy Technologies.
2014-06-16 12:36:30 -04:00
out:
BUG/MINOR: ssl: Double free of OCSP Certificate ID This bug could be reproduced loading several certificated from "bind" line: with "server_ocsp.pem" as argument to "crt" setting and updating the CDSA certificate with the RSA as follows: echo -e "set ssl cert reg-tests/ssl/ocsp_update/multicert/server_ocsp.pem.ecdsa \ <<\n$(cat reg-tests/ssl/ocsp_update/multicert/server_ocsp.pem.rsa)\n" | socat - /tmp/stats followed by an "commit ssl cert reg-tests/ssl/ocsp_update/multicert/server_ocsp.pem.ecdsa" command. This could be detected by libasan as follows: ================================================================= ==507223==ERROR: AddressSanitizer: attempting double-free on 0x60200007afb0 in thread T3: #0 0x7fabc6fb5527 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x54527) #1 0x7fabc6ae8f8c in ossl_asn1_string_embed_free (/opt/quictls/lib/libcrypto.so.81.3+0xd4f8c) #2 0x7fabc6af54e9 in ossl_asn1_primitive_free (/opt/quictls/lib/libcrypto.so.81.3+0xe14e9) #3 0x7fabc6af5960 in ossl_asn1_template_free (/opt/quictls/lib/libcrypto.so.81.3+0xe1960) #4 0x7fabc6af569f in ossl_asn1_item_embed_free (/opt/quictls/lib/libcrypto.so.81.3+0xe169f) #5 0x7fabc6af58a4 in ASN1_item_free (/opt/quictls/lib/libcrypto.so.81.3+0xe18a4) #6 0x46a159 in ssl_sock_free_cert_key_and_chain_contents src/ssl_ckch.c:723 #7 0x46aa92 in ckch_store_free src/ssl_ckch.c:869 #8 0x4704ad in cli_release_commit_cert src/ssl_ckch.c:1981 #9 0x962e83 in cli_io_handler src/cli.c:1140 #10 0xc1edff in task_run_applet src/applet.c:454 #11 0xaf8be9 in run_tasks_from_lists src/task.c:634 #12 0xafa2ed in process_runnable_tasks src/task.c:876 #13 0xa23c72 in run_poll_loop src/haproxy.c:3024 #14 0xa24aa3 in run_thread_poll_loop src/haproxy.c:3226 #15 0x7fabc69e7ea6 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x7ea6) #16 0x7fabc6907a2e in __clone (/lib/x86_64-linux-gnu/libc.so.6+0xfba2e) 0x60200007afb0 is located 0 bytes inside of 3-byte region [0x60200007afb0,0x60200007afb3) freed by thread T3 here: #0 0x7fabc6fb5527 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x54527) #1 0x7fabc6ae8f8c in ossl_asn1_string_embed_free (/opt/quictls/lib/libcrypto.so.81.3+0xd4f8c) previously allocated by thread T2 here: #0 0x7fabc6fb573f in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x5473f) #1 0x7fabc6ae8d77 in ASN1_STRING_set (/opt/quictls/lib/libcrypto.so.81.3+0xd4d77) Thread T3 created by T0 here: #0 0x7fabc6f84bba in pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x23bba) #1 0xc04f36 in setup_extra_threads src/thread.c:252 #2 0xa2761f in main src/haproxy.c:3917 #3 0x7fabc682fd09 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x23d09) Thread T2 created by T0 here: #0 0x7fabc6f84bba in pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x23bba) #1 0xc04f36 in setup_extra_threads src/thread.c:252 #2 0xa2761f in main src/haproxy.c:3917 #3 0x7fabc682fd09 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x23d09) SUMMARY: AddressSanitizer: double-free ??:0 __interceptor_free ==507223==ABORTING Aborted The OCSP CID stored in the impacted ckch data were freed but not reset to NULL, leading to a subsequent double free. Must be backported to 2.8.
2023-12-05 08:50:40 -05:00
if (ret && data->ocsp_cid) {
MEDIUM: ssl: Add ocsp_certid in ckch structure and discard ocsp buffer early The ocsp_response member of the cert_key_and_chain structure is only used temporarily. During a standard init process where an ocsp response is provided, this ocsp file is first copied into the ocsp_response buffer without any ocsp-related parsing (see ssl_sock_load_ocsp_response_from_file), and then the contents are actually interpreted and inserted into the actual ocsp tree (cert_ocsp_tree) later in the process (see ssl_sock_load_ocsp). If the response was deemed valid, it is then copied into the actual ocsp_response structure's 'response' field (see ssl_sock_load_ocsp_response). From this point, the ocsp_response field of the cert_key_and_chain object could be discarded since actual ocsp operations will be based of the certificate_ocsp object. The only remaining runtime use of the ckch's ocsp_response field was in the CLI, and more precisely in the 'show ssl cert' mechanism. This constraint could be removed by adding an OCSP_CERTID directly in the ckch because the buffer was only used to get this id. This patch then adds the OCSP_CERTID pointer in the ckch, it clears the ocsp_response buffer early and simplifies the ckch_store_build_certid function.
2022-12-20 05:11:08 -05:00
OCSP_CERTID_free(data->ocsp_cid);
BUG/MINOR: ssl: Double free of OCSP Certificate ID This bug could be reproduced loading several certificated from "bind" line: with "server_ocsp.pem" as argument to "crt" setting and updating the CDSA certificate with the RSA as follows: echo -e "set ssl cert reg-tests/ssl/ocsp_update/multicert/server_ocsp.pem.ecdsa \ <<\n$(cat reg-tests/ssl/ocsp_update/multicert/server_ocsp.pem.rsa)\n" | socat - /tmp/stats followed by an "commit ssl cert reg-tests/ssl/ocsp_update/multicert/server_ocsp.pem.ecdsa" command. This could be detected by libasan as follows: ================================================================= ==507223==ERROR: AddressSanitizer: attempting double-free on 0x60200007afb0 in thread T3: #0 0x7fabc6fb5527 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x54527) #1 0x7fabc6ae8f8c in ossl_asn1_string_embed_free (/opt/quictls/lib/libcrypto.so.81.3+0xd4f8c) #2 0x7fabc6af54e9 in ossl_asn1_primitive_free (/opt/quictls/lib/libcrypto.so.81.3+0xe14e9) #3 0x7fabc6af5960 in ossl_asn1_template_free (/opt/quictls/lib/libcrypto.so.81.3+0xe1960) #4 0x7fabc6af569f in ossl_asn1_item_embed_free (/opt/quictls/lib/libcrypto.so.81.3+0xe169f) #5 0x7fabc6af58a4 in ASN1_item_free (/opt/quictls/lib/libcrypto.so.81.3+0xe18a4) #6 0x46a159 in ssl_sock_free_cert_key_and_chain_contents src/ssl_ckch.c:723 #7 0x46aa92 in ckch_store_free src/ssl_ckch.c:869 #8 0x4704ad in cli_release_commit_cert src/ssl_ckch.c:1981 #9 0x962e83 in cli_io_handler src/cli.c:1140 #10 0xc1edff in task_run_applet src/applet.c:454 #11 0xaf8be9 in run_tasks_from_lists src/task.c:634 #12 0xafa2ed in process_runnable_tasks src/task.c:876 #13 0xa23c72 in run_poll_loop src/haproxy.c:3024 #14 0xa24aa3 in run_thread_poll_loop src/haproxy.c:3226 #15 0x7fabc69e7ea6 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x7ea6) #16 0x7fabc6907a2e in __clone (/lib/x86_64-linux-gnu/libc.so.6+0xfba2e) 0x60200007afb0 is located 0 bytes inside of 3-byte region [0x60200007afb0,0x60200007afb3) freed by thread T3 here: #0 0x7fabc6fb5527 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x54527) #1 0x7fabc6ae8f8c in ossl_asn1_string_embed_free (/opt/quictls/lib/libcrypto.so.81.3+0xd4f8c) previously allocated by thread T2 here: #0 0x7fabc6fb573f in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x5473f) #1 0x7fabc6ae8d77 in ASN1_STRING_set (/opt/quictls/lib/libcrypto.so.81.3+0xd4d77) Thread T3 created by T0 here: #0 0x7fabc6f84bba in pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x23bba) #1 0xc04f36 in setup_extra_threads src/thread.c:252 #2 0xa2761f in main src/haproxy.c:3917 #3 0x7fabc682fd09 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x23d09) Thread T2 created by T0 here: #0 0x7fabc6f84bba in pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x23bba) #1 0xc04f36 in setup_extra_threads src/thread.c:252 #2 0xa2761f in main src/haproxy.c:3917 #3 0x7fabc682fd09 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x23d09) SUMMARY: AddressSanitizer: double-free ??:0 __interceptor_free ==507223==ABORTING Aborted The OCSP CID stored in the impacted ckch data were freed but not reset to NULL, leading to a subsequent double free. Must be backported to 2.8.
2023-12-05 08:50:40 -05:00
data->ocsp_cid = NULL;
}
MEDIUM: ssl: Add ocsp_certid in ckch structure and discard ocsp buffer early The ocsp_response member of the cert_key_and_chain structure is only used temporarily. During a standard init process where an ocsp response is provided, this ocsp file is first copied into the ocsp_response buffer without any ocsp-related parsing (see ssl_sock_load_ocsp_response_from_file), and then the contents are actually interpreted and inserted into the actual ocsp tree (cert_ocsp_tree) later in the process (see ssl_sock_load_ocsp). If the response was deemed valid, it is then copied into the actual ocsp_response structure's 'response' field (see ssl_sock_load_ocsp_response). From this point, the ocsp_response field of the cert_key_and_chain object could be discarded since actual ocsp operations will be based of the certificate_ocsp object. The only remaining runtime use of the ckch's ocsp_response field was in the CLI, and more precisely in the 'show ssl cert' mechanism. This constraint could be removed by adding an OCSP_CERTID directly in the ckch because the buffer was only used to get this id. This patch then adds the OCSP_CERTID pointer in the ckch, it clears the ocsp_response buffer early and simplifies the ckch_store_build_certid function.
2022-12-20 05:11:08 -05:00
if (!ret && data->ocsp_response) {
ha_free(&data->ocsp_response->area);
ha_free(&data->ocsp_response);
}
MEDIUM: ssl: basic OCSP stapling support. The support is all based on static responses. This doesn't add any request / response logic to HAProxy, but allows a way to update information through the socket interface. Currently certificates specified using "crt" or "crt-list" on "bind" lines are loaded as PEM files. For each PEM file, haproxy checks for the presence of file at the same path suffixed by ".ocsp". If such file is found, support for the TLS Certificate Status Request extension (also known as "OCSP stapling") is automatically enabled. The content of this file is optional. If not empty, it must contain a valid OCSP Response in DER format. In order to be valid an OCSP Response must comply with the following rules: it has to indicate a good status, it has to be a single response for the certificate of the PEM file, and it has to be valid at the moment of addition. If these rules are not respected the OCSP Response is ignored and a warning is emitted. In order to identify which certificate an OCSP Response applies to, the issuer's certificate is necessary. If the issuer's certificate is not found in the PEM file, it will be loaded from a file at the same path as the PEM file suffixed by ".issuer" if it exists otherwise it will fail with an error. It is possible to update an OCSP Response from the unix socket using: set ssl ocsp-response <response> This command is used to update an OCSP Response for a certificate (see "crt" on "bind" lines). Same controls are performed as during the initial loading of the response. The <response> must be passed as a base64 encoded string of the DER encoded response from the OCSP server. Example: openssl ocsp -issuer issuer.pem -cert server.pem \ -host ocsp.issuer.com:80 -respout resp.der echo "set ssl ocsp-response $(base64 -w 10000 resp.der)" | \ socat stdio /var/run/haproxy.stat This feature is automatically enabled on openssl 0.9.8h and above. This work was performed jointly by Dirkjan Bussink of GitHub and Emeric Brun of HAProxy Technologies.
2014-06-16 12:36:30 -04:00
if (ocsp)
BUG/MINOR: ssl: ocsp structure not freed properly in case of error In case of error, the ocsp item might already be in the ocsp certificate tree but simply freed instead of destroyed through ssl_sock_free_ocsp. This patch can be backported to all stable versions.
2022-11-03 10:16:49 -04:00
ssl_sock_free_ocsp(ocsp);
MEDIUM: ssl: basic OCSP stapling support. The support is all based on static responses. This doesn't add any request / response logic to HAProxy, but allows a way to update information through the socket interface. Currently certificates specified using "crt" or "crt-list" on "bind" lines are loaded as PEM files. For each PEM file, haproxy checks for the presence of file at the same path suffixed by ".ocsp". If such file is found, support for the TLS Certificate Status Request extension (also known as "OCSP stapling") is automatically enabled. The content of this file is optional. If not empty, it must contain a valid OCSP Response in DER format. In order to be valid an OCSP Response must comply with the following rules: it has to indicate a good status, it has to be a single response for the certificate of the PEM file, and it has to be valid at the moment of addition. If these rules are not respected the OCSP Response is ignored and a warning is emitted. In order to identify which certificate an OCSP Response applies to, the issuer's certificate is necessary. If the issuer's certificate is not found in the PEM file, it will be loaded from a file at the same path as the PEM file suffixed by ".issuer" if it exists otherwise it will fail with an error. It is possible to update an OCSP Response from the unix socket using: set ssl ocsp-response <response> This command is used to update an OCSP Response for a certificate (see "crt" on "bind" lines). Same controls are performed as during the initial loading of the response. The <response> must be passed as a base64 encoded string of the DER encoded response from the OCSP server. Example: openssl ocsp -issuer issuer.pem -cert server.pem \ -host ocsp.issuer.com:80 -respout resp.der echo "set ssl ocsp-response $(base64 -w 10000 resp.der)" | \ socat stdio /var/run/haproxy.stat This feature is automatically enabled on openssl 0.9.8h and above. This work was performed jointly by Dirkjan Bussink of GitHub and Emeric Brun of HAProxy Technologies.
2014-06-16 12:36:30 -04:00
if (warn)
free(warn);
BUG/MINOR: ssl: Stop leaking `err` in ssl_sock_load_ocsp() Previously performing a config check of `.github/h2spec.config` would report a 20 byte leak as reported in GitHub Issue #2082. The leak was introduced in a6c0a59e9af65180c3ff591b91855bea8d19b352, which is dev only. No backport needed.
2023-03-19 11:07:47 -04:00
free(err);
MEDIUM: ssl: basic OCSP stapling support. The support is all based on static responses. This doesn't add any request / response logic to HAProxy, but allows a way to update information through the socket interface. Currently certificates specified using "crt" or "crt-list" on "bind" lines are loaded as PEM files. For each PEM file, haproxy checks for the presence of file at the same path suffixed by ".ocsp". If such file is found, support for the TLS Certificate Status Request extension (also known as "OCSP stapling") is automatically enabled. The content of this file is optional. If not empty, it must contain a valid OCSP Response in DER format. In order to be valid an OCSP Response must comply with the following rules: it has to indicate a good status, it has to be a single response for the certificate of the PEM file, and it has to be valid at the moment of addition. If these rules are not respected the OCSP Response is ignored and a warning is emitted. In order to identify which certificate an OCSP Response applies to, the issuer's certificate is necessary. If the issuer's certificate is not found in the PEM file, it will be loaded from a file at the same path as the PEM file suffixed by ".issuer" if it exists otherwise it will fail with an error. It is possible to update an OCSP Response from the unix socket using: set ssl ocsp-response <response> This command is used to update an OCSP Response for a certificate (see "crt" on "bind" lines). Same controls are performed as during the initial loading of the response. The <response> must be passed as a base64 encoded string of the DER encoded response from the OCSP server. Example: openssl ocsp -issuer issuer.pem -cert server.pem \ -host ocsp.issuer.com:80 -respout resp.der echo "set ssl ocsp-response $(base64 -w 10000 resp.der)" | \ socat stdio /var/run/haproxy.stat This feature is automatically enabled on openssl 0.9.8h and above. This work was performed jointly by Dirkjan Bussink of GitHub and Emeric Brun of HAProxy Technologies.
2014-06-16 12:36:30 -04:00
return ret;
}
MINOR: ssl: Move OCSP code to a dedicated source file This is a simple cleanup that moves OCSP related code to a dedicated file instead of interlacing it in some pure ssl connection code.
2022-12-20 05:11:17 -05:00
BUG/MEDIUM: ssl: OCSP must work with BoringSSL It's a regression from b3201a3e "BUG/MINOR: disable dynamic OCSP load with BoringSSL". The origin bug is link to 76b4a12 "BUG/MEDIUM: ssl: memory leak of ocsp data at SSL_CTX_free()": ssl_sock_free_ocsp() shoud be in #ifndef OPENSSL_IS_BORINGSSL. To avoid long #ifdef for small code, the BoringSSL part for ocsp load is isolated in a simple #ifdef. This must be backported in 2.2 and 2.1
2020-10-26 08:55:30 -04:00
#endif
#ifdef OPENSSL_IS_BORINGSSL
MINOR: ssl: Add certificate's path to certificate_ocsp structure In order to have some information about the frontend certificate when dumping the contents of the ocsp update tree from the cli, we could either keep a reference to a ckch_store in the certificate_ocsp structure, which might cause some dangling reference problems, or simply copy the path to the certificate in the ocsp response structure. This latter solution was chosen because of its simplicity.
2023-03-01 10:11:50 -05:00
static int ssl_sock_load_ocsp(const char *path, SSL_CTX *ctx, struct ckch_data *data, STACK_OF(X509) *chain)
MINOR: boringssl: basic support for OCSP Stapling Use boringssl SSL_CTX_set_ocsp_response to set OCSP response from file with '.ocsp' extension. CLI update is not supported.
2017-05-22 08:58:00 -04:00
{
BUG/MINOR: ssl: fix OCSP build with BoringSSL 246c024 broke the build of the OCSP code with BoringSSL. Rework it a little so it could load the OCSP buffer of the ckch. Issue #322.
2019-10-14 08:51:41 -04:00
return SSL_CTX_set_ocsp_response(ctx, (const uint8_t *)ckch->ocsp_response->area, ckch->ocsp_response->data);
MINOR: boringssl: basic support for OCSP Stapling Use boringssl SSL_CTX_set_ocsp_response to set OCSP response from file with '.ocsp' extension. CLI update is not supported.
2017-05-22 08:58:00 -04:00
}
#endif
BUG/MINOR: ssl: fix OCSP build with BoringSSL 246c024 broke the build of the OCSP code with BoringSSL. Rework it a little so it could load the OCSP buffer of the ckch. Issue #322.
2019-10-14 08:51:41 -04:00
BUILD: ssl: fix typo in HAVE_SSL_CTX_ADD_SERVER_CUSTOM_EXT macro HAVE_SSL_CTX_ADD_SERVER_CUSTOM_EXT was introduced in ec609098718b9c1cd803ca57442b2b98c9ba4a16 however it was defined as HAVE_SL_CTX_ADD_SERVER_CUSTOM_EXT (missing "S") let us fix typo
2021-02-06 08:55:27 -05:00
#ifdef HAVE_SSL_CTX_ADD_SERVER_CUSTOM_EXT
MEDIUM: ssl: Certificate Transparency support Adds ability to include Signed Certificate Timestamp List in TLS extension. File containing SCTL must be present at the same path of the certificate file, suffixed with '.sctl'. This requires OpenSSL 1.0.2 or later.
2015-03-07 17:03:59 -05:00
#define CT_EXTENSION_TYPE 18
REORG: ssl: move the ckch_store related functions to src/ssl_ckch.c Move the cert_key_and_chain functions: int ssl_sock_load_files_into_ckch(const char *path, struct cert_key_and_chain *ckch, char **err); int ssl_sock_load_pem_into_ckch(const char *path, char *buf, struct cert_key_and_chain *ckch , char **err); void ssl_sock_free_cert_key_and_chain_contents(struct cert_key_and_chain *ckch); int ssl_sock_load_key_into_ckch(const char *path, char *buf, struct cert_key_and_chain *ckch , char **err); int ssl_sock_load_ocsp_response_from_file(const char *ocsp_path, char *buf, struct cert_key_and_chain *ckch, char **err); int ssl_sock_load_sctl_from_file(const char *sctl_path, char *buf, struct cert_key_and_chain *ckch, char **err); int ssl_sock_load_issuer_file_into_ckch(const char *path, char *buf, struct cert_key_and_chain *ckch, char **err); And the utility ckch_store functions: void ckch_store_free(struct ckch_store *store) struct ckch_store *ckch_store_new(const char *filename, int nmemb) struct ckch_store *ckchs_dup(const struct ckch_store *src) ckch_store *ckchs_lookup(char *path) ckch_store *ckchs_load_cert_file(char *path, int multi, char **err)
2020-05-13 04:10:01 -04:00
int sctl_ex_index = -1;
MEDIUM: ssl: Certificate Transparency support Adds ability to include Signed Certificate Timestamp List in TLS extension. File containing SCTL must be present at the same path of the certificate file, suffixed with '.sctl'. This requires OpenSSL 1.0.2 or later.
2015-03-07 17:03:59 -05:00
int ssl_sock_sctl_add_cbk(SSL *ssl, unsigned ext_type, const unsigned char **out, size_t *outlen, int *al, void *add_arg)
{
MAJOR: chunks: replace struct chunk with struct buffer Now all the code used to manipulate chunks uses a struct buffer instead. The functions are still called "chunk*", and some of them will progressively move to the generic buffer handling code as they are cleaned up.
2018-07-13 05:56:34 -04:00
struct buffer *sctl = add_arg;
MEDIUM: ssl: Certificate Transparency support Adds ability to include Signed Certificate Timestamp List in TLS extension. File containing SCTL must be present at the same path of the certificate file, suffixed with '.sctl'. This requires OpenSSL 1.0.2 or later.
2015-03-07 17:03:59 -05:00
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
*out = (unsigned char *) sctl->area;
*outlen = sctl->data;
MEDIUM: ssl: Certificate Transparency support Adds ability to include Signed Certificate Timestamp List in TLS extension. File containing SCTL must be present at the same path of the certificate file, suffixed with '.sctl'. This requires OpenSSL 1.0.2 or later.
2015-03-07 17:03:59 -05:00
return 1;
}
int ssl_sock_sctl_parse_cbk(SSL *s, unsigned int ext_type, const unsigned char *in, size_t inlen, int *al, void *parse_arg)
{
return 1;
}
MINOR: ssl: load the sctl in/from the ckch Don't try to load the file containing the sctl each time we generate a SSL_CTX. The .sctl is now loaded in the struct cert_key_and_chain only once and then loaded from this structure when creating a SSL_CTX. Note that this now make possible the use of sctl with multi-cert bundles.
2019-10-10 09:16:44 -04:00
static int ssl_sock_load_sctl(SSL_CTX *ctx, struct buffer *sctl)
MEDIUM: ssl: Certificate Transparency support Adds ability to include Signed Certificate Timestamp List in TLS extension. File containing SCTL must be present at the same path of the certificate file, suffixed with '.sctl'. This requires OpenSSL 1.0.2 or later.
2015-03-07 17:03:59 -05:00
{
int ret = -1;
MINOR: ssl: load the sctl in/from the ckch Don't try to load the file containing the sctl each time we generate a SSL_CTX. The .sctl is now loaded in the struct cert_key_and_chain only once and then loaded from this structure when creating a SSL_CTX. Note that this now make possible the use of sctl with multi-cert bundles.
2019-10-10 09:16:44 -04:00
if (!SSL_CTX_add_server_custom_ext(ctx, CT_EXTENSION_TYPE, ssl_sock_sctl_add_cbk, NULL, sctl, ssl_sock_sctl_parse_cbk, NULL))
MEDIUM: ssl: Certificate Transparency support Adds ability to include Signed Certificate Timestamp List in TLS extension. File containing SCTL must be present at the same path of the certificate file, suffixed with '.sctl'. This requires OpenSSL 1.0.2 or later.
2015-03-07 17:03:59 -05:00
goto out;
SSL_CTX_set_ex_data(ctx, sctl_ex_index, sctl);
ret = 0;
out:
return ret;
}
#endif
MEDIUM: ssl: protect against client-initiated renegociation CVE-2009-3555 suggests that client-initiated renegociation should be prevented in the middle of data. The workaround here consists in having the SSL layer notify our callback about a handshake occurring, which in turn causes the connection to be marked in the error state if it was already considered established (which means if a previous handshake was completed). The result is that the connection with the client is immediately aborted and any pending data are dropped.
2012-09-03 14:36:47 -04:00
void ssl_sock_infocbk(const SSL *ssl, int where, int ret)
{
BUG/MAJOR: ssl: OpenSSL context is stored in non-reserved memory slot We never saw unexplicated crash with SSL, so I suppose that we are luck, or the slot 0 is always reserved. Anyway the usage of the macro SSL_get_app_data() and SSL_set_app_data() seem wrong. This patch change the deprecated functions SSL_get_app_data() and SSL_set_app_data() by the new functions SSL_get_ex_data() and SSL_set_ex_data(), and it reserves the slot in the SSL memory space. For information, this is the two declaration which seems wrong or incomplete in the OpenSSL ssl.h file. We can see the usage of the slot 0 whoch is hardcoded, but never reserved. #define SSL_set_app_data(s,arg) (SSL_set_ex_data(s,0,(char *)arg)) #define SSL_get_app_data(s) (SSL_get_ex_data(s,0)) This patch must be backported at least in 1.8, maybe in other versions.
2018-06-17 15:37:05 -04:00
struct connection *conn = SSL_get_ex_data(ssl, ssl_app_data_index);
MEDIUM: quic/ssl: add new ex data for quic_conn Allow to register quic_conn as ex-data in SSL callbacks. A new index is used to identify it as ssl_qc_app_data_index. Replace connection by quic_conn as SSL ex-data when initializing the QUIC SSL session. When using SSL callbacks in QUIC context, the connection is now NULL. Used quic_conn instead to retrieve the required parameters. Also clean up The same changes are conducted inside the QUIC SSL methods of xprt-quic : connection instance usage is replaced by quic_conn.
2022-01-19 04:03:30 -05:00
#ifdef USE_QUIC
struct quic_conn *qc = SSL_get_ex_data(ssl, ssl_qc_app_data_index);
#endif /* USE_QUIC */
struct ssl_sock_ctx *ctx = NULL;
MINOR: ssl: handshake optim for long certificate chains. Suggested on the mailing list by Ilya Grigorik and greatly inspired from Nginx code: we try to dynamicaly rise the output buffer size from 4k to 16k during the handshake to reduce the number of round trips. This is mostly beneficial when initcwnd==10. Ilya's tests confirm the gain and show a handshake time divided by 3 : before: http://www.webpagetest.org/result/140116_VW_3bd95a5cfb7e667498ef13b59639b9bf/2/details/ after: http://www.webpagetest.org/result/140201_2X_03511ec63344f442b81c24d2bf39f59d/3/details/
2014-01-28 09:43:53 -05:00
BIO *write_bio;
BUILD/CLEANUP: ssl: avoid a warning due to mixed code and declaration Actually it was caused by some dummy code meant to shut gcc up for an unused argument!
2015-02-27 10:36:16 -05:00
(void)ret; /* shut gcc stupid warning */
MEDIUM: ssl: protect against client-initiated renegociation CVE-2009-3555 suggests that client-initiated renegociation should be prevented in the middle of data. The workaround here consists in having the SSL layer notify our callback about a handshake occurring, which in turn causes the connection to be marked in the error state if it was already considered established (which means if a previous handshake was completed). The result is that the connection with the client is immediately aborted and any pending data are dropped.
2012-09-03 14:36:47 -04:00
MEDIUM: quic/ssl: add new ex data for quic_conn Allow to register quic_conn as ex-data in SSL callbacks. A new index is used to identify it as ssl_qc_app_data_index. Replace connection by quic_conn as SSL ex-data when initializing the QUIC SSL session. When using SSL callbacks in QUIC context, the connection is now NULL. Used quic_conn instead to retrieve the required parameters. Also clean up The same changes are conducted inside the QUIC SSL methods of xprt-quic : connection instance usage is replaced by quic_conn.
2022-01-19 04:03:30 -05:00
if (conn)
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
ctx = conn_get_ssl_sock_ctx(conn);
MEDIUM: quic/ssl: add new ex data for quic_conn Allow to register quic_conn as ex-data in SSL callbacks. A new index is used to identify it as ssl_qc_app_data_index. Replace connection by quic_conn as SSL ex-data when initializing the QUIC SSL session. When using SSL callbacks in QUIC context, the connection is now NULL. Used quic_conn instead to retrieve the required parameters. Also clean up The same changes are conducted inside the QUIC SSL methods of xprt-quic : connection instance usage is replaced by quic_conn.
2022-01-19 04:03:30 -05:00
#ifdef USE_QUIC
else if (qc)
ctx = qc->xprt_ctx;
#endif /* USE_QUIC */
MINOR: ssl: fix build in release mode Fix potential null pointer dereference. In fact, this case is not possible, only a mistake in SSL ex-data initialization may cause it : either connection is set or quic_conn, which allows to retrieve the bind_conf. A BUG_ON was already present but this does not cover release build.
2022-01-24 05:04:05 -05:00
if (!ctx) {
/* must never happen */
ABORT_NOW();
return;
}
MEDIUM: quic/ssl: add new ex data for quic_conn Allow to register quic_conn as ex-data in SSL callbacks. A new index is used to identify it as ssl_qc_app_data_index. Replace connection by quic_conn as SSL ex-data when initializing the QUIC SSL session. When using SSL callbacks in QUIC context, the connection is now NULL. Used quic_conn instead to retrieve the required parameters. Also clean up The same changes are conducted inside the QUIC SSL methods of xprt-quic : connection instance usage is replaced by quic_conn.
2022-01-19 04:03:30 -05:00
BUG/MEDIUM: ssl: Fix handling of TLS 1.3 KeyUpdate messages In OpenSSL 1.1.1 TLS 1.3 KeyUpdate messages will trigger the callback that is used to verify renegotiation is disabled. This means that these KeyUpdate messages fail. In OpenSSL 1.1.1 a better mechanism is available with the SSL_OP_NO_RENEGOTIATION flag that disables any TLS 1.2 and earlier negotiation. So if this SSL_OP_NO_RENEGOTIATION flag is available, instead of having a manual check, trust OpenSSL and disable the check. This means that TLS 1.3 KeyUpdate messages will work properly. Reported-By: Adam Langley <agl@imperialviolet.org>
2019-01-21 12:35:03 -05:00
#ifndef SSL_OP_NO_RENEGOTIATION
/* Please note that BoringSSL defines this macro to zero so don't
* change this to #if and do not assign a default value to this macro!
*/
MEDIUM: ssl: protect against client-initiated renegociation CVE-2009-3555 suggests that client-initiated renegociation should be prevented in the middle of data. The workaround here consists in having the SSL layer notify our callback about a handshake occurring, which in turn causes the connection to be marked in the error state if it was already considered established (which means if a previous handshake was completed). The result is that the connection with the client is immediately aborted and any pending data are dropped.
2012-09-03 14:36:47 -04:00
if (where & SSL_CB_HANDSHAKE_START) {
/* Disable renegotiation (CVE-2009-3555) */
MEDIUM: quic/ssl: add new ex data for quic_conn Allow to register quic_conn as ex-data in SSL callbacks. A new index is used to identify it as ssl_qc_app_data_index. Replace connection by quic_conn as SSL ex-data when initializing the QUIC SSL session. When using SSL callbacks in QUIC context, the connection is now NULL. Used quic_conn instead to retrieve the required parameters. Also clean up The same changes are conducted inside the QUIC SSL methods of xprt-quic : connection instance usage is replaced by quic_conn.
2022-01-19 04:03:30 -05:00
if (conn && (conn->flags & (CO_FL_WAIT_L6_CONN | CO_FL_EARLY_SSL_HS | CO_FL_EARLY_DATA)) == 0) {
MEDIUM: ssl: protect against client-initiated renegociation CVE-2009-3555 suggests that client-initiated renegociation should be prevented in the middle of data. The workaround here consists in having the SSL layer notify our callback about a handshake occurring, which in turn causes the connection to be marked in the error state if it was already considered established (which means if a previous handshake was completed). The result is that the connection with the client is immediately aborted and any pending data are dropped.
2012-09-03 14:36:47 -04:00
conn->flags |= CO_FL_ERROR;
MEDIUM: connection: add error reporting for the SSL Get a bit more info in the logs when client-side SSL handshakes fail.
2012-12-03 10:32:10 -05:00
conn->err_code = CO_ER_SSL_RENEG;
}
MEDIUM: ssl: protect against client-initiated renegociation CVE-2009-3555 suggests that client-initiated renegociation should be prevented in the middle of data. The workaround here consists in having the SSL layer notify our callback about a handshake occurring, which in turn causes the connection to be marked in the error state if it was already considered established (which means if a previous handshake was completed). The result is that the connection with the client is immediately aborted and any pending data are dropped.
2012-09-03 14:36:47 -04:00
}
BUG/MEDIUM: ssl: Fix handling of TLS 1.3 KeyUpdate messages In OpenSSL 1.1.1 TLS 1.3 KeyUpdate messages will trigger the callback that is used to verify renegotiation is disabled. This means that these KeyUpdate messages fail. In OpenSSL 1.1.1 a better mechanism is available with the SSL_OP_NO_RENEGOTIATION flag that disables any TLS 1.2 and earlier negotiation. So if this SSL_OP_NO_RENEGOTIATION flag is available, instead of having a manual check, trust OpenSSL and disable the check. This means that TLS 1.3 KeyUpdate messages will work properly. Reported-By: Adam Langley <agl@imperialviolet.org>
2019-01-21 12:35:03 -05:00
#endif
MINOR: ssl: handshake optim for long certificate chains. Suggested on the mailing list by Ilya Grigorik and greatly inspired from Nginx code: we try to dynamicaly rise the output buffer size from 4k to 16k during the handshake to reduce the number of round trips. This is mostly beneficial when initcwnd==10. Ilya's tests confirm the gain and show a handshake time divided by 3 : before: http://www.webpagetest.org/result/140116_VW_3bd95a5cfb7e667498ef13b59639b9bf/2/details/ after: http://www.webpagetest.org/result/140201_2X_03511ec63344f442b81c24d2bf39f59d/3/details/
2014-01-28 09:43:53 -05:00
if ((where & SSL_CB_ACCEPT_LOOP) == SSL_CB_ACCEPT_LOOP) {
MEDIUM: connections: Move some fields from struct connection to ssl_sock_ctx. Move xprt_st, tmp_early_data and sent_early_data from struct connection to struct ssl_sock_ctx, as they are only used in the SSL code.
2019-02-28 12:10:45 -05:00
if (!(ctx->xprt_st & SSL_SOCK_ST_FL_16K_WBFSIZE)) {
MINOR: ssl: handshake optim for long certificate chains. Suggested on the mailing list by Ilya Grigorik and greatly inspired from Nginx code: we try to dynamicaly rise the output buffer size from 4k to 16k during the handshake to reduce the number of round trips. This is mostly beneficial when initcwnd==10. Ilya's tests confirm the gain and show a handshake time divided by 3 : before: http://www.webpagetest.org/result/140116_VW_3bd95a5cfb7e667498ef13b59639b9bf/2/details/ after: http://www.webpagetest.org/result/140201_2X_03511ec63344f442b81c24d2bf39f59d/3/details/
2014-01-28 09:43:53 -05:00
/* Long certificate chains optimz
CLEANUP: assorted typo fixes in the code and comments These are mostly comments in the code. A few error messages were fixed and are of low enough importance not to deserve a backport. Some regtests were also fixed.
2020-03-10 03:06:11 -04:00
If write and read bios are different, we
MINOR: ssl: handshake optim for long certificate chains. Suggested on the mailing list by Ilya Grigorik and greatly inspired from Nginx code: we try to dynamicaly rise the output buffer size from 4k to 16k during the handshake to reduce the number of round trips. This is mostly beneficial when initcwnd==10. Ilya's tests confirm the gain and show a handshake time divided by 3 : before: http://www.webpagetest.org/result/140116_VW_3bd95a5cfb7e667498ef13b59639b9bf/2/details/ after: http://www.webpagetest.org/result/140201_2X_03511ec63344f442b81c24d2bf39f59d/3/details/
2014-01-28 09:43:53 -05:00
consider that the buffering was activated,
so we rise the output buffer size from 4k
to 16k */
write_bio = SSL_get_wbio(ssl);
if (write_bio != SSL_get_rbio(ssl)) {
BIO_set_write_buffer_size(write_bio, 16384);
MEDIUM: connections: Move some fields from struct connection to ssl_sock_ctx. Move xprt_st, tmp_early_data and sent_early_data from struct connection to struct ssl_sock_ctx, as they are only used in the SSL code.
2019-02-28 12:10:45 -05:00
ctx->xprt_st |= SSL_SOCK_ST_FL_16K_WBFSIZE;
MINOR: ssl: handshake optim for long certificate chains. Suggested on the mailing list by Ilya Grigorik and greatly inspired from Nginx code: we try to dynamicaly rise the output buffer size from 4k to 16k during the handshake to reduce the number of round trips. This is mostly beneficial when initcwnd==10. Ilya's tests confirm the gain and show a handshake time divided by 3 : before: http://www.webpagetest.org/result/140116_VW_3bd95a5cfb7e667498ef13b59639b9bf/2/details/ after: http://www.webpagetest.org/result/140201_2X_03511ec63344f442b81c24d2bf39f59d/3/details/
2014-01-28 09:43:53 -05:00
}
}
}
MEDIUM: ssl: protect against client-initiated renegociation CVE-2009-3555 suggests that client-initiated renegociation should be prevented in the middle of data. The workaround here consists in having the SSL layer notify our callback about a handshake occurring, which in turn causes the connection to be marked in the error state if it was already considered established (which means if a previous handshake was completed). The result is that the connection with the client is immediately aborted and any pending data are dropped.
2012-09-03 14:36:47 -04:00
}
MINOR: ssl: add fetch and ACL 'client_crt' to test a client cert is present Useful in case of 'verify optional' to know if the client sent a certificate.
2012-09-21 07:15:06 -04:00
/* Callback is called for each certificate of the chain during a verify
ok is set to 1 if preverify detect no error on current certificate.
Returns 0 to break the handshake, 1 otherwise. */
MINOR: ssl: Add statement 'verifyhost' to "server" statements verifyhost allows you to specify a hostname that the remote server's SSL certificate must match. Connections that don't match will be closed with an SSL error.
2013-06-27 03:05:25 -04:00
int ssl_sock_bind_verifycbk(int ok, X509_STORE_CTX *x_store)
MINOR: ssl: add fetch and ACL 'client_crt' to test a client cert is present Useful in case of 'verify optional' to know if the client sent a certificate.
2012-09-21 07:15:06 -04:00
{
SSL *ssl;
struct connection *conn;
BUG/MINOR: quic: Possible crash when verifying certificates This verification is done by ssl_sock_bind_verifycbk() which is set at different locations in the ssl_sock.c code . About QUIC connections, there are a lot of chances the connection object is not initialized when entering this function. What must be accessed is the SSL object to retrieve the connection or quic_conn objects, then the bind_conf object of the listener. If the connection object is not found, we try to find the quic_conn object. Modify ssl_sock_dump_errors() interface which takes a connection object as parameter to also passed a quic_conn object as parameter. Again this function try first to access the connection object if not NULL or the quic_conn object if not. There is a remaining thing to do for QUIC: store the certificate verification error code as it is currently stored in the connection object. This error code is at least used by the "bc_err" and "fc_err" sample fetches. There are chances this bug is in relation with GH #1851. Thank you to @tasavis for the report. Must be merged into 2.6.
2022-09-06 13:37:08 -04:00
struct ssl_sock_ctx *ctx = NULL;
MINOR: ssl: add ignore verify errors options Allow to ignore some verify errors and to let them pass the handshake. Add option 'crt-ignore-err <list>' Ignore verify errors at depth == 0 (client certificate) <list> is string 'all' or a comma separated list of verify error IDs (see http://www.openssl.org/docs/apps/verify.html) Add option 'ca-ignore-err <list>' Same as 'crt-ignore-err' for all depths > 0 (CA chain certs) Ex ignore all errors on CA and expired or not-yet-valid errors on client certificate: bind 0.0.0.0:443 ssl crt crt.pem verify required cafile ca.pem ca-ignore-err all crt-ignore-err 10,9
2012-09-21 08:31:21 -04:00
int err, depth;
MEDIUM: ssl: Keep a reference to the client's certificate for use in logs Most of the SSL sample fetches related to the client certificate were based on the SSL_get_peer_certificate function which returns NULL when the verification process failed. This made it impossible to use those fetches in a log format since they would always be empty. The patch adds a reference to the X509 object representing the client certificate in the SSL structure and makes use of this reference in the fetches. The reference can only be obtained in ssl_sock_bind_verifycbk which means that in case of an SSL error occurring before the verification process ("no shared cipher" for instance, which happens while processing the Client Hello), we won't ever start the verification process and it will be impossible to get information about the client certificate. This patch also allows most of the ssl_c_XXX fetches to return a usable value in case of connection failure (because of a verification error for instance) by making the "conn->flags & CO_FL_WAIT_XPRT" test (which requires a connection to be established) less strict. Thanks to this patch, a log-format such as the following should return usable information in case of an error occurring during the verification process : log-format "DN=%{+Q}[ssl_c_s_dn] serial=%[ssl_c_serial,hex] \ hash=%[ssl_c_sha1,hex]" It should answer to GitHub issue #693.
2021-08-19 12:06:30 -04:00
X509 *client_crt;
STACK_OF(X509) *certs;
BUILD: ssl_sock: bind_conf uninitialized in ssl_sock_bind_verifycbk() Even if this cannot happen, ensure <bind_conf> is initialized in this function to please some compilers. Takes the opportunity of this patch to replace an ABORT_NOW() by a BUG_ON() because if the variable values they test are not initialized, this is really because there is a bug. Must be backported to 2.6.
2022-10-14 03:34:00 -04:00
struct bind_conf *bind_conf = NULL;
BUG/MINOR: quic: Possible crash when verifying certificates This verification is done by ssl_sock_bind_verifycbk() which is set at different locations in the ssl_sock.c code . About QUIC connections, there are a lot of chances the connection object is not initialized when entering this function. What must be accessed is the SSL object to retrieve the connection or quic_conn objects, then the bind_conf object of the listener. If the connection object is not found, we try to find the quic_conn object. Modify ssl_sock_dump_errors() interface which takes a connection object as parameter to also passed a quic_conn object as parameter. Again this function try first to access the connection object if not NULL or the quic_conn object if not. There is a remaining thing to do for QUIC: store the certificate verification error code as it is currently stored in the connection object. This error code is at least used by the "bc_err" and "fc_err" sample fetches. There are chances this bug is in relation with GH #1851. Thank you to @tasavis for the report. Must be merged into 2.6.
2022-09-06 13:37:08 -04:00
struct quic_conn *qc = NULL;
MINOR: ssl: add fetch and ACL 'client_crt' to test a client cert is present Useful in case of 'verify optional' to know if the client sent a certificate.
2012-09-21 07:15:06 -04:00
ssl = X509_STORE_CTX_get_ex_data(x_store, SSL_get_ex_data_X509_STORE_CTX_idx());
BUG/MAJOR: ssl: OpenSSL context is stored in non-reserved memory slot We never saw unexplicated crash with SSL, so I suppose that we are luck, or the slot 0 is always reserved. Anyway the usage of the macro SSL_get_app_data() and SSL_set_app_data() seem wrong. This patch change the deprecated functions SSL_get_app_data() and SSL_set_app_data() by the new functions SSL_get_ex_data() and SSL_set_ex_data(), and it reserves the slot in the SSL memory space. For information, this is the two declaration which seems wrong or incomplete in the OpenSSL ssl.h file. We can see the usage of the slot 0 whoch is hardcoded, but never reserved. #define SSL_set_app_data(s,arg) (SSL_set_ex_data(s,0,(char *)arg)) #define SSL_get_app_data(s) (SSL_get_ex_data(s,0)) This patch must be backported at least in 1.8, maybe in other versions.
2018-06-17 15:37:05 -04:00
conn = SSL_get_ex_data(ssl, ssl_app_data_index);
MEDIUM: ssl: Keep a reference to the client's certificate for use in logs Most of the SSL sample fetches related to the client certificate were based on the SSL_get_peer_certificate function which returns NULL when the verification process failed. This made it impossible to use those fetches in a log format since they would always be empty. The patch adds a reference to the X509 object representing the client certificate in the SSL structure and makes use of this reference in the fetches. The reference can only be obtained in ssl_sock_bind_verifycbk which means that in case of an SSL error occurring before the verification process ("no shared cipher" for instance, which happens while processing the Client Hello), we won't ever start the verification process and it will be impossible to get information about the client certificate. This patch also allows most of the ssl_c_XXX fetches to return a usable value in case of connection failure (because of a verification error for instance) by making the "conn->flags & CO_FL_WAIT_XPRT" test (which requires a connection to be established) less strict. Thanks to this patch, a log-format such as the following should return usable information in case of an error occurring during the verification process : log-format "DN=%{+Q}[ssl_c_s_dn] serial=%[ssl_c_serial,hex] \ hash=%[ssl_c_sha1,hex]" It should answer to GitHub issue #693.
2021-08-19 12:06:30 -04:00
client_crt = SSL_get_ex_data(ssl, ssl_client_crt_ref_index);
MINOR: ssl: add fetch and ACL 'client_crt' to test a client cert is present Useful in case of 'verify optional' to know if the client sent a certificate.
2012-09-21 07:15:06 -04:00
BUG/MINOR: quic: Possible crash when verifying certificates This verification is done by ssl_sock_bind_verifycbk() which is set at different locations in the ssl_sock.c code . About QUIC connections, there are a lot of chances the connection object is not initialized when entering this function. What must be accessed is the SSL object to retrieve the connection or quic_conn objects, then the bind_conf object of the listener. If the connection object is not found, we try to find the quic_conn object. Modify ssl_sock_dump_errors() interface which takes a connection object as parameter to also passed a quic_conn object as parameter. Again this function try first to access the connection object if not NULL or the quic_conn object if not. There is a remaining thing to do for QUIC: store the certificate verification error code as it is currently stored in the connection object. This error code is at least used by the "bc_err" and "fc_err" sample fetches. There are chances this bug is in relation with GH #1851. Thank you to @tasavis for the report. Must be merged into 2.6.
2022-09-06 13:37:08 -04:00
if (conn) {
bind_conf = __objt_listener(conn->target)->bind_conf;
ctx = __conn_get_ssl_sock_ctx(conn);
}
#ifdef USE_QUIC
else {
qc = SSL_get_ex_data(ssl, ssl_qc_app_data_index);
BUILD: ssl_sock: fix null dereference for QUIC build A previous commit tries to fix uninitialized GCC warning on ssl code for QUIC build. See the fix here : 48e46f98ccf97427995eb41c6f28cc38705bdd7e BUILD: ssl_sock: bind_conf uninitialized in ssl_sock_bind_verifycbk() However, this is incomplete as it still reports possible NULL dereference on ctx variable (GCC v12.2.0). Here is the compilation result : src/ssl_sock.c: In function ‘ssl_sock_bind_verifycbk’: src/ssl_sock.c:1739:12: error: potential null pointer dereference [-Werror=null-dereference] 1739 | ctx->xprt_st |= SSL_SOCK_ST_FL_VERIFY_DONE; | To fix this, remove check on qc which can also never happens and replace it with a BUG_ON. This seems to satisfy GCC on my machine. This must be backported up to 2.6.
2022-10-17 12:46:49 -04:00
BUG_ON(!qc); /* Must never happen */
bind_conf = qc->li->bind_conf;
ctx = qc->xprt_ctx;
BUG/MINOR: quic: Possible crash when verifying certificates This verification is done by ssl_sock_bind_verifycbk() which is set at different locations in the ssl_sock.c code . About QUIC connections, there are a lot of chances the connection object is not initialized when entering this function. What must be accessed is the SSL object to retrieve the connection or quic_conn objects, then the bind_conf object of the listener. If the connection object is not found, we try to find the quic_conn object. Modify ssl_sock_dump_errors() interface which takes a connection object as parameter to also passed a quic_conn object as parameter. Again this function try first to access the connection object if not NULL or the quic_conn object if not. There is a remaining thing to do for QUIC: store the certificate verification error code as it is currently stored in the connection object. This error code is at least used by the "bc_err" and "fc_err" sample fetches. There are chances this bug is in relation with GH #1851. Thank you to @tasavis for the report. Must be merged into 2.6.
2022-09-06 13:37:08 -04:00
}
#endif
BUILD: ssl_sock: bind_conf uninitialized in ssl_sock_bind_verifycbk() Even if this cannot happen, ensure <bind_conf> is initialized in this function to please some compilers. Takes the opportunity of this patch to replace an ABORT_NOW() by a BUG_ON() because if the variable values they test are not initialized, this is really because there is a bug. Must be backported to 2.6.
2022-10-14 03:34:00 -04:00
BUG_ON(!ctx || !bind_conf);
BUILD: ssl-sock: Silent error about NULL deref in ssl_sock_bind_verifycbk() In ssl_sock_bind_verifycbk(), when compiled without QUIC support, the compiler may report an error during compilation about a possible NULL dereference: src/ssl_sock.c: In function ‘ssl_sock_bind_verifycbk’: src/ssl_sock.c:1738:12: error: potential null pointer dereference [-Werror=null-dereference] 1738 | ctx->xprt_st |= SSL_SOCK_ST_FL_VERIFY_DONE; | ~~~^~~~~~~~~ A BUG_ON() was addeded because it must never happen. But when compiled without DEBUG_STRICT, there is nothing to help the compiler. Thus ALREADY_CHECKED() macro is used. The ssl-sock context and the bind config are concerned. This patch must be backported to 2.6.
2022-11-23 03:27:13 -05:00
ALREADY_CHECKED(ctx);
ALREADY_CHECKED(bind_conf);
BUG/MINOR: quic: Possible crash when verifying certificates This verification is done by ssl_sock_bind_verifycbk() which is set at different locations in the ssl_sock.c code . About QUIC connections, there are a lot of chances the connection object is not initialized when entering this function. What must be accessed is the SSL object to retrieve the connection or quic_conn objects, then the bind_conf object of the listener. If the connection object is not found, we try to find the quic_conn object. Modify ssl_sock_dump_errors() interface which takes a connection object as parameter to also passed a quic_conn object as parameter. Again this function try first to access the connection object if not NULL or the quic_conn object if not. There is a remaining thing to do for QUIC: store the certificate verification error code as it is currently stored in the connection object. This error code is at least used by the "bc_err" and "fc_err" sample fetches. There are chances this bug is in relation with GH #1851. Thank you to @tasavis for the report. Must be merged into 2.6.
2022-09-06 13:37:08 -04:00
MEDIUM: connections: Move some fields from struct connection to ssl_sock_ctx. Move xprt_st, tmp_early_data and sent_early_data from struct connection to struct ssl_sock_ctx, as they are only used in the SSL code.
2019-02-28 12:10:45 -05:00
ctx->xprt_st |= SSL_SOCK_ST_FL_VERIFY_DONE;
MINOR: ssl: add fetch and ACL 'client_crt' to test a client cert is present Useful in case of 'verify optional' to know if the client sent a certificate.
2012-09-21 07:15:06 -04:00
MEDIUM: ssl: Keep a reference to the client's certificate for use in logs Most of the SSL sample fetches related to the client certificate were based on the SSL_get_peer_certificate function which returns NULL when the verification process failed. This made it impossible to use those fetches in a log format since they would always be empty. The patch adds a reference to the X509 object representing the client certificate in the SSL structure and makes use of this reference in the fetches. The reference can only be obtained in ssl_sock_bind_verifycbk which means that in case of an SSL error occurring before the verification process ("no shared cipher" for instance, which happens while processing the Client Hello), we won't ever start the verification process and it will be impossible to get information about the client certificate. This patch also allows most of the ssl_c_XXX fetches to return a usable value in case of connection failure (because of a verification error for instance) by making the "conn->flags & CO_FL_WAIT_XPRT" test (which requires a connection to be established) less strict. Thanks to this patch, a log-format such as the following should return usable information in case of an error occurring during the verification process : log-format "DN=%{+Q}[ssl_c_s_dn] serial=%[ssl_c_serial,hex] \ hash=%[ssl_c_sha1,hex]" It should answer to GitHub issue #693.
2021-08-19 12:06:30 -04:00
depth = X509_STORE_CTX_get_error_depth(x_store);
err = X509_STORE_CTX_get_error(x_store);
MINOR: ssl: add ignore verify errors options Allow to ignore some verify errors and to let them pass the handshake. Add option 'crt-ignore-err <list>' Ignore verify errors at depth == 0 (client certificate) <list> is string 'all' or a comma separated list of verify error IDs (see http://www.openssl.org/docs/apps/verify.html) Add option 'ca-ignore-err <list>' Same as 'crt-ignore-err' for all depths > 0 (CA chain certs) Ex ignore all errors on CA and expired or not-yet-valid errors on client certificate: bind 0.0.0.0:443 ssl crt crt.pem verify required cafile ca.pem ca-ignore-err all crt-ignore-err 10,9
2012-09-21 08:31:21 -04:00
if (ok) /* no errors */
return ok;
MEDIUM: ssl: Keep a reference to the client's certificate for use in logs Most of the SSL sample fetches related to the client certificate were based on the SSL_get_peer_certificate function which returns NULL when the verification process failed. This made it impossible to use those fetches in a log format since they would always be empty. The patch adds a reference to the X509 object representing the client certificate in the SSL structure and makes use of this reference in the fetches. The reference can only be obtained in ssl_sock_bind_verifycbk which means that in case of an SSL error occurring before the verification process ("no shared cipher" for instance, which happens while processing the Client Hello), we won't ever start the verification process and it will be impossible to get information about the client certificate. This patch also allows most of the ssl_c_XXX fetches to return a usable value in case of connection failure (because of a verification error for instance) by making the "conn->flags & CO_FL_WAIT_XPRT" test (which requires a connection to be established) less strict. Thanks to this patch, a log-format such as the following should return usable information in case of an error occurring during the verification process : log-format "DN=%{+Q}[ssl_c_s_dn] serial=%[ssl_c_serial,hex] \ hash=%[ssl_c_sha1,hex]" It should answer to GitHub issue #693.
2021-08-19 12:06:30 -04:00
/* Keep a reference to the client's certificate in order to be able to
* dump some fetches values in a log even when the verification process
* fails. */
if (depth == 0) {
X509_free(client_crt);
client_crt = X509_STORE_CTX_get0_cert(x_store);
if (client_crt) {
X509_up_ref(client_crt);
SSL_set_ex_data(ssl, ssl_client_crt_ref_index, client_crt);
}
}
else {
/* An error occurred on a CA certificate of the certificate
* chain, we might never call this verify callback on the client
* certificate's depth (which is 0) so we try to store the
* reference right now. */
BUILD/MINOR: ssl: Fix compilation with OpenSSL 1.0.2 The X509_STORE_CTX_get0_cert did not exist yet on OpenSSL 1.0.2 and neither did X509_STORE_CTX_get0_chain, which was not actually needed since its get1 equivalent already existed.
2021-08-20 03:51:23 -04:00
certs = X509_STORE_CTX_get1_chain(x_store);
if (certs) {
client_crt = sk_X509_value(certs, 0);
if (client_crt) {
X509_up_ref(client_crt);
SSL_set_ex_data(ssl, ssl_client_crt_ref_index, client_crt);
MEDIUM: ssl: Keep a reference to the client's certificate for use in logs Most of the SSL sample fetches related to the client certificate were based on the SSL_get_peer_certificate function which returns NULL when the verification process failed. This made it impossible to use those fetches in a log format since they would always be empty. The patch adds a reference to the X509 object representing the client certificate in the SSL structure and makes use of this reference in the fetches. The reference can only be obtained in ssl_sock_bind_verifycbk which means that in case of an SSL error occurring before the verification process ("no shared cipher" for instance, which happens while processing the Client Hello), we won't ever start the verification process and it will be impossible to get information about the client certificate. This patch also allows most of the ssl_c_XXX fetches to return a usable value in case of connection failure (because of a verification error for instance) by making the "conn->flags & CO_FL_WAIT_XPRT" test (which requires a connection to be established) less strict. Thanks to this patch, a log-format such as the following should return usable information in case of an error occurring during the verification process : log-format "DN=%{+Q}[ssl_c_s_dn] serial=%[ssl_c_serial,hex] \ hash=%[ssl_c_sha1,hex]" It should answer to GitHub issue #693.
2021-08-19 12:06:30 -04:00
}
sk_X509_pop_free(certs, X509_free);
}
}
MINOR: ssl: add ignore verify errors options Allow to ignore some verify errors and to let them pass the handshake. Add option 'crt-ignore-err <list>' Ignore verify errors at depth == 0 (client certificate) <list> is string 'all' or a comma separated list of verify error IDs (see http://www.openssl.org/docs/apps/verify.html) Add option 'ca-ignore-err <list>' Same as 'crt-ignore-err' for all depths > 0 (CA chain certs) Ex ignore all errors on CA and expired or not-yet-valid errors on client certificate: bind 0.0.0.0:443 ssl crt crt.pem verify required cafile ca.pem ca-ignore-err all crt-ignore-err 10,9
2012-09-21 08:31:21 -04:00
/* check if CA error needs to be ignored */
if (depth > 0) {
MEDIUM: connections: Move some fields from struct connection to ssl_sock_ctx. Move xprt_st, tmp_early_data and sent_early_data from struct connection to struct ssl_sock_ctx, as they are only used in the SSL code.
2019-02-28 12:10:45 -05:00
if (!SSL_SOCK_ST_TO_CA_ERROR(ctx->xprt_st)) {
ctx->xprt_st |= SSL_SOCK_CA_ERROR_TO_ST(err);
ctx->xprt_st |= SSL_SOCK_CAEDEPTH_TO_ST(depth);
MINOR: ssl: add fetches and ACLs to return verify errors Add fetch 'ssl_verify_caerr': returns the first ssl verify error at depth > 0 (CA chain). Add fetch 'ssl_verify_caerr_depth': returns the first ssl verify error depth (max returns is 15 if depth > 15). Add fetch 'ssl_verify_crterr': returns the fist ssl verify error at depth == 0.
2012-09-21 09:27:54 -04:00
}
BUG/MEDIUM: ssl: Verify error codes can exceed 63 The CRT and CA verify error codes were stored in 6 bits each in the xprt_st field of the ssl_sock_ctx meaning that only error code up to 63 could be stored. Likewise, the ca-ignore-err and crt-ignore-err options relied on two unsigned long longs that were used as bitfields for all the ignored error codes. On the latest OpenSSL1.1.1 and with OpenSSLv3 and newer, verify errors have exceeded this value so these two storages must be increased. The error codes will now be stored on 7 bits each and the ignore-err bitfields are replaced by a big enough array and dedicated bit get and set functions. It can be backported on all stable branches. [wla: let it be tested a little while before backport] Signed-off-by: William Lallemand <wlallemand@haproxy.org>
2022-11-10 04:48:58 -05:00
if (err <= SSL_MAX_VFY_ERROR_CODE &&
BUG/MINOR: ssl: bind_conf is uncorrectly accessed when using QUIC Since commit 9b2598 ("BUG/MEDIUM: ssl: Verify error codes can exceed 63"), the ca_ignerr_bitfield and crt_ignerr_bietfield are incorrecly accessed from __objt_listener(conn->target)->bind_conf which is not avaiable from QUIC. The bind_conf variable was mistakenly replaced. This patch fixes the issue by using again the bind_conf variable. Must be backported where 9b2598 was backported.
2022-11-10 10:45:24 -05:00
cert_ignerr_bitfield_get(bind_conf->ca_ignerr_bitfield, err))
BUG/MINOR: quic: Possible crash when verifying certificates This verification is done by ssl_sock_bind_verifycbk() which is set at different locations in the ssl_sock.c code . About QUIC connections, there are a lot of chances the connection object is not initialized when entering this function. What must be accessed is the SSL object to retrieve the connection or quic_conn objects, then the bind_conf object of the listener. If the connection object is not found, we try to find the quic_conn object. Modify ssl_sock_dump_errors() interface which takes a connection object as parameter to also passed a quic_conn object as parameter. Again this function try first to access the connection object if not NULL or the quic_conn object if not. There is a remaining thing to do for QUIC: store the certificate verification error code as it is currently stored in the connection object. This error code is at least used by the "bc_err" and "fc_err" sample fetches. There are chances this bug is in relation with GH #1851. Thank you to @tasavis for the report. Must be merged into 2.6.
2022-09-06 13:37:08 -04:00
goto err_ignored;
MINOR: ssl: add ignore verify errors options Allow to ignore some verify errors and to let them pass the handshake. Add option 'crt-ignore-err <list>' Ignore verify errors at depth == 0 (client certificate) <list> is string 'all' or a comma separated list of verify error IDs (see http://www.openssl.org/docs/apps/verify.html) Add option 'ca-ignore-err <list>' Same as 'crt-ignore-err' for all depths > 0 (CA chain certs) Ex ignore all errors on CA and expired or not-yet-valid errors on client certificate: bind 0.0.0.0:443 ssl crt crt.pem verify required cafile ca.pem ca-ignore-err all crt-ignore-err 10,9
2012-09-21 08:31:21 -04:00
BUG/MINOR: quic: Possible crash when verifying certificates This verification is done by ssl_sock_bind_verifycbk() which is set at different locations in the ssl_sock.c code . About QUIC connections, there are a lot of chances the connection object is not initialized when entering this function. What must be accessed is the SSL object to retrieve the connection or quic_conn objects, then the bind_conf object of the listener. If the connection object is not found, we try to find the quic_conn object. Modify ssl_sock_dump_errors() interface which takes a connection object as parameter to also passed a quic_conn object as parameter. Again this function try first to access the connection object if not NULL or the quic_conn object if not. There is a remaining thing to do for QUIC: store the certificate verification error code as it is currently stored in the connection object. This error code is at least used by the "bc_err" and "fc_err" sample fetches. There are chances this bug is in relation with GH #1851. Thank you to @tasavis for the report. Must be merged into 2.6.
2022-09-06 13:37:08 -04:00
/* TODO: for QUIC connection, this error code is lost */
if (conn)
conn->err_code = CO_ER_SSL_CA_FAIL;
MINOR: ssl: add ignore verify errors options Allow to ignore some verify errors and to let them pass the handshake. Add option 'crt-ignore-err <list>' Ignore verify errors at depth == 0 (client certificate) <list> is string 'all' or a comma separated list of verify error IDs (see http://www.openssl.org/docs/apps/verify.html) Add option 'ca-ignore-err <list>' Same as 'crt-ignore-err' for all depths > 0 (CA chain certs) Ex ignore all errors on CA and expired or not-yet-valid errors on client certificate: bind 0.0.0.0:443 ssl crt crt.pem verify required cafile ca.pem ca-ignore-err all crt-ignore-err 10,9
2012-09-21 08:31:21 -04:00
return 0;
}
MEDIUM: connections: Move some fields from struct connection to ssl_sock_ctx. Move xprt_st, tmp_early_data and sent_early_data from struct connection to struct ssl_sock_ctx, as they are only used in the SSL code.
2019-02-28 12:10:45 -05:00
if (!SSL_SOCK_ST_TO_CRTERROR(ctx->xprt_st))
ctx->xprt_st |= SSL_SOCK_CRTERROR_TO_ST(err);
MINOR: ssl: add fetches and ACLs to return verify errors Add fetch 'ssl_verify_caerr': returns the first ssl verify error at depth > 0 (CA chain). Add fetch 'ssl_verify_caerr_depth': returns the first ssl verify error depth (max returns is 15 if depth > 15). Add fetch 'ssl_verify_crterr': returns the fist ssl verify error at depth == 0.
2012-09-21 09:27:54 -04:00
MINOR: ssl: add ignore verify errors options Allow to ignore some verify errors and to let them pass the handshake. Add option 'crt-ignore-err <list>' Ignore verify errors at depth == 0 (client certificate) <list> is string 'all' or a comma separated list of verify error IDs (see http://www.openssl.org/docs/apps/verify.html) Add option 'ca-ignore-err <list>' Same as 'crt-ignore-err' for all depths > 0 (CA chain certs) Ex ignore all errors on CA and expired or not-yet-valid errors on client certificate: bind 0.0.0.0:443 ssl crt crt.pem verify required cafile ca.pem ca-ignore-err all crt-ignore-err 10,9
2012-09-21 08:31:21 -04:00
/* check if certificate error needs to be ignored */
BUG/MEDIUM: ssl: Verify error codes can exceed 63 The CRT and CA verify error codes were stored in 6 bits each in the xprt_st field of the ssl_sock_ctx meaning that only error code up to 63 could be stored. Likewise, the ca-ignore-err and crt-ignore-err options relied on two unsigned long longs that were used as bitfields for all the ignored error codes. On the latest OpenSSL1.1.1 and with OpenSSLv3 and newer, verify errors have exceeded this value so these two storages must be increased. The error codes will now be stored on 7 bits each and the ignore-err bitfields are replaced by a big enough array and dedicated bit get and set functions. It can be backported on all stable branches. [wla: let it be tested a little while before backport] Signed-off-by: William Lallemand <wlallemand@haproxy.org>
2022-11-10 04:48:58 -05:00
if (err <= SSL_MAX_VFY_ERROR_CODE &&
BUG/MINOR: ssl: bind_conf is uncorrectly accessed when using QUIC Since commit 9b2598 ("BUG/MEDIUM: ssl: Verify error codes can exceed 63"), the ca_ignerr_bitfield and crt_ignerr_bietfield are incorrecly accessed from __objt_listener(conn->target)->bind_conf which is not avaiable from QUIC. The bind_conf variable was mistakenly replaced. This patch fixes the issue by using again the bind_conf variable. Must be backported where 9b2598 was backported.
2022-11-10 10:45:24 -05:00
cert_ignerr_bitfield_get(bind_conf->crt_ignerr_bitfield, err))
BUG/MINOR: quic: Possible crash when verifying certificates This verification is done by ssl_sock_bind_verifycbk() which is set at different locations in the ssl_sock.c code . About QUIC connections, there are a lot of chances the connection object is not initialized when entering this function. What must be accessed is the SSL object to retrieve the connection or quic_conn objects, then the bind_conf object of the listener. If the connection object is not found, we try to find the quic_conn object. Modify ssl_sock_dump_errors() interface which takes a connection object as parameter to also passed a quic_conn object as parameter. Again this function try first to access the connection object if not NULL or the quic_conn object if not. There is a remaining thing to do for QUIC: store the certificate verification error code as it is currently stored in the connection object. This error code is at least used by the "bc_err" and "fc_err" sample fetches. There are chances this bug is in relation with GH #1851. Thank you to @tasavis for the report. Must be merged into 2.6.
2022-09-06 13:37:08 -04:00
goto err_ignored;
MINOR: ssl: add ignore verify errors options Allow to ignore some verify errors and to let them pass the handshake. Add option 'crt-ignore-err <list>' Ignore verify errors at depth == 0 (client certificate) <list> is string 'all' or a comma separated list of verify error IDs (see http://www.openssl.org/docs/apps/verify.html) Add option 'ca-ignore-err <list>' Same as 'crt-ignore-err' for all depths > 0 (CA chain certs) Ex ignore all errors on CA and expired or not-yet-valid errors on client certificate: bind 0.0.0.0:443 ssl crt crt.pem verify required cafile ca.pem ca-ignore-err all crt-ignore-err 10,9
2012-09-21 08:31:21 -04:00
BUG/MINOR: quic: Possible crash when verifying certificates This verification is done by ssl_sock_bind_verifycbk() which is set at different locations in the ssl_sock.c code . About QUIC connections, there are a lot of chances the connection object is not initialized when entering this function. What must be accessed is the SSL object to retrieve the connection or quic_conn objects, then the bind_conf object of the listener. If the connection object is not found, we try to find the quic_conn object. Modify ssl_sock_dump_errors() interface which takes a connection object as parameter to also passed a quic_conn object as parameter. Again this function try first to access the connection object if not NULL or the quic_conn object if not. There is a remaining thing to do for QUIC: store the certificate verification error code as it is currently stored in the connection object. This error code is at least used by the "bc_err" and "fc_err" sample fetches. There are chances this bug is in relation with GH #1851. Thank you to @tasavis for the report. Must be merged into 2.6.
2022-09-06 13:37:08 -04:00
/* TODO: for QUIC connection, this error code is lost */
if (conn)
conn->err_code = CO_ER_SSL_CRT_FAIL;
MINOR: ssl: add ignore verify errors options Allow to ignore some verify errors and to let them pass the handshake. Add option 'crt-ignore-err <list>' Ignore verify errors at depth == 0 (client certificate) <list> is string 'all' or a comma separated list of verify error IDs (see http://www.openssl.org/docs/apps/verify.html) Add option 'ca-ignore-err <list>' Same as 'crt-ignore-err' for all depths > 0 (CA chain certs) Ex ignore all errors on CA and expired or not-yet-valid errors on client certificate: bind 0.0.0.0:443 ssl crt crt.pem verify required cafile ca.pem ca-ignore-err all crt-ignore-err 10,9
2012-09-21 08:31:21 -04:00
return 0;
BUG/MINOR: quic: Possible crash when verifying certificates This verification is done by ssl_sock_bind_verifycbk() which is set at different locations in the ssl_sock.c code . About QUIC connections, there are a lot of chances the connection object is not initialized when entering this function. What must be accessed is the SSL object to retrieve the connection or quic_conn objects, then the bind_conf object of the listener. If the connection object is not found, we try to find the quic_conn object. Modify ssl_sock_dump_errors() interface which takes a connection object as parameter to also passed a quic_conn object as parameter. Again this function try first to access the connection object if not NULL or the quic_conn object if not. There is a remaining thing to do for QUIC: store the certificate verification error code as it is currently stored in the connection object. This error code is at least used by the "bc_err" and "fc_err" sample fetches. There are chances this bug is in relation with GH #1851. Thank you to @tasavis for the report. Must be merged into 2.6.
2022-09-06 13:37:08 -04:00
err_ignored:
ssl_sock_dump_errors(conn, qc);
ERR_clear_error();
return 1;
MINOR: ssl: add fetch and ACL 'client_crt' to test a client cert is present Useful in case of 'verify optional' to know if the client sent a certificate.
2012-09-21 07:15:06 -04:00
}
MEDIUM: ssl: split ssl_sock_msgcbk() and use a new callback mechanism Make use of ssl_sock_register_msg_callback(). Function ssl_sock_msgcbk() is now split into two dedicated functions for heartbeat and clienthello. They are both registered by using a new callback mechanism for SSL/TLS protocol messages.
2020-05-11 09:51:45 -04:00
#ifdef TLS1_RT_HEARTBEAT
static void ssl_sock_parse_heartbeat(struct connection *conn, int write_p, int version,
int content_type, const void *buf, size_t len,
SSL *ssl)
{
/* test heartbeat received (write_p is set to 0
for a received record) */
if ((content_type == TLS1_RT_HEARTBEAT) && (write_p == 0)) {
BUILD: ssl: add an unchecked version of __conn_get_ssl_sock_ctx() First gcc, then now coverity report possible null derefs in situations where we know these cannot happen since we call the functions in contexts that guarantee the existence of the connection and the method used. Let's introduce an unchecked version of the function for such cases, just like we had to do with objt_*. This allows us to remove the ALREADY_CHECKED() statements (which coverity doesn't see), and addresses github issues #1643, #1644, #1647.
2022-04-12 01:31:06 -04:00
struct ssl_sock_ctx *ctx = __conn_get_ssl_sock_ctx(conn);
MEDIUM: ssl: split ssl_sock_msgcbk() and use a new callback mechanism Make use of ssl_sock_register_msg_callback(). Function ssl_sock_msgcbk() is now split into two dedicated functions for heartbeat and clienthello. They are both registered by using a new callback mechanism for SSL/TLS protocol messages.
2020-05-11 09:51:45 -04:00
const unsigned char *p = buf;
unsigned int payload;
ctx->xprt_st |= SSL_SOCK_RECV_HEARTBEAT;
/* Check if this is a CVE-2014-0160 exploitation attempt. */
if (*p != TLS1_HB_REQUEST)
return;
if (len < 1 + 2 + 16) /* 1 type + 2 size + 0 payload + 16 padding */
goto kill_it;
payload = (p[1] * 256) + p[2];
if (3 + payload + 16 <= len)
return; /* OK no problem */
kill_it:
/* We have a clear heartbleed attack (CVE-2014-0160), the
* advertised payload is larger than the advertised packet
* length, so we have garbage in the buffer between the
* payload and the end of the buffer (p+len). We can't know
* if the SSL stack is patched, and we don't know if we can
* safely wipe out the area between p+3+len and payload.
* So instead, we prevent the response from being sent by
* setting the max_send_fragment to 0 and we report an SSL
* error, which will kill this connection. It will be reported
* above as SSL_ERROR_SSL while an other handshake failure with
* a heartbeat message will be reported as SSL_ERROR_SYSCALL.
*/
ssl->max_send_fragment = 0;
SSLerr(SSL_F_TLS1_HEARTBEAT, SSL_R_SSL_HANDSHAKE_FAILURE);
}
}
#endif
static void ssl_sock_parse_clienthello(struct connection *conn, int write_p, int version,
int content_type, const void *buf, size_t len,
SSL *ssl)
MEDIUM: ssl: add new sample-fetch which captures the cipherlist This new sample-fetches captures the cipher list offer by the client SSL connection during the client-hello phase. This is useful for fingerprint the SSL connection.
2017-02-25 06:45:22 -05:00
{
MINOR: ssl: improved cipherlist captures Alloc capture buffer later (when filling), parse client-hello after heartbeat check and remove capture->conn (unused).
2017-03-08 05:07:10 -05:00
struct ssl_capture *capture;
MEDIUM: ssl: Capture more info from Client Hello When we set tune.ssl.capture-cipherlist-size to a non-zero value we are able to capture cipherlist supported by the client. To be able to provide JA3 compatible TLS fingerprinting we need to capture more information from Client Hello message: - SSL Version - SSL Extensions - Elliptic Curves - Elliptic Curve Point Formats This patch allows HAProxy to capture such information and store it for later use.
2021-07-12 08:16:55 -04:00
uchar *msg;
uchar *end;
uchar *extensions_end;
uchar *ec_start = NULL;
uchar *ec_formats_start = NULL;
uchar *list_end;
ushort protocol_version;
ushort extension_id;
ushort ec_len = 0;
uchar ec_formats_len = 0;
int offset = 0;
int rec_len;
MEDIUM: ssl: add new sample-fetch which captures the cipherlist This new sample-fetches captures the cipher list offer by the client SSL connection during the client-hello phase. This is useful for fingerprint the SSL connection.
2017-02-25 06:45:22 -05:00
/* This function is called for "from client" and "to server"
* connections. The combination of write_p == 0 and content_type == 22
CLEANUP: fix typos in the ssl_sock subsystem Fix some typos found in the code comments of the ssl_sock subsystem.
2018-11-15 12:07:59 -05:00
* is only available during "from client" connection.
MEDIUM: ssl: add new sample-fetch which captures the cipherlist This new sample-fetches captures the cipher list offer by the client SSL connection during the client-hello phase. This is useful for fingerprint the SSL connection.
2017-02-25 06:45:22 -05:00
*/
/* "write_p" is set to 0 is the bytes are received messages,
* otherwise it is set to 1.
*/
if (write_p != 0)
return;
/* content_type contains the type of message received or sent
* according with the SSL/TLS protocol spec. This message is
* encoded with one byte. The value 256 (two bytes) is used
* for designing the SSL/TLS record layer. According with the
* rfc6101, the expected message (other than 256) are:
* - change_cipher_spec(20)
* - alert(21)
* - handshake(22)
* - application_data(23)
* - (255)
* We are interessed by the handshake and specially the client
* hello.
*/
if (content_type != 22)
return;
/* The message length is at least 4 bytes, containing the
* message type and the message length.
*/
if (len < 4)
return;
/* First byte of the handshake message id the type of
CLEANUP: assorted typo fixes in the code and comments These are mostly comments in the code. A few error messages were fixed and are of low enough importance not to deserve a backport. Some regtests were also fixed.
2020-03-10 03:06:11 -04:00
* message. The known types are:
MEDIUM: ssl: add new sample-fetch which captures the cipherlist This new sample-fetches captures the cipher list offer by the client SSL connection during the client-hello phase. This is useful for fingerprint the SSL connection.
2017-02-25 06:45:22 -05:00
* - hello_request(0)
* - client_hello(1)
* - server_hello(2)
* - certificate(11)
* - server_key_exchange (12)
* - certificate_request(13)
* - server_hello_done(14)
* We are interested by the client hello.
*/
msg = (unsigned char *)buf;
if (msg[0] != 1)
return;
/* Next three bytes are the length of the message. The total length
* must be this decoded length + 4. If the length given as argument
* is not the same, we abort the protocol dissector.
*/
rec_len = (msg[1] << 16) + (msg[2] << 8) + msg[3];
if (len < rec_len + 4)
return;
msg += 4;
end = msg + rec_len;
if (end < msg)
return;
MEDIUM: ssl: Capture more info from Client Hello When we set tune.ssl.capture-cipherlist-size to a non-zero value we are able to capture cipherlist supported by the client. To be able to provide JA3 compatible TLS fingerprinting we need to capture more information from Client Hello message: - SSL Version - SSL Extensions - Elliptic Curves - Elliptic Curve Point Formats This patch allows HAProxy to capture such information and store it for later use.
2021-07-12 08:16:55 -04:00
/* Expect 2 bytes for protocol version
* (1 byte for major and 1 byte for minor)
MEDIUM: ssl: add new sample-fetch which captures the cipherlist This new sample-fetches captures the cipher list offer by the client SSL connection during the client-hello phase. This is useful for fingerprint the SSL connection.
2017-02-25 06:45:22 -05:00
*/
MEDIUM: ssl: Capture more info from Client Hello When we set tune.ssl.capture-cipherlist-size to a non-zero value we are able to capture cipherlist supported by the client. To be able to provide JA3 compatible TLS fingerprinting we need to capture more information from Client Hello message: - SSL Version - SSL Extensions - Elliptic Curves - Elliptic Curve Point Formats This patch allows HAProxy to capture such information and store it for later use.
2021-07-12 08:16:55 -04:00
if (msg + 2 > end)
return;
protocol_version = (msg[0] << 8) + msg[1];
msg += 2;
/* Expect the random, composed by 4 bytes for the unix time and
* 28 bytes for unix payload. So we jump 4 + 28.
*/
msg += 4 + 28;
BUG/MINOR: ssl: ssl_sock_parse_clienthello ignores session id In ssl_sock_parse_clienthello(), the code considers that SSL Sessionid size is '1', and then considers that the SSL cipher suite is availble right after the session id size information. This actually works in a single case, when the client does not send a session id. This patch fixes this issue by introducing the a propoer way to parse the session id and move forward the cursor by the session id length when required. Need to be backported to 1.8.
2018-11-28 09:20:25 -05:00
if (msg > end)
return;
/* Next, is session id:
* if present, we have to jump by length + 1 for the size information
* if not present, we have to jump by 1 only
*/
if (msg[0] > 0)
msg += msg[0];
msg += 1;
MEDIUM: ssl: add new sample-fetch which captures the cipherlist This new sample-fetches captures the cipher list offer by the client SSL connection during the client-hello phase. This is useful for fingerprint the SSL connection.
2017-02-25 06:45:22 -05:00
if (msg > end)
return;
/* Next two bytes are the ciphersuite length. */
if (msg + 2 > end)
return;
rec_len = (msg[0] << 8) + msg[1];
msg += 2;
if (msg + rec_len > end || msg + rec_len < msg)
return;
MEDIUM: ssl: Capture more info from Client Hello When we set tune.ssl.capture-cipherlist-size to a non-zero value we are able to capture cipherlist supported by the client. To be able to provide JA3 compatible TLS fingerprinting we need to capture more information from Client Hello message: - SSL Version - SSL Extensions - Elliptic Curves - Elliptic Curve Point Formats This patch allows HAProxy to capture such information and store it for later use.
2021-07-12 08:16:55 -04:00
capture = pool_zalloc(pool_head_ssl_capture);
MINOR: ssl: improved cipherlist captures Alloc capture buffer later (when filling), parse client-hello after heartbeat check and remove capture->conn (unused).
2017-03-08 05:07:10 -05:00
if (!capture)
return;
MEDIUM: ssl: add new sample-fetch which captures the cipherlist This new sample-fetches captures the cipher list offer by the client SSL connection during the client-hello phase. This is useful for fingerprint the SSL connection.
2017-02-25 06:45:22 -05:00
/* Compute the xxh64 of the ciphersuite. */
capture->xxh64 = XXH64(msg, rec_len, 0);
/* Capture the ciphersuite. */
MEDIUM: config: Deprecate tune.ssl.capture-cipherlist-size Deprecate tune.ssl.capture-cipherlist-size in favor of tune.ssl.capture-buffer-size which better describes the purpose of the setting.
2021-07-13 13:04:24 -04:00
capture->ciphersuite_len = MIN(global_ssl.capture_buffer_size, rec_len);
MEDIUM: ssl: Capture more info from Client Hello When we set tune.ssl.capture-cipherlist-size to a non-zero value we are able to capture cipherlist supported by the client. To be able to provide JA3 compatible TLS fingerprinting we need to capture more information from Client Hello message: - SSL Version - SSL Extensions - Elliptic Curves - Elliptic Curve Point Formats This patch allows HAProxy to capture such information and store it for later use.
2021-07-12 08:16:55 -04:00
capture->ciphersuite_offset = 0;
memcpy(capture->data, msg, capture->ciphersuite_len);
msg += rec_len;
offset += capture->ciphersuite_len;
/* Initialize other data */
capture->protocol_version = protocol_version;
/* Next, compression methods:
* if present, we have to jump by length + 1 for the size information
* if not present, we have to jump by 1 only
*/
if (msg[0] > 0)
msg += msg[0];
msg += 1;
if (msg > end)
goto store_capture;
/* We reached extensions */
if (msg + 2 > end)
goto store_capture;
rec_len = (msg[0] << 8) + msg[1];
msg += 2;
if (msg + rec_len > end || msg + rec_len < msg)
goto store_capture;
extensions_end = msg + rec_len;
capture->extensions_offset = offset;
/* Parse each extension */
while (msg + 4 < extensions_end) {
/* Add 2 bytes of extension_id */
MEDIUM: config: Deprecate tune.ssl.capture-cipherlist-size Deprecate tune.ssl.capture-cipherlist-size in favor of tune.ssl.capture-buffer-size which better describes the purpose of the setting.
2021-07-13 13:04:24 -04:00
if (global_ssl.capture_buffer_size >= offset + 2) {
MEDIUM: ssl: Capture more info from Client Hello When we set tune.ssl.capture-cipherlist-size to a non-zero value we are able to capture cipherlist supported by the client. To be able to provide JA3 compatible TLS fingerprinting we need to capture more information from Client Hello message: - SSL Version - SSL Extensions - Elliptic Curves - Elliptic Curve Point Formats This patch allows HAProxy to capture such information and store it for later use.
2021-07-12 08:16:55 -04:00
capture->data[offset++] = msg[0];
capture->data[offset++] = msg[1];
capture->extensions_len += 2;
}
else
break;
extension_id = (msg[0] << 8) + msg[1];
/* Length of the extension */
rec_len = (msg[2] << 8) + msg[3];
/* Expect 2 bytes extension id + 2 bytes extension size */
msg += 2 + 2;
if (msg + rec_len > extensions_end || msg + rec_len < msg)
goto store_capture;
/* TLS Extensions
* https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml */
if (extension_id == 0x000a) {
/* Elliptic Curves:
* https://www.rfc-editor.org/rfc/rfc8422.html
* https://www.rfc-editor.org/rfc/rfc7919.html */
list_end = msg + rec_len;
if (msg + 2 > list_end)
goto store_capture;
rec_len = (msg[0] << 8) + msg[1];
msg += 2;
if (msg + rec_len > list_end || msg + rec_len < msg)
goto store_capture;
/* Store location/size of the list */
ec_start = msg;
ec_len = rec_len;
}
else if (extension_id == 0x000b) {
/* Elliptic Curves Point Formats:
* https://www.rfc-editor.org/rfc/rfc8422.html */
list_end = msg + rec_len;
if (msg + 1 > list_end)
goto store_capture;
rec_len = msg[0];
msg += 1;
if (msg + rec_len > list_end || msg + rec_len < msg)
goto store_capture;
/* Store location/size of the list */
ec_formats_start = msg;
ec_formats_len = rec_len;
}
msg += rec_len;
}
if (ec_start) {
rec_len = ec_len;
MEDIUM: config: Deprecate tune.ssl.capture-cipherlist-size Deprecate tune.ssl.capture-cipherlist-size in favor of tune.ssl.capture-buffer-size which better describes the purpose of the setting.
2021-07-13 13:04:24 -04:00
if (offset + rec_len > global_ssl.capture_buffer_size)
rec_len = global_ssl.capture_buffer_size - offset;
MEDIUM: ssl: Capture more info from Client Hello When we set tune.ssl.capture-cipherlist-size to a non-zero value we are able to capture cipherlist supported by the client. To be able to provide JA3 compatible TLS fingerprinting we need to capture more information from Client Hello message: - SSL Version - SSL Extensions - Elliptic Curves - Elliptic Curve Point Formats This patch allows HAProxy to capture such information and store it for later use.
2021-07-12 08:16:55 -04:00
memcpy(capture->data + offset, ec_start, rec_len);
capture->ec_offset = offset;
capture->ec_len = rec_len;
offset += rec_len;
}
if (ec_formats_start) {
rec_len = ec_formats_len;
MEDIUM: config: Deprecate tune.ssl.capture-cipherlist-size Deprecate tune.ssl.capture-cipherlist-size in favor of tune.ssl.capture-buffer-size which better describes the purpose of the setting.
2021-07-13 13:04:24 -04:00
if (offset + rec_len > global_ssl.capture_buffer_size)
rec_len = global_ssl.capture_buffer_size - offset;
MEDIUM: ssl: Capture more info from Client Hello When we set tune.ssl.capture-cipherlist-size to a non-zero value we are able to capture cipherlist supported by the client. To be able to provide JA3 compatible TLS fingerprinting we need to capture more information from Client Hello message: - SSL Version - SSL Extensions - Elliptic Curves - Elliptic Curve Point Formats This patch allows HAProxy to capture such information and store it for later use.
2021-07-12 08:16:55 -04:00
memcpy(capture->data + offset, ec_formats_start, rec_len);
capture->ec_formats_offset = offset;
capture->ec_formats_len = rec_len;
offset += rec_len;
}
MINOR: ssl: improved cipherlist captures Alloc capture buffer later (when filling), parse client-hello after heartbeat check and remove capture->conn (unused).
2017-03-08 05:07:10 -05:00
MEDIUM: ssl: Capture more info from Client Hello When we set tune.ssl.capture-cipherlist-size to a non-zero value we are able to capture cipherlist supported by the client. To be able to provide JA3 compatible TLS fingerprinting we need to capture more information from Client Hello message: - SSL Version - SSL Extensions - Elliptic Curves - Elliptic Curve Point Formats This patch allows HAProxy to capture such information and store it for later use.
2021-07-12 08:16:55 -04:00
store_capture:
MINOR: ssl: improved cipherlist captures Alloc capture buffer later (when filling), parse client-hello after heartbeat check and remove capture->conn (unused).
2017-03-08 05:07:10 -05:00
SSL_set_ex_data(ssl, ssl_capture_ptr_index, capture);
MEDIUM: ssl: add new sample-fetch which captures the cipherlist This new sample-fetches captures the cipher list offer by the client SSL connection during the client-hello phase. This is useful for fingerprint the SSL connection.
2017-02-25 06:45:22 -05:00
}
WIP/MINOR: ssl: add sample fetches for keylog in frontend OpenSSL 1.1.1 provides a callback registering function SSL_CTX_set_keylog_callback, which allows one to receive a string containing the keys to deciphers TLSv1.3. Unfortunately it is not possible to store this data in binary form and we can only get this information using the callback. Which means that we need to store it until the connection is closed. This patches add 2 pools, the first one, pool_head_ssl_keylog is used to store a struct ssl_keylog which will be inserted as a ex_data in a SSL *. The second one is pool_head_ssl_keylog_str which will be used to store the hexadecimal strings. To enable the capture of the keys, you need to set "tune.ssl.keylog on" in your configuration. The following fetches were implemented: ssl_fc_client_early_traffic_secret, ssl_fc_client_handshake_traffic_secret, ssl_fc_server_handshake_traffic_secret, ssl_fc_client_traffic_secret_0, ssl_fc_server_traffic_secret_0, ssl_fc_exporter_secret, ssl_fc_early_exporter_secret
2020-07-06 05:41:30 -04:00
BUILD: make tune.ssl.keylog available again Since commit 04a5a44 ("BUILD: ssl: use HAVE_OPENSSL_KEYLOG instead of OpenSSL versions") the "tune.ssl.keylog" feature is broken because HAVE_OPENSSL_KEYLOG does not exist. Replace this by a HAVE_SSL_KEYLOG which is defined in openssl-compat.h. Also add an error when not built with the right openssl version. Must be backported as far as 2.3.
2021-06-09 10:46:12 -04:00
#ifdef HAVE_SSL_KEYLOG
WIP/MINOR: ssl: add sample fetches for keylog in frontend OpenSSL 1.1.1 provides a callback registering function SSL_CTX_set_keylog_callback, which allows one to receive a string containing the keys to deciphers TLSv1.3. Unfortunately it is not possible to store this data in binary form and we can only get this information using the callback. Which means that we need to store it until the connection is closed. This patches add 2 pools, the first one, pool_head_ssl_keylog is used to store a struct ssl_keylog which will be inserted as a ex_data in a SSL *. The second one is pool_head_ssl_keylog_str which will be used to store the hexadecimal strings. To enable the capture of the keys, you need to set "tune.ssl.keylog on" in your configuration. The following fetches were implemented: ssl_fc_client_early_traffic_secret, ssl_fc_client_handshake_traffic_secret, ssl_fc_server_handshake_traffic_secret, ssl_fc_client_traffic_secret_0, ssl_fc_server_traffic_secret_0, ssl_fc_exporter_secret, ssl_fc_early_exporter_secret
2020-07-06 05:41:30 -04:00
static void ssl_init_keylog(struct connection *conn, int write_p, int version,
int content_type, const void *buf, size_t len,
SSL *ssl)
{
struct ssl_keylog *keylog;
if (SSL_get_ex_data(ssl, ssl_keylog_index))
return;
CLEANUP: ssl: use pool_zalloc() in ssl_init_keylog() This one used to alloc then zero the area, let's have the allocator do it.
2021-03-22 16:10:12 -04:00
keylog = pool_zalloc(pool_head_ssl_keylog);
WIP/MINOR: ssl: add sample fetches for keylog in frontend OpenSSL 1.1.1 provides a callback registering function SSL_CTX_set_keylog_callback, which allows one to receive a string containing the keys to deciphers TLSv1.3. Unfortunately it is not possible to store this data in binary form and we can only get this information using the callback. Which means that we need to store it until the connection is closed. This patches add 2 pools, the first one, pool_head_ssl_keylog is used to store a struct ssl_keylog which will be inserted as a ex_data in a SSL *. The second one is pool_head_ssl_keylog_str which will be used to store the hexadecimal strings. To enable the capture of the keys, you need to set "tune.ssl.keylog on" in your configuration. The following fetches were implemented: ssl_fc_client_early_traffic_secret, ssl_fc_client_handshake_traffic_secret, ssl_fc_server_handshake_traffic_secret, ssl_fc_client_traffic_secret_0, ssl_fc_server_traffic_secret_0, ssl_fc_exporter_secret, ssl_fc_early_exporter_secret
2020-07-06 05:41:30 -04:00
if (!keylog)
return;
if (!SSL_set_ex_data(ssl, ssl_keylog_index, keylog)) {
pool_free(pool_head_ssl_keylog, keylog);
return;
}
}
#endif
MEDIUM: ssl: explicitly log failed handshakes after a heartbeat Add a callback to receive the heartbeat notification. There, we add SSL_SOCK_RECV_HEARTBEAT flag on the ssl session if a heartbeat is seen. If a handshake fails, we log a different message to mention the fact that a heartbeat was seen. The test is only performed on the frontend side.
2014-04-25 13:05:36 -04:00
/* Callback is called for ssl protocol analyse */
void ssl_sock_msgcbk(int write_p, int version, int content_type, const void *buf, size_t len, SSL *ssl, void *arg)
{
MEDIUM: ssl: allow to register callbacks for SSL/TLS protocol messages This patch adds the ability to register callbacks for SSL/TLS protocol messages by using the function ssl_sock_register_msg_callback(). All registered callback functions will be called when observing received or sent SSL/TLS protocol messages.
2020-05-08 12:30:00 -04:00
struct connection *conn = SSL_get_ex_data(ssl, ssl_app_data_index);
struct ssl_sock_msg_callback *cbk;
/* Try to call all callback functions that were registered by using
* ssl_sock_register_msg_callback().
*/
list_for_each_entry(cbk, &ssl_sock_msg_callbacks, list) {
cbk->func(conn, write_p, version, content_type, buf, len, ssl);
}
MEDIUM: ssl: explicitly log failed handshakes after a heartbeat Add a callback to receive the heartbeat notification. There, we add SSL_SOCK_RECV_HEARTBEAT flag on the ssl session if a heartbeat is seen. If a handshake fails, we log a different message to mention the fact that a heartbeat was seen. The test is only performed on the frontend side.
2014-04-25 13:05:36 -04:00
}
MINOR: server: Add "alpn" and "npn" keywords. Add new keywords to "server" lines, alpn and npn. If set, when connecting through SSL, those alpn/npn will be negociated during the SSL handshake.
2018-11-20 17:33:50 -05:00
#if defined(OPENSSL_NPN_NEGOTIATED) && !defined(OPENSSL_NO_NEXTPROTONEG)
static int ssl_sock_srv_select_protos(SSL *s, unsigned char **out, unsigned char *outlen,
const unsigned char *in, unsigned int inlen,
void *arg)
{
struct server *srv = arg;
if (SSL_select_next_proto(out, outlen, in, inlen, (unsigned char *)srv->ssl_ctx.npn_str,
srv->ssl_ctx.npn_len) == OPENSSL_NPN_NEGOTIATED)
return SSL_TLSEXT_ERR_OK;
return SSL_TLSEXT_ERR_NOACK;
}
#endif
BUILD: ssl: Fix build with OpenSSL without NPN capability OpenSSL can be built without NEXTPROTONEG support by passing -no-npn to the configure script. This sets the OPENSSL_NO_NEXTPROTONEG flag in opensslconf.h Since NEXTPROTONEG is now considered deprecated, it is superseeded by ALPN (Application Layer Protocol Next), HAProxy should allow building withough NPN support.
2018-02-15 07:34:58 -05:00
#if defined(OPENSSL_NPN_NEGOTIATED) && !defined(OPENSSL_NO_NEXTPROTONEG)
MEDIUM: ssl: add support for the "npn" bind keyword The ssl_npn match could not work by itself because clients do not use the NPN extension unless the server advertises the protocols it supports. Thanks to Simone Bordet for the explanations on how to get it right.
2012-10-18 12:57:14 -04:00
/* This callback is used so that the server advertises the list of
CLEANUP: assorted typo fixes in the code and comments These are mostly comments in the code. A few error messages were fixed and are of low enough importance not to deserve a backport. Some regtests were also fixed.
2020-03-10 03:06:11 -04:00
* negotiable protocols for NPN.
MEDIUM: ssl: add support for the "npn" bind keyword The ssl_npn match could not work by itself because clients do not use the NPN extension unless the server advertises the protocols it supports. Thanks to Simone Bordet for the explanations on how to get it right.
2012-10-18 12:57:14 -04:00
*/
static int ssl_sock_advertise_npn_protos(SSL *s, const unsigned char **data,
unsigned int *len, void *arg)
{
MAJOR: ssl: bind configuration per certificat crt-list is extend to support ssl configuration. You can now have such line in crt-list <file>: mycert.pem [npn h2,http/1.1] Support include "npn", "alpn", "verify", "ca_file", "crl_file", "ecdhe", "ciphers" configuration and ssl options. "crt-base" is also supported to fetch certificates.
2016-12-29 12:26:15 -05:00
struct ssl_bind_conf *conf = arg;
MEDIUM: ssl: add support for the "npn" bind keyword The ssl_npn match could not work by itself because clients do not use the NPN extension unless the server advertises the protocols it supports. Thanks to Simone Bordet for the explanations on how to get it right.
2012-10-18 12:57:14 -04:00
*data = (const unsigned char *)conf->npn_str;
*len = conf->npn_len;
return SSL_TLSEXT_ERR_OK;
}
#endif
MEDIUM: ssl: Use ALPN support as it will be available in OpenSSL 1.0.2 The current ALPN support is based on custom OpenSSL patches. These are however not the same as what has landed on OpenSSL: http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=6f017a8f9db3a79f3a3406cf8d493ccd346db691 This patch change the code so it supports ALPN as it will be part of OpenSSL.
2014-02-13 06:29:42 -05:00
#ifdef TLSEXT_TYPE_application_layer_protocol_negotiation
MINOR: ssl: add support for the "alpn" bind keyword The ALPN extension is meant to replace the now deprecated NPN extension. This patch implements support for it. It requires a version of openssl with support for this extension. Patches are available here right now : http://html5labs.interopbridges.com/media/167447/alpn_patches.zip
2013-04-01 20:30:41 -04:00
/* This callback is used so that the server advertises the list of
CLEANUP: assorted typo fixes in the code and comments These are mostly comments in the code. A few error messages were fixed and are of low enough importance not to deserve a backport. Some regtests were also fixed.
2020-03-10 03:06:11 -04:00
* negotiable protocols for ALPN.
MINOR: ssl: add support for the "alpn" bind keyword The ALPN extension is meant to replace the now deprecated NPN extension. This patch implements support for it. It requires a version of openssl with support for this extension. Patches are available here right now : http://html5labs.interopbridges.com/media/167447/alpn_patches.zip
2013-04-01 20:30:41 -04:00
*/
MEDIUM: ssl: Use ALPN support as it will be available in OpenSSL 1.0.2 The current ALPN support is based on custom OpenSSL patches. These are however not the same as what has landed on OpenSSL: http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=6f017a8f9db3a79f3a3406cf8d493ccd346db691 This patch change the code so it supports ALPN as it will be part of OpenSSL.
2014-02-13 06:29:42 -05:00
static int ssl_sock_advertise_alpn_protos(SSL *s, const unsigned char **out,
unsigned char *outlen,
const unsigned char *server,
unsigned int server_len, void *arg)
MINOR: ssl: add support for the "alpn" bind keyword The ALPN extension is meant to replace the now deprecated NPN extension. This patch implements support for it. It requires a version of openssl with support for this extension. Patches are available here right now : http://html5labs.interopbridges.com/media/167447/alpn_patches.zip
2013-04-01 20:30:41 -04:00
{
MAJOR: ssl: bind configuration per certificat crt-list is extend to support ssl configuration. You can now have such line in crt-list <file>: mycert.pem [npn h2,http/1.1] Support include "npn", "alpn", "verify", "ca_file", "crl_file", "ecdhe", "ciphers" configuration and ssl options. "crt-base" is also supported to fetch certificates.
2016-12-29 12:26:15 -05:00
struct ssl_bind_conf *conf = arg;
MINOR: ssl_sock: Set the QUIC application from ssl_sock_advertise_alpn_protos. Make this function call quic_set_app_ops() if the protocol could be negotiated by the TLS stack.
2021-12-14 13:40:04 -05:00
#ifdef USE_QUIC
MEDIUM: quic/ssl: add new ex data for quic_conn Allow to register quic_conn as ex-data in SSL callbacks. A new index is used to identify it as ssl_qc_app_data_index. Replace connection by quic_conn as SSL ex-data when initializing the QUIC SSL session. When using SSL callbacks in QUIC context, the connection is now NULL. Used quic_conn instead to retrieve the required parameters. Also clean up The same changes are conducted inside the QUIC SSL methods of xprt-quic : connection instance usage is replaced by quic_conn.
2022-01-19 04:03:30 -05:00
struct quic_conn *qc = SSL_get_ex_data(s, ssl_qc_app_data_index);
MINOR: ssl_sock: Set the QUIC application from ssl_sock_advertise_alpn_protos. Make this function call quic_set_app_ops() if the protocol could be negotiated by the TLS stack.
2021-12-14 13:40:04 -05:00
#endif
MINOR: ssl: add support for the "alpn" bind keyword The ALPN extension is meant to replace the now deprecated NPN extension. This patch implements support for it. It requires a version of openssl with support for this extension. Patches are available here right now : http://html5labs.interopbridges.com/media/167447/alpn_patches.zip
2013-04-01 20:30:41 -04:00
MEDIUM: ssl: Use ALPN support as it will be available in OpenSSL 1.0.2 The current ALPN support is based on custom OpenSSL patches. These are however not the same as what has landed on OpenSSL: http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=6f017a8f9db3a79f3a3406cf8d493ccd346db691 This patch change the code so it supports ALPN as it will be part of OpenSSL.
2014-02-13 06:29:42 -05:00
if (SSL_select_next_proto((unsigned char**) out, outlen, (const unsigned char *)conf->alpn_str,
conf->alpn_len, server, server_len) != OPENSSL_NPN_NEGOTIATED) {
MINOR: quic: Set "no_application_protocol" alert We set this TLS error when no application protocol could be negotiated via the TLS callback concerned. It is converted as a QUIC CRYPTO_ERROR error (0x178).
2021-11-19 11:02:20 -05:00
#ifdef USE_QUIC
MEDIUM: quic/ssl: add new ex data for quic_conn Allow to register quic_conn as ex-data in SSL callbacks. A new index is used to identify it as ssl_qc_app_data_index. Replace connection by quic_conn as SSL ex-data when initializing the QUIC SSL session. When using SSL callbacks in QUIC context, the connection is now NULL. Used quic_conn instead to retrieve the required parameters. Also clean up The same changes are conducted inside the QUIC SSL methods of xprt-quic : connection instance usage is replaced by quic_conn.
2022-01-19 04:03:30 -05:00
if (qc)
quic_set_tls_alert(qc, SSL_AD_NO_APPLICATION_PROTOCOL);
MINOR: quic: Set "no_application_protocol" alert We set this TLS error when no application protocol could be negotiated via the TLS callback concerned. It is converted as a QUIC CRYPTO_ERROR error (0x178).
2021-11-19 11:02:20 -05:00
#endif
MEDIUM: ssl: Use ALPN support as it will be available in OpenSSL 1.0.2 The current ALPN support is based on custom OpenSSL patches. These are however not the same as what has landed on OpenSSL: http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=6f017a8f9db3a79f3a3406cf8d493ccd346db691 This patch change the code so it supports ALPN as it will be part of OpenSSL.
2014-02-13 06:29:42 -05:00
return SSL_TLSEXT_ERR_NOACK;
}
MINOR: ssl_sock: Set the QUIC application from ssl_sock_advertise_alpn_protos. Make this function call quic_set_app_ops() if the protocol could be negotiated by the TLS stack.
2021-12-14 13:40:04 -05:00
#ifdef USE_QUIC
MEDIUM: quic/ssl: add new ex data for quic_conn Allow to register quic_conn as ex-data in SSL callbacks. A new index is used to identify it as ssl_qc_app_data_index. Replace connection by quic_conn as SSL ex-data when initializing the QUIC SSL session. When using SSL callbacks in QUIC context, the connection is now NULL. Used quic_conn instead to retrieve the required parameters. Also clean up The same changes are conducted inside the QUIC SSL methods of xprt-quic : connection instance usage is replaced by quic_conn.
2022-01-19 04:03:30 -05:00
if (qc && !quic_set_app_ops(qc, *out, *outlen)) {
quic_set_tls_alert(qc, SSL_AD_NO_APPLICATION_PROTOCOL);
MINOR: ssl_sock: Set the QUIC application from ssl_sock_advertise_alpn_protos. Make this function call quic_set_app_ops() if the protocol could be negotiated by the TLS stack.
2021-12-14 13:40:04 -05:00
return SSL_TLSEXT_ERR_NOACK;
}
#endif
MINOR: ssl: add support for the "alpn" bind keyword The ALPN extension is meant to replace the now deprecated NPN extension. This patch implements support for it. It requires a version of openssl with support for this extension. Patches are available here right now : http://html5labs.interopbridges.com/media/167447/alpn_patches.zip
2013-04-01 20:30:41 -04:00
return SSL_TLSEXT_ERR_OK;
}
#endif
CLEANUP: ssl-sock: use HA_OPENSSL_VERSION_NUMBER instead of OPENSSL_VERSION_NUMBER Most tests on OPENSSL_VERSION_NUMBER have become complex and break all the time because this number is fake for some derivatives like LibreSSL. This patch creates a new macro, HA_OPENSSL_VERSION_NUMBER, which will carry the real openssl version defining the compatibility level, and this version will be adjusted depending on the variants.
2019-05-09 07:26:41 -04:00
#if (HA_OPENSSL_VERSION_NUMBER < 0x1010000fL)
MEDIUM: ssl: ctx_set_version/ssl_set_version func for methodVersions table This patch cleanup the usage of set_version func with a more suitable name: ctx_set_version. It introduce ssl_set_version func (unused for the moment).
2017-05-18 06:33:19 -04:00
static void ctx_set_SSLv3_func(SSL_CTX *ctx, set_context_func c)
REORG: ssl: move defines and methodVersions table upper It will used in ssl_sock_switchctx_cbk.
2017-05-18 05:56:58 -04:00
{
BUG/MINOR: ssl: remove haproxy SSLv3 support when ssl lib have no SSLv3 The commit 5db33cbd "MEDIUM: ssl: ssl_methods implementation is reworked and factored for min/max tlsxx" drop the case when ssl lib have removed SSLv3. The commit 1e59fcc5 "BUG/MINOR: ssl: Be sure that SSLv3 connection methods exist for openssl < 1.1.0" fix build but it's false because haproxy think that ssl lib support SSLv3. SSL_OP_NO_* are flags to set in ssl_options and is the way haproxy do the link between ssl capabilities and haproxy configuration. (The mapping table is done via methodVersions). SSL_OP_NO_* is set to 0 when ssl lib doesn't support a new TLS version. Older version (like SSLv3) can be removed at build or unsupported (like libressl). In all case OPENSSL_NO_SSL3 is define. To keep the same logic, this patch alter SSL_OP_NO_SSLv3 to 0 when SSLv3 is not supported by ssl lib (when OPENSSL_NO_SSL3 is define).
2017-07-12 06:53:02 -04:00
#if SSL_OP_NO_SSLv3
MEDIUM: ssl: ctx_set_version/ssl_set_version func for methodVersions table This patch cleanup the usage of set_version func with a more suitable name: ctx_set_version. It introduce ssl_set_version func (unused for the moment).
2017-05-18 06:33:19 -04:00
c == SET_SERVER ? SSL_CTX_set_ssl_version(ctx, SSLv3_server_method())
REORG: ssl: move defines and methodVersions table upper It will used in ssl_sock_switchctx_cbk.
2017-05-18 05:56:58 -04:00
: SSL_CTX_set_ssl_version(ctx, SSLv3_client_method());
#endif
}
MEDIUM: ssl: ctx_set_version/ssl_set_version func for methodVersions table This patch cleanup the usage of set_version func with a more suitable name: ctx_set_version. It introduce ssl_set_version func (unused for the moment).
2017-05-18 06:33:19 -04:00
static void ctx_set_TLSv10_func(SSL_CTX *ctx, set_context_func c) {
c == SET_SERVER ? SSL_CTX_set_ssl_version(ctx, TLSv1_server_method())
REORG: ssl: move defines and methodVersions table upper It will used in ssl_sock_switchctx_cbk.
2017-05-18 05:56:58 -04:00
: SSL_CTX_set_ssl_version(ctx, TLSv1_client_method());
}
MEDIUM: ssl: ctx_set_version/ssl_set_version func for methodVersions table This patch cleanup the usage of set_version func with a more suitable name: ctx_set_version. It introduce ssl_set_version func (unused for the moment).
2017-05-18 06:33:19 -04:00
static void ctx_set_TLSv11_func(SSL_CTX *ctx, set_context_func c) {
REORG: ssl: move defines and methodVersions table upper It will used in ssl_sock_switchctx_cbk.
2017-05-18 05:56:58 -04:00
#if SSL_OP_NO_TLSv1_1
MEDIUM: ssl: ctx_set_version/ssl_set_version func for methodVersions table This patch cleanup the usage of set_version func with a more suitable name: ctx_set_version. It introduce ssl_set_version func (unused for the moment).
2017-05-18 06:33:19 -04:00
c == SET_SERVER ? SSL_CTX_set_ssl_version(ctx, TLSv1_1_server_method())
REORG: ssl: move defines and methodVersions table upper It will used in ssl_sock_switchctx_cbk.
2017-05-18 05:56:58 -04:00
: SSL_CTX_set_ssl_version(ctx, TLSv1_1_client_method());
#endif
}
MEDIUM: ssl: ctx_set_version/ssl_set_version func for methodVersions table This patch cleanup the usage of set_version func with a more suitable name: ctx_set_version. It introduce ssl_set_version func (unused for the moment).
2017-05-18 06:33:19 -04:00
static void ctx_set_TLSv12_func(SSL_CTX *ctx, set_context_func c) {
REORG: ssl: move defines and methodVersions table upper It will used in ssl_sock_switchctx_cbk.
2017-05-18 05:56:58 -04:00
#if SSL_OP_NO_TLSv1_2
MEDIUM: ssl: ctx_set_version/ssl_set_version func for methodVersions table This patch cleanup the usage of set_version func with a more suitable name: ctx_set_version. It introduce ssl_set_version func (unused for the moment).
2017-05-18 06:33:19 -04:00
c == SET_SERVER ? SSL_CTX_set_ssl_version(ctx, TLSv1_2_server_method())
REORG: ssl: move defines and methodVersions table upper It will used in ssl_sock_switchctx_cbk.
2017-05-18 05:56:58 -04:00
: SSL_CTX_set_ssl_version(ctx, TLSv1_2_client_method());
#endif
}
DOC: ssl: Use consistent naming for TLS protocols In most cases, "TLSv1.x" naming is used across and documentation, lazy people tend to grep too much and may not find what they are looking for. Fixing people is hard.
2018-08-13 19:56:13 -04:00
/* TLSv1.2 is the last supported version in this context. */
MEDIUM: ssl: ctx_set_version/ssl_set_version func for methodVersions table This patch cleanup the usage of set_version func with a more suitable name: ctx_set_version. It introduce ssl_set_version func (unused for the moment).
2017-05-18 06:33:19 -04:00
static void ctx_set_TLSv13_func(SSL_CTX *ctx, set_context_func c) {}
/* Unusable in this context. */
static void ssl_set_SSLv3_func(SSL *ssl, set_context_func c) {}
static void ssl_set_TLSv10_func(SSL *ssl, set_context_func c) {}
static void ssl_set_TLSv11_func(SSL *ssl, set_context_func c) {}
static void ssl_set_TLSv12_func(SSL *ssl, set_context_func c) {}
static void ssl_set_TLSv13_func(SSL *ssl, set_context_func c) {}
REORG: ssl: move defines and methodVersions table upper It will used in ssl_sock_switchctx_cbk.
2017-05-18 05:56:58 -04:00
#else /* openssl >= 1.1.0 */
MEDIUM: ssl: ctx_set_version/ssl_set_version func for methodVersions table This patch cleanup the usage of set_version func with a more suitable name: ctx_set_version. It introduce ssl_set_version func (unused for the moment).
2017-05-18 06:33:19 -04:00
static void ctx_set_SSLv3_func(SSL_CTX *ctx, set_context_func c) {
c == SET_MAX ? SSL_CTX_set_max_proto_version(ctx, SSL3_VERSION)
REORG: ssl: move defines and methodVersions table upper It will used in ssl_sock_switchctx_cbk.
2017-05-18 05:56:58 -04:00
: SSL_CTX_set_min_proto_version(ctx, SSL3_VERSION);
}
MEDIUM: ssl: ctx_set_version/ssl_set_version func for methodVersions table This patch cleanup the usage of set_version func with a more suitable name: ctx_set_version. It introduce ssl_set_version func (unused for the moment).
2017-05-18 06:33:19 -04:00
static void ssl_set_SSLv3_func(SSL *ssl, set_context_func c) {
c == SET_MAX ? SSL_set_max_proto_version(ssl, SSL3_VERSION)
: SSL_set_min_proto_version(ssl, SSL3_VERSION);
}
static void ctx_set_TLSv10_func(SSL_CTX *ctx, set_context_func c) {
c == SET_MAX ? SSL_CTX_set_max_proto_version(ctx, TLS1_VERSION)
REORG: ssl: move defines and methodVersions table upper It will used in ssl_sock_switchctx_cbk.
2017-05-18 05:56:58 -04:00
: SSL_CTX_set_min_proto_version(ctx, TLS1_VERSION);
}
MEDIUM: ssl: ctx_set_version/ssl_set_version func for methodVersions table This patch cleanup the usage of set_version func with a more suitable name: ctx_set_version. It introduce ssl_set_version func (unused for the moment).
2017-05-18 06:33:19 -04:00
static void ssl_set_TLSv10_func(SSL *ssl, set_context_func c) {
c == SET_MAX ? SSL_set_max_proto_version(ssl, TLS1_VERSION)
: SSL_set_min_proto_version(ssl, TLS1_VERSION);
}
static void ctx_set_TLSv11_func(SSL_CTX *ctx, set_context_func c) {
c == SET_MAX ? SSL_CTX_set_max_proto_version(ctx, TLS1_1_VERSION)
REORG: ssl: move defines and methodVersions table upper It will used in ssl_sock_switchctx_cbk.
2017-05-18 05:56:58 -04:00
: SSL_CTX_set_min_proto_version(ctx, TLS1_1_VERSION);
}
MEDIUM: ssl: ctx_set_version/ssl_set_version func for methodVersions table This patch cleanup the usage of set_version func with a more suitable name: ctx_set_version. It introduce ssl_set_version func (unused for the moment).
2017-05-18 06:33:19 -04:00
static void ssl_set_TLSv11_func(SSL *ssl, set_context_func c) {
c == SET_MAX ? SSL_set_max_proto_version(ssl, TLS1_1_VERSION)
: SSL_set_min_proto_version(ssl, TLS1_1_VERSION);
}
static void ctx_set_TLSv12_func(SSL_CTX *ctx, set_context_func c) {
c == SET_MAX ? SSL_CTX_set_max_proto_version(ctx, TLS1_2_VERSION)
REORG: ssl: move defines and methodVersions table upper It will used in ssl_sock_switchctx_cbk.
2017-05-18 05:56:58 -04:00
: SSL_CTX_set_min_proto_version(ctx, TLS1_2_VERSION);
}
MEDIUM: ssl: ctx_set_version/ssl_set_version func for methodVersions table This patch cleanup the usage of set_version func with a more suitable name: ctx_set_version. It introduce ssl_set_version func (unused for the moment).
2017-05-18 06:33:19 -04:00
static void ssl_set_TLSv12_func(SSL *ssl, set_context_func c) {
c == SET_MAX ? SSL_set_max_proto_version(ssl, TLS1_2_VERSION)
: SSL_set_min_proto_version(ssl, TLS1_2_VERSION);
}
static void ctx_set_TLSv13_func(SSL_CTX *ctx, set_context_func c) {
BUILD: fix compilation for OpenSSL-3.0.0-alpha17 Some changes in the OpenSSL syntax API broke this syntax: #if SSL_OP_NO_TLSv1_3 OpenSSL made this change which broke our usage in commit f04bb0bce490de847ed0482b8ec9eabedd173852: -# define SSL_OP_NO_TLSv1_3 (uint64_t)0x20000000 +#define SSL_OP_BIT(n) ((uint64_t)1 << (uint64_t)n) +# define SSL_OP_NO_TLSv1_3 SSL_OP_BIT(29) Which can't be evaluated by the preprocessor anymore. This patch replace the test by an openssl version test. This fix part of #1276 issue.
2021-06-02 10:09:11 -04:00
#if (HA_OPENSSL_VERSION_NUMBER >= 0x10101000L)
MEDIUM: ssl: ctx_set_version/ssl_set_version func for methodVersions table This patch cleanup the usage of set_version func with a more suitable name: ctx_set_version. It introduce ssl_set_version func (unused for the moment).
2017-05-18 06:33:19 -04:00
c == SET_MAX ? SSL_CTX_set_max_proto_version(ctx, TLS1_3_VERSION)
REORG: ssl: move defines and methodVersions table upper It will used in ssl_sock_switchctx_cbk.
2017-05-18 05:56:58 -04:00
: SSL_CTX_set_min_proto_version(ctx, TLS1_3_VERSION);
#endif
}
MEDIUM: ssl: ctx_set_version/ssl_set_version func for methodVersions table This patch cleanup the usage of set_version func with a more suitable name: ctx_set_version. It introduce ssl_set_version func (unused for the moment).
2017-05-18 06:33:19 -04:00
static void ssl_set_TLSv13_func(SSL *ssl, set_context_func c) {
BUILD: fix compilation for OpenSSL-3.0.0-alpha17 Some changes in the OpenSSL syntax API broke this syntax: #if SSL_OP_NO_TLSv1_3 OpenSSL made this change which broke our usage in commit f04bb0bce490de847ed0482b8ec9eabedd173852: -# define SSL_OP_NO_TLSv1_3 (uint64_t)0x20000000 +#define SSL_OP_BIT(n) ((uint64_t)1 << (uint64_t)n) +# define SSL_OP_NO_TLSv1_3 SSL_OP_BIT(29) Which can't be evaluated by the preprocessor anymore. This patch replace the test by an openssl version test. This fix part of #1276 issue.
2021-06-02 10:09:11 -04:00
#if (HA_OPENSSL_VERSION_NUMBER >= 0x10101000L)
MEDIUM: ssl: ctx_set_version/ssl_set_version func for methodVersions table This patch cleanup the usage of set_version func with a more suitable name: ctx_set_version. It introduce ssl_set_version func (unused for the moment).
2017-05-18 06:33:19 -04:00
c == SET_MAX ? SSL_set_max_proto_version(ssl, TLS1_3_VERSION)
: SSL_set_min_proto_version(ssl, TLS1_3_VERSION);
REORG: ssl: move defines and methodVersions table upper It will used in ssl_sock_switchctx_cbk.
2017-05-18 05:56:58 -04:00
#endif
}
MEDIUM: ssl: ctx_set_version/ssl_set_version func for methodVersions table This patch cleanup the usage of set_version func with a more suitable name: ctx_set_version. It introduce ssl_set_version func (unused for the moment).
2017-05-18 06:33:19 -04:00
#endif
static void ctx_set_None_func(SSL_CTX *ctx, set_context_func c) { }
static void ssl_set_None_func(SSL *ssl, set_context_func c) { }
REORG: ssl: move defines and methodVersions table upper It will used in ssl_sock_switchctx_cbk.
2017-05-18 05:56:58 -04:00
REORG: ssl: move macros and structure definitions to ssl_sock.h The ssl_sock.c file contains a lot of macros and structure definitions that should be in a .h. Move them to the more appropriate types/ssl_sock.h file.
2020-05-07 09:20:43 -04:00
struct methodVersions methodVersions[] = {
MEDIUM: ssl: ctx_set_version/ssl_set_version func for methodVersions table This patch cleanup the usage of set_version func with a more suitable name: ctx_set_version. It introduce ssl_set_version func (unused for the moment).
2017-05-18 06:33:19 -04:00
{0, 0, ctx_set_None_func, ssl_set_None_func, "NONE"}, /* CONF_TLSV_NONE */
{SSL_OP_NO_SSLv3, MC_SSL_O_NO_SSLV3, ctx_set_SSLv3_func, ssl_set_SSLv3_func, "SSLv3"}, /* CONF_SSLV3 */
{SSL_OP_NO_TLSv1, MC_SSL_O_NO_TLSV10, ctx_set_TLSv10_func, ssl_set_TLSv10_func, "TLSv1.0"}, /* CONF_TLSV10 */
{SSL_OP_NO_TLSv1_1, MC_SSL_O_NO_TLSV11, ctx_set_TLSv11_func, ssl_set_TLSv11_func, "TLSv1.1"}, /* CONF_TLSV11 */
{SSL_OP_NO_TLSv1_2, MC_SSL_O_NO_TLSV12, ctx_set_TLSv12_func, ssl_set_TLSv12_func, "TLSv1.2"}, /* CONF_TLSV12 */
{SSL_OP_NO_TLSv1_3, MC_SSL_O_NO_TLSV13, ctx_set_TLSv13_func, ssl_set_TLSv13_func, "TLSv1.3"}, /* CONF_TLSV13 */
REORG: ssl: move defines and methodVersions table upper It will used in ssl_sock_switchctx_cbk.
2017-05-18 05:56:58 -04:00
};
BUG/MEDIUM: ssl: fix verify/ca-file per certificate SSL verify and client_CA inherits from the initial ctx (default_ctx). When a certificate is found, the SSL connection environment must be replaced by the certificate configuration (via SSL_set_verify and SSL_set_client_CA_list).
2017-03-01 12:54:56 -05:00
static void ssl_sock_switchctx_set(SSL *ssl, SSL_CTX *ctx)
{
SSL_set_verify(ssl, SSL_CTX_get_verify_mode(ctx), ssl_sock_bind_verifycbk);
SSL_set_client_CA_list(ssl, SSL_dup_CA_list(SSL_CTX_get_client_CA_list(ctx)));
SSL_set_SSL_CTX(ssl, ctx);
}
MINOR: ssl: move certificate selection in a dedicate function The certificate selection used in the WolfSSL cert_cb and in the OpenSSL clienthello callback is the same, the function was duplicate to achieve the same. This patch move the selection code to a common function called ssl_sock_chose_sni_ctx(). The servername string is still lowered in the callback, however the search for the first dot in the string (wildp) is done in ssl_sock_chose_sni_ctx() The function uses the same certificate selection algorithm as before, it needs to know if you need rsa or ecdsa, the bind_conf to achieve the lookup, and the servername string. This patch moves the code for WolSSL only.
2023-11-23 10:35:52 -05:00
/*
* Return the right sni_ctx for a <bind_conf> and a chosen <servername> (must be in lowercase)
* RSA <have_rsa_sig> and ECDSA <have_ecdsa_sig> capabilities of the client can also be used.
*
* This function does a lookup in the bind_conf sni tree so the caller should lock its tree.
*/
REORG: ssl: move 'generate-certificates' code to ssl_gencert.c A lot of code specific to the 'generate-certificates' option was left in ssl_sock.c. Move the code to 'ssl_gencert.c' and 'ssl_gencert.h'
2024-01-12 09:23:49 -05:00
struct sni_ctx *ssl_sock_chose_sni_ctx(struct bind_conf *s, const char *servername,
MINOR: ssl: move certificate selection in a dedicate function The certificate selection used in the WolfSSL cert_cb and in the OpenSSL clienthello callback is the same, the function was duplicate to achieve the same. This patch move the selection code to a common function called ssl_sock_chose_sni_ctx(). The servername string is still lowered in the callback, however the search for the first dot in the string (wildp) is done in ssl_sock_chose_sni_ctx() The function uses the same certificate selection algorithm as before, it needs to know if you need rsa or ecdsa, the bind_conf to achieve the lookup, and the servername string. This patch moves the code for WolSSL only.
2023-11-23 10:35:52 -05:00
int have_rsa_sig, int have_ecdsa_sig)
{
struct ebmb_node *node, *n, *node_ecdsa = NULL, *node_rsa = NULL, *node_anonymous = NULL;
const char *wildp = NULL;
int i;
/* look for the first dot for wildcard search */
for (i = 0; servername[i] != '\0'; i++) {
if (servername[i] == '.') {
wildp = &servername[i];
break;
}
}
MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection This patch changes the default certificate mechanism. Since the beginning of SSL in HAProxy, the default certificate was the first certificate of a bind line. This allowed to fallback on this certificate when no servername extension was sent by the server, or when no SAN nor CN was available in the certificate. When using a multi-certificate bundle (ecdsa+rsa), it was possible to have both certificates as the fallback one, leting openssl chose the right one. This was possible because a multi-certificate bundle was generating a unique SSL_CTX for both certificates. When the haproxy and openssl architecture evolved, we decided to use multiple SSL_CTX for a multi-cert bundle, in order to simplify the code and allow updates over the CLI. However only one default_ctx was allowed, so we lost the ability to chose between ECDSA and RSA for the default certificate. This patch allows to use a '*' filter for a certificate, which allow to lookup between multiple '*' filter, and have one in RSA and another one in ECDSA. It replaces the default_ctx mechanism in the ClientHello callback and use the standard algorithm to look for a default cert and chose between ECDSA and RSA. /!\ This patch breaks the automatic setting of the default certificate, which will be introduce in the next patch. So the first certificate of a bind line won't be used as a defaullt anymore. To use this feature, one could use crt-list with '*' filters: $ cat foo.crtlist foobar.pem.rsa * foobar.pem.ecdsa * In order to test the feature, it's easy to send a request without the servername extension and use ECDSA or RSA compatible ciphers: $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-RSA-AES256-GCM-SHA384 $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-ECDSA-AES256-GCM-SHA384
2024-01-10 08:05:59 -05:00
/* if the servername is empty look for the default in the wildcard list */
if (!*servername)
wildp = servername;
MINOR: ssl: move certificate selection in a dedicate function The certificate selection used in the WolfSSL cert_cb and in the OpenSSL clienthello callback is the same, the function was duplicate to achieve the same. This patch move the selection code to a common function called ssl_sock_chose_sni_ctx(). The servername string is still lowered in the callback, however the search for the first dot in the string (wildp) is done in ssl_sock_chose_sni_ctx() The function uses the same certificate selection algorithm as before, it needs to know if you need rsa or ecdsa, the bind_conf to achieve the lookup, and the servername string. This patch moves the code for WolSSL only.
2023-11-23 10:35:52 -05:00
/* Look for an ECDSA, RSA and DSA certificate, first in the single
* name and if not found in the wildcard */
for (i = 0; i < 2; i++) {
if (i == 0) /* lookup in full qualified names */
node = ebst_lookup(&s->sni_ctx, trash.area);
else if (i == 1 && wildp) /* lookup in wildcards names */
node = ebst_lookup(&s->sni_w_ctx, wildp);
else
break;
for (n = node; n; n = ebmb_next_dup(n)) {
/* lookup a not neg filter */
if (!container_of(n, struct sni_ctx, name)->neg) {
struct sni_ctx *sni, *sni_tmp;
int skip = 0;
if (i == 1 && wildp) { /* wildcard */
/* If this is a wildcard, look for an exclusion on the same crt-list line */
sni = container_of(n, struct sni_ctx, name);
list_for_each_entry(sni_tmp, &sni->ckch_inst->sni_ctx, by_ckch_inst) {
if (sni_tmp->neg && (strcmp((const char *)sni_tmp->name.key, trash.area) == 0)) {
skip = 1;
break;
}
}
if (skip)
continue;
}
switch(container_of(n, struct sni_ctx, name)->kinfo.sig) {
case TLSEXT_signature_ecdsa:
if (!node_ecdsa)
node_ecdsa = n;
break;
case TLSEXT_signature_rsa:
if (!node_rsa)
node_rsa = n;
break;
default: /* TLSEXT_signature_anonymous|dsa */
if (!node_anonymous)
node_anonymous = n;
break;
}
}
}
}
/* Once the certificates are found, select them depending on what is
* supported in the client and by key_signature priority order: EDSA >
* RSA > DSA */
if (have_ecdsa_sig && node_ecdsa)
node = node_ecdsa;
else if (have_rsa_sig && node_rsa)
node = node_rsa;
else if (node_anonymous)
node = node_anonymous;
else if (node_ecdsa)
node = node_ecdsa; /* no ecdsa signature case (< TLSv1.2) */
else
node = node_rsa; /* no rsa signature case (far far away) */
if (node)
return container_of(node, struct sni_ctx, name);
return NULL;
}
BUILD: ssl: guard Client Hello callbacks with HAVE_SSL_CLIENT_HELLO_CB macro instead of openssl version let us introduce new macro HAVE_SSL_CLIENT_HELLO_CB and guard callback functions with it
2021-01-22 14:09:14 -05:00
#ifdef HAVE_SSL_CLIENT_HELLO_CB
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
MINOR: ssl: Export definitions required by QUIC. QUIC needs to initialize its BIO and SSL session the same way as for SSL over TCP connections. It needs also to use the same ClientHello callback. This patch only exports functions and variables shared between QUIC and SSL/TCP connections.
2020-11-23 05:19:04 -05:00
int ssl_sock_switchctx_err_cbk(SSL *ssl, int *al, void *priv)
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
{
MINOR: ssl: generated certificate is missing in switchctx early callback Openssl 1.1.1 supports switchctx early callback and generated certificate. Generated certificate calls must be available in switchctx early callback.
2017-08-14 05:01:25 -04:00
struct bind_conf *s = priv;
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
(void)al; /* shut gcc stupid warning */
CLEANUP: listener: replace bind_conf->generate_cers with BC_O_GENERATE_CERTS The new flag will now replace this boolean variable.
2022-05-20 10:03:18 -04:00
if (SSL_get_servername(ssl, TLSEXT_NAMETYPE_host_name) || (s->options & BC_O_GENERATE_CERTS))
MINOR: ssl: generated certificate is missing in switchctx early callback Openssl 1.1.1 supports switchctx early callback and generated certificate. Generated certificate calls must be available in switchctx early callback.
2017-08-14 05:01:25 -04:00
return SSL_TLSEXT_ERR_OK;
return SSL_TLSEXT_ERR_NOACK;
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
}
MINOR: ssl: support Openssl 1.1.1 early callback for switchctx Use Openssl-1.1.1 SSL_CTX_set_client_hello_cb to mimic BoringSSL early callback. Native multi certificate and SSL/TLS method per certificate is now supported by Openssl >= 1.1.1.
2017-08-16 05:33:17 -04:00
#ifdef OPENSSL_IS_BORINGSSL
MINOR: ssl: Export definitions required by QUIC. QUIC needs to initialize its BIO and SSL session the same way as for SSL over TCP connections. It needs also to use the same ClientHello callback. This patch only exports functions and variables shared between QUIC and SSL/TCP connections.
2020-11-23 05:19:04 -05:00
int ssl_sock_switchctx_cbk(const struct ssl_early_callback_ctx *ctx)
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
{
MEDIUM: ssl: convert CBS (BoringSSL api) usage to neutral code switchctx early callback is only supported for BoringSSL. To prepare the support of openssl 1.1.1 early callback, convert CBS api to neutral code to work with any ssl libs.
2017-08-16 05:28:44 -04:00
SSL *ssl = ctx->ssl;
MINOR: ssl: support Openssl 1.1.1 early callback for switchctx Use Openssl-1.1.1 SSL_CTX_set_client_hello_cb to mimic BoringSSL early callback. Native multi certificate and SSL/TLS method per certificate is now supported by Openssl >= 1.1.1.
2017-08-16 05:33:17 -04:00
#else
MINOR: ssl: Export definitions required by QUIC. QUIC needs to initialize its BIO and SSL session the same way as for SSL over TCP connections. It needs also to use the same ClientHello callback. This patch only exports functions and variables shared between QUIC and SSL/TCP connections.
2020-11-23 05:19:04 -05:00
int ssl_sock_switchctx_cbk(SSL *ssl, int *al, void *arg)
MINOR: ssl: support Openssl 1.1.1 early callback for switchctx Use Openssl-1.1.1 SSL_CTX_set_client_hello_cb to mimic BoringSSL early callback. Native multi certificate and SSL/TLS method per certificate is now supported by Openssl >= 1.1.1.
2017-08-16 05:33:17 -04:00
{
#endif
MEDIUM: quic/ssl: add new ex data for quic_conn Allow to register quic_conn as ex-data in SSL callbacks. A new index is used to identify it as ssl_qc_app_data_index. Replace connection by quic_conn as SSL ex-data when initializing the QUIC SSL session. When using SSL callbacks in QUIC context, the connection is now NULL. Used quic_conn instead to retrieve the required parameters. Also clean up The same changes are conducted inside the QUIC SSL methods of xprt-quic : connection instance usage is replaced by quic_conn.
2022-01-19 04:03:30 -05:00
struct connection *conn = SSL_get_ex_data(ssl, ssl_app_data_index);
#ifdef USE_QUIC
struct quic_conn *qc = SSL_get_ex_data(ssl, ssl_qc_app_data_index);
#endif /* USE_QUIC */
struct bind_conf *s = NULL;
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
const uint8_t *extension_data;
size_t extension_len;
BUG/MEDIUM: ECC cert should work with TLS < v1.2 and openssl >= 1.1.1 With openssl >= 1.1.1 and boringssl multi-cert is natively supported. ECDSA/RSA selection is done and work correctly with TLS >= v1.2. TLS < v1.2 have no TLSEXT_TYPE_signature_algorithms extension: ECC certificate can't be selected, and handshake fail if no RSA cert is present. Safe ECC certificate selection without client announcement can be very tricky (browser compatibilty). The safer approach is to select ECDSA certificate if no other certificate matches, like it is with openssl < 1.1.1: certificate selection is only done via the SNI. Thanks to Lukas Tribus for reporting this and analysing the problem. This patch should be backported to 1.8
2018-09-03 10:29:16 -04:00
int has_rsa_sig = 0, has_ecdsa_sig = 0;
MEDIUM: ssl: use ssl_sock_chose_sni_ctx() in the clienthello callback This patch removes the code which selects the SSL certificate in the OpenSSL Client Hello callback, to use the ssl_sock_chose_sni_ctx() function which does the same. The bigger part of the function which remains is the extraction of the servername, ciphers and sigalgs, because it's done manually by parsing the TLS extensions. This is not supposed to change anything functionally.
2023-11-23 11:54:47 -05:00
struct sni_ctx *sni_ctx;
MINOR: ssl: replace 'trash.area' by 'servername' in ssl_sock_switchctx_cbk() Replace 'trash.area' by 'servername' for more readibility.
2023-11-24 13:20:28 -05:00
const char *servername;
MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection This patch changes the default certificate mechanism. Since the beginning of SSL in HAProxy, the default certificate was the first certificate of a bind line. This allowed to fallback on this certificate when no servername extension was sent by the server, or when no SAN nor CN was available in the certificate. When using a multi-certificate bundle (ecdsa+rsa), it was possible to have both certificates as the fallback one, leting openssl chose the right one. This was possible because a multi-certificate bundle was generating a unique SSL_CTX for both certificates. When the haproxy and openssl architecture evolved, we decided to use multiple SSL_CTX for a multi-cert bundle, in order to simplify the code and allow updates over the CLI. However only one default_ctx was allowed, so we lost the ability to chose between ECDSA and RSA for the default certificate. This patch allows to use a '*' filter for a certificate, which allow to lookup between multiple '*' filter, and have one in RSA and another one in ECDSA. It replaces the default_ctx mechanism in the ClientHello callback and use the standard algorithm to look for a default cert and chose between ECDSA and RSA. /!\ This patch breaks the automatic setting of the default certificate, which will be introduce in the next patch. So the first certificate of a bind line won't be used as a defaullt anymore. To use this feature, one could use crt-list with '*' filters: $ cat foo.crtlist foobar.pem.rsa * foobar.pem.ecdsa * In order to test the feature, it's easy to send a request without the servername extension and use ECDSA or RSA compatible ciphers: $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-RSA-AES256-GCM-SHA384 $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-ECDSA-AES256-GCM-SHA384
2024-01-10 08:05:59 -05:00
size_t servername_len = 0;
int default_lookup = 0; /* did we lookup for a default yet? */
MEDIUM: ssl: Handle early data with OpenSSL 1.1.1 When compiled with Openssl >= 1.1.1, before attempting to do the handshake, try to read any early data. If any early data is present, then we'll create the session, read the data, and handle the request before we're doing the handshake. For this, we add a new connection flag, CO_FL_EARLY_SSL_HS, which is not part of the CO_FL_HANDSHAKE set, allowing to proceed with a session even before an SSL handshake is completed. As early data do have security implication, we let the origin server know the request comes from early data by adding the "Early-Data" header, as specified in this draft from the HTTP working group : https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-replay
2017-09-22 12:26:28 -04:00
int allow_early = 0;
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
int i;
MEDIUM: quic/ssl: add new ex data for quic_conn Allow to register quic_conn as ex-data in SSL callbacks. A new index is used to identify it as ssl_qc_app_data_index. Replace connection by quic_conn as SSL ex-data when initializing the QUIC SSL session. When using SSL callbacks in QUIC context, the connection is now NULL. Used quic_conn instead to retrieve the required parameters. Also clean up The same changes are conducted inside the QUIC SSL methods of xprt-quic : connection instance usage is replaced by quic_conn.
2022-01-19 04:03:30 -05:00
if (conn)
s = __objt_listener(conn->target)->bind_conf;
#ifdef USE_QUIC
else if (qc)
s = qc->li->bind_conf;
#endif /* USE_QUIC */
MINOR: ssl: fix build in release mode Fix potential null pointer dereference. In fact, this case is not possible, only a mistake in SSL ex-data initialization may cause it : either connection is set or quic_conn, which allows to retrieve the bind_conf. A BUG_ON was already present but this does not cover release build.
2022-01-24 05:04:05 -05:00
if (!s) {
/* must never happen */
ABORT_NOW();
return 0;
}
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
MINOR: ssl: QUIC transport parameters parsing. This patch modifies the TLS ClientHello message callback so that to parse the QUIC client transport parameters.
2020-11-23 09:37:11 -05:00
#ifdef USE_QUIC
MEDIUM: quic/ssl: add new ex data for quic_conn Allow to register quic_conn as ex-data in SSL callbacks. A new index is used to identify it as ssl_qc_app_data_index. Replace connection by quic_conn as SSL ex-data when initializing the QUIC SSL session. When using SSL callbacks in QUIC context, the connection is now NULL. Used quic_conn instead to retrieve the required parameters. Also clean up The same changes are conducted inside the QUIC SSL methods of xprt-quic : connection instance usage is replaced by quic_conn.
2022-01-19 04:03:30 -05:00
if (qc) {
MINOR: ssl: QUIC transport parameters parsing. This patch modifies the TLS ClientHello message callback so that to parse the QUIC client transport parameters.
2020-11-23 09:37:11 -05:00
/* Look for the QUIC transport parameters. */
#ifdef OPENSSL_IS_BORINGSSL
MEDIUM: quic/ssl: add new ex data for quic_conn Allow to register quic_conn as ex-data in SSL callbacks. A new index is used to identify it as ssl_qc_app_data_index. Replace connection by quic_conn as SSL ex-data when initializing the QUIC SSL session. When using SSL callbacks in QUIC context, the connection is now NULL. Used quic_conn instead to retrieve the required parameters. Also clean up The same changes are conducted inside the QUIC SSL methods of xprt-quic : connection instance usage is replaced by quic_conn.
2022-01-19 04:03:30 -05:00
if (!SSL_early_callback_ctx_extension_get(ctx, qc->tps_tls_ext,
MINOR: ssl: QUIC transport parameters parsing. This patch modifies the TLS ClientHello message callback so that to parse the QUIC client transport parameters.
2020-11-23 09:37:11 -05:00
&extension_data, &extension_len))
#else
MEDIUM: quic/ssl: add new ex data for quic_conn Allow to register quic_conn as ex-data in SSL callbacks. A new index is used to identify it as ssl_qc_app_data_index. Replace connection by quic_conn as SSL ex-data when initializing the QUIC SSL session. When using SSL callbacks in QUIC context, the connection is now NULL. Used quic_conn instead to retrieve the required parameters. Also clean up The same changes are conducted inside the QUIC SSL methods of xprt-quic : connection instance usage is replaced by quic_conn.
2022-01-19 04:03:30 -05:00
if (!SSL_client_hello_get0_ext(ssl, qc->tps_tls_ext,
MINOR: ssl: QUIC transport parameters parsing. This patch modifies the TLS ClientHello message callback so that to parse the QUIC client transport parameters.
2020-11-23 09:37:11 -05:00
&extension_data, &extension_len))
#endif
MINOR: quic: Immediately close if no transport parameters extension found If the ClientHello callback does not manage to find a correct QUIC transport parameters extension, we immediately close the connection with missing_extension(109) as TLS alert which is turned into 0x16d QUIC connection error.
2021-11-22 09:55:16 -05:00
{
/* This is not redundant. It we only return 0 without setting
* <*al>, this has as side effect to generate another TLS alert
* which would be set after calling quic_set_tls_alert().
*/
*al = SSL_AD_MISSING_EXTENSION;
MEDIUM: quic/ssl: add new ex data for quic_conn Allow to register quic_conn as ex-data in SSL callbacks. A new index is used to identify it as ssl_qc_app_data_index. Replace connection by quic_conn as SSL ex-data when initializing the QUIC SSL session. When using SSL callbacks in QUIC context, the connection is now NULL. Used quic_conn instead to retrieve the required parameters. Also clean up The same changes are conducted inside the QUIC SSL methods of xprt-quic : connection instance usage is replaced by quic_conn.
2022-01-19 04:03:30 -05:00
quic_set_tls_alert(qc, SSL_AD_MISSING_EXTENSION);
MINOR: quic: Immediately close if no transport parameters extension found If the ClientHello callback does not manage to find a correct QUIC transport parameters extension, we immediately close the connection with missing_extension(109) as TLS alert which is turned into 0x16d QUIC connection error.
2021-11-22 09:55:16 -05:00
return 0;
}
MINOR: ssl: QUIC transport parameters parsing. This patch modifies the TLS ClientHello message callback so that to parse the QUIC client transport parameters.
2020-11-23 09:37:11 -05:00
MEDIUM: quic/ssl: add new ex data for quic_conn Allow to register quic_conn as ex-data in SSL callbacks. A new index is used to identify it as ssl_qc_app_data_index. Replace connection by quic_conn as SSL ex-data when initializing the QUIC SSL session. When using SSL callbacks in QUIC context, the connection is now NULL. Used quic_conn instead to retrieve the required parameters. Also clean up The same changes are conducted inside the QUIC SSL methods of xprt-quic : connection instance usage is replaced by quic_conn.
2022-01-19 04:03:30 -05:00
if (!quic_transport_params_store(qc, 0, extension_data,
MEDIUM: quic: Remove qc_conn_finalize() from the ClientHello TLS callbacks This is a bad idea to make the TLS ClientHello callback call qc_conn_finalize(). If this latter fails, this would generate a TLS alert and make the connection send packet whereas it is not functional. But qc_conn_finalize() job was to install the transport parameters sent by the QUIC listener. This installation cannot be done at any time. This must be done after having possibly negotiated the QUIC version and before sending the first Handshake packets. It seems the better moment to do that in when the Handshake TX secrets are derived. This has been found inspecting the ngtcp2 code. Calling SSL_set_quic_transport_params() too late would make the ServerHello to be sent without the transport parameters. The code for the connection update which was done from qc_conn_finalize() has been moved to quic_transport_params_store(). So, this update is done as soon as possible. Add QUIC_FL_CONN_TX_TP_RECEIVED to flag the connection as having received the peer transport parameters. Indeed this is required when the ClientHello message is splitted between packets. Add QUIC_FL_CONN_FINALIZED to protect the connection from calling qc_conn_finalize() more than one time. This latter is called only when the connection has received the transport parameters and after returning from SSL_do_hanshake() which is the function which trigger the TLS ClientHello callback call. Remove the calls to qc_conn_finalize() from from the TLS ClientHello callbacks. Must be backported to 2.6. and 2.7.
2023-02-01 11:56:57 -05:00
extension_data + extension_len))
MINOR: ssl: QUIC transport parameters parsing. This patch modifies the TLS ClientHello message callback so that to parse the QUIC client transport parameters.
2020-11-23 09:37:11 -05:00
goto abort;
MEDIUM: quic: Remove qc_conn_finalize() from the ClientHello TLS callbacks This is a bad idea to make the TLS ClientHello callback call qc_conn_finalize(). If this latter fails, this would generate a TLS alert and make the connection send packet whereas it is not functional. But qc_conn_finalize() job was to install the transport parameters sent by the QUIC listener. This installation cannot be done at any time. This must be done after having possibly negotiated the QUIC version and before sending the first Handshake packets. It seems the better moment to do that in when the Handshake TX secrets are derived. This has been found inspecting the ngtcp2 code. Calling SSL_set_quic_transport_params() too late would make the ServerHello to be sent without the transport parameters. The code for the connection update which was done from qc_conn_finalize() has been moved to quic_transport_params_store(). So, this update is done as soon as possible. Add QUIC_FL_CONN_TX_TP_RECEIVED to flag the connection as having received the peer transport parameters. Indeed this is required when the ClientHello message is splitted between packets. Add QUIC_FL_CONN_FINALIZED to protect the connection from calling qc_conn_finalize() more than one time. This latter is called only when the connection has received the transport parameters and after returning from SSL_do_hanshake() which is the function which trigger the TLS ClientHello callback call. Remove the calls to qc_conn_finalize() from from the TLS ClientHello callbacks. Must be backported to 2.6. and 2.7.
2023-02-01 11:56:57 -05:00
qc->flags |= QUIC_FL_CONN_TX_TP_RECEIVED;
MINOR: ssl: QUIC transport parameters parsing. This patch modifies the TLS ClientHello message callback so that to parse the QUIC client transport parameters.
2020-11-23 09:37:11 -05:00
}
MEDIUM: quic/ssl: add new ex data for quic_conn Allow to register quic_conn as ex-data in SSL callbacks. A new index is used to identify it as ssl_qc_app_data_index. Replace connection by quic_conn as SSL ex-data when initializing the QUIC SSL session. When using SSL callbacks in QUIC context, the connection is now NULL. Used quic_conn instead to retrieve the required parameters. Also clean up The same changes are conducted inside the QUIC SSL methods of xprt-quic : connection instance usage is replaced by quic_conn.
2022-01-19 04:03:30 -05:00
#endif /* USE_QUIC */
MINOR: ssl: QUIC transport parameters parsing. This patch modifies the TLS ClientHello message callback so that to parse the QUIC client transport parameters.
2020-11-23 09:37:11 -05:00
MINOR: ssl: Don't abuse ssl_options. A bind_conf does contain a ssl_bind_conf, which already has a flag to know if early data are activated, so use that, instead of adding a new flag in the ssl_options field.
2017-10-27 08:58:08 -04:00
if (s->ssl_conf.early_data)
MEDIUM: ssl: Handle early data with OpenSSL 1.1.1 When compiled with Openssl >= 1.1.1, before attempting to do the handshake, try to read any early data. If any early data is present, then we'll create the session, read the data, and handle the request before we're doing the handshake. For this, we add a new connection flag, CO_FL_EARLY_SSL_HS, which is not part of the CO_FL_HANDSHAKE set, allowing to proceed with a session even before an SSL handshake is completed. As early data do have security implication, we let the origin server know the request comes from early data by adding the "Early-Data" header, as specified in this draft from the HTTP working group : https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-replay
2017-09-22 12:26:28 -04:00
allow_early = 1;
MINOR: ssl: support Openssl 1.1.1 early callback for switchctx Use Openssl-1.1.1 SSL_CTX_set_client_hello_cb to mimic BoringSSL early callback. Native multi certificate and SSL/TLS method per certificate is now supported by Openssl >= 1.1.1.
2017-08-16 05:33:17 -04:00
#ifdef OPENSSL_IS_BORINGSSL
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
if (SSL_early_callback_ctx_extension_get(ctx, TLSEXT_TYPE_server_name,
&extension_data, &extension_len)) {
MINOR: ssl: support Openssl 1.1.1 early callback for switchctx Use Openssl-1.1.1 SSL_CTX_set_client_hello_cb to mimic BoringSSL early callback. Native multi certificate and SSL/TLS method per certificate is now supported by Openssl >= 1.1.1.
2017-08-16 05:33:17 -04:00
#else
if (SSL_client_hello_get0_ext(ssl, TLSEXT_TYPE_server_name, &extension_data, &extension_len)) {
#endif
MEDIUM: ssl: convert CBS (BoringSSL api) usage to neutral code switchctx early callback is only supported for BoringSSL. To prepare the support of openssl 1.1.1 early callback, convert CBS api to neutral code to work with any ssl libs.
2017-08-16 05:28:44 -04:00
/*
* The server_name extension was given too much extensibility when it
* was written, so parsing the normal case is a bit complex.
*/
size_t len;
if (extension_len <= 2)
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
goto abort;
MEDIUM: ssl: convert CBS (BoringSSL api) usage to neutral code switchctx early callback is only supported for BoringSSL. To prepare the support of openssl 1.1.1 early callback, convert CBS api to neutral code to work with any ssl libs.
2017-08-16 05:28:44 -04:00
/* Extract the length of the supplied list of names. */
len = (*extension_data++) << 8;
len |= *extension_data++;
if (len + 2 != extension_len)
goto abort;
/*
* The list in practice only has a single element, so we only consider
* the first one.
*/
if (len == 0 || *extension_data++ != TLSEXT_NAMETYPE_host_name)
goto abort;
extension_len = len - 1;
/* Now we can finally pull out the byte array with the actual hostname. */
if (extension_len <= 2)
goto abort;
len = (*extension_data++) << 8;
len |= *extension_data++;
if (len == 0 || len + 2 > extension_len || len > TLSEXT_MAXLEN_host_name
|| memchr(extension_data, 0, len) != NULL)
goto abort;
MINOR: ssl: replace 'trash.area' by 'servername' in ssl_sock_switchctx_cbk() Replace 'trash.area' by 'servername' for more readibility.
2023-11-24 13:20:28 -05:00
servername = (char *)extension_data;
MEDIUM: ssl: convert CBS (BoringSSL api) usage to neutral code switchctx early callback is only supported for BoringSSL. To prepare the support of openssl 1.1.1 early callback, convert CBS api to neutral code to work with any ssl libs.
2017-08-16 05:28:44 -04:00
servername_len = len;
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
} else {
MINOR: ssl: generated certificate is missing in switchctx early callback Openssl 1.1.1 supports switchctx early callback and generated certificate. Generated certificate calls must be available in switchctx early callback.
2017-08-14 05:01:25 -04:00
#if (!defined SSL_NO_GENERATE_CERTIFICATES)
CLEANUP: listener: replace bind_conf->generate_cers with BC_O_GENERATE_CERTS The new flag will now replace this boolean variable.
2022-05-20 10:03:18 -04:00
if (s->options & BC_O_GENERATE_CERTS && ssl_sock_generate_certificate_from_conn(s, ssl)) {
MEDIUM: ssl: Handle early data with OpenSSL 1.1.1 When compiled with Openssl >= 1.1.1, before attempting to do the handshake, try to read any early data. If any early data is present, then we'll create the session, read the data, and handle the request before we're doing the handshake. For this, we add a new connection flag, CO_FL_EARLY_SSL_HS, which is not part of the CO_FL_HANDSHAKE set, allowing to proceed with a session even before an SSL handshake is completed. As early data do have security implication, we let the origin server know the request comes from early data by adding the "Early-Data" header, as specified in this draft from the HTTP working group : https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-replay
2017-09-22 12:26:28 -04:00
goto allow_early;
MINOR: ssl: generated certificate is missing in switchctx early callback Openssl 1.1.1 supports switchctx early callback and generated certificate. Generated certificate calls must be available in switchctx early callback.
2017-08-14 05:01:25 -04:00
}
#endif
MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection This patch changes the default certificate mechanism. Since the beginning of SSL in HAProxy, the default certificate was the first certificate of a bind line. This allowed to fallback on this certificate when no servername extension was sent by the server, or when no SAN nor CN was available in the certificate. When using a multi-certificate bundle (ecdsa+rsa), it was possible to have both certificates as the fallback one, leting openssl chose the right one. This was possible because a multi-certificate bundle was generating a unique SSL_CTX for both certificates. When the haproxy and openssl architecture evolved, we decided to use multiple SSL_CTX for a multi-cert bundle, in order to simplify the code and allow updates over the CLI. However only one default_ctx was allowed, so we lost the ability to chose between ECDSA and RSA for the default certificate. This patch allows to use a '*' filter for a certificate, which allow to lookup between multiple '*' filter, and have one in RSA and another one in ECDSA. It replaces the default_ctx mechanism in the ClientHello callback and use the standard algorithm to look for a default cert and chose between ECDSA and RSA. /!\ This patch breaks the automatic setting of the default certificate, which will be introduce in the next patch. So the first certificate of a bind line won't be used as a defaullt anymore. To use this feature, one could use crt-list with '*' filters: $ cat foo.crtlist foobar.pem.rsa * foobar.pem.ecdsa * In order to test the feature, it's easy to send a request without the servername extension and use ECDSA or RSA compatible ciphers: $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-RSA-AES256-GCM-SHA384 $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-ECDSA-AES256-GCM-SHA384
2024-01-10 08:05:59 -05:00
/* no servername field is not compatible with strict-sni */
if (s->strict_sni)
goto abort;
/* without servername extension, look for the defaults which is
* defined by an empty servername string */
servername = "";
servername_len = 0;
default_lookup = 1;
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
}
CLEANUP: assorted typo fixes in the code and comments These are mostly comments in the code. A few error messages were fixed and are of low enough importance not to deserve a backport. Some regtests were also fixed.
2020-03-10 03:06:11 -04:00
/* extract/check clientHello information */
MINOR: ssl: support Openssl 1.1.1 early callback for switchctx Use Openssl-1.1.1 SSL_CTX_set_client_hello_cb to mimic BoringSSL early callback. Native multi certificate and SSL/TLS method per certificate is now supported by Openssl >= 1.1.1.
2017-08-16 05:33:17 -04:00
#ifdef OPENSSL_IS_BORINGSSL
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
if (SSL_early_callback_ctx_extension_get(ctx, TLSEXT_TYPE_signature_algorithms, &extension_data, &extension_len)) {
MINOR: ssl: support Openssl 1.1.1 early callback for switchctx Use Openssl-1.1.1 SSL_CTX_set_client_hello_cb to mimic BoringSSL early callback. Native multi certificate and SSL/TLS method per certificate is now supported by Openssl >= 1.1.1.
2017-08-16 05:33:17 -04:00
#else
if (SSL_client_hello_get0_ext(ssl, TLSEXT_TYPE_signature_algorithms, &extension_data, &extension_len)) {
#endif
MEDIUM: ssl: convert CBS (BoringSSL api) usage to neutral code switchctx early callback is only supported for BoringSSL. To prepare the support of openssl 1.1.1 early callback, convert CBS api to neutral code to work with any ssl libs.
2017-08-16 05:28:44 -04:00
uint8_t sign;
size_t len;
if (extension_len < 2)
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
goto abort;
MEDIUM: ssl: convert CBS (BoringSSL api) usage to neutral code switchctx early callback is only supported for BoringSSL. To prepare the support of openssl 1.1.1 early callback, convert CBS api to neutral code to work with any ssl libs.
2017-08-16 05:28:44 -04:00
len = (*extension_data++) << 8;
len |= *extension_data++;
if (len + 2 != extension_len)
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
goto abort;
MEDIUM: ssl: convert CBS (BoringSSL api) usage to neutral code switchctx early callback is only supported for BoringSSL. To prepare the support of openssl 1.1.1 early callback, convert CBS api to neutral code to work with any ssl libs.
2017-08-16 05:28:44 -04:00
if (len % 2 != 0)
goto abort;
for (; len > 0; len -= 2) {
extension_data++; /* hash */
sign = *extension_data++;
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
switch (sign) {
case TLSEXT_signature_rsa:
BUG/MEDIUM: ECC cert should work with TLS < v1.2 and openssl >= 1.1.1 With openssl >= 1.1.1 and boringssl multi-cert is natively supported. ECDSA/RSA selection is done and work correctly with TLS >= v1.2. TLS < v1.2 have no TLSEXT_TYPE_signature_algorithms extension: ECC certificate can't be selected, and handshake fail if no RSA cert is present. Safe ECC certificate selection without client announcement can be very tricky (browser compatibilty). The safer approach is to select ECDSA certificate if no other certificate matches, like it is with openssl < 1.1.1: certificate selection is only done via the SNI. Thanks to Lukas Tribus for reporting this and analysing the problem. This patch should be backported to 1.8
2018-09-03 10:29:16 -04:00
has_rsa_sig = 1;
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
break;
case TLSEXT_signature_ecdsa:
has_ecdsa_sig = 1;
break;
default:
continue;
}
BUG/MEDIUM: ECC cert should work with TLS < v1.2 and openssl >= 1.1.1 With openssl >= 1.1.1 and boringssl multi-cert is natively supported. ECDSA/RSA selection is done and work correctly with TLS >= v1.2. TLS < v1.2 have no TLSEXT_TYPE_signature_algorithms extension: ECC certificate can't be selected, and handshake fail if no RSA cert is present. Safe ECC certificate selection without client announcement can be very tricky (browser compatibilty). The safer approach is to select ECDSA certificate if no other certificate matches, like it is with openssl < 1.1.1: certificate selection is only done via the SNI. Thanks to Lukas Tribus for reporting this and analysing the problem. This patch should be backported to 1.8
2018-09-03 10:29:16 -04:00
if (has_ecdsa_sig && has_rsa_sig)
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
break;
}
} else {
DOC: ssl: Use consistent naming for TLS protocols In most cases, "TLSv1.x" naming is used across and documentation, lazy people tend to grep too much and may not find what they are looking for. Fixing people is hard.
2018-08-13 19:56:13 -04:00
/* without TLSEXT_TYPE_signature_algorithms extension (< TLSv1.2) */
BUG/MEDIUM: ECC cert should work with TLS < v1.2 and openssl >= 1.1.1 With openssl >= 1.1.1 and boringssl multi-cert is natively supported. ECDSA/RSA selection is done and work correctly with TLS >= v1.2. TLS < v1.2 have no TLSEXT_TYPE_signature_algorithms extension: ECC certificate can't be selected, and handshake fail if no RSA cert is present. Safe ECC certificate selection without client announcement can be very tricky (browser compatibilty). The safer approach is to select ECDSA certificate if no other certificate matches, like it is with openssl < 1.1.1: certificate selection is only done via the SNI. Thanks to Lukas Tribus for reporting this and analysing the problem. This patch should be backported to 1.8
2018-09-03 10:29:16 -04:00
has_rsa_sig = 1;
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
}
if (has_ecdsa_sig) { /* in very rare case: has ecdsa sign but not a ECDSA cipher */
MEDIUM: ssl: convert CBS (BoringSSL api) usage to neutral code switchctx early callback is only supported for BoringSSL. To prepare the support of openssl 1.1.1 early callback, convert CBS api to neutral code to work with any ssl libs.
2017-08-16 05:28:44 -04:00
const SSL_CIPHER *cipher;
BUG/MINOR: ssl: suboptimal certificate selection with TLSv1.3 and dual ECDSA/RSA When using TLSv1.3, the signature algorithms extension is used to chose the right ECDSA or RSA certificate. However there was an old test for previous version of TLS (< 1.3) which was testing if the cipher is compatible with ECDSA when an ECDSA signature algorithm is used. This test was relying on SSL_CIPHER_get_auth_nid(cipher) == NID_auth_ecdsa to verify if the cipher is still good. Problem is, with TLSv1.3, all ciphersuites are compatible with any authentication algorithm, but SSL_CIPHER_get_auth_nid(cipher) does not return NID_auth_ecdsa, but NID_auth_any. Because of this, with TLSv1.3 when both ECDSA and RSA certificates are available for a domain, the ECDSA one is not chosen in priority. This patch also introduces a test on the cipher IDs for the signaling ciphersuites, because they would always return NID_auth_any, and are not relevent for this selection. This patch fixes issue #2300. Must be backported in all stable versions.
2023-10-24 17:58:02 -04:00
uint32_t cipher_id;
MEDIUM: ssl: convert CBS (BoringSSL api) usage to neutral code switchctx early callback is only supported for BoringSSL. To prepare the support of openssl 1.1.1 early callback, convert CBS api to neutral code to work with any ssl libs.
2017-08-16 05:28:44 -04:00
size_t len;
const uint8_t *cipher_suites;
BUG/MEDIUM: ECC cert should work with TLS < v1.2 and openssl >= 1.1.1 With openssl >= 1.1.1 and boringssl multi-cert is natively supported. ECDSA/RSA selection is done and work correctly with TLS >= v1.2. TLS < v1.2 have no TLSEXT_TYPE_signature_algorithms extension: ECC certificate can't be selected, and handshake fail if no RSA cert is present. Safe ECC certificate selection without client announcement can be very tricky (browser compatibilty). The safer approach is to select ECDSA certificate if no other certificate matches, like it is with openssl < 1.1.1: certificate selection is only done via the SNI. Thanks to Lukas Tribus for reporting this and analysing the problem. This patch should be backported to 1.8
2018-09-03 10:29:16 -04:00
has_ecdsa_sig = 0;
MINOR: ssl: support Openssl 1.1.1 early callback for switchctx Use Openssl-1.1.1 SSL_CTX_set_client_hello_cb to mimic BoringSSL early callback. Native multi certificate and SSL/TLS method per certificate is now supported by Openssl >= 1.1.1.
2017-08-16 05:33:17 -04:00
#ifdef OPENSSL_IS_BORINGSSL
MEDIUM: ssl: convert CBS (BoringSSL api) usage to neutral code switchctx early callback is only supported for BoringSSL. To prepare the support of openssl 1.1.1 early callback, convert CBS api to neutral code to work with any ssl libs.
2017-08-16 05:28:44 -04:00
len = ctx->cipher_suites_len;
cipher_suites = ctx->cipher_suites;
MINOR: ssl: support Openssl 1.1.1 early callback for switchctx Use Openssl-1.1.1 SSL_CTX_set_client_hello_cb to mimic BoringSSL early callback. Native multi certificate and SSL/TLS method per certificate is now supported by Openssl >= 1.1.1.
2017-08-16 05:33:17 -04:00
#else
len = SSL_client_hello_get0_ciphers(ssl, &cipher_suites);
#endif
MEDIUM: ssl: convert CBS (BoringSSL api) usage to neutral code switchctx early callback is only supported for BoringSSL. To prepare the support of openssl 1.1.1 early callback, convert CBS api to neutral code to work with any ssl libs.
2017-08-16 05:28:44 -04:00
if (len % 2 != 0)
goto abort;
for (; len != 0; len -= 2, cipher_suites += 2) {
MINOR: ssl: support Openssl 1.1.1 early callback for switchctx Use Openssl-1.1.1 SSL_CTX_set_client_hello_cb to mimic BoringSSL early callback. Native multi certificate and SSL/TLS method per certificate is now supported by Openssl >= 1.1.1.
2017-08-16 05:33:17 -04:00
#ifdef OPENSSL_IS_BORINGSSL
MEDIUM: ssl: convert CBS (BoringSSL api) usage to neutral code switchctx early callback is only supported for BoringSSL. To prepare the support of openssl 1.1.1 early callback, convert CBS api to neutral code to work with any ssl libs.
2017-08-16 05:28:44 -04:00
uint16_t cipher_suite = (cipher_suites[0] << 8) | cipher_suites[1];
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
cipher = SSL_get_cipher_by_value(cipher_suite);
MINOR: ssl: support Openssl 1.1.1 early callback for switchctx Use Openssl-1.1.1 SSL_CTX_set_client_hello_cb to mimic BoringSSL early callback. Native multi certificate and SSL/TLS method per certificate is now supported by Openssl >= 1.1.1.
2017-08-16 05:33:17 -04:00
#else
cipher = SSL_CIPHER_find(ssl, cipher_suites);
#endif
BUG/MEDIUM: ssl: segfault when cipher is NULL The patch which fixes the certificate selection uses SSL_CIPHER_get_id() to skip the SCSV ciphers without checking if cipher is NULL. This patch fixes the issue by skipping any NULL cipher in the iteration. Problem was reported in #2329. Need to be backported where 23093c72f139eddfce68ea5580193ee131901591 was backported. No release was made with this patch so the severity is MEDIUM.
2023-10-30 13:08:16 -04:00
if (!cipher)
continue;
BUG/MINOR: ssl: suboptimal certificate selection with TLSv1.3 and dual ECDSA/RSA When using TLSv1.3, the signature algorithms extension is used to chose the right ECDSA or RSA certificate. However there was an old test for previous version of TLS (< 1.3) which was testing if the cipher is compatible with ECDSA when an ECDSA signature algorithm is used. This test was relying on SSL_CIPHER_get_auth_nid(cipher) == NID_auth_ecdsa to verify if the cipher is still good. Problem is, with TLSv1.3, all ciphersuites are compatible with any authentication algorithm, but SSL_CIPHER_get_auth_nid(cipher) does not return NID_auth_ecdsa, but NID_auth_any. Because of this, with TLSv1.3 when both ECDSA and RSA certificates are available for a domain, the ECDSA one is not chosen in priority. This patch also introduces a test on the cipher IDs for the signaling ciphersuites, because they would always return NID_auth_any, and are not relevent for this selection. This patch fixes issue #2300. Must be backported in all stable versions.
2023-10-24 17:58:02 -04:00
cipher_id = SSL_CIPHER_get_id(cipher);
/* skip the SCSV "fake" signaling ciphersuites because they are NID_auth_any (RFC 7507) */
if (cipher_id == SSL3_CK_SCSV || cipher_id == SSL3_CK_FALLBACK_SCSV)
continue;
BUG/MEDIUM: ssl: segfault when cipher is NULL The patch which fixes the certificate selection uses SSL_CIPHER_get_id() to skip the SCSV ciphers without checking if cipher is NULL. This patch fixes the issue by skipping any NULL cipher in the iteration. Problem was reported in #2329. Need to be backported where 23093c72f139eddfce68ea5580193ee131901591 was backported. No release was made with this patch so the severity is MEDIUM.
2023-10-30 13:08:16 -04:00
if (SSL_CIPHER_get_auth_nid(cipher) == NID_auth_ecdsa
|| SSL_CIPHER_get_auth_nid(cipher) == NID_auth_any) {
BUG/MEDIUM: ECC cert should work with TLS < v1.2 and openssl >= 1.1.1 With openssl >= 1.1.1 and boringssl multi-cert is natively supported. ECDSA/RSA selection is done and work correctly with TLS >= v1.2. TLS < v1.2 have no TLSEXT_TYPE_signature_algorithms extension: ECC certificate can't be selected, and handshake fail if no RSA cert is present. Safe ECC certificate selection without client announcement can be very tricky (browser compatibilty). The safer approach is to select ECDSA certificate if no other certificate matches, like it is with openssl < 1.1.1: certificate selection is only done via the SNI. Thanks to Lukas Tribus for reporting this and analysing the problem. This patch should be backported to 1.8
2018-09-03 10:29:16 -04:00
has_ecdsa_sig = 1;
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
break;
}
}
}
MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection This patch changes the default certificate mechanism. Since the beginning of SSL in HAProxy, the default certificate was the first certificate of a bind line. This allowed to fallback on this certificate when no servername extension was sent by the server, or when no SAN nor CN was available in the certificate. When using a multi-certificate bundle (ecdsa+rsa), it was possible to have both certificates as the fallback one, leting openssl chose the right one. This was possible because a multi-certificate bundle was generating a unique SSL_CTX for both certificates. When the haproxy and openssl architecture evolved, we decided to use multiple SSL_CTX for a multi-cert bundle, in order to simplify the code and allow updates over the CLI. However only one default_ctx was allowed, so we lost the ability to chose between ECDSA and RSA for the default certificate. This patch allows to use a '*' filter for a certificate, which allow to lookup between multiple '*' filter, and have one in RSA and another one in ECDSA. It replaces the default_ctx mechanism in the ClientHello callback and use the standard algorithm to look for a default cert and chose between ECDSA and RSA. /!\ This patch breaks the automatic setting of the default certificate, which will be introduce in the next patch. So the first certificate of a bind line won't be used as a defaullt anymore. To use this feature, one could use crt-list with '*' filters: $ cat foo.crtlist foobar.pem.rsa * foobar.pem.ecdsa * In order to test the feature, it's easy to send a request without the servername extension and use ECDSA or RSA compatible ciphers: $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-RSA-AES256-GCM-SHA384 $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-ECDSA-AES256-GCM-SHA384
2024-01-10 08:05:59 -05:00
sni_lookup:
MEDIUM: ssl: use ssl_sock_chose_sni_ctx() in the clienthello callback This patch removes the code which selects the SSL certificate in the OpenSSL Client Hello callback, to use the ssl_sock_chose_sni_ctx() function which does the same. The bigger part of the function which remains is the extraction of the servername, ciphers and sigalgs, because it's done manually by parsing the TLS extensions. This is not supposed to change anything functionally.
2023-11-23 11:54:47 -05:00
/* we need to transform this a NULL-ended string in lowecase */
for (i = 0; i < trash.size && i < servername_len; i++)
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
trash.area[i] = tolower(servername[i]);
trash.area[i] = 0;
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
MEDIUM: ssl/cli: 'set ssl cert' updates a certificate from the CLI $ echo -e "set ssl cert certificate.pem <<\n$(cat certificate2.pem)\n" | \ socat stdio /var/run/haproxy.stat Certificate updated! The operation is locked at the ckch level with a HA_SPINLOCK_T which prevents the ckch architecture (ckch_store, ckch_inst..) to be modified at the same time. So you can't do a certificate update at the same time from multiple CLI connections. SNI trees are also locked with a HA_RWLOCK_T so reading operations are locked only during a certificate update. Bundles are supported but you need to update each file (.rsa|ecdsa|.dsa) independently. If a file is used in the configuration as a bundle AND as a unique certificate, both will be updated. Bundles, directories and crt-list are supported, however filters in crt-list are currently unsupported. The code tries to allocate every SNIs and certificate instances first, so it can rollback the operation if that was unsuccessful. If you have too much instances of the certificate (at least 20000 in my tests on my laptop), the function can take too much time and be killed by the watchdog. This will be fixed later. Also with too much certificates it's possible that socat exits before the end of the generation without displaying a message, consider changing the socat timeout in this case (-t2 for example). The size of the certificate is currently limited by the maximum size of a payload, that must fit in a buffer.
2019-09-19 11:12:49 -04:00
HA_RWLOCK_RDLOCK(SNI_LOCK, &s->sni_lock);
MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection This patch changes the default certificate mechanism. Since the beginning of SSL in HAProxy, the default certificate was the first certificate of a bind line. This allowed to fallback on this certificate when no servername extension was sent by the server, or when no SAN nor CN was available in the certificate. When using a multi-certificate bundle (ecdsa+rsa), it was possible to have both certificates as the fallback one, leting openssl chose the right one. This was possible because a multi-certificate bundle was generating a unique SSL_CTX for both certificates. When the haproxy and openssl architecture evolved, we decided to use multiple SSL_CTX for a multi-cert bundle, in order to simplify the code and allow updates over the CLI. However only one default_ctx was allowed, so we lost the ability to chose between ECDSA and RSA for the default certificate. This patch allows to use a '*' filter for a certificate, which allow to lookup between multiple '*' filter, and have one in RSA and another one in ECDSA. It replaces the default_ctx mechanism in the ClientHello callback and use the standard algorithm to look for a default cert and chose between ECDSA and RSA. /!\ This patch breaks the automatic setting of the default certificate, which will be introduce in the next patch. So the first certificate of a bind line won't be used as a defaullt anymore. To use this feature, one could use crt-list with '*' filters: $ cat foo.crtlist foobar.pem.rsa * foobar.pem.ecdsa * In order to test the feature, it's easy to send a request without the servername extension and use ECDSA or RSA compatible ciphers: $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-RSA-AES256-GCM-SHA384 $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-ECDSA-AES256-GCM-SHA384
2024-01-10 08:05:59 -05:00
sni_ctx = ssl_sock_chose_sni_ctx(s, trash.area, has_rsa_sig, has_ecdsa_sig);
MEDIUM: ssl: use ssl_sock_chose_sni_ctx() in the clienthello callback This patch removes the code which selects the SSL certificate in the OpenSSL Client Hello callback, to use the ssl_sock_chose_sni_ctx() function which does the same. The bigger part of the function which remains is the extraction of the servername, ciphers and sigalgs, because it's done manually by parsing the TLS extensions. This is not supposed to change anything functionally.
2023-11-23 11:54:47 -05:00
if (sni_ctx) {
BUG/MEDIUM: ssl: does not look for all SNIs before chosing a certificate In bug #810, the SNI are not matched correctly, indeed when trying to match a certificate type in ssl_sock_switchctx_cbk() all SNIs were not looked up correctly. In the case you have in a crt-list: wildcard.subdomain.domain.tld.pem.rsa *.subdomain.domain.tld record.subdomain.domain.tld record.subdomain.domain.tld.pem.ecdsa record.subdomain.domain.tld another-record.subdomain.domain.tld If the client only supports RSA and requests "another-record.subdomain.domain.tld", HAProxy will find the single ECDSA certificate and won't try to look up for a wildcard RSA certificate. This patch fixes the code so we look for all single and wildcard before chosing the certificate type. This bug was introduced by commit 3777e3a ("BUG/MINOR: ssl: certificate choice can be unexpected with openssl >= 1.1.1"). It must be backported as far as 1.8 once it is heavily tested.
2020-08-14 08:43:35 -04:00
/* switch ctx */
MEDIUM: ssl: use ssl_sock_chose_sni_ctx() in the clienthello callback This patch removes the code which selects the SSL certificate in the OpenSSL Client Hello callback, to use the ssl_sock_chose_sni_ctx() function which does the same. The bigger part of the function which remains is the extraction of the servername, ciphers and sigalgs, because it's done manually by parsing the TLS extensions. This is not supposed to change anything functionally.
2023-11-23 11:54:47 -05:00
struct ssl_bind_conf *conf = sni_ctx->conf;
ssl_sock_switchctx_set(ssl, sni_ctx->ctx);
BUG/MEDIUM: ssl: does not look for all SNIs before chosing a certificate In bug #810, the SNI are not matched correctly, indeed when trying to match a certificate type in ssl_sock_switchctx_cbk() all SNIs were not looked up correctly. In the case you have in a crt-list: wildcard.subdomain.domain.tld.pem.rsa *.subdomain.domain.tld record.subdomain.domain.tld record.subdomain.domain.tld.pem.ecdsa record.subdomain.domain.tld another-record.subdomain.domain.tld If the client only supports RSA and requests "another-record.subdomain.domain.tld", HAProxy will find the single ECDSA certificate and won't try to look up for a wildcard RSA certificate. This patch fixes the code so we look for all single and wildcard before chosing the certificate type. This bug was introduced by commit 3777e3a ("BUG/MINOR: ssl: certificate choice can be unexpected with openssl >= 1.1.1"). It must be backported as far as 1.8 once it is heavily tested.
2020-08-14 08:43:35 -04:00
if (conf) {
methodVersions[conf->ssl_methods.min].ssl_set_version(ssl, SET_MIN);
methodVersions[conf->ssl_methods.max].ssl_set_version(ssl, SET_MAX);
if (conf->early_data)
allow_early = 1;
BUG/MINOR: ssl: certificate choice can be unexpected with openssl >= 1.1.1 It's regression from 9f9b0c6 "BUG/MEDIUM: ECC cert should work with TLS < v1.2 and openssl >= 1.1.1". Wilcard EC certifcate could be selected at the expense of specific RSA certificate. In any case, specific certificate should always selected first, next wildcard. Reflect this rule in a loop to avoid any bug in certificate selection changes. Fix issue #394. It should be backported as far as 1.8.
2019-11-06 10:05:34 -05:00
}
BUG/MEDIUM: ssl: does not look for all SNIs before chosing a certificate In bug #810, the SNI are not matched correctly, indeed when trying to match a certificate type in ssl_sock_switchctx_cbk() all SNIs were not looked up correctly. In the case you have in a crt-list: wildcard.subdomain.domain.tld.pem.rsa *.subdomain.domain.tld record.subdomain.domain.tld record.subdomain.domain.tld.pem.ecdsa record.subdomain.domain.tld another-record.subdomain.domain.tld If the client only supports RSA and requests "another-record.subdomain.domain.tld", HAProxy will find the single ECDSA certificate and won't try to look up for a wildcard RSA certificate. This patch fixes the code so we look for all single and wildcard before chosing the certificate type. This bug was introduced by commit 3777e3a ("BUG/MINOR: ssl: certificate choice can be unexpected with openssl >= 1.1.1"). It must be backported as far as 1.8 once it is heavily tested.
2020-08-14 08:43:35 -04:00
HA_RWLOCK_RDUNLOCK(SNI_LOCK, &s->sni_lock);
goto allow_early;
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
}
MEDIUM: ssl/cli: 'set ssl cert' updates a certificate from the CLI $ echo -e "set ssl cert certificate.pem <<\n$(cat certificate2.pem)\n" | \ socat stdio /var/run/haproxy.stat Certificate updated! The operation is locked at the ckch level with a HA_SPINLOCK_T which prevents the ckch architecture (ckch_store, ckch_inst..) to be modified at the same time. So you can't do a certificate update at the same time from multiple CLI connections. SNI trees are also locked with a HA_RWLOCK_T so reading operations are locked only during a certificate update. Bundles are supported but you need to update each file (.rsa|ecdsa|.dsa) independently. If a file is used in the configuration as a bundle AND as a unique certificate, both will be updated. Bundles, directories and crt-list are supported, however filters in crt-list are currently unsupported. The code tries to allocate every SNIs and certificate instances first, so it can rollback the operation if that was unsuccessful. If you have too much instances of the certificate (at least 20000 in my tests on my laptop), the function can take too much time and be killed by the watchdog. This will be fixed later. Also with too much certificates it's possible that socat exits before the end of the generation without displaying a message, consider changing the socat timeout in this case (-t2 for example). The size of the certificate is currently limited by the maximum size of a payload, that must fit in a buffer.
2019-09-19 11:12:49 -04:00
CLEANUP: ssl: fix SNI/CKCH lock labels The CKCH and the SNI locks originally used the same label, we split them but we forgot to change some of them.
2019-10-18 05:02:19 -04:00
HA_RWLOCK_RDUNLOCK(SNI_LOCK, &s->sni_lock);
MINOR: ssl: generated certificate is missing in switchctx early callback Openssl 1.1.1 supports switchctx early callback and generated certificate. Generated certificate calls must be available in switchctx early callback.
2017-08-14 05:01:25 -04:00
#if (!defined SSL_NO_GENERATE_CERTIFICATES)
MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection This patch changes the default certificate mechanism. Since the beginning of SSL in HAProxy, the default certificate was the first certificate of a bind line. This allowed to fallback on this certificate when no servername extension was sent by the server, or when no SAN nor CN was available in the certificate. When using a multi-certificate bundle (ecdsa+rsa), it was possible to have both certificates as the fallback one, leting openssl chose the right one. This was possible because a multi-certificate bundle was generating a unique SSL_CTX for both certificates. When the haproxy and openssl architecture evolved, we decided to use multiple SSL_CTX for a multi-cert bundle, in order to simplify the code and allow updates over the CLI. However only one default_ctx was allowed, so we lost the ability to chose between ECDSA and RSA for the default certificate. This patch allows to use a '*' filter for a certificate, which allow to lookup between multiple '*' filter, and have one in RSA and another one in ECDSA. It replaces the default_ctx mechanism in the ClientHello callback and use the standard algorithm to look for a default cert and chose between ECDSA and RSA. /!\ This patch breaks the automatic setting of the default certificate, which will be introduce in the next patch. So the first certificate of a bind line won't be used as a defaullt anymore. To use this feature, one could use crt-list with '*' filters: $ cat foo.crtlist foobar.pem.rsa * foobar.pem.ecdsa * In order to test the feature, it's easy to send a request without the servername extension and use ECDSA or RSA compatible ciphers: $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-RSA-AES256-GCM-SHA384 $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-ECDSA-AES256-GCM-SHA384
2024-01-10 08:05:59 -05:00
if (s->options & BC_O_GENERATE_CERTS && ssl_sock_generate_certificate(trash.area, s, ssl)) {
MINOR: ssl: generated certificate is missing in switchctx early callback Openssl 1.1.1 supports switchctx early callback and generated certificate. Generated certificate calls must be available in switchctx early callback.
2017-08-14 05:01:25 -04:00
/* switch ctx done in ssl_sock_generate_certificate */
MEDIUM: ssl: Handle early data with OpenSSL 1.1.1 When compiled with Openssl >= 1.1.1, before attempting to do the handshake, try to read any early data. If any early data is present, then we'll create the session, read the data, and handle the request before we're doing the handshake. For this, we add a new connection flag, CO_FL_EARLY_SSL_HS, which is not part of the CO_FL_HANDSHAKE set, allowing to proceed with a session even before an SSL handshake is completed. As early data do have security implication, we let the origin server know the request comes from early data by adding the "Early-Data" header, as specified in this draft from the HTTP working group : https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-replay
2017-09-22 12:26:28 -04:00
goto allow_early;
MINOR: ssl: generated certificate is missing in switchctx early callback Openssl 1.1.1 supports switchctx early callback and generated certificate. Generated certificate calls must be available in switchctx early callback.
2017-08-14 05:01:25 -04:00
}
#endif
MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection This patch changes the default certificate mechanism. Since the beginning of SSL in HAProxy, the default certificate was the first certificate of a bind line. This allowed to fallback on this certificate when no servername extension was sent by the server, or when no SAN nor CN was available in the certificate. When using a multi-certificate bundle (ecdsa+rsa), it was possible to have both certificates as the fallback one, leting openssl chose the right one. This was possible because a multi-certificate bundle was generating a unique SSL_CTX for both certificates. When the haproxy and openssl architecture evolved, we decided to use multiple SSL_CTX for a multi-cert bundle, in order to simplify the code and allow updates over the CLI. However only one default_ctx was allowed, so we lost the ability to chose between ECDSA and RSA for the default certificate. This patch allows to use a '*' filter for a certificate, which allow to lookup between multiple '*' filter, and have one in RSA and another one in ECDSA. It replaces the default_ctx mechanism in the ClientHello callback and use the standard algorithm to look for a default cert and chose between ECDSA and RSA. /!\ This patch breaks the automatic setting of the default certificate, which will be introduce in the next patch. So the first certificate of a bind line won't be used as a defaullt anymore. To use this feature, one could use crt-list with '*' filters: $ cat foo.crtlist foobar.pem.rsa * foobar.pem.ecdsa * In order to test the feature, it's easy to send a request without the servername extension and use ECDSA or RSA compatible ciphers: $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-RSA-AES256-GCM-SHA384 $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-ECDSA-AES256-GCM-SHA384
2024-01-10 08:05:59 -05:00
if (!s->strict_sni && !default_lookup) {
/* we didn't find a SNI, and we didn't look for a default
* look again to find a matching default cert */
servername = "";
servername_len = 0;
default_lookup = 1;
goto sni_lookup;
BUG/MEDIUM: ssl: in bind line, ssl-options after 'crt' are ignored. Bug introduced with "removes SSL_CTX_set_ssl_version call and cleanup CTX creation": ssl_sock_new_ctx is called before all the bind line is parsed. The fix consists of separating the use of default_ctx as the initialization context of the SSL connection via bind_conf->initial_ctx. Initial_ctx contains all the necessary parameters before performing the selection of the CTX: default_ctx is processed as others ctx without unnecessary parameters.
2017-03-06 09:34:44 -05:00
}
BUG/MEDIUM: ssl: abort with the correct SSL error when SNI not found Since commit c2aae74 ("MEDIUM: ssl: Handle early data with OpenSSL 1.1.1"), the codepath of the clientHello callback changed, letting an unknown SNI escape with a 'return 1' instead of passing through the abort label. An error was still emitted because the frontend continued the handshake with the initial_ctx, which can't be used to achieve an handshake. However, it had the ugly side effect of letting the request pass in the case of a TLS resume. Which could be surprising when combining strict-sni with the removing of a crt-list entry over the CLI for example. (like its done in the ssl/new_del_ssl_crlfile.vtc reg-test). This patch switches the code path of the allow_early and abort label, so the default code path is the abort one, letting the clientHello returns the correct SSL_AD_UNRECOGNIZED_NAME in case of errors. Which means the client will now receive: OpenSSL error[0x14094458] ssl3_read_bytes: tlsv1 unrecognized name Instead of: OpenSSL error[0x14094410] ssl3_read_bytes: sslv3 alert handshake failure Which was the error emitted before HAProxy 1.8. This patch must be carrefuly backported as far as 1.8 once we validated its impact.
2021-11-18 11:46:26 -05:00
BUG/MINOR: ssl: Store client SNI in SSL context in case of ClientHello error If an error is raised during the ClientHello callback on the server side (ssl_sock_switchctx_cbk), the servername callback won't be called and the client's SNI will not be saved in the SSL context. But since we use the SSL_get_servername function to return this SNI in the ssl_fc_sni sample fetch, that means that in case of error, such as an SNI mismatch with a frontend having the strict-sni option enabled, the sample fetch would not work (making strict-sni related errors hard to debug). This patch fixes that by storing the SNI as an ex_data in the SSL context in case the ClientHello callback returns an error. This way the sample fetch can fallback to getting the SNI this way. It will still first call the SSL_get_servername function first since it is the proper way of getting a client's SNI when the handshake succeeded. In order to avoid memory allocations are runtime into this highly used runtime function, a new memory pool was created to store those client SNIs. Its entry size is set to 256 bytes since SNIs can't be longer than 255 characters. This fixes GitHub #1484. It can be backported in 2.5.
2022-01-07 11:12:01 -05:00
/* We are about to raise an handshake error so the servername extension
* callback will never be called and the SNI will never be stored in the
* SSL context. In order for the ssl_fc_sni sample fetch to still work
* in such a case, we store the SNI ourselves as an ex_data information
* in the SSL context.
*/
{
char *client_sni = pool_alloc(ssl_sock_client_sni_pool);
if (client_sni) {
MINOR: ssl: replace 'trash.area' by 'servername' in ssl_sock_switchctx_cbk() Replace 'trash.area' by 'servername' for more readibility.
2023-11-24 13:20:28 -05:00
strncpy(client_sni, servername, TLSEXT_MAXLEN_host_name);
BUG/MINOR: ssl: Store client SNI in SSL context in case of ClientHello error If an error is raised during the ClientHello callback on the server side (ssl_sock_switchctx_cbk), the servername callback won't be called and the client's SNI will not be saved in the SSL context. But since we use the SSL_get_servername function to return this SNI in the ssl_fc_sni sample fetch, that means that in case of error, such as an SNI mismatch with a frontend having the strict-sni option enabled, the sample fetch would not work (making strict-sni related errors hard to debug). This patch fixes that by storing the SNI as an ex_data in the SSL context in case the ClientHello callback returns an error. This way the sample fetch can fallback to getting the SNI this way. It will still first call the SSL_get_servername function first since it is the proper way of getting a client's SNI when the handshake succeeded. In order to avoid memory allocations are runtime into this highly used runtime function, a new memory pool was created to store those client SNIs. Its entry size is set to 256 bytes since SNIs can't be longer than 255 characters. This fixes GitHub #1484. It can be backported in 2.5.
2022-01-07 11:12:01 -05:00
client_sni[TLSEXT_MAXLEN_host_name] = '\0';
SSL_set_ex_data(ssl, ssl_client_sni_index, client_sni);
}
}
BUG/MEDIUM: ssl: abort with the correct SSL error when SNI not found Since commit c2aae74 ("MEDIUM: ssl: Handle early data with OpenSSL 1.1.1"), the codepath of the clientHello callback changed, letting an unknown SNI escape with a 'return 1' instead of passing through the abort label. An error was still emitted because the frontend continued the handshake with the initial_ctx, which can't be used to achieve an handshake. However, it had the ugly side effect of letting the request pass in the case of a TLS resume. Which could be surprising when combining strict-sni with the removing of a crt-list entry over the CLI for example. (like its done in the ssl/new_del_ssl_crlfile.vtc reg-test). This patch switches the code path of the allow_early and abort label, so the default code path is the abort one, letting the clientHello returns the correct SSL_AD_UNRECOGNIZED_NAME in case of errors. Which means the client will now receive: OpenSSL error[0x14094458] ssl3_read_bytes: tlsv1 unrecognized name Instead of: OpenSSL error[0x14094410] ssl3_read_bytes: sslv3 alert handshake failure Which was the error emitted before HAProxy 1.8. This patch must be carrefuly backported as far as 1.8 once we validated its impact.
2021-11-18 11:46:26 -05:00
/* other cases fallback on abort, if strict-sni is set but no node was found */
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
abort:
/* abort handshake (was SSL_TLSEXT_ERR_ALERT_FATAL) */
MEDIUM: quic/ssl: add new ex data for quic_conn Allow to register quic_conn as ex-data in SSL callbacks. A new index is used to identify it as ssl_qc_app_data_index. Replace connection by quic_conn as SSL ex-data when initializing the QUIC SSL session. When using SSL callbacks in QUIC context, the connection is now NULL. Used quic_conn instead to retrieve the required parameters. Also clean up The same changes are conducted inside the QUIC SSL methods of xprt-quic : connection instance usage is replaced by quic_conn.
2022-01-19 04:03:30 -05:00
if (conn)
conn->err_code = CO_ER_SSL_HANDSHAKE;
MINOR: ssl: support Openssl 1.1.1 early callback for switchctx Use Openssl-1.1.1 SSL_CTX_set_client_hello_cb to mimic BoringSSL early callback. Native multi certificate and SSL/TLS method per certificate is now supported by Openssl >= 1.1.1.
2017-08-16 05:33:17 -04:00
#ifdef OPENSSL_IS_BORINGSSL
MEDIUM: ssl: convert CBS (BoringSSL api) usage to neutral code switchctx early callback is only supported for BoringSSL. To prepare the support of openssl 1.1.1 early callback, convert CBS api to neutral code to work with any ssl libs.
2017-08-16 05:28:44 -04:00
return ssl_select_cert_error;
MINOR: ssl: support Openssl 1.1.1 early callback for switchctx Use Openssl-1.1.1 SSL_CTX_set_client_hello_cb to mimic BoringSSL early callback. Native multi certificate and SSL/TLS method per certificate is now supported by Openssl >= 1.1.1.
2017-08-16 05:33:17 -04:00
#else
*al = SSL_AD_UNRECOGNIZED_NAME;
return 0;
#endif
BUG/MEDIUM: ssl: abort with the correct SSL error when SNI not found Since commit c2aae74 ("MEDIUM: ssl: Handle early data with OpenSSL 1.1.1"), the codepath of the clientHello callback changed, letting an unknown SNI escape with a 'return 1' instead of passing through the abort label. An error was still emitted because the frontend continued the handshake with the initial_ctx, which can't be used to achieve an handshake. However, it had the ugly side effect of letting the request pass in the case of a TLS resume. Which could be surprising when combining strict-sni with the removing of a crt-list entry over the CLI for example. (like its done in the ssl/new_del_ssl_crlfile.vtc reg-test). This patch switches the code path of the allow_early and abort label, so the default code path is the abort one, letting the clientHello returns the correct SSL_AD_UNRECOGNIZED_NAME in case of errors. Which means the client will now receive: OpenSSL error[0x14094458] ssl3_read_bytes: tlsv1 unrecognized name Instead of: OpenSSL error[0x14094410] ssl3_read_bytes: sslv3 alert handshake failure Which was the error emitted before HAProxy 1.8. This patch must be carrefuly backported as far as 1.8 once we validated its impact.
2021-11-18 11:46:26 -05:00
allow_early:
#ifdef OPENSSL_IS_BORINGSSL
if (allow_early)
SSL_set_early_data_enabled(ssl, 1);
#else
if (!allow_early)
SSL_set_max_early_data(ssl, 0);
#endif
return 1;
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
}
CLEANUP: ssl: fix wrong #else commentary The else is not for boringSSL but for the lack of Client Hello callback. Should have been changed in 1fc44d4 ("BUILD: ssl: guard Client Hello callbacks with HAVE_SSL_CLIENT_HELLO_CB macro instead of openssl version"). Could be backported in 2.4.
2021-11-18 09:25:16 -05:00
#else /* ! HAVE_SSL_CLIENT_HELLO_CB */
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
/* Sets the SSL ctx of <ssl> to match the advertised server name. Returns a
* warning when no match is found, which implies the default (first) cert
* will keep being used.
*/
BUILD: ssl: fix ssl_sock_switchtx_cbk when no client_hello_cb When building HAProxy with USE_QUIC and libressl 3.6.0, the ssl_sock_switchtx_cbk symbol is not found because libressl does not implement the client_hello_cb. A ssl_sock_switchtx_cbk version for the servername callback is available but wasn't exported correctly.
2022-09-02 09:27:32 -04:00
int ssl_sock_switchctx_cbk(SSL *ssl, int *al, void *priv)
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
{
const char *servername;
const char *wildp = NULL;
MEDIUM: ssl: improve crt-list format to support negation Improve the crt-list file format to allow a rule to negate a certain SNI : <crtfile> [[!]<snifilter> ...] This can be useful when a domain supports a wildcard but you don't want to deliver the wildcard cert for certain specific domains.
2013-05-07 14:20:06 -04:00
struct ebmb_node *node, *n;
BUILD: ssl: fix to build (again) with boringssl Limitations: . disable force-ssl/tls (need more work) should be set earlier with SSL_CTX_new (SSL_CTX_set_ssl_version is removed) . disable generate-certificates (need more work) introduce SSL_NO_GENERATE_CERTIFICATES to disable generate-certificates. Cleanup some #ifdef and type related to boringssl env.
2017-01-13 11:48:18 -05:00
struct bind_conf *s = priv;
MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection This patch changes the default certificate mechanism. Since the beginning of SSL in HAProxy, the default certificate was the first certificate of a bind line. This allowed to fallback on this certificate when no servername extension was sent by the server, or when no SAN nor CN was available in the certificate. When using a multi-certificate bundle (ecdsa+rsa), it was possible to have both certificates as the fallback one, leting openssl chose the right one. This was possible because a multi-certificate bundle was generating a unique SSL_CTX for both certificates. When the haproxy and openssl architecture evolved, we decided to use multiple SSL_CTX for a multi-cert bundle, in order to simplify the code and allow updates over the CLI. However only one default_ctx was allowed, so we lost the ability to chose between ECDSA and RSA for the default certificate. This patch allows to use a '*' filter for a certificate, which allow to lookup between multiple '*' filter, and have one in RSA and another one in ECDSA. It replaces the default_ctx mechanism in the ClientHello callback and use the standard algorithm to look for a default cert and chose between ECDSA and RSA. /!\ This patch breaks the automatic setting of the default certificate, which will be introduce in the next patch. So the first certificate of a bind line won't be used as a defaullt anymore. To use this feature, one could use crt-list with '*' filters: $ cat foo.crtlist foobar.pem.rsa * foobar.pem.ecdsa * In order to test the feature, it's easy to send a request without the servername extension and use ECDSA or RSA compatible ciphers: $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-RSA-AES256-GCM-SHA384 $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-ECDSA-AES256-GCM-SHA384
2024-01-10 08:05:59 -05:00
int default_lookup = 0; /* did we lookup for a default yet? */
MINOR: quic: add QUIC support when no client_hello_cb Add QUIC support to the ssl_sock_switchctx_cbk() variant used only when no client_hello_cb is available. This could be used with libreSSL implementation of QUIC for example. It also works with quictls when HAVE_SSL_CLIENT_HELLO_CB is removed from openss-compat.h
2022-09-07 05:21:34 -04:00
#ifdef USE_QUIC
const uint8_t *extension_data;
size_t extension_len;
struct quic_conn *qc = SSL_get_ex_data(ssl, ssl_qc_app_data_index);
#endif /* USE_QUIC */
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
int i;
(void)al; /* shut gcc stupid warning */
MINOR: quic: add QUIC support when no client_hello_cb Add QUIC support to the ssl_sock_switchctx_cbk() variant used only when no client_hello_cb is available. This could be used with libreSSL implementation of QUIC for example. It also works with quictls when HAVE_SSL_CLIENT_HELLO_CB is removed from openss-compat.h
2022-09-07 05:21:34 -04:00
#ifdef USE_QUIC
if (qc) {
/* Look for the QUIC transport parameters. */
SSL_get_peer_quic_transport_params(ssl, &extension_data, &extension_len);
if (extension_len == 0) {
/* This is not redundant. It we only return 0 without setting
* <*al>, this has as side effect to generate another TLS alert
* which would be set after calling quic_set_tls_alert().
*/
*al = SSL_AD_MISSING_EXTENSION;
quic_set_tls_alert(qc, SSL_AD_MISSING_EXTENSION);
return SSL_TLSEXT_ERR_NOACK;
}
if (!quic_transport_params_store(qc, 0, extension_data,
MEDIUM: quic: Remove qc_conn_finalize() from the ClientHello TLS callbacks This is a bad idea to make the TLS ClientHello callback call qc_conn_finalize(). If this latter fails, this would generate a TLS alert and make the connection send packet whereas it is not functional. But qc_conn_finalize() job was to install the transport parameters sent by the QUIC listener. This installation cannot be done at any time. This must be done after having possibly negotiated the QUIC version and before sending the first Handshake packets. It seems the better moment to do that in when the Handshake TX secrets are derived. This has been found inspecting the ngtcp2 code. Calling SSL_set_quic_transport_params() too late would make the ServerHello to be sent without the transport parameters. The code for the connection update which was done from qc_conn_finalize() has been moved to quic_transport_params_store(). So, this update is done as soon as possible. Add QUIC_FL_CONN_TX_TP_RECEIVED to flag the connection as having received the peer transport parameters. Indeed this is required when the ClientHello message is splitted between packets. Add QUIC_FL_CONN_FINALIZED to protect the connection from calling qc_conn_finalize() more than one time. This latter is called only when the connection has received the transport parameters and after returning from SSL_do_hanshake() which is the function which trigger the TLS ClientHello callback call. Remove the calls to qc_conn_finalize() from from the TLS ClientHello callbacks. Must be backported to 2.6. and 2.7.
2023-02-01 11:56:57 -05:00
extension_data + extension_len))
MINOR: quic: add QUIC support when no client_hello_cb Add QUIC support to the ssl_sock_switchctx_cbk() variant used only when no client_hello_cb is available. This could be used with libreSSL implementation of QUIC for example. It also works with quictls when HAVE_SSL_CLIENT_HELLO_CB is removed from openss-compat.h
2022-09-07 05:21:34 -04:00
return SSL_TLSEXT_ERR_NOACK;
MEDIUM: quic: Remove qc_conn_finalize() from the ClientHello TLS callbacks This is a bad idea to make the TLS ClientHello callback call qc_conn_finalize(). If this latter fails, this would generate a TLS alert and make the connection send packet whereas it is not functional. But qc_conn_finalize() job was to install the transport parameters sent by the QUIC listener. This installation cannot be done at any time. This must be done after having possibly negotiated the QUIC version and before sending the first Handshake packets. It seems the better moment to do that in when the Handshake TX secrets are derived. This has been found inspecting the ngtcp2 code. Calling SSL_set_quic_transport_params() too late would make the ServerHello to be sent without the transport parameters. The code for the connection update which was done from qc_conn_finalize() has been moved to quic_transport_params_store(). So, this update is done as soon as possible. Add QUIC_FL_CONN_TX_TP_RECEIVED to flag the connection as having received the peer transport parameters. Indeed this is required when the ClientHello message is splitted between packets. Add QUIC_FL_CONN_FINALIZED to protect the connection from calling qc_conn_finalize() more than one time. This latter is called only when the connection has received the transport parameters and after returning from SSL_do_hanshake() which is the function which trigger the TLS ClientHello callback call. Remove the calls to qc_conn_finalize() from from the TLS ClientHello callbacks. Must be backported to 2.6. and 2.7.
2023-02-01 11:56:57 -05:00
qc->flags |= QUIC_FL_CONN_TX_TP_RECEIVED;
MINOR: quic: add QUIC support when no client_hello_cb Add QUIC support to the ssl_sock_switchctx_cbk() variant used only when no client_hello_cb is available. This could be used with libreSSL implementation of QUIC for example. It also works with quictls when HAVE_SSL_CLIENT_HELLO_CB is removed from openss-compat.h
2022-09-07 05:21:34 -04:00
}
#endif /* USE_QUIC */
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
servername = SSL_get_servername(ssl, TLSEXT_NAMETYPE_host_name);
MEDIUM: ssl: add bind-option "strict-sni" This new option ensures that there is no possible fallback to a default certificate if the client does not provide an SNI which is explicitly handled by a certificate.
2013-01-24 11:17:15 -05:00
if (!servername) {
BUILD: ssl: fix to build (again) with boringssl Limitations: . disable force-ssl/tls (need more work) should be set earlier with SSL_CTX_new (SSL_CTX_set_ssl_version is removed) . disable generate-certificates (need more work) introduce SSL_NO_GENERATE_CERTIFICATES to disable generate-certificates. Cleanup some #ifdef and type related to boringssl env.
2017-01-13 11:48:18 -05:00
#if (!defined SSL_NO_GENERATE_CERTIFICATES)
CLEANUP: listener: replace bind_conf->generate_cers with BC_O_GENERATE_CERTS The new flag will now replace this boolean variable.
2022-05-20 10:03:18 -04:00
if (s->options & BC_O_GENERATE_CERTS && ssl_sock_generate_certificate_from_conn(s, ssl))
MINOR: ssl: generated certificate is missing in switchctx early callback Openssl 1.1.1 supports switchctx early callback and generated certificate. Generated certificate calls must be available in switchctx early callback.
2017-08-14 05:01:25 -04:00
return SSL_TLSEXT_ERR_OK;
BUILD: ssl: fix to build (again) with boringssl Limitations: . disable force-ssl/tls (need more work) should be set earlier with SSL_CTX_new (SSL_CTX_set_ssl_version is removed) . disable generate-certificates (need more work) introduce SSL_NO_GENERATE_CERTIFICATES to disable generate-certificates. Cleanup some #ifdef and type related to boringssl env.
2017-01-13 11:48:18 -05:00
#endif
BUG/MEDIUM: ssl: in bind line, ssl-options after 'crt' are ignored. Bug introduced with "removes SSL_CTX_set_ssl_version call and cleanup CTX creation": ssl_sock_new_ctx is called before all the bind line is parsed. The fix consists of separating the use of default_ctx as the initialization context of the SSL connection via bind_conf->initial_ctx. Initial_ctx contains all the necessary parameters before performing the selection of the CTX: default_ctx is processed as others ctx without unnecessary parameters.
2017-03-06 09:34:44 -05:00
if (s->strict_sni)
return SSL_TLSEXT_ERR_ALERT_FATAL;
MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection This patch changes the default certificate mechanism. Since the beginning of SSL in HAProxy, the default certificate was the first certificate of a bind line. This allowed to fallback on this certificate when no servername extension was sent by the server, or when no SAN nor CN was available in the certificate. When using a multi-certificate bundle (ecdsa+rsa), it was possible to have both certificates as the fallback one, leting openssl chose the right one. This was possible because a multi-certificate bundle was generating a unique SSL_CTX for both certificates. When the haproxy and openssl architecture evolved, we decided to use multiple SSL_CTX for a multi-cert bundle, in order to simplify the code and allow updates over the CLI. However only one default_ctx was allowed, so we lost the ability to chose between ECDSA and RSA for the default certificate. This patch allows to use a '*' filter for a certificate, which allow to lookup between multiple '*' filter, and have one in RSA and another one in ECDSA. It replaces the default_ctx mechanism in the ClientHello callback and use the standard algorithm to look for a default cert and chose between ECDSA and RSA. /!\ This patch breaks the automatic setting of the default certificate, which will be introduce in the next patch. So the first certificate of a bind line won't be used as a defaullt anymore. To use this feature, one could use crt-list with '*' filters: $ cat foo.crtlist foobar.pem.rsa * foobar.pem.ecdsa * In order to test the feature, it's easy to send a request without the servername extension and use ECDSA or RSA compatible ciphers: $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-RSA-AES256-GCM-SHA384 $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-ECDSA-AES256-GCM-SHA384
2024-01-10 08:05:59 -05:00
/* without servername extension, look for the defaults which is
* defined by an empty servername string */
servername = "";
default_lookup = 1;
MEDIUM: ssl: add bind-option "strict-sni" This new option ensures that there is no possible fallback to a default certificate if the client does not provide an SNI which is explicitly handled by a certificate.
2013-01-24 11:17:15 -05:00
}
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection This patch changes the default certificate mechanism. Since the beginning of SSL in HAProxy, the default certificate was the first certificate of a bind line. This allowed to fallback on this certificate when no servername extension was sent by the server, or when no SAN nor CN was available in the certificate. When using a multi-certificate bundle (ecdsa+rsa), it was possible to have both certificates as the fallback one, leting openssl chose the right one. This was possible because a multi-certificate bundle was generating a unique SSL_CTX for both certificates. When the haproxy and openssl architecture evolved, we decided to use multiple SSL_CTX for a multi-cert bundle, in order to simplify the code and allow updates over the CLI. However only one default_ctx was allowed, so we lost the ability to chose between ECDSA and RSA for the default certificate. This patch allows to use a '*' filter for a certificate, which allow to lookup between multiple '*' filter, and have one in RSA and another one in ECDSA. It replaces the default_ctx mechanism in the ClientHello callback and use the standard algorithm to look for a default cert and chose between ECDSA and RSA. /!\ This patch breaks the automatic setting of the default certificate, which will be introduce in the next patch. So the first certificate of a bind line won't be used as a defaullt anymore. To use this feature, one could use crt-list with '*' filters: $ cat foo.crtlist foobar.pem.rsa * foobar.pem.ecdsa * In order to test the feature, it's easy to send a request without the servername extension and use ECDSA or RSA compatible ciphers: $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-RSA-AES256-GCM-SHA384 $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-ECDSA-AES256-GCM-SHA384
2024-01-10 08:05:59 -05:00
sni_lookup:
MEDIUM: make the trash be a chunk instead of a char * The trash is used everywhere to store the results of temporary strings built out of s(n)printf, or as a storage for a chunk when chunks are needed. Using global.tune.bufsize is not the most convenient thing either. So let's replace trash with a chunk and directly use it as such. We can then use trash.size as the natural way to get its size, and get rid of many intermediary chunks that were previously used. The patch is huge because it touches many areas but it makes the code a lot more clear and even outlines places where trash was used without being that obvious.
2012-10-29 11:51:55 -04:00
for (i = 0; i < trash.size; i++) {
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
if (!servername[i])
break;
BUILD: tree-wide: cast arguments to tolower/toupper to unsigned char NetBSD apparently uses macros for tolower/toupper and complains about the use of char for array subscripts. Let's properly cast all of them to unsigned char where they are used. This is needed to fix issue #729.
2020-07-05 15:46:32 -04:00
trash.area[i] = tolower((unsigned char)servername[i]);
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
if (!wildp && (trash.area[i] == '.'))
wildp = &trash.area[i];
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
}
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
trash.area[i] = 0;
MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection This patch changes the default certificate mechanism. Since the beginning of SSL in HAProxy, the default certificate was the first certificate of a bind line. This allowed to fallback on this certificate when no servername extension was sent by the server, or when no SAN nor CN was available in the certificate. When using a multi-certificate bundle (ecdsa+rsa), it was possible to have both certificates as the fallback one, leting openssl chose the right one. This was possible because a multi-certificate bundle was generating a unique SSL_CTX for both certificates. When the haproxy and openssl architecture evolved, we decided to use multiple SSL_CTX for a multi-cert bundle, in order to simplify the code and allow updates over the CLI. However only one default_ctx was allowed, so we lost the ability to chose between ECDSA and RSA for the default certificate. This patch allows to use a '*' filter for a certificate, which allow to lookup between multiple '*' filter, and have one in RSA and another one in ECDSA. It replaces the default_ctx mechanism in the ClientHello callback and use the standard algorithm to look for a default cert and chose between ECDSA and RSA. /!\ This patch breaks the automatic setting of the default certificate, which will be introduce in the next patch. So the first certificate of a bind line won't be used as a defaullt anymore. To use this feature, one could use crt-list with '*' filters: $ cat foo.crtlist foobar.pem.rsa * foobar.pem.ecdsa * In order to test the feature, it's easy to send a request without the servername extension and use ECDSA or RSA compatible ciphers: $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-RSA-AES256-GCM-SHA384 $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-ECDSA-AES256-GCM-SHA384
2024-01-10 08:05:59 -05:00
if(!*trash.area) /* handle the default which in wildcard tree */
wildp = trash.area;
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
MEDIUM: ssl/cli: 'set ssl cert' updates a certificate from the CLI $ echo -e "set ssl cert certificate.pem <<\n$(cat certificate2.pem)\n" | \ socat stdio /var/run/haproxy.stat Certificate updated! The operation is locked at the ckch level with a HA_SPINLOCK_T which prevents the ckch architecture (ckch_store, ckch_inst..) to be modified at the same time. So you can't do a certificate update at the same time from multiple CLI connections. SNI trees are also locked with a HA_RWLOCK_T so reading operations are locked only during a certificate update. Bundles are supported but you need to update each file (.rsa|ecdsa|.dsa) independently. If a file is used in the configuration as a bundle AND as a unique certificate, both will be updated. Bundles, directories and crt-list are supported, however filters in crt-list are currently unsupported. The code tries to allocate every SNIs and certificate instances first, so it can rollback the operation if that was unsuccessful. If you have too much instances of the certificate (at least 20000 in my tests on my laptop), the function can take too much time and be killed by the watchdog. This will be fixed later. Also with too much certificates it's possible that socat exits before the end of the generation without displaying a message, consider changing the socat timeout in this case (-t2 for example). The size of the certificate is currently limited by the maximum size of a payload, that must fit in a buffer.
2019-09-19 11:12:49 -04:00
HA_RWLOCK_RDLOCK(SNI_LOCK, &s->sni_lock);
BUG/MINOR: ssl: fix crt-list neg filter for openssl < 1.1.1 Certificate selection in client_hello_cb (openssl >= 1.1.1) correctly handles crt-list neg filter. Certificate selection for openssl < 1.1.1 has not been touched for a while: crt-list neg filter is not the same than his counterpart and is wrong. Fix it to mimic the same behavior has is counterpart. It should be backported as far as 1.6.
2019-11-04 09:49:46 -05:00
node = NULL;
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
/* lookup in full qualified names */
BUG/MINOR: ssl: fix crt-list neg filter for openssl < 1.1.1 Certificate selection in client_hello_cb (openssl >= 1.1.1) correctly handles crt-list neg filter. Certificate selection for openssl < 1.1.1 has not been touched for a while: crt-list neg filter is not the same than his counterpart and is wrong. Fix it to mimic the same behavior has is counterpart. It should be backported as far as 1.6.
2019-11-04 09:49:46 -05:00
for (n = ebst_lookup(&s->sni_ctx, trash.area); n; n = ebmb_next_dup(n)) {
/* lookup a not neg filter */
MEDIUM: ssl: improve crt-list format to support negation Improve the crt-list file format to allow a rule to negate a certain SNI : <crtfile> [[!]<snifilter> ...] This can be useful when a domain supports a wildcard but you don't want to deliver the wildcard cert for certain specific domains.
2013-05-07 14:20:06 -04:00
if (!container_of(n, struct sni_ctx, name)->neg) {
node = n;
break;
MEDIUM: ssl: add bind-option "strict-sni" This new option ensures that there is no possible fallback to a default certificate if the client does not provide an SNI which is explicitly handled by a certificate.
2013-01-24 11:17:15 -05:00
}
MEDIUM: ssl: improve crt-list format to support negation Improve the crt-list file format to allow a rule to negate a certain SNI : <crtfile> [[!]<snifilter> ...] This can be useful when a domain supports a wildcard but you don't want to deliver the wildcard cert for certain specific domains.
2013-05-07 14:20:06 -04:00
}
if (!node && wildp) {
/* lookup in wildcards names */
BUG/MINOR: ssl: fix crt-list neg filter for openssl < 1.1.1 Certificate selection in client_hello_cb (openssl >= 1.1.1) correctly handles crt-list neg filter. Certificate selection for openssl < 1.1.1 has not been touched for a while: crt-list neg filter is not the same than his counterpart and is wrong. Fix it to mimic the same behavior has is counterpart. It should be backported as far as 1.6.
2019-11-04 09:49:46 -05:00
for (n = ebst_lookup(&s->sni_w_ctx, wildp); n; n = ebmb_next_dup(n)) {
/* lookup a not neg filter */
if (!container_of(n, struct sni_ctx, name)->neg) {
node = n;
break;
}
}
MEDIUM: ssl: improve crt-list format to support negation Improve the crt-list file format to allow a rule to negate a certain SNI : <crtfile> [[!]<snifilter> ...] This can be useful when a domain supports a wildcard but you don't want to deliver the wildcard cert for certain specific domains.
2013-05-07 14:20:06 -04:00
}
BUG/MINOR: ssl: fix crt-list neg filter for openssl < 1.1.1 Certificate selection in client_hello_cb (openssl >= 1.1.1) correctly handles crt-list neg filter. Certificate selection for openssl < 1.1.1 has not been touched for a while: crt-list neg filter is not the same than his counterpart and is wrong. Fix it to mimic the same behavior has is counterpart. It should be backported as far as 1.6.
2019-11-04 09:49:46 -05:00
if (!node) {
BUILD: ssl: fix to build (again) with boringssl Limitations: . disable force-ssl/tls (need more work) should be set earlier with SSL_CTX_new (SSL_CTX_set_ssl_version is removed) . disable generate-certificates (need more work) introduce SSL_NO_GENERATE_CERTIFICATES to disable generate-certificates. Cleanup some #ifdef and type related to boringssl env.
2017-01-13 11:48:18 -05:00
#if (!defined SSL_NO_GENERATE_CERTIFICATES)
CLEANUP: listener: replace bind_conf->generate_cers with BC_O_GENERATE_CERTS The new flag will now replace this boolean variable.
2022-05-20 10:03:18 -04:00
if (s->options & BC_O_GENERATE_CERTS && ssl_sock_generate_certificate(servername, s, ssl)) {
MINOR: ssl: generated certificate is missing in switchctx early callback Openssl 1.1.1 supports switchctx early callback and generated certificate. Generated certificate calls must be available in switchctx early callback.
2017-08-14 05:01:25 -04:00
/* switch ctx done in ssl_sock_generate_certificate */
MEDIUM: ssl/cli: 'set ssl cert' updates a certificate from the CLI $ echo -e "set ssl cert certificate.pem <<\n$(cat certificate2.pem)\n" | \ socat stdio /var/run/haproxy.stat Certificate updated! The operation is locked at the ckch level with a HA_SPINLOCK_T which prevents the ckch architecture (ckch_store, ckch_inst..) to be modified at the same time. So you can't do a certificate update at the same time from multiple CLI connections. SNI trees are also locked with a HA_RWLOCK_T so reading operations are locked only during a certificate update. Bundles are supported but you need to update each file (.rsa|ecdsa|.dsa) independently. If a file is used in the configuration as a bundle AND as a unique certificate, both will be updated. Bundles, directories and crt-list are supported, however filters in crt-list are currently unsupported. The code tries to allocate every SNIs and certificate instances first, so it can rollback the operation if that was unsuccessful. If you have too much instances of the certificate (at least 20000 in my tests on my laptop), the function can take too much time and be killed by the watchdog. This will be fixed later. Also with too much certificates it's possible that socat exits before the end of the generation without displaying a message, consider changing the socat timeout in this case (-t2 for example). The size of the certificate is currently limited by the maximum size of a payload, that must fit in a buffer.
2019-09-19 11:12:49 -04:00
HA_RWLOCK_RDUNLOCK(SNI_LOCK, &s->sni_lock);
MEDIUM: ssl: Add options to forge SSL certificates With this patch, it is possible to configure HAProxy to forge the SSL certificate sent to a client using the SNI servername. We do it in the SNI callback. To enable this feature, you must pass following BIND options: * ca-sign-file <FILE> : This is the PEM file containing the CA certitifacte and the CA private key to create and sign server's certificates. * (optionally) ca-sign-pass <PASS>: This is the CA private key passphrase, if any. * generate-certificates: Enable the dynamic generation of certificates for a listener. Because generating certificates is expensive, there is a LRU cache to store them. Its size can be customized by setting the global parameter 'tune.ssl.ssl-ctx-cache-size'.
2015-06-09 11:29:50 -04:00
return SSL_TLSEXT_ERR_OK;
}
BUILD: ssl: fix to build (again) with boringssl Limitations: . disable force-ssl/tls (need more work) should be set earlier with SSL_CTX_new (SSL_CTX_set_ssl_version is removed) . disable generate-certificates (need more work) introduce SSL_NO_GENERATE_CERTIFICATES to disable generate-certificates. Cleanup some #ifdef and type related to boringssl env.
2017-01-13 11:48:18 -05:00
#endif
MINOR: ssl/cli: replace the default_ctx during 'commit ssl cert' If the SSL_CTX of a previous instance (ckch_inst) was used as a default_ctx, replace the default_ctx of the bind_conf by the first SSL_CTX inserted in the SNI tree. Use the RWLOCK of the sni tree to handle the change of the default_ctx.
2019-11-04 11:56:13 -05:00
HA_RWLOCK_RDUNLOCK(SNI_LOCK, &s->sni_lock);
MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection This patch changes the default certificate mechanism. Since the beginning of SSL in HAProxy, the default certificate was the first certificate of a bind line. This allowed to fallback on this certificate when no servername extension was sent by the server, or when no SAN nor CN was available in the certificate. When using a multi-certificate bundle (ecdsa+rsa), it was possible to have both certificates as the fallback one, leting openssl chose the right one. This was possible because a multi-certificate bundle was generating a unique SSL_CTX for both certificates. When the haproxy and openssl architecture evolved, we decided to use multiple SSL_CTX for a multi-cert bundle, in order to simplify the code and allow updates over the CLI. However only one default_ctx was allowed, so we lost the ability to chose between ECDSA and RSA for the default certificate. This patch allows to use a '*' filter for a certificate, which allow to lookup between multiple '*' filter, and have one in RSA and another one in ECDSA. It replaces the default_ctx mechanism in the ClientHello callback and use the standard algorithm to look for a default cert and chose between ECDSA and RSA. /!\ This patch breaks the automatic setting of the default certificate, which will be introduce in the next patch. So the first certificate of a bind line won't be used as a defaullt anymore. To use this feature, one could use crt-list with '*' filters: $ cat foo.crtlist foobar.pem.rsa * foobar.pem.ecdsa * In order to test the feature, it's easy to send a request without the servername extension and use ECDSA or RSA compatible ciphers: $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-RSA-AES256-GCM-SHA384 $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-ECDSA-AES256-GCM-SHA384
2024-01-10 08:05:59 -05:00
if (!s->strict_sni && !default_lookup) {
/* we didn't find a SNI, and we didn't look for a default
* look again to find a matching default cert */
servername = "";
default_lookup = 1;
goto sni_lookup;
}
return SSL_TLSEXT_ERR_ALERT_FATAL;
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
}
MINOR: ssl_sock: Early data disabled during SSL_CTX switching (aws-lc) This patch impacts only haproxy when built against aws-lc TLS stack (OPENSSL_IS_AWSLC). During the SSL_CTX switching from ssl_sock_switchctx_cbk() callback, ssl_sock_switchctx_set() is called. This latter calls SSL_set_SSL_CTX() whose aims is to change the SSL_CTX attached o an SSL object (TLS session). But the aws-lc (or boringssl) implementation of this function copy the "early data enabled" setting value (boolean) coming with the SSL_CTX object into the SSL object. So, if not set in the SSL_CTX object this setting disabled the one which has been set by configuration into the SSL object (see qc_set_quic_early_data_enabled(), it calls SSL_set_early_data_enabled() with an SSL object as parameter). Fix this enabling the "early data enabled" setting into the SSL_CTX before setting this latter into the SSL object. This patch is required to make QUIC 0-RTT work with haproxy built against aws-lc. Note that, this patch should also help in early data support for TCP connections.
2024-01-23 08:45:25 -05:00
#if defined(OPENSSL_IS_AWSLC)
/* Note that ssl_sock_switchctx_set() calls SSL_set_SSL_CTX() which propagates the
* "early data enabled" setting from the SSL_CTX object to the SSL objects.
* So enable early data for this SSL_CTX context if configured.
*/
if (s->ssl_conf.early_data)
SSL_CTX_set_early_data_enabled(container_of(node, struct sni_ctx, name)->ctx, 1);
#endif
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
/* switch ctx */
BUG/MEDIUM: ssl: fix verify/ca-file per certificate SSL verify and client_CA inherits from the initial ctx (default_ctx). When a certificate is found, the SSL connection environment must be replaced by the certificate configuration (via SSL_set_verify and SSL_set_client_CA_list).
2017-03-01 12:54:56 -05:00
ssl_sock_switchctx_set(ssl, container_of(node, struct sni_ctx, name)->ctx);
MEDIUM: ssl/cli: 'set ssl cert' updates a certificate from the CLI $ echo -e "set ssl cert certificate.pem <<\n$(cat certificate2.pem)\n" | \ socat stdio /var/run/haproxy.stat Certificate updated! The operation is locked at the ckch level with a HA_SPINLOCK_T which prevents the ckch architecture (ckch_store, ckch_inst..) to be modified at the same time. So you can't do a certificate update at the same time from multiple CLI connections. SNI trees are also locked with a HA_RWLOCK_T so reading operations are locked only during a certificate update. Bundles are supported but you need to update each file (.rsa|ecdsa|.dsa) independently. If a file is used in the configuration as a bundle AND as a unique certificate, both will be updated. Bundles, directories and crt-list are supported, however filters in crt-list are currently unsupported. The code tries to allocate every SNIs and certificate instances first, so it can rollback the operation if that was unsuccessful. If you have too much instances of the certificate (at least 20000 in my tests on my laptop), the function can take too much time and be killed by the watchdog. This will be fixed later. Also with too much certificates it's possible that socat exits before the end of the generation without displaying a message, consider changing the socat timeout in this case (-t2 for example). The size of the certificate is currently limited by the maximum size of a payload, that must fit in a buffer.
2019-09-19 11:12:49 -04:00
HA_RWLOCK_RDUNLOCK(SNI_LOCK, &s->sni_lock);
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
return SSL_TLSEXT_ERR_OK;
}
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
#endif /* (!) OPENSSL_IS_BORINGSSL */
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
MINOR: ssl: activate the certificate selection callback for WolfSSL The PR which allows to chose a certificate depending on the ciphers and the signature algorithms was merged in WolfSSL. Let's activate this code. This could be backported in 2.9 only when the next WolfSSL release is available (5.6.5). It will also need a check on the version.
2023-12-08 05:33:03 -05:00
#if defined(USE_OPENSSL_WOLFSSL)
MEDIUM: ssl: implement rsa/ecdsa selection with WolfSSL PR https://github.com/wolfSSL/wolfssl/pull/6963 implements primitives to extract ciphers and algorithm signatures. It allows to chose a certificate depending on the sigals and ciphers presented by the client (RSA or ECDSA). Since WolfSSL does not implement the clienthello callback, the patch uses the certificate callback (SSL_CTX_set_cert_cb()) The callback is inspired by our clienthello callback, however the extraction of client ciphers and sigalgs is simpler, wolfSSL_get_sigalg_info() and wolfSSL_get_ciphersuite_info() are used. This is not enabled by default yet as the PR was not merged.
2023-11-16 12:16:53 -05:00
/* This implement the equivalent of the clientHello Callback but using the cert_cb.
* WolfSSL is able to extract the sigalgs and ciphers of the client byt using the API
* provided in https://github.com/wolfSSL/wolfssl/pull/6963
*
* Not activated for now since the PR is not merged.
*/
static int ssl_sock_switchctx_wolfSSL_cbk(WOLFSSL* ssl, void* arg)
{
struct bind_conf *s = arg;
int has_rsa_sig = 0, has_ecdsa_sig = 0;
const char *servername;
MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection This patch changes the default certificate mechanism. Since the beginning of SSL in HAProxy, the default certificate was the first certificate of a bind line. This allowed to fallback on this certificate when no servername extension was sent by the server, or when no SAN nor CN was available in the certificate. When using a multi-certificate bundle (ecdsa+rsa), it was possible to have both certificates as the fallback one, leting openssl chose the right one. This was possible because a multi-certificate bundle was generating a unique SSL_CTX for both certificates. When the haproxy and openssl architecture evolved, we decided to use multiple SSL_CTX for a multi-cert bundle, in order to simplify the code and allow updates over the CLI. However only one default_ctx was allowed, so we lost the ability to chose between ECDSA and RSA for the default certificate. This patch allows to use a '*' filter for a certificate, which allow to lookup between multiple '*' filter, and have one in RSA and another one in ECDSA. It replaces the default_ctx mechanism in the ClientHello callback and use the standard algorithm to look for a default cert and chose between ECDSA and RSA. /!\ This patch breaks the automatic setting of the default certificate, which will be introduce in the next patch. So the first certificate of a bind line won't be used as a defaullt anymore. To use this feature, one could use crt-list with '*' filters: $ cat foo.crtlist foobar.pem.rsa * foobar.pem.ecdsa * In order to test the feature, it's easy to send a request without the servername extension and use ECDSA or RSA compatible ciphers: $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-RSA-AES256-GCM-SHA384 $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-ECDSA-AES256-GCM-SHA384
2024-01-10 08:05:59 -05:00
int default_lookup = 0;
MINOR: ssl: move certificate selection in a dedicate function The certificate selection used in the WolfSSL cert_cb and in the OpenSSL clienthello callback is the same, the function was duplicate to achieve the same. This patch move the selection code to a common function called ssl_sock_chose_sni_ctx(). The servername string is still lowered in the callback, however the search for the first dot in the string (wildp) is done in ssl_sock_chose_sni_ctx() The function uses the same certificate selection algorithm as before, it needs to know if you need rsa or ecdsa, the bind_conf to achieve the lookup, and the servername string. This patch moves the code for WolSSL only.
2023-11-23 10:35:52 -05:00
struct sni_ctx *sni_ctx;
MEDIUM: ssl: implement rsa/ecdsa selection with WolfSSL PR https://github.com/wolfSSL/wolfssl/pull/6963 implements primitives to extract ciphers and algorithm signatures. It allows to chose a certificate depending on the sigals and ciphers presented by the client (RSA or ECDSA). Since WolfSSL does not implement the clienthello callback, the patch uses the certificate callback (SSL_CTX_set_cert_cb()) The callback is inspired by our clienthello callback, however the extraction of client ciphers and sigalgs is simpler, wolfSSL_get_sigalg_info() and wolfSSL_get_ciphersuite_info() are used. This is not enabled by default yet as the PR was not merged.
2023-11-16 12:16:53 -05:00
int i;
if (!s) {
/* must never happen */
ABORT_NOW();
return 0;
}
servername = SSL_get_servername(ssl, TLSEXT_NAMETYPE_host_name);
if (!servername) {
MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection This patch changes the default certificate mechanism. Since the beginning of SSL in HAProxy, the default certificate was the first certificate of a bind line. This allowed to fallback on this certificate when no servername extension was sent by the server, or when no SAN nor CN was available in the certificate. When using a multi-certificate bundle (ecdsa+rsa), it was possible to have both certificates as the fallback one, leting openssl chose the right one. This was possible because a multi-certificate bundle was generating a unique SSL_CTX for both certificates. When the haproxy and openssl architecture evolved, we decided to use multiple SSL_CTX for a multi-cert bundle, in order to simplify the code and allow updates over the CLI. However only one default_ctx was allowed, so we lost the ability to chose between ECDSA and RSA for the default certificate. This patch allows to use a '*' filter for a certificate, which allow to lookup between multiple '*' filter, and have one in RSA and another one in ECDSA. It replaces the default_ctx mechanism in the ClientHello callback and use the standard algorithm to look for a default cert and chose between ECDSA and RSA. /!\ This patch breaks the automatic setting of the default certificate, which will be introduce in the next patch. So the first certificate of a bind line won't be used as a defaullt anymore. To use this feature, one could use crt-list with '*' filters: $ cat foo.crtlist foobar.pem.rsa * foobar.pem.ecdsa * In order to test the feature, it's easy to send a request without the servername extension and use ECDSA or RSA compatible ciphers: $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-RSA-AES256-GCM-SHA384 $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-ECDSA-AES256-GCM-SHA384
2024-01-10 08:05:59 -05:00
if (s->strict_sni)
goto abort;
/* without servername extension, look for the defaults which is
* defined by an empty servername string */
servername = "";
default_lookup = 1;
MEDIUM: ssl: implement rsa/ecdsa selection with WolfSSL PR https://github.com/wolfSSL/wolfssl/pull/6963 implements primitives to extract ciphers and algorithm signatures. It allows to chose a certificate depending on the sigals and ciphers presented by the client (RSA or ECDSA). Since WolfSSL does not implement the clienthello callback, the patch uses the certificate callback (SSL_CTX_set_cert_cb()) The callback is inspired by our clienthello callback, however the extraction of client ciphers and sigalgs is simpler, wolfSSL_get_sigalg_info() and wolfSSL_get_ciphersuite_info() are used. This is not enabled by default yet as the PR was not merged.
2023-11-16 12:16:53 -05:00
}
/* extract sigalgs and ciphers */
{
const byte* suites = NULL;
word16 suiteSz = 0;
const byte* hashSigAlgo = NULL;
word16 hashSigAlgoSz = 0;
word16 idx = 0;
wolfSSL_get_client_suites_sigalgs(ssl, &suites, &suiteSz, &hashSigAlgo, &hashSigAlgoSz);
if (suites == NULL || suiteSz == 0 || hashSigAlgo == NULL || hashSigAlgoSz == 0)
return 0;
if (SSL_version(ssl) != TLS1_3_VERSION) {
for (idx = 0; idx < suiteSz; idx += 2) {
WOLFSSL_CIPHERSUITE_INFO info;
info = wolfSSL_get_ciphersuite_info(suites[idx], suites[idx+1]);
if (info.rsaAuth)
has_rsa_sig = 1;
else if (info.eccAuth)
has_ecdsa_sig = 1;
}
}
if (hashSigAlgoSz > 0) {
/* sigalgs extension takes precedence over ciphersuites */
has_ecdsa_sig = 0;
has_rsa_sig = 0;
}
for (idx = 0; idx < hashSigAlgoSz; idx += 2) {
BUILD: ssl: update types in wolfssl cert selection callback The types have changed in the PR for the wolfSSL_get_sigalg_info() function, let's update them. Must be backported in 2.9.
2023-12-08 05:55:15 -05:00
int hashAlgo;
int sigAlgo;
MEDIUM: ssl: implement rsa/ecdsa selection with WolfSSL PR https://github.com/wolfSSL/wolfssl/pull/6963 implements primitives to extract ciphers and algorithm signatures. It allows to chose a certificate depending on the sigals and ciphers presented by the client (RSA or ECDSA). Since WolfSSL does not implement the clienthello callback, the patch uses the certificate callback (SSL_CTX_set_cert_cb()) The callback is inspired by our clienthello callback, however the extraction of client ciphers and sigalgs is simpler, wolfSSL_get_sigalg_info() and wolfSSL_get_ciphersuite_info() are used. This is not enabled by default yet as the PR was not merged.
2023-11-16 12:16:53 -05:00
wolfSSL_get_sigalg_info(hashSigAlgo[idx+0], hashSigAlgo[idx+1], &hashAlgo, &sigAlgo);
if (sigAlgo == RSAk || sigAlgo == RSAPSSk)
has_rsa_sig = 1;
else if (sigAlgo == ECDSAk)
has_ecdsa_sig = 1;
}
}
MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection This patch changes the default certificate mechanism. Since the beginning of SSL in HAProxy, the default certificate was the first certificate of a bind line. This allowed to fallback on this certificate when no servername extension was sent by the server, or when no SAN nor CN was available in the certificate. When using a multi-certificate bundle (ecdsa+rsa), it was possible to have both certificates as the fallback one, leting openssl chose the right one. This was possible because a multi-certificate bundle was generating a unique SSL_CTX for both certificates. When the haproxy and openssl architecture evolved, we decided to use multiple SSL_CTX for a multi-cert bundle, in order to simplify the code and allow updates over the CLI. However only one default_ctx was allowed, so we lost the ability to chose between ECDSA and RSA for the default certificate. This patch allows to use a '*' filter for a certificate, which allow to lookup between multiple '*' filter, and have one in RSA and another one in ECDSA. It replaces the default_ctx mechanism in the ClientHello callback and use the standard algorithm to look for a default cert and chose between ECDSA and RSA. /!\ This patch breaks the automatic setting of the default certificate, which will be introduce in the next patch. So the first certificate of a bind line won't be used as a defaullt anymore. To use this feature, one could use crt-list with '*' filters: $ cat foo.crtlist foobar.pem.rsa * foobar.pem.ecdsa * In order to test the feature, it's easy to send a request without the servername extension and use ECDSA or RSA compatible ciphers: $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-RSA-AES256-GCM-SHA384 $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-ECDSA-AES256-GCM-SHA384
2024-01-10 08:05:59 -05:00
sni_lookup:
MINOR: ssl: move certificate selection in a dedicate function The certificate selection used in the WolfSSL cert_cb and in the OpenSSL clienthello callback is the same, the function was duplicate to achieve the same. This patch move the selection code to a common function called ssl_sock_chose_sni_ctx(). The servername string is still lowered in the callback, however the search for the first dot in the string (wildp) is done in ssl_sock_chose_sni_ctx() The function uses the same certificate selection algorithm as before, it needs to know if you need rsa or ecdsa, the bind_conf to achieve the lookup, and the servername string. This patch moves the code for WolSSL only.
2023-11-23 10:35:52 -05:00
/* we need to transform this into a NULL-ended string in lowecase */
for (i = 0; i < trash.size && servername[i] != '\0'; i++)
trash.area[i] = tolower(servername[i]);
MEDIUM: ssl: implement rsa/ecdsa selection with WolfSSL PR https://github.com/wolfSSL/wolfssl/pull/6963 implements primitives to extract ciphers and algorithm signatures. It allows to chose a certificate depending on the sigals and ciphers presented by the client (RSA or ECDSA). Since WolfSSL does not implement the clienthello callback, the patch uses the certificate callback (SSL_CTX_set_cert_cb()) The callback is inspired by our clienthello callback, however the extraction of client ciphers and sigalgs is simpler, wolfSSL_get_sigalg_info() and wolfSSL_get_ciphersuite_info() are used. This is not enabled by default yet as the PR was not merged.
2023-11-16 12:16:53 -05:00
trash.area[i] = 0;
MINOR: ssl: replace 'trash.area' by 'servername' in ssl_sock_switchctx_cbk() Replace 'trash.area' by 'servername' for more readibility.
2023-11-24 13:20:28 -05:00
servername = trash.area;
MEDIUM: ssl: implement rsa/ecdsa selection with WolfSSL PR https://github.com/wolfSSL/wolfssl/pull/6963 implements primitives to extract ciphers and algorithm signatures. It allows to chose a certificate depending on the sigals and ciphers presented by the client (RSA or ECDSA). Since WolfSSL does not implement the clienthello callback, the patch uses the certificate callback (SSL_CTX_set_cert_cb()) The callback is inspired by our clienthello callback, however the extraction of client ciphers and sigalgs is simpler, wolfSSL_get_sigalg_info() and wolfSSL_get_ciphersuite_info() are used. This is not enabled by default yet as the PR was not merged.
2023-11-16 12:16:53 -05:00
HA_RWLOCK_RDLOCK(SNI_LOCK, &s->sni_lock);
MINOR: ssl: move certificate selection in a dedicate function The certificate selection used in the WolfSSL cert_cb and in the OpenSSL clienthello callback is the same, the function was duplicate to achieve the same. This patch move the selection code to a common function called ssl_sock_chose_sni_ctx(). The servername string is still lowered in the callback, however the search for the first dot in the string (wildp) is done in ssl_sock_chose_sni_ctx() The function uses the same certificate selection algorithm as before, it needs to know if you need rsa or ecdsa, the bind_conf to achieve the lookup, and the servername string. This patch moves the code for WolSSL only.
2023-11-23 10:35:52 -05:00
sni_ctx = ssl_sock_chose_sni_ctx(s, servername, has_rsa_sig, has_ecdsa_sig);
if (sni_ctx) {
MEDIUM: ssl: implement rsa/ecdsa selection with WolfSSL PR https://github.com/wolfSSL/wolfssl/pull/6963 implements primitives to extract ciphers and algorithm signatures. It allows to chose a certificate depending on the sigals and ciphers presented by the client (RSA or ECDSA). Since WolfSSL does not implement the clienthello callback, the patch uses the certificate callback (SSL_CTX_set_cert_cb()) The callback is inspired by our clienthello callback, however the extraction of client ciphers and sigalgs is simpler, wolfSSL_get_sigalg_info() and wolfSSL_get_ciphersuite_info() are used. This is not enabled by default yet as the PR was not merged.
2023-11-16 12:16:53 -05:00
/* switch ctx */
MINOR: ssl: move certificate selection in a dedicate function The certificate selection used in the WolfSSL cert_cb and in the OpenSSL clienthello callback is the same, the function was duplicate to achieve the same. This patch move the selection code to a common function called ssl_sock_chose_sni_ctx(). The servername string is still lowered in the callback, however the search for the first dot in the string (wildp) is done in ssl_sock_chose_sni_ctx() The function uses the same certificate selection algorithm as before, it needs to know if you need rsa or ecdsa, the bind_conf to achieve the lookup, and the servername string. This patch moves the code for WolSSL only.
2023-11-23 10:35:52 -05:00
struct ssl_bind_conf *conf = sni_ctx->conf;
ssl_sock_switchctx_set(ssl, sni_ctx->ctx);
MEDIUM: ssl: implement rsa/ecdsa selection with WolfSSL PR https://github.com/wolfSSL/wolfssl/pull/6963 implements primitives to extract ciphers and algorithm signatures. It allows to chose a certificate depending on the sigals and ciphers presented by the client (RSA or ECDSA). Since WolfSSL does not implement the clienthello callback, the patch uses the certificate callback (SSL_CTX_set_cert_cb()) The callback is inspired by our clienthello callback, however the extraction of client ciphers and sigalgs is simpler, wolfSSL_get_sigalg_info() and wolfSSL_get_ciphersuite_info() are used. This is not enabled by default yet as the PR was not merged.
2023-11-16 12:16:53 -05:00
if (conf) {
methodVersions[conf->ssl_methods.min].ssl_set_version(ssl, SET_MIN);
methodVersions[conf->ssl_methods.max].ssl_set_version(ssl, SET_MAX);
}
HA_RWLOCK_RDUNLOCK(SNI_LOCK, &s->sni_lock);
goto allow_early;
}
HA_RWLOCK_RDUNLOCK(SNI_LOCK, &s->sni_lock);
MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection This patch changes the default certificate mechanism. Since the beginning of SSL in HAProxy, the default certificate was the first certificate of a bind line. This allowed to fallback on this certificate when no servername extension was sent by the server, or when no SAN nor CN was available in the certificate. When using a multi-certificate bundle (ecdsa+rsa), it was possible to have both certificates as the fallback one, leting openssl chose the right one. This was possible because a multi-certificate bundle was generating a unique SSL_CTX for both certificates. When the haproxy and openssl architecture evolved, we decided to use multiple SSL_CTX for a multi-cert bundle, in order to simplify the code and allow updates over the CLI. However only one default_ctx was allowed, so we lost the ability to chose between ECDSA and RSA for the default certificate. This patch allows to use a '*' filter for a certificate, which allow to lookup between multiple '*' filter, and have one in RSA and another one in ECDSA. It replaces the default_ctx mechanism in the ClientHello callback and use the standard algorithm to look for a default cert and chose between ECDSA and RSA. /!\ This patch breaks the automatic setting of the default certificate, which will be introduce in the next patch. So the first certificate of a bind line won't be used as a defaullt anymore. To use this feature, one could use crt-list with '*' filters: $ cat foo.crtlist foobar.pem.rsa * foobar.pem.ecdsa * In order to test the feature, it's easy to send a request without the servername extension and use ECDSA or RSA compatible ciphers: $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-RSA-AES256-GCM-SHA384 $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-ECDSA-AES256-GCM-SHA384
2024-01-10 08:05:59 -05:00
if (!s->strict_sni && !default_lookup) {
/* we didn't find a SNI, and we didn't look for a default
* look again to find a matching default cert */
servername = "";
default_lookup = 1;
goto sni_lookup;
MEDIUM: ssl: implement rsa/ecdsa selection with WolfSSL PR https://github.com/wolfSSL/wolfssl/pull/6963 implements primitives to extract ciphers and algorithm signatures. It allows to chose a certificate depending on the sigals and ciphers presented by the client (RSA or ECDSA). Since WolfSSL does not implement the clienthello callback, the patch uses the certificate callback (SSL_CTX_set_cert_cb()) The callback is inspired by our clienthello callback, however the extraction of client ciphers and sigalgs is simpler, wolfSSL_get_sigalg_info() and wolfSSL_get_ciphersuite_info() are used. This is not enabled by default yet as the PR was not merged.
2023-11-16 12:16:53 -05:00
}
/* We are about to raise an handshake error so the servername extension
* callback will never be called and the SNI will never be stored in the
* SSL context. In order for the ssl_fc_sni sample fetch to still work
* in such a case, we store the SNI ourselves as an ex_data information
* in the SSL context.
*/
{
char *client_sni = pool_alloc(ssl_sock_client_sni_pool);
if (client_sni) {
MINOR: ssl: replace 'trash.area' by 'servername' in ssl_sock_switchctx_cbk() Replace 'trash.area' by 'servername' for more readibility.
2023-11-24 13:20:28 -05:00
strncpy(client_sni, servername, TLSEXT_MAXLEN_host_name);
MEDIUM: ssl: implement rsa/ecdsa selection with WolfSSL PR https://github.com/wolfSSL/wolfssl/pull/6963 implements primitives to extract ciphers and algorithm signatures. It allows to chose a certificate depending on the sigals and ciphers presented by the client (RSA or ECDSA). Since WolfSSL does not implement the clienthello callback, the patch uses the certificate callback (SSL_CTX_set_cert_cb()) The callback is inspired by our clienthello callback, however the extraction of client ciphers and sigalgs is simpler, wolfSSL_get_sigalg_info() and wolfSSL_get_ciphersuite_info() are used. This is not enabled by default yet as the PR was not merged.
2023-11-16 12:16:53 -05:00
client_sni[TLSEXT_MAXLEN_host_name] = '\0';
SSL_set_ex_data(ssl, ssl_client_sni_index, client_sni);
}
}
/* other cases fallback on abort, if strict-sni is set but no node was found */
abort:
/* abort handshake (was SSL_TLSEXT_ERR_ALERT_FATAL) */
return 0;
allow_early:
return 1;
}
#endif
MINOR: ssl: try to load Diffie-Hellman parameters from cert file Feature is disabled if openssl compiled with OPENSSL_NO_DH.
2012-09-20 10:19:02 -04:00
#ifndef OPENSSL_NO_DH
MEDIUM: ssl: Add the option to use standardized DH parameters >= 1024 bits When no static DH parameters are specified, this patch makes haproxy use standardized (rfc 2409 / rfc 3526) DH parameters with prime lenghts of 1024, 2048, 4096 or 8192 bits for DHE key exchange. The size of the temporary/ephemeral DH key is computed as the minimum of the RSA/DSA server key size and the value of a new option named tune.ssl.default-dh-param.
2014-06-12 08:58:40 -04:00
MINOR: ssl: Add ssl_new_dh_fromdata helper function Starting from OpenSSLv3, the DH_set0_pqg function is deprecated and the use of DH objects directly is advised against so this new helper function will be used to convert our hard-coded DH parameters into an EVP_PKEY. It relies on the new OSSL_PARAM mechanism, as described in the EVP_PKEY-DH manpage.
2022-02-11 06:04:52 -05:00
static inline HASSL_DH *ssl_new_dh_fromdata(BIGNUM *p, BIGNUM *g)
{
#if (HA_OPENSSL_VERSION_NUMBER >= 0x3000000fL)
OSSL_PARAM_BLD *tmpl = NULL;
OSSL_PARAM *params = NULL;
EVP_PKEY_CTX *ctx = NULL;
EVP_PKEY *pkey = NULL;
if ((tmpl = OSSL_PARAM_BLD_new()) == NULL
|| !OSSL_PARAM_BLD_push_BN(tmpl, OSSL_PKEY_PARAM_FFC_P, p)
|| !OSSL_PARAM_BLD_push_BN(tmpl, OSSL_PKEY_PARAM_FFC_G, g)
|| (params = OSSL_PARAM_BLD_to_param(tmpl)) == NULL) {
goto end;
}
ctx = EVP_PKEY_CTX_new_from_name(NULL, "DH", NULL);
if (ctx == NULL
|| !EVP_PKEY_fromdata_init(ctx)
|| !EVP_PKEY_fromdata(ctx, &pkey, EVP_PKEY_KEY_PARAMETERS, params)) {
goto end;
}
end:
EVP_PKEY_CTX_free(ctx);
OSSL_PARAM_free(params);
OSSL_PARAM_BLD_free(tmpl);
BUG/MINOR: ssl: Memory leak of DH BIGNUM fields When running HAProxy with OpenSSLv3, the two BIGNUMs used to build our own DH parameters are not freed. It was not necessary previously because ownership of those parameters was transferred to OpenSSL through the DH_set0_pqg call. This patch should be backported to 2.6.
2022-11-03 10:16:47 -04:00
BN_free(p);
BN_free(g);
MINOR: ssl: Add ssl_new_dh_fromdata helper function Starting from OpenSSLv3, the DH_set0_pqg function is deprecated and the use of DH objects directly is advised against so this new helper function will be used to convert our hard-coded DH parameters into an EVP_PKEY. It relies on the new OSSL_PARAM mechanism, as described in the EVP_PKEY-DH manpage.
2022-02-11 06:04:52 -05:00
return pkey;
#else
MEDIUM: ssl: Replace all DH objects by EVP_PKEY on OpenSSLv3 (via HASSL_DH type) DH structure is a low-level one that should not be used anymore with OpenSSLv3. All functions working on DH were marked as deprecated and this patch replaces the ones we used with new APIs recommended in OpenSSLv3, be it in the migration guide or the multiple new manpages they created. This patch replaces all mentions of the DH type by the HASSL_DH one, which will be replaced by EVP_PKEY with OpenSSLv3 and will remain DH on older versions. It also uses all the newly created helper functions that enable for instance to load DH parameters from a file into an EVP_PKEY, or to set DH parameters into an SSL_CTX for use in a DHE negotiation. The following deprecated functions will effectively disappear when building with OpenSSLv3 : DH_set0_pqg, PEM_read_bio_DHparams, DH_new, DH_free, DH_up_ref, SSL_CTX_set_tmp_dh.
2022-02-11 06:04:55 -05:00
HASSL_DH *dh = DH_new();
MINOR: ssl: Add ssl_new_dh_fromdata helper function Starting from OpenSSLv3, the DH_set0_pqg function is deprecated and the use of DH objects directly is advised against so this new helper function will be used to convert our hard-coded DH parameters into an EVP_PKEY. It relies on the new OSSL_PARAM mechanism, as described in the EVP_PKEY-DH manpage.
2022-02-11 06:04:52 -05:00
if (!dh)
return NULL;
DH_set0_pqg(dh, p, NULL, g);
return dh;
#endif
}
BUILD: ssl: Fix compilation with OpenSSL 1.0.2 The DH parameters used for OpenSSL versions 1.1.1 and earlier where changed. For OpenSSL 1.0.2 and LibreSSL the newly introduced ssl_get_dh_by_nid function is not used since we keep the original parameters.
2022-04-20 12:30:17 -04:00
#if (HA_OPENSSL_VERSION_NUMBER >= 0x10101000L)
MINOR: ssl: Use DH parameters defined in RFC7919 instead of hard coded ones RFC7919 defined sets of DH parameters supposedly strong enough to be used safely. We will then use them when we can instead of our hard coded ones (namely the ffdhe2048 and ffdhe4096 named groups). The ffdhe2048 and ffdhe4096 named groups were integrated in OpenSSL starting with version 1.1.1. Instead of duplicating those parameters in haproxy for older versions of OpenSSL, we will keep using our own parameters when they are not provided by the SSL library. We will also need to keep our 1024 bits DH parameters since they are considered not safe enough to have a dedicated named group in RFC7919 but we must still keep it for retrocompatibility with old Java clients. This request was described in GitHub issue #1604.
2022-04-12 05:31:54 -04:00
static inline HASSL_DH *ssl_get_dh_by_nid(int nid)
{
#if (HA_OPENSSL_VERSION_NUMBER >= 0x3000000fL)
OSSL_PARAM params[2];
EVP_PKEY *pkey = NULL;
EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, "DH", NULL);
const char *named_group = NULL;
if (!pctx)
goto end;
named_group = OBJ_nid2ln(nid);
if (!named_group)
goto end;
params[0] = OSSL_PARAM_construct_utf8_string("group", (char*)named_group, 0);
params[1] = OSSL_PARAM_construct_end();
if (EVP_PKEY_keygen_init(pctx) && EVP_PKEY_CTX_set_params(pctx, params))
EVP_PKEY_generate(pctx, &pkey);
end:
EVP_PKEY_CTX_free(pctx);
return pkey;
#else
HASSL_DH *dh = NULL;
dh = DH_new_by_nid(nid);
return dh;
#endif
}
BUILD: ssl: Fix compilation with OpenSSL 1.0.2 The DH parameters used for OpenSSL versions 1.1.1 and earlier where changed. For OpenSSL 1.0.2 and LibreSSL the newly introduced ssl_get_dh_by_nid function is not used since we keep the original parameters.
2022-04-20 12:30:17 -04:00
#endif
MINOR: ssl: Use DH parameters defined in RFC7919 instead of hard coded ones RFC7919 defined sets of DH parameters supposedly strong enough to be used safely. We will then use them when we can instead of our hard coded ones (namely the ffdhe2048 and ffdhe4096 named groups). The ffdhe2048 and ffdhe4096 named groups were integrated in OpenSSL starting with version 1.1.1. Instead of duplicating those parameters in haproxy for older versions of OpenSSL, we will keep using our own parameters when they are not provided by the SSL library. We will also need to keep our 1024 bits DH parameters since they are considered not safe enough to have a dedicated named group in RFC7919 but we must still keep it for retrocompatibility with old Java clients. This request was described in GitHub issue #1604.
2022-04-12 05:31:54 -04:00
MINOR: ssl: Add ssl_new_dh_fromdata helper function Starting from OpenSSLv3, the DH_set0_pqg function is deprecated and the use of DH objects directly is advised against so this new helper function will be used to convert our hard-coded DH parameters into an EVP_PKEY. It relies on the new OSSL_PARAM mechanism, as described in the EVP_PKEY-DH manpage.
2022-02-11 06:04:52 -05:00
MEDIUM: ssl: Replace all DH objects by EVP_PKEY on OpenSSLv3 (via HASSL_DH type) DH structure is a low-level one that should not be used anymore with OpenSSLv3. All functions working on DH were marked as deprecated and this patch replaces the ones we used with new APIs recommended in OpenSSLv3, be it in the migration guide or the multiple new manpages they created. This patch replaces all mentions of the DH type by the HASSL_DH one, which will be replaced by EVP_PKEY with OpenSSLv3 and will remain DH on older versions. It also uses all the newly created helper functions that enable for instance to load DH parameters from a file into an EVP_PKEY, or to set DH parameters into an SSL_CTX for use in a DHE negotiation. The following deprecated functions will effectively disappear when building with OpenSSLv3 : DH_set0_pqg, PEM_read_bio_DHparams, DH_new, DH_free, DH_up_ref, SSL_CTX_set_tmp_dh.
2022-02-11 06:04:55 -05:00
static HASSL_DH * ssl_get_dh_1024(void)
MEDIUM: ssl: Add the option to use standardized DH parameters >= 1024 bits When no static DH parameters are specified, this patch makes haproxy use standardized (rfc 2409 / rfc 3526) DH parameters with prime lenghts of 1024, 2048, 4096 or 8192 bits for DHE key exchange. The size of the temporary/ephemeral DH key is computed as the minimum of the RSA/DSA server key size and the value of a new option named tune.ssl.default-dh-param.
2014-06-12 08:58:40 -04:00
{
MEDIUM: ssl: replace standards DH groups with custom ones It is likely that powerful adversaries have been pre-computing the standardized DH groups, because being widely used have made them valuable targets. While users are advised to generate their own DH parameters, replace the ones we ship by values been randomly generated for this product only. [wt: replaced dh1024_p, dh2048_p, and dh4096_p with locally-generated ones as recommended by Rmi]
2015-05-29 10:26:17 -04:00
static unsigned char dh1024_p[]={
0xFA,0xF9,0x2A,0x22,0x2A,0xA7,0x7F,0xE1,0x67,0x4E,0x53,0xF7,
0x56,0x13,0xC3,0xB1,0xE3,0x29,0x6B,0x66,0x31,0x6A,0x7F,0xB3,
0xC2,0x68,0x6B,0xCB,0x1D,0x57,0x39,0x1D,0x1F,0xFF,0x1C,0xC9,
0xA6,0xA4,0x98,0x82,0x31,0x5D,0x25,0xFF,0x8A,0xE0,0x73,0x96,
0x81,0xC8,0x83,0x79,0xC1,0x5A,0x04,0xF8,0x37,0x0D,0xA8,0x3D,
0xAE,0x74,0xBC,0xDB,0xB6,0xA4,0x75,0xD9,0x71,0x8A,0xA0,0x17,
0x9E,0x2D,0xC8,0xA8,0xDF,0x2C,0x5F,0x82,0x95,0xF8,0x92,0x9B,
0xA7,0x33,0x5F,0x89,0x71,0xC8,0x2D,0x6B,0x18,0x86,0xC4,0x94,
0x22,0xA5,0x52,0x8D,0xF6,0xF6,0xD2,0x37,0x92,0x0F,0xA5,0xCC,
0xDB,0x7B,0x1D,0x3D,0xA1,0x31,0xB7,0x80,0x8F,0x0B,0x67,0x5E,
0x36,0xA5,0x60,0x0C,0xF1,0x95,0x33,0x8B,
};
static unsigned char dh1024_g[]={
0x02,
};
MEDIUM: ssl: Add support for OpenSSL 1.1.0 In the last release a lot of the structures have become opaque for an end user. This means the code using these needs to be changed to use the proper functions to interact with these structures instead of trying to manipulate them directly. This does not fix any deprecations yet that are part of 1.1.0, it only ensures that it can be compiled against that version and is still compatible with older ones. [wt: openssl-0.9.8 doesn't build with it, there are conflicts on certain function prototypes which we declare as inline here and which are defined differently there. But openssl-0.9.8 is not supported anymore so probably it's OK to go without it for now and we'll see later if some users still need it. Emeric has reviewed this change and didn't spot anything obvious which requires special care. Let's try it for real now]
2016-08-29 07:26:37 -04:00
BIGNUM *p;
BIGNUM *g;
MEDIUM: ssl: Replace all DH objects by EVP_PKEY on OpenSSLv3 (via HASSL_DH type) DH structure is a low-level one that should not be used anymore with OpenSSLv3. All functions working on DH were marked as deprecated and this patch replaces the ones we used with new APIs recommended in OpenSSLv3, be it in the migration guide or the multiple new manpages they created. This patch replaces all mentions of the DH type by the HASSL_DH one, which will be replaced by EVP_PKEY with OpenSSLv3 and will remain DH on older versions. It also uses all the newly created helper functions that enable for instance to load DH parameters from a file into an EVP_PKEY, or to set DH parameters into an SSL_CTX for use in a DHE negotiation. The following deprecated functions will effectively disappear when building with OpenSSLv3 : DH_set0_pqg, PEM_read_bio_DHparams, DH_new, DH_free, DH_up_ref, SSL_CTX_set_tmp_dh.
2022-02-11 06:04:55 -05:00
HASSL_DH *dh = NULL;
p = BN_bin2bn(dh1024_p, sizeof dh1024_p, NULL);
g = BN_bin2bn(dh1024_g, sizeof dh1024_g, NULL);
if (p && g)
dh = ssl_new_dh_fromdata(p, g);
MEDIUM: ssl: Add the option to use standardized DH parameters >= 1024 bits When no static DH parameters are specified, this patch makes haproxy use standardized (rfc 2409 / rfc 3526) DH parameters with prime lenghts of 1024, 2048, 4096 or 8192 bits for DHE key exchange. The size of the temporary/ephemeral DH key is computed as the minimum of the RSA/DSA server key size and the value of a new option named tune.ssl.default-dh-param.
2014-06-12 08:58:40 -04:00
return dh;
}
MEDIUM: ssl: Replace all DH objects by EVP_PKEY on OpenSSLv3 (via HASSL_DH type) DH structure is a low-level one that should not be used anymore with OpenSSLv3. All functions working on DH were marked as deprecated and this patch replaces the ones we used with new APIs recommended in OpenSSLv3, be it in the migration guide or the multiple new manpages they created. This patch replaces all mentions of the DH type by the HASSL_DH one, which will be replaced by EVP_PKEY with OpenSSLv3 and will remain DH on older versions. It also uses all the newly created helper functions that enable for instance to load DH parameters from a file into an EVP_PKEY, or to set DH parameters into an SSL_CTX for use in a DHE negotiation. The following deprecated functions will effectively disappear when building with OpenSSLv3 : DH_set0_pqg, PEM_read_bio_DHparams, DH_new, DH_free, DH_up_ref, SSL_CTX_set_tmp_dh.
2022-02-11 06:04:55 -05:00
static HASSL_DH *ssl_get_dh_2048(void)
MEDIUM: ssl: Add the option to use standardized DH parameters >= 1024 bits When no static DH parameters are specified, this patch makes haproxy use standardized (rfc 2409 / rfc 3526) DH parameters with prime lenghts of 1024, 2048, 4096 or 8192 bits for DHE key exchange. The size of the temporary/ephemeral DH key is computed as the minimum of the RSA/DSA server key size and the value of a new option named tune.ssl.default-dh-param.
2014-06-12 08:58:40 -04:00
{
MINOR: ssl: Use DH parameters defined in RFC7919 instead of hard coded ones RFC7919 defined sets of DH parameters supposedly strong enough to be used safely. We will then use them when we can instead of our hard coded ones (namely the ffdhe2048 and ffdhe4096 named groups). The ffdhe2048 and ffdhe4096 named groups were integrated in OpenSSL starting with version 1.1.1. Instead of duplicating those parameters in haproxy for older versions of OpenSSL, we will keep using our own parameters when they are not provided by the SSL library. We will also need to keep our 1024 bits DH parameters since they are considered not safe enough to have a dedicated named group in RFC7919 but we must still keep it for retrocompatibility with old Java clients. This request was described in GitHub issue #1604.
2022-04-12 05:31:54 -04:00
#if (HA_OPENSSL_VERSION_NUMBER < 0x10101000L)
MEDIUM: ssl: replace standards DH groups with custom ones It is likely that powerful adversaries have been pre-computing the standardized DH groups, because being widely used have made them valuable targets. While users are advised to generate their own DH parameters, replace the ones we ship by values been randomly generated for this product only. [wt: replaced dh1024_p, dh2048_p, and dh4096_p with locally-generated ones as recommended by Rmi]
2015-05-29 10:26:17 -04:00
static unsigned char dh2048_p[]={
0xEC,0x86,0xF8,0x70,0xA0,0x33,0x16,0xEC,0x05,0x1A,0x73,0x59,
0xCD,0x1F,0x8B,0xF8,0x29,0xE4,0xD2,0xCF,0x52,0xDD,0xC2,0x24,
0x8D,0xB5,0x38,0x9A,0xFB,0x5C,0xA4,0xE4,0xB2,0xDA,0xCE,0x66,
0x50,0x74,0xA6,0x85,0x4D,0x4B,0x1D,0x30,0xB8,0x2B,0xF3,0x10,
0xE9,0xA7,0x2D,0x05,0x71,0xE7,0x81,0xDF,0x8B,0x59,0x52,0x3B,
0x5F,0x43,0x0B,0x68,0xF1,0xDB,0x07,0xBE,0x08,0x6B,0x1B,0x23,
0xEE,0x4D,0xCC,0x9E,0x0E,0x43,0xA0,0x1E,0xDF,0x43,0x8C,0xEC,
0xBE,0xBE,0x90,0xB4,0x51,0x54,0xB9,0x2F,0x7B,0x64,0x76,0x4E,
0x5D,0xD4,0x2E,0xAE,0xC2,0x9E,0xAE,0x51,0x43,0x59,0xC7,0x77,
0x9C,0x50,0x3C,0x0E,0xED,0x73,0x04,0x5F,0xF1,0x4C,0x76,0x2A,
0xD8,0xF8,0xCF,0xFC,0x34,0x40,0xD1,0xB4,0x42,0x61,0x84,0x66,
0x42,0x39,0x04,0xF8,0x68,0xB2,0x62,0xD7,0x55,0xED,0x1B,0x74,
0x75,0x91,0xE0,0xC5,0x69,0xC1,0x31,0x5C,0xDB,0x7B,0x44,0x2E,
0xCE,0x84,0x58,0x0D,0x1E,0x66,0x0C,0xC8,0x44,0x9E,0xFD,0x40,
0x08,0x67,0x5D,0xFB,0xA7,0x76,0x8F,0x00,0x11,0x87,0xE9,0x93,
0xF9,0x7D,0xC4,0xBC,0x74,0x55,0x20,0xD4,0x4A,0x41,0x2F,0x43,
0x42,0x1A,0xC1,0xF2,0x97,0x17,0x49,0x27,0x37,0x6B,0x2F,0x88,
0x7E,0x1C,0xA0,0xA1,0x89,0x92,0x27,0xD9,0x56,0x5A,0x71,0xC1,
0x56,0x37,0x7E,0x3A,0x9D,0x05,0xE7,0xEE,0x5D,0x8F,0x82,0x17,
0xBC,0xE9,0xC2,0x93,0x30,0x82,0xF9,0xF4,0xC9,0xAE,0x49,0xDB,
0xD0,0x54,0xB4,0xD9,0x75,0x4D,0xFA,0x06,0xB8,0xD6,0x38,0x41,
0xB7,0x1F,0x77,0xF3,
};
static unsigned char dh2048_g[]={
0x02,
};
MEDIUM: ssl: Add support for OpenSSL 1.1.0 In the last release a lot of the structures have become opaque for an end user. This means the code using these needs to be changed to use the proper functions to interact with these structures instead of trying to manipulate them directly. This does not fix any deprecations yet that are part of 1.1.0, it only ensures that it can be compiled against that version and is still compatible with older ones. [wt: openssl-0.9.8 doesn't build with it, there are conflicts on certain function prototypes which we declare as inline here and which are defined differently there. But openssl-0.9.8 is not supported anymore so probably it's OK to go without it for now and we'll see later if some users still need it. Emeric has reviewed this change and didn't spot anything obvious which requires special care. Let's try it for real now]
2016-08-29 07:26:37 -04:00
BIGNUM *p;
BIGNUM *g;
MEDIUM: ssl: Replace all DH objects by EVP_PKEY on OpenSSLv3 (via HASSL_DH type) DH structure is a low-level one that should not be used anymore with OpenSSLv3. All functions working on DH were marked as deprecated and this patch replaces the ones we used with new APIs recommended in OpenSSLv3, be it in the migration guide or the multiple new manpages they created. This patch replaces all mentions of the DH type by the HASSL_DH one, which will be replaced by EVP_PKEY with OpenSSLv3 and will remain DH on older versions. It also uses all the newly created helper functions that enable for instance to load DH parameters from a file into an EVP_PKEY, or to set DH parameters into an SSL_CTX for use in a DHE negotiation. The following deprecated functions will effectively disappear when building with OpenSSLv3 : DH_set0_pqg, PEM_read_bio_DHparams, DH_new, DH_free, DH_up_ref, SSL_CTX_set_tmp_dh.
2022-02-11 06:04:55 -05:00
HASSL_DH *dh = NULL;
p = BN_bin2bn(dh2048_p, sizeof dh2048_p, NULL);
g = BN_bin2bn(dh2048_g, sizeof dh2048_g, NULL);
if (p && g)
dh = ssl_new_dh_fromdata(p, g);
MEDIUM: ssl: Add the option to use standardized DH parameters >= 1024 bits When no static DH parameters are specified, this patch makes haproxy use standardized (rfc 2409 / rfc 3526) DH parameters with prime lenghts of 1024, 2048, 4096 or 8192 bits for DHE key exchange. The size of the temporary/ephemeral DH key is computed as the minimum of the RSA/DSA server key size and the value of a new option named tune.ssl.default-dh-param.
2014-06-12 08:58:40 -04:00
return dh;
MINOR: ssl: Use DH parameters defined in RFC7919 instead of hard coded ones RFC7919 defined sets of DH parameters supposedly strong enough to be used safely. We will then use them when we can instead of our hard coded ones (namely the ffdhe2048 and ffdhe4096 named groups). The ffdhe2048 and ffdhe4096 named groups were integrated in OpenSSL starting with version 1.1.1. Instead of duplicating those parameters in haproxy for older versions of OpenSSL, we will keep using our own parameters when they are not provided by the SSL library. We will also need to keep our 1024 bits DH parameters since they are considered not safe enough to have a dedicated named group in RFC7919 but we must still keep it for retrocompatibility with old Java clients. This request was described in GitHub issue #1604.
2022-04-12 05:31:54 -04:00
#else
return ssl_get_dh_by_nid(NID_ffdhe2048);
#endif
MEDIUM: ssl: Add the option to use standardized DH parameters >= 1024 bits When no static DH parameters are specified, this patch makes haproxy use standardized (rfc 2409 / rfc 3526) DH parameters with prime lenghts of 1024, 2048, 4096 or 8192 bits for DHE key exchange. The size of the temporary/ephemeral DH key is computed as the minimum of the RSA/DSA server key size and the value of a new option named tune.ssl.default-dh-param.
2014-06-12 08:58:40 -04:00
}
MEDIUM: ssl: Replace all DH objects by EVP_PKEY on OpenSSLv3 (via HASSL_DH type) DH structure is a low-level one that should not be used anymore with OpenSSLv3. All functions working on DH were marked as deprecated and this patch replaces the ones we used with new APIs recommended in OpenSSLv3, be it in the migration guide or the multiple new manpages they created. This patch replaces all mentions of the DH type by the HASSL_DH one, which will be replaced by EVP_PKEY with OpenSSLv3 and will remain DH on older versions. It also uses all the newly created helper functions that enable for instance to load DH parameters from a file into an EVP_PKEY, or to set DH parameters into an SSL_CTX for use in a DHE negotiation. The following deprecated functions will effectively disappear when building with OpenSSLv3 : DH_set0_pqg, PEM_read_bio_DHparams, DH_new, DH_free, DH_up_ref, SSL_CTX_set_tmp_dh.
2022-02-11 06:04:55 -05:00
static HASSL_DH *ssl_get_dh_4096(void)
MEDIUM: ssl: Add the option to use standardized DH parameters >= 1024 bits When no static DH parameters are specified, this patch makes haproxy use standardized (rfc 2409 / rfc 3526) DH parameters with prime lenghts of 1024, 2048, 4096 or 8192 bits for DHE key exchange. The size of the temporary/ephemeral DH key is computed as the minimum of the RSA/DSA server key size and the value of a new option named tune.ssl.default-dh-param.
2014-06-12 08:58:40 -04:00
{
MINOR: ssl: Use DH parameters defined in RFC7919 instead of hard coded ones RFC7919 defined sets of DH parameters supposedly strong enough to be used safely. We will then use them when we can instead of our hard coded ones (namely the ffdhe2048 and ffdhe4096 named groups). The ffdhe2048 and ffdhe4096 named groups were integrated in OpenSSL starting with version 1.1.1. Instead of duplicating those parameters in haproxy for older versions of OpenSSL, we will keep using our own parameters when they are not provided by the SSL library. We will also need to keep our 1024 bits DH parameters since they are considered not safe enough to have a dedicated named group in RFC7919 but we must still keep it for retrocompatibility with old Java clients. This request was described in GitHub issue #1604.
2022-04-12 05:31:54 -04:00
#if (HA_OPENSSL_VERSION_NUMBER < 0x10101000L)
MEDIUM: ssl: replace standards DH groups with custom ones It is likely that powerful adversaries have been pre-computing the standardized DH groups, because being widely used have made them valuable targets. While users are advised to generate their own DH parameters, replace the ones we ship by values been randomly generated for this product only. [wt: replaced dh1024_p, dh2048_p, and dh4096_p with locally-generated ones as recommended by Rmi]
2015-05-29 10:26:17 -04:00
static unsigned char dh4096_p[]={
0xDE,0x16,0x94,0xCD,0x99,0x58,0x07,0xF1,0xF7,0x32,0x96,0x11,
0x04,0x82,0xD4,0x84,0x72,0x80,0x99,0x06,0xCA,0xF0,0xA3,0x68,
0x07,0xCE,0x64,0x50,0xE7,0x74,0x45,0x20,0x80,0x5E,0x4D,0xAD,
0xA5,0xB6,0xED,0xFA,0x80,0x6C,0x3B,0x35,0xC4,0x9A,0x14,0x6B,
0x32,0xBB,0xFD,0x1F,0x17,0x8E,0xB7,0x1F,0xD6,0xFA,0x3F,0x7B,
0xEE,0x16,0xA5,0x62,0x33,0x0D,0xED,0xBC,0x4E,0x58,0xE5,0x47,
0x4D,0xE9,0xAB,0x8E,0x38,0xD3,0x6E,0x90,0x57,0xE3,0x22,0x15,
0x33,0xBD,0xF6,0x43,0x45,0xB5,0x10,0x0A,0xBE,0x2C,0xB4,0x35,
0xB8,0x53,0x8D,0xAD,0xFB,0xA7,0x1F,0x85,0x58,0x41,0x7A,0x79,
0x20,0x68,0xB3,0xE1,0x3D,0x08,0x76,0xBF,0x86,0x0D,0x49,0xE3,
0x82,0x71,0x8C,0xB4,0x8D,0x81,0x84,0xD4,0xE7,0xBE,0x91,0xDC,
0x26,0x39,0x48,0x0F,0x35,0xC4,0xCA,0x65,0xE3,0x40,0x93,0x52,
0x76,0x58,0x7D,0xDD,0x51,0x75,0xDC,0x69,0x61,0xBF,0x47,0x2C,
0x16,0x68,0x2D,0xC9,0x29,0xD3,0xE6,0xC0,0x99,0x48,0xA0,0x9A,
0xC8,0x78,0xC0,0x6D,0x81,0x67,0x12,0x61,0x3F,0x71,0xBA,0x41,
0x1F,0x6C,0x89,0x44,0x03,0xBA,0x3B,0x39,0x60,0xAA,0x28,0x55,
0x59,0xAE,0xB8,0xFA,0xCB,0x6F,0xA5,0x1A,0xF7,0x2B,0xDD,0x52,
0x8A,0x8B,0xE2,0x71,0xA6,0x5E,0x7E,0xD8,0x2E,0x18,0xE0,0x66,
0xDF,0xDD,0x22,0x21,0x99,0x52,0x73,0xA6,0x33,0x20,0x65,0x0E,
0x53,0xE7,0x6B,0x9B,0xC5,0xA3,0x2F,0x97,0x65,0x76,0xD3,0x47,
0x23,0x77,0x12,0xB6,0x11,0x7B,0x24,0xED,0xF1,0xEF,0xC0,0xE2,
0xA3,0x7E,0x67,0x05,0x3E,0x96,0x4D,0x45,0xC2,0x18,0xD1,0x73,
0x9E,0x07,0xF3,0x81,0x6E,0x52,0x63,0xF6,0x20,0x76,0xB9,0x13,
0xD2,0x65,0x30,0x18,0x16,0x09,0x16,0x9E,0x8F,0xF1,0xD2,0x10,
0x5A,0xD3,0xD4,0xAF,0x16,0x61,0xDA,0x55,0x2E,0x18,0x5E,0x14,
0x08,0x54,0x2E,0x2A,0x25,0xA2,0x1A,0x9B,0x8B,0x32,0xA9,0xFD,
0xC2,0x48,0x96,0xE1,0x80,0xCA,0xE9,0x22,0x17,0xBB,0xCE,0x3E,
0x9E,0xED,0xC7,0xF1,0x1F,0xEC,0x17,0x21,0xDC,0x7B,0x82,0x48,
0x8E,0xBB,0x4B,0x9D,0x5B,0x04,0x04,0xDA,0xDB,0x39,0xDF,0x01,
0x40,0xC3,0xAA,0x26,0x23,0x89,0x75,0xC6,0x0B,0xD0,0xA2,0x60,
0x6A,0xF1,0xCC,0x65,0x18,0x98,0x1B,0x52,0xD2,0x74,0x61,0xCC,
0xBD,0x60,0xAE,0xA3,0xA0,0x66,0x6A,0x16,0x34,0x92,0x3F,0x41,
0x40,0x31,0x29,0xC0,0x2C,0x63,0xB2,0x07,0x8D,0xEB,0x94,0xB8,
0xE8,0x47,0x92,0x52,0x93,0x6A,0x1B,0x7E,0x1A,0x61,0xB3,0x1B,
0xF0,0xD6,0x72,0x9B,0xF1,0xB0,0xAF,0xBF,0x3E,0x65,0xEF,0x23,
0x1D,0x6F,0xFF,0x70,0xCD,0x8A,0x4C,0x8A,0xA0,0x72,0x9D,0xBE,
0xD4,0xBB,0x24,0x47,0x4A,0x68,0xB5,0xF5,0xC6,0xD5,0x7A,0xCD,
0xCA,0x06,0x41,0x07,0xAD,0xC2,0x1E,0xE6,0x54,0xA7,0xAD,0x03,
0xD9,0x12,0xC1,0x9C,0x13,0xB1,0xC9,0x0A,0x43,0x8E,0x1E,0x08,
0xCE,0x50,0x82,0x73,0x5F,0xA7,0x55,0x1D,0xD9,0x59,0xAC,0xB5,
0xEA,0x02,0x7F,0x6C,0x5B,0x74,0x96,0x98,0x67,0x24,0xA3,0x0F,
0x15,0xFC,0xA9,0x7D,0x3E,0x67,0xD1,0x70,0xF8,0x97,0xF3,0x67,
0xC5,0x8C,0x88,0x44,0x08,0x02,0xC7,0x2B,
MEDIUM: ssl: Add the option to use standardized DH parameters >= 1024 bits When no static DH parameters are specified, this patch makes haproxy use standardized (rfc 2409 / rfc 3526) DH parameters with prime lenghts of 1024, 2048, 4096 or 8192 bits for DHE key exchange. The size of the temporary/ephemeral DH key is computed as the minimum of the RSA/DSA server key size and the value of a new option named tune.ssl.default-dh-param.
2014-06-12 08:58:40 -04:00
};
MEDIUM: ssl: replace standards DH groups with custom ones It is likely that powerful adversaries have been pre-computing the standardized DH groups, because being widely used have made them valuable targets. While users are advised to generate their own DH parameters, replace the ones we ship by values been randomly generated for this product only. [wt: replaced dh1024_p, dh2048_p, and dh4096_p with locally-generated ones as recommended by Rmi]
2015-05-29 10:26:17 -04:00
static unsigned char dh4096_g[]={
0x02,
};
MEDIUM: ssl: Add the option to use standardized DH parameters >= 1024 bits When no static DH parameters are specified, this patch makes haproxy use standardized (rfc 2409 / rfc 3526) DH parameters with prime lenghts of 1024, 2048, 4096 or 8192 bits for DHE key exchange. The size of the temporary/ephemeral DH key is computed as the minimum of the RSA/DSA server key size and the value of a new option named tune.ssl.default-dh-param.
2014-06-12 08:58:40 -04:00
MEDIUM: ssl: Add support for OpenSSL 1.1.0 In the last release a lot of the structures have become opaque for an end user. This means the code using these needs to be changed to use the proper functions to interact with these structures instead of trying to manipulate them directly. This does not fix any deprecations yet that are part of 1.1.0, it only ensures that it can be compiled against that version and is still compatible with older ones. [wt: openssl-0.9.8 doesn't build with it, there are conflicts on certain function prototypes which we declare as inline here and which are defined differently there. But openssl-0.9.8 is not supported anymore so probably it's OK to go without it for now and we'll see later if some users still need it. Emeric has reviewed this change and didn't spot anything obvious which requires special care. Let's try it for real now]
2016-08-29 07:26:37 -04:00
BIGNUM *p;
BIGNUM *g;
MEDIUM: ssl: Replace all DH objects by EVP_PKEY on OpenSSLv3 (via HASSL_DH type) DH structure is a low-level one that should not be used anymore with OpenSSLv3. All functions working on DH were marked as deprecated and this patch replaces the ones we used with new APIs recommended in OpenSSLv3, be it in the migration guide or the multiple new manpages they created. This patch replaces all mentions of the DH type by the HASSL_DH one, which will be replaced by EVP_PKEY with OpenSSLv3 and will remain DH on older versions. It also uses all the newly created helper functions that enable for instance to load DH parameters from a file into an EVP_PKEY, or to set DH parameters into an SSL_CTX for use in a DHE negotiation. The following deprecated functions will effectively disappear when building with OpenSSLv3 : DH_set0_pqg, PEM_read_bio_DHparams, DH_new, DH_free, DH_up_ref, SSL_CTX_set_tmp_dh.
2022-02-11 06:04:55 -05:00
HASSL_DH *dh = NULL;
p = BN_bin2bn(dh4096_p, sizeof dh4096_p, NULL);
g = BN_bin2bn(dh4096_g, sizeof dh4096_g, NULL);
if (p && g)
dh = ssl_new_dh_fromdata(p, g);
MEDIUM: ssl: Add the option to use standardized DH parameters >= 1024 bits When no static DH parameters are specified, this patch makes haproxy use standardized (rfc 2409 / rfc 3526) DH parameters with prime lenghts of 1024, 2048, 4096 or 8192 bits for DHE key exchange. The size of the temporary/ephemeral DH key is computed as the minimum of the RSA/DSA server key size and the value of a new option named tune.ssl.default-dh-param.
2014-06-12 08:58:40 -04:00
return dh;
MINOR: ssl: Use DH parameters defined in RFC7919 instead of hard coded ones RFC7919 defined sets of DH parameters supposedly strong enough to be used safely. We will then use them when we can instead of our hard coded ones (namely the ffdhe2048 and ffdhe4096 named groups). The ffdhe2048 and ffdhe4096 named groups were integrated in OpenSSL starting with version 1.1.1. Instead of duplicating those parameters in haproxy for older versions of OpenSSL, we will keep using our own parameters when they are not provided by the SSL library. We will also need to keep our 1024 bits DH parameters since they are considered not safe enough to have a dedicated named group in RFC7919 but we must still keep it for retrocompatibility with old Java clients. This request was described in GitHub issue #1604.
2022-04-12 05:31:54 -04:00
#else
return ssl_get_dh_by_nid(NID_ffdhe4096);
#endif
MEDIUM: ssl: Add the option to use standardized DH parameters >= 1024 bits When no static DH parameters are specified, this patch makes haproxy use standardized (rfc 2409 / rfc 3526) DH parameters with prime lenghts of 1024, 2048, 4096 or 8192 bits for DHE key exchange. The size of the temporary/ephemeral DH key is computed as the minimum of the RSA/DSA server key size and the value of a new option named tune.ssl.default-dh-param.
2014-06-12 08:58:40 -04:00
}
MEDIUM: ssl: Replace all DH objects by EVP_PKEY on OpenSSLv3 (via HASSL_DH type) DH structure is a low-level one that should not be used anymore with OpenSSLv3. All functions working on DH were marked as deprecated and this patch replaces the ones we used with new APIs recommended in OpenSSLv3, be it in the migration guide or the multiple new manpages they created. This patch replaces all mentions of the DH type by the HASSL_DH one, which will be replaced by EVP_PKEY with OpenSSLv3 and will remain DH on older versions. It also uses all the newly created helper functions that enable for instance to load DH parameters from a file into an EVP_PKEY, or to set DH parameters into an SSL_CTX for use in a DHE negotiation. The following deprecated functions will effectively disappear when building with OpenSSLv3 : DH_set0_pqg, PEM_read_bio_DHparams, DH_new, DH_free, DH_up_ref, SSL_CTX_set_tmp_dh.
2022-02-11 06:04:55 -05:00
static HASSL_DH *ssl_get_tmp_dh(EVP_PKEY *pkey)
MEDIUM: ssl: Add the option to use standardized DH parameters >= 1024 bits When no static DH parameters are specified, this patch makes haproxy use standardized (rfc 2409 / rfc 3526) DH parameters with prime lenghts of 1024, 2048, 4096 or 8192 bits for DHE key exchange. The size of the temporary/ephemeral DH key is computed as the minimum of the RSA/DSA server key size and the value of a new option named tune.ssl.default-dh-param.
2014-06-12 08:58:40 -04:00
{
MEDIUM: ssl: Replace all DH objects by EVP_PKEY on OpenSSLv3 (via HASSL_DH type) DH structure is a low-level one that should not be used anymore with OpenSSLv3. All functions working on DH were marked as deprecated and this patch replaces the ones we used with new APIs recommended in OpenSSLv3, be it in the migration guide or the multiple new manpages they created. This patch replaces all mentions of the DH type by the HASSL_DH one, which will be replaced by EVP_PKEY with OpenSSLv3 and will remain DH on older versions. It also uses all the newly created helper functions that enable for instance to load DH parameters from a file into an EVP_PKEY, or to set DH parameters into an SSL_CTX for use in a DHE negotiation. The following deprecated functions will effectively disappear when building with OpenSSLv3 : DH_set0_pqg, PEM_read_bio_DHparams, DH_new, DH_free, DH_up_ref, SSL_CTX_set_tmp_dh.
2022-02-11 06:04:55 -05:00
HASSL_DH *dh = NULL;
MEDIUM: ssl: Add support for OpenSSL 1.1.0 In the last release a lot of the structures have become opaque for an end user. This means the code using these needs to be changed to use the proper functions to interact with these structures instead of trying to manipulate them directly. This does not fix any deprecations yet that are part of 1.1.0, it only ensures that it can be compiled against that version and is still compatible with older ones. [wt: openssl-0.9.8 doesn't build with it, there are conflicts on certain function prototypes which we declare as inline here and which are defined differently there. But openssl-0.9.8 is not supported anymore so probably it's OK to go without it for now and we'll see later if some users still need it. Emeric has reviewed this change and didn't spot anything obvious which requires special care. Let's try it for real now]
2016-08-29 07:26:37 -04:00
int type;
MINOR: ssl: Factorize ssl_get_tmp_dh and append a cbk to its name In the upcoming OpenSSLv3 specific patches, we will make use of the newly created ssl_get_tmp_dh that returns an EVP_PKEY containing DH parameters of the same size as a bind line's RSA or DSA private key. The previously named ssl_get_tmp_dh function was renamed ssl_get_tmp_dh_cbk because it is only used as a callback passed to OpenSSL through SSL_CTX_set_tmp_dh_callback calls.
2022-02-11 06:04:49 -05:00
int keylen = 0;
MEDIUM: ssl: Add support for OpenSSL 1.1.0 In the last release a lot of the structures have become opaque for an end user. This means the code using these needs to be changed to use the proper functions to interact with these structures instead of trying to manipulate them directly. This does not fix any deprecations yet that are part of 1.1.0, it only ensures that it can be compiled against that version and is still compatible with older ones. [wt: openssl-0.9.8 doesn't build with it, there are conflicts on certain function prototypes which we declare as inline here and which are defined differently there. But openssl-0.9.8 is not supported anymore so probably it's OK to go without it for now and we'll see later if some users still need it. Emeric has reviewed this change and didn't spot anything obvious which requires special care. Let's try it for real now]
2016-08-29 07:26:37 -04:00
type = pkey ? EVP_PKEY_base_id(pkey) : EVP_PKEY_NONE;
MEDIUM: ssl: Add the option to use standardized DH parameters >= 1024 bits When no static DH parameters are specified, this patch makes haproxy use standardized (rfc 2409 / rfc 3526) DH parameters with prime lenghts of 1024, 2048, 4096 or 8192 bits for DHE key exchange. The size of the temporary/ephemeral DH key is computed as the minimum of the RSA/DSA server key size and the value of a new option named tune.ssl.default-dh-param.
2014-06-12 08:58:40 -04:00
BUG/MEDIUM: fix DH length when EC key is used dh of length 1024 were chosen for EVP_PKEY_EC key type. let us pick "default_dh_param" instead. issue was found on Ubuntu 22.04 which is shipped with OpenSSL configured with SECLEVEL=2 by default. such SECLEVEL value prohibits DH shorter than 2048: OpenSSL error[0xa00018a] SSL_CTX_set0_tmp_dh_pkey: dh key too small better strategy for chosing DH still may be considered though.
2022-07-23 14:55:19 -04:00
if (type == EVP_PKEY_EC) {
keylen = global_ssl.default_dh_param;
}
MEDIUM: ssl: Add the option to use standardized DH parameters >= 1024 bits When no static DH parameters are specified, this patch makes haproxy use standardized (rfc 2409 / rfc 3526) DH parameters with prime lenghts of 1024, 2048, 4096 or 8192 bits for DHE key exchange. The size of the temporary/ephemeral DH key is computed as the minimum of the RSA/DSA server key size and the value of a new option named tune.ssl.default-dh-param.
2014-06-12 08:58:40 -04:00
/* The keylen supplied by OpenSSL can only be 512 or 1024.
See ssl3_send_server_key_exchange() in ssl/s3_srvr.c
*/
if (type == EVP_PKEY_RSA || type == EVP_PKEY_DSA) {
keylen = EVP_PKEY_bits(pkey);
}
CLEANUP: ssl: move most ssl-specific global settings to ssl_sock.c Historically a lot of SSL global settings were stored into the global struct, but we've reached a point where there are 3 ifdefs in it just for this, and others in haproxy.c to initialize it. This patch moves all the private fields to a new struct "global_ssl" stored in ssl_sock.c. This includes : char *crt_base; char *ca_base; char *listen_default_ciphers; char *connect_default_ciphers; int listen_default_ssloptions; int connect_default_ssloptions; int tune.sslprivatecache; /* Force to use a private session cache even if nbproc > 1 */ unsigned int tune.ssllifetime; /* SSL session lifetime in seconds */ unsigned int tune.ssl_max_record; /* SSL max record size */ unsigned int tune.ssl_default_dh_param; /* SSL maximum DH parameter size */ int tune.ssl_ctx_cache; /* max number of entries in the ssl_ctx cache. */ The "tune" part was removed (useless here) and the occasional "ssl" prefixes were removed as well. Thus for example instead of global.tune.ssl_default_dh_param we now have : global_ssl.default_dh_param A few initializers were present in the constructor, they could be brought back to the structure declaration. A few other entries had to stay in global for now. They concern memory calculationn (used in haproxy.c) and stats (used in stats.c). The code is already much cleaner now, especially for global.h and haproxy.c which become readable.
2016-12-22 17:12:01 -05:00
if (keylen > global_ssl.default_dh_param) {
keylen = global_ssl.default_dh_param;
MEDIUM: ssl: Add the option to use standardized DH parameters >= 1024 bits When no static DH parameters are specified, this patch makes haproxy use standardized (rfc 2409 / rfc 3526) DH parameters with prime lenghts of 1024, 2048, 4096 or 8192 bits for DHE key exchange. The size of the temporary/ephemeral DH key is computed as the minimum of the RSA/DSA server key size and the value of a new option named tune.ssl.default-dh-param.
2014-06-12 08:58:40 -04:00
}
MEDIUM: ssl: replace standards DH groups with custom ones It is likely that powerful adversaries have been pre-computing the standardized DH groups, because being widely used have made them valuable targets. While users are advised to generate their own DH parameters, replace the ones we ship by values been randomly generated for this product only. [wt: replaced dh1024_p, dh2048_p, and dh4096_p with locally-generated ones as recommended by Rmi]
2015-05-29 10:26:17 -04:00
if (keylen >= 4096) {
MINOR: ssl: Build local DH of right size when needed The current way the local DH structures are built relies on the fact that the ssl_get_tmp_dh function would only be called as a callback during a DHE negotiation, so after all the SSL contexts are built and the init is over. With OpenSSLv3, this function will now be called during init, so before those objects are curretly built. This patch ensures that when calling ssl_get_tmp_dh and trying to use one of or hard-coded DH parameters, it will be created if it did not exist yet. The current DH parameter creation is also kept so that with versions before OpenSSLv3 we don't end up creating this DH object during a handshake.
2022-02-11 06:04:53 -05:00
if (!local_dh_4096)
local_dh_4096 = ssl_get_dh_4096();
BUG/MEDIUM: ssl: Fix a memory leak in DHE key exchange OpenSSL does not free the DH * value returned by the callback specified with SSL_CTX_set_tmp_dh_callback(), leading to a memory leak for SSL/TLS connections using Diffie Hellman Ephemeral key exchange. This patch fixes the leak by allocating the DH * structs holding the DH parameters once, at configuration time. Note: this fix must be backported to 1.5.
2014-07-15 05:36:40 -04:00
dh = local_dh_4096;
MEDIUM: ssl: Add the option to use standardized DH parameters >= 1024 bits When no static DH parameters are specified, this patch makes haproxy use standardized (rfc 2409 / rfc 3526) DH parameters with prime lenghts of 1024, 2048, 4096 or 8192 bits for DHE key exchange. The size of the temporary/ephemeral DH key is computed as the minimum of the RSA/DSA server key size and the value of a new option named tune.ssl.default-dh-param.
2014-06-12 08:58:40 -04:00
}
else if (keylen >= 2048) {
MINOR: ssl: Build local DH of right size when needed The current way the local DH structures are built relies on the fact that the ssl_get_tmp_dh function would only be called as a callback during a DHE negotiation, so after all the SSL contexts are built and the init is over. With OpenSSLv3, this function will now be called during init, so before those objects are curretly built. This patch ensures that when calling ssl_get_tmp_dh and trying to use one of or hard-coded DH parameters, it will be created if it did not exist yet. The current DH parameter creation is also kept so that with versions before OpenSSLv3 we don't end up creating this DH object during a handshake.
2022-02-11 06:04:53 -05:00
if (!local_dh_2048)
local_dh_2048 = ssl_get_dh_2048();
BUG/MEDIUM: ssl: Fix a memory leak in DHE key exchange OpenSSL does not free the DH * value returned by the callback specified with SSL_CTX_set_tmp_dh_callback(), leading to a memory leak for SSL/TLS connections using Diffie Hellman Ephemeral key exchange. This patch fixes the leak by allocating the DH * structs holding the DH parameters once, at configuration time. Note: this fix must be backported to 1.5.
2014-07-15 05:36:40 -04:00
dh = local_dh_2048;
MEDIUM: ssl: Add the option to use standardized DH parameters >= 1024 bits When no static DH parameters are specified, this patch makes haproxy use standardized (rfc 2409 / rfc 3526) DH parameters with prime lenghts of 1024, 2048, 4096 or 8192 bits for DHE key exchange. The size of the temporary/ephemeral DH key is computed as the minimum of the RSA/DSA server key size and the value of a new option named tune.ssl.default-dh-param.
2014-06-12 08:58:40 -04:00
}
else {
MINOR: ssl: Build local DH of right size when needed The current way the local DH structures are built relies on the fact that the ssl_get_tmp_dh function would only be called as a callback during a DHE negotiation, so after all the SSL contexts are built and the init is over. With OpenSSLv3, this function will now be called during init, so before those objects are curretly built. This patch ensures that when calling ssl_get_tmp_dh and trying to use one of or hard-coded DH parameters, it will be created if it did not exist yet. The current DH parameter creation is also kept so that with versions before OpenSSLv3 we don't end up creating this DH object during a handshake.
2022-02-11 06:04:53 -05:00
if (!local_dh_1024)
local_dh_1024 = ssl_get_dh_1024();
BUG/MEDIUM: ssl: Fix a memory leak in DHE key exchange OpenSSL does not free the DH * value returned by the callback specified with SSL_CTX_set_tmp_dh_callback(), leading to a memory leak for SSL/TLS connections using Diffie Hellman Ephemeral key exchange. This patch fixes the leak by allocating the DH * structs holding the DH parameters once, at configuration time. Note: this fix must be backported to 1.5.
2014-07-15 05:36:40 -04:00
dh = local_dh_1024;
MEDIUM: ssl: Add the option to use standardized DH parameters >= 1024 bits When no static DH parameters are specified, this patch makes haproxy use standardized (rfc 2409 / rfc 3526) DH parameters with prime lenghts of 1024, 2048, 4096 or 8192 bits for DHE key exchange. The size of the temporary/ephemeral DH key is computed as the minimum of the RSA/DSA server key size and the value of a new option named tune.ssl.default-dh-param.
2014-06-12 08:58:40 -04:00
}
return dh;
}
MINOR: ssl: Remove calls to SSL_CTX_set_tmp_dh_callback on OpenSSLv3 The SSL_CTX_set_tmp_dh_callback function was marked as deprecated in OpenSSLv3 so this patch replaces this callback mechanism by a direct set of DH parameters during init.
2022-02-11 06:04:56 -05:00
#if (HA_OPENSSL_VERSION_NUMBER < 0x3000000fL)
MINOR: ssl: Factorize ssl_get_tmp_dh and append a cbk to its name In the upcoming OpenSSLv3 specific patches, we will make use of the newly created ssl_get_tmp_dh that returns an EVP_PKEY containing DH parameters of the same size as a bind line's RSA or DSA private key. The previously named ssl_get_tmp_dh function was renamed ssl_get_tmp_dh_cbk because it is only used as a callback passed to OpenSSL through SSL_CTX_set_tmp_dh_callback calls.
2022-02-11 06:04:49 -05:00
/* Returns Diffie-Hellman parameters matching the private key length
but not exceeding global_ssl.default_dh_param */
REORG: ssl: move 'generate-certificates' code to ssl_gencert.c A lot of code specific to the 'generate-certificates' option was left in ssl_sock.c. Move the code to 'ssl_gencert.c' and 'ssl_gencert.h'
2024-01-12 09:23:49 -05:00
HASSL_DH *ssl_get_tmp_dh_cbk(SSL *ssl, int export, int keylen)
MINOR: ssl: Factorize ssl_get_tmp_dh and append a cbk to its name In the upcoming OpenSSLv3 specific patches, we will make use of the newly created ssl_get_tmp_dh that returns an EVP_PKEY containing DH parameters of the same size as a bind line's RSA or DSA private key. The previously named ssl_get_tmp_dh function was renamed ssl_get_tmp_dh_cbk because it is only used as a callback passed to OpenSSL through SSL_CTX_set_tmp_dh_callback calls.
2022-02-11 06:04:49 -05:00
{
EVP_PKEY *pkey = SSL_get_privatekey(ssl);
return ssl_get_tmp_dh(pkey);
}
MINOR: ssl: Remove calls to SSL_CTX_set_tmp_dh_callback on OpenSSLv3 The SSL_CTX_set_tmp_dh_callback function was marked as deprecated in OpenSSLv3 so this patch replaces this callback mechanism by a direct set of DH parameters during init.
2022-02-11 06:04:56 -05:00
#endif
MINOR: ssl: Factorize ssl_get_tmp_dh and append a cbk to its name In the upcoming OpenSSLv3 specific patches, we will make use of the newly created ssl_get_tmp_dh that returns an EVP_PKEY containing DH parameters of the same size as a bind line's RSA or DSA private key. The previously named ssl_get_tmp_dh function was renamed ssl_get_tmp_dh_cbk because it is only used as a callback passed to OpenSSL through SSL_CTX_set_tmp_dh_callback calls.
2022-02-11 06:04:49 -05:00
MINOR: ssl: Add ssl_sock_set_tmp_dh helper function Starting from OpenSSLv3, the SSL_CTX_set_tmp_dh function is deprecated and it should be replaced by SSL_CTX_set0_tmp_dh_pkey, which takes an EVP_PKEY instead of a DH parameter. Since this function is new to OpenSSLv3 and its use requires an extra EVP_PKEY_up_ref call, we will keep the two versions side by side, otherwise it would require to get rid of all DH references in older OpenSSL versions as well. This helper function is not used yet so this commit should be strictly iso-functional, regardless of the OpenSSL version.
2022-02-11 06:04:50 -05:00
static int ssl_sock_set_tmp_dh(SSL_CTX *ctx, HASSL_DH *dh)
{
#if (HA_OPENSSL_VERSION_NUMBER < 0x3000000fL)
return SSL_CTX_set_tmp_dh(ctx, dh);
#else
int retval = 0;
HASSL_DH_up_ref(dh);
retval = SSL_CTX_set0_tmp_dh_pkey(ctx, dh);
if (!retval)
HASSL_DH_free(dh);
return retval;
#endif
}
MINOR: ssl: Add ssl_sock_set_tmp_dh_from_pkey helper function This helper function will only be used with OpenSSLv3. It simply sets in an SSL_CTX a set of DH parameters of the same size as a certificate's private key. This logic is the same as the one used with older versions, it simply relies on new APIs. If no pkey can be found the SSL_CTX_set_dh_auto function wll be called, making the SSL_CTX rely on DH parameters provided by OpenSSL in case of DHE negotiation.
2022-02-11 06:04:51 -05:00
#if (HA_OPENSSL_VERSION_NUMBER >= 0x3000000fL)
REORG: ssl: move 'generate-certificates' code to ssl_gencert.c A lot of code specific to the 'generate-certificates' option was left in ssl_sock.c. Move the code to 'ssl_gencert.c' and 'ssl_gencert.h'
2024-01-12 09:23:49 -05:00
void ssl_sock_set_tmp_dh_from_pkey(SSL_CTX *ctx, EVP_PKEY *pkey)
MINOR: ssl: Add ssl_sock_set_tmp_dh_from_pkey helper function This helper function will only be used with OpenSSLv3. It simply sets in an SSL_CTX a set of DH parameters of the same size as a certificate's private key. This logic is the same as the one used with older versions, it simply relies on new APIs. If no pkey can be found the SSL_CTX_set_dh_auto function wll be called, making the SSL_CTX rely on DH parameters provided by OpenSSL in case of DHE negotiation.
2022-02-11 06:04:51 -05:00
{
HASSL_DH *dh = NULL;
if (pkey && (dh = ssl_get_tmp_dh(pkey))) {
HASSL_DH_up_ref(dh);
if (!SSL_CTX_set0_tmp_dh_pkey(ctx, dh))
HASSL_DH_free(dh);
}
}
#endif
MINOR: ssl: Add ssl_sock_get_dh_from_bio helper function This new function makes use of the new OpenSSLv3 APIs that should be used to load DH parameters from a file (or a BIO in this case) and that should replace the deprecated PEM_read_bio_DHparams function. Note that this function returns an EVP_PKEY when using OpenSSLv3 since they now advise against using low level structures such as DH ones. This helper function is not used yet so this commit should be stricly iso-functional, regardless of the OpenSSL version.
2022-02-11 06:04:48 -05:00
HASSL_DH *ssl_sock_get_dh_from_bio(BIO *bio)
{
#if (HA_OPENSSL_VERSION_NUMBER >= 0x3000000fL)
HASSL_DH *dh = NULL;
OSSL_DECODER_CTX *dctx = NULL;
const char *format = "PEM";
const char *keytype = "DH";
dctx = OSSL_DECODER_CTX_new_for_pkey(&dh, format, NULL, keytype,
OSSL_KEYMGMT_SELECT_DOMAIN_PARAMETERS,
NULL, NULL);
if (dctx == NULL || OSSL_DECODER_CTX_get_num_decoders(dctx) == 0)
goto end;
/* The DH parameters might not be the first section found in the PEM
* file so we need to iterate over all of them until we find the right
* one.
*/
while (!BIO_eof(bio) && !dh)
OSSL_DECODER_from_bio(dctx, bio);
end:
OSSL_DECODER_CTX_free(dctx);
return dh;
#else
HASSL_DH *dh = NULL;
dh = PEM_read_bio_DHparams(bio, NULL, NULL, NULL);
return dh;
#endif
}
MEDIUM: ssl: Replace all DH objects by EVP_PKEY on OpenSSLv3 (via HASSL_DH type) DH structure is a low-level one that should not be used anymore with OpenSSLv3. All functions working on DH were marked as deprecated and this patch replaces the ones we used with new APIs recommended in OpenSSLv3, be it in the migration guide or the multiple new manpages they created. This patch replaces all mentions of the DH type by the HASSL_DH one, which will be replaced by EVP_PKEY with OpenSSLv3 and will remain DH on older versions. It also uses all the newly created helper functions that enable for instance to load DH parameters from a file into an EVP_PKEY, or to set DH parameters into an SSL_CTX for use in a DHE negotiation. The following deprecated functions will effectively disappear when building with OpenSSLv3 : DH_set0_pqg, PEM_read_bio_DHparams, DH_new, DH_free, DH_up_ref, SSL_CTX_set_tmp_dh.
2022-02-11 06:04:55 -05:00
static HASSL_DH * ssl_sock_get_dh_from_file(const char *filename)
MINOR: ssl: try to load Diffie-Hellman parameters from cert file Feature is disabled if openssl compiled with OPENSSL_NO_DH.
2012-09-20 10:19:02 -04:00
{
MEDIUM: ssl: Replace all DH objects by EVP_PKEY on OpenSSLv3 (via HASSL_DH type) DH structure is a low-level one that should not be used anymore with OpenSSLv3. All functions working on DH were marked as deprecated and this patch replaces the ones we used with new APIs recommended in OpenSSLv3, be it in the migration guide or the multiple new manpages they created. This patch replaces all mentions of the DH type by the HASSL_DH one, which will be replaced by EVP_PKEY with OpenSSLv3 and will remain DH on older versions. It also uses all the newly created helper functions that enable for instance to load DH parameters from a file into an EVP_PKEY, or to set DH parameters into an SSL_CTX for use in a DHE negotiation. The following deprecated functions will effectively disappear when building with OpenSSLv3 : DH_set0_pqg, PEM_read_bio_DHparams, DH_new, DH_free, DH_up_ref, SSL_CTX_set_tmp_dh.
2022-02-11 06:04:55 -05:00
HASSL_DH *dh = NULL;
MEDIUM: ssl: add the possibility to use a global DH parameters file This patch adds the ssl-dh-param-file global setting. It sets the default DH parameters that will be used during the SSL/TLS handshake when ephemeral Diffie-Hellman (DHE) key exchange is used, for all "bind" lines which do not explicitely define theirs.
2015-05-29 09:53:22 -04:00
BIO *in = BIO_new(BIO_s_file());
MINOR: ssl: try to load Diffie-Hellman parameters from cert file Feature is disabled if openssl compiled with OPENSSL_NO_DH.
2012-09-20 10:19:02 -04:00
if (in == NULL)
goto end;
MEDIUM: ssl: add the possibility to use a global DH parameters file This patch adds the ssl-dh-param-file global setting. It sets the default DH parameters that will be used during the SSL/TLS handshake when ephemeral Diffie-Hellman (DHE) key exchange is used, for all "bind" lines which do not explicitely define theirs.
2015-05-29 09:53:22 -04:00
if (BIO_read_filename(in, filename) <= 0)
MINOR: ssl: try to load Diffie-Hellman parameters from cert file Feature is disabled if openssl compiled with OPENSSL_NO_DH.
2012-09-20 10:19:02 -04:00
goto end;
MEDIUM: ssl: Replace all DH objects by EVP_PKEY on OpenSSLv3 (via HASSL_DH type) DH structure is a low-level one that should not be used anymore with OpenSSLv3. All functions working on DH were marked as deprecated and this patch replaces the ones we used with new APIs recommended in OpenSSLv3, be it in the migration guide or the multiple new manpages they created. This patch replaces all mentions of the DH type by the HASSL_DH one, which will be replaced by EVP_PKEY with OpenSSLv3 and will remain DH on older versions. It also uses all the newly created helper functions that enable for instance to load DH parameters from a file into an EVP_PKEY, or to set DH parameters into an SSL_CTX for use in a DHE negotiation. The following deprecated functions will effectively disappear when building with OpenSSLv3 : DH_set0_pqg, PEM_read_bio_DHparams, DH_new, DH_free, DH_up_ref, SSL_CTX_set_tmp_dh.
2022-02-11 06:04:55 -05:00
dh = ssl_sock_get_dh_from_bio(in);
MEDIUM: ssl: add the possibility to use a global DH parameters file This patch adds the ssl-dh-param-file global setting. It sets the default DH parameters that will be used during the SSL/TLS handshake when ephemeral Diffie-Hellman (DHE) key exchange is used, for all "bind" lines which do not explicitely define theirs.
2015-05-29 09:53:22 -04:00
end:
if (in)
BIO_free(in);
BUG/MEDIUM: ssl: loading dh param from certifile causes unpredictable error. If the dh parameter is not found, the openssl's error global stack was not correctly cleared causing unpredictable error during the following parsing (chain cert parsing for instance). This patch should be backported in 1.8 (and perhaps 1.7)
2018-08-16 09:14:12 -04:00
ERR_clear_error();
MEDIUM: ssl: add the possibility to use a global DH parameters file This patch adds the ssl-dh-param-file global setting. It sets the default DH parameters that will be used during the SSL/TLS handshake when ephemeral Diffie-Hellman (DHE) key exchange is used, for all "bind" lines which do not explicitely define theirs.
2015-05-29 09:53:22 -04:00
return dh;
}
int ssl_sock_load_global_dh_param_from_file(const char *filename)
{
global_dh = ssl_sock_get_dh_from_file(filename);
if (global_dh) {
return 0;
}
return -1;
}
MINOR: ssl: try to load Diffie-Hellman parameters from cert file Feature is disabled if openssl compiled with OPENSSL_NO_DH.
2012-09-20 10:19:02 -04:00
#endif
MEDIUM: ssl: introduce the ckch instance structure struct ckch_inst represents an instance of a certificate (ckch_node) used in a bind_conf. Every sni_ctx created for 1 ckch_node in a bind_conf are linked in this structure. This patch allocate the ckch_inst for each bind_conf and inserts the sni_ctx in its linked list.
2019-10-03 18:29:42 -04:00
/* This function allocates a sni_ctx and adds it to the ckch_inst */
MEDIUM: ssl: split ssl_sock_add_cert_sni() In order to allow the creation of sni_ctx in runtime, we need to split the function to allow rollback. We need to be able to allocate all sni_ctxs required before inserting them in case we need to rollback if we didn't succeed the allocation. The function was splitted in 2 parts. The first one ckch_inst_add_cert_sni() allocates a struct sni_ctx, fill it with the right data and insert it in the ckch_inst's list of sni_ctx. The second will take every sni_ctx in the ckch_inst and insert them in the bind_conf's sni tree.
2019-10-03 18:53:29 -04:00
static int ckch_inst_add_cert_sni(SSL_CTX *ctx, struct ckch_inst *ckch_inst,
MEDIUM: ssl: introduce the ckch instance structure struct ckch_inst represents an instance of a certificate (ckch_node) used in a bind_conf. Every sni_ctx created for 1 ckch_node in a bind_conf are linked in this structure. This patch allocate the ckch_inst for each bind_conf and inserts the sni_ctx in its linked list.
2019-10-03 18:29:42 -04:00
struct bind_conf *s, struct ssl_bind_conf *conf,
struct pkey_info kinfo, char *name, int order)
MEDIUM: ssl: add mapping from SNI to cert file using "crt-list" It designates a list of PEM file with an optional list of SNI filter per certificate, with the following format for each line : <crtfile>[ <snifilter>]* Wildcards are supported in the SNI filter. The certificates will be presented to clients who provide a valid TLS Server Name Indication field matching one of SNI filter. If no SNI filter is specified the CN and alt subjects are used.
2013-01-22 09:31:15 -05:00
{
struct sni_ctx *sc;
MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection This patch changes the default certificate mechanism. Since the beginning of SSL in HAProxy, the default certificate was the first certificate of a bind line. This allowed to fallback on this certificate when no servername extension was sent by the server, or when no SAN nor CN was available in the certificate. When using a multi-certificate bundle (ecdsa+rsa), it was possible to have both certificates as the fallback one, leting openssl chose the right one. This was possible because a multi-certificate bundle was generating a unique SSL_CTX for both certificates. When the haproxy and openssl architecture evolved, we decided to use multiple SSL_CTX for a multi-cert bundle, in order to simplify the code and allow updates over the CLI. However only one default_ctx was allowed, so we lost the ability to chose between ECDSA and RSA for the default certificate. This patch allows to use a '*' filter for a certificate, which allow to lookup between multiple '*' filter, and have one in RSA and another one in ECDSA. It replaces the default_ctx mechanism in the ClientHello callback and use the standard algorithm to look for a default cert and chose between ECDSA and RSA. /!\ This patch breaks the automatic setting of the default certificate, which will be introduce in the next patch. So the first certificate of a bind line won't be used as a defaullt anymore. To use this feature, one could use crt-list with '*' filters: $ cat foo.crtlist foobar.pem.rsa * foobar.pem.ecdsa * In order to test the feature, it's easy to send a request without the servername extension and use ECDSA or RSA compatible ciphers: $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-RSA-AES256-GCM-SHA384 $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-ECDSA-AES256-GCM-SHA384
2024-01-10 08:05:59 -05:00
int wild = 0, neg = 0, default_crt = 0;
MEDIUM: ssl: improve crt-list format to support negation Improve the crt-list file format to allow a rule to negate a certain SNI : <crtfile> [[!]<snifilter> ...] This can be useful when a domain supports a wildcard but you don't want to deliver the wildcard cert for certain specific domains.
2013-05-07 14:20:06 -04:00
if (*name == '!') {
neg = 1;
name++;
}
if (*name == '*') {
wild = 1;
name++;
MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection This patch changes the default certificate mechanism. Since the beginning of SSL in HAProxy, the default certificate was the first certificate of a bind line. This allowed to fallback on this certificate when no servername extension was sent by the server, or when no SAN nor CN was available in the certificate. When using a multi-certificate bundle (ecdsa+rsa), it was possible to have both certificates as the fallback one, leting openssl chose the right one. This was possible because a multi-certificate bundle was generating a unique SSL_CTX for both certificates. When the haproxy and openssl architecture evolved, we decided to use multiple SSL_CTX for a multi-cert bundle, in order to simplify the code and allow updates over the CLI. However only one default_ctx was allowed, so we lost the ability to chose between ECDSA and RSA for the default certificate. This patch allows to use a '*' filter for a certificate, which allow to lookup between multiple '*' filter, and have one in RSA and another one in ECDSA. It replaces the default_ctx mechanism in the ClientHello callback and use the standard algorithm to look for a default cert and chose between ECDSA and RSA. /!\ This patch breaks the automatic setting of the default certificate, which will be introduce in the next patch. So the first certificate of a bind line won't be used as a defaullt anymore. To use this feature, one could use crt-list with '*' filters: $ cat foo.crtlist foobar.pem.rsa * foobar.pem.ecdsa * In order to test the feature, it's easy to send a request without the servername extension and use ECDSA or RSA compatible ciphers: $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-RSA-AES256-GCM-SHA384 $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-ECDSA-AES256-GCM-SHA384
2024-01-10 08:05:59 -05:00
/* if this was only a '*' filter, this is a default cert */
if (!*name)
default_crt = 1;
MEDIUM: ssl: improve crt-list format to support negation Improve the crt-list file format to allow a rule to negate a certain SNI : <crtfile> [[!]<snifilter> ...] This can be useful when a domain supports a wildcard but you don't want to deliver the wildcard cert for certain specific domains.
2013-05-07 14:20:06 -04:00
}
/* !* filter is a nop */
if (neg && wild)
return order;
MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection This patch changes the default certificate mechanism. Since the beginning of SSL in HAProxy, the default certificate was the first certificate of a bind line. This allowed to fallback on this certificate when no servername extension was sent by the server, or when no SAN nor CN was available in the certificate. When using a multi-certificate bundle (ecdsa+rsa), it was possible to have both certificates as the fallback one, leting openssl chose the right one. This was possible because a multi-certificate bundle was generating a unique SSL_CTX for both certificates. When the haproxy and openssl architecture evolved, we decided to use multiple SSL_CTX for a multi-cert bundle, in order to simplify the code and allow updates over the CLI. However only one default_ctx was allowed, so we lost the ability to chose between ECDSA and RSA for the default certificate. This patch allows to use a '*' filter for a certificate, which allow to lookup between multiple '*' filter, and have one in RSA and another one in ECDSA. It replaces the default_ctx mechanism in the ClientHello callback and use the standard algorithm to look for a default cert and chose between ECDSA and RSA. /!\ This patch breaks the automatic setting of the default certificate, which will be introduce in the next patch. So the first certificate of a bind line won't be used as a defaullt anymore. To use this feature, one could use crt-list with '*' filters: $ cat foo.crtlist foobar.pem.rsa * foobar.pem.ecdsa * In order to test the feature, it's easy to send a request without the servername extension and use ECDSA or RSA compatible ciphers: $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-RSA-AES256-GCM-SHA384 $ openssl s_client -connect localhost:8443 -tls1_2 -cipher ECDHE-ECDSA-AES256-GCM-SHA384
2024-01-10 08:05:59 -05:00
if (*name || default_crt) {
MEDIUM: ssl: improve crt-list format to support negation Improve the crt-list file format to allow a rule to negate a certain SNI : <crtfile> [[!]<snifilter> ...] This can be useful when a domain supports a wildcard but you don't want to deliver the wildcard cert for certain specific domains.
2013-05-07 14:20:06 -04:00
int j, len;
len = strlen(name);
BUG/MINOR: ssl: prevent multiple entries for the same certificate Today, the certificate are indexed int he SNI tree using their CN and the list of thier AltNames. So, Some certificates have the same names in the CN and one of the AltNames entries. Typically Let's Encrypt duplicate the the DNS name in the CN and the AltName. This patch prevents the creation of identical entries in the trees. It checks the same DNS name and the same SSL context. If the same certificate is registered two time it will be duplicated. This patch should be backported in the 1.6 and 1.5 version.
2016-10-06 04:56:48 -04:00
for (j = 0; j < len && j < trash.size; j++)
BUILD: tree-wide: cast arguments to tolower/toupper to unsigned char NetBSD apparently uses macros for tolower/toupper and complains about the use of char for array subscripts. Let's properly cast all of them to unsigned char where they are used. This is needed to fix issue #729.
2020-07-05 15:46:32 -04:00
trash.area[j] = tolower((unsigned char)name[j]);
BUG/MINOR: ssl: prevent multiple entries for the same certificate Today, the certificate are indexed int he SNI tree using their CN and the list of thier AltNames. So, Some certificates have the same names in the CN and one of the AltNames entries. Typically Let's Encrypt duplicate the the DNS name in the CN and the AltName. This patch prevents the creation of identical entries in the trees. It checks the same DNS name and the same SSL context. If the same certificate is registered two time it will be duplicated. This patch should be backported in the 1.6 and 1.5 version.
2016-10-06 04:56:48 -04:00
if (j >= trash.size)
BUG/MINOR: ssl: abort on sni allocation failure The ssl_sock_add_cert_sni() function never return an error when a sni_ctx allocation fail. It silently ignores the problem and continues to try to allocate other snis. It is unlikely that a sni allocation will succeed after one failure and start a configuration without all the snis. But to avoid any problem we return a -1 upon an sni allocation error and stop the configuration parsing. This patch must be backported in every version supporting the crt-list sni filters. (as far as 1.5)
2019-10-03 17:46:33 -04:00
return -1;
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
trash.area[j] = 0;
BUG/MINOR: ssl: prevent multiple entries for the same certificate Today, the certificate are indexed int he SNI tree using their CN and the list of thier AltNames. So, Some certificates have the same names in the CN and one of the AltNames entries. Typically Let's Encrypt duplicate the the DNS name in the CN and the AltName. This patch prevents the creation of identical entries in the trees. It checks the same DNS name and the same SSL context. If the same certificate is registered two time it will be duplicated. This patch should be backported in the 1.6 and 1.5 version.
2016-10-06 04:56:48 -04:00
MEDIUM: ssl: add mapping from SNI to cert file using "crt-list" It designates a list of PEM file with an optional list of SNI filter per certificate, with the following format for each line : <crtfile>[ <snifilter>]* Wildcards are supported in the SNI filter. The certificates will be presented to clients who provide a valid TLS Server Name Indication field matching one of SNI filter. If no SNI filter is specified the CN and alt subjects are used.
2013-01-22 09:31:15 -05:00
sc = malloc(sizeof(struct sni_ctx) + len + 1);
BUG/MINOR: ssl: Check malloc return code If malloc() can't allocate memory and return NULL, a segfaut will raises. This patch should be backported in the 1.6 and 1.5 version.
2016-10-06 04:35:29 -04:00
if (!sc)
BUG/MINOR: ssl: abort on sni allocation failure The ssl_sock_add_cert_sni() function never return an error when a sni_ctx allocation fail. It silently ignores the problem and continues to try to allocate other snis. It is unlikely that a sni allocation will succeed after one failure and start a configuration without all the snis. But to avoid any problem we return a -1 upon an sni allocation error and stop the configuration parsing. This patch must be backported in every version supporting the crt-list sni filters. (as far as 1.5)
2019-10-03 17:46:33 -04:00
return -1;
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
memcpy(sc->name.key, trash.area, len + 1);
CLEANUP: ssl: use the refcount for the SSL_CTX' Use the refcount of the SSL_CTX' to free them instead of freeing them on certains conditions. That way we can free the SSL_CTX everywhere its pointer is used.
2020-04-08 10:11:26 -04:00
SSL_CTX_up_ref(ctx);
MEDIUM: ssl: add mapping from SNI to cert file using "crt-list" It designates a list of PEM file with an optional list of SNI filter per certificate, with the following format for each line : <crtfile>[ <snifilter>]* Wildcards are supported in the SNI filter. The certificates will be presented to clients who provide a valid TLS Server Name Indication field matching one of SNI filter. If no SNI filter is specified the CN and alt subjects are used.
2013-01-22 09:31:15 -05:00
sc->ctx = ctx;
MAJOR: ssl: bind configuration per certificat crt-list is extend to support ssl configuration. You can now have such line in crt-list <file>: mycert.pem [npn h2,http/1.1] Support include "npn", "alpn", "verify", "ca_file", "crl_file", "ecdhe", "ciphers" configuration and ssl options. "crt-base" is also supported to fetch certificates.
2016-12-29 12:26:15 -05:00
sc->conf = conf;
MINOR: ssl: extract full pkey info in load_certificate Private key information is used in switchctx to implement native multicert selection (ecdsa/rsa/anonymous). This patch extract and store full pkey information: dsa type and pkey size in bits. This can be used for switchctx or to report pkey informations in ppv2 and log.
2017-10-27 12:43:29 -04:00
sc->kinfo = kinfo;
MEDIUM: ssl: improve crt-list format to support negation Improve the crt-list file format to allow a rule to negate a certain SNI : <crtfile> [[!]<snifilter> ...] This can be useful when a domain supports a wildcard but you don't want to deliver the wildcard cert for certain specific domains.
2013-05-07 14:20:06 -04:00
sc->order = order++;
sc->neg = neg;
MEDIUM: ssl: split ssl_sock_add_cert_sni() In order to allow the creation of sni_ctx in runtime, we need to split the function to allow rollback. We need to be able to allocate all sni_ctxs required before inserting them in case we need to rollback if we didn't succeed the allocation. The function was splitted in 2 parts. The first one ckch_inst_add_cert_sni() allocates a struct sni_ctx, fill it with the right data and insert it in the ckch_inst's list of sni_ctx. The second will take every sni_ctx in the ckch_inst and insert them in the bind_conf's sni tree.
2019-10-03 18:53:29 -04:00
sc->wild = wild;
sc->name.node.leaf_p = NULL;
MINOR: ssl: reach a ckch_store from a sni_ctx It was only possible to go down from the ckch_store to the sni_ctx but not to go up from the sni_ctx to the ckch_store. To allow that, 2 pointers were added: - a ckch_inst pointer in the struct sni_ctx - a ckckh_store pointer in the struct ckch_inst
2020-03-05 04:17:47 -05:00
sc->ckch_inst = ckch_inst;
CLEANUP: lists/tree-wide: rename some list operations to avoid some confusion The current "ADD" vs "ADDQ" is confusing because when thinking in terms of appending at the end of a list, "ADD" naturally comes to mind, but here it does the opposite, it inserts. Several times already it's been incorrectly used where ADDQ was expected, the latest of which was a fortunate accident explained in 6fa922562 ("CLEANUP: stream: explain why we queue the stream at the head of the server list"). Let's use more explicit (but slightly longer) names now: LIST_ADD -> LIST_INSERT LIST_ADDQ -> LIST_APPEND LIST_ADDED -> LIST_INLIST LIST_DEL -> LIST_DELETE The same is true for MT_LISTs, including their "TRY" variant. LIST_DEL_INIT keeps its short name to encourage to use it instead of the lazier LIST_DELETE which is often less safe. The change is large (~674 non-comment entries) but is mechanical enough to remain safe. No permutation was performed, so any out-of-tree code can easily map older names to new ones. The list doc was updated.
2021-04-21 01:32:39 -04:00
LIST_APPEND(&ckch_inst->sni_ctx, &sc->by_ckch_inst);
MEDIUM: ssl: add mapping from SNI to cert file using "crt-list" It designates a list of PEM file with an optional list of SNI filter per certificate, with the following format for each line : <crtfile>[ <snifilter>]* Wildcards are supported in the SNI filter. The certificates will be presented to clients who provide a valid TLS Server Name Indication field matching one of SNI filter. If no SNI filter is specified the CN and alt subjects are used.
2013-01-22 09:31:15 -05:00
}
return order;
}
MEDIUM: ssl: split ssl_sock_add_cert_sni() In order to allow the creation of sni_ctx in runtime, we need to split the function to allow rollback. We need to be able to allocate all sni_ctxs required before inserting them in case we need to rollback if we didn't succeed the allocation. The function was splitted in 2 parts. The first one ckch_inst_add_cert_sni() allocates a struct sni_ctx, fill it with the right data and insert it in the ckch_inst's list of sni_ctx. The second will take every sni_ctx in the ckch_inst and insert them in the bind_conf's sni tree.
2019-10-03 18:53:29 -04:00
/*
* Insert the sni_ctxs that are listed in the ckch_inst, in the bind_conf's sni_ctx tree
* This function can't return an error.
*
* *CAUTION*: The caller must lock the sni tree if called in multithreading mode
*/
REORG: ssl: move the crt-list CLI functions in src/ssl_crtlist.c Move the crtlist functions for the CLI to src/ssl_crtlist.c
2020-05-13 11:23:59 -04:00
void ssl_sock_load_cert_sni(struct ckch_inst *ckch_inst, struct bind_conf *bind_conf)
MEDIUM: ssl: split ssl_sock_add_cert_sni() In order to allow the creation of sni_ctx in runtime, we need to split the function to allow rollback. We need to be able to allocate all sni_ctxs required before inserting them in case we need to rollback if we didn't succeed the allocation. The function was splitted in 2 parts. The first one ckch_inst_add_cert_sni() allocates a struct sni_ctx, fill it with the right data and insert it in the ckch_inst's list of sni_ctx. The second will take every sni_ctx in the ckch_inst and insert them in the bind_conf's sni tree.
2019-10-03 18:53:29 -04:00
{
struct sni_ctx *sc0, *sc0b, *sc1;
struct ebmb_node *node;
list_for_each_entry_safe(sc0, sc0b, &ckch_inst->sni_ctx, by_ckch_inst) {
/* ignore if sc0 was already inserted in a tree */
if (sc0->name.node.leaf_p)
continue;
/* Check for duplicates. */
if (sc0->wild)
node = ebst_lookup(&bind_conf->sni_w_ctx, (char *)sc0->name.key);
else
node = ebst_lookup(&bind_conf->sni_ctx, (char *)sc0->name.key);
for (; node; node = ebmb_next_dup(node)) {
sc1 = ebmb_entry(node, struct sni_ctx, name);
if (sc1->ctx == sc0->ctx && sc1->conf == sc0->conf
&& sc1->neg == sc0->neg && sc1->wild == sc0->wild) {
/* it's a duplicate, we should remove and free it */
CLEANUP: lists/tree-wide: rename some list operations to avoid some confusion The current "ADD" vs "ADDQ" is confusing because when thinking in terms of appending at the end of a list, "ADD" naturally comes to mind, but here it does the opposite, it inserts. Several times already it's been incorrectly used where ADDQ was expected, the latest of which was a fortunate accident explained in 6fa922562 ("CLEANUP: stream: explain why we queue the stream at the head of the server list"). Let's use more explicit (but slightly longer) names now: LIST_ADD -> LIST_INSERT LIST_ADDQ -> LIST_APPEND LIST_ADDED -> LIST_INLIST LIST_DEL -> LIST_DELETE The same is true for MT_LISTs, including their "TRY" variant. LIST_DEL_INIT keeps its short name to encourage to use it instead of the lazier LIST_DELETE which is often less safe. The change is large (~674 non-comment entries) but is mechanical enough to remain safe. No permutation was performed, so any out-of-tree code can easily map older names to new ones. The list doc was updated.
2021-04-21 01:32:39 -04:00
LIST_DELETE(&sc0->by_ckch_inst);
CLEANUP: ssl: use the refcount for the SSL_CTX' Use the refcount of the SSL_CTX' to free them instead of freeing them on certains conditions. That way we can free the SSL_CTX everywhere its pointer is used.
2020-04-08 10:11:26 -04:00
SSL_CTX_free(sc0->ctx);
CLEANUP: tree-wide: replace free(x);x=NULL with ha_free(&x) This makes the code more readable and less prone to copy-paste errors. In addition, it allows to place some __builtin_constant_p() predicates to trigger a link-time error in case the compiler knows that the freed area is constant. It will also produce compile-time error if trying to free something that is not a regular pointer (e.g. a function). The DEBUG_MEM_STATS macro now also defines an instance for ha_free() so that all these calls can be checked. 178 occurrences were converted. The vast majority of them were handled by the following Coccinelle script, some slightly refined to better deal with "&*x" or with long lines: @ rule @ expression E; @@ - free(E); - E = NULL; + ha_free(&E); It was verified that the resulting code is the same, more or less a handful of cases where the compiler optimized slightly differently the temporary variable that holds the copy of the pointer. A non-negligible amount of {free(str);str=NULL;str_len=0;} are still present in the config part (mostly header names in proxies). These ones should also be cleaned for the same reasons, and probably be turned into ist strings.
2021-02-20 04:46:51 -05:00
ha_free(&sc0);
BUG/MEDIUM: ssl: NULL dereference in ssl_sock_load_cert_sni() A NULL dereference can occur when inserting SNIs. In the case of checking for duplicates, if there is already several sni_ctx with the same key. Fix issue #321.
2019-10-14 04:46:58 -04:00
break;
MEDIUM: ssl: split ssl_sock_add_cert_sni() In order to allow the creation of sni_ctx in runtime, we need to split the function to allow rollback. We need to be able to allocate all sni_ctxs required before inserting them in case we need to rollback if we didn't succeed the allocation. The function was splitted in 2 parts. The first one ckch_inst_add_cert_sni() allocates a struct sni_ctx, fill it with the right data and insert it in the ckch_inst's list of sni_ctx. The second will take every sni_ctx in the ckch_inst and insert them in the bind_conf's sni tree.
2019-10-03 18:53:29 -04:00
}
}
/* if duplicate, ignore the insertion */
if (!sc0)
continue;
if (sc0->wild)
ebst_insert(&bind_conf->sni_w_ctx, &sc0->name);
else
ebst_insert(&bind_conf->sni_ctx, &sc0->name);
BUG/MINOR: ssl: Fix update of default certificate The default SSL_CTX used by a specific frontend is the one of the first ckch instance created for this frontend. If this instance has SNIs, then the SSL context is linked to the instance through the list of SNIs contained in it. If the instance does not have any SNIs though, then the SSL_CTX is only referenced by the bind_conf structure and the instance itself has no link to it. When trying to update a certificate used by the default instance through a cli command, a new version of the default instance was rebuilt but the default SSL context referenced in the bind_conf structure would not be changed, resulting in a buggy behavior in which depending on the SNI used by the client, he could either use the new version of the updated certificate or the original one. This patch adds a reference to the default SSL context in the default ckch instances so that it can be hot swapped during a certificate update. This should fix GitHub issue #1143. It can be backported as far as 2.2.
2021-03-17 09:56:54 -04:00
}
MEDIUM: ssl: split ssl_sock_add_cert_sni() In order to allow the creation of sni_ctx in runtime, we need to split the function to allow rollback. We need to be able to allocate all sni_ctxs required before inserting them in case we need to rollback if we didn't succeed the allocation. The function was splitted in 2 parts. The first one ckch_inst_add_cert_sni() allocates a struct sni_ctx, fill it with the right data and insert it in the ckch_inst's list of sni_ctx. The second will take every sni_ctx in the ckch_inst and insert them in the bind_conf's sni tree.
2019-10-03 18:53:29 -04:00
}
MEDIUM: ssl: lookup and store in a ckch_node tree Don't read a certificate file again if it was already stored in the ckchn tree. It allows HAProxy to start more quickly if the same certificate is used at different places in the configuration. HAProxy lookup in the ssl_sock_load_cert() function, doing it at this level allows to skip the reading of the certificate in the filesystem. If the certificate is not found in the tree, we insert the ckch_node in the tree once the certificate is read on the filesystem, the filename or the bundle name is used as the key.
2019-07-23 09:00:54 -04:00
/*
REORG: ssl: rename ckch_node to ckch_store A ckch_store is a storage which contains a pointer to one or several cert_key_and_chain structures. This patch renames ckch_node to ckch_store, and ckch_n, ckchn to ckchs.
2019-10-08 05:36:53 -04:00
* tree used to store the ckchs ordered by filename/bundle name
MEDIUM: ssl: lookup and store in a ckch_node tree Don't read a certificate file again if it was already stored in the ckchn tree. It allows HAProxy to start more quickly if the same certificate is used at different places in the configuration. HAProxy lookup in the ssl_sock_load_cert() function, doing it at this level allows to skip the reading of the certificate in the filesystem. If the certificate is not found in the tree, we insert the ckch_node in the tree once the certificate is read on the filesystem, the filename or the bundle name is used as the key.
2019-07-23 09:00:54 -04:00
*/
REORG: ssl: rename ckch_node to ckch_store A ckch_store is a storage which contains a pointer to one or several cert_key_and_chain structures. This patch renames ckch_node to ckch_store, and ckch_n, ckchn to ckchs.
2019-10-08 05:36:53 -04:00
struct eb_root ckchs_tree = EB_ROOT_UNIQUE;
MEDIUM: ssl: lookup and store in a ckch_node tree Don't read a certificate file again if it was already stored in the ckchn tree. It allows HAProxy to start more quickly if the same certificate is used at different places in the configuration. HAProxy lookup in the ssl_sock_load_cert() function, doing it at this level allows to skip the reading of the certificate in the filesystem. If the certificate is not found in the tree, we insert the ckch_node in the tree once the certificate is read on the filesystem, the filename or the bundle name is used as the key.
2019-07-23 09:00:54 -04:00
MEDIUM: ssl: allow crt-list caching The crtlist structure defines a crt-list in the HAProxy configuration. It contains crtlist_entry structures which are the lines in a crt-list file. crt-list are now loaded in memory using crtlist and crtlist_entry structures. The file is read only once. The generation algorithm changed a little bit, new ckch instances are generated from the crtlist structures, instead of being generated during the file loading. The loading function was split in two, one that loads and caches the crt-list and certificates, and one that looks for a crt-list and creates the ckch instances. Filters are also stored in crtlist_entry->filters as a char ** so we can generate the sni_ctx again if needed. I won't be needed anymore to parse the sni_ctx to do that. A crtlist_entry stores the list of all ckch_inst that were generated from this entry.
2020-03-06 15:54:13 -05:00
/* tree of crtlist (crt-list/directory) */
REORG: ssl: move the crt-list CLI functions in src/ssl_crtlist.c Move the crtlist functions for the CLI to src/ssl_crtlist.c
2020-05-13 11:23:59 -04:00
struct eb_root crtlists_tree = EB_ROOT_UNIQUE;
MEDIUM: ssl: Added support for creating SSL_CTX with multiple certs Added ability for users to specify multiple certificates that all relate a single server. Users do this by specifying certificate "cert_name.pem" but having "cert_name.pem.rsa", "cert_name.pem.dsa" and/or "cert_name.pem.ecdsa" in the directory. HAProxy will now intelligently search for those 3 files and try combine them into as few SSL_CTX's as possible based on CN/SAN. This will allow HAProxy to support multiple ciphersuite key algorithms off a single SSL_CTX. This change integrates into the existing architecture of SNI lookup and multiple SNI's can point to the same SSL_CTX, which can support multiple key_types.
2015-12-02 13:01:29 -05:00
CLEANUP: ssl: make ssl_sock_load_dh_params handle errcode/warn ssl_sock_load_dh_params used to return >0 or -1 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, this is the only code returned for now. An error message was added in the case of failure and the comment was updated.
2019-10-17 07:27:40 -04:00
/* Loads Diffie-Hellman parameter from a ckchs to an SSL_CTX.
CLEANUP: assorted typo fixes in the code and comments These are mostly comments in the code. A few error messages were fixed and are of low enough importance not to deserve a backport. Some regtests were also fixed.
2020-03-10 03:06:11 -04:00
* If there is no DH parameter available in the ckchs, the global
CLEANUP: ssl: make ssl_sock_load_dh_params handle errcode/warn ssl_sock_load_dh_params used to return >0 or -1 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, this is the only code returned for now. An error message was added in the case of failure and the comment was updated.
2019-10-17 07:27:40 -04:00
* DH parameter is loaded into the SSL_CTX and if there is no
* DH parameter available in ckchs nor in global, the default
* DH parameters are applied on the SSL_CTX.
* Returns a bitfield containing the flags:
* ERR_FATAL in any fatal error case
* ERR_ALERT if a reason of the error is availabine in err
* ERR_WARN if a warning is available into err
* The value 0 means there is no error nor warning and
* the operation succeed.
*/
MEDIUM: ssl: load DH param in struct cert_key_and_chain Load the DH param at the same time as the certificate, we don't need to open the file once more and read it again. We store it in the ckch_node. There is a minor change comparing to the previous way of loading the DH param in a bundle. With a bundle, the DH param in a certificate file was never loaded, it only used the global DH or the default DH, now it's able to use the DH param from a certificate file.
2019-07-23 10:06:08 -04:00
#ifndef OPENSSL_NO_DH
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
static int ssl_sock_load_dh_params(SSL_CTX *ctx, const struct ckch_data *data,
CLEANUP: ssl: make ssl_sock_load_dh_params handle errcode/warn ssl_sock_load_dh_params used to return >0 or -1 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, this is the only code returned for now. An error message was added in the case of failure and the comment was updated.
2019-10-17 07:27:40 -04:00
const char *path, char **err)
MEDIUM: ssl: load DH param in struct cert_key_and_chain Load the DH param at the same time as the certificate, we don't need to open the file once more and read it again. We store it in the ckch_node. There is a minor change comparing to the previous way of loading the DH param in a bundle. With a bundle, the DH param in a certificate file was never loaded, it only used the global DH or the default DH, now it's able to use the DH param from a certificate file.
2019-07-23 10:06:08 -04:00
{
CLEANUP: ssl: make ssl_sock_load_dh_params handle errcode/warn ssl_sock_load_dh_params used to return >0 or -1 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, this is the only code returned for now. An error message was added in the case of failure and the comment was updated.
2019-10-17 07:27:40 -04:00
int ret = 0;
MEDIUM: ssl: Replace all DH objects by EVP_PKEY on OpenSSLv3 (via HASSL_DH type) DH structure is a low-level one that should not be used anymore with OpenSSLv3. All functions working on DH were marked as deprecated and this patch replaces the ones we used with new APIs recommended in OpenSSLv3, be it in the migration guide or the multiple new manpages they created. This patch replaces all mentions of the DH type by the HASSL_DH one, which will be replaced by EVP_PKEY with OpenSSLv3 and will remain DH on older versions. It also uses all the newly created helper functions that enable for instance to load DH parameters from a file into an EVP_PKEY, or to set DH parameters into an SSL_CTX for use in a DHE negotiation. The following deprecated functions will effectively disappear when building with OpenSSLv3 : DH_set0_pqg, PEM_read_bio_DHparams, DH_new, DH_free, DH_up_ref, SSL_CTX_set_tmp_dh.
2022-02-11 06:04:55 -05:00
HASSL_DH *dh = NULL;
MEDIUM: ssl: load DH param in struct cert_key_and_chain Load the DH param at the same time as the certificate, we don't need to open the file once more and read it again. We store it in the ckch_node. There is a minor change comparing to the previous way of loading the DH param in a bundle. With a bundle, the DH param in a certificate file was never loaded, it only used the global DH or the default DH, now it's able to use the DH param from a certificate file.
2019-07-23 10:06:08 -04:00
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
if (data && data->dh) {
dh = data->dh;
MEDIUM: ssl: Replace all DH objects by EVP_PKEY on OpenSSLv3 (via HASSL_DH type) DH structure is a low-level one that should not be used anymore with OpenSSLv3. All functions working on DH were marked as deprecated and this patch replaces the ones we used with new APIs recommended in OpenSSLv3, be it in the migration guide or the multiple new manpages they created. This patch replaces all mentions of the DH type by the HASSL_DH one, which will be replaced by EVP_PKEY with OpenSSLv3 and will remain DH on older versions. It also uses all the newly created helper functions that enable for instance to load DH parameters from a file into an EVP_PKEY, or to set DH parameters into an SSL_CTX for use in a DHE negotiation. The following deprecated functions will effectively disappear when building with OpenSSLv3 : DH_set0_pqg, PEM_read_bio_DHparams, DH_new, DH_free, DH_up_ref, SSL_CTX_set_tmp_dh.
2022-02-11 06:04:55 -05:00
if (!ssl_sock_set_tmp_dh(ctx, dh)) {
BUG/MEDIUM: ssl: 'tune.ssl.default-dh-param' value ignored with openssl > 1.1.1 If openssl 1.1.1 is used, c2aae74f0 commit mistakenly enables DH automatic feature from openssl instead of ECDH automatic feature. There is no impact for the ECDH one because the feature is always enabled for that version. But doing this, the 'tune.ssl.default-dh-param' was completely ignored for DH parameters. This patch fix the bug calling 'SSL_CTX_set_ecdh_auto' instead of 'SSL_CTX_set_dh_auto'. Currently some users may use a 2048 DH bits parameter, thinking they're using a 1024 bits one. Doing this, they may experience performance issue on light hardware. This patch warns the user if haproxy fails to configure the given DH parameter. In this case and if openssl version is > 1.1.0, haproxy will let openssl to automatically choose a default DH parameter. For other openssl versions, the DH ciphers won't be usable. A commonly case of failure is due to the security level of openssl.cnf which could refuse a 1024 bits DH parameter for a 2048 bits key: $ cat /etc/ssl/openssl.cnf ... [system_default_sect] MinProtocol = TLSv1 CipherString = DEFAULT@SECLEVEL=2 This should be backport into any branch containing the commit c2aae74f0. It requires all or part of the previous CLEANUP series. This addresses github issue #324.
2019-10-17 08:53:03 -04:00
memprintf(err, "%sunable to load the DH parameter specified in '%s'",
err && *err ? *err : "", path);
memprintf(err, "%s, DH ciphers won't be available.\n",
err && *err ? *err : "");
ret |= ERR_WARN;
goto end;
}
MEDIUM: ssl: load DH param in struct cert_key_and_chain Load the DH param at the same time as the certificate, we don't need to open the file once more and read it again. We store it in the ckch_node. There is a minor change comparing to the previous way of loading the DH param in a bundle. With a bundle, the DH param in a certificate file was never loaded, it only used the global DH or the default DH, now it's able to use the DH param from a certificate file.
2019-07-23 10:06:08 -04:00
if (ssl_dh_ptr_index >= 0) {
/* store a pointer to the DH params to avoid complaining about
ssl-default-dh-param not being set for this SSL_CTX */
SSL_CTX_set_ex_data(ctx, ssl_dh_ptr_index, dh);
}
}
else if (global_dh) {
MEDIUM: ssl: Replace all DH objects by EVP_PKEY on OpenSSLv3 (via HASSL_DH type) DH structure is a low-level one that should not be used anymore with OpenSSLv3. All functions working on DH were marked as deprecated and this patch replaces the ones we used with new APIs recommended in OpenSSLv3, be it in the migration guide or the multiple new manpages they created. This patch replaces all mentions of the DH type by the HASSL_DH one, which will be replaced by EVP_PKEY with OpenSSLv3 and will remain DH on older versions. It also uses all the newly created helper functions that enable for instance to load DH parameters from a file into an EVP_PKEY, or to set DH parameters into an SSL_CTX for use in a DHE negotiation. The following deprecated functions will effectively disappear when building with OpenSSLv3 : DH_set0_pqg, PEM_read_bio_DHparams, DH_new, DH_free, DH_up_ref, SSL_CTX_set_tmp_dh.
2022-02-11 06:04:55 -05:00
if (!ssl_sock_set_tmp_dh(ctx, global_dh)) {
BUG/MEDIUM: ssl: 'tune.ssl.default-dh-param' value ignored with openssl > 1.1.1 If openssl 1.1.1 is used, c2aae74f0 commit mistakenly enables DH automatic feature from openssl instead of ECDH automatic feature. There is no impact for the ECDH one because the feature is always enabled for that version. But doing this, the 'tune.ssl.default-dh-param' was completely ignored for DH parameters. This patch fix the bug calling 'SSL_CTX_set_ecdh_auto' instead of 'SSL_CTX_set_dh_auto'. Currently some users may use a 2048 DH bits parameter, thinking they're using a 1024 bits one. Doing this, they may experience performance issue on light hardware. This patch warns the user if haproxy fails to configure the given DH parameter. In this case and if openssl version is > 1.1.0, haproxy will let openssl to automatically choose a default DH parameter. For other openssl versions, the DH ciphers won't be usable. A commonly case of failure is due to the security level of openssl.cnf which could refuse a 1024 bits DH parameter for a 2048 bits key: $ cat /etc/ssl/openssl.cnf ... [system_default_sect] MinProtocol = TLSv1 CipherString = DEFAULT@SECLEVEL=2 This should be backport into any branch containing the commit c2aae74f0. It requires all or part of the previous CLEANUP series. This addresses github issue #324.
2019-10-17 08:53:03 -04:00
memprintf(err, "%sunable to use the global DH parameter for certificate '%s'",
err && *err ? *err : "", path);
memprintf(err, "%s, DH ciphers won't be available.\n",
err && *err ? *err : "");
ret |= ERR_WARN;
goto end;
}
MEDIUM: ssl: load DH param in struct cert_key_and_chain Load the DH param at the same time as the certificate, we don't need to open the file once more and read it again. We store it in the ckch_node. There is a minor change comparing to the previous way of loading the DH param in a bundle. With a bundle, the DH param in a certificate file was never loaded, it only used the global DH or the default DH, now it's able to use the DH param from a certificate file.
2019-07-23 10:06:08 -04:00
}
else {
/* Clear openssl global errors stack */
ERR_clear_error();
MEDIUM: ssl: Disable DHE ciphers by default DHE ciphers do not present a security risk if the key is big enough but they are slow and mostly obsoleted by ECDHE. This patch removes any default DH parameters. This will effectively disable all DHE ciphers unless a global ssl-dh-param-file is defined, or tune.ssl.default-dh-param is set, or a frontend has DH parameters included in its PEM certificate. In this latter case, only the frontends that have DH parameters will have DHE ciphers enabled. Adding explicitely a DHE ciphers in a "bind" line will not be enough to actually enable DHE. We would still need to know which DH parameters to use so one of the three conditions described above must be met. This request was described in GitHub issue #1604.
2022-04-12 05:31:55 -04:00
/* We do not want DHE ciphers to be added to the cipher list
* unless there is an explicit global dh option in the conf.
*/
if (global_ssl.default_dh_param) {
if (global_ssl.default_dh_param <= 1024) {
/* we are limited to DH parameter of 1024 bits anyway */
if (local_dh_1024 == NULL)
local_dh_1024 = ssl_get_dh_1024();
if (local_dh_1024 == NULL) {
memprintf(err, "%sunable to load default 1024 bits DH parameter for certificate '%s'.\n",
err && *err ? *err : "", path);
ret |= ERR_ALERT | ERR_FATAL;
goto end;
}
MEDIUM: ssl: load DH param in struct cert_key_and_chain Load the DH param at the same time as the certificate, we don't need to open the file once more and read it again. We store it in the ckch_node. There is a minor change comparing to the previous way of loading the DH param in a bundle. With a bundle, the DH param in a certificate file was never loaded, it only used the global DH or the default DH, now it's able to use the DH param from a certificate file.
2019-07-23 10:06:08 -04:00
MEDIUM: ssl: Disable DHE ciphers by default DHE ciphers do not present a security risk if the key is big enough but they are slow and mostly obsoleted by ECDHE. This patch removes any default DH parameters. This will effectively disable all DHE ciphers unless a global ssl-dh-param-file is defined, or tune.ssl.default-dh-param is set, or a frontend has DH parameters included in its PEM certificate. In this latter case, only the frontends that have DH parameters will have DHE ciphers enabled. Adding explicitely a DHE ciphers in a "bind" line will not be enough to actually enable DHE. We would still need to know which DH parameters to use so one of the three conditions described above must be met. This request was described in GitHub issue #1604.
2022-04-12 05:31:55 -04:00
if (!ssl_sock_set_tmp_dh(ctx, local_dh_1024)) {
memprintf(err, "%sunable to load default 1024 bits DH parameter for certificate '%s'.\n",
err && *err ? *err : "", path);
memprintf(err, "%s, DH ciphers won't be available.\n",
err && *err ? *err : "");
ret |= ERR_WARN;
goto end;
}
BUG/MEDIUM: ssl: 'tune.ssl.default-dh-param' value ignored with openssl > 1.1.1 If openssl 1.1.1 is used, c2aae74f0 commit mistakenly enables DH automatic feature from openssl instead of ECDH automatic feature. There is no impact for the ECDH one because the feature is always enabled for that version. But doing this, the 'tune.ssl.default-dh-param' was completely ignored for DH parameters. This patch fix the bug calling 'SSL_CTX_set_ecdh_auto' instead of 'SSL_CTX_set_dh_auto'. Currently some users may use a 2048 DH bits parameter, thinking they're using a 1024 bits one. Doing this, they may experience performance issue on light hardware. This patch warns the user if haproxy fails to configure the given DH parameter. In this case and if openssl version is > 1.1.0, haproxy will let openssl to automatically choose a default DH parameter. For other openssl versions, the DH ciphers won't be usable. A commonly case of failure is due to the security level of openssl.cnf which could refuse a 1024 bits DH parameter for a 2048 bits key: $ cat /etc/ssl/openssl.cnf ... [system_default_sect] MinProtocol = TLSv1 CipherString = DEFAULT@SECLEVEL=2 This should be backport into any branch containing the commit c2aae74f0. It requires all or part of the previous CLEANUP series. This addresses github issue #324.
2019-10-17 08:53:03 -04:00
}
MEDIUM: ssl: Disable DHE ciphers by default DHE ciphers do not present a security risk if the key is big enough but they are slow and mostly obsoleted by ECDHE. This patch removes any default DH parameters. This will effectively disable all DHE ciphers unless a global ssl-dh-param-file is defined, or tune.ssl.default-dh-param is set, or a frontend has DH parameters included in its PEM certificate. In this latter case, only the frontends that have DH parameters will have DHE ciphers enabled. Adding explicitely a DHE ciphers in a "bind" line will not be enough to actually enable DHE. We would still need to know which DH parameters to use so one of the three conditions described above must be met. This request was described in GitHub issue #1604.
2022-04-12 05:31:55 -04:00
else {
MINOR: ssl: Remove calls to SSL_CTX_set_tmp_dh_callback on OpenSSLv3 The SSL_CTX_set_tmp_dh_callback function was marked as deprecated in OpenSSLv3 so this patch replaces this callback mechanism by a direct set of DH parameters during init.
2022-02-11 06:04:56 -05:00
#if (HA_OPENSSL_VERSION_NUMBER < 0x3000000fL)
MEDIUM: ssl: Disable DHE ciphers by default DHE ciphers do not present a security risk if the key is big enough but they are slow and mostly obsoleted by ECDHE. This patch removes any default DH parameters. This will effectively disable all DHE ciphers unless a global ssl-dh-param-file is defined, or tune.ssl.default-dh-param is set, or a frontend has DH parameters included in its PEM certificate. In this latter case, only the frontends that have DH parameters will have DHE ciphers enabled. Adding explicitely a DHE ciphers in a "bind" line will not be enough to actually enable DHE. We would still need to know which DH parameters to use so one of the three conditions described above must be met. This request was described in GitHub issue #1604.
2022-04-12 05:31:55 -04:00
SSL_CTX_set_tmp_dh_callback(ctx, ssl_get_tmp_dh_cbk);
MINOR: ssl: Remove calls to SSL_CTX_set_tmp_dh_callback on OpenSSLv3 The SSL_CTX_set_tmp_dh_callback function was marked as deprecated in OpenSSLv3 so this patch replaces this callback mechanism by a direct set of DH parameters during init.
2022-02-11 06:04:56 -05:00
#else
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
ssl_sock_set_tmp_dh_from_pkey(ctx, data ? data->key : NULL);
MINOR: ssl: Remove calls to SSL_CTX_set_tmp_dh_callback on OpenSSLv3 The SSL_CTX_set_tmp_dh_callback function was marked as deprecated in OpenSSLv3 so this patch replaces this callback mechanism by a direct set of DH parameters during init.
2022-02-11 06:04:56 -05:00
#endif
MEDIUM: ssl: Disable DHE ciphers by default DHE ciphers do not present a security risk if the key is big enough but they are slow and mostly obsoleted by ECDHE. This patch removes any default DH parameters. This will effectively disable all DHE ciphers unless a global ssl-dh-param-file is defined, or tune.ssl.default-dh-param is set, or a frontend has DH parameters included in its PEM certificate. In this latter case, only the frontends that have DH parameters will have DHE ciphers enabled. Adding explicitely a DHE ciphers in a "bind" line will not be enough to actually enable DHE. We would still need to know which DH parameters to use so one of the three conditions described above must be met. This request was described in GitHub issue #1604.
2022-04-12 05:31:55 -04:00
}
MEDIUM: ssl: load DH param in struct cert_key_and_chain Load the DH param at the same time as the certificate, we don't need to open the file once more and read it again. We store it in the ckch_node. There is a minor change comparing to the previous way of loading the DH param in a bundle. With a bundle, the DH param in a certificate file was never loaded, it only used the global DH or the default DH, now it's able to use the DH param from a certificate file.
2019-07-23 10:06:08 -04:00
}
}
end:
BUG/MINOR: ssl: clear the SSL errors on DH loading failure In ssl_sock_load_dh_params(), if haproxy failed to apply the dhparam with SSL_CTX_set_tmp_dh(), it will apply the DH with SSL_CTX_set_dh_auto(). The problem is that we don't clean the OpenSSL errors when leaving this function so it could fail to load the certificate, even if it's only a warning. Fixes bug #483. Must be backported in 2.1.
2020-02-05 05:46:33 -05:00
ERR_clear_error();
MEDIUM: ssl: load DH param in struct cert_key_and_chain Load the DH param at the same time as the certificate, we don't need to open the file once more and read it again. We store it in the ckch_node. There is a minor change comparing to the previous way of loading the DH param in a bundle. With a bundle, the DH param in a certificate file was never loaded, it only used the global DH or the default DH, now it's able to use the DH param from a certificate file.
2019-07-23 10:06:08 -04:00
return ret;
}
#endif
MINOR: ssl: Certificate chain loading refactorization Move the certificate chain loading code into a dedicated function that will then be useable elsewhere.
2021-01-25 11:19:42 -05:00
/* Load a certificate chain into an SSL context.
CLEANUP: ssl: make ssl_sock_put_ckch_into_ctx handle errcode/warn ssl_sock_put_ckch_into_ctx used to return 0 or >0 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, this is the only code returned for now. And a comment was updated.
2019-10-17 07:25:14 -04:00
* Returns a bitfield containing the flags:
* ERR_FATAL in any fatal error case
* ERR_ALERT if the reason of the error is available in err
* ERR_WARN if a warning is available into err
BUG/MINOR: ssl: Fix memory leak of find_chain in ssl_sock_load_cert_chain The certificate chain that gets passed in the SSL_CTX through SSL_CTX_set1_chain has its reference counter increased by OpenSSL itself. But since the ssl_sock_load_cert_chain function might create a brand new certificate chain if none exists in the ckch_data (sk_X509_new_null), then we ended up returning a new certificate chain to the caller that was never destroyed. This patch can be backported to all stable branches but it might need to be reworked for branches older than 2.4 because of commit ec805a32b9 that refactorized the modified code.
2022-12-15 09:44:37 -05:00
* The caller is responsible of freeing the newly built or newly refcounted
* find_chain element.
CLEANUP: ssl: make ssl_sock_put_ckch_into_ctx handle errcode/warn ssl_sock_put_ckch_into_ctx used to return 0 or >0 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, this is the only code returned for now. And a comment was updated.
2019-10-17 07:25:14 -04:00
* The value 0 means there is no error nor warning and
* the operation succeed.
MINOR: ssl: Added cert_key_and_chain struct Added cert_key_and_chain struct to ssl. This struct will store the contents of a crt path (from the config file) into memory. This will allow us to use the data stored in memory instead of reading the file multiple times. This will be used to support a later commit to load multiple pkeys/certs into a single SSL_CTX
2015-12-01 15:16:07 -05:00
*/
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
static int ssl_sock_load_cert_chain(const char *path, const struct ckch_data *data,
MINOR: ssl: Certificate chain loading refactorization Move the certificate chain loading code into a dedicated function that will then be useable elsewhere.
2021-01-25 11:19:42 -05:00
SSL_CTX *ctx, STACK_OF(X509) **find_chain, char **err)
MINOR: ssl: Added cert_key_and_chain struct Added cert_key_and_chain struct to ssl. This struct will store the contents of a crt path (from the config file) into memory. This will allow us to use the data stored in memory instead of reading the file multiple times. This will be used to support a later commit to load multiple pkeys/certs into a single SSL_CTX
2015-12-01 15:16:07 -05:00
{
CLEANUP: ssl: make ssl_sock_put_ckch_into_ctx handle errcode/warn ssl_sock_put_ckch_into_ctx used to return 0 or >0 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, this is the only code returned for now. And a comment was updated.
2019-10-17 07:25:14 -04:00
int errcode = 0;
MINOR: ssl: ssl_sock_load_cert_chain() display error strings Display error strings when SSL_CTX_use_certificate() or SSL_CTX_set1_chain() doesn't work.
2022-11-15 10:56:03 -05:00
int ret;
ERR_clear_error();
CLEANUP: ssl: make ssl_sock_put_ckch_into_ctx handle errcode/warn ssl_sock_put_ckch_into_ctx used to return 0 or >0 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, this is the only code returned for now. And a comment was updated.
2019-10-17 07:25:14 -04:00
MINOR: ssl: Certificate chain loading refactorization Move the certificate chain loading code into a dedicated function that will then be useable elsewhere.
2021-01-25 11:19:42 -05:00
if (find_chain == NULL) {
errcode |= ERR_FATAL;
goto end;
MINOR: ssl: Added cert_key_and_chain struct Added cert_key_and_chain struct to ssl. This struct will store the contents of a crt path (from the config file) into memory. This will allow us to use the data stored in memory instead of reading the file multiple times. This will be used to support a later commit to load multiple pkeys/certs into a single SSL_CTX
2015-12-01 15:16:07 -05:00
}
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
if (!SSL_CTX_use_certificate(ctx, data->cert)) {
MINOR: ssl: ssl_sock_load_cert_chain() display error strings Display error strings when SSL_CTX_use_certificate() or SSL_CTX_set1_chain() doesn't work.
2022-11-15 10:56:03 -05:00
ret = ERR_get_error();
memprintf(err, "%sunable to load SSL certificate into SSL Context '%s': %s.\n",
err && *err ? *err : "", path, ERR_reason_error_string(ret));
CLEANUP: ssl: make ssl_sock_put_ckch_into_ctx handle errcode/warn ssl_sock_put_ckch_into_ctx used to return 0 or >0 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, this is the only code returned for now. And a comment was updated.
2019-10-17 07:25:14 -04:00
errcode |= ERR_ALERT | ERR_FATAL;
goto end;
MINOR: ssl: Added cert_key_and_chain struct Added cert_key_and_chain struct to ssl. This struct will store the contents of a crt path (from the config file) into memory. This will allow us to use the data stored in memory instead of reading the file multiple times. This will be used to support a later commit to load multiple pkeys/certs into a single SSL_CTX
2015-12-01 15:16:07 -05:00
}
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
if (data->chain) {
BUG/MINOR: ssl: Fix memory leak of find_chain in ssl_sock_load_cert_chain The certificate chain that gets passed in the SSL_CTX through SSL_CTX_set1_chain has its reference counter increased by OpenSSL itself. But since the ssl_sock_load_cert_chain function might create a brand new certificate chain if none exists in the ckch_data (sk_X509_new_null), then we ended up returning a new certificate chain to the caller that was never destroyed. This patch can be backported to all stable branches but it might need to be reworked for branches older than 2.4 because of commit ec805a32b9 that refactorized the modified code.
2022-12-15 09:44:37 -05:00
*find_chain = X509_chain_up_ref(data->chain);
MINOR: ssl: resolve issuers chain later The goal is to use the ckch to store data from a loaded PEM file or a <payload> and only for that. This patch addresses the ckch->chain case. Looking for the issuers chain, if no chain is present in the ckch, can be done in ssl_sock_put_ckch_into_ctx(). This way it is possible to know the origin of the certificate chain without an extra state.
2020-02-18 09:27:32 -05:00
} else {
/* Find Certificate Chain in global */
struct issuer_chain *issuer;
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
issuer = ssl_get0_issuer_chain(data->cert);
MINOR: ssl: resolve issuers chain later The goal is to use the ckch to store data from a loaded PEM file or a <payload> and only for that. This patch addresses the ckch->chain case. Looking for the issuers chain, if no chain is present in the ckch, can be done in ssl_sock_put_ckch_into_ctx(). This way it is possible to know the origin of the certificate chain without an extra state.
2020-02-18 09:27:32 -05:00
if (issuer)
BUG/MINOR: ssl: Fix memory leak of find_chain in ssl_sock_load_cert_chain The certificate chain that gets passed in the SSL_CTX through SSL_CTX_set1_chain has its reference counter increased by OpenSSL itself. But since the ssl_sock_load_cert_chain function might create a brand new certificate chain if none exists in the ckch_data (sk_X509_new_null), then we ended up returning a new certificate chain to the caller that was never destroyed. This patch can be backported to all stable branches but it might need to be reworked for branches older than 2.4 because of commit ec805a32b9 that refactorized the modified code.
2022-12-15 09:44:37 -05:00
*find_chain = X509_chain_up_ref(issuer->chain);
MINOR: ssl: resolve issuers chain later The goal is to use the ckch to store data from a loaded PEM file or a <payload> and only for that. This patch addresses the ckch->chain case. Looking for the issuers chain, if no chain is present in the ckch, can be done in ssl_sock_put_ckch_into_ctx(). This way it is possible to know the origin of the certificate chain without an extra state.
2020-02-18 09:27:32 -05:00
}
BUG/MEDIUM: ssl: chain must be initialized with sk_X509_new_null() Even when there isn't a chain, it must be initialized to a empty X509 structure with sk_X509_new_null(). This patch fixes a segfault which appears with older versions of the SSL libs (openssl 0.9.8, libressl 2.8.3...) because X509_chain_up_ref() does not check the pointer. This bug was introduced by b90d2cb ("MINOR: ssl: resolve issuers chain later"). Should fix issue #516.
2020-02-27 08:48:35 -05:00
MINOR: ssl: Certificate chain loading refactorization Move the certificate chain loading code into a dedicated function that will then be useable elsewhere.
2021-01-25 11:19:42 -05:00
if (!*find_chain) {
BUG/MEDIUM: ssl: never generates the chain from the verify store In bug #781 it was reported that HAProxy completes the certificate chain using the verify store in the case there is no chain. Indeed, according to OpenSSL documentation, when generating the chain, OpenSSL use the chain store OR the verify store in the case there is no chain store. As a workaround, this patch always put a NULL chain in the SSL_CTX so OpenSSL does not tries to complete it. This must be backported in all branches, the code could be different, the important part is to ALWAYS set a chain, and uses sk_X509_new_null() if the chain is NULL.
2020-08-12 14:02:10 -04:00
/* always put a null chain stack in the SSL_CTX so it does not
* try to build the chain from the verify store */
MINOR: ssl: Certificate chain loading refactorization Move the certificate chain loading code into a dedicated function that will then be useable elsewhere.
2021-01-25 11:19:42 -05:00
*find_chain = sk_X509_new_null();
BUG/MEDIUM: ssl: never generates the chain from the verify store In bug #781 it was reported that HAProxy completes the certificate chain using the verify store in the case there is no chain. Indeed, according to OpenSSL documentation, when generating the chain, OpenSSL use the chain store OR the verify store in the case there is no chain store. As a workaround, this patch always put a NULL chain in the SSL_CTX so OpenSSL does not tries to complete it. This must be backported in all branches, the code could be different, the important part is to ALWAYS set a chain, and uses sk_X509_new_null() if the chain is NULL.
2020-08-12 14:02:10 -04:00
}
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
/* Load all certs in the data into the ctx_chain for the ssl_ctx */
Revert "MINOR: ssl: rework add cert chain to CTX to be libssl independent" This reverts commit 4fed93eb725b513dd3b2029daa888311db110851. This commit was simplifying the certificate chain loading with SSL_CTX_add_extra_chain_cert() which is available in all SSL libraries. Unfortunately this function is not compatible with the multi-certificates bundles, which have the effect of concatenating the chains of all certificate types instead of creating a chain for each type (RSA, ECDSA etc.) Should fix issue #655.
2020-06-02 12:27:20 -04:00
#ifdef SSL_CTX_set1_chain
MINOR: ssl: Certificate chain loading refactorization Move the certificate chain loading code into a dedicated function that will then be useable elsewhere.
2021-01-25 11:19:42 -05:00
if (!SSL_CTX_set1_chain(ctx, *find_chain)) {
MINOR: ssl: ssl_sock_load_cert_chain() display error strings Display error strings when SSL_CTX_use_certificate() or SSL_CTX_set1_chain() doesn't work.
2022-11-15 10:56:03 -05:00
ret = ERR_get_error();
MINOR: ssl: remove OpenSSL 1.0.2 mention into certificate loading error Remove the mention to OpenSSL 1.0.2 in the certificate chain loading error, which is not relevant. Could be backported in 2.7.
2023-04-17 08:32:25 -04:00
memprintf(err, "%sunable to load chain certificate into SSL Context '%s': %s.\n",
MINOR: ssl: ssl_sock_load_cert_chain() display error strings Display error strings when SSL_CTX_use_certificate() or SSL_CTX_set1_chain() doesn't work.
2022-11-15 10:56:03 -05:00
err && *err ? *err : "", path, ERR_reason_error_string(ret));
BUG/MEDIUM: ssl: never generates the chain from the verify store In bug #781 it was reported that HAProxy completes the certificate chain using the verify store in the case there is no chain. Indeed, according to OpenSSL documentation, when generating the chain, OpenSSL use the chain store OR the verify store in the case there is no chain store. As a workaround, this patch always put a NULL chain in the SSL_CTX so OpenSSL does not tries to complete it. This must be backported in all branches, the code could be different, the important part is to ALWAYS set a chain, and uses sk_X509_new_null() if the chain is NULL.
2020-08-12 14:02:10 -04:00
errcode |= ERR_ALERT | ERR_FATAL;
goto end;
}
Revert "MINOR: ssl: rework add cert chain to CTX to be libssl independent" This reverts commit 4fed93eb725b513dd3b2029daa888311db110851. This commit was simplifying the certificate chain loading with SSL_CTX_add_extra_chain_cert() which is available in all SSL libraries. Unfortunately this function is not compatible with the multi-certificates bundles, which have the effect of concatenating the chains of all certificate types instead of creating a chain for each type (RSA, ECDSA etc.) Should fix issue #655.
2020-06-02 12:27:20 -04:00
#else
{ /* legacy compat (< openssl 1.0.2) */
MINOR: ssl: rework add cert chain to CTX to be libssl independent SSL_CTX_set1_chain is used for openssl >= 1.0.2 and a loop with SSL_CTX_add_extra_chain_cert for openssl < 1.0.2. SSL_CTX_add_extra_chain_cert exist with openssl >= 1.0.2 and can be used for all openssl version (is new name is SSL_CTX_add0_chain_cert). This patch use SSL_CTX_add_extra_chain_cert to remove any #ifdef for compatibilty. In addition sk_X509_num()/sk_X509_value() replace sk_X509_shift() to extract CA from chain, as it is used in others part of the code.
2020-02-28 10:00:34 -05:00
X509 *ca;
BUG/MINOR: ssl: Fix memory leak of find_chain in ssl_sock_load_cert_chain The certificate chain that gets passed in the SSL_CTX through SSL_CTX_set1_chain has its reference counter increased by OpenSSL itself. But since the ssl_sock_load_cert_chain function might create a brand new certificate chain if none exists in the ckch_data (sk_X509_new_null), then we ended up returning a new certificate chain to the caller that was never destroyed. This patch can be backported to all stable branches but it might need to be reworked for branches older than 2.4 because of commit ec805a32b9 that refactorized the modified code.
2022-12-15 09:44:37 -05:00
while ((ca = sk_X509_shift(*find_chain)))
MINOR: ssl: rework add cert chain to CTX to be libssl independent SSL_CTX_set1_chain is used for openssl >= 1.0.2 and a loop with SSL_CTX_add_extra_chain_cert for openssl < 1.0.2. SSL_CTX_add_extra_chain_cert exist with openssl >= 1.0.2 and can be used for all openssl version (is new name is SSL_CTX_add0_chain_cert). This patch use SSL_CTX_add_extra_chain_cert to remove any #ifdef for compatibilty. In addition sk_X509_num()/sk_X509_value() replace sk_X509_shift() to extract CA from chain, as it is used in others part of the code.
2020-02-28 10:00:34 -05:00
if (!SSL_CTX_add_extra_chain_cert(ctx, ca)) {
memprintf(err, "%sunable to load chain certificate into SSL Context '%s'.\n",
err && *err ? *err : "", path);
Revert "MINOR: ssl: rework add cert chain to CTX to be libssl independent" This reverts commit 4fed93eb725b513dd3b2029daa888311db110851. This commit was simplifying the certificate chain loading with SSL_CTX_add_extra_chain_cert() which is available in all SSL libraries. Unfortunately this function is not compatible with the multi-certificates bundles, which have the effect of concatenating the chains of all certificate types instead of creating a chain for each type (RSA, ECDSA etc.) Should fix issue #655.
2020-06-02 12:27:20 -04:00
X509_free(ca);
MINOR: ssl: rework add cert chain to CTX to be libssl independent SSL_CTX_set1_chain is used for openssl >= 1.0.2 and a loop with SSL_CTX_add_extra_chain_cert for openssl < 1.0.2. SSL_CTX_add_extra_chain_cert exist with openssl >= 1.0.2 and can be used for all openssl version (is new name is SSL_CTX_add0_chain_cert). This patch use SSL_CTX_add_extra_chain_cert to remove any #ifdef for compatibilty. In addition sk_X509_num()/sk_X509_value() replace sk_X509_shift() to extract CA from chain, as it is used in others part of the code.
2020-02-28 10:00:34 -05:00
errcode |= ERR_ALERT | ERR_FATAL;
goto end;
}
}
Revert "MINOR: ssl: rework add cert chain to CTX to be libssl independent" This reverts commit 4fed93eb725b513dd3b2029daa888311db110851. This commit was simplifying the certificate chain loading with SSL_CTX_add_extra_chain_cert() which is available in all SSL libraries. Unfortunately this function is not compatible with the multi-certificates bundles, which have the effect of concatenating the chains of all certificate types instead of creating a chain for each type (RSA, ECDSA etc.) Should fix issue #655.
2020-06-02 12:27:20 -04:00
#endif
MINOR: ssl: Added cert_key_and_chain struct Added cert_key_and_chain struct to ssl. This struct will store the contents of a crt path (from the config file) into memory. This will allow us to use the data stored in memory instead of reading the file multiple times. This will be used to support a later commit to load multiple pkeys/certs into a single SSL_CTX
2015-12-01 15:16:07 -05:00
BUG/MINOR: ssl: ssl-skip-self-issued-ca requires >= 1.0.2 The previous fix for ssl-skip-self-issued-ca requires the use of SSL_CTX_build_cert_chain() which is only available starting from OpenSSL 1.0.2
2020-08-10 11:28:23 -04:00
#ifdef SSL_CTX_build_cert_chain
BUG/MEDIUM: ssl: fix the ssl-skip-self-issued-ca option In commit f187ce6, the ssl-skip-self-issued-ca option was accidentally made useless by reverting the SSL_CTX reworking. The previous attempt of making this feature was putting each certificate of the chain in the SSL_CTX with SSL_CTX_add_extra_chain_cert() and was skipping the Root CA. The problem here is that doing it this way instead of doing a SSL_CTX_set1_chain() break the support of the multi-certificate bundles. The SSL_CTX_build_cert_chain() function allows one to remove the Root CA with the SSL_BUILD_CHAIN_FLAG_NO_ROOT flag. Use it instead of doing tricks with the CA. Should fix issue #804. Must be backported in 2.2.
2020-08-10 10:18:45 -04:00
/* remove the Root CA from the SSL_CTX if the option is activated */
if (global_ssl.skip_self_issued_ca) {
if (!SSL_CTX_build_cert_chain(ctx, SSL_BUILD_CHAIN_FLAG_NO_ROOT|SSL_BUILD_CHAIN_FLAG_UNTRUSTED|SSL_BUILD_CHAIN_FLAG_IGNORE_ERROR)) {
memprintf(err, "%sunable to load chain certificate into SSL Context '%s'.\n",
err && *err ? *err : "", path);
errcode |= ERR_ALERT | ERR_FATAL;
goto end;
}
}
BUG/MINOR: ssl: ssl-skip-self-issued-ca requires >= 1.0.2 The previous fix for ssl-skip-self-issued-ca requires the use of SSL_CTX_build_cert_chain() which is only available starting from OpenSSL 1.0.2
2020-08-10 11:28:23 -04:00
#endif
BUG/MEDIUM: ssl: fix the ssl-skip-self-issued-ca option In commit f187ce6, the ssl-skip-self-issued-ca option was accidentally made useless by reverting the SSL_CTX reworking. The previous attempt of making this feature was putting each certificate of the chain in the SSL_CTX with SSL_CTX_add_extra_chain_cert() and was skipping the Root CA. The problem here is that doing it this way instead of doing a SSL_CTX_set1_chain() break the support of the multi-certificate bundles. The SSL_CTX_build_cert_chain() function allows one to remove the Root CA with the SSL_BUILD_CHAIN_FLAG_NO_ROOT flag. Use it instead of doing tricks with the CA. Should fix issue #804. Must be backported in 2.2.
2020-08-10 10:18:45 -04:00
MINOR: ssl: Certificate chain loading refactorization Move the certificate chain loading code into a dedicated function that will then be useable elsewhere.
2021-01-25 11:19:42 -05:00
end:
return errcode;
}
/* Loads the info in ckch into ctx
* Returns a bitfield containing the flags:
* ERR_FATAL in any fatal error case
* ERR_ALERT if the reason of the error is available in err
* ERR_WARN if a warning is available into err
* The value 0 means there is no error nor warning and
* the operation succeed.
*/
MEDIUM: ssl: Add ocsp_certid in ckch structure and discard ocsp buffer early The ocsp_response member of the cert_key_and_chain structure is only used temporarily. During a standard init process where an ocsp response is provided, this ocsp file is first copied into the ocsp_response buffer without any ocsp-related parsing (see ssl_sock_load_ocsp_response_from_file), and then the contents are actually interpreted and inserted into the actual ocsp tree (cert_ocsp_tree) later in the process (see ssl_sock_load_ocsp). If the response was deemed valid, it is then copied into the actual ocsp_response structure's 'response' field (see ssl_sock_load_ocsp_response). From this point, the ocsp_response field of the cert_key_and_chain object could be discarded since actual ocsp operations will be based of the certificate_ocsp object. The only remaining runtime use of the ckch's ocsp_response field was in the CLI, and more precisely in the 'show ssl cert' mechanism. This constraint could be removed by adding an OCSP_CERTID directly in the ckch because the buffer was only used to get this id. This patch then adds the OCSP_CERTID pointer in the ckch, it clears the ocsp_response buffer early and simplifies the ckch_store_build_certid function.
2022-12-20 05:11:08 -05:00
static int ssl_sock_put_ckch_into_ctx(const char *path, struct ckch_data *data, SSL_CTX *ctx, char **err)
MINOR: ssl: Certificate chain loading refactorization Move the certificate chain loading code into a dedicated function that will then be useable elsewhere.
2021-01-25 11:19:42 -05:00
{
int errcode = 0;
STACK_OF(X509) *find_chain = NULL;
MINOR: ssl: dump the SSL string error when SSL_CTX_use_PrivateKey() failed. Display the OpenSSL reason error string when SSL_CTX_use_PrivateKey() failed.
2022-10-27 08:41:07 -04:00
ERR_clear_error();
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
if (SSL_CTX_use_PrivateKey(ctx, data->key) <= 0) {
MINOR: ssl: dump the SSL string error when SSL_CTX_use_PrivateKey() failed. Display the OpenSSL reason error string when SSL_CTX_use_PrivateKey() failed.
2022-10-27 08:41:07 -04:00
int ret;
ret = ERR_get_error();
memprintf(err, "%sunable to load SSL private key into SSL Context '%s': %s.\n",
err && *err ? *err : "", path, ERR_reason_error_string(ret));
MINOR: ssl: Certificate chain loading refactorization Move the certificate chain loading code into a dedicated function that will then be useable elsewhere.
2021-01-25 11:19:42 -05:00
errcode |= ERR_ALERT | ERR_FATAL;
return errcode;
}
/* Load certificate chain */
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
errcode |= ssl_sock_load_cert_chain(path, data, ctx, &find_chain, err);
MINOR: ssl: Certificate chain loading refactorization Move the certificate chain loading code into a dedicated function that will then be useable elsewhere.
2021-01-25 11:19:42 -05:00
if (errcode & ERR_CODE)
goto end;
MEDIUM: ssl: load DH param in struct cert_key_and_chain Load the DH param at the same time as the certificate, we don't need to open the file once more and read it again. We store it in the ckch_node. There is a minor change comparing to the previous way of loading the DH param in a bundle. With a bundle, the DH param in a certificate file was never loaded, it only used the global DH or the default DH, now it's able to use the DH param from a certificate file.
2019-07-23 10:06:08 -04:00
#ifndef OPENSSL_NO_DH
/* store a NULL pointer to indicate we have not yet loaded
a custom DH param file */
if (ssl_dh_ptr_index >= 0) {
SSL_CTX_set_ex_data(ctx, ssl_dh_ptr_index, NULL);
}
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
errcode |= ssl_sock_load_dh_params(ctx, data, path, err);
CLEANUP: ssl: make ssl_sock_load_dh_params handle errcode/warn ssl_sock_load_dh_params used to return >0 or -1 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, this is the only code returned for now. An error message was added in the case of failure and the comment was updated.
2019-10-17 07:27:40 -04:00
if (errcode & ERR_CODE) {
MEDIUM: ssl: load DH param in struct cert_key_and_chain Load the DH param at the same time as the certificate, we don't need to open the file once more and read it again. We store it in the ckch_node. There is a minor change comparing to the previous way of loading the DH param in a bundle. With a bundle, the DH param in a certificate file was never loaded, it only used the global DH or the default DH, now it's able to use the DH param from a certificate file.
2019-07-23 10:06:08 -04:00
memprintf(err, "%sunable to load DH parameters from file '%s'.\n",
err && *err ? *err : "", path);
CLEANUP: ssl: make ssl_sock_put_ckch_into_ctx handle errcode/warn ssl_sock_put_ckch_into_ctx used to return 0 or >0 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, this is the only code returned for now. And a comment was updated.
2019-10-17 07:25:14 -04:00
goto end;
MEDIUM: ssl: load DH param in struct cert_key_and_chain Load the DH param at the same time as the certificate, we don't need to open the file once more and read it again. We store it in the ckch_node. There is a minor change comparing to the previous way of loading the DH param in a bundle. With a bundle, the DH param in a certificate file was never loaded, it only used the global DH or the default DH, now it's able to use the DH param from a certificate file.
2019-07-23 10:06:08 -04:00
}
#endif
BUILD: ssl: fix typo in HAVE_SSL_CTX_ADD_SERVER_CUSTOM_EXT macro HAVE_SSL_CTX_ADD_SERVER_CUSTOM_EXT was introduced in ec609098718b9c1cd803ca57442b2b98c9ba4a16 however it was defined as HAVE_SL_CTX_ADD_SERVER_CUSTOM_EXT (missing "S") let us fix typo
2021-02-06 08:55:27 -05:00
#ifdef HAVE_SSL_CTX_ADD_SERVER_CUSTOM_EXT
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
if (sctl_ex_index >= 0 && data->sctl) {
if (ssl_sock_load_sctl(ctx, data->sctl) < 0) {
MINOR: ssl: load the sctl in/from the ckch Don't try to load the file containing the sctl each time we generate a SSL_CTX. The .sctl is now loaded in the struct cert_key_and_chain only once and then loaded from this structure when creating a SSL_CTX. Note that this now make possible the use of sctl with multi-cert bundles.
2019-10-10 09:16:44 -04:00
memprintf(err, "%s '%s.sctl' is present but cannot be read or parsed'.\n",
CLEANUP: ssl: Clean up error handling This commit removes the explicit checks for `if (err)` before passing `err` to `memprintf`. `memprintf` already checks itself whether the `**out*` parameter is `NULL` before doing anything. This reduces the indentation depth and makes the code more readable, before there is less boilerplate code. Instead move the check into the ternary conditional when the error message should be appended to a previous message. This is consistent with the rest of ssl_sock.c and with the rest of HAProxy. Thus this patch is the arguably cleaner fix for issue #374 and builds upon 5f1fa7db86c53827c97f8a8c3f5fa75bfcb5be9a and 8b453912ce9a4e1a3b1329efb2af04d1e470852e Additionally it fixes a few places where the check *still* was missing.
2019-11-23 17:45:10 -05:00
err && *err ? *err : "", path);
CLEANUP: ssl: make ssl_sock_put_ckch_into_ctx handle errcode/warn ssl_sock_put_ckch_into_ctx used to return 0 or >0 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, this is the only code returned for now. And a comment was updated.
2019-10-17 07:25:14 -04:00
errcode |= ERR_ALERT | ERR_FATAL;
goto end;
MINOR: ssl: load the sctl in/from the ckch Don't try to load the file containing the sctl each time we generate a SSL_CTX. The .sctl is now loaded in the struct cert_key_and_chain only once and then loaded from this structure when creating a SSL_CTX. Note that this now make possible the use of sctl with multi-cert bundles.
2019-10-10 09:16:44 -04:00
}
}
#endif
BUG/MEDIUM: ssl: OCSP must work with BoringSSL It's a regression from b3201a3e "BUG/MINOR: disable dynamic OCSP load with BoringSSL". The origin bug is link to 76b4a12 "BUG/MEDIUM: ssl: memory leak of ocsp data at SSL_CTX_free()": ssl_sock_free_ocsp() shoud be in #ifndef OPENSSL_IS_BORINGSSL. To avoid long #ifdef for small code, the BoringSSL part for ocsp load is isolated in a simple #ifdef. This must be backported in 2.2 and 2.1
2020-10-26 08:55:30 -04:00
#if ((defined SSL_CTRL_SET_TLSEXT_STATUS_REQ_CB && !defined OPENSSL_NO_OCSP) || defined OPENSSL_IS_BORINGSSL)
MEDIUM: ssl: Insert ocsp responses in update tree when needed When 'ocsp-update' is enabled for a given certificate, we need to insert the certificate_ocsp member of this certificate in the OCSP update tree as well as the already existing OCSP response tree. For such an entry to be created, the certificate needs to contain an "OCSP URI" field, and we also need to know the certificate's issuer, that is used to build the OCSP_CERTID. When no OCSP response is known for a given certificate, an empty certificate_ocsp object gets created so that it can be inserted in the ocsp update tree. The entry is inserted on the first spot of the update tree since its expire time is 0. Then whenever the update task is started, it will try to get responses for those certificates first. In order for the update process to work, we also need to store some information relative to the main certificate into the certificate_ocsp structure. This avoids having to keep a reference to a ckch in an ocsp tree entry. This patch adds a reference to the certificate chain as well as the ocsp issuer that might have been filled during init into the certificate_ocsp object. It also gets the ocsp uri at this time since it is contained in the server's certificate. We only take the first uri that might be contained in the certificate though. Those fields are only filled when ocsp auto update is enabled for the concerned certificate.
2022-12-20 05:11:12 -05:00
/* Load OCSP Info into context
* If OCSP update mode is set to 'on', an entry will be created in the
* ocsp tree even if no ocsp_response was known during init, unless the
CLEANUP: assorted typo fixes in the code and comments This is 35th iteration of typo fixes
2023-04-01 06:26:42 -04:00
* frontend's conf disables ocsp update explicitly.
MEDIUM: ssl: Insert ocsp responses in update tree when needed When 'ocsp-update' is enabled for a given certificate, we need to insert the certificate_ocsp member of this certificate in the OCSP update tree as well as the already existing OCSP response tree. For such an entry to be created, the certificate needs to contain an "OCSP URI" field, and we also need to know the certificate's issuer, that is used to build the OCSP_CERTID. When no OCSP response is known for a given certificate, an empty certificate_ocsp object gets created so that it can be inserted in the ocsp update tree. The entry is inserted on the first spot of the update tree since its expire time is 0. Then whenever the update task is started, it will try to get responses for those certificates first. In order for the update process to work, we also need to store some information relative to the main certificate into the certificate_ocsp structure. This avoids having to keep a reference to a ckch in an ocsp tree entry. This patch adds a reference to the certificate chain as well as the ocsp issuer that might have been filled during init into the certificate_ocsp object. It also gets the ocsp uri at this time since it is contained in the server's certificate. We only take the first uri that might be contained in the certificate though. Those fields are only filled when ocsp auto update is enabled for the concerned certificate.
2022-12-20 05:11:12 -05:00
*/
MINOR: ssl: Add certificate's path to certificate_ocsp structure In order to have some information about the frontend certificate when dumping the contents of the ocsp update tree from the cli, we could either keep a reference to a ckch_store in the certificate_ocsp structure, which might cause some dangling reference problems, or simply copy the path to the certificate in the ocsp response structure. This latter solution was chosen because of its simplicity.
2023-03-01 10:11:50 -05:00
if (ssl_sock_load_ocsp(path, ctx, data, find_chain) < 0) {
MEDIUM: ssl: Insert ocsp responses in update tree when needed When 'ocsp-update' is enabled for a given certificate, we need to insert the certificate_ocsp member of this certificate in the OCSP update tree as well as the already existing OCSP response tree. For such an entry to be created, the certificate needs to contain an "OCSP URI" field, and we also need to know the certificate's issuer, that is used to build the OCSP_CERTID. When no OCSP response is known for a given certificate, an empty certificate_ocsp object gets created so that it can be inserted in the ocsp update tree. The entry is inserted on the first spot of the update tree since its expire time is 0. Then whenever the update task is started, it will try to get responses for those certificates first. In order for the update process to work, we also need to store some information relative to the main certificate into the certificate_ocsp structure. This avoids having to keep a reference to a ckch in an ocsp tree entry. This patch adds a reference to the certificate chain as well as the ocsp issuer that might have been filled during init into the certificate_ocsp object. It also gets the ocsp uri at this time since it is contained in the server's certificate. We only take the first uri that might be contained in the certificate though. Those fields are only filled when ocsp auto update is enabled for the concerned certificate.
2022-12-20 05:11:12 -05:00
if (data->ocsp_response)
CLEANUP: ssl: Clean up error handling This commit removes the explicit checks for `if (err)` before passing `err` to `memprintf`. `memprintf` already checks itself whether the `**out*` parameter is `NULL` before doing anything. This reduces the indentation depth and makes the code more readable, before there is less boilerplate code. Instead move the check into the ternary conditional when the error message should be appended to a previous message. This is consistent with the rest of ssl_sock.c and with the rest of HAProxy. Thus this patch is the arguably cleaner fix for issue #374 and builds upon 5f1fa7db86c53827c97f8a8c3f5fa75bfcb5be9a and 8b453912ce9a4e1a3b1329efb2af04d1e470852e Additionally it fixes a few places where the check *still* was missing.
2019-11-23 17:45:10 -05:00
memprintf(err, "%s '%s.ocsp' is present and activates OCSP but it is impossible to compute the OCSP certificate ID (maybe the issuer could not be found)'.\n",
MEDIUM: ssl: Insert ocsp responses in update tree when needed When 'ocsp-update' is enabled for a given certificate, we need to insert the certificate_ocsp member of this certificate in the OCSP update tree as well as the already existing OCSP response tree. For such an entry to be created, the certificate needs to contain an "OCSP URI" field, and we also need to know the certificate's issuer, that is used to build the OCSP_CERTID. When no OCSP response is known for a given certificate, an empty certificate_ocsp object gets created so that it can be inserted in the ocsp update tree. The entry is inserted on the first spot of the update tree since its expire time is 0. Then whenever the update task is started, it will try to get responses for those certificates first. In order for the update process to work, we also need to store some information relative to the main certificate into the certificate_ocsp structure. This avoids having to keep a reference to a ckch in an ocsp tree entry. This patch adds a reference to the certificate chain as well as the ocsp issuer that might have been filled during init into the certificate_ocsp object. It also gets the ocsp uri at this time since it is contained in the server's certificate. We only take the first uri that might be contained in the certificate though. Those fields are only filled when ocsp auto update is enabled for the concerned certificate.
2022-12-20 05:11:12 -05:00
err && *err ? *err : "", path);
else
BUG/MINOR: ssl: Fix error message after ssl_sock_load_ocsp call If we were to enable 'ocsp-update' on a certificate that does not have an OCSP URI, we would exit ssl_sock_load_ocsp with a negative error code which would raise a misleading error message ("<cert> has an OCSP URI and OCSP auto-update is set to 'on' ..."). This patch simply fixes the error message but an error is still raised. This issue was raised in GitHub #2432. It can be backported up to branch 2.8.
2024-02-01 05:58:14 -05:00
memprintf(err, "%s '%s' has an OCSP auto-update set to 'on' but an error occurred (maybe the OCSP URI or the issuer could not be found)'.\n",
MEDIUM: ssl: Insert ocsp responses in update tree when needed When 'ocsp-update' is enabled for a given certificate, we need to insert the certificate_ocsp member of this certificate in the OCSP update tree as well as the already existing OCSP response tree. For such an entry to be created, the certificate needs to contain an "OCSP URI" field, and we also need to know the certificate's issuer, that is used to build the OCSP_CERTID. When no OCSP response is known for a given certificate, an empty certificate_ocsp object gets created so that it can be inserted in the ocsp update tree. The entry is inserted on the first spot of the update tree since its expire time is 0. Then whenever the update task is started, it will try to get responses for those certificates first. In order for the update process to work, we also need to store some information relative to the main certificate into the certificate_ocsp structure. This avoids having to keep a reference to a ckch in an ocsp tree entry. This patch adds a reference to the certificate chain as well as the ocsp issuer that might have been filled during init into the certificate_ocsp object. It also gets the ocsp uri at this time since it is contained in the server's certificate. We only take the first uri that might be contained in the certificate though. Those fields are only filled when ocsp auto update is enabled for the concerned certificate.
2022-12-20 05:11:12 -05:00
err && *err ? *err : "", path);
errcode |= ERR_ALERT | ERR_FATAL;
goto end;
MINOR: ssl: load the ocsp in/from the ckch Don't try to load the files containing the issuer and the OCSP response each time we generate a SSL_CTX. The .ocsp and the .issuer are now loaded in the struct cert_key_and_chain only once and then loaded from this structure when creating a SSL_CTX.
2019-10-11 02:59:13 -04:00
}
#endif
CLEANUP: ssl: make ssl_sock_put_ckch_into_ctx handle errcode/warn ssl_sock_put_ckch_into_ctx used to return 0 or >0 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, this is the only code returned for now. And a comment was updated.
2019-10-17 07:25:14 -04:00
end:
BUG/MINOR: ssl: Fix memory leak of find_chain in ssl_sock_load_cert_chain The certificate chain that gets passed in the SSL_CTX through SSL_CTX_set1_chain has its reference counter increased by OpenSSL itself. But since the ssl_sock_load_cert_chain function might create a brand new certificate chain if none exists in the ckch_data (sk_X509_new_null), then we ended up returning a new certificate chain to the caller that was never destroyed. This patch can be backported to all stable branches but it might need to be reworked for branches older than 2.4 because of commit ec805a32b9 that refactorized the modified code.
2022-12-15 09:44:37 -05:00
sk_X509_pop_free(find_chain, X509_free);
CLEANUP: ssl: make ssl_sock_put_ckch_into_ctx handle errcode/warn ssl_sock_put_ckch_into_ctx used to return 0 or >0 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, this is the only code returned for now. And a comment was updated.
2019-10-17 07:25:14 -04:00
return errcode;
MINOR: ssl: Added cert_key_and_chain struct Added cert_key_and_chain struct to ssl. This struct will store the contents of a crt path (from the config file) into memory. This will allow us to use the data stored in memory instead of reading the file multiple times. This will be used to support a later commit to load multiple pkeys/certs into a single SSL_CTX
2015-12-01 15:16:07 -05:00
}
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
/* Loads the info of a ckch built out of a backend certificate into an SSL ctx
* Returns a bitfield containing the flags:
* ERR_FATAL in any fatal error case
* ERR_ALERT if the reason of the error is available in err
* ERR_WARN if a warning is available into err
* The value 0 means there is no error nor warning and
* the operation succeed.
*/
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
static int ssl_sock_put_srv_ckch_into_ctx(const char *path, const struct ckch_data *data,
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
SSL_CTX *ctx, char **err)
{
int errcode = 0;
STACK_OF(X509) *find_chain = NULL;
/* Load the private key */
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
if (SSL_CTX_use_PrivateKey(ctx, data->key) <= 0) {
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
memprintf(err, "%sunable to load SSL private key into SSL Context '%s'.\n",
err && *err ? *err : "", path);
errcode |= ERR_ALERT | ERR_FATAL;
}
/* Load certificate chain */
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
errcode |= ssl_sock_load_cert_chain(path, data, ctx, &find_chain, err);
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
if (errcode & ERR_CODE)
goto end;
if (SSL_CTX_check_private_key(ctx) <= 0) {
memprintf(err, "%sinconsistencies between private key and certificate loaded from PEM file '%s'.\n",
err && *err ? *err : "", path);
errcode |= ERR_ALERT | ERR_FATAL;
}
end:
BUG/MINOR: ssl: Fix memory leak of find_chain in ssl_sock_load_cert_chain The certificate chain that gets passed in the SSL_CTX through SSL_CTX_set1_chain has its reference counter increased by OpenSSL itself. But since the ssl_sock_load_cert_chain function might create a brand new certificate chain if none exists in the ckch_data (sk_X509_new_null), then we ended up returning a new certificate chain to the caller that was never destroyed. This patch can be backported to all stable branches but it might need to be reworked for branches older than 2.4 because of commit ec805a32b9 that refactorized the modified code.
2022-12-15 09:44:37 -05:00
sk_X509_pop_free(find_chain, X509_free);
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
return errcode;
}
MEDIUM: ssl: ssl_sock_load_ckchs() alloc a ckch_inst The ssl_sock_load_{multi}_ckchs() function were renamed and modified: - allocate a ckch_inst and loads the sni in it - return a ckch_inst or NULL - the sni_ctx are not added anymore in the sni trees from there - renamed in ckch_inst_new_load_{multi}_store() - new ssl_sock_load_ckchs() function calls ckch_inst_new_load_{multi}_store() and add the sni_ctx to the sni trees.
2019-10-07 07:52:11 -04:00
/*
* This function allocate a ckch_inst and create its snis
CLEANUP: ssl: make ckch_inst_new_load_(multi_)store handle errcode/warn ckch_inst_new_load_store() and ckch_inst_new_load_multi_store used to return 0 or >0 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, his is the only code returned for now. And the comment was updated.
2019-10-17 07:16:58 -04:00
*
* Returns a bitfield containing the flags:
* ERR_FATAL in any fatal error case
* ERR_ALERT if the reason of the error is available in err
* ERR_WARN if a warning is available into err
MEDIUM: ssl: ssl_sock_load_ckchs() alloc a ckch_inst The ssl_sock_load_{multi}_ckchs() function were renamed and modified: - allocate a ckch_inst and loads the sni in it - return a ckch_inst or NULL - the sni_ctx are not added anymore in the sni trees from there - renamed in ckch_inst_new_load_{multi}_store() - new ssl_sock_load_ckchs() function calls ckch_inst_new_load_{multi}_store() and add the sni_ctx to the sni trees.
2019-10-07 07:52:11 -04:00
*/
REORG: ssl: move the crt-list CLI functions in src/ssl_crtlist.c Move the crtlist functions for the CLI to src/ssl_crtlist.c
2020-05-13 11:23:59 -04:00
int ckch_inst_new_load_store(const char *path, struct ckch_store *ckchs, struct bind_conf *bind_conf,
MEDIUM: ssl: generate '*' SNI filters for default certificates This patch follows the previous one about default certificate selection ("MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection"). This patch generates '*" SNI filters for the first certificate of a bind line, it will be used to match default certificates. Instead of setting the default_ctx pointer in the bind line. Since the filters are in the SNI tree, it allows to have multiple default certificate and restore the ecdsa/rsa selection with a multi-cert bundle. This configuration: # foobar.pem.ecdsa and foobar.pem.rsa bind *:8443 ssl crt foobar.pem crt next.pem will use "foobar.pem.ecdsa" and "foobar.pem.rsa" as default certificates. Note: there is still cleanup needed around default_ctx. This was discussed in github issue #2392.
2024-01-10 10:07:17 -05:00
struct ssl_bind_conf *ssl_conf, char **sni_filter, int fcount, int is_default, struct ckch_inst **ckchi, char **err)
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
{
MINOR: ssl: merge ssl_sock_load_cert_file() and ssl_sock_load_cert_chain_file() This commit merges the function ssl_sock_load_cert_file() and ssl_sock_load_cert_chain_file(). The goal is to refactor the SSL code and use the cert_key_and_chain struct to load everything.
2019-05-15 09:33:54 -04:00
SSL_CTX *ctx;
int i;
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
int order = 0;
X509_NAME *xname;
char *str;
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
EVP_PKEY *pkey;
MINOR: ssl: extract full pkey info in load_certificate Private key information is used in switchctx to implement native multicert selection (ecdsa/rsa/anonymous). This patch extract and store full pkey information: dsa type and pkey size in bits. This can be used for switchctx or to report pkey informations in ppv2 and log.
2017-10-27 12:43:29 -04:00
struct pkey_info kinfo = { .sig = TLSEXT_signature_anonymous, .bits = 0 };
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
#ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME
STACK_OF(GENERAL_NAME) *names;
#endif
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
struct ckch_data *data;
MEDIUM: ssl: ssl_sock_load_ckchs() alloc a ckch_inst The ssl_sock_load_{multi}_ckchs() function were renamed and modified: - allocate a ckch_inst and loads the sni in it - return a ckch_inst or NULL - the sni_ctx are not added anymore in the sni trees from there - renamed in ckch_inst_new_load_{multi}_store() - new ssl_sock_load_ckchs() function calls ckch_inst_new_load_{multi}_store() and add the sni_ctx to the sni trees.
2019-10-07 07:52:11 -04:00
struct ckch_inst *ckch_inst = NULL;
CLEANUP: ssl: make ckch_inst_new_load_(multi_)store handle errcode/warn ckch_inst_new_load_store() and ckch_inst_new_load_multi_store used to return 0 or >0 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, his is the only code returned for now. And the comment was updated.
2019-10-17 07:16:58 -04:00
int errcode = 0;
*ckchi = NULL;
MEDIUM: ssl: use cert_key_and_chain struct in ssl_sock_load_cert_file() This structure was only used in the case of the multi-cert bundle. Using these primitives everywhere when we load the file are a first step in the deduplication of the code.
2019-05-15 10:08:56 -04:00
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
if (!ckchs || !ckchs->data)
CLEANUP: ssl: make ckch_inst_new_load_(multi_)store handle errcode/warn ckch_inst_new_load_store() and ckch_inst_new_load_multi_store used to return 0 or >0 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, his is the only code returned for now. And the comment was updated.
2019-10-17 07:16:58 -04:00
return ERR_FATAL;
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
data = ckchs->data;
MEDIUM: ssl: split the loading of the certificates Split the functions which open the certificates. Instead of opening directly the certificates and inserting them directly into a SSL_CTX, we use a struct cert_key_and_chain to store them in memory and then we associate a SSL_CTX to the certificate stored in that structure. Introduce the struct ckch_node for the multi-cert bundles so we can store multiple cert_key_and_chain in the same structure. The functions ssl_sock_load_multi_cert() and ssl_sock_load_cert_file() were modified so they don't open the certicates anymore on the filesystem. (they still open the sctl and ocsp though). These functions were renamed ssl_sock_load_ckchn() and ssl_sock_load_multi_ckchn(). The new function ckchn_load_cert_file() is in charge of loading the files in the cert_key_and_chain. (TODO: load ocsp and sctl from there too). The ultimate goal is to be able to load a certificate from a certificate tree without doing any filesystem access, so we don't try to open it again if it was already loaded, and we share its configuration.
2019-07-18 13:28:17 -04:00
MINOR: ssl: merge ssl_sock_load_cert_file() and ssl_sock_load_cert_chain_file() This commit merges the function ssl_sock_load_cert_file() and ssl_sock_load_cert_chain_file(). The goal is to refactor the SSL code and use the cert_key_and_chain struct to load everything.
2019-05-15 09:33:54 -04:00
ctx = SSL_CTX_new(SSLv23_server_method());
if (!ctx) {
memprintf(err, "%sunable to allocate SSL context for cert '%s'.\n",
err && *err ? *err : "", path);
CLEANUP: ssl: make ckch_inst_new_load_(multi_)store handle errcode/warn ckch_inst_new_load_store() and ckch_inst_new_load_multi_store used to return 0 or >0 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, his is the only code returned for now. And the comment was updated.
2019-10-17 07:16:58 -04:00
errcode |= ERR_ALERT | ERR_FATAL;
goto error;
MINOR: ssl: merge ssl_sock_load_cert_file() and ssl_sock_load_cert_chain_file() This commit merges the function ssl_sock_load_cert_file() and ssl_sock_load_cert_chain_file(). The goal is to refactor the SSL code and use the cert_key_and_chain struct to load everything.
2019-05-15 09:33:54 -04:00
}
MEDIUM: ssl: allow to change the OpenSSL security level from global section The new "ssl-security-level" option allows one to change the OpenSSL security level without having to change the openssl.cnf global file of your distribution. This directives applies on every SSL_CTX context. People sometimes change their security level directly in the ciphers directive, however there are some cases when the security level change is not applied in the right order (for example when applying a DH param). Before this patch, it was to possible to trick by using a specific openssl.cnf file and start haproxy this way: OPENSSL_CONF=./openssl.cnf ./haproxy -f bug-2468.cfg Values for the security level can be found there: https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_security_level.html This was discussed in github issue #2468.
2024-03-12 11:22:34 -04:00
if (global_ssl.security_level > -1)
SSL_CTX_set_security_level(ctx, global_ssl.security_level);
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
errcode |= ssl_sock_put_ckch_into_ctx(path, data, ctx, err);
CLEANUP: ssl: make ssl_sock_put_ckch_into_ctx handle errcode/warn ssl_sock_put_ckch_into_ctx used to return 0 or >0 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, this is the only code returned for now. And a comment was updated.
2019-10-17 07:25:14 -04:00
if (errcode & ERR_CODE)
MEDIUM: ssl: ssl_sock_load_ckchs() alloc a ckch_inst The ssl_sock_load_{multi}_ckchs() function were renamed and modified: - allocate a ckch_inst and loads the sni in it - return a ckch_inst or NULL - the sni_ctx are not added anymore in the sni trees from there - renamed in ckch_inst_new_load_{multi}_store() - new ssl_sock_load_ckchs() function calls ckch_inst_new_load_{multi}_store() and add the sni_ctx to the sni trees.
2019-10-07 07:52:11 -04:00
goto error;
ckch_inst = ckch_inst_new();
if (!ckch_inst) {
memprintf(err, "%sunable to allocate SSL context for cert '%s'.\n",
err && *err ? *err : "", path);
CLEANUP: ssl: make ckch_inst_new_load_(multi_)store handle errcode/warn ckch_inst_new_load_store() and ckch_inst_new_load_multi_store used to return 0 or >0 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, his is the only code returned for now. And the comment was updated.
2019-10-17 07:16:58 -04:00
errcode |= ERR_ALERT | ERR_FATAL;
MINOR: ssl: ssl_sock_load_ckchn() can properly fail ssl_sock_load_ckchn() is now able to fail without polluting the bind_conf trees and leaking memory. It is a prerequisite to load certificate on-the-fly with the CLI. The insertion of the sni_ctxs in the trees are done once everything has been allocated correctly.
2019-10-04 09:37:05 -04:00
goto error;
MINOR: ssl: merge ssl_sock_load_cert_file() and ssl_sock_load_cert_chain_file() This commit merges the function ssl_sock_load_cert_file() and ssl_sock_load_cert_chain_file(). The goal is to refactor the SSL code and use the cert_key_and_chain struct to load everything.
2019-05-15 09:33:54 -04:00
}
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
pkey = X509_get_pubkey(data->cert);
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
if (pkey) {
MINOR: ssl: extract full pkey info in load_certificate Private key information is used in switchctx to implement native multicert selection (ecdsa/rsa/anonymous). This patch extract and store full pkey information: dsa type and pkey size in bits. This can be used for switchctx or to report pkey informations in ppv2 and log.
2017-10-27 12:43:29 -04:00
kinfo.bits = EVP_PKEY_bits(pkey);
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
switch(EVP_PKEY_base_id(pkey)) {
case EVP_PKEY_RSA:
MINOR: ssl: extract full pkey info in load_certificate Private key information is used in switchctx to implement native multicert selection (ecdsa/rsa/anonymous). This patch extract and store full pkey information: dsa type and pkey size in bits. This can be used for switchctx or to report pkey informations in ppv2 and log.
2017-10-27 12:43:29 -04:00
kinfo.sig = TLSEXT_signature_rsa;
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
break;
case EVP_PKEY_EC:
MINOR: ssl: extract full pkey info in load_certificate Private key information is used in switchctx to implement native multicert selection (ecdsa/rsa/anonymous). This patch extract and store full pkey information: dsa type and pkey size in bits. This can be used for switchctx or to report pkey informations in ppv2 and log.
2017-10-27 12:43:29 -04:00
kinfo.sig = TLSEXT_signature_ecdsa;
break;
case EVP_PKEY_DSA:
kinfo.sig = TLSEXT_signature_dsa;
MEDIUM: boringssl: support native multi-cert selection without bundling This patch used boringssl's callback to analyse CLientHello before any handshake to extract key signature capabilities. Certificat with better signature (ECDSA before RSA) is choosed transparenty, if client can support it. RSA and ECDSA certificates can be declare in a row (without order). This makes it possible to set different ssl and filter parameter with crt-list.
2017-02-20 10:11:50 -05:00
break;
}
EVP_PKEY_free(pkey);
}
BUG/MEDIUM: Fix crt-list file parsing error: filtered name was ignored. Also add support for multiple filtered names on same certificate (per line).
2013-04-22 07:05:23 -04:00
if (fcount) {
BUG/MINOR: ssl: abort on sni allocation failure The ssl_sock_add_cert_sni() function never return an error when a sni_ctx allocation fail. It silently ignores the problem and continues to try to allocate other snis. It is unlikely that a sni allocation will succeed after one failure and start a configuration without all the snis. But to avoid any problem we return a -1 upon an sni allocation error and stop the configuration parsing. This patch must be backported in every version supporting the crt-list sni filters. (as far as 1.5)
2019-10-03 17:46:33 -04:00
while (fcount--) {
MEDIUM: ssl: split ssl_sock_add_cert_sni() In order to allow the creation of sni_ctx in runtime, we need to split the function to allow rollback. We need to be able to allocate all sni_ctxs required before inserting them in case we need to rollback if we didn't succeed the allocation. The function was splitted in 2 parts. The first one ckch_inst_add_cert_sni() allocates a struct sni_ctx, fill it with the right data and insert it in the ckch_inst's list of sni_ctx. The second will take every sni_ctx in the ckch_inst and insert them in the bind_conf's sni tree.
2019-10-03 18:53:29 -04:00
order = ckch_inst_add_cert_sni(ctx, ckch_inst, bind_conf, ssl_conf, kinfo, sni_filter[fcount], order);
BUG/MINOR: ssl: abort on sni allocation failure The ssl_sock_add_cert_sni() function never return an error when a sni_ctx allocation fail. It silently ignores the problem and continues to try to allocate other snis. It is unlikely that a sni allocation will succeed after one failure and start a configuration without all the snis. But to avoid any problem we return a -1 upon an sni allocation error and stop the configuration parsing. This patch must be backported in every version supporting the crt-list sni filters. (as far as 1.5)
2019-10-03 17:46:33 -04:00
if (order < 0) {
memprintf(err, "%sunable to create a sni context.\n", err && *err ? *err : "");
CLEANUP: ssl: make ckch_inst_new_load_(multi_)store handle errcode/warn ckch_inst_new_load_store() and ckch_inst_new_load_multi_store used to return 0 or >0 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, his is the only code returned for now. And the comment was updated.
2019-10-17 07:16:58 -04:00
errcode |= ERR_ALERT | ERR_FATAL;
MINOR: ssl: ssl_sock_load_ckchn() can properly fail ssl_sock_load_ckchn() is now able to fail without polluting the bind_conf trees and leaking memory. It is a prerequisite to load certificate on-the-fly with the CLI. The insertion of the sni_ctxs in the trees are done once everything has been allocated correctly.
2019-10-04 09:37:05 -04:00
goto error;
BUG/MINOR: ssl: abort on sni allocation failure The ssl_sock_add_cert_sni() function never return an error when a sni_ctx allocation fail. It silently ignores the problem and continues to try to allocate other snis. It is unlikely that a sni allocation will succeed after one failure and start a configuration without all the snis. But to avoid any problem we return a -1 upon an sni allocation error and stop the configuration parsing. This patch must be backported in every version supporting the crt-list sni filters. (as far as 1.5)
2019-10-03 17:46:33 -04:00
}
}
MEDIUM: ssl: add mapping from SNI to cert file using "crt-list" It designates a list of PEM file with an optional list of SNI filter per certificate, with the following format for each line : <crtfile>[ <snifilter>]* Wildcards are supported in the SNI filter. The certificates will be presented to clients who provide a valid TLS Server Name Indication field matching one of SNI filter. If no SNI filter is specified the CN and alt subjects are used.
2013-01-22 09:31:15 -05:00
}
else {
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
#ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
names = X509_get_ext_d2i(data->cert, NID_subject_alt_name, NULL, NULL);
MEDIUM: ssl: add mapping from SNI to cert file using "crt-list" It designates a list of PEM file with an optional list of SNI filter per certificate, with the following format for each line : <crtfile>[ <snifilter>]* Wildcards are supported in the SNI filter. The certificates will be presented to clients who provide a valid TLS Server Name Indication field matching one of SNI filter. If no SNI filter is specified the CN and alt subjects are used.
2013-01-22 09:31:15 -05:00
if (names) {
for (i = 0; i < sk_GENERAL_NAME_num(names); i++) {
GENERAL_NAME *name = sk_GENERAL_NAME_value(names, i);
if (name->type == GEN_DNS) {
if (ASN1_STRING_to_UTF8((unsigned char **)&str, name->d.dNSName) >= 0) {
MEDIUM: ssl: split ssl_sock_add_cert_sni() In order to allow the creation of sni_ctx in runtime, we need to split the function to allow rollback. We need to be able to allocate all sni_ctxs required before inserting them in case we need to rollback if we didn't succeed the allocation. The function was splitted in 2 parts. The first one ckch_inst_add_cert_sni() allocates a struct sni_ctx, fill it with the right data and insert it in the ckch_inst's list of sni_ctx. The second will take every sni_ctx in the ckch_inst and insert them in the bind_conf's sni tree.
2019-10-03 18:53:29 -04:00
order = ckch_inst_add_cert_sni(ctx, ckch_inst, bind_conf, ssl_conf, kinfo, str, order);
MEDIUM: ssl: add mapping from SNI to cert file using "crt-list" It designates a list of PEM file with an optional list of SNI filter per certificate, with the following format for each line : <crtfile>[ <snifilter>]* Wildcards are supported in the SNI filter. The certificates will be presented to clients who provide a valid TLS Server Name Indication field matching one of SNI filter. If no SNI filter is specified the CN and alt subjects are used.
2013-01-22 09:31:15 -05:00
OPENSSL_free(str);
BUG/MINOR: ssl: abort on sni allocation failure The ssl_sock_add_cert_sni() function never return an error when a sni_ctx allocation fail. It silently ignores the problem and continues to try to allocate other snis. It is unlikely that a sni allocation will succeed after one failure and start a configuration without all the snis. But to avoid any problem we return a -1 upon an sni allocation error and stop the configuration parsing. This patch must be backported in every version supporting the crt-list sni filters. (as far as 1.5)
2019-10-03 17:46:33 -04:00
if (order < 0) {
memprintf(err, "%sunable to create a sni context.\n", err && *err ? *err : "");
CLEANUP: ssl: make ckch_inst_new_load_(multi_)store handle errcode/warn ckch_inst_new_load_store() and ckch_inst_new_load_multi_store used to return 0 or >0 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, his is the only code returned for now. And the comment was updated.
2019-10-17 07:16:58 -04:00
errcode |= ERR_ALERT | ERR_FATAL;
MINOR: ssl: ssl_sock_load_ckchn() can properly fail ssl_sock_load_ckchn() is now able to fail without polluting the bind_conf trees and leaking memory. It is a prerequisite to load certificate on-the-fly with the CLI. The insertion of the sni_ctxs in the trees are done once everything has been allocated correctly.
2019-10-04 09:37:05 -04:00
goto error;
BUG/MINOR: ssl: abort on sni allocation failure The ssl_sock_add_cert_sni() function never return an error when a sni_ctx allocation fail. It silently ignores the problem and continues to try to allocate other snis. It is unlikely that a sni allocation will succeed after one failure and start a configuration without all the snis. But to avoid any problem we return a -1 upon an sni allocation error and stop the configuration parsing. This patch must be backported in every version supporting the crt-list sni filters. (as far as 1.5)
2019-10-03 17:46:33 -04:00
}
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
}
}
}
MEDIUM: ssl: add mapping from SNI to cert file using "crt-list" It designates a list of PEM file with an optional list of SNI filter per certificate, with the following format for each line : <crtfile>[ <snifilter>]* Wildcards are supported in the SNI filter. The certificates will be presented to clients who provide a valid TLS Server Name Indication field matching one of SNI filter. If no SNI filter is specified the CN and alt subjects are used.
2013-01-22 09:31:15 -05:00
sk_GENERAL_NAME_pop_free(names, GENERAL_NAME_free);
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
}
#endif /* SSL_CTRL_SET_TLSEXT_HOSTNAME */
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
xname = X509_get_subject_name(data->cert);
MEDIUM: ssl: add mapping from SNI to cert file using "crt-list" It designates a list of PEM file with an optional list of SNI filter per certificate, with the following format for each line : <crtfile>[ <snifilter>]* Wildcards are supported in the SNI filter. The certificates will be presented to clients who provide a valid TLS Server Name Indication field matching one of SNI filter. If no SNI filter is specified the CN and alt subjects are used.
2013-01-22 09:31:15 -05:00
i = -1;
while ((i = X509_NAME_get_index_by_NID(xname, NID_commonName, i)) != -1) {
X509_NAME_ENTRY *entry = X509_NAME_get_entry(xname, i);
MEDIUM: ssl: Add support for OpenSSL 1.1.0 In the last release a lot of the structures have become opaque for an end user. This means the code using these needs to be changed to use the proper functions to interact with these structures instead of trying to manipulate them directly. This does not fix any deprecations yet that are part of 1.1.0, it only ensures that it can be compiled against that version and is still compatible with older ones. [wt: openssl-0.9.8 doesn't build with it, there are conflicts on certain function prototypes which we declare as inline here and which are defined differently there. But openssl-0.9.8 is not supported anymore so probably it's OK to go without it for now and we'll see later if some users still need it. Emeric has reviewed this change and didn't spot anything obvious which requires special care. Let's try it for real now]
2016-08-29 07:26:37 -04:00
ASN1_STRING *value;
value = X509_NAME_ENTRY_get_data(entry);
if (ASN1_STRING_to_UTF8((unsigned char **)&str, value) >= 0) {
MEDIUM: ssl: split ssl_sock_add_cert_sni() In order to allow the creation of sni_ctx in runtime, we need to split the function to allow rollback. We need to be able to allocate all sni_ctxs required before inserting them in case we need to rollback if we didn't succeed the allocation. The function was splitted in 2 parts. The first one ckch_inst_add_cert_sni() allocates a struct sni_ctx, fill it with the right data and insert it in the ckch_inst's list of sni_ctx. The second will take every sni_ctx in the ckch_inst and insert them in the bind_conf's sni tree.
2019-10-03 18:53:29 -04:00
order = ckch_inst_add_cert_sni(ctx, ckch_inst, bind_conf, ssl_conf, kinfo, str, order);
MEDIUM: ssl: add mapping from SNI to cert file using "crt-list" It designates a list of PEM file with an optional list of SNI filter per certificate, with the following format for each line : <crtfile>[ <snifilter>]* Wildcards are supported in the SNI filter. The certificates will be presented to clients who provide a valid TLS Server Name Indication field matching one of SNI filter. If no SNI filter is specified the CN and alt subjects are used.
2013-01-22 09:31:15 -05:00
OPENSSL_free(str);
BUG/MINOR: ssl: abort on sni allocation failure The ssl_sock_add_cert_sni() function never return an error when a sni_ctx allocation fail. It silently ignores the problem and continues to try to allocate other snis. It is unlikely that a sni allocation will succeed after one failure and start a configuration without all the snis. But to avoid any problem we return a -1 upon an sni allocation error and stop the configuration parsing. This patch must be backported in every version supporting the crt-list sni filters. (as far as 1.5)
2019-10-03 17:46:33 -04:00
if (order < 0) {
memprintf(err, "%sunable to create a sni context.\n", err && *err ? *err : "");
CLEANUP: ssl: make ckch_inst_new_load_(multi_)store handle errcode/warn ckch_inst_new_load_store() and ckch_inst_new_load_multi_store used to return 0 or >0 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, his is the only code returned for now. And the comment was updated.
2019-10-17 07:16:58 -04:00
errcode |= ERR_ALERT | ERR_FATAL;
MINOR: ssl: ssl_sock_load_ckchn() can properly fail ssl_sock_load_ckchn() is now able to fail without polluting the bind_conf trees and leaking memory. It is a prerequisite to load certificate on-the-fly with the CLI. The insertion of the sni_ctxs in the trees are done once everything has been allocated correctly.
2019-10-04 09:37:05 -04:00
goto error;
BUG/MINOR: ssl: abort on sni allocation failure The ssl_sock_add_cert_sni() function never return an error when a sni_ctx allocation fail. It silently ignores the problem and continues to try to allocate other snis. It is unlikely that a sni allocation will succeed after one failure and start a configuration without all the snis. But to avoid any problem we return a -1 upon an sni allocation error and stop the configuration parsing. This patch must be backported in every version supporting the crt-list sni filters. (as far as 1.5)
2019-10-03 17:46:33 -04:00
}
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
}
}
}
/* we must not free the SSL_CTX anymore below, since it's already in
* the tree, so it will be discovered and cleaned in time.
*/
MINOR: ssl: try to load Diffie-Hellman parameters from cert file Feature is disabled if openssl compiled with OPENSSL_NO_DH.
2012-09-20 10:19:02 -04:00
MEDIUM: ssl: generate '*' SNI filters for default certificates This patch follows the previous one about default certificate selection ("MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection"). This patch generates '*" SNI filters for the first certificate of a bind line, it will be used to match default certificates. Instead of setting the default_ctx pointer in the bind line. Since the filters are in the SNI tree, it allows to have multiple default certificate and restore the ecdsa/rsa selection with a multi-cert bundle. This configuration: # foobar.pem.ecdsa and foobar.pem.rsa bind *:8443 ssl crt foobar.pem crt next.pem will use "foobar.pem.ecdsa" and "foobar.pem.rsa" as default certificates. Note: there is still cleanup needed around default_ctx. This was discussed in github issue #2392.
2024-01-10 10:07:17 -05:00
if (is_default) {
MINOR: ssl/cli: replace the default_ctx during 'commit ssl cert' If the SSL_CTX of a previous instance (ckch_inst) was used as a default_ctx, replace the default_ctx of the bind_conf by the first SSL_CTX inserted in the SNI tree. Use the RWLOCK of the sni tree to handle the change of the default_ctx.
2019-11-04 11:56:13 -05:00
ckch_inst->is_default = 1;
MEDIUM: ssl: generate '*' SNI filters for default certificates This patch follows the previous one about default certificate selection ("MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection"). This patch generates '*" SNI filters for the first certificate of a bind line, it will be used to match default certificates. Instead of setting the default_ctx pointer in the bind line. Since the filters are in the SNI tree, it allows to have multiple default certificate and restore the ecdsa/rsa selection with a multi-cert bundle. This configuration: # foobar.pem.ecdsa and foobar.pem.rsa bind *:8443 ssl crt foobar.pem crt next.pem will use "foobar.pem.ecdsa" and "foobar.pem.rsa" as default certificates. Note: there is still cleanup needed around default_ctx. This was discussed in github issue #2392.
2024-01-10 10:07:17 -05:00
/* insert an empty SNI which will be used to lookup default certificate */
order = ckch_inst_add_cert_sni(ctx, ckch_inst, bind_conf, ssl_conf, kinfo, "*", order);
if (order < 0) {
memprintf(err, "%sunable to create a sni context.\n", err && *err ? *err : "");
errcode |= ERR_ALERT | ERR_FATAL;
goto error;
}
MAJOR: ssl: bind configuration per certificat crt-list is extend to support ssl configuration. You can now have such line in crt-list <file>: mycert.pem [npn h2,http/1.1] Support include "npn", "alpn", "verify", "ca_file", "crl_file", "ecdhe", "ciphers" configuration and ssl options. "crt-base" is also supported to fetch certificates.
2016-12-29 12:26:15 -05:00
}
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
BUG/MINOR: ssl: Fix update of default certificate The default SSL_CTX used by a specific frontend is the one of the first ckch instance created for this frontend. If this instance has SNIs, then the SSL context is linked to the instance through the list of SNIs contained in it. If the instance does not have any SNIs though, then the SSL_CTX is only referenced by the bind_conf structure and the instance itself has no link to it. When trying to update a certificate used by the default instance through a cli command, a new version of the default instance was rebuilt but the default SSL context referenced in the bind_conf structure would not be changed, resulting in a buggy behavior in which depending on the SNI used by the client, he could either use the new version of the updated certificate or the original one. This patch adds a reference to the default SSL context in the default ckch instances so that it can be hot swapped during a certificate update. This should fix GitHub issue #1143. It can be backported as far as 2.2.
2021-03-17 09:56:54 -04:00
/* Always keep a reference to the newly constructed SSL_CTX in the
* instance. This way if the instance has no SNIs, the SSL_CTX will
* still be linked. */
SSL_CTX_up_ref(ctx);
ckch_inst->ctx = ctx;
MEDIUM: ssl: introduce the ckch instance structure struct ckch_inst represents an instance of a certificate (ckch_node) used in a bind_conf. Every sni_ctx created for 1 ckch_node in a bind_conf are linked in this structure. This patch allocate the ckch_inst for each bind_conf and inserts the sni_ctx in its linked list.
2019-10-03 18:29:42 -04:00
/* everything succeed, the ckch instance can be used */
ckch_inst->bind_conf = bind_conf;
MEDIUM: ssl/cli: 'set ssl cert' updates a certificate from the CLI $ echo -e "set ssl cert certificate.pem <<\n$(cat certificate2.pem)\n" | \ socat stdio /var/run/haproxy.stat Certificate updated! The operation is locked at the ckch level with a HA_SPINLOCK_T which prevents the ckch architecture (ckch_store, ckch_inst..) to be modified at the same time. So you can't do a certificate update at the same time from multiple CLI connections. SNI trees are also locked with a HA_RWLOCK_T so reading operations are locked only during a certificate update. Bundles are supported but you need to update each file (.rsa|ecdsa|.dsa) independently. If a file is used in the configuration as a bundle AND as a unique certificate, both will be updated. Bundles, directories and crt-list are supported, however filters in crt-list are currently unsupported. The code tries to allocate every SNIs and certificate instances first, so it can rollback the operation if that was unsuccessful. If you have too much instances of the certificate (at least 20000 in my tests on my laptop), the function can take too much time and be killed by the watchdog. This will be fixed later. Also with too much certificates it's possible that socat exits before the end of the generation without displaying a message, consider changing the socat timeout in this case (-t2 for example). The size of the certificate is currently limited by the maximum size of a payload, that must fit in a buffer.
2019-09-19 11:12:49 -04:00
ckch_inst->ssl_conf = ssl_conf;
MINOR: ssl: reach a ckch_store from a sni_ctx It was only possible to go down from the ckch_store to the sni_ctx but not to go up from the sni_ctx to the ckch_store. To allow that, 2 pointers were added: - a ckch_inst pointer in the struct sni_ctx - a ckckh_store pointer in the struct ckch_inst
2020-03-05 04:17:47 -05:00
ckch_inst->ckch_store = ckchs;
MEDIUM: ssl: introduce the ckch instance structure struct ckch_inst represents an instance of a certificate (ckch_node) used in a bind_conf. Every sni_ctx created for 1 ckch_node in a bind_conf are linked in this structure. This patch allocate the ckch_inst for each bind_conf and inserts the sni_ctx in its linked list.
2019-10-03 18:29:42 -04:00
CLEANUP: ssl: use the refcount for the SSL_CTX' Use the refcount of the SSL_CTX' to free them instead of freeing them on certains conditions. That way we can free the SSL_CTX everywhere its pointer is used.
2020-04-08 10:11:26 -04:00
SSL_CTX_free(ctx); /* we need to free the ctx since we incremented the refcount where it's used */
CLEANUP: ssl: make ckch_inst_new_load_(multi_)store handle errcode/warn ckch_inst_new_load_store() and ckch_inst_new_load_multi_store used to return 0 or >0 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, his is the only code returned for now. And the comment was updated.
2019-10-17 07:16:58 -04:00
*ckchi = ckch_inst;
return errcode;
MINOR: ssl: ssl_sock_load_ckchn() can properly fail ssl_sock_load_ckchn() is now able to fail without polluting the bind_conf trees and leaking memory. It is a prerequisite to load certificate on-the-fly with the CLI. The insertion of the sni_ctxs in the trees are done once everything has been allocated correctly.
2019-10-04 09:37:05 -04:00
error:
/* free the allocated sni_ctxs */
MEDIUM: ssl: ssl_sock_load_ckchs() alloc a ckch_inst The ssl_sock_load_{multi}_ckchs() function were renamed and modified: - allocate a ckch_inst and loads the sni in it - return a ckch_inst or NULL - the sni_ctx are not added anymore in the sni trees from there - renamed in ckch_inst_new_load_{multi}_store() - new ssl_sock_load_ckchs() function calls ckch_inst_new_load_{multi}_store() and add the sni_ctx to the sni trees.
2019-10-07 07:52:11 -04:00
if (ckch_inst) {
MINOR: ssl: free instances and SNIs with ckch_inst_free() Remove duplicated code by creating a new function ckch_inst_free() which deals with the SNIs linked in a ckch_inst and free the ckch_inst.
2020-04-09 10:31:05 -04:00
ckch_inst_free(ckch_inst);
MEDIUM: ssl: ssl_sock_load_ckchs() alloc a ckch_inst The ssl_sock_load_{multi}_ckchs() function were renamed and modified: - allocate a ckch_inst and loads the sni in it - return a ckch_inst or NULL - the sni_ctx are not added anymore in the sni trees from there - renamed in ckch_inst_new_load_{multi}_store() - new ssl_sock_load_ckchs() function calls ckch_inst_new_load_{multi}_store() and add the sni_ctx to the sni trees.
2019-10-07 07:52:11 -04:00
ckch_inst = NULL;
MINOR: ssl: ssl_sock_load_ckchn() can properly fail ssl_sock_load_ckchn() is now able to fail without polluting the bind_conf trees and leaking memory. It is a prerequisite to load certificate on-the-fly with the CLI. The insertion of the sni_ctxs in the trees are done once everything has been allocated correctly.
2019-10-04 09:37:05 -04:00
}
SSL_CTX_free(ctx);
CLEANUP: ssl: make ckch_inst_new_load_(multi_)store handle errcode/warn ckch_inst_new_load_store() and ckch_inst_new_load_multi_store used to return 0 or >0 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, his is the only code returned for now. And the comment was updated.
2019-10-17 07:16:58 -04:00
return errcode;
MEDIUM: ssl: ssl_sock_load_ckchs() alloc a ckch_inst The ssl_sock_load_{multi}_ckchs() function were renamed and modified: - allocate a ckch_inst and loads the sni in it - return a ckch_inst or NULL - the sni_ctx are not added anymore in the sni trees from there - renamed in ckch_inst_new_load_{multi}_store() - new ssl_sock_load_ckchs() function calls ckch_inst_new_load_{multi}_store() and add the sni_ctx to the sni trees.
2019-10-07 07:52:11 -04:00
}
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
/*
* This function allocate a ckch_inst that will be used on the backend side
* (server line)
*
* Returns a bitfield containing the flags:
* ERR_FATAL in any fatal error case
* ERR_ALERT if the reason of the error is available in err
* ERR_WARN if a warning is available into err
*/
int ckch_inst_new_load_srv_store(const char *path, struct ckch_store *ckchs,
CLEANUP: ssl: remove SSL_CTX function parameter Since the server SSL_CTX is now stored in the ckch_inst, it is not needed anymore to pass an SSL_CTX to ckch_inst_new_load_srv_store() and ssl_sock_load_srv_ckchs().
2021-01-26 05:27:42 -05:00
struct ckch_inst **ckchi, char **err)
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
{
SSL_CTX *ctx;
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
struct ckch_data *data;
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
struct ckch_inst *ckch_inst = NULL;
int errcode = 0;
*ckchi = NULL;
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
if (!ckchs || !ckchs->data)
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
return ERR_FATAL;
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
data = ckchs->data;
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
ctx = SSL_CTX_new(SSLv23_client_method());
if (!ctx) {
memprintf(err, "%sunable to allocate SSL context for cert '%s'.\n",
err && *err ? *err : "", path);
errcode |= ERR_ALERT | ERR_FATAL;
goto error;
}
MEDIUM: ssl: allow to change the OpenSSL security level from global section The new "ssl-security-level" option allows one to change the OpenSSL security level without having to change the openssl.cnf global file of your distribution. This directives applies on every SSL_CTX context. People sometimes change their security level directly in the ciphers directive, however there are some cases when the security level change is not applied in the right order (for example when applying a DH param). Before this patch, it was to possible to trick by using a specific openssl.cnf file and start haproxy this way: OPENSSL_CONF=./openssl.cnf ./haproxy -f bug-2468.cfg Values for the security level can be found there: https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_security_level.html This was discussed in github issue #2468.
2024-03-12 11:22:34 -04:00
if (global_ssl.security_level > -1)
SSL_CTX_set_security_level(ctx, global_ssl.security_level);
MEDIUM: ssl: rename the struct "cert_key_and_chain" to "ckch_data" Rename the structure "cert_key_and_chain" to "ckch_data" in order to avoid confusion with the store whcih often called "ckchs". The "cert_key_and_chain *ckch" were renamed "ckch_data *data", so we now have store->data instead of ckchs->ckch. Marked medium because it changes the API.
2022-11-22 05:51:53 -05:00
errcode |= ssl_sock_put_srv_ckch_into_ctx(path, data, ctx, err);
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
if (errcode & ERR_CODE)
goto error;
ckch_inst = ckch_inst_new();
if (!ckch_inst) {
memprintf(err, "%sunable to allocate SSL context for cert '%s'.\n",
err && *err ? *err : "", path);
errcode |= ERR_ALERT | ERR_FATAL;
goto error;
}
/* everything succeed, the ckch instance can be used */
ckch_inst->bind_conf = NULL;
ckch_inst->ssl_conf = NULL;
ckch_inst->ckch_store = ckchs;
CLEANUP: ssl: remove SSL_CTX function parameter Since the server SSL_CTX is now stored in the ckch_inst, it is not needed anymore to pass an SSL_CTX to ckch_inst_new_load_srv_store() and ssl_sock_load_srv_ckchs().
2021-01-26 05:27:42 -05:00
ckch_inst->ctx = ctx;
CLEANUP: ssl: make load_srv_{ckchs,cert} match their bind counterpart This patch makes things more consistent between the bind_conf functions and the server ones: - ssl_sock_load_srv_ckchs() loads the SSL_CTX in the server (ssl_sock_load_ckchs() load the SNIs in the bind_conf) - add the server parameter to ssl_sock_load_srv_ckchs() - changes made to the ckch_inst are done in ckch_inst_new_load_srv_store()
2021-01-26 06:01:46 -05:00
ckch_inst->is_server_instance = 1;
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
*ckchi = ckch_inst;
return errcode;
error:
SSL_CTX_free(ctx);
return errcode;
}
CLEANUP: ssl: make ssl_sock_load_ckchs() return a set of ERR_* ssl_sock_load_ckchs() used to return 0 or >0 to indicate success or failure even though this was not documented. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, this is the only code returned for now. And a comment was added.
2019-10-16 11:06:25 -04:00
/* Returns a set of ERR_* flags possibly with an error in <err>. */
MEDIUM: ssl: ssl_sock_load_ckchs() alloc a ckch_inst The ssl_sock_load_{multi}_ckchs() function were renamed and modified: - allocate a ckch_inst and loads the sni in it - return a ckch_inst or NULL - the sni_ctx are not added anymore in the sni trees from there - renamed in ckch_inst_new_load_{multi}_store() - new ssl_sock_load_ckchs() function calls ckch_inst_new_load_{multi}_store() and add the sni_ctx to the sni trees.
2019-10-07 07:52:11 -04:00
static int ssl_sock_load_ckchs(const char *path, struct ckch_store *ckchs,
struct bind_conf *bind_conf, struct ssl_bind_conf *ssl_conf,
MEDIUM: ssl: generate '*' SNI filters for default certificates This patch follows the previous one about default certificate selection ("MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection"). This patch generates '*" SNI filters for the first certificate of a bind line, it will be used to match default certificates. Instead of setting the default_ctx pointer in the bind line. Since the filters are in the SNI tree, it allows to have multiple default certificate and restore the ecdsa/rsa selection with a multi-cert bundle. This configuration: # foobar.pem.ecdsa and foobar.pem.rsa bind *:8443 ssl crt foobar.pem crt next.pem will use "foobar.pem.ecdsa" and "foobar.pem.rsa" as default certificates. Note: there is still cleanup needed around default_ctx. This was discussed in github issue #2392.
2024-01-10 10:07:17 -05:00
char **sni_filter, int fcount,
int is_default,
struct ckch_inst **ckch_inst, char **err)
MEDIUM: ssl: ssl_sock_load_ckchs() alloc a ckch_inst The ssl_sock_load_{multi}_ckchs() function were renamed and modified: - allocate a ckch_inst and loads the sni in it - return a ckch_inst or NULL - the sni_ctx are not added anymore in the sni trees from there - renamed in ckch_inst_new_load_{multi}_store() - new ssl_sock_load_ckchs() function calls ckch_inst_new_load_{multi}_store() and add the sni_ctx to the sni trees.
2019-10-07 07:52:11 -04:00
{
CLEANUP: ssl: make ckch_inst_new_load_(multi_)store handle errcode/warn ckch_inst_new_load_store() and ckch_inst_new_load_multi_store used to return 0 or >0 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, his is the only code returned for now. And the comment was updated.
2019-10-17 07:16:58 -04:00
int errcode = 0;
MEDIUM: ssl: ssl_sock_load_ckchs() alloc a ckch_inst The ssl_sock_load_{multi}_ckchs() function were renamed and modified: - allocate a ckch_inst and loads the sni in it - return a ckch_inst or NULL - the sni_ctx are not added anymore in the sni trees from there - renamed in ckch_inst_new_load_{multi}_store() - new ssl_sock_load_ckchs() function calls ckch_inst_new_load_{multi}_store() and add the sni_ctx to the sni trees.
2019-10-07 07:52:11 -04:00
/* we found the ckchs in the tree, we can use it directly */
MEDIUM: ssl: generate '*' SNI filters for default certificates This patch follows the previous one about default certificate selection ("MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection"). This patch generates '*" SNI filters for the first certificate of a bind line, it will be used to match default certificates. Instead of setting the default_ctx pointer in the bind line. Since the filters are in the SNI tree, it allows to have multiple default certificate and restore the ecdsa/rsa selection with a multi-cert bundle. This configuration: # foobar.pem.ecdsa and foobar.pem.rsa bind *:8443 ssl crt foobar.pem crt next.pem will use "foobar.pem.ecdsa" and "foobar.pem.rsa" as default certificates. Note: there is still cleanup needed around default_ctx. This was discussed in github issue #2392.
2024-01-10 10:07:17 -05:00
errcode |= ckch_inst_new_load_store(path, ckchs, bind_conf, ssl_conf, sni_filter, fcount, is_default, ckch_inst, err);
MEDIUM: ssl: ssl_sock_load_ckchs() alloc a ckch_inst The ssl_sock_load_{multi}_ckchs() function were renamed and modified: - allocate a ckch_inst and loads the sni in it - return a ckch_inst or NULL - the sni_ctx are not added anymore in the sni trees from there - renamed in ckch_inst_new_load_{multi}_store() - new ssl_sock_load_ckchs() function calls ckch_inst_new_load_{multi}_store() and add the sni_ctx to the sni trees.
2019-10-07 07:52:11 -04:00
CLEANUP: ssl: make ckch_inst_new_load_(multi_)store handle errcode/warn ckch_inst_new_load_store() and ckch_inst_new_load_multi_store used to return 0 or >0 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, his is the only code returned for now. And the comment was updated.
2019-10-17 07:16:58 -04:00
if (errcode & ERR_CODE)
return errcode;
MEDIUM: ssl: ssl_sock_load_ckchs() alloc a ckch_inst The ssl_sock_load_{multi}_ckchs() function were renamed and modified: - allocate a ckch_inst and loads the sni in it - return a ckch_inst or NULL - the sni_ctx are not added anymore in the sni trees from there - renamed in ckch_inst_new_load_{multi}_store() - new ssl_sock_load_ckchs() function calls ckch_inst_new_load_{multi}_store() and add the sni_ctx to the sni trees.
2019-10-07 07:52:11 -04:00
MINOR: ssl: pass ckch_inst to ssl_sock_load_ckchs() Pass a pointer to the struct ckch_inst to the ssl_sock_load_ckchs() function so we can manipulate the ckch_inst from ssl_sock_load_cert_list_file() and ssl_sock_load_cert().
2020-03-09 11:48:43 -04:00
ssl_sock_load_cert_sni(*ckch_inst, bind_conf);
MEDIUM: ssl: ssl_sock_load_ckchs() alloc a ckch_inst The ssl_sock_load_{multi}_ckchs() function were renamed and modified: - allocate a ckch_inst and loads the sni in it - return a ckch_inst or NULL - the sni_ctx are not added anymore in the sni trees from there - renamed in ckch_inst_new_load_{multi}_store() - new ssl_sock_load_ckchs() function calls ckch_inst_new_load_{multi}_store() and add the sni_ctx to the sni trees.
2019-10-07 07:52:11 -04:00
/* succeed, add the instance to the ckch_store's list of instance */
CLEANUP: lists/tree-wide: rename some list operations to avoid some confusion The current "ADD" vs "ADDQ" is confusing because when thinking in terms of appending at the end of a list, "ADD" naturally comes to mind, but here it does the opposite, it inserts. Several times already it's been incorrectly used where ADDQ was expected, the latest of which was a fortunate accident explained in 6fa922562 ("CLEANUP: stream: explain why we queue the stream at the head of the server list"). Let's use more explicit (but slightly longer) names now: LIST_ADD -> LIST_INSERT LIST_ADDQ -> LIST_APPEND LIST_ADDED -> LIST_INLIST LIST_DEL -> LIST_DELETE The same is true for MT_LISTs, including their "TRY" variant. LIST_DEL_INIT keeps its short name to encourage to use it instead of the lazier LIST_DELETE which is often less safe. The change is large (~674 non-comment entries) but is mechanical enough to remain safe. No permutation was performed, so any out-of-tree code can easily map older names to new ones. The list doc was updated.
2021-04-21 01:32:39 -04:00
LIST_APPEND(&ckchs->ckch_inst, &((*ckch_inst)->by_ckchs));
CLEANUP: ssl: make ckch_inst_new_load_(multi_)store handle errcode/warn ckch_inst_new_load_store() and ckch_inst_new_load_multi_store used to return 0 or >0 to indicate success or failure. Make it return a set of ERR_* instead so that its callers can transparently report its status. Given that its callers only used to know about ERR_ALERT | ERR_FATAL, his is the only code returned for now. And the comment was updated.
2019-10-17 07:16:58 -04:00
return errcode;
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
}
CLEANUP: ssl: make load_srv_{ckchs,cert} match their bind counterpart This patch makes things more consistent between the bind_conf functions and the server ones: - ssl_sock_load_srv_ckchs() loads the SSL_CTX in the server (ssl_sock_load_ckchs() load the SNIs in the bind_conf) - add the server parameter to ssl_sock_load_srv_ckchs() - changes made to the ckch_inst are done in ckch_inst_new_load_srv_store()
2021-01-26 06:01:46 -05:00
/* This function generates a <struct ckch_inst *> for a <struct server *>, and
* fill the SSL_CTX of the server.
*
* Returns a set of ERR_* flags possibly with an error in <err>. */
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
static int ssl_sock_load_srv_ckchs(const char *path, struct ckch_store *ckchs,
CLEANUP: ssl: make load_srv_{ckchs,cert} match their bind counterpart This patch makes things more consistent between the bind_conf functions and the server ones: - ssl_sock_load_srv_ckchs() loads the SSL_CTX in the server (ssl_sock_load_ckchs() load the SNIs in the bind_conf) - add the server parameter to ssl_sock_load_srv_ckchs() - changes made to the ckch_inst are done in ckch_inst_new_load_srv_store()
2021-01-26 06:01:46 -05:00
struct server *server, struct ckch_inst **ckch_inst, char **err)
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
{
int errcode = 0;
/* we found the ckchs in the tree, we can use it directly */
CLEANUP: ssl: remove SSL_CTX function parameter Since the server SSL_CTX is now stored in the ckch_inst, it is not needed anymore to pass an SSL_CTX to ckch_inst_new_load_srv_store() and ssl_sock_load_srv_ckchs().
2021-01-26 05:27:42 -05:00
errcode |= ckch_inst_new_load_srv_store(path, ckchs, ckch_inst, err);
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
if (errcode & ERR_CODE)
return errcode;
CLEANUP: ssl: make load_srv_{ckchs,cert} match their bind counterpart This patch makes things more consistent between the bind_conf functions and the server ones: - ssl_sock_load_srv_ckchs() loads the SSL_CTX in the server (ssl_sock_load_ckchs() load the SNIs in the bind_conf) - add the server parameter to ssl_sock_load_srv_ckchs() - changes made to the ckch_inst are done in ckch_inst_new_load_srv_store()
2021-01-26 06:01:46 -05:00
(*ckch_inst)->server = server;
/* Keep the reference to the SSL_CTX in the server. */
SSL_CTX_up_ref((*ckch_inst)->ctx);
server->ssl_ctx.ctx = (*ckch_inst)->ctx;
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
/* succeed, add the instance to the ckch_store's list of instance */
CLEANUP: lists/tree-wide: rename some list operations to avoid some confusion The current "ADD" vs "ADDQ" is confusing because when thinking in terms of appending at the end of a list, "ADD" naturally comes to mind, but here it does the opposite, it inserts. Several times already it's been incorrectly used where ADDQ was expected, the latest of which was a fortunate accident explained in 6fa922562 ("CLEANUP: stream: explain why we queue the stream at the head of the server list"). Let's use more explicit (but slightly longer) names now: LIST_ADD -> LIST_INSERT LIST_ADDQ -> LIST_APPEND LIST_ADDED -> LIST_INLIST LIST_DEL -> LIST_DELETE The same is true for MT_LISTs, including their "TRY" variant. LIST_DEL_INIT keeps its short name to encourage to use it instead of the lazier LIST_DELETE which is often less safe. The change is large (~674 non-comment entries) but is mechanical enough to remain safe. No permutation was performed, so any out-of-tree code can easily map older names to new ones. The list doc was updated.
2021-04-21 01:32:39 -04:00
LIST_APPEND(&ckchs->ckch_inst, &((*ckch_inst)->by_ckchs));
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
return errcode;
}
MINOR: ssl: directories are loaded like crt-list Generate a directory cache with the crtlist and crtlist_entry structures. With this new model, directories are a special case of the crt-lists. A directory is a crt-list which allows only one occurence of each file, without SSL configuration (ssl_bind_conf) and without filters.
2020-03-06 16:26:32 -05:00
REORG: ssl: move some functions above crtlist_load_cert_dir() Move some function above crtlist_load_cert_dir() so crtlist_load_cert_dir() is at the right place, and crtlist_free() can be used inside.
2020-03-30 12:45:10 -04:00
/* Make sure openssl opens /dev/urandom before the chroot. The work is only
* done once. Zero is returned if the operation fails. No error is returned
* if the random is said as not implemented, because we expect that openssl
* will use another method once needed.
*/
MINOR: ssl: always initialize random generator Explicitly call ssl_initialize_random to initialize the random generator in init() global function. If the initialization fails, the startup is interrupted. This commit is in preparation for support of ssl on dynamic servers. To be able to activate ssl on dynamic servers, it is necessary to ensure that the random generator is initialized on startup regardless of the config. It cannot be called at runtime as access to /dev/urandom is required. This also has the effect to fix the previous non-consistent behavior. Indeed, if bind or server in the config are using ssl, the initialization function was called, and if it failed, the startup was interrupted. Otherwise, the ssl initialization code could have been called through the ssl server for lua, but this times without blocking the startup on error. Or not called at all if lua was deactivated.
2021-05-19 09:35:29 -04:00
int ssl_initialize_random(void)
REORG: ssl: move some functions above crtlist_load_cert_dir() Move some function above crtlist_load_cert_dir() so crtlist_load_cert_dir() is at the right place, and crtlist_free() can be used inside.
2020-03-30 12:45:10 -04:00
{
unsigned char random;
static int random_initialized = 0;
if (!random_initialized && RAND_bytes(&random, 1) != 0)
random_initialized = 1;
return random_initialized;
}
MEDIUM: ssl: allow crt-list caching The crtlist structure defines a crt-list in the HAProxy configuration. It contains crtlist_entry structures which are the lines in a crt-list file. crt-list are now loaded in memory using crtlist and crtlist_entry structures. The file is read only once. The generation algorithm changed a little bit, new ckch instances are generated from the crtlist structures, instead of being generated during the file loading. The loading function was split in two, one that loads and caches the crt-list and certificates, and one that looks for a crt-list and creates the ckch instances. Filters are also stored in crtlist_entry->filters as a char ** so we can generate the sni_ctx again if needed. I won't be needed anymore to parse the sni_ctx to do that. A crtlist_entry stores the list of all ckch_inst that were generated from this entry.
2020-03-06 15:54:13 -05:00
/* Load a crt-list file, this is done in 2 parts:
* - store the content of the file in a crtlist structure with crtlist_entry structures
* - generate the instances by iterating on entries in the crtlist struct
*
* Nothing is locked there, this function is used in the configuration parser.
*
* Returns a set of ERR_* flags possibly with an error in <err>.
*/
MINOR: ssl: directories are loaded like crt-list Generate a directory cache with the crtlist and crtlist_entry structures. With this new model, directories are a special case of the crt-lists. A directory is a crt-list which allows only one occurence of each file, without SSL configuration (ssl_bind_conf) and without filters.
2020-03-06 16:26:32 -05:00
int ssl_sock_load_cert_list_file(char *file, int dir, struct bind_conf *bind_conf, struct proxy *curproxy, char **err)
MEDIUM: ssl: allow crt-list caching The crtlist structure defines a crt-list in the HAProxy configuration. It contains crtlist_entry structures which are the lines in a crt-list file. crt-list are now loaded in memory using crtlist and crtlist_entry structures. The file is read only once. The generation algorithm changed a little bit, new ckch instances are generated from the crtlist structures, instead of being generated during the file loading. The loading function was split in two, one that loads and caches the crt-list and certificates, and one that looks for a crt-list and creates the ckch instances. Filters are also stored in crtlist_entry->filters as a char ** so we can generate the sni_ctx again if needed. I won't be needed anymore to parse the sni_ctx to do that. A crtlist_entry stores the list of all ckch_inst that were generated from this entry.
2020-03-06 15:54:13 -05:00
{
struct crtlist *crtlist = NULL;
struct ebmb_node *eb;
BUG/MINOR: ssl: ckch_inst wrongly inserted in crtlist_entry The instances were wrongly inserted in the crtlist entries, all instances of a crt-list were inserted in the last crt-list entry. Which was kind of handy to free all instances upon error. Now that it's done correctly, the error path was changed, it must iterate on the entries and find the ckch_insts which were generated for this bind_conf. To avoid wasting time, it stops the iteration once it found the first unsuccessful generation.
2020-03-30 11:01:33 -04:00
struct crtlist_entry *entry = NULL;
MINOR: ssl: add a list of bind_conf in struct crtlist In order to be able to add new certificate in a crt-list, we need the list of bind_conf that uses this crt-list so we can create a ckch_inst for each of them.
2020-03-25 10:10:49 -04:00
struct bind_conf_list *bind_conf_node = NULL;
MEDIUM: ssl: allow crt-list caching The crtlist structure defines a crt-list in the HAProxy configuration. It contains crtlist_entry structures which are the lines in a crt-list file. crt-list are now loaded in memory using crtlist and crtlist_entry structures. The file is read only once. The generation algorithm changed a little bit, new ckch instances are generated from the crtlist structures, instead of being generated during the file loading. The loading function was split in two, one that loads and caches the crt-list and certificates, and one that looks for a crt-list and creates the ckch instances. Filters are also stored in crtlist_entry->filters as a char ** so we can generate the sni_ctx again if needed. I won't be needed anymore to parse the sni_ctx to do that. A crtlist_entry stores the list of all ckch_inst that were generated from this entry.
2020-03-06 15:54:13 -05:00
int cfgerr = 0;
BUG/MINOR: ssl: trailing slashes in directory names wrongly cached The crtlist_load_cert_dir() caches the directory name without trailing slashes when ssl_sock_load_cert_list_file() tries to lookup without cleaning the trailing slashes. This bug leads to creating the crtlist twice and prevents to remove correctly a crtlist_entry since it exists in the serveral crtlists created by accident. Move the trailing slashes cleanup in ssl_sock_load_cert_list_file() to fix the problem. This bug was introduced by 6be66ec ("MINOR: ssl: directories are loaded like crt-list")
2020-04-08 07:15:18 -04:00
char *end;
MEDIUM: ssl: allow crt-list caching The crtlist structure defines a crt-list in the HAProxy configuration. It contains crtlist_entry structures which are the lines in a crt-list file. crt-list are now loaded in memory using crtlist and crtlist_entry structures. The file is read only once. The generation algorithm changed a little bit, new ckch instances are generated from the crtlist structures, instead of being generated during the file loading. The loading function was split in two, one that loads and caches the crt-list and certificates, and one that looks for a crt-list and creates the ckch instances. Filters are also stored in crtlist_entry->filters as a char ** so we can generate the sni_ctx again if needed. I won't be needed anymore to parse the sni_ctx to do that. A crtlist_entry stores the list of all ckch_inst that were generated from this entry.
2020-03-06 15:54:13 -05:00
MINOR: ssl: add a list of bind_conf in struct crtlist In order to be able to add new certificate in a crt-list, we need the list of bind_conf that uses this crt-list so we can create a ckch_inst for each of them.
2020-03-25 10:10:49 -04:00
bind_conf_node = malloc(sizeof(*bind_conf_node));
if (!bind_conf_node) {
memprintf(err, "%sCan't alloc memory!\n", err && *err ? *err : "");
cfgerr |= ERR_FATAL | ERR_ALERT;
goto error;
}
bind_conf_node->next = NULL;
bind_conf_node->bind_conf = bind_conf;
BUG/MINOR: ssl: trailing slashes in directory names wrongly cached The crtlist_load_cert_dir() caches the directory name without trailing slashes when ssl_sock_load_cert_list_file() tries to lookup without cleaning the trailing slashes. This bug leads to creating the crtlist twice and prevents to remove correctly a crtlist_entry since it exists in the serveral crtlists created by accident. Move the trailing slashes cleanup in ssl_sock_load_cert_list_file() to fix the problem. This bug was introduced by 6be66ec ("MINOR: ssl: directories are loaded like crt-list")
2020-04-08 07:15:18 -04:00
/* strip trailing slashes, including first one */
for (end = file + strlen(file) - 1; end >= file && *end == '/'; end--)
*end = 0;
MEDIUM: ssl: allow crt-list caching The crtlist structure defines a crt-list in the HAProxy configuration. It contains crtlist_entry structures which are the lines in a crt-list file. crt-list are now loaded in memory using crtlist and crtlist_entry structures. The file is read only once. The generation algorithm changed a little bit, new ckch instances are generated from the crtlist structures, instead of being generated during the file loading. The loading function was split in two, one that loads and caches the crt-list and certificates, and one that looks for a crt-list and creates the ckch instances. Filters are also stored in crtlist_entry->filters as a char ** so we can generate the sni_ctx again if needed. I won't be needed anymore to parse the sni_ctx to do that. A crtlist_entry stores the list of all ckch_inst that were generated from this entry.
2020-03-06 15:54:13 -05:00
/* look for an existing crtlist or create one */
eb = ebst_lookup(&crtlists_tree, file);
if (eb) {
crtlist = ebmb_entry(eb, struct crtlist, node);
} else {
MINOR: ssl: directories are loaded like crt-list Generate a directory cache with the crtlist and crtlist_entry structures. With this new model, directories are a special case of the crt-lists. A directory is a crt-list which allows only one occurence of each file, without SSL configuration (ssl_bind_conf) and without filters.
2020-03-06 16:26:32 -05:00
/* load a crt-list OR a directory */
if (dir)
cfgerr |= crtlist_load_cert_dir(file, bind_conf, &crtlist, err);
else
cfgerr |= crtlist_parse_file(file, bind_conf, curproxy, &crtlist, err);
MEDIUM: ssl: allow crt-list caching The crtlist structure defines a crt-list in the HAProxy configuration. It contains crtlist_entry structures which are the lines in a crt-list file. crt-list are now loaded in memory using crtlist and crtlist_entry structures. The file is read only once. The generation algorithm changed a little bit, new ckch instances are generated from the crtlist structures, instead of being generated during the file loading. The loading function was split in two, one that loads and caches the crt-list and certificates, and one that looks for a crt-list and creates the ckch instances. Filters are also stored in crtlist_entry->filters as a char ** so we can generate the sni_ctx again if needed. I won't be needed anymore to parse the sni_ctx to do that. A crtlist_entry stores the list of all ckch_inst that were generated from this entry.
2020-03-06 15:54:13 -05:00
if (!(cfgerr & ERR_CODE))
ebst_insert(&crtlists_tree, &crtlist->node);
}
if (cfgerr & ERR_CODE) {
cfgerr |= ERR_FATAL | ERR_ALERT;
goto error;
}
/* generates ckch instance from the crtlist_entry */
list_for_each_entry(entry, &crtlist->ord_entries, by_crtlist) {
struct ckch_store *store;
struct ckch_inst *ckch_inst = NULL;
MEDIUM: ssl: generate '*' SNI filters for default certificates This patch follows the previous one about default certificate selection ("MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection"). This patch generates '*" SNI filters for the first certificate of a bind line, it will be used to match default certificates. Instead of setting the default_ctx pointer in the bind line. Since the filters are in the SNI tree, it allows to have multiple default certificate and restore the ecdsa/rsa selection with a multi-cert bundle. This configuration: # foobar.pem.ecdsa and foobar.pem.rsa bind *:8443 ssl crt foobar.pem crt next.pem will use "foobar.pem.ecdsa" and "foobar.pem.rsa" as default certificates. Note: there is still cleanup needed around default_ctx. This was discussed in github issue #2392.
2024-01-10 10:07:17 -05:00
int is_default = 0;
MEDIUM: ssl: allow crt-list caching The crtlist structure defines a crt-list in the HAProxy configuration. It contains crtlist_entry structures which are the lines in a crt-list file. crt-list are now loaded in memory using crtlist and crtlist_entry structures. The file is read only once. The generation algorithm changed a little bit, new ckch instances are generated from the crtlist structures, instead of being generated during the file loading. The loading function was split in two, one that loads and caches the crt-list and certificates, and one that looks for a crt-list and creates the ckch instances. Filters are also stored in crtlist_entry->filters as a char ** so we can generate the sni_ctx again if needed. I won't be needed anymore to parse the sni_ctx to do that. A crtlist_entry stores the list of all ckch_inst that were generated from this entry.
2020-03-06 15:54:13 -05:00
store = entry->node.key;
MEDIUM: ssl: generate '*' SNI filters for default certificates This patch follows the previous one about default certificate selection ("MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection"). This patch generates '*" SNI filters for the first certificate of a bind line, it will be used to match default certificates. Instead of setting the default_ctx pointer in the bind line. Since the filters are in the SNI tree, it allows to have multiple default certificate and restore the ecdsa/rsa selection with a multi-cert bundle. This configuration: # foobar.pem.ecdsa and foobar.pem.rsa bind *:8443 ssl crt foobar.pem crt next.pem will use "foobar.pem.ecdsa" and "foobar.pem.rsa" as default certificates. Note: there is still cleanup needed around default_ctx. This was discussed in github issue #2392.
2024-01-10 10:07:17 -05:00
/* if the SNI trees were empty the first "crt" become a default certificate,
* it can be applied on multiple certificates if it's a bundle */
if (eb_is_empty(&bind_conf->sni_ctx) && eb_is_empty(&bind_conf->sni_w_ctx))
is_default = 1;
cfgerr |= ssl_sock_load_ckchs(store->path, store, bind_conf, entry->ssl_conf, entry->filters, entry->fcount, is_default, &ckch_inst, err);
MEDIUM: ssl: allow crt-list caching The crtlist structure defines a crt-list in the HAProxy configuration. It contains crtlist_entry structures which are the lines in a crt-list file. crt-list are now loaded in memory using crtlist and crtlist_entry structures. The file is read only once. The generation algorithm changed a little bit, new ckch instances are generated from the crtlist structures, instead of being generated during the file loading. The loading function was split in two, one that loads and caches the crt-list and certificates, and one that looks for a crt-list and creates the ckch instances. Filters are also stored in crtlist_entry->filters as a char ** so we can generate the sni_ctx again if needed. I won't be needed anymore to parse the sni_ctx to do that. A crtlist_entry stores the list of all ckch_inst that were generated from this entry.
2020-03-06 15:54:13 -05:00
if (cfgerr & ERR_CODE) {
memprintf(err, "error processing line %d in file '%s' : %s", entry->linenum, file, *err);
goto error;
}
CLEANUP: lists/tree-wide: rename some list operations to avoid some confusion The current "ADD" vs "ADDQ" is confusing because when thinking in terms of appending at the end of a list, "ADD" naturally comes to mind, but here it does the opposite, it inserts. Several times already it's been incorrectly used where ADDQ was expected, the latest of which was a fortunate accident explained in 6fa922562 ("CLEANUP: stream: explain why we queue the stream at the head of the server list"). Let's use more explicit (but slightly longer) names now: LIST_ADD -> LIST_INSERT LIST_ADDQ -> LIST_APPEND LIST_ADDED -> LIST_INLIST LIST_DEL -> LIST_DELETE The same is true for MT_LISTs, including their "TRY" variant. LIST_DEL_INIT keeps its short name to encourage to use it instead of the lazier LIST_DELETE which is often less safe. The change is large (~674 non-comment entries) but is mechanical enough to remain safe. No permutation was performed, so any out-of-tree code can easily map older names to new ones. The list doc was updated.
2021-04-21 01:32:39 -04:00
LIST_APPEND(&entry->ckch_inst, &ckch_inst->by_crtlist_entry);
CLEANUP: ssl/cli: use the list of filters in the crtlist_entry In 'commit ssl cert', instead of trying to regenerate a list of filters from the SNIs, use the list provided by the crtlist_entry used to generate the ckch_inst. This list of filters doesn't need to be free'd anymore since they are always reused from the crtlist_entry.
2020-04-08 10:29:15 -04:00
ckch_inst->crtlist_entry = entry;
MEDIUM: ssl: allow crt-list caching The crtlist structure defines a crt-list in the HAProxy configuration. It contains crtlist_entry structures which are the lines in a crt-list file. crt-list are now loaded in memory using crtlist and crtlist_entry structures. The file is read only once. The generation algorithm changed a little bit, new ckch instances are generated from the crtlist structures, instead of being generated during the file loading. The loading function was split in two, one that loads and caches the crt-list and certificates, and one that looks for a crt-list and creates the ckch instances. Filters are also stored in crtlist_entry->filters as a char ** so we can generate the sni_ctx again if needed. I won't be needed anymore to parse the sni_ctx to do that. A crtlist_entry stores the list of all ckch_inst that were generated from this entry.
2020-03-06 15:54:13 -05:00
}
MINOR: ssl: add a list of bind_conf in struct crtlist In order to be able to add new certificate in a crt-list, we need the list of bind_conf that uses this crt-list so we can create a ckch_inst for each of them.
2020-03-25 10:10:49 -04:00
/* add the bind_conf to the list */
bind_conf_node->next = crtlist->bind_conf;
crtlist->bind_conf = bind_conf_node;
MEDIUM: ssl: allow crt-list caching The crtlist structure defines a crt-list in the HAProxy configuration. It contains crtlist_entry structures which are the lines in a crt-list file. crt-list are now loaded in memory using crtlist and crtlist_entry structures. The file is read only once. The generation algorithm changed a little bit, new ckch instances are generated from the crtlist structures, instead of being generated during the file loading. The loading function was split in two, one that loads and caches the crt-list and certificates, and one that looks for a crt-list and creates the ckch instances. Filters are also stored in crtlist_entry->filters as a char ** so we can generate the sni_ctx again if needed. I won't be needed anymore to parse the sni_ctx to do that. A crtlist_entry stores the list of all ckch_inst that were generated from this entry.
2020-03-06 15:54:13 -05:00
return cfgerr;
error:
{
BUG/MINOR: ssl: ckch_inst wrongly inserted in crtlist_entry The instances were wrongly inserted in the crtlist entries, all instances of a crt-list were inserted in the last crt-list entry. Which was kind of handy to free all instances upon error. Now that it's done correctly, the error path was changed, it must iterate on the entries and find the ckch_insts which were generated for this bind_conf. To avoid wasting time, it stops the iteration once it found the first unsuccessful generation.
2020-03-30 11:01:33 -04:00
struct crtlist_entry *lastentry;
MEDIUM: ssl: allow crt-list caching The crtlist structure defines a crt-list in the HAProxy configuration. It contains crtlist_entry structures which are the lines in a crt-list file. crt-list are now loaded in memory using crtlist and crtlist_entry structures. The file is read only once. The generation algorithm changed a little bit, new ckch instances are generated from the crtlist structures, instead of being generated during the file loading. The loading function was split in two, one that loads and caches the crt-list and certificates, and one that looks for a crt-list and creates the ckch instances. Filters are also stored in crtlist_entry->filters as a char ** so we can generate the sni_ctx again if needed. I won't be needed anymore to parse the sni_ctx to do that. A crtlist_entry stores the list of all ckch_inst that were generated from this entry.
2020-03-06 15:54:13 -05:00
struct ckch_inst *inst, *s_inst;
BUG/MINOR: ssl: ckch_inst wrongly inserted in crtlist_entry The instances were wrongly inserted in the crtlist entries, all instances of a crt-list were inserted in the last crt-list entry. Which was kind of handy to free all instances upon error. Now that it's done correctly, the error path was changed, it must iterate on the entries and find the ckch_insts which were generated for this bind_conf. To avoid wasting time, it stops the iteration once it found the first unsuccessful generation.
2020-03-30 11:01:33 -04:00
lastentry = entry; /* which entry we tried to generate last */
if (lastentry) {
list_for_each_entry(entry, &crtlist->ord_entries, by_crtlist) {
if (entry == lastentry) /* last entry we tried to generate, no need to go further */
break;
list_for_each_entry_safe(inst, s_inst, &entry->ckch_inst, by_crtlist_entry) {
MEDIUM: ssl: allow crt-list caching The crtlist structure defines a crt-list in the HAProxy configuration. It contains crtlist_entry structures which are the lines in a crt-list file. crt-list are now loaded in memory using crtlist and crtlist_entry structures. The file is read only once. The generation algorithm changed a little bit, new ckch instances are generated from the crtlist structures, instead of being generated during the file loading. The loading function was split in two, one that loads and caches the crt-list and certificates, and one that looks for a crt-list and creates the ckch instances. Filters are also stored in crtlist_entry->filters as a char ** so we can generate the sni_ctx again if needed. I won't be needed anymore to parse the sni_ctx to do that. A crtlist_entry stores the list of all ckch_inst that were generated from this entry.
2020-03-06 15:54:13 -05:00
BUG/MINOR: ssl: ckch_inst wrongly inserted in crtlist_entry The instances were wrongly inserted in the crtlist entries, all instances of a crt-list were inserted in the last crt-list entry. Which was kind of handy to free all instances upon error. Now that it's done correctly, the error path was changed, it must iterate on the entries and find the ckch_insts which were generated for this bind_conf. To avoid wasting time, it stops the iteration once it found the first unsuccessful generation.
2020-03-30 11:01:33 -04:00
/* this was not generated for this bind_conf, skip */
if (inst->bind_conf != bind_conf)
continue;
MINOR: ssl: free instances and SNIs with ckch_inst_free() Remove duplicated code by creating a new function ckch_inst_free() which deals with the SNIs linked in a ckch_inst and free the ckch_inst.
2020-04-09 10:31:05 -04:00
/* free the sni_ctx and instance */
ckch_inst_free(inst);
BUG/MINOR: ssl: ckch_inst wrongly inserted in crtlist_entry The instances were wrongly inserted in the crtlist entries, all instances of a crt-list were inserted in the last crt-list entry. Which was kind of handy to free all instances upon error. Now that it's done correctly, the error path was changed, it must iterate on the entries and find the ckch_insts which were generated for this bind_conf. To avoid wasting time, it stops the iteration once it found the first unsuccessful generation.
2020-03-30 11:01:33 -04:00
}
MEDIUM: ssl: allow crt-list caching The crtlist structure defines a crt-list in the HAProxy configuration. It contains crtlist_entry structures which are the lines in a crt-list file. crt-list are now loaded in memory using crtlist and crtlist_entry structures. The file is read only once. The generation algorithm changed a little bit, new ckch instances are generated from the crtlist structures, instead of being generated during the file loading. The loading function was split in two, one that loads and caches the crt-list and certificates, and one that looks for a crt-list and creates the ckch instances. Filters are also stored in crtlist_entry->filters as a char ** so we can generate the sni_ctx again if needed. I won't be needed anymore to parse the sni_ctx to do that. A crtlist_entry stores the list of all ckch_inst that were generated from this entry.
2020-03-06 15:54:13 -05:00
}
}
MINOR: ssl: add a list of bind_conf in struct crtlist In order to be able to add new certificate in a crt-list, we need the list of bind_conf that uses this crt-list so we can create a ckch_inst for each of them.
2020-03-25 10:10:49 -04:00
free(bind_conf_node);
MEDIUM: ssl: allow crt-list caching The crtlist structure defines a crt-list in the HAProxy configuration. It contains crtlist_entry structures which are the lines in a crt-list file. crt-list are now loaded in memory using crtlist and crtlist_entry structures. The file is read only once. The generation algorithm changed a little bit, new ckch instances are generated from the crtlist structures, instead of being generated during the file loading. The loading function was split in two, one that loads and caches the crt-list and certificates, and one that looks for a crt-list and creates the ckch instances. Filters are also stored in crtlist_entry->filters as a char ** so we can generate the sni_ctx again if needed. I won't be needed anymore to parse the sni_ctx to do that. A crtlist_entry stores the list of all ckch_inst that were generated from this entry.
2020-03-06 15:54:13 -05:00
}
MEDIUM: ssl: add mapping from SNI to cert file using "crt-list" It designates a list of PEM file with an optional list of SNI filter per certificate, with the following format for each line : <crtfile>[ <snifilter>]* Wildcards are supported in the SNI filter. The certificates will be presented to clients who provide a valid TLS Server Name Indication field matching one of SNI filter. If no SNI filter is specified the CN and alt subjects are used.
2013-01-22 09:31:15 -05:00
return cfgerr;
}
REORG: ssl: move ssl_sock_load_cert() Move the ssl_sock_load_cert() at the right place.
2020-03-16 09:45:55 -04:00
/* Returns a set of ERR_* flags possibly with an error in <err>. */
MEDIUM: ssl: implements 'default-crt' keyword for bind Lines The 'default-crt' bind keyword allows to specify multiples default/fallback certificates, allowing one to have an RSA as well as an ECDSA default.
2024-01-12 11:32:48 -05:00
int ssl_sock_load_cert(char *path, struct bind_conf *bind_conf, int is_default, char **err)
REORG: ssl: move ssl_sock_load_cert() Move the ssl_sock_load_cert() at the right place.
2020-03-16 09:45:55 -04:00
{
struct stat buf;
int cfgerr = 0;
struct ckch_store *ckchs;
MINOR: ssl: pass ckch_inst to ssl_sock_load_ckchs() Pass a pointer to the struct ckch_inst to the ssl_sock_load_ckchs() function so we can manipulate the ckch_inst from ssl_sock_load_cert_list_file() and ssl_sock_load_cert().
2020-03-09 11:48:43 -04:00
struct ckch_inst *ckch_inst = NULL;
BUG/MEDIUM: ssl: error when no certificate are found When a non-existing file was specified in the configuration, haproxy does not exits with an error which is not normal. This bug was introduced by dfa93be ("MEDIUM: ssl: emulate multi-cert bundles loading in standard loading") which does nothing if the stat failed. This patch introduce a "found" variable which is checked at the end of the function so we exit with an error if no find were found. Must be backported to 2.3.
2020-11-20 09:36:13 -05:00
int found = 0; /* did we found a file to load ? */
MEDIUM: ssl: generate '*' SNI filters for default certificates This patch follows the previous one about default certificate selection ("MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection"). This patch generates '*" SNI filters for the first certificate of a bind line, it will be used to match default certificates. Instead of setting the default_ctx pointer in the bind line. Since the filters are in the SNI tree, it allows to have multiple default certificate and restore the ecdsa/rsa selection with a multi-cert bundle. This configuration: # foobar.pem.ecdsa and foobar.pem.rsa bind *:8443 ssl crt foobar.pem crt next.pem will use "foobar.pem.ecdsa" and "foobar.pem.rsa" as default certificates. Note: there is still cleanup needed around default_ctx. This was discussed in github issue #2392.
2024-01-10 10:07:17 -05:00
/* if the SNI trees were empty the first "crt" become a default certificate,
* it can be applied on multiple certificates if it's a bundle */
MEDIUM: ssl: implements 'default-crt' keyword for bind Lines The 'default-crt' bind keyword allows to specify multiples default/fallback certificates, allowing one to have an RSA as well as an ECDSA default.
2024-01-12 11:32:48 -05:00
if (is_default == 0) {
if (eb_is_empty(&bind_conf->sni_ctx) && eb_is_empty(&bind_conf->sni_w_ctx))
is_default = 1;
}
REORG: ssl: move ssl_sock_load_cert() Move the ssl_sock_load_cert() at the right place.
2020-03-16 09:45:55 -04:00
if ((ckchs = ckchs_lookup(path))) {
/* we found the ckchs in the tree, we can use it directly */
MEDIUM: ssl: generate '*' SNI filters for default certificates This patch follows the previous one about default certificate selection ("MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection"). This patch generates '*" SNI filters for the first certificate of a bind line, it will be used to match default certificates. Instead of setting the default_ctx pointer in the bind line. Since the filters are in the SNI tree, it allows to have multiple default certificate and restore the ecdsa/rsa selection with a multi-cert bundle. This configuration: # foobar.pem.ecdsa and foobar.pem.rsa bind *:8443 ssl crt foobar.pem crt next.pem will use "foobar.pem.ecdsa" and "foobar.pem.rsa" as default certificates. Note: there is still cleanup needed around default_ctx. This was discussed in github issue #2392.
2024-01-10 10:07:17 -05:00
cfgerr |= ssl_sock_load_ckchs(path, ckchs, bind_conf, NULL, NULL, 0, is_default, &ckch_inst, err);
BUG/MINOR: ssl: Detect more 'ocsp-update' incompatibilities The inconsistencies in 'ocsp-update' parameter were only checked when parsing a crt-list line so if a certificate was used on a bind line after being used in a crt-list with 'ocsp-update' set to 'on', then no error would be raised. This patch helps detect such inconsistencies. This patch can be backported up to branch 2.8.
2024-03-25 11:50:24 -04:00
MEDIUM: ssl: Add 'tune.ssl.ocsp-update.mode' global option This option can be used to set a default ocsp-update mode for all certificates of a given conf file. It allows to activate ocsp-update on certificates without the need to create separate crt-lists. It can still be superseded by the crt-list 'ocsp-update' option. It takes either "on" or "off" as value and defaults to "off". Since setting this new parameter to "on" would mean that we try to enable ocsp-update on any certificate, and also certificates that don't have an OCSP URI, the checks performed in ssl_sock_load_ocsp were softened. We don't systematically raise an error when trying to enable ocsp-update on a certificate that does not have an OCSP URI, be it via the global option or the crt-list one. We will still raise an error when a user tries to load a certificate that does have an OCSP URI but a missing issuer certificate (if ocsp-update is enabled).
2024-03-25 11:50:25 -04:00
/* The ckch_store might have been created through a crt-list
* line so we must check that the ocsp-update modes are still
* compatible between the global mode and the explicit one from
* the crt-list. */
cfgerr |= ocsp_update_check_cfg_consistency(ckchs, NULL, path, err);
BUG/MINOR: ssl: Detect more 'ocsp-update' incompatibilities The inconsistencies in 'ocsp-update' parameter were only checked when parsing a crt-list line so if a certificate was used on a bind line after being used in a crt-list with 'ocsp-update' set to 'on', then no error would be raised. This patch helps detect such inconsistencies. This patch can be backported up to branch 2.8.
2024-03-25 11:50:24 -04:00
BUG/MEDIUM: ssl: error when no certificate are found When a non-existing file was specified in the configuration, haproxy does not exits with an error which is not normal. This bug was introduced by dfa93be ("MEDIUM: ssl: emulate multi-cert bundles loading in standard loading") which does nothing if the stat failed. This patch introduce a "found" variable which is checked at the end of the function so we exit with an error if no find were found. Must be backported to 2.3.
2020-11-20 09:36:13 -05:00
found++;
} else if (stat(path, &buf) == 0) {
found++;
REORG: ssl: move ssl_sock_load_cert() Move the ssl_sock_load_cert() at the right place.
2020-03-16 09:45:55 -04:00
if (S_ISDIR(buf.st_mode) == 0) {
CLEANUP: ssl: remove test on "multi" variable in ckch functions Since the removal of the multi-certificates bundle support, this variable is not useful anymore, we can remove all tests for this variable and suppose that every ckch contains a single certificate.
2020-09-16 10:08:08 -04:00
ckchs = ckchs_load_cert_file(path, err);
REORG: ssl: move ssl_sock_load_cert() Move the ssl_sock_load_cert() at the right place.
2020-03-16 09:45:55 -04:00
if (!ckchs)
BUG/MEDIUM: ssl: error when no certificate are found When a non-existing file was specified in the configuration, haproxy does not exits with an error which is not normal. This bug was introduced by dfa93be ("MEDIUM: ssl: emulate multi-cert bundles loading in standard loading") which does nothing if the stat failed. This patch introduce a "found" variable which is checked at the end of the function so we exit with an error if no find were found. Must be backported to 2.3.
2020-11-20 09:36:13 -05:00
cfgerr |= ERR_ALERT | ERR_FATAL;
MEDIUM: ssl: generate '*' SNI filters for default certificates This patch follows the previous one about default certificate selection ("MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection"). This patch generates '*" SNI filters for the first certificate of a bind line, it will be used to match default certificates. Instead of setting the default_ctx pointer in the bind line. Since the filters are in the SNI tree, it allows to have multiple default certificate and restore the ecdsa/rsa selection with a multi-cert bundle. This configuration: # foobar.pem.ecdsa and foobar.pem.rsa bind *:8443 ssl crt foobar.pem crt next.pem will use "foobar.pem.ecdsa" and "foobar.pem.rsa" as default certificates. Note: there is still cleanup needed around default_ctx. This was discussed in github issue #2392.
2024-01-10 10:07:17 -05:00
cfgerr |= ssl_sock_load_ckchs(path, ckchs, bind_conf, NULL, NULL, 0, is_default, &ckch_inst, err);
REORG: ssl: move ssl_sock_load_cert() Move the ssl_sock_load_cert() at the right place.
2020-03-16 09:45:55 -04:00
} else {
BUG/MEDIUM: ssl: error when no certificate are found When a non-existing file was specified in the configuration, haproxy does not exits with an error which is not normal. This bug was introduced by dfa93be ("MEDIUM: ssl: emulate multi-cert bundles loading in standard loading") which does nothing if the stat failed. This patch introduce a "found" variable which is checked at the end of the function so we exit with an error if no find were found. Must be backported to 2.3.
2020-11-20 09:36:13 -05:00
cfgerr |= ssl_sock_load_cert_list_file(path, 1, bind_conf, bind_conf->frontend, err);
REORG: ssl: move ssl_sock_load_cert() Move the ssl_sock_load_cert() at the right place.
2020-03-16 09:45:55 -04:00
}
} else {
/* stat failed, could be a bundle */
if (global_ssl.extra_files & SSL_GF_BUNDLE) {
MEDIUM: ssl: emulate multi-cert bundles loading in standard loading Like the previous commit, this one emulates the bundling by loading each certificate separately and storing it in a separate SSL_CTX. This patch does it for the standard certificate loading, which means outside directories or crt-list. The multi-certificates bundle was the common way of offering multiple certificates of different types (ecdsa and rsa) for a same SSL_CTX. This was implemented with OpenSSL 1.0.2 before the client_hello callback was available. Now that all versions which does not support this callback are deprecated (< 1.1.0), we can safely removes the support for the bundle which was inconvenient and complexify too much the code.
2020-09-16 08:48:52 -04:00
char fp[MAXPATHLEN+1] = {0};
int n = 0;
/* Load all possible certs and keys in separate ckch_store */
for (n = 0; n < SSL_SOCK_NUM_KEYTYPES; n++) {
struct stat buf;
int ret;
ret = snprintf(fp, sizeof(fp), "%s.%s", path, SSL_SOCK_KEYTYPE_NAMES[n]);
if (ret > sizeof(fp))
continue;
if ((ckchs = ckchs_lookup(fp))) {
MEDIUM: ssl: generate '*' SNI filters for default certificates This patch follows the previous one about default certificate selection ("MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection"). This patch generates '*" SNI filters for the first certificate of a bind line, it will be used to match default certificates. Instead of setting the default_ctx pointer in the bind line. Since the filters are in the SNI tree, it allows to have multiple default certificate and restore the ecdsa/rsa selection with a multi-cert bundle. This configuration: # foobar.pem.ecdsa and foobar.pem.rsa bind *:8443 ssl crt foobar.pem crt next.pem will use "foobar.pem.ecdsa" and "foobar.pem.rsa" as default certificates. Note: there is still cleanup needed around default_ctx. This was discussed in github issue #2392.
2024-01-10 10:07:17 -05:00
cfgerr |= ssl_sock_load_ckchs(fp, ckchs, bind_conf, NULL, NULL, 0, is_default, &ckch_inst, err);
BUG/MEDIUM: ssl: error when no certificate are found When a non-existing file was specified in the configuration, haproxy does not exits with an error which is not normal. This bug was introduced by dfa93be ("MEDIUM: ssl: emulate multi-cert bundles loading in standard loading") which does nothing if the stat failed. This patch introduce a "found" variable which is checked at the end of the function so we exit with an error if no find were found. Must be backported to 2.3.
2020-11-20 09:36:13 -05:00
found++;
MEDIUM: ssl: emulate multi-cert bundles loading in standard loading Like the previous commit, this one emulates the bundling by loading each certificate separately and storing it in a separate SSL_CTX. This patch does it for the standard certificate loading, which means outside directories or crt-list. The multi-certificates bundle was the common way of offering multiple certificates of different types (ecdsa and rsa) for a same SSL_CTX. This was implemented with OpenSSL 1.0.2 before the client_hello callback was available. Now that all versions which does not support this callback are deprecated (< 1.1.0), we can safely removes the support for the bundle which was inconvenient and complexify too much the code.
2020-09-16 08:48:52 -04:00
} else {
if (stat(fp, &buf) == 0) {
BUG/MEDIUM: ssl: error when no certificate are found When a non-existing file was specified in the configuration, haproxy does not exits with an error which is not normal. This bug was introduced by dfa93be ("MEDIUM: ssl: emulate multi-cert bundles loading in standard loading") which does nothing if the stat failed. This patch introduce a "found" variable which is checked at the end of the function so we exit with an error if no find were found. Must be backported to 2.3.
2020-11-20 09:36:13 -05:00
found++;
CLEANUP: ssl: remove test on "multi" variable in ckch functions Since the removal of the multi-certificates bundle support, this variable is not useful anymore, we can remove all tests for this variable and suppose that every ckch contains a single certificate.
2020-09-16 10:08:08 -04:00
ckchs = ckchs_load_cert_file(fp, err);
MEDIUM: ssl: emulate multi-cert bundles loading in standard loading Like the previous commit, this one emulates the bundling by loading each certificate separately and storing it in a separate SSL_CTX. This patch does it for the standard certificate loading, which means outside directories or crt-list. The multi-certificates bundle was the common way of offering multiple certificates of different types (ecdsa and rsa) for a same SSL_CTX. This was implemented with OpenSSL 1.0.2 before the client_hello callback was available. Now that all versions which does not support this callback are deprecated (< 1.1.0), we can safely removes the support for the bundle which was inconvenient and complexify too much the code.
2020-09-16 08:48:52 -04:00
if (!ckchs)
BUG/MEDIUM: ssl: error when no certificate are found When a non-existing file was specified in the configuration, haproxy does not exits with an error which is not normal. This bug was introduced by dfa93be ("MEDIUM: ssl: emulate multi-cert bundles loading in standard loading") which does nothing if the stat failed. This patch introduce a "found" variable which is checked at the end of the function so we exit with an error if no find were found. Must be backported to 2.3.
2020-11-20 09:36:13 -05:00
cfgerr |= ERR_ALERT | ERR_FATAL;
MEDIUM: ssl: generate '*' SNI filters for default certificates This patch follows the previous one about default certificate selection ("MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection"). This patch generates '*" SNI filters for the first certificate of a bind line, it will be used to match default certificates. Instead of setting the default_ctx pointer in the bind line. Since the filters are in the SNI tree, it allows to have multiple default certificate and restore the ecdsa/rsa selection with a multi-cert bundle. This configuration: # foobar.pem.ecdsa and foobar.pem.rsa bind *:8443 ssl crt foobar.pem crt next.pem will use "foobar.pem.ecdsa" and "foobar.pem.rsa" as default certificates. Note: there is still cleanup needed around default_ctx. This was discussed in github issue #2392.
2024-01-10 10:07:17 -05:00
cfgerr |= ssl_sock_load_ckchs(fp, ckchs, bind_conf, NULL, NULL, 0, is_default, &ckch_inst, err);
MEDIUM: ssl: emulate multi-cert bundles loading in standard loading Like the previous commit, this one emulates the bundling by loading each certificate separately and storing it in a separate SSL_CTX. This patch does it for the standard certificate loading, which means outside directories or crt-list. The multi-certificates bundle was the common way of offering multiple certificates of different types (ecdsa and rsa) for a same SSL_CTX. This was implemented with OpenSSL 1.0.2 before the client_hello callback was available. Now that all versions which does not support this callback are deprecated (< 1.1.0), we can safely removes the support for the bundle which was inconvenient and complexify too much the code.
2020-09-16 08:48:52 -04:00
}
}
}
MEDIUM: ssl: fatal error with bundle + openssl < 1.1.1 Since HAProxy 2.3, OpenSSL 1.1.1 is a requirement for using a multi-certificate bundle in the configuration. This patch emits a fatal error when HAProxy tries to load a bundle with an older version of HAProxy. This problem was encountered by an user in issue #990. This must be backported in 2.3.
2020-12-04 09:45:02 -05:00
#if HA_OPENSSL_VERSION_NUMBER < 0x10101000L
if (found) {
memprintf(err, "%sCan't load '%s'. Loading a multi certificates bundle requires OpenSSL >= 1.1.1\n",
err && *err ? *err : "", path);
cfgerr |= ERR_ALERT | ERR_FATAL;
}
#endif
REORG: ssl: move ssl_sock_load_cert() Move the ssl_sock_load_cert() at the right place.
2020-03-16 09:45:55 -04:00
}
}
BUG/MEDIUM: ssl: error when no certificate are found When a non-existing file was specified in the configuration, haproxy does not exits with an error which is not normal. This bug was introduced by dfa93be ("MEDIUM: ssl: emulate multi-cert bundles loading in standard loading") which does nothing if the stat failed. This patch introduce a "found" variable which is checked at the end of the function so we exit with an error if no find were found. Must be backported to 2.3.
2020-11-20 09:36:13 -05:00
if (!found) {
memprintf(err, "%sunable to stat SSL certificate from file '%s' : %s.\n",
err && *err ? *err : "", path, strerror(errno));
cfgerr |= ERR_ALERT | ERR_FATAL;
}
REORG: ssl: move ssl_sock_load_cert() Move the ssl_sock_load_cert() at the right place.
2020-03-16 09:45:55 -04:00
return cfgerr;
}
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
/* Create a full ssl context and ckch instance that will be used for a specific
* backend server (server configuration line).
* Returns a set of ERR_* flags possibly with an error in <err>.
*/
MINOR: ssl: render file-access optional on server crt loading The function ssl_sock_load_srv_cert will be used at runtime for dynamic servers. If the cert is not loaded on ckch tree, we try to access it from the file-system. Now this access operation is rendered optional by a new function argument. It is only allowed at parsing time, but will be disabled for dynamic servers at runtime.
2021-05-21 10:22:11 -04:00
int ssl_sock_load_srv_cert(char *path, struct server *server, int create_if_none, char **err)
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
{
struct stat buf;
int cfgerr = 0;
struct ckch_store *ckchs;
int found = 0; /* did we found a file to load ? */
if ((ckchs = ckchs_lookup(path))) {
/* we found the ckchs in the tree, we can use it directly */
CLEANUP: ssl: make load_srv_{ckchs,cert} match their bind counterpart This patch makes things more consistent between the bind_conf functions and the server ones: - ssl_sock_load_srv_ckchs() loads the SSL_CTX in the server (ssl_sock_load_ckchs() load the SNIs in the bind_conf) - add the server parameter to ssl_sock_load_srv_ckchs() - changes made to the ckch_inst are done in ckch_inst_new_load_srv_store()
2021-01-26 06:01:46 -05:00
cfgerr |= ssl_sock_load_srv_ckchs(path, ckchs, server, &server->ssl_ctx.inst, err);
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
found++;
MINOR: ssl: render file-access optional on server crt loading The function ssl_sock_load_srv_cert will be used at runtime for dynamic servers. If the cert is not loaded on ckch tree, we try to access it from the file-system. Now this access operation is rendered optional by a new function argument. It is only allowed at parsing time, but will be disabled for dynamic servers at runtime.
2021-05-21 10:22:11 -04:00
} else {
if (!create_if_none) {
memprintf(err, "%sunable to stat SSL certificate '%s'.\n",
err && *err ? *err : "", path);
cfgerr |= ERR_ALERT | ERR_FATAL;
goto out;
}
if (stat(path, &buf) == 0) {
/* We do not manage directories on backend side. */
if (S_ISDIR(buf.st_mode) == 0) {
++found;
ckchs = ckchs_load_cert_file(path, err);
if (!ckchs)
cfgerr |= ERR_ALERT | ERR_FATAL;
cfgerr |= ssl_sock_load_srv_ckchs(path, ckchs, server, &server->ssl_ctx.inst, err);
}
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
}
}
if (!found) {
memprintf(err, "%sunable to stat SSL certificate from file '%s' : %s.\n",
err && *err ? *err : "", path, strerror(errno));
cfgerr |= ERR_ALERT | ERR_FATAL;
}
MINOR: ssl: render file-access optional on server crt loading The function ssl_sock_load_srv_cert will be used at runtime for dynamic servers. If the cert is not loaded on ckch tree, we try to access it from the file-system. Now this access operation is rendered optional by a new function argument. It is only allowed at parsing time, but will be disabled for dynamic servers at runtime.
2021-05-21 10:22:11 -04:00
out:
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
return cfgerr;
}
BUG/MEDIUM: ssl: in bind line, ssl-options after 'crt' are ignored. Bug introduced with "removes SSL_CTX_set_ssl_version call and cleanup CTX creation": ssl_sock_new_ctx is called before all the bind line is parsed. The fix consists of separating the use of default_ctx as the initialization context of the SSL connection via bind_conf->initial_ctx. Initial_ctx contains all the necessary parameters before performing the selection of the CTX: default_ctx is processed as others ctx without unnecessary parameters.
2017-03-06 09:34:44 -05:00
/* Create an initial CTX used to start the SSL connection before switchctx */
MEDIUM: ssl: ssl-min-ver and ssl-max-ver compatibility. In haproxy < 1.8, no-sslv3/no-tlsv1x are ignored when force-sslv3/force-tlsv1x is used (without warning). With this patch, no-sslv3/no-tlsv1x are ignored when ssl-min-ver or ssl-max-ver is used (with warning). When all SSL/TLS versions are disable: generate an error, not a warning. example: ssl-min-ver TLSV1.3 (or force-tlsv13) with a openssl <= 1.1.0.
2017-05-05 12:06:12 -04:00
static int
BUG/MEDIUM: ssl: in bind line, ssl-options after 'crt' are ignored. Bug introduced with "removes SSL_CTX_set_ssl_version call and cleanup CTX creation": ssl_sock_new_ctx is called before all the bind line is parsed. The fix consists of separating the use of default_ctx as the initialization context of the SSL connection via bind_conf->initial_ctx. Initial_ctx contains all the necessary parameters before performing the selection of the CTX: default_ctx is processed as others ctx without unnecessary parameters.
2017-03-06 09:34:44 -05:00
ssl_sock_initial_ctx(struct bind_conf *bind_conf)
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
{
MINOR: ssl: removes SSL_CTX_set_ssl_version call and cleanup CTX creation. BoringSSL doesn't support SSL_CTX_set_ssl_version. To remove this call, the CTX creation is cleanup to clarify what is happening. SSL_CTX_new is used to match the original behavior, in order: force-<method> according the method version then the default method with no-<method> options. OPENSSL_NO_SSL3 error message is now in force-sslv3 parsing (as force-tls*). For CTX creation in bind environement, all CTX set related to the initial ctx are aggregate to ssl_sock_new_ctx function for clarity. Tests with crt-list have shown that server_method, options and mode are linked to the initial CTX (default_ctx): all ssl-options are link to each bind line and must be removed from crt-list.
2017-03-03 06:21:32 -05:00
SSL_CTX *ctx = NULL;
MEDIUM: ssl: ssl_methods implementation is reworked and factored for min/max tlsxx Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. This patch introduce internal min/max and replace force-tlsxx implementation. SSL method configuration is store in 'struct tls_version_filter'. SSL method configuration to openssl setting is abstract in 'methodVersions' table. With openssl < 1.1.0, SSL_CTX_set_ssl_version is used for force (min == max). With openssl >= 1.1.0, SSL_CTX_set_min/max_proto_version is used.
2017-03-30 13:19:37 -04:00
long options =
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
SSL_OP_ALL | /* all known workarounds for bugs */
SSL_OP_NO_SSLv2 |
SSL_OP_NO_COMPRESSION |
MINOR: ssl: try to load Diffie-Hellman parameters from cert file Feature is disabled if openssl compiled with OPENSSL_NO_DH.
2012-09-20 10:19:02 -04:00
SSL_OP_SINGLE_DH_USE |
MINOR: ssl: add elliptic curve Diffie-Hellman support for ssl key generation Add 'ecdhe' on 'bind' statement: to set named curve used to generate ECDHE keys (ex: ecdhe secp521r1)
2012-09-20 11:10:03 -04:00
SSL_OP_SINGLE_ECDH_USE |
MINOR: ssl: remove prefer-server-ciphers statement and set it as the default on ssl listeners.
2012-10-04 12:44:19 -04:00
SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION |
MINOR: ssl: set SSL_OP_PRIORITIZE_CHACHA Sets OpenSSL 1.1.1's SSL_OP_PRIORITIZE_CHACHA unconditionally, as per [1]: When SSL_OP_CIPHER_SERVER_PREFERENCE is set, temporarily reprioritize ChaCha20-Poly1305 ciphers to the top of the server cipher list if a ChaCha20-Poly1305 cipher is at the top of the client cipher list. This helps those clients (e.g. mobile) use ChaCha20-Poly1305 if that cipher is anywhere in the server cipher list; but still allows other clients to use AES and other ciphers. Requires SSL_OP_CIPHER_SERVER_PREFERENCE. [1] https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_clear_options.html
2018-05-18 11:55:57 -04:00
SSL_OP_PRIORITIZE_CHACHA |
MINOR: ssl: remove prefer-server-ciphers statement and set it as the default on ssl listeners.
2012-10-04 12:44:19 -04:00
SSL_OP_CIPHER_SERVER_PREFERENCE;
MEDIUM: ssl: ssl_methods implementation is reworked and factored for min/max tlsxx Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. This patch introduce internal min/max and replace force-tlsxx implementation. SSL method configuration is store in 'struct tls_version_filter'. SSL method configuration to openssl setting is abstract in 'methodVersions' table. With openssl < 1.1.0, SSL_CTX_set_ssl_version is used for force (min == max). With openssl >= 1.1.0, SSL_CTX_set_min/max_proto_version is used.
2017-03-30 13:19:37 -04:00
long mode =
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
SSL_MODE_ENABLE_PARTIAL_WRITE |
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER |
MEDIUM: ssl: add support for smaller SSL records There's a very common openssl patch on the net meant to significantly reduce openssl's memory usage. This patch has been provided for many versions now, and it makes sense to add support for it given that it is very simple. It only requires to add an extra SSL_MODE flag. Just like for other flags, if the flag is unknown, it's unset. About 44kB of memory may be saved per SSL session with the patch.
2014-11-13 08:06:52 -05:00
SSL_MODE_RELEASE_BUFFERS |
SSL_MODE_SMALL_BUFFERS;
MINOR: ssl: remove duplicate ssl_methods in struct bind_conf Patch "MINOR: ssl: support ssl-min-ver and ssl-max-ver with crt-list" introduce ssl_methods in struct ssl_bind_conf. struct bind_conf have now ssl_methods and ssl_conf.ssl_methods (unused). It's error-prone. This patch remove the duplicate structure to avoid any confusion.
2017-08-09 12:26:20 -04:00
struct tls_version_filter *conf_ssl_methods = &bind_conf->ssl_conf.ssl_methods;
MEDIUM: ssl: calculate the real min/max TLS version and find holes Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. Find the real min/max versions (openssl capabilities and haproxy configuration) and generate warning with bad versions range. 'no-tlsxx' can generate 'holes': "The list of protocols available can be further limited using the SSL_OP_NO_X options of the SSL_CTX_set_options or SSL_set_options functions. Clients should avoid creating 'holes' in the set of protocols they support, when disabling a protocol, make sure that you also disable either all previous or all subsequent protocol versions. In clients, when a protocol version is disabled without disabling all previous protocol versions, the effect is to also disable all subsequent protocol versions." To not break compatibility, "holes" is authorized with warning, because openssl 1.1.0 and boringssl deal with it (keep the upper or lower range depending the case and version).
2017-03-30 13:25:07 -04:00
int i, min, max, hole;
MEDIUM: ssl: ssl-min-ver and ssl-max-ver compatibility. In haproxy < 1.8, no-sslv3/no-tlsv1x are ignored when force-sslv3/force-tlsv1x is used (without warning). With this patch, no-sslv3/no-tlsv1x are ignored when ssl-min-ver or ssl-max-ver is used (with warning). When all SSL/TLS versions are disable: generate an error, not a warning. example: ssl-min-ver TLSV1.3 (or force-tlsv13) with a openssl <= 1.1.0.
2017-05-05 12:06:12 -04:00
int flags = MC_SSL_O_ALL;
int cfgerr = 0;
MINOR: ssl: set ssl-min-ver in ambiguous configurations Using ssl-max-ver without ssl-min-ver is ambiguous. When the ssl-min-ver is not configured, and ssl-max-ver is set to a value lower than the default ssl-min-ver (which is TLSv1.2 currently), set the ssl-min-ver to the value of ssl-max-ver, and emit a warning.
2020-06-02 04:52:24 -04:00
const int default_min_ver = CONF_TLSV12;
MINOR: ssl: removes SSL_CTX_set_ssl_version call and cleanup CTX creation. BoringSSL doesn't support SSL_CTX_set_ssl_version. To remove this call, the CTX creation is cleanup to clarify what is happening. SSL_CTX_new is used to match the original behavior, in order: force-<method> according the method version then the default method with no-<method> options. OPENSSL_NO_SSL3 error message is now in force-sslv3 parsing (as force-tls*). For CTX creation in bind environement, all CTX set related to the initial ctx are aggregate to ssl_sock_new_ctx function for clarity. Tests with crt-list have shown that server_method, options and mode are linked to the initial CTX (default_ctx): all ssl-options are link to each bind line and must be removed from crt-list.
2017-03-03 06:21:32 -05:00
MEDIUM: ssl: ssl_methods implementation is reworked and factored for min/max tlsxx Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. This patch introduce internal min/max and replace force-tlsxx implementation. SSL method configuration is store in 'struct tls_version_filter'. SSL method configuration to openssl setting is abstract in 'methodVersions' table. With openssl < 1.1.0, SSL_CTX_set_ssl_version is used for force (min == max). With openssl >= 1.1.0, SSL_CTX_set_min/max_proto_version is used.
2017-03-30 13:19:37 -04:00
ctx = SSL_CTX_new(SSLv23_server_method());
MEDIUM: ssl: ssl-min-ver and ssl-max-ver compatibility. In haproxy < 1.8, no-sslv3/no-tlsv1x are ignored when force-sslv3/force-tlsv1x is used (without warning). With this patch, no-sslv3/no-tlsv1x are ignored when ssl-min-ver or ssl-max-ver is used (with warning). When all SSL/TLS versions are disable: generate an error, not a warning. example: ssl-min-ver TLSV1.3 (or force-tlsv13) with a openssl <= 1.1.0.
2017-05-05 12:06:12 -04:00
bind_conf->initial_ctx = ctx;
MEDIUM: ssl: allow to change the OpenSSL security level from global section The new "ssl-security-level" option allows one to change the OpenSSL security level without having to change the openssl.cnf global file of your distribution. This directives applies on every SSL_CTX context. People sometimes change their security level directly in the ciphers directive, however there are some cases when the security level change is not applied in the right order (for example when applying a DH param). Before this patch, it was to possible to trick by using a specific openssl.cnf file and start haproxy this way: OPENSSL_CONF=./openssl.cnf ./haproxy -f bug-2468.cfg Values for the security level can be found there: https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_security_level.html This was discussed in github issue #2468.
2024-03-12 11:22:34 -04:00
if (global_ssl.security_level > -1)
SSL_CTX_set_security_level(ctx, global_ssl.security_level);
MEDIUM: ssl: ssl-min-ver and ssl-max-ver compatibility. In haproxy < 1.8, no-sslv3/no-tlsv1x are ignored when force-sslv3/force-tlsv1x is used (without warning). With this patch, no-sslv3/no-tlsv1x are ignored when ssl-min-ver or ssl-max-ver is used (with warning). When all SSL/TLS versions are disable: generate an error, not a warning. example: ssl-min-ver TLSV1.3 (or force-tlsv13) with a openssl <= 1.1.0.
2017-05-05 12:06:12 -04:00
if (conf_ssl_methods->flags && (conf_ssl_methods->min || conf_ssl_methods->max))
CLEANUP: log: Rename Alert/Warning in ha_alert/ha_warning
2017-11-24 10:50:31 -05:00
ha_warning("Proxy '%s': no-sslv3/no-tlsv1x are ignored for bind '%s' at [%s:%d]. "
"Use only 'ssl-min-ver' and 'ssl-max-ver' to fix.\n",
bind_conf->frontend->id, bind_conf->arg, bind_conf->file, bind_conf->line);
MEDIUM: ssl: ssl-min-ver and ssl-max-ver compatibility. In haproxy < 1.8, no-sslv3/no-tlsv1x are ignored when force-sslv3/force-tlsv1x is used (without warning). With this patch, no-sslv3/no-tlsv1x are ignored when ssl-min-ver or ssl-max-ver is used (with warning). When all SSL/TLS versions are disable: generate an error, not a warning. example: ssl-min-ver TLSV1.3 (or force-tlsv13) with a openssl <= 1.1.0.
2017-05-05 12:06:12 -04:00
else
flags = conf_ssl_methods->flags;
MEDIUM: ssl: ssl_methods implementation is reworked and factored for min/max tlsxx Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. This patch introduce internal min/max and replace force-tlsxx implementation. SSL method configuration is store in 'struct tls_version_filter'. SSL method configuration to openssl setting is abstract in 'methodVersions' table. With openssl < 1.1.0, SSL_CTX_set_ssl_version is used for force (min == max). With openssl >= 1.1.0, SSL_CTX_set_min/max_proto_version is used.
2017-03-30 13:19:37 -04:00
MEDIUM: ssl: disable SSLv3 per default for bind For security, disable SSLv3 on bind line must be the default configuration. SSLv3 can be enabled with "ssl-min-ver SSLv3".
2017-05-15 09:53:41 -04:00
min = conf_ssl_methods->min;
max = conf_ssl_methods->max;
MINOR: ssl: set ssl-min-ver in ambiguous configurations Using ssl-max-ver without ssl-min-ver is ambiguous. When the ssl-min-ver is not configured, and ssl-max-ver is set to a value lower than the default ssl-min-ver (which is TLSv1.2 currently), set the ssl-min-ver to the value of ssl-max-ver, and emit a warning.
2020-06-02 04:52:24 -04:00
/* default minimum is TLSV12, */
if (!min) {
if (!max || (max >= default_min_ver)) {
min = default_min_ver;
} else {
ha_warning("Proxy '%s': Ambiguous configuration for bind '%s' at [%s:%d]: the ssl-min-ver value is not configured and the ssl-max-ver value is lower than the default ssl-min-ver value (%s). "
"Setting the ssl-min-ver to %s. Use 'ssl-min-ver' to fix this.\n",
bind_conf->frontend->id, bind_conf->arg, bind_conf->file, bind_conf->line, methodVersions[default_min_ver].name, methodVersions[max].name);
min = max;
}
}
MEDIUM: ssl: ctx_set_version/ssl_set_version func for methodVersions table This patch cleanup the usage of set_version func with a more suitable name: ctx_set_version. It introduce ssl_set_version func (unused for the moment).
2017-05-18 06:33:19 -04:00
/* Real min and max should be determinate with configuration and openssl's capabilities */
MEDIUM: ssl: disable SSLv3 per default for bind For security, disable SSLv3 on bind line must be the default configuration. SSLv3 can be enabled with "ssl-min-ver SSLv3".
2017-05-15 09:53:41 -04:00
if (min)
flags |= (methodVersions[min].flag - 1);
if (max)
flags |= ~((methodVersions[max].flag << 1) - 1);
MEDIUM: ssl: ctx_set_version/ssl_set_version func for methodVersions table This patch cleanup the usage of set_version func with a more suitable name: ctx_set_version. It introduce ssl_set_version func (unused for the moment).
2017-05-18 06:33:19 -04:00
/* find min, max and holes */
MEDIUM: ssl: calculate the real min/max TLS version and find holes Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. Find the real min/max versions (openssl capabilities and haproxy configuration) and generate warning with bad versions range. 'no-tlsxx' can generate 'holes': "The list of protocols available can be further limited using the SSL_OP_NO_X options of the SSL_CTX_set_options or SSL_set_options functions. Clients should avoid creating 'holes' in the set of protocols they support, when disabling a protocol, make sure that you also disable either all previous or all subsequent protocol versions. In clients, when a protocol version is disabled without disabling all previous protocol versions, the effect is to also disable all subsequent protocol versions." To not break compatibility, "holes" is authorized with warning, because openssl 1.1.0 and boringssl deal with it (keep the upper or lower range depending the case and version).
2017-03-30 13:25:07 -04:00
min = max = CONF_TLSV_NONE;
hole = 0;
MEDIUM: ssl: ssl_methods implementation is reworked and factored for min/max tlsxx Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. This patch introduce internal min/max and replace force-tlsxx implementation. SSL method configuration is store in 'struct tls_version_filter'. SSL method configuration to openssl setting is abstract in 'methodVersions' table. With openssl < 1.1.0, SSL_CTX_set_ssl_version is used for force (min == max). With openssl >= 1.1.0, SSL_CTX_set_min/max_proto_version is used.
2017-03-30 13:19:37 -04:00
for (i = CONF_TLSV_MIN; i <= CONF_TLSV_MAX; i++)
MEDIUM: ssl: calculate the real min/max TLS version and find holes Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. Find the real min/max versions (openssl capabilities and haproxy configuration) and generate warning with bad versions range. 'no-tlsxx' can generate 'holes': "The list of protocols available can be further limited using the SSL_OP_NO_X options of the SSL_CTX_set_options or SSL_set_options functions. Clients should avoid creating 'holes' in the set of protocols they support, when disabling a protocol, make sure that you also disable either all previous or all subsequent protocol versions. In clients, when a protocol version is disabled without disabling all previous protocol versions, the effect is to also disable all subsequent protocol versions." To not break compatibility, "holes" is authorized with warning, because openssl 1.1.0 and boringssl deal with it (keep the upper or lower range depending the case and version).
2017-03-30 13:25:07 -04:00
/* version is in openssl && version not disable in configuration */
MEDIUM: ssl: ssl-min-ver and ssl-max-ver compatibility. In haproxy < 1.8, no-sslv3/no-tlsv1x are ignored when force-sslv3/force-tlsv1x is used (without warning). With this patch, no-sslv3/no-tlsv1x are ignored when ssl-min-ver or ssl-max-ver is used (with warning). When all SSL/TLS versions are disable: generate an error, not a warning. example: ssl-min-ver TLSV1.3 (or force-tlsv13) with a openssl <= 1.1.0.
2017-05-05 12:06:12 -04:00
if (methodVersions[i].option && !(flags & methodVersions[i].flag)) {
MEDIUM: ssl: calculate the real min/max TLS version and find holes Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. Find the real min/max versions (openssl capabilities and haproxy configuration) and generate warning with bad versions range. 'no-tlsxx' can generate 'holes': "The list of protocols available can be further limited using the SSL_OP_NO_X options of the SSL_CTX_set_options or SSL_set_options functions. Clients should avoid creating 'holes' in the set of protocols they support, when disabling a protocol, make sure that you also disable either all previous or all subsequent protocol versions. In clients, when a protocol version is disabled without disabling all previous protocol versions, the effect is to also disable all subsequent protocol versions." To not break compatibility, "holes" is authorized with warning, because openssl 1.1.0 and boringssl deal with it (keep the upper or lower range depending the case and version).
2017-03-30 13:25:07 -04:00
if (min) {
if (hole) {
CLEANUP: log: Rename Alert/Warning in ha_alert/ha_warning
2017-11-24 10:50:31 -05:00
ha_warning("Proxy '%s': SSL/TLS versions range not contiguous for bind '%s' at [%s:%d]. "
"Hole find for %s. Use only 'ssl-min-ver' and 'ssl-max-ver' to fix.\n",
bind_conf->frontend->id, bind_conf->arg, bind_conf->file, bind_conf->line,
methodVersions[hole].name);
MEDIUM: ssl: calculate the real min/max TLS version and find holes Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. Find the real min/max versions (openssl capabilities and haproxy configuration) and generate warning with bad versions range. 'no-tlsxx' can generate 'holes': "The list of protocols available can be further limited using the SSL_OP_NO_X options of the SSL_CTX_set_options or SSL_set_options functions. Clients should avoid creating 'holes' in the set of protocols they support, when disabling a protocol, make sure that you also disable either all previous or all subsequent protocol versions. In clients, when a protocol version is disabled without disabling all previous protocol versions, the effect is to also disable all subsequent protocol versions." To not break compatibility, "holes" is authorized with warning, because openssl 1.1.0 and boringssl deal with it (keep the upper or lower range depending the case and version).
2017-03-30 13:25:07 -04:00
hole = 0;
}
max = i;
}
else {
min = max = i;
}
}
else {
if (min)
hole = i;
}
MEDIUM: ssl: ssl-min-ver and ssl-max-ver compatibility. In haproxy < 1.8, no-sslv3/no-tlsv1x are ignored when force-sslv3/force-tlsv1x is used (without warning). With this patch, no-sslv3/no-tlsv1x are ignored when ssl-min-ver or ssl-max-ver is used (with warning). When all SSL/TLS versions are disable: generate an error, not a warning. example: ssl-min-ver TLSV1.3 (or force-tlsv13) with a openssl <= 1.1.0.
2017-05-05 12:06:12 -04:00
if (!min) {
CLEANUP: log: Rename Alert/Warning in ha_alert/ha_warning
2017-11-24 10:50:31 -05:00
ha_alert("Proxy '%s': all SSL/TLS versions are disabled for bind '%s' at [%s:%d].\n",
bind_conf->frontend->id, bind_conf->arg, bind_conf->file, bind_conf->line);
MEDIUM: ssl: ssl-min-ver and ssl-max-ver compatibility. In haproxy < 1.8, no-sslv3/no-tlsv1x are ignored when force-sslv3/force-tlsv1x is used (without warning). With this patch, no-sslv3/no-tlsv1x are ignored when ssl-min-ver or ssl-max-ver is used (with warning). When all SSL/TLS versions are disable: generate an error, not a warning. example: ssl-min-ver TLSV1.3 (or force-tlsv13) with a openssl <= 1.1.0.
2017-05-05 12:06:12 -04:00
cfgerr += 1;
}
MINOR: ssl: support ssl-min-ver and ssl-max-ver with crt-list SSL/TLS version can be changed per certificat if and only if openssl lib support earlier callback on handshake and, of course, is implemented in haproxy. It's ok for BoringSSL. For Openssl, version 1.1.1 have such callback and could support it.
2017-05-18 06:46:50 -04:00
/* save real min/max in bind_conf */
conf_ssl_methods->min = min;
conf_ssl_methods->max = max;
MEDIUM: ssl: ssl_methods implementation is reworked and factored for min/max tlsxx Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. This patch introduce internal min/max and replace force-tlsxx implementation. SSL method configuration is store in 'struct tls_version_filter'. SSL method configuration to openssl setting is abstract in 'methodVersions' table. With openssl < 1.1.0, SSL_CTX_set_ssl_version is used for force (min == max). With openssl >= 1.1.0, SSL_CTX_set_min/max_proto_version is used.
2017-03-30 13:19:37 -04:00
CLEANUP: ssl-sock: use HA_OPENSSL_VERSION_NUMBER instead of OPENSSL_VERSION_NUMBER Most tests on OPENSSL_VERSION_NUMBER have become complex and break all the time because this number is fake for some derivatives like LibreSSL. This patch creates a new macro, HA_OPENSSL_VERSION_NUMBER, which will carry the real openssl version defining the compatibility level, and this version will be adjusted depending on the variants.
2019-05-09 07:26:41 -04:00
#if (HA_OPENSSL_VERSION_NUMBER < 0x1010000fL)
MEDIUM: ssl: ssl_methods implementation is reworked and factored for min/max tlsxx Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. This patch introduce internal min/max and replace force-tlsxx implementation. SSL method configuration is store in 'struct tls_version_filter'. SSL method configuration to openssl setting is abstract in 'methodVersions' table. With openssl < 1.1.0, SSL_CTX_set_ssl_version is used for force (min == max). With openssl >= 1.1.0, SSL_CTX_set_min/max_proto_version is used.
2017-03-30 13:19:37 -04:00
/* Keep force-xxx implementation as it is in older haproxy. It's a
CLEANUP: fix typos in the ssl_sock subsystem Fix some typos found in the code comments of the ssl_sock subsystem.
2018-11-15 12:07:59 -05:00
precautionary measure to avoid any surprise with older openssl version. */
MEDIUM: ssl: ssl_methods implementation is reworked and factored for min/max tlsxx Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. This patch introduce internal min/max and replace force-tlsxx implementation. SSL method configuration is store in 'struct tls_version_filter'. SSL method configuration to openssl setting is abstract in 'methodVersions' table. With openssl < 1.1.0, SSL_CTX_set_ssl_version is used for force (min == max). With openssl >= 1.1.0, SSL_CTX_set_min/max_proto_version is used.
2017-03-30 13:19:37 -04:00
if (min == max)
MEDIUM: ssl: ctx_set_version/ssl_set_version func for methodVersions table This patch cleanup the usage of set_version func with a more suitable name: ctx_set_version. It introduce ssl_set_version func (unused for the moment).
2017-05-18 06:33:19 -04:00
methodVersions[min].ctx_set_version(ctx, SET_SERVER);
MEDIUM: ssl: ssl-min-ver and ssl-max-ver compatibility. In haproxy < 1.8, no-sslv3/no-tlsv1x are ignored when force-sslv3/force-tlsv1x is used (without warning). With this patch, no-sslv3/no-tlsv1x are ignored when ssl-min-ver or ssl-max-ver is used (with warning). When all SSL/TLS versions are disable: generate an error, not a warning. example: ssl-min-ver TLSV1.3 (or force-tlsv13) with a openssl <= 1.1.0.
2017-05-05 12:06:12 -04:00
else
BUG/MINOR: ssl: fix ssl-{min,max}-ver with openssl < 1.1.0 In bug #676, it was reported that ssl-min-ver SSLv3 does not work in Amazon environments with OpenSSL 1.0.2. The reason for this is a patch of Amazon OpenSSL which sets SSL_OP_NO_SSLv3 in SSL_CTX_new(). Which is kind of a problem with our implementation of ssl-{min,max}-ver in old openSSL versions, because it does not try to clear existing version flags. This patch fixes the bug by cleaning versions flags known by HAProxy in the SSL_CTX before applying the right ones. Should be backported as far as 1.8.
2020-06-11 11:34:00 -04:00
for (i = CONF_TLSV_MIN; i <= CONF_TLSV_MAX; i++) {
/* clear every version flags in case SSL_CTX_new()
* returns an SSL_CTX with disabled versions */
SSL_CTX_clear_options(ctx, methodVersions[i].option);
MEDIUM: ssl: ssl-min-ver and ssl-max-ver compatibility. In haproxy < 1.8, no-sslv3/no-tlsv1x are ignored when force-sslv3/force-tlsv1x is used (without warning). With this patch, no-sslv3/no-tlsv1x are ignored when ssl-min-ver or ssl-max-ver is used (with warning). When all SSL/TLS versions are disable: generate an error, not a warning. example: ssl-min-ver TLSV1.3 (or force-tlsv13) with a openssl <= 1.1.0.
2017-05-05 12:06:12 -04:00
if (flags & methodVersions[i].flag)
options |= methodVersions[i].option;
BUG/MINOR: ssl: fix ssl-{min,max}-ver with openssl < 1.1.0 In bug #676, it was reported that ssl-min-ver SSLv3 does not work in Amazon environments with OpenSSL 1.0.2. The reason for this is a patch of Amazon OpenSSL which sets SSL_OP_NO_SSLv3 in SSL_CTX_new(). Which is kind of a problem with our implementation of ssl-{min,max}-ver in old openSSL versions, because it does not try to clear existing version flags. This patch fixes the bug by cleaning versions flags known by HAProxy in the SSL_CTX before applying the right ones. Should be backported as far as 1.8.
2020-06-11 11:34:00 -04:00
}
MEDIUM: ssl: ssl_methods implementation is reworked and factored for min/max tlsxx Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. This patch introduce internal min/max and replace force-tlsxx implementation. SSL method configuration is store in 'struct tls_version_filter'. SSL method configuration to openssl setting is abstract in 'methodVersions' table. With openssl < 1.1.0, SSL_CTX_set_ssl_version is used for force (min == max). With openssl >= 1.1.0, SSL_CTX_set_min/max_proto_version is used.
2017-03-30 13:19:37 -04:00
#else /* openssl >= 1.1.0 */
MEDIUM: ssl: calculate the real min/max TLS version and find holes Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. Find the real min/max versions (openssl capabilities and haproxy configuration) and generate warning with bad versions range. 'no-tlsxx' can generate 'holes': "The list of protocols available can be further limited using the SSL_OP_NO_X options of the SSL_CTX_set_options or SSL_set_options functions. Clients should avoid creating 'holes' in the set of protocols they support, when disabling a protocol, make sure that you also disable either all previous or all subsequent protocol versions. In clients, when a protocol version is disabled without disabling all previous protocol versions, the effect is to also disable all subsequent protocol versions." To not break compatibility, "holes" is authorized with warning, because openssl 1.1.0 and boringssl deal with it (keep the upper or lower range depending the case and version).
2017-03-30 13:25:07 -04:00
/* set the max_version is required to cap TLS version or activate new TLS (v1.3) */
MEDIUM: ssl: ctx_set_version/ssl_set_version func for methodVersions table This patch cleanup the usage of set_version func with a more suitable name: ctx_set_version. It introduce ssl_set_version func (unused for the moment).
2017-05-18 06:33:19 -04:00
methodVersions[min].ctx_set_version(ctx, SET_MIN);
methodVersions[max].ctx_set_version(ctx, SET_MAX);
MINOR: ssl: removes SSL_CTX_set_ssl_version call and cleanup CTX creation. BoringSSL doesn't support SSL_CTX_set_ssl_version. To remove this call, the CTX creation is cleanup to clarify what is happening. SSL_CTX_new is used to match the original behavior, in order: force-<method> according the method version then the default method with no-<method> options. OPENSSL_NO_SSL3 error message is now in force-sslv3 parsing (as force-tls*). For CTX creation in bind environement, all CTX set related to the initial ctx are aggregate to ssl_sock_new_ctx function for clarity. Tests with crt-list have shown that server_method, options and mode are linked to the initial CTX (default_ctx): all ssl-options are link to each bind line and must be removed from crt-list.
2017-03-03 06:21:32 -05:00
#endif
MEDIUM: ssl: ssl_methods implementation is reworked and factored for min/max tlsxx Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. This patch introduce internal min/max and replace force-tlsxx implementation. SSL method configuration is store in 'struct tls_version_filter'. SSL method configuration to openssl setting is abstract in 'methodVersions' table. With openssl < 1.1.0, SSL_CTX_set_ssl_version is used for force (min == max). With openssl >= 1.1.0, SSL_CTX_set_min/max_proto_version is used.
2017-03-30 13:19:37 -04:00
if (bind_conf->ssl_options & BC_SSL_O_NO_TLS_TICKETS)
options |= SSL_OP_NO_TICKET;
if (bind_conf->ssl_options & BC_SSL_O_PREF_CLIE_CIPH)
options &= ~SSL_OP_CIPHER_SERVER_PREFERENCE;
BUG/MEDIUM: ssl: Fix handling of TLS 1.3 KeyUpdate messages In OpenSSL 1.1.1 TLS 1.3 KeyUpdate messages will trigger the callback that is used to verify renegotiation is disabled. This means that these KeyUpdate messages fail. In OpenSSL 1.1.1 a better mechanism is available with the SSL_OP_NO_RENEGOTIATION flag that disables any TLS 1.2 and earlier negotiation. So if this SSL_OP_NO_RENEGOTIATION flag is available, instead of having a manual check, trust OpenSSL and disable the check. This means that TLS 1.3 KeyUpdate messages will work properly. Reported-By: Adam Langley <agl@imperialviolet.org>
2019-01-21 12:35:03 -05:00
#ifdef SSL_OP_NO_RENEGOTIATION
options |= SSL_OP_NO_RENEGOTIATION;
#endif
MEDIUM: ssl: ssl_methods implementation is reworked and factored for min/max tlsxx Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. This patch introduce internal min/max and replace force-tlsxx implementation. SSL method configuration is store in 'struct tls_version_filter'. SSL method configuration to openssl setting is abstract in 'methodVersions' table. With openssl < 1.1.0, SSL_CTX_set_ssl_version is used for force (min == max). With openssl >= 1.1.0, SSL_CTX_set_min/max_proto_version is used.
2017-03-30 13:19:37 -04:00
SSL_CTX_set_options(ctx, options);
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
BUILD: ssl: use SSL_MODE_ASYNC macro instead of OPENSSL_VERSION
2020-11-13 15:56:34 -05:00
#ifdef SSL_MODE_ASYNC
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
if (global_ssl.async)
mode |= SSL_MODE_ASYNC;
#endif
MEDIUM: ssl: ssl_methods implementation is reworked and factored for min/max tlsxx Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. This patch introduce internal min/max and replace force-tlsxx implementation. SSL method configuration is store in 'struct tls_version_filter'. SSL method configuration to openssl setting is abstract in 'methodVersions' table. With openssl < 1.1.0, SSL_CTX_set_ssl_version is used for force (min == max). With openssl >= 1.1.0, SSL_CTX_set_min/max_proto_version is used.
2017-03-30 13:19:37 -04:00
SSL_CTX_set_mode(ctx, mode);
MINOR: ssl: removes SSL_CTX_set_ssl_version call and cleanup CTX creation. BoringSSL doesn't support SSL_CTX_set_ssl_version. To remove this call, the CTX creation is cleanup to clarify what is happening. SSL_CTX_new is used to match the original behavior, in order: force-<method> according the method version then the default method with no-<method> options. OPENSSL_NO_SSL3 error message is now in force-sslv3 parsing (as force-tls*). For CTX creation in bind environement, all CTX set related to the initial ctx are aggregate to ssl_sock_new_ctx function for clarity. Tests with crt-list have shown that server_method, options and mode are linked to the initial CTX (default_ctx): all ssl-options are link to each bind line and must be removed from crt-list.
2017-03-03 06:21:32 -05:00
if (global_ssl.life_time)
SSL_CTX_set_timeout(ctx, global_ssl.life_time);
BUG/MEDIUM: ssl: in bind line, ssl-options after 'crt' are ignored. Bug introduced with "removes SSL_CTX_set_ssl_version call and cleanup CTX creation": ssl_sock_new_ctx is called before all the bind line is parsed. The fix consists of separating the use of default_ctx as the initialization context of the SSL connection via bind_conf->initial_ctx. Initial_ctx contains all the necessary parameters before performing the selection of the CTX: default_ctx is processed as others ctx without unnecessary parameters.
2017-03-06 09:34:44 -05:00
#ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME
BUILD: ssl: fix the ifdef mess in ssl_sock_initial_ctx ssl_sock_initial_ctx uses the wrong #ifdef to check the availability of the client_hello_cb. Cleanup the #ifdef, add comments and indentation.
2022-09-07 04:54:17 -04:00
# ifdef OPENSSL_IS_BORINGSSL
BUG/MEDIUM: ssl: in bind line, ssl-options after 'crt' are ignored. Bug introduced with "removes SSL_CTX_set_ssl_version call and cleanup CTX creation": ssl_sock_new_ctx is called before all the bind line is parsed. The fix consists of separating the use of default_ctx as the initialization context of the SSL connection via bind_conf->initial_ctx. Initial_ctx contains all the necessary parameters before performing the selection of the CTX: default_ctx is processed as others ctx without unnecessary parameters.
2017-03-06 09:34:44 -05:00
SSL_CTX_set_select_certificate_cb(ctx, ssl_sock_switchctx_cbk);
SSL_CTX_set_tlsext_servername_callback(ctx, ssl_sock_switchctx_err_cbk);
BUILD: ssl: fix the ifdef mess in ssl_sock_initial_ctx ssl_sock_initial_ctx uses the wrong #ifdef to check the availability of the client_hello_cb. Cleanup the #ifdef, add comments and indentation.
2022-09-07 04:54:17 -04:00
# elif defined(HAVE_SSL_CLIENT_HELLO_CB)
# if defined(SSL_OP_NO_ANTI_REPLAY)
BUG/MEDIUM: ssl: Don't set the max early data we can receive too early. When accepting the max early data, don't set it on the SSL_CTX while parsing the configuration, as at this point global.tune.maxrewrite may still be -1, either because it was not set, or because it hasn't been set yet. Instead, set it for each connection, just after we created the new SSL. Not doing so meant that we could pretend to accept early data bigger than one of our buffer. This should be backported to 2.1, 2.0, 1.9 and 1.8.
2019-12-17 09:39:54 -05:00
if (bind_conf->ssl_conf.early_data)
BUG/MEDIUM: ssl: Disable anti-replay protection and set max data with 0RTT. When using early data, disable the OpenSSL anti-replay protection, and set the max amount of early data we're ready to accept, based on the size of buffers, or early data won't work with the released OpenSSL 1.1.1. This should be backported to 1.8.
2019-01-02 12:46:41 -05:00
SSL_CTX_set_options(ctx, SSL_OP_NO_ANTI_REPLAY);
BUILD: ssl: fix the ifdef mess in ssl_sock_initial_ctx ssl_sock_initial_ctx uses the wrong #ifdef to check the availability of the client_hello_cb. Cleanup the #ifdef, add comments and indentation.
2022-09-07 04:54:17 -04:00
# endif /* ! SSL_OP_NO_ANTI_REPLAY */
MINOR: ssl: support Openssl 1.1.1 early callback for switchctx Use Openssl-1.1.1 SSL_CTX_set_client_hello_cb to mimic BoringSSL early callback. Native multi certificate and SSL/TLS method per certificate is now supported by Openssl >= 1.1.1.
2017-08-16 05:33:17 -04:00
SSL_CTX_set_client_hello_cb(ctx, ssl_sock_switchctx_cbk, NULL);
SSL_CTX_set_tlsext_servername_callback(ctx, ssl_sock_switchctx_err_cbk);
MINOR: ssl: activate the certificate selection callback for WolfSSL The PR which allows to chose a certificate depending on the ciphers and the signature algorithms was merged in WolfSSL. Let's activate this code. This could be backported in 2.9 only when the next WolfSSL release is available (5.6.5). It will also need a check on the version.
2023-12-08 05:33:03 -05:00
# elif defined(USE_OPENSSL_WOLFSSL)
MEDIUM: ssl: implement rsa/ecdsa selection with WolfSSL PR https://github.com/wolfSSL/wolfssl/pull/6963 implements primitives to extract ciphers and algorithm signatures. It allows to chose a certificate depending on the sigals and ciphers presented by the client (RSA or ECDSA). Since WolfSSL does not implement the clienthello callback, the patch uses the certificate callback (SSL_CTX_set_cert_cb()) The callback is inspired by our clienthello callback, however the extraction of client ciphers and sigalgs is simpler, wolfSSL_get_sigalg_info() and wolfSSL_get_ciphersuite_info() are used. This is not enabled by default yet as the PR was not merged.
2023-11-16 12:16:53 -05:00
SSL_CTX_set_cert_cb(ctx, ssl_sock_switchctx_wolfSSL_cbk, bind_conf);
# else
/* ! OPENSSL_IS_BORINGSSL && ! HAVE_SSL_CLIENT_HELLO_CB */
BUG/MEDIUM: ssl: in bind line, ssl-options after 'crt' are ignored. Bug introduced with "removes SSL_CTX_set_ssl_version call and cleanup CTX creation": ssl_sock_new_ctx is called before all the bind line is parsed. The fix consists of separating the use of default_ctx as the initialization context of the SSL connection via bind_conf->initial_ctx. Initial_ctx contains all the necessary parameters before performing the selection of the CTX: default_ctx is processed as others ctx without unnecessary parameters.
2017-03-06 09:34:44 -05:00
SSL_CTX_set_tlsext_servername_callback(ctx, ssl_sock_switchctx_cbk);
BUILD: ssl: fix the ifdef mess in ssl_sock_initial_ctx ssl_sock_initial_ctx uses the wrong #ifdef to check the availability of the client_hello_cb. Cleanup the #ifdef, add comments and indentation.
2022-09-07 04:54:17 -04:00
# endif
MINOR: ssl: generated certificate is missing in switchctx early callback Openssl 1.1.1 supports switchctx early callback and generated certificate. Generated certificate calls must be available in switchctx early callback.
2017-08-14 05:01:25 -04:00
SSL_CTX_set_tlsext_servername_arg(ctx, bind_conf);
BUILD: ssl: fix the ifdef mess in ssl_sock_initial_ctx ssl_sock_initial_ctx uses the wrong #ifdef to check the availability of the client_hello_cb. Cleanup the #ifdef, add comments and indentation.
2022-09-07 04:54:17 -04:00
#endif /* ! SSL_CTRL_SET_TLSEXT_HOSTNAME */
MEDIUM: ssl: ssl-min-ver and ssl-max-ver compatibility. In haproxy < 1.8, no-sslv3/no-tlsv1x are ignored when force-sslv3/force-tlsv1x is used (without warning). With this patch, no-sslv3/no-tlsv1x are ignored when ssl-min-ver or ssl-max-ver is used (with warning). When all SSL/TLS versions are disable: generate an error, not a warning. example: ssl-min-ver TLSV1.3 (or force-tlsv13) with a openssl <= 1.1.0.
2017-05-05 12:06:12 -04:00
return cfgerr;
MINOR: ssl: removes SSL_CTX_set_ssl_version call and cleanup CTX creation. BoringSSL doesn't support SSL_CTX_set_ssl_version. To remove this call, the CTX creation is cleanup to clarify what is happening. SSL_CTX_new is used to match the original behavior, in order: force-<method> according the method version then the default method with no-<method> options. OPENSSL_NO_SSL3 error message is now in force-sslv3 parsing (as force-tls*). For CTX creation in bind environement, all CTX set related to the initial ctx are aggregate to ssl_sock_new_ctx function for clarity. Tests with crt-list have shown that server_method, options and mode are linked to the initial CTX (default_ctx): all ssl-options are link to each bind line and must be removed from crt-list.
2017-03-03 06:21:32 -05:00
}
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
MINOR: shctx: Remove redundant arg from free_block callback The free_block callback does not get called on blocks that are not row heads anymore so we don't need too shared_block parameters.
2023-11-16 11:38:26 -05:00
static inline void sh_ssl_sess_free_blocks(struct shared_block *first, void *data)
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
{
MINOR: shctx: Remove redundant arg from free_block callback The free_block callback does not get called on blocks that are not row heads anymore so we don't need too shared_block parameters.
2023-11-16 11:38:26 -05:00
struct sh_ssl_sess_hdr *sh_ssl_sess = (struct sh_ssl_sess_hdr *)first->data;
if (first->len > 0)
sh_ssl_sess_tree_delete(sh_ssl_sess);
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
}
/* return first block from sh_ssl_sess */
static inline struct shared_block *sh_ssl_sess_first_block(struct sh_ssl_sess_hdr *sh_ssl_sess)
{
CLEANUP: use "offsetof" where appropriate let's use the C library macro "offsetof"
2023-04-15 17:39:43 -04:00
return (struct shared_block *)((unsigned char *)sh_ssl_sess - offsetof(struct shared_block, data));
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
}
/* store a session into the cache
* s_id : session id padded with zero to SSL_MAX_SSL_SESSION_ID_LENGTH
* data: asn1 encoded session
* data_len: asn1 encoded session length
* Returns 1 id session was stored (else 0)
*/
static int sh_ssl_sess_store(unsigned char *s_id, unsigned char *data, int data_len)
{
struct shared_block *first;
struct sh_ssl_sess_hdr *sh_ssl_sess, *oldsh_ssl_sess;
MINOR: shctx: Shared objects block by block allocation. This patch makes shctx capable of storing objects in several parts, each parts being made of several blocks. There is no more need to walk through until reaching the end of a row to append new blocks. A new pointer to a struct shared_block member, named last_reserved, has been added to struct shared_block so that to memorize the last block which was reserved by shctx_row_reserve_hot(). Same thing about "last_append" pointer which is used to memorize the last block used by shctx_row_data_append() to store the data.
2018-10-22 11:55:57 -04:00
first = shctx_row_reserve_hot(ssl_shctx, NULL, data_len + sizeof(struct sh_ssl_sess_hdr));
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
if (!first) {
/* Could not retrieve enough free blocks to store that session */
return 0;
}
MEDIUM: shctx: Descend shctx_lock calls into the shctx_row_reserve_hot Descend the shctx_lock calls into the shctx_row_reserve_hot so that the cases when we don't need to lock anything (enough space in the current row or not enough space in the 'avail' list) do not take the lock at all. In sh_ssl_sess_new_cb the lock had to be descended into sh_ssl_sess_store in order not to cover the shctx_row_reserve_hot call anymore.
2023-11-16 11:38:23 -05:00
shctx_wrlock(ssl_shctx);
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
/* STORE the key in the first elem */
sh_ssl_sess = (struct sh_ssl_sess_hdr *)first->data;
memcpy(sh_ssl_sess->key_data, s_id, SSL_MAX_SSL_SESSION_ID_LENGTH);
first->len = sizeof(struct sh_ssl_sess_hdr);
/* it returns the already existing node
or current node if none, never returns null */
oldsh_ssl_sess = sh_ssl_sess_tree_insert(sh_ssl_sess);
if (oldsh_ssl_sess != sh_ssl_sess) {
/* NOTE: Row couldn't be in use because we lock read & write function */
/* release the reserved row */
BUG/MEDIUM: ssl: wrong eviction from the session cache tree When using WolfSSL, there are some cases were the SSL_CTX_sess_new_cb is called with an existing session ID. These cases are not met with OpenSSL. When the ID is found in the session tree during the insertion, the shared_block len is not set to 0 and is not used. However if later the block is reused, since the len is not set to 0, the release callback will be called an ebmb_delete will be tried on the block, even if it's not in the tree, provoking a crash. The code was buggy from the beginning, but the case never happen with openssl which changes the ID. Must be backported in every maintained branches.
2023-01-31 08:12:28 -05:00
first->len = 0; /* the len must be liberated in order not to call the release callback on it */
MEDIUM: shctx: Remove 'hot' list from shared_context The "hot" list stored in a shared_context was used to keep a reference to shared blocks that were currently being used and were thus removed from the available list (so that they don't get reused for another cache response). This 'hot' list does not ever need to be shared across threads since every one of them only works on their current row. The main need behind this 'hot' list was to detach the corresponding blocks from the 'avail' list and to have a known list root when calling list_for_each_entry_from in shctx_row_data_append (for instance). Since we actually never need to iterate over all members of the 'hot' list, we can remove it and replace the inc_hot/dec_hot logic by a detach/reattach one.
2023-11-16 11:38:19 -05:00
shctx_row_reattach(ssl_shctx, first);
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
/* replace the previous session already in the tree */
sh_ssl_sess = oldsh_ssl_sess;
/* ignore the previous session data, only use the header */
first = sh_ssl_sess_first_block(sh_ssl_sess);
MEDIUM: shctx: Remove 'hot' list from shared_context The "hot" list stored in a shared_context was used to keep a reference to shared blocks that were currently being used and were thus removed from the available list (so that they don't get reused for another cache response). This 'hot' list does not ever need to be shared across threads since every one of them only works on their current row. The main need behind this 'hot' list was to detach the corresponding blocks from the 'avail' list and to have a known list root when calling list_for_each_entry_from in shctx_row_data_append (for instance). Since we actually never need to iterate over all members of the 'hot' list, we can remove it and replace the inc_hot/dec_hot logic by a detach/reattach one.
2023-11-16 11:38:19 -05:00
shctx_row_detach(ssl_shctx, first);
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
first->len = sizeof(struct sh_ssl_sess_hdr);
}
MINOR: shctx: Remove explicit 'from' param from shctx_row_data_append This parameter is not necessary since the first element of a row always has a pointer to the row's tail.
2023-11-16 11:38:14 -05:00
if (shctx_row_data_append(ssl_shctx, first, data, data_len) < 0) {
MEDIUM: shctx: Remove 'hot' list from shared_context The "hot" list stored in a shared_context was used to keep a reference to shared blocks that were currently being used and were thus removed from the available list (so that they don't get reused for another cache response). This 'hot' list does not ever need to be shared across threads since every one of them only works on their current row. The main need behind this 'hot' list was to detach the corresponding blocks from the 'avail' list and to have a known list root when calling list_for_each_entry_from in shctx_row_data_append (for instance). Since we actually never need to iterate over all members of the 'hot' list, we can remove it and replace the inc_hot/dec_hot logic by a detach/reattach one.
2023-11-16 11:38:19 -05:00
shctx_row_reattach(ssl_shctx, first);
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
return 0;
BUG/MEDIUM: ssl: cache doesn't release shctx blocks Since the rework of the shctx with the hot list system, the ssl cache was putting session inside the hot list, without removing them. Once all block were used, they were all locked in the hot list, which was forbiding to reuse them for new sessions. Bug introduced by 4f45bb9 ("MEDIUM: shctx: separate ssl and shctx") Thanks to Jeffrey J. Persch for reporting this bug. Must be backported to 1.8.
2018-01-03 13:15:51 -05:00
}
MEDIUM: shctx: Remove 'hot' list from shared_context The "hot" list stored in a shared_context was used to keep a reference to shared blocks that were currently being used and were thus removed from the available list (so that they don't get reused for another cache response). This 'hot' list does not ever need to be shared across threads since every one of them only works on their current row. The main need behind this 'hot' list was to detach the corresponding blocks from the 'avail' list and to have a known list root when calling list_for_each_entry_from in shctx_row_data_append (for instance). Since we actually never need to iterate over all members of the 'hot' list, we can remove it and replace the inc_hot/dec_hot logic by a detach/reattach one.
2023-11-16 11:38:19 -05:00
shctx_row_reattach(ssl_shctx, first);
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
MEDIUM: shctx: Descend shctx_lock calls into the shctx_row_reserve_hot Descend the shctx_lock calls into the shctx_row_reserve_hot so that the cases when we don't need to lock anything (enough space in the current row or not enough space in the 'avail' list) do not take the lock at all. In sh_ssl_sess_new_cb the lock had to be descended into sh_ssl_sess_store in order not to cover the shctx_row_reserve_hot call anymore.
2023-11-16 11:38:23 -05:00
shctx_wrunlock(ssl_shctx);
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
return 1;
}
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
MINOR: ssl: Handle session resumption with TLS 1.3 With TLS 1.3, session aren't established until after the main handshake has completed. So we can't just rely on calling SSL_get1_session(). Instead, we now register a callback for the "new session" event. This should work for previous versions of TLS as well.
2017-11-03 08:43:35 -04:00
/* SSL callback used when a new session is created while connecting to a server */
static int ssl_sess_new_srv_cb(SSL *ssl, SSL_SESSION *sess)
{
BUG/MAJOR: ssl: OpenSSL context is stored in non-reserved memory slot We never saw unexplicated crash with SSL, so I suppose that we are luck, or the slot 0 is always reserved. Anyway the usage of the macro SSL_get_app_data() and SSL_set_app_data() seem wrong. This patch change the deprecated functions SSL_get_app_data() and SSL_set_app_data() by the new functions SSL_get_ex_data() and SSL_set_ex_data(), and it reserves the slot in the SSL memory space. For information, this is the two declaration which seems wrong or incomplete in the OpenSSL ssl.h file. We can see the usage of the slot 0 whoch is hardcoded, but never reserved. #define SSL_set_app_data(s,arg) (SSL_set_ex_data(s,0,(char *)arg)) #define SSL_get_app_data(s) (SSL_get_ex_data(s,0)) This patch must be backported at least in 1.8, maybe in other versions.
2018-06-17 15:37:05 -04:00
struct connection *conn = SSL_get_ex_data(ssl, ssl_app_data_index);
MINOR: SSL: Store the ASN1 representation of client sessions. Instead of storing the SSL_SESSION pointer directly in the struct server, store the ASN1 representation, otherwise, session resumption is broken with TLS 1.3, when multiple outgoing connections want to use the same session.
2017-11-16 11:42:52 -05:00
struct server *s;
MINOR: server/ssl: maintain an index of the last known valid SSL session When a thread creates a new session for a server, if none was known yet, we assign the thread id (hence the reused_sess index) to a shared variable so that other threads will later be able to find it when they don't have one yet. For now we only set and clear the pointer upon session creation, we do not yet pick it. Note that we could have done it per thread-group, so as to avoid any cross-thread exchanges, but it's anticipated that this is essentially used during startup, at a moment where the cost of inter-thread contention is very low compared to the ability to restart at full speed, which explains why instead we store a single entry.
2023-08-21 05:55:42 -04:00
uint old_tid;
MINOR: ssl: Handle session resumption with TLS 1.3 With TLS 1.3, session aren't established until after the main handshake has completed. So we can't just rely on calling SSL_get1_session(). Instead, we now register a callback for the "new session" event. This should work for previous versions of TLS as well.
2017-11-03 08:43:35 -04:00
BUILD: ssl_sock: remove build warnings on potential null-derefs When building with -Wnull-dereferences, gcc sees some cases where a pointer is dereferenced after a check may set it to null. While all of these are already guarded by either a preliminary test or the code's construction (eg: listeners code being called only on listeners), it cannot be blamed for not "seeing" this, so better use the unguarded calls everywhere this happens, particularly after checks. This is a step towards building with -Wextra.
2018-09-20 04:57:52 -04:00
s = __objt_server(conn->target);
MINOR: ssl: Handle session resumption with TLS 1.3 With TLS 1.3, session aren't established until after the main handshake has completed. So we can't just rely on calling SSL_get1_session(). Instead, we now register a callback for the "new session" event. This should work for previous versions of TLS as well.
2017-11-03 08:43:35 -04:00
MEDIUM: ssl: add a rwlock for SSL server session cache When adding the server side support for certificate update over the CLI we encountered a design problem with the SSL session cache which was not locked. Indeed, once a certificate is updated we need to flush the cache, but we also need to ensure that the cache is not used during the update. To prevent the use of the cache during an update, this patch introduce a rwlock for the SSL server session cache. In the SSL session part this patch only lock in read, even if it writes. The reason behind this, is that in the session part, there is one cache storage per thread so it is not a problem to write in the cache from several threads. The problem is only when trying to write in the cache from the CLI (which could be on any thread) when a session is trying to access the cache. So there is a write lock in the CLI part to prevent simultaneous access by a session and the CLI. This patch also remove the thread_isolate attempt which is eating too much CPU time and was not protecting from the use of a free ptr in the session.
2021-02-08 04:43:44 -05:00
/* RWLOCK: only read lock the SSL cache even when writing in it because there is
* one cache per thread, it only prevents to flush it from the CLI in
MEDIUM: server/ssl: place an rwlock in the per-thread ssl server session The goal will be to permit a thread to update its session while having it shared with other threads. For now we only place the lock and arrange the code around it so that this is quite light. For now only the owner thread uses this lock so there is no contention. Note that there is a subtlety in the openssl API regarding i2s_SSL_SESSION() in that it fills the area pointed to by its argument with a dump of the session and returns a size that's equal to the previously allocated one. As such, it does modify the shared area even if that's not obvious at first glance.
2023-08-21 02:41:49 -04:00
* another thread. However, we also write-lock our session element while
* updating it to make sure no other thread is reading it while we're copying
* or releasing it.
*/
MEDIUM: ssl: add a rwlock for SSL server session cache When adding the server side support for certificate update over the CLI we encountered a design problem with the SSL session cache which was not locked. Indeed, once a certificate is updated we need to flush the cache, but we also need to ensure that the cache is not used during the update. To prevent the use of the cache during an update, this patch introduce a rwlock for the SSL server session cache. In the SSL session part this patch only lock in read, even if it writes. The reason behind this, is that in the session part, there is one cache storage per thread so it is not a problem to write in the cache from several threads. The problem is only when trying to write in the cache from the CLI (which could be on any thread) when a session is trying to access the cache. So there is a write lock in the CLI part to prevent simultaneous access by a session and the CLI. This patch also remove the thread_isolate attempt which is eating too much CPU time and was not protecting from the use of a free ptr in the session.
2021-02-08 04:43:44 -05:00
MINOR: SSL: Store the ASN1 representation of client sessions. Instead of storing the SSL_SESSION pointer directly in the struct server, store the ASN1 representation, otherwise, session resumption is broken with TLS 1.3, when multiple outgoing connections want to use the same session.
2017-11-16 11:42:52 -05:00
if (!(s->ssl_ctx.options & SRV_SSL_O_NO_REUSE)) {
int len;
unsigned char *ptr;
BUG/MEDIUM: ssl: backend TLS resumption with sni and TLSv1.3 When establishing an outboud connection, haproxy checks if the cached TLS session has the same SNI as the connection we are trying to resume. This test was done by calling SSL_get_servername() which in TLSv1.2 returned the SNI. With TLSv1.3 this is not the case anymore and this function returns NULL, which invalidates any outboud connection we are trying to resume if it uses the sni keyword on its server line. This patch fixes the problem by storing the SNI in the "reused_sess" structure beside the session itself. The ssl_sock_set_servername() now has a RWLOCK because this session cache entry could be accessed by the CLI when trying to update a certificate on the backend. This fix must be backported in every maintained version, however the RWLOCK only exists since version 2.4.
2021-11-16 20:59:21 -05:00
const char *sni;
MINOR: ssl: Handle session resumption with TLS 1.3 With TLS 1.3, session aren't established until after the main handshake has completed. So we can't just rely on calling SSL_get1_session(). Instead, we now register a callback for the "new session" event. This should work for previous versions of TLS as well.
2017-11-03 08:43:35 -04:00
DOC: ssl: add some comments about the non-obvious session allocation stuff The SSL session allocation/reuse part is far from being trivial, and there are some necessary tricks such as allocating then immediately freeing that are required by the API due to internal refcount. All of this is particularly hard to grasp, even with the scarce man pages. Let's document a little bit what's granted and expected along this path to help the reader later.
2023-08-21 05:17:10 -04:00
/* determine the required len to store this new session */
MINOR: SSL: Store the ASN1 representation of client sessions. Instead of storing the SSL_SESSION pointer directly in the struct server, store the ASN1 representation, otherwise, session resumption is broken with TLS 1.3, when multiple outgoing connections want to use the same session.
2017-11-16 11:42:52 -05:00
len = i2d_SSL_SESSION(sess, NULL);
BUG/MEDIUM: ssl: backend TLS resumption with sni and TLSv1.3 When establishing an outboud connection, haproxy checks if the cached TLS session has the same SNI as the connection we are trying to resume. This test was done by calling SSL_get_servername() which in TLSv1.2 returned the SNI. With TLSv1.3 this is not the case anymore and this function returns NULL, which invalidates any outboud connection we are trying to resume if it uses the sni keyword on its server line. This patch fixes the problem by storing the SNI in the "reused_sess" structure beside the session itself. The ssl_sock_set_servername() now has a RWLOCK because this session cache entry could be accessed by the CLI when trying to update a certificate on the backend. This fix must be backported in every maintained version, however the RWLOCK only exists since version 2.4.
2021-11-16 20:59:21 -05:00
sni = SSL_get_servername(ssl, TLSEXT_NAMETYPE_host_name);
MEDIUM: ssl: add a rwlock for SSL server session cache When adding the server side support for certificate update over the CLI we encountered a design problem with the SSL session cache which was not locked. Indeed, once a certificate is updated we need to flush the cache, but we also need to ensure that the cache is not used during the update. To prevent the use of the cache during an update, this patch introduce a rwlock for the SSL server session cache. In the SSL session part this patch only lock in read, even if it writes. The reason behind this, is that in the session part, there is one cache storage per thread so it is not a problem to write in the cache from several threads. The problem is only when trying to write in the cache from the CLI (which could be on any thread) when a session is trying to access the cache. So there is a write lock in the CLI part to prevent simultaneous access by a session and the CLI. This patch also remove the thread_isolate attempt which is eating too much CPU time and was not protecting from the use of a free ptr in the session.
2021-02-08 04:43:44 -05:00
HA_RWLOCK_RDLOCK(SSL_SERVER_LOCK, &s->ssl_ctx.lock);
MEDIUM: server/ssl: place an rwlock in the per-thread ssl server session The goal will be to permit a thread to update its session while having it shared with other threads. For now we only place the lock and arrange the code around it so that this is quite light. For now only the owner thread uses this lock so there is no contention. Note that there is a subtlety in the openssl API regarding i2s_SSL_SESSION() in that it fills the area pointed to by its argument with a dump of the session and returns a size that's equal to the previously allocated one. As such, it does modify the shared area even if that's not obvious at first glance.
2023-08-21 02:41:49 -04:00
ptr = s->ssl_ctx.reused_sess[tid].ptr;
/* we're updating the possibly shared session right now */
HA_RWLOCK_WRLOCK(SSL_SERVER_LOCK, &s->ssl_ctx.reused_sess[tid].sess_lock);
if (!ptr || s->ssl_ctx.reused_sess[tid].allocated_size < len) {
/* insufficient storage, reallocate */
MINOR: ssl_sock: avoid iterating realloc(+1) on stored context The SSL context storage in servers is per-thread, and the contents are allocated for a length that is determined from the session. It turns out that placing some traces there revealed that the realloc() that is called to grow the area can be called multiple times in a row even for just health checks, to grow the area by just one or two bytes. Given that malloc() allocates in multiples of 8 or 16 anyway, let's round the allocated size up to the nearest multiple of 8 to avoid this unneeded operation.
2023-08-21 02:12:12 -04:00
len = (len + 7) & -8; /* round to the nearest 8 bytes */
MEDIUM: server/ssl: place an rwlock in the per-thread ssl server session The goal will be to permit a thread to update its session while having it shared with other threads. For now we only place the lock and arrange the code around it so that this is quite light. For now only the owner thread uses this lock so there is no contention. Note that there is a subtlety in the openssl API regarding i2s_SSL_SESSION() in that it fills the area pointed to by its argument with a dump of the session and returns a size that's equal to the previously allocated one. As such, it does modify the shared area even if that's not obvious at first glance.
2023-08-21 02:41:49 -04:00
ptr = realloc(ptr, len);
BUG/MINOR: ssl_sock: fix possible memory leak on OOM That's the classical realloc() issue: if it returns NULL, the old area is not freed but we erase the pointer. It was brought by commit e18d4e828 ("BUG/MEDIUM: ssl: backend TLS resumption with sni and TLSv1.3"), and should be backported where this commit was backported.
2023-08-21 02:45:35 -04:00
if (!ptr)
free(s->ssl_ctx.reused_sess[tid].ptr);
CLEANUP: ssl: use realloc() instead of free()+malloc() There was a free(ptr) followed by ptr=malloc(ptr, len), which is the equivalent of ptr = realloc(ptr, len) but slower and less clean. Let's replace this.
2021-02-26 15:05:08 -05:00
s->ssl_ctx.reused_sess[tid].ptr = ptr;
MINOR: SSL: Store the ASN1 representation of client sessions. Instead of storing the SSL_SESSION pointer directly in the struct server, store the ASN1 representation, otherwise, session resumption is broken with TLS 1.3, when multiple outgoing connections want to use the same session.
2017-11-16 11:42:52 -05:00
s->ssl_ctx.reused_sess[tid].allocated_size = len;
}
DOC: ssl: add some comments about the non-obvious session allocation stuff The SSL session allocation/reuse part is far from being trivial, and there are some necessary tricks such as allocating then immediately freeing that are required by the API due to internal refcount. All of this is particularly hard to grasp, even with the scarce man pages. Let's document a little bit what's granted and expected along this path to help the reader later.
2023-08-21 05:17:10 -04:00
MEDIUM: server/ssl: place an rwlock in the per-thread ssl server session The goal will be to permit a thread to update its session while having it shared with other threads. For now we only place the lock and arrange the code around it so that this is quite light. For now only the owner thread uses this lock so there is no contention. Note that there is a subtlety in the openssl API regarding i2s_SSL_SESSION() in that it fills the area pointed to by its argument with a dump of the session and returns a size that's equal to the previously allocated one. As such, it does modify the shared area even if that's not obvious at first glance.
2023-08-21 02:41:49 -04:00
if (ptr) {
DOC: ssl: add some comments about the non-obvious session allocation stuff The SSL session allocation/reuse part is far from being trivial, and there are some necessary tricks such as allocating then immediately freeing that are required by the API due to internal refcount. All of this is particularly hard to grasp, even with the scarce man pages. Let's document a little bit what's granted and expected along this path to help the reader later.
2023-08-21 05:17:10 -04:00
/* store the new session into ptr and advance it; save the
* resulting size. It's guaranteed to be equal to the returned
* len above, and the pointer to be advanced by as much.
*/
s->ssl_ctx.reused_sess[tid].size = i2d_SSL_SESSION(sess, &ptr);
MINOR: SSL: Store the ASN1 representation of client sessions. Instead of storing the SSL_SESSION pointer directly in the struct server, store the ASN1 representation, otherwise, session resumption is broken with TLS 1.3, when multiple outgoing connections want to use the same session.
2017-11-16 11:42:52 -05:00
}
BUG/MEDIUM: ssl: backend TLS resumption with sni and TLSv1.3 When establishing an outboud connection, haproxy checks if the cached TLS session has the same SNI as the connection we are trying to resume. This test was done by calling SSL_get_servername() which in TLSv1.2 returned the SNI. With TLSv1.3 this is not the case anymore and this function returns NULL, which invalidates any outboud connection we are trying to resume if it uses the sni keyword on its server line. This patch fixes the problem by storing the SNI in the "reused_sess" structure beside the session itself. The ssl_sock_set_servername() now has a RWLOCK because this session cache entry could be accessed by the CLI when trying to update a certificate on the backend. This fix must be backported in every maintained version, however the RWLOCK only exists since version 2.4.
2021-11-16 20:59:21 -05:00
MEDIUM: server/ssl: place an rwlock in the per-thread ssl server session The goal will be to permit a thread to update its session while having it shared with other threads. For now we only place the lock and arrange the code around it so that this is quite light. For now only the owner thread uses this lock so there is no contention. Note that there is a subtlety in the openssl API regarding i2s_SSL_SESSION() in that it fills the area pointed to by its argument with a dump of the session and returns a size that's equal to the previously allocated one. As such, it does modify the shared area even if that's not obvious at first glance.
2023-08-21 02:41:49 -04:00
/* done updating the session */
MINOR: server/ssl: maintain an index of the last known valid SSL session When a thread creates a new session for a server, if none was known yet, we assign the thread id (hence the reused_sess index) to a shared variable so that other threads will later be able to find it when they don't have one yet. For now we only set and clear the pointer upon session creation, we do not yet pick it. Note that we could have done it per thread-group, so as to avoid any cross-thread exchanges, but it's anticipated that this is essentially used during startup, at a moment where the cost of inter-thread contention is very low compared to the ability to restart at full speed, which explains why instead we store a single entry.
2023-08-21 05:55:42 -04:00
/* Now we'll try to add or remove this entry as a valid one:
* - if no entry is set and we have one, let's share it
* - if our entry was set and we have no more, let's clear it
*/
old_tid = HA_ATOMIC_LOAD(&s->ssl_ctx.last_ssl_sess_tid); // 0=none, >0 = tid + 1
if (!s->ssl_ctx.reused_sess[tid].ptr && old_tid == tid + 1)
HA_ATOMIC_CAS(&s->ssl_ctx.last_ssl_sess_tid, &old_tid, 0); // no more valid
else if (s->ssl_ctx.reused_sess[tid].ptr && !old_tid)
HA_ATOMIC_CAS(&s->ssl_ctx.last_ssl_sess_tid, &old_tid, tid + 1);
BUG/MEDIUM: ssl: backend TLS resumption with sni and TLSv1.3 When establishing an outboud connection, haproxy checks if the cached TLS session has the same SNI as the connection we are trying to resume. This test was done by calling SSL_get_servername() which in TLSv1.2 returned the SNI. With TLSv1.3 this is not the case anymore and this function returns NULL, which invalidates any outboud connection we are trying to resume if it uses the sni keyword on its server line. This patch fixes the problem by storing the SNI in the "reused_sess" structure beside the session itself. The ssl_sock_set_servername() now has a RWLOCK because this session cache entry could be accessed by the CLI when trying to update a certificate on the backend. This fix must be backported in every maintained version, however the RWLOCK only exists since version 2.4.
2021-11-16 20:59:21 -05:00
if (s->ssl_ctx.reused_sess[tid].sni) {
/* if the new sni is empty or isn' t the same as the old one */
if ((!sni) || strcmp(s->ssl_ctx.reused_sess[tid].sni, sni) != 0) {
ha_free(&s->ssl_ctx.reused_sess[tid].sni);
if (sni)
s->ssl_ctx.reused_sess[tid].sni = strdup(sni);
}
} else if (sni) {
/* if there wasn't an old sni but there is a new one */
s->ssl_ctx.reused_sess[tid].sni = strdup(sni);
}
MEDIUM: server/ssl: place an rwlock in the per-thread ssl server session The goal will be to permit a thread to update its session while having it shared with other threads. For now we only place the lock and arrange the code around it so that this is quite light. For now only the owner thread uses this lock so there is no contention. Note that there is a subtlety in the openssl API regarding i2s_SSL_SESSION() in that it fills the area pointed to by its argument with a dump of the session and returns a size that's equal to the previously allocated one. As such, it does modify the shared area even if that's not obvious at first glance.
2023-08-21 02:41:49 -04:00
HA_RWLOCK_WRUNLOCK(SSL_SERVER_LOCK, &s->ssl_ctx.reused_sess[tid].sess_lock);
MEDIUM: ssl: add a rwlock for SSL server session cache When adding the server side support for certificate update over the CLI we encountered a design problem with the SSL session cache which was not locked. Indeed, once a certificate is updated we need to flush the cache, but we also need to ensure that the cache is not used during the update. To prevent the use of the cache during an update, this patch introduce a rwlock for the SSL server session cache. In the SSL session part this patch only lock in read, even if it writes. The reason behind this, is that in the session part, there is one cache storage per thread so it is not a problem to write in the cache from several threads. The problem is only when trying to write in the cache from the CLI (which could be on any thread) when a session is trying to access the cache. So there is a write lock in the CLI part to prevent simultaneous access by a session and the CLI. This patch also remove the thread_isolate attempt which is eating too much CPU time and was not protecting from the use of a free ptr in the session.
2021-02-08 04:43:44 -05:00
HA_RWLOCK_RDUNLOCK(SSL_SERVER_LOCK, &s->ssl_ctx.lock);
MINOR: SSL: Store the ASN1 representation of client sessions. Instead of storing the SSL_SESSION pointer directly in the struct server, store the ASN1 representation, otherwise, session resumption is broken with TLS 1.3, when multiple outgoing connections want to use the same session.
2017-11-16 11:42:52 -05:00
} else {
MEDIUM: ssl: add a rwlock for SSL server session cache When adding the server side support for certificate update over the CLI we encountered a design problem with the SSL session cache which was not locked. Indeed, once a certificate is updated we need to flush the cache, but we also need to ensure that the cache is not used during the update. To prevent the use of the cache during an update, this patch introduce a rwlock for the SSL server session cache. In the SSL session part this patch only lock in read, even if it writes. The reason behind this, is that in the session part, there is one cache storage per thread so it is not a problem to write in the cache from several threads. The problem is only when trying to write in the cache from the CLI (which could be on any thread) when a session is trying to access the cache. So there is a write lock in the CLI part to prevent simultaneous access by a session and the CLI. This patch also remove the thread_isolate attempt which is eating too much CPU time and was not protecting from the use of a free ptr in the session.
2021-02-08 04:43:44 -05:00
HA_RWLOCK_RDLOCK(SSL_SERVER_LOCK, &s->ssl_ctx.lock);
MEDIUM: server/ssl: place an rwlock in the per-thread ssl server session The goal will be to permit a thread to update its session while having it shared with other threads. For now we only place the lock and arrange the code around it so that this is quite light. For now only the owner thread uses this lock so there is no contention. Note that there is a subtlety in the openssl API regarding i2s_SSL_SESSION() in that it fills the area pointed to by its argument with a dump of the session and returns a size that's equal to the previously allocated one. As such, it does modify the shared area even if that's not obvious at first glance.
2023-08-21 02:41:49 -04:00
if (s->ssl_ctx.reused_sess[tid].ptr) {
HA_RWLOCK_WRLOCK(SSL_SERVER_LOCK, &s->ssl_ctx.reused_sess[tid].sess_lock);
ha_free(&s->ssl_ctx.reused_sess[tid].ptr);
HA_RWLOCK_WRUNLOCK(SSL_SERVER_LOCK, &s->ssl_ctx.reused_sess[tid].sess_lock);
}
MINOR: server/ssl: maintain an index of the last known valid SSL session When a thread creates a new session for a server, if none was known yet, we assign the thread id (hence the reused_sess index) to a shared variable so that other threads will later be able to find it when they don't have one yet. For now we only set and clear the pointer upon session creation, we do not yet pick it. Note that we could have done it per thread-group, so as to avoid any cross-thread exchanges, but it's anticipated that this is essentially used during startup, at a moment where the cost of inter-thread contention is very low compared to the ability to restart at full speed, which explains why instead we store a single entry.
2023-08-21 05:55:42 -04:00
old_tid = HA_ATOMIC_LOAD(&s->ssl_ctx.last_ssl_sess_tid); // 0=none, >0 = tid + 1
if (old_tid == tid + 1)
HA_ATOMIC_CAS(&s->ssl_ctx.last_ssl_sess_tid, &old_tid, 0); // no more valid
MEDIUM: ssl: add a rwlock for SSL server session cache When adding the server side support for certificate update over the CLI we encountered a design problem with the SSL session cache which was not locked. Indeed, once a certificate is updated we need to flush the cache, but we also need to ensure that the cache is not used during the update. To prevent the use of the cache during an update, this patch introduce a rwlock for the SSL server session cache. In the SSL session part this patch only lock in read, even if it writes. The reason behind this, is that in the session part, there is one cache storage per thread so it is not a problem to write in the cache from several threads. The problem is only when trying to write in the cache from the CLI (which could be on any thread) when a session is trying to access the cache. So there is a write lock in the CLI part to prevent simultaneous access by a session and the CLI. This patch also remove the thread_isolate attempt which is eating too much CPU time and was not protecting from the use of a free ptr in the session.
2021-02-08 04:43:44 -05:00
HA_RWLOCK_RDUNLOCK(SSL_SERVER_LOCK, &s->ssl_ctx.lock);
MINOR: SSL: Store the ASN1 representation of client sessions. Instead of storing the SSL_SESSION pointer directly in the struct server, store the ASN1 representation, otherwise, session resumption is broken with TLS 1.3, when multiple outgoing connections want to use the same session.
2017-11-16 11:42:52 -05:00
}
return 0;
MINOR: ssl: Handle session resumption with TLS 1.3 With TLS 1.3, session aren't established until after the main handshake has completed. So we can't just rely on calling SSL_get1_session(). Instead, we now register a callback for the "new session" event. This should work for previous versions of TLS as well.
2017-11-03 08:43:35 -04:00
}
MINOR: SSL: Store the ASN1 representation of client sessions. Instead of storing the SSL_SESSION pointer directly in the struct server, store the ASN1 representation, otherwise, session resumption is broken with TLS 1.3, when multiple outgoing connections want to use the same session.
2017-11-16 11:42:52 -05:00
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
/* SSL callback used on new session creation */
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
int sh_ssl_sess_new_cb(SSL *ssl, SSL_SESSION *sess)
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
{
unsigned char encsess[SHSESS_MAX_DATA_LEN]; /* encoded session */
unsigned char encid[SSL_MAX_SSL_SESSION_ID_LENGTH]; /* encoded id */
unsigned char *p;
int data_len;
BUG/MINOR: ssl: fix memcpy overlap without consequences. A trick is used to set SESSION_ID, and SESSION_ID_CONTEXT lengths to 0 and avoid ASN1 encoding of these values. There is no specific function to set the length of those parameters to 0 so we fake this calling these function to a different value with the same buffer but a length to zero. But those functions don't seem to check the length of zero before performing a memcpy of length zero but with src and dst buf on the same pointer, causing valgrind to bark. So the code was re-work to pass them different pointers even if buffer content is un-used. In a second time, reseting value, a memcpy overlap happened on the SESSION_ID_CONTEXT. It was re-worked and this is now reset using the constant global value SHCTX_APPNAME which is a different pointer with the same content. This patch should be backported in every version since ssl support was added to haproxy if we want valgrind to shut up. This is tracked in github issue #56.
2019-10-08 12:27:37 -04:00
unsigned int sid_length;
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
const unsigned char *sid_data;
/* Session id is already stored in to key and session id is known
CLEANUP: assorted typo fixes in the code and comments These are mostly comments in the code. A few error messages were fixed and are of low enough importance not to deserve a backport. Some regtests were also fixed.
2020-03-10 03:06:11 -04:00
* so we don't store it to keep size.
BUG/MINOR: ssl: fix memcpy overlap without consequences. A trick is used to set SESSION_ID, and SESSION_ID_CONTEXT lengths to 0 and avoid ASN1 encoding of these values. There is no specific function to set the length of those parameters to 0 so we fake this calling these function to a different value with the same buffer but a length to zero. But those functions don't seem to check the length of zero before performing a memcpy of length zero but with src and dst buf on the same pointer, causing valgrind to bark. So the code was re-work to pass them different pointers even if buffer content is un-used. In a second time, reseting value, a memcpy overlap happened on the SESSION_ID_CONTEXT. It was re-worked and this is now reset using the constant global value SHCTX_APPNAME which is a different pointer with the same content. This patch should be backported in every version since ssl support was added to haproxy if we want valgrind to shut up. This is tracked in github issue #56.
2019-10-08 12:27:37 -04:00
* note: SSL_SESSION_set1_id is using
* a memcpy so we need to use a different pointer
* than sid_data or sid_ctx_data to avoid valgrind
* complaining.
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
*/
sid_data = SSL_SESSION_get_id(sess, &sid_length);
BUG/MINOR: ssl: fix memcpy overlap without consequences. A trick is used to set SESSION_ID, and SESSION_ID_CONTEXT lengths to 0 and avoid ASN1 encoding of these values. There is no specific function to set the length of those parameters to 0 so we fake this calling these function to a different value with the same buffer but a length to zero. But those functions don't seem to check the length of zero before performing a memcpy of length zero but with src and dst buf on the same pointer, causing valgrind to bark. So the code was re-work to pass them different pointers even if buffer content is un-used. In a second time, reseting value, a memcpy overlap happened on the SESSION_ID_CONTEXT. It was re-worked and this is now reset using the constant global value SHCTX_APPNAME which is a different pointer with the same content. This patch should be backported in every version since ssl support was added to haproxy if we want valgrind to shut up. This is tracked in github issue #56.
2019-10-08 12:27:37 -04:00
/* copy value in an other buffer */
memcpy(encid, sid_data, sid_length);
/* pad with 0 */
if (sid_length < SSL_MAX_SSL_SESSION_ID_LENGTH)
memset(encid + sid_length, 0, SSL_MAX_SSL_SESSION_ID_LENGTH-sid_length);
/* force length to zero to avoid ASN1 encoding */
SSL_SESSION_set1_id(sess, encid, 0);
/* force length to zero to avoid ASN1 encoding */
SSL_SESSION_set1_id_context(sess, (const unsigned char *)SHCTX_APPNAME, 0);
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
/* check if buffer is large enough for the ASN1 encoded session */
data_len = i2d_SSL_SESSION(sess, NULL);
if (data_len > SHSESS_MAX_DATA_LEN)
goto err;
p = encsess;
/* process ASN1 session encoding before the lock */
i2d_SSL_SESSION(sess, &p);
/* store to cache */
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
sh_ssl_sess_store(encid, encsess, data_len);
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
err:
/* reset original length values */
BUG/MINOR: ssl: fix memcpy overlap without consequences. A trick is used to set SESSION_ID, and SESSION_ID_CONTEXT lengths to 0 and avoid ASN1 encoding of these values. There is no specific function to set the length of those parameters to 0 so we fake this calling these function to a different value with the same buffer but a length to zero. But those functions don't seem to check the length of zero before performing a memcpy of length zero but with src and dst buf on the same pointer, causing valgrind to bark. So the code was re-work to pass them different pointers even if buffer content is un-used. In a second time, reseting value, a memcpy overlap happened on the SESSION_ID_CONTEXT. It was re-worked and this is now reset using the constant global value SHCTX_APPNAME which is a different pointer with the same content. This patch should be backported in every version since ssl support was added to haproxy if we want valgrind to shut up. This is tracked in github issue #56.
2019-10-08 12:27:37 -04:00
SSL_SESSION_set1_id(sess, encid, sid_length);
SSL_SESSION_set1_id_context(sess, (const unsigned char *)SHCTX_APPNAME, strlen(SHCTX_APPNAME));
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
return 0; /* do not increment session reference count */
}
/* SSL callback used on lookup an existing session cause none found in internal cache */
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
SSL_SESSION *sh_ssl_sess_get_cb(SSL *ssl, __OPENSSL_110_CONST__ unsigned char *key, int key_len, int *do_copy)
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
{
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
struct sh_ssl_sess_hdr *sh_ssl_sess;
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
unsigned char data[SHSESS_MAX_DATA_LEN], *p;
unsigned char tmpkey[SSL_MAX_SSL_SESSION_ID_LENGTH];
SSL_SESSION *sess;
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
struct shared_block *first;
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
BUG/MINOR: ssl: use atomic ops to update global shctx stats The global shctx lookups and misses was updated without using atomic ops, so the stats available in "show info" are very likely off by a few units over time. This should be backported as far as 1.8. Versions without _HA_ATOMIC_INC() can use HA_ATOMIC_ADD(,1).
2021-06-15 10:39:22 -04:00
_HA_ATOMIC_INC(&global.shctx_lookups);
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
/* allow the session to be freed automatically by openssl */
*do_copy = 0;
/* tree key is zeros padded sessionid */
if (key_len < SSL_MAX_SSL_SESSION_ID_LENGTH) {
memcpy(tmpkey, key, key_len);
memset(tmpkey + key_len, 0, SSL_MAX_SSL_SESSION_ID_LENGTH - key_len);
key = tmpkey;
}
/* lock cache */
MEDIUM: cache: Switch shctx spinlock to rwlock and restrict its scope Since a lock on the cache tree was added in the latest cache changes, we do not need to use the shared_context's lock to lock more than pure shared_context related data anymore. This already existing lock will now only cover the 'avail' list from the shared_context. It can then be changed to a rwlock instead of a spinlock because we might want to only run through the avail list sometimes. Apart form changing the type of the shctx lock, the main modification introduced by this patch is to limit the amount of code covered by the shctx lock. This lock does not need to cover any code strictly related to the cache tree anymore.
2023-11-16 11:38:21 -05:00
shctx_wrlock(ssl_shctx);
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
/* lookup for session */
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
sh_ssl_sess = sh_ssl_sess_tree_lookup(key);
if (!sh_ssl_sess) {
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
/* no session found: unlock cache and exit */
MEDIUM: cache: Switch shctx spinlock to rwlock and restrict its scope Since a lock on the cache tree was added in the latest cache changes, we do not need to use the shared_context's lock to lock more than pure shared_context related data anymore. This already existing lock will now only cover the 'avail' list from the shared_context. It can then be changed to a rwlock instead of a spinlock because we might want to only run through the avail list sometimes. Apart form changing the type of the shctx lock, the main modification introduced by this patch is to limit the amount of code covered by the shctx lock. This lock does not need to cover any code strictly related to the cache tree anymore.
2023-11-16 11:38:21 -05:00
shctx_wrunlock(ssl_shctx);
BUG/MINOR: ssl: use atomic ops to update global shctx stats The global shctx lookups and misses was updated without using atomic ops, so the stats available in "show info" are very likely off by a few units over time. This should be backported as far as 1.8. Versions without _HA_ATOMIC_INC() can use HA_ATOMIC_ADD(,1).
2021-06-15 10:39:22 -04:00
_HA_ATOMIC_INC(&global.shctx_misses);
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
return NULL;
}
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
/* sh_ssl_sess (shared_block->data) is at the end of shared_block */
first = sh_ssl_sess_first_block(sh_ssl_sess);
shctx_row_data_get(ssl_shctx, first, data, sizeof(struct sh_ssl_sess_hdr), first->len-sizeof(struct sh_ssl_sess_hdr));
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
MEDIUM: cache: Switch shctx spinlock to rwlock and restrict its scope Since a lock on the cache tree was added in the latest cache changes, we do not need to use the shared_context's lock to lock more than pure shared_context related data anymore. This already existing lock will now only cover the 'avail' list from the shared_context. It can then be changed to a rwlock instead of a spinlock because we might want to only run through the avail list sometimes. Apart form changing the type of the shctx lock, the main modification introduced by this patch is to limit the amount of code covered by the shctx lock. This lock does not need to cover any code strictly related to the cache tree anymore.
2023-11-16 11:38:21 -05:00
shctx_wrunlock(ssl_shctx);
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
/* decode ASN1 session */
p = data;
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
sess = d2i_SSL_SESSION(NULL, (const unsigned char **)&p, first->len-sizeof(struct sh_ssl_sess_hdr));
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
/* Reset session id and session id contenxt */
if (sess) {
SSL_SESSION_set1_id(sess, key, key_len);
SSL_SESSION_set1_id_context(sess, (const unsigned char *)SHCTX_APPNAME, strlen(SHCTX_APPNAME));
}
return sess;
}
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
/* SSL callback used to signal session is no more used in internal cache */
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
void sh_ssl_sess_remove_cb(SSL_CTX *ctx, SSL_SESSION *sess)
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
{
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
struct sh_ssl_sess_hdr *sh_ssl_sess;
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
unsigned char tmpkey[SSL_MAX_SSL_SESSION_ID_LENGTH];
unsigned int sid_length;
const unsigned char *sid_data;
(void)ctx;
sid_data = SSL_SESSION_get_id(sess, &sid_length);
/* tree key is zeros padded sessionid */
if (sid_length < SSL_MAX_SSL_SESSION_ID_LENGTH) {
memcpy(tmpkey, sid_data, sid_length);
memset(tmpkey+sid_length, 0, SSL_MAX_SSL_SESSION_ID_LENGTH - sid_length);
sid_data = tmpkey;
}
MEDIUM: cache: Switch shctx spinlock to rwlock and restrict its scope Since a lock on the cache tree was added in the latest cache changes, we do not need to use the shared_context's lock to lock more than pure shared_context related data anymore. This already existing lock will now only cover the 'avail' list from the shared_context. It can then be changed to a rwlock instead of a spinlock because we might want to only run through the avail list sometimes. Apart form changing the type of the shctx lock, the main modification introduced by this patch is to limit the amount of code covered by the shctx lock. This lock does not need to cover any code strictly related to the cache tree anymore.
2023-11-16 11:38:21 -05:00
shctx_wrlock(ssl_shctx);
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
/* lookup for session */
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
sh_ssl_sess = sh_ssl_sess_tree_lookup(sid_data);
if (sh_ssl_sess) {
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
/* free session */
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
sh_ssl_sess_tree_delete(sh_ssl_sess);
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
}
/* unlock cache */
MEDIUM: cache: Switch shctx spinlock to rwlock and restrict its scope Since a lock on the cache tree was added in the latest cache changes, we do not need to use the shared_context's lock to lock more than pure shared_context related data anymore. This already existing lock will now only cover the 'avail' list from the shared_context. It can then be changed to a rwlock instead of a spinlock because we might want to only run through the avail list sometimes. Apart form changing the type of the shctx lock, the main modification introduced by this patch is to limit the amount of code covered by the shctx lock. This lock does not need to cover any code strictly related to the cache tree anymore.
2023-11-16 11:38:21 -05:00
shctx_wrunlock(ssl_shctx);
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
}
/* Set session cache mode to server and disable openssl internal cache.
* Set shared cache callbacks on an ssl context.
* Shared context MUST be firstly initialized */
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
void ssl_set_shctx(SSL_CTX *ctx)
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
{
SSL_CTX_set_session_id_context(ctx, (const unsigned char *)SHCTX_APPNAME, strlen(SHCTX_APPNAME));
if (!ssl_shctx) {
SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_OFF);
return;
}
SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_SERVER |
SSL_SESS_CACHE_NO_INTERNAL |
SSL_SESS_CACHE_NO_AUTO_CLEAR);
/* Set callbacks */
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
SSL_CTX_sess_set_new_cb(ctx, sh_ssl_sess_new_cb);
SSL_CTX_sess_set_get_cb(ctx, sh_ssl_sess_get_cb);
SSL_CTX_sess_set_remove_cb(ctx, sh_ssl_sess_remove_cb);
REORG: shctx: move ssl functions to ssl_sock.c Move the ssl callback functions of the ssl shared session cache to ssl_sock.c. The shctx functions still needs to be separated of the ssl tree and data.
2017-10-30 14:36:36 -04:00
}
WIP/MINOR: ssl: add sample fetches for keylog in frontend OpenSSL 1.1.1 provides a callback registering function SSL_CTX_set_keylog_callback, which allows one to receive a string containing the keys to deciphers TLSv1.3. Unfortunately it is not possible to store this data in binary form and we can only get this information using the callback. Which means that we need to store it until the connection is closed. This patches add 2 pools, the first one, pool_head_ssl_keylog is used to store a struct ssl_keylog which will be inserted as a ex_data in a SSL *. The second one is pool_head_ssl_keylog_str which will be used to store the hexadecimal strings. To enable the capture of the keys, you need to set "tune.ssl.keylog on" in your configuration. The following fetches were implemented: ssl_fc_client_early_traffic_secret, ssl_fc_client_handshake_traffic_secret, ssl_fc_server_handshake_traffic_secret, ssl_fc_client_traffic_secret_0, ssl_fc_server_traffic_secret_0, ssl_fc_exporter_secret, ssl_fc_early_exporter_secret
2020-07-06 05:41:30 -04:00
/*
* https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format
*
* The format is:
* * <Label> <space> <ClientRandom> <space> <Secret>
* We only need to copy the secret as there is a sample fetch for the ClientRandom
*/
BUILD: make tune.ssl.keylog available again Since commit 04a5a44 ("BUILD: ssl: use HAVE_OPENSSL_KEYLOG instead of OpenSSL versions") the "tune.ssl.keylog" feature is broken because HAVE_OPENSSL_KEYLOG does not exist. Replace this by a HAVE_SSL_KEYLOG which is defined in openssl-compat.h. Also add an error when not built with the right openssl version. Must be backported as far as 2.3.
2021-06-09 10:46:12 -04:00
#ifdef HAVE_SSL_KEYLOG
WIP/MINOR: ssl: add sample fetches for keylog in frontend OpenSSL 1.1.1 provides a callback registering function SSL_CTX_set_keylog_callback, which allows one to receive a string containing the keys to deciphers TLSv1.3. Unfortunately it is not possible to store this data in binary form and we can only get this information using the callback. Which means that we need to store it until the connection is closed. This patches add 2 pools, the first one, pool_head_ssl_keylog is used to store a struct ssl_keylog which will be inserted as a ex_data in a SSL *. The second one is pool_head_ssl_keylog_str which will be used to store the hexadecimal strings. To enable the capture of the keys, you need to set "tune.ssl.keylog on" in your configuration. The following fetches were implemented: ssl_fc_client_early_traffic_secret, ssl_fc_client_handshake_traffic_secret, ssl_fc_server_handshake_traffic_secret, ssl_fc_client_traffic_secret_0, ssl_fc_server_traffic_secret_0, ssl_fc_exporter_secret, ssl_fc_early_exporter_secret
2020-07-06 05:41:30 -04:00
void SSL_CTX_keylog(const SSL *ssl, const char *line)
{
struct ssl_keylog *keylog;
char *lastarg = NULL;
char *dst = NULL;
MINOR: quic: Call the keylog callback for QUIC openssl wrapper from SSL_CTX_keylog() SSL_CTX_keylog() is the callback used when the TLS keylog feature is enabled with tune.ssl.keylog configuration setting. But the QUIC openssl wrapper also needs to use such a callback to receive the QUIC TLS secrets from the TLS stack. Add a call to the keylog callback for the QUIC openssl wrapper to SSL_CTX_keylog() to ensure that it will be called when the TLS keylog feature is enabled.
2023-06-07 05:25:35 -04:00
#ifdef USE_QUIC_OPENSSL_COMPAT
quic_tls_compat_keylog_callback(ssl, line);
#endif
WIP/MINOR: ssl: add sample fetches for keylog in frontend OpenSSL 1.1.1 provides a callback registering function SSL_CTX_set_keylog_callback, which allows one to receive a string containing the keys to deciphers TLSv1.3. Unfortunately it is not possible to store this data in binary form and we can only get this information using the callback. Which means that we need to store it until the connection is closed. This patches add 2 pools, the first one, pool_head_ssl_keylog is used to store a struct ssl_keylog which will be inserted as a ex_data in a SSL *. The second one is pool_head_ssl_keylog_str which will be used to store the hexadecimal strings. To enable the capture of the keys, you need to set "tune.ssl.keylog on" in your configuration. The following fetches were implemented: ssl_fc_client_early_traffic_secret, ssl_fc_client_handshake_traffic_secret, ssl_fc_server_handshake_traffic_secret, ssl_fc_client_traffic_secret_0, ssl_fc_server_traffic_secret_0, ssl_fc_exporter_secret, ssl_fc_early_exporter_secret
2020-07-06 05:41:30 -04:00
keylog = SSL_get_ex_data(ssl, ssl_keylog_index);
if (!keylog)
return;
lastarg = strrchr(line, ' ');
if (lastarg == NULL || ++lastarg == NULL)
return;
dst = pool_alloc(pool_head_ssl_keylog_str);
if (!dst)
return;
strncpy(dst, lastarg, SSL_KEYLOG_MAX_SECRET_SIZE-1);
dst[SSL_KEYLOG_MAX_SECRET_SIZE-1] = '\0';
if (strncmp(line, "CLIENT_RANDOM ", strlen("CLIENT RANDOM ")) == 0) {
if (keylog->client_random)
goto error;
keylog->client_random = dst;
} else if (strncmp(line, "CLIENT_EARLY_TRAFFIC_SECRET ", strlen("CLIENT_EARLY_TRAFFIC_SECRET ")) == 0) {
if (keylog->client_early_traffic_secret)
goto error;
keylog->client_early_traffic_secret = dst;
} else if (strncmp(line, "CLIENT_HANDSHAKE_TRAFFIC_SECRET ", strlen("CLIENT_HANDSHAKE_TRAFFIC_SECRET ")) == 0) {
if(keylog->client_handshake_traffic_secret)
goto error;
keylog->client_handshake_traffic_secret = dst;
} else if (strncmp(line, "SERVER_HANDSHAKE_TRAFFIC_SECRET ", strlen("SERVER_HANDSHAKE_TRAFFIC_SECRET ")) == 0) {
if (keylog->server_handshake_traffic_secret)
goto error;
keylog->server_handshake_traffic_secret = dst;
} else if (strncmp(line, "CLIENT_TRAFFIC_SECRET_0 ", strlen("CLIENT_TRAFFIC_SECRET_0 ")) == 0) {
if (keylog->client_traffic_secret_0)
goto error;
keylog->client_traffic_secret_0 = dst;
} else if (strncmp(line, "SERVER_TRAFFIC_SECRET_0 ", strlen("SERVER_TRAFFIC_SECRET_0 ")) == 0) {
if (keylog->server_traffic_secret_0)
goto error;
keylog->server_traffic_secret_0 = dst;
} else if (strncmp(line, "EARLY_EXPORTER_SECRET ", strlen("EARLY_EXPORTER_SECRET ")) == 0) {
if (keylog->early_exporter_secret)
goto error;
keylog->early_exporter_secret = dst;
} else if (strncmp(line, "EXPORTER_SECRET ", strlen("EXPORTER_SECRET ")) == 0) {
if (keylog->exporter_secret)
goto error;
keylog->exporter_secret = dst;
} else {
goto error;
}
return;
error:
pool_free(pool_head_ssl_keylog_str, dst);
return;
}
#endif
MINOR: ssl: ssl_sock_prepare_ctx() return an error code Rework ssl_sock_prepare_ctx() so it fills a buffer with the error messages instead of using ha_alert()/ha_warning(). Also returns an error code (ERR_*) instead of the number of errors.
2019-11-21 09:48:10 -05:00
/*
* This function applies the SSL configuration on a SSL_CTX
* It returns an error code and fills the <err> buffer
*/
MEDIUM: ssl: Chain ckch instances in ca-file entries Each ca-file entry of the tree will now hold a list of the ckch instances that use it so that we can iterate over them when updating the ca-file via a cli command. Since the link between the SSL contexts and the CA file tree entries is only built during the ssl_sock_prepare_ctx function, which are called after all the ckch instances are created, we need to add a little post processing after each ssl_sock_prepare_ctx that builds the link between the corresponding ckch instance and CA file tree entries. In order to manage the ca-file and ca-verify-file options, any ckch instance can be linked to multiple CA file tree entries and any CA file entry can link multiple ckch instances. This is done thanks to a dedicated list of ckch_inst references stored in the CA file tree entries over which we can iterate (during an update for instance). We avoid having one of those instances go stale by keeping a list of references to those references in the instances. When deleting a ckch_inst, we can then remove all the ckch_inst_link instances that reference it, and when deleting a cafile_entry, we iterate over the list of ckch_inst reference and clear the corresponding entry in their own list of ckch_inst_link references.
2021-02-19 11:41:55 -05:00
static int ssl_sock_prepare_ctx(struct bind_conf *bind_conf, struct ssl_bind_conf *ssl_conf, SSL_CTX *ctx, char **err)
MINOR: ssl: removes SSL_CTX_set_ssl_version call and cleanup CTX creation. BoringSSL doesn't support SSL_CTX_set_ssl_version. To remove this call, the CTX creation is cleanup to clarify what is happening. SSL_CTX_new is used to match the original behavior, in order: force-<method> according the method version then the default method with no-<method> options. OPENSSL_NO_SSL3 error message is now in force-sslv3 parsing (as force-tls*). For CTX creation in bind environement, all CTX set related to the initial ctx are aggregate to ssl_sock_new_ctx function for clarity. Tests with crt-list have shown that server_method, options and mode are linked to the initial CTX (default_ctx): all ssl-options are link to each bind line and must be removed from crt-list.
2017-03-03 06:21:32 -05:00
{
struct proxy *curproxy = bind_conf->frontend;
int cfgerr = 0;
int verify = SSL_VERIFY_NONE;
BUILD: ssl: silence a warning when building without NPN nor ALPN support When building with a library not offering any of these, ssl_conf_cur is not used. Can be backported to 1.8.
2018-01-04 12:55:19 -05:00
struct ssl_bind_conf __maybe_unused *ssl_conf_cur;
MAJOR: ssl: bind configuration per certificat crt-list is extend to support ssl configuration. You can now have such line in crt-list <file>: mycert.pem [npn h2,http/1.1] Support include "npn", "alpn", "verify", "ca_file", "crl_file", "ecdhe", "ciphers" configuration and ssl options. "crt-base" is also supported to fetch certificates.
2016-12-29 12:26:15 -05:00
const char *conf_ciphers;
BUILD: SSL: guard TLS13 ciphersuites with HAVE_SSL_CTX_SET_CIPHERSUITES HAVE_SSL_CTX_SET_CIPHERSUITES is newly defined macro set in openssl-compat.h, which helps to identify ssl libs (currently OpenSSL-1.1.1 only) that supports TLS13 cipersuites manipulation on TLS13 context
2020-11-21 04:37:34 -05:00
#ifdef HAVE_SSL_CTX_SET_CIPHERSUITES
MEDIUM: ssl: add support for ciphersuites option for TLSv1.3 OpenSSL released support for TLSv1.3. It also added a separate function SSL_CTX_set_ciphersuites that is used to set the ciphers used in the TLS 1.3 handshake. This change adds support for that new configuration option by adding a ciphersuites configuration variable that works essentially the same as the existing ciphers setting. Note that it should likely be backported to 1.8 in order to ease usage of the now released openssl-1.1.1.
2018-09-14 05:14:21 -04:00
const char *conf_ciphersuites;
#endif
MINOR: ssl: add curve suite for ECDHE negotiation Add 'curves' parameter on 'bind' and for 'crt-list' to set curve suite. (ex: curves X25519:P-256)
2017-01-09 10:15:54 -05:00
const char *conf_curves = NULL;
MINOR: ssl: disable CRL checks with WolfSSL when no CRL file WolfSSL is enabling by default the CRL checks even if a CRL file wasn't provided. This patch resets the default X509_STORE flags so this is not checked by default.
2023-05-02 12:26:46 -04:00
X509_STORE *store = SSL_CTX_get_cert_store(ctx);
MINOR: ssl: allow to change the server signature algorithm This patch introduces the "sigalgs" keyword for the bind line, which allows to configure the list of server signature algorithms negociated during the handshake. Also available as "ssl-default-bind-sigalgs" in the default section. This patch was originally written by Bruno Henc.
2023-05-04 09:33:55 -04:00
#if defined(SSL_CTX_set1_sigalgs_list)
const char *conf_sigalgs = NULL;
#endif
MINOR: ssl: allow to change the signature algorithm for client authentication This commit introduces the keyword "client-sigalgs" for the bind line, which does the same as "sigalgs" but for the client authentication. "ssl-default-bind-client-sigalgs" allows to set the default parameter for all the bind lines. This patch should fix issue #2081.
2023-05-04 18:05:46 -04:00
#if defined(SSL_CTX_set1_client_sigalgs_list)
const char *conf_client_sigalgs = NULL;
#endif
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
MINOR: ssl: support ssl-min-ver and ssl-max-ver with crt-list SSL/TLS version can be changed per certificat if and only if openssl lib support earlier callback on handshake and, of course, is implemented in haproxy. It's ok for BoringSSL. For Openssl, version 1.1.1 have such callback and could support it.
2017-05-18 06:46:50 -04:00
if (ssl_conf) {
struct tls_version_filter *conf_ssl_methods = &ssl_conf->ssl_methods;
int i, min, max;
int flags = MC_SSL_O_ALL;
/* Real min and max should be determinate with configuration and openssl's capabilities */
MINOR: ssl: remove duplicate ssl_methods in struct bind_conf Patch "MINOR: ssl: support ssl-min-ver and ssl-max-ver with crt-list" introduce ssl_methods in struct ssl_bind_conf. struct bind_conf have now ssl_methods and ssl_conf.ssl_methods (unused). It's error-prone. This patch remove the duplicate structure to avoid any confusion.
2017-08-09 12:26:20 -04:00
min = conf_ssl_methods->min ? conf_ssl_methods->min : bind_conf->ssl_conf.ssl_methods.min;
max = conf_ssl_methods->max ? conf_ssl_methods->max : bind_conf->ssl_conf.ssl_methods.max;
MINOR: ssl: support ssl-min-ver and ssl-max-ver with crt-list SSL/TLS version can be changed per certificat if and only if openssl lib support earlier callback on handshake and, of course, is implemented in haproxy. It's ok for BoringSSL. For Openssl, version 1.1.1 have such callback and could support it.
2017-05-18 06:46:50 -04:00
if (min)
flags |= (methodVersions[min].flag - 1);
if (max)
flags |= ~((methodVersions[max].flag << 1) - 1);
min = max = CONF_TLSV_NONE;
for (i = CONF_TLSV_MIN; i <= CONF_TLSV_MAX; i++)
if (methodVersions[i].option && !(flags & methodVersions[i].flag)) {
if (min)
max = i;
else
min = max = i;
}
/* save real min/max */
conf_ssl_methods->min = min;
conf_ssl_methods->max = max;
if (!min) {
CLEANUP: ssl: Clean up error handling This commit removes the explicit checks for `if (err)` before passing `err` to `memprintf`. `memprintf` already checks itself whether the `**out*` parameter is `NULL` before doing anything. This reduces the indentation depth and makes the code more readable, before there is less boilerplate code. Instead move the check into the ternary conditional when the error message should be appended to a previous message. This is consistent with the rest of ssl_sock.c and with the rest of HAProxy. Thus this patch is the arguably cleaner fix for issue #374 and builds upon 5f1fa7db86c53827c97f8a8c3f5fa75bfcb5be9a and 8b453912ce9a4e1a3b1329efb2af04d1e470852e Additionally it fixes a few places where the check *still* was missing.
2019-11-23 17:45:10 -05:00
memprintf(err, "%sProxy '%s': all SSL/TLS versions are disabled for bind '%s' at [%s:%d].\n",
err && *err ? *err : "", bind_conf->frontend->id, bind_conf->arg, bind_conf->file, bind_conf->line);
MINOR: ssl: ssl_sock_prepare_ctx() return an error code Rework ssl_sock_prepare_ctx() so it fills a buffer with the error messages instead of using ha_alert()/ha_warning(). Also returns an error code (ERR_*) instead of the number of errors.
2019-11-21 09:48:10 -05:00
cfgerr |= ERR_ALERT | ERR_FATAL;
MINOR: ssl: support ssl-min-ver and ssl-max-ver with crt-list SSL/TLS version can be changed per certificat if and only if openssl lib support earlier callback on handshake and, of course, is implemented in haproxy. It's ok for BoringSSL. For Openssl, version 1.1.1 have such callback and could support it.
2017-05-18 06:46:50 -04:00
}
}
MAJOR: ssl: bind configuration per certificat crt-list is extend to support ssl configuration. You can now have such line in crt-list <file>: mycert.pem [npn h2,http/1.1] Support include "npn", "alpn", "verify", "ca_file", "crl_file", "ecdhe", "ciphers" configuration and ssl options. "crt-base" is also supported to fetch certificates.
2016-12-29 12:26:15 -05:00
switch ((ssl_conf && ssl_conf->verify) ? ssl_conf->verify : bind_conf->ssl_conf.verify) {
MEDIUM: ssl: Set verify 'required' as global default for servers side. If no CA file specified on a server line, the config parser will show an error. Adds an cmdline option '-dV' to re-set verify 'none' as global default on servers side (previous behavior). Also adds 'ssl-server-verify' global statement to set global default to 'none' or 'required'. WARNING: this changes the default verify mode from "none" to "required" on the server side, and it *will* break insecure setups.
2014-01-29 06:24:34 -05:00
case SSL_SOCK_VERIFY_NONE:
verify = SSL_VERIFY_NONE;
break;
case SSL_SOCK_VERIFY_OPTIONAL:
verify = SSL_VERIFY_PEER;
break;
case SSL_SOCK_VERIFY_REQUIRED:
verify = SSL_VERIFY_PEER|SSL_VERIFY_FAIL_IF_NO_PEER_CERT;
break;
}
SSL_CTX_set_verify(ctx, verify, ssl_sock_bind_verifycbk);
if (verify & SSL_VERIFY_PEER) {
MAJOR: ssl: bind configuration per certificat crt-list is extend to support ssl configuration. You can now have such line in crt-list <file>: mycert.pem [npn h2,http/1.1] Support include "npn", "alpn", "verify", "ca_file", "crl_file", "ecdhe", "ciphers" configuration and ssl options. "crt-base" is also supported to fetch certificates.
2016-12-29 12:26:15 -05:00
char *ca_file = (ssl_conf && ssl_conf->ca_file) ? ssl_conf->ca_file : bind_conf->ssl_conf.ca_file;
MINOR: ssl: add "ca-verify-file" directive It's only available for bind line. "ca-verify-file" allows to separate CA certificates from "ca-file". CA names sent in server hello message is only compute from "ca-file". Typically, "ca-file" must be defined with intermediate certificates and "ca-verify-file" with certificates to ending the chain, like root CA. Fix issue #404.
2019-12-16 10:39:17 -05:00
char *ca_verify_file = (ssl_conf && ssl_conf->ca_verify_file) ? ssl_conf->ca_verify_file : bind_conf->ssl_conf.ca_verify_file;
MAJOR: ssl: bind configuration per certificat crt-list is extend to support ssl configuration. You can now have such line in crt-list <file>: mycert.pem [npn h2,http/1.1] Support include "npn", "alpn", "verify", "ca_file", "crl_file", "ecdhe", "ciphers" configuration and ssl options. "crt-base" is also supported to fetch certificates.
2016-12-29 12:26:15 -05:00
char *crl_file = (ssl_conf && ssl_conf->crl_file) ? ssl_conf->crl_file : bind_conf->ssl_conf.crl_file;
MINOR: ssl: add "ca-verify-file" directive It's only available for bind line. "ca-verify-file" allows to separate CA certificates from "ca-file". CA names sent in server hello message is only compute from "ca-file". Typically, "ca-file" must be defined with intermediate certificates and "ca-verify-file" with certificates to ending the chain, like root CA. Fix issue #404.
2019-12-16 10:39:17 -05:00
if (ca_file || ca_verify_file) {
MINOR: ssl: deduplicate ca-file Typically server line like: 'server-template srv 1-1000 *:443 ssl ca-file ca-certificates.crt' load ca-certificates.crt 1000 times and stay duplicated in memory. Same case for bind line: ca-file is loaded for each certificate. Same 'ca-file' can be load one time only and stay deduplicated in memory. As a corollary, this will prevent file access for ca-file when updating a certificate via CLI.
2019-10-24 05:32:47 -04:00
/* set CAfile to verify */
MINOR: ssl: add "ca-verify-file" directive It's only available for bind line. "ca-verify-file" allows to separate CA certificates from "ca-file". CA names sent in server hello message is only compute from "ca-file". Typically, "ca-file" must be defined with intermediate certificates and "ca-verify-file" with certificates to ending the chain, like root CA. Fix issue #404.
2019-12-16 10:39:17 -05:00
if (ca_file && !ssl_set_verify_locations_file(ctx, ca_file)) {
MINOR: ssl: deduplicate ca-file Typically server line like: 'server-template srv 1-1000 *:443 ssl ca-file ca-certificates.crt' load ca-certificates.crt 1000 times and stay duplicated in memory. Same case for bind line: ca-file is loaded for each certificate. Same 'ca-file' can be load one time only and stay deduplicated in memory. As a corollary, this will prevent file access for ca-file when updating a certificate via CLI.
2019-10-24 05:32:47 -04:00
memprintf(err, "%sProxy '%s': unable to set CA file '%s' for bind '%s' at [%s:%d].\n",
CLEANUP: ssl: Clean up error handling This commit removes the explicit checks for `if (err)` before passing `err` to `memprintf`. `memprintf` already checks itself whether the `**out*` parameter is `NULL` before doing anything. This reduces the indentation depth and makes the code more readable, before there is less boilerplate code. Instead move the check into the ternary conditional when the error message should be appended to a previous message. This is consistent with the rest of ssl_sock.c and with the rest of HAProxy. Thus this patch is the arguably cleaner fix for issue #374 and builds upon 5f1fa7db86c53827c97f8a8c3f5fa75bfcb5be9a and 8b453912ce9a4e1a3b1329efb2af04d1e470852e Additionally it fixes a few places where the check *still* was missing.
2019-11-23 17:45:10 -05:00
err && *err ? *err : "", curproxy->id, ca_file, bind_conf->arg, bind_conf->file, bind_conf->line);
MINOR: ssl: ssl_sock_prepare_ctx() return an error code Rework ssl_sock_prepare_ctx() so it fills a buffer with the error messages instead of using ha_alert()/ha_warning(). Also returns an error code (ERR_*) instead of the number of errors.
2019-11-21 09:48:10 -05:00
cfgerr |= ERR_ALERT | ERR_FATAL;
MEDIUM: ssl: add client certificate authentication support Add keyword 'verify' on bind: 'verify none': authentication disabled (default) 'verify optional': accept connection without certificate and process a verify if the client sent a certificate 'verify required': reject connection without certificate and process a verify if the client send a certificate Add keyword 'cafile' on bind: 'cafile <path>' path to a client CA file used to verify. 'crlfile <path>' path to a client CRL file used to verify.
2012-09-20 12:23:56 -04:00
}
MINOR: ssl: add "ca-verify-file" directive It's only available for bind line. "ca-verify-file" allows to separate CA certificates from "ca-file". CA names sent in server hello message is only compute from "ca-file". Typically, "ca-file" must be defined with intermediate certificates and "ca-verify-file" with certificates to ending the chain, like root CA. Fix issue #404.
2019-12-16 10:39:17 -05:00
if (ca_verify_file && !ssl_set_verify_locations_file(ctx, ca_verify_file)) {
memprintf(err, "%sProxy '%s': unable to set CA-no-names file '%s' for bind '%s' at [%s:%d].\n",
err && *err ? *err : "", curproxy->id, ca_verify_file, bind_conf->arg, bind_conf->file, bind_conf->line);
cfgerr |= ERR_ALERT | ERR_FATAL;
}
if (ca_file && !((ssl_conf && ssl_conf->no_ca_names) || bind_conf->ssl_conf.no_ca_names)) {
MINOR: ssl: add "no-ca-names" parameter for bind This option prevent to send CA names in server hello message when ca-file is used. This parameter is also available in "crt-list".
2017-07-28 09:01:05 -04:00
/* set CA names for client cert request, function returns void */
MINOR: ssl: compute ca-list from deduplicate ca-file ca-list can be extracted from ca-file already loaded in memory. This patch set ca-list from deduplicated ca-file when needed and share it in ca-file tree. As a corollary, this will prevent file access for ca-list when updating a certificate via CLI.
2019-10-24 12:08:51 -04:00
SSL_CTX_set_client_CA_list(ctx, SSL_dup_CA_list(ssl_get_client_ca_file(ca_file)));
MINOR: ssl: add "no-ca-names" parameter for bind This option prevent to send CA names in server hello message when ca-file is used. This parameter is also available in "crt-list".
2017-07-28 09:01:05 -04:00
}
MINOR: ssl: disable CRL checks with WolfSSL when no CRL file WolfSSL is enabling by default the CRL checks even if a CRL file wasn't provided. This patch resets the default X509_STORE flags so this is not checked by default.
2023-05-02 12:26:46 -04:00
#ifdef USE_OPENSSL_WOLFSSL
/* WolfSSL activates CRL checks by default so we need to disable it */
X509_STORE_set_flags(store, 0) ;
#endif
MEDIUM: ssl: add client certificate authentication support Add keyword 'verify' on bind: 'verify none': authentication disabled (default) 'verify optional': accept connection without certificate and process a verify if the client sent a certificate 'verify required': reject connection without certificate and process a verify if the client send a certificate Add keyword 'cafile' on bind: 'cafile <path>' path to a client CA file used to verify. 'crlfile <path>' path to a client CRL file used to verify.
2012-09-20 12:23:56 -04:00
}
MEDIUM: ssl: Set verify 'required' as global default for servers side. If no CA file specified on a server line, the config parser will show an error. Adds an cmdline option '-dV' to re-set verify 'none' as global default on servers side (previous behavior). Also adds 'ssl-server-verify' global statement to set global default to 'none' or 'required'. WARNING: this changes the default verify mode from "none" to "required" on the server side, and it *will* break insecure setups.
2014-01-29 06:24:34 -05:00
else {
CLEANUP: ssl: Clean up error handling This commit removes the explicit checks for `if (err)` before passing `err` to `memprintf`. `memprintf` already checks itself whether the `**out*` parameter is `NULL` before doing anything. This reduces the indentation depth and makes the code more readable, before there is less boilerplate code. Instead move the check into the ternary conditional when the error message should be appended to a previous message. This is consistent with the rest of ssl_sock.c and with the rest of HAProxy. Thus this patch is the arguably cleaner fix for issue #374 and builds upon 5f1fa7db86c53827c97f8a8c3f5fa75bfcb5be9a and 8b453912ce9a4e1a3b1329efb2af04d1e470852e Additionally it fixes a few places where the check *still* was missing.
2019-11-23 17:45:10 -05:00
memprintf(err, "%sProxy '%s': verify is enabled but no CA file specified for bind '%s' at [%s:%d].\n",
err && *err ? *err : "", curproxy->id, bind_conf->arg, bind_conf->file, bind_conf->line);
MINOR: ssl: ssl_sock_prepare_ctx() return an error code Rework ssl_sock_prepare_ctx() so it fills a buffer with the error messages instead of using ha_alert()/ha_warning(). Also returns an error code (ERR_*) instead of the number of errors.
2019-11-21 09:48:10 -05:00
cfgerr |= ERR_ALERT | ERR_FATAL;
MEDIUM: ssl: Set verify 'required' as global default for servers side. If no CA file specified on a server line, the config parser will show an error. Adds an cmdline option '-dV' to re-set verify 'none' as global default on servers side (previous behavior). Also adds 'ssl-server-verify' global statement to set global default to 'none' or 'required'. WARNING: this changes the default verify mode from "none" to "required" on the server side, and it *will* break insecure setups.
2014-01-29 06:24:34 -05:00
}
BUG/MINOR: build: Fix compilation issue on openssl 0.9.6 due to missing CRL feature.
2012-10-02 13:25:50 -04:00
#ifdef X509_V_FLAG_CRL_CHECK
MAJOR: ssl: bind configuration per certificat crt-list is extend to support ssl configuration. You can now have such line in crt-list <file>: mycert.pem [npn h2,http/1.1] Support include "npn", "alpn", "verify", "ca_file", "crl_file", "ecdhe", "ciphers" configuration and ssl options. "crt-base" is also supported to fetch certificates.
2016-12-29 12:26:15 -05:00
if (crl_file) {
MEDIUM: ssl: add client certificate authentication support Add keyword 'verify' on bind: 'verify none': authentication disabled (default) 'verify optional': accept connection without certificate and process a verify if the client sent a certificate 'verify required': reject connection without certificate and process a verify if the client send a certificate Add keyword 'cafile' on bind: 'cafile <path>' path to a client CA file used to verify. 'crlfile <path>' path to a client CRL file used to verify.
2012-09-20 12:23:56 -04:00
MINOR: ssl: deduplicate crl-file Load file for crl or ca-cert is realy done with the same function in OpenSSL, via X509_STORE_load_locations. Accordingly, deduplicate crl-file and ca-file can share the same function.
2019-11-21 13:09:31 -05:00
if (!ssl_set_cert_crl_file(store, crl_file)) {
CLEANUP: ssl: Clean up error handling This commit removes the explicit checks for `if (err)` before passing `err` to `memprintf`. `memprintf` already checks itself whether the `**out*` parameter is `NULL` before doing anything. This reduces the indentation depth and makes the code more readable, before there is less boilerplate code. Instead move the check into the ternary conditional when the error message should be appended to a previous message. This is consistent with the rest of ssl_sock.c and with the rest of HAProxy. Thus this patch is the arguably cleaner fix for issue #374 and builds upon 5f1fa7db86c53827c97f8a8c3f5fa75bfcb5be9a and 8b453912ce9a4e1a3b1329efb2af04d1e470852e Additionally it fixes a few places where the check *still* was missing.
2019-11-23 17:45:10 -05:00
memprintf(err, "%sProxy '%s': unable to configure CRL file '%s' for bind '%s' at [%s:%d].\n",
err && *err ? *err : "", curproxy->id, crl_file, bind_conf->arg, bind_conf->file, bind_conf->line);
MINOR: ssl: ssl_sock_prepare_ctx() return an error code Rework ssl_sock_prepare_ctx() so it fills a buffer with the error messages instead of using ha_alert()/ha_warning(). Also returns an error code (ERR_*) instead of the number of errors.
2019-11-21 09:48:10 -05:00
cfgerr |= ERR_ALERT | ERR_FATAL;
MEDIUM: ssl: add client certificate authentication support Add keyword 'verify' on bind: 'verify none': authentication disabled (default) 'verify optional': accept connection without certificate and process a verify if the client sent a certificate 'verify required': reject connection without certificate and process a verify if the client send a certificate Add keyword 'cafile' on bind: 'cafile <path>' path to a client CA file used to verify. 'crlfile <path>' path to a client CRL file used to verify.
2012-09-20 12:23:56 -04:00
}
BUG/MINOR: ssl: Fix CRL check was not enabled when crlfile was specified.
2012-10-02 09:20:55 -04:00
else {
X509_STORE_set_flags(store, X509_V_FLAG_CRL_CHECK|X509_V_FLAG_CRL_CHECK_ALL);
}
MEDIUM: ssl: add client certificate authentication support Add keyword 'verify' on bind: 'verify none': authentication disabled (default) 'verify optional': accept connection without certificate and process a verify if the client sent a certificate 'verify required': reject connection without certificate and process a verify if the client send a certificate Add keyword 'cafile' on bind: 'cafile <path>' path to a client CA file used to verify. 'crlfile <path>' path to a client CRL file used to verify.
2012-09-20 12:23:56 -04:00
}
BUG/MINOR: build: Fix compilation issue on openssl 0.9.6 due to missing CRL feature.
2012-10-02 13:25:50 -04:00
#endif
BUG/MEDIUM: ssl: Prevent ssl error from affecting other connections. J. Maurice reported that ssllabs.com test affects unrelated legitimate traffic and cause SSL errors and broken connections. Sometimes openssl store read/write/handshake errors in a global stack. This stack is not specific to the current session. Openssl API does not clean the stack at the beginning of a new read/write. And the function used to retrieve error ID after read/write, returns the generic error SSL_ERROR_SSL if the global stack is not empty. The fix consists in cleaning the errors stack after read/write/handshake errors.
2012-12-14 05:21:13 -05:00
ERR_clear_error();
MEDIUM: ssl: add client certificate authentication support Add keyword 'verify' on bind: 'verify none': authentication disabled (default) 'verify optional': accept connection without certificate and process a verify if the client sent a certificate 'verify required': reject connection without certificate and process a verify if the client send a certificate Add keyword 'cafile' on bind: 'cafile <path>' path to a client CA file used to verify. 'crlfile <path>' path to a client CRL file used to verify.
2012-09-20 12:23:56 -04:00
}
MEDIUM: Add support for configurable TLS ticket keys Until now, the TLS ticket keys couldn't have been configured and shared between multiple instances or multiple servers running HAproxy. The result was that if a request got a TLS ticket from one instance/server and it hits another one afterwards, it will have to go through the full SSL handshake and negotation. This patch enables adding a ticket file to the bind line, which will be used for all SSL contexts created from that bind line. We can use the same file on all instances or servers to mitigate this issue and have consistent TLS tickets assigned. Clients will no longer have to negotiate every time they change the handling process. Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
2015-02-27 13:56:49 -05:00
#if (defined SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB && TLS_TICKETS_NO > 0)
MINOR: Add TLS ticket keys reference and use it in the listener struct Within the listener struct we need to use a reference to the TLS ticket keys which binds the actual keys with the filename. This will make it possible to update the keys through the socket Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
2015-05-09 02:46:00 -04:00
if(bind_conf->keys_ref) {
MINOR: ssl: Remove call to SSL_CTX_set_tlsext_ticket_key_cb with OpenSSLv3 SSL_CTX_set_tlsext_ticket_key_cb was deprecated on OpenSSLv3 because it uses an HMAC_pointer which is deprecated as well. According to the v3's manpage it should be replaced by SSL_CTX_set_tlsext_ticket_key_evp_cb which uses a EVP_MAC_CTX pointer. This new callback was introduced in OpenSSLv3 so we need to keep the two calls in the source base and to split the usage depending on the OpenSSL version.
2022-02-08 11:45:58 -05:00
if (!SSL_CTX_set_tlsext_ticket_key_evp_cb(ctx, ssl_tlsext_ticket_key_cb)) {
CLEANUP: ssl: Clean up error handling This commit removes the explicit checks for `if (err)` before passing `err` to `memprintf`. `memprintf` already checks itself whether the `**out*` parameter is `NULL` before doing anything. This reduces the indentation depth and makes the code more readable, before there is less boilerplate code. Instead move the check into the ternary conditional when the error message should be appended to a previous message. This is consistent with the rest of ssl_sock.c and with the rest of HAProxy. Thus this patch is the arguably cleaner fix for issue #374 and builds upon 5f1fa7db86c53827c97f8a8c3f5fa75bfcb5be9a and 8b453912ce9a4e1a3b1329efb2af04d1e470852e Additionally it fixes a few places where the check *still* was missing.
2019-11-23 17:45:10 -05:00
memprintf(err, "%sProxy '%s': unable to set callback for TLS ticket validation for bind '%s' at [%s:%d].\n",
err && *err ? *err : "", curproxy->id, bind_conf->arg, bind_conf->file, bind_conf->line);
MINOR: ssl: ssl_sock_prepare_ctx() return an error code Rework ssl_sock_prepare_ctx() so it fills a buffer with the error messages instead of using ha_alert()/ha_warning(). Also returns an error code (ERR_*) instead of the number of errors.
2019-11-21 09:48:10 -05:00
cfgerr |= ERR_ALERT | ERR_FATAL;
MEDIUM: Add support for configurable TLS ticket keys Until now, the TLS ticket keys couldn't have been configured and shared between multiple instances or multiple servers running HAproxy. The result was that if a request got a TLS ticket from one instance/server and it hits another one afterwards, it will have to go through the full SSL handshake and negotation. This patch enables adding a ticket file to the bind line, which will be used for all SSL contexts created from that bind line. We can use the same file on all instances or servers to mitigate this issue and have consistent TLS tickets assigned. Clients will no longer have to negotiate every time they change the handling process. Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
2015-02-27 13:56:49 -05:00
}
}
#endif
MEDIUM: shctx: separate ssl and shctx This patch reorganize the shctx API in a generic storage API, separating the shared SSL session handling from its core. The shctx API only handles the generic data part, it does not know what kind of data you use with it. A shared_context is a storage structure allocated in a shared memory, allowing its usage in a multithread or a multiprocess context. The structure use 2 linked list, one containing the available blocks, and another for the hot locked blocks. At initialization the available list is filled with <maxblocks> blocks of size <blocksize>. An <extra> space is initialized outside the list in case you need some specific storage. +-----------------------+--------+--------+--------+--------+---- | struct shared_context | extra | block1 | block2 | block3 | ... +-----------------------+--------+--------+--------+--------+---- <-------- maxblocks ---------> * blocksize The API allows to store content on several linked blocks. For example, if you allocated blocks of 16 bytes, and you want to store an object of 60 bytes, the object will be allocated in a row of 4 blocks. The API was made for LRU usage, each time you get an object, it pushes the object at the end of the list. When it needs more space, it discards The functions name have been renamed in a more logical way, the part regarding shctx have been prefixed by shctx_ and the functions for the shared ssl session cache have been prefixed by sh_ssl_sess_.
2017-10-30 15:08:51 -04:00
ssl_set_shctx(ctx);
MAJOR: ssl: bind configuration per certificat crt-list is extend to support ssl configuration. You can now have such line in crt-list <file>: mycert.pem [npn h2,http/1.1] Support include "npn", "alpn", "verify", "ca_file", "crl_file", "ecdhe", "ciphers" configuration and ssl options. "crt-base" is also supported to fetch certificates.
2016-12-29 12:26:15 -05:00
conf_ciphers = (ssl_conf && ssl_conf->ciphers) ? ssl_conf->ciphers : bind_conf->ssl_conf.ciphers;
if (conf_ciphers &&
!SSL_CTX_set_cipher_list(ctx, conf_ciphers)) {
CLEANUP: ssl: Clean up error handling This commit removes the explicit checks for `if (err)` before passing `err` to `memprintf`. `memprintf` already checks itself whether the `**out*` parameter is `NULL` before doing anything. This reduces the indentation depth and makes the code more readable, before there is less boilerplate code. Instead move the check into the ternary conditional when the error message should be appended to a previous message. This is consistent with the rest of ssl_sock.c and with the rest of HAProxy. Thus this patch is the arguably cleaner fix for issue #374 and builds upon 5f1fa7db86c53827c97f8a8c3f5fa75bfcb5be9a and 8b453912ce9a4e1a3b1329efb2af04d1e470852e Additionally it fixes a few places where the check *still* was missing.
2019-11-23 17:45:10 -05:00
memprintf(err, "%sProxy '%s': unable to set SSL cipher list to '%s' for bind '%s' at [%s:%d].\n",
err && *err ? *err : "", curproxy->id, conf_ciphers, bind_conf->arg, bind_conf->file, bind_conf->line);
MINOR: ssl: ssl_sock_prepare_ctx() return an error code Rework ssl_sock_prepare_ctx() so it fills a buffer with the error messages instead of using ha_alert()/ha_warning(). Also returns an error code (ERR_*) instead of the number of errors.
2019-11-21 09:48:10 -05:00
cfgerr |= ERR_ALERT | ERR_FATAL;
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
}
BUILD: SSL: guard TLS13 ciphersuites with HAVE_SSL_CTX_SET_CIPHERSUITES HAVE_SSL_CTX_SET_CIPHERSUITES is newly defined macro set in openssl-compat.h, which helps to identify ssl libs (currently OpenSSL-1.1.1 only) that supports TLS13 cipersuites manipulation on TLS13 context
2020-11-21 04:37:34 -05:00
#ifdef HAVE_SSL_CTX_SET_CIPHERSUITES
MEDIUM: ssl: add support for ciphersuites option for TLSv1.3 OpenSSL released support for TLSv1.3. It also added a separate function SSL_CTX_set_ciphersuites that is used to set the ciphers used in the TLS 1.3 handshake. This change adds support for that new configuration option by adding a ciphersuites configuration variable that works essentially the same as the existing ciphers setting. Note that it should likely be backported to 1.8 in order to ease usage of the now released openssl-1.1.1.
2018-09-14 05:14:21 -04:00
conf_ciphersuites = (ssl_conf && ssl_conf->ciphersuites) ? ssl_conf->ciphersuites : bind_conf->ssl_conf.ciphersuites;
if (conf_ciphersuites &&
!SSL_CTX_set_ciphersuites(ctx, conf_ciphersuites)) {
CLEANUP: ssl: Clean up error handling This commit removes the explicit checks for `if (err)` before passing `err` to `memprintf`. `memprintf` already checks itself whether the `**out*` parameter is `NULL` before doing anything. This reduces the indentation depth and makes the code more readable, before there is less boilerplate code. Instead move the check into the ternary conditional when the error message should be appended to a previous message. This is consistent with the rest of ssl_sock.c and with the rest of HAProxy. Thus this patch is the arguably cleaner fix for issue #374 and builds upon 5f1fa7db86c53827c97f8a8c3f5fa75bfcb5be9a and 8b453912ce9a4e1a3b1329efb2af04d1e470852e Additionally it fixes a few places where the check *still* was missing.
2019-11-23 17:45:10 -05:00
memprintf(err, "%sProxy '%s': unable to set TLS 1.3 cipher suites to '%s' for bind '%s' at [%s:%d].\n",
err && *err ? *err : "", curproxy->id, conf_ciphersuites, bind_conf->arg, bind_conf->file, bind_conf->line);
MINOR: ssl: ssl_sock_prepare_ctx() return an error code Rework ssl_sock_prepare_ctx() so it fills a buffer with the error messages instead of using ha_alert()/ha_warning(). Also returns an error code (ERR_*) instead of the number of errors.
2019-11-21 09:48:10 -05:00
cfgerr |= ERR_ALERT | ERR_FATAL;
MEDIUM: ssl: add support for ciphersuites option for TLSv1.3 OpenSSL released support for TLSv1.3. It also added a separate function SSL_CTX_set_ciphersuites that is used to set the ciphers used in the TLS 1.3 handshake. This change adds support for that new configuration option by adding a ciphersuites configuration variable that works essentially the same as the existing ciphers setting. Note that it should likely be backported to 1.8 in order to ease usage of the now released openssl-1.1.1.
2018-09-14 05:14:21 -04:00
}
#endif
BUILD: ssl: fix build with -DOPENSSL_NO_DH
2017-03-03 11:04:14 -05:00
#ifndef OPENSSL_NO_DH
MEDIUM: ssl: Disable DHE ciphers by default DHE ciphers do not present a security risk if the key is big enough but they are slow and mostly obsoleted by ECDHE. This patch removes any default DH parameters. This will effectively disable all DHE ciphers unless a global ssl-dh-param-file is defined, or tune.ssl.default-dh-param is set, or a frontend has DH parameters included in its PEM certificate. In this latter case, only the frontends that have DH parameters will have DHE ciphers enabled. Adding explicitely a DHE ciphers in a "bind" line will not be enough to actually enable DHE. We would still need to know which DH parameters to use so one of the three conditions described above must be met. This request was described in GitHub issue #1604.
2022-04-12 05:31:55 -04:00
if (!local_dh_1024)
local_dh_1024 = ssl_get_dh_1024();
if (!local_dh_2048)
local_dh_2048 = ssl_get_dh_2048();
if (!local_dh_4096)
local_dh_4096 = ssl_get_dh_4096();
BUG/MEDIUM: ssl: Fix a memory leak in DHE key exchange OpenSSL does not free the DH * value returned by the callback specified with SSL_CTX_set_tmp_dh_callback(), leading to a memory leak for SSL/TLS connections using Diffie Hellman Ephemeral key exchange. This patch fixes the leak by allocating the DH * structs holding the DH parameters once, at configuration time. Note: this fix must be backported to 1.5.
2014-07-15 05:36:40 -04:00
#endif /* OPENSSL_NO_DH */
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
SSL_CTX_set_info_callback(ctx, ssl_sock_infocbk);
BUILD: ssl: guard SSL_CTX_set_msg_callback with SSL_CTRL_SET_MSG_CALLBACK macro both SSL_CTX_set_msg_callback and SSL_CTRL_SET_MSG_CALLBACK defined since ea262260469e49149cb10b25a87dfd6ad3fbb4ba, we can safely switch to that guard instead of OpenSSL version
2021-02-08 06:55:06 -05:00
#ifdef SSL_CTRL_SET_MSG_CALLBACK
MEDIUM: ssl: explicitly log failed handshakes after a heartbeat Add a callback to receive the heartbeat notification. There, we add SSL_SOCK_RECV_HEARTBEAT flag on the ssl session if a heartbeat is seen. If a handshake fails, we log a different message to mention the fact that a heartbeat was seen. The test is only performed on the frontend side.
2014-04-25 13:05:36 -04:00
SSL_CTX_set_msg_callback(ctx, ssl_sock_msgcbk);
BUILD: ssl: SSL_CTX_set_msg_callback() needs openssl >= 0.9.7 1.5-dev24 introduced SSL_CTX_set_msg_callback(), which came with OpenSSL 0.9.7. A build attempt with an older one failed and we're still compatible with 0.9.6 in 1.5.
2014-05-08 16:45:11 -04:00
#endif
BUILD: make tune.ssl.keylog available again Since commit 04a5a44 ("BUILD: ssl: use HAVE_OPENSSL_KEYLOG instead of OpenSSL versions") the "tune.ssl.keylog" feature is broken because HAVE_OPENSSL_KEYLOG does not exist. Replace this by a HAVE_SSL_KEYLOG which is defined in openssl-compat.h. Also add an error when not built with the right openssl version. Must be backported as far as 2.3.
2021-06-09 10:46:12 -04:00
#ifdef HAVE_SSL_KEYLOG
BUG/MINOR: ssl: don't initialize the keylog callback when not required The registering of the keylog callback seems to provoke a loss of performance. Disable the registration as well as the fetches if tune.ssl.keylog is off. Must be backported as far as 2.2.
2022-11-18 09:00:15 -05:00
/* only activate the keylog callback if it was required to prevent performance loss */
if (global_ssl.keylog > 0)
SSL_CTX_set_keylog_callback(ctx, SSL_CTX_keylog);
WIP/MINOR: ssl: add sample fetches for keylog in frontend OpenSSL 1.1.1 provides a callback registering function SSL_CTX_set_keylog_callback, which allows one to receive a string containing the keys to deciphers TLSv1.3. Unfortunately it is not possible to store this data in binary form and we can only get this information using the callback. Which means that we need to store it until the connection is closed. This patches add 2 pools, the first one, pool_head_ssl_keylog is used to store a struct ssl_keylog which will be inserted as a ex_data in a SSL *. The second one is pool_head_ssl_keylog_str which will be used to store the hexadecimal strings. To enable the capture of the keys, you need to set "tune.ssl.keylog on" in your configuration. The following fetches were implemented: ssl_fc_client_early_traffic_secret, ssl_fc_client_handshake_traffic_secret, ssl_fc_server_handshake_traffic_secret, ssl_fc_client_traffic_secret_0, ssl_fc_server_traffic_secret_0, ssl_fc_exporter_secret, ssl_fc_early_exporter_secret
2020-07-06 05:41:30 -04:00
#endif
MEDIUM: ssl: explicitly log failed handshakes after a heartbeat Add a callback to receive the heartbeat notification. There, we add SSL_SOCK_RECV_HEARTBEAT flag on the ssl session if a heartbeat is seen. If a handshake fails, we log a different message to mention the fact that a heartbeat was seen. The test is only performed on the frontend side.
2014-04-25 13:05:36 -04:00
BUILD: ssl: Fix build with OpenSSL without NPN capability OpenSSL can be built without NEXTPROTONEG support by passing -no-npn to the configure script. This sets the OPENSSL_NO_NEXTPROTONEG flag in opensslconf.h Since NEXTPROTONEG is now considered deprecated, it is superseeded by ALPN (Application Layer Protocol Next), HAProxy should allow building withough NPN support.
2018-02-15 07:34:58 -05:00
#if defined(OPENSSL_NPN_NEGOTIATED) && !defined(OPENSSL_NO_NEXTPROTONEG)
MAJOR: ssl: bind configuration per certificat crt-list is extend to support ssl configuration. You can now have such line in crt-list <file>: mycert.pem [npn h2,http/1.1] Support include "npn", "alpn", "verify", "ca_file", "crl_file", "ecdhe", "ciphers" configuration and ssl options. "crt-base" is also supported to fetch certificates.
2016-12-29 12:26:15 -05:00
ssl_conf_cur = NULL;
if (ssl_conf && ssl_conf->npn_str)
ssl_conf_cur = ssl_conf;
else if (bind_conf->ssl_conf.npn_str)
ssl_conf_cur = &bind_conf->ssl_conf;
if (ssl_conf_cur)
SSL_CTX_set_next_protos_advertised_cb(ctx, ssl_sock_advertise_npn_protos, ssl_conf_cur);
MEDIUM: ssl: add support for the "npn" bind keyword The ssl_npn match could not work by itself because clients do not use the NPN extension unless the server advertises the protocols it supports. Thanks to Simone Bordet for the explanations on how to get it right.
2012-10-18 12:57:14 -04:00
#endif
MEDIUM: ssl: Use ALPN support as it will be available in OpenSSL 1.0.2 The current ALPN support is based on custom OpenSSL patches. These are however not the same as what has landed on OpenSSL: http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=6f017a8f9db3a79f3a3406cf8d493ccd346db691 This patch change the code so it supports ALPN as it will be part of OpenSSL.
2014-02-13 06:29:42 -05:00
#ifdef TLSEXT_TYPE_application_layer_protocol_negotiation
MAJOR: ssl: bind configuration per certificat crt-list is extend to support ssl configuration. You can now have such line in crt-list <file>: mycert.pem [npn h2,http/1.1] Support include "npn", "alpn", "verify", "ca_file", "crl_file", "ecdhe", "ciphers" configuration and ssl options. "crt-base" is also supported to fetch certificates.
2016-12-29 12:26:15 -05:00
ssl_conf_cur = NULL;
if (ssl_conf && ssl_conf->alpn_str)
ssl_conf_cur = ssl_conf;
else if (bind_conf->ssl_conf.alpn_str)
ssl_conf_cur = &bind_conf->ssl_conf;
MINOR: ssl: do not set ALPN callback with the empty string While it does not have any effect, it's better not to try to setup an ALPN callback nor to try to lookup algorithms when the configured ALPN string is empty as a result of "no-alpn" being used.
2023-04-19 03:05:49 -04:00
if (ssl_conf_cur && ssl_conf_cur->alpn_len)
MAJOR: ssl: bind configuration per certificat crt-list is extend to support ssl configuration. You can now have such line in crt-list <file>: mycert.pem [npn h2,http/1.1] Support include "npn", "alpn", "verify", "ca_file", "crl_file", "ecdhe", "ciphers" configuration and ssl options. "crt-base" is also supported to fetch certificates.
2016-12-29 12:26:15 -05:00
SSL_CTX_set_alpn_select_cb(ctx, ssl_sock_advertise_alpn_protos, ssl_conf_cur);
MINOR: ssl: add support for the "alpn" bind keyword The ALPN extension is meant to replace the now deprecated NPN extension. This patch implements support for it. It requires a version of openssl with support for this extension. Patches are available here right now : http://html5labs.interopbridges.com/media/167447/alpn_patches.zip
2013-04-01 20:30:41 -04:00
#endif
BUILD: ssl: use feature macros for detecting ec curves manipulation support Let us use SSL_CTX_set1_curves_list, defined by OpenSSL, as well as in openssl-compat when SSL_CTRL_SET_CURVES_LIST is present (BoringSSL), for feature detection instead of versions.
2020-11-03 14:39:07 -05:00
#if defined(SSL_CTX_set1_curves_list)
MINOR: ssl: add curve suite for ECDHE negotiation Add 'curves' parameter on 'bind' and for 'crt-list' to set curve suite. (ex: curves X25519:P-256)
2017-01-09 10:15:54 -05:00
conf_curves = (ssl_conf && ssl_conf->curves) ? ssl_conf->curves : bind_conf->ssl_conf.curves;
if (conf_curves) {
if (!SSL_CTX_set1_curves_list(ctx, conf_curves)) {
CLEANUP: ssl: Clean up error handling This commit removes the explicit checks for `if (err)` before passing `err` to `memprintf`. `memprintf` already checks itself whether the `**out*` parameter is `NULL` before doing anything. This reduces the indentation depth and makes the code more readable, before there is less boilerplate code. Instead move the check into the ternary conditional when the error message should be appended to a previous message. This is consistent with the rest of ssl_sock.c and with the rest of HAProxy. Thus this patch is the arguably cleaner fix for issue #374 and builds upon 5f1fa7db86c53827c97f8a8c3f5fa75bfcb5be9a and 8b453912ce9a4e1a3b1329efb2af04d1e470852e Additionally it fixes a few places where the check *still* was missing.
2019-11-23 17:45:10 -05:00
memprintf(err, "%sProxy '%s': unable to set SSL curves list to '%s' for bind '%s' at [%s:%d].\n",
err && *err ? *err : "", curproxy->id, conf_curves, bind_conf->arg, bind_conf->file, bind_conf->line);
MINOR: ssl: ssl_sock_prepare_ctx() return an error code Rework ssl_sock_prepare_ctx() so it fills a buffer with the error messages instead of using ha_alert()/ha_warning(). Also returns an error code (ERR_*) instead of the number of errors.
2019-11-21 09:48:10 -05:00
cfgerr |= ERR_ALERT | ERR_FATAL;
MINOR: ssl: add curve suite for ECDHE negotiation Add 'curves' parameter on 'bind' and for 'crt-list' to set curve suite. (ex: curves X25519:P-256)
2017-01-09 10:15:54 -05:00
}
BUILD: ssl: simplify SSL_CTX_set_ecdh_auto compatibility SSL_CTX_set_ecdh_auto is declared (when present) with #define. A simple #ifdef avoid to list all cases of ssllibs. It's a placebo in new ssllibs. It's ok with openssl 1.0.1, 1.0.2, 1.1.0, libressl and boringssl. Thanks to Piotr Kubaj for postponing and testing with libressl.
2017-03-20 06:11:49 -04:00
(void)SSL_CTX_set_ecdh_auto(ctx, 1);
MINOR: ssl: add curve suite for ECDHE negotiation Add 'curves' parameter on 'bind' and for 'crt-list' to set curve suite. (ex: curves X25519:P-256)
2017-01-09 10:15:54 -05:00
}
MINOR: ssl: Remove EC_KEY related calls when preparing SSL context The ecdhe option relies on the SSL_CTX_set_tmp_ecdh function which has been marked as deprecated in OpenSSLv3. As advised in the SSL_CTX_set_tmp_ecdh manpage, this function should be replaced by the SSL_CTX_set1_groups one (or the SSL_CTX_set1_curves one in our case which does the same but existed on older OpenSSL versions as well). When using the "curves" option we have a different behaviour with OpenSSL1.0.2 compared to later versions. On this early version an SSL backend using a P-256 ECDSA certificate manages to connect to an SSL frontend having a "curves P-384" option (when it fails with later versions). Even if the API used for later version than OpenSSL 1.0.2 already existed then, for some reason the behaviour is not the same on the older version which explains why the original code with the deprecated API is kept for this version (otherwise we would risk breaking everything on a version that might still be used by some people despite being pretty old). This patch should be strictly isofunctional.
2022-02-08 11:45:54 -05:00
#endif /* defined(SSL_CTX_set1_curves_list) */
MINOR: ssl: add curve suite for ECDHE negotiation Add 'curves' parameter on 'bind' and for 'crt-list' to set curve suite. (ex: curves X25519:P-256)
2017-01-09 10:15:54 -05:00
if (!conf_curves) {
CLEANUP: ssl-sock: use HA_OPENSSL_VERSION_NUMBER instead of OPENSSL_VERSION_NUMBER Most tests on OPENSSL_VERSION_NUMBER have become complex and break all the time because this number is fake for some derivatives like LibreSSL. This patch creates a new macro, HA_OPENSSL_VERSION_NUMBER, which will carry the real openssl version defining the compatibility level, and this version will be adjusted depending on the variants.
2019-05-09 07:26:41 -04:00
#if (HA_OPENSSL_VERSION_NUMBER >= 0x10101000L)
MINOR: ssl: Remove EC_KEY related calls when preparing SSL context The ecdhe option relies on the SSL_CTX_set_tmp_ecdh function which has been marked as deprecated in OpenSSLv3. As advised in the SSL_CTX_set_tmp_ecdh manpage, this function should be replaced by the SSL_CTX_set1_groups one (or the SSL_CTX_set1_curves one in our case which does the same but existed on older OpenSSL versions as well). When using the "curves" option we have a different behaviour with OpenSSL1.0.2 compared to later versions. On this early version an SSL backend using a P-256 ECDSA certificate manages to connect to an SSL frontend having a "curves P-384" option (when it fails with later versions). Even if the API used for later version than OpenSSL 1.0.2 already existed then, for some reason the behaviour is not the same on the older version which explains why the original code with the deprecated API is kept for this version (otherwise we would risk breaking everything on a version that might still be used by some people despite being pretty old). This patch should be strictly isofunctional.
2022-02-08 11:45:54 -05:00
#if defined(SSL_CTX_set1_curves_list)
MAJOR: ssl: bind configuration per certificat crt-list is extend to support ssl configuration. You can now have such line in crt-list <file>: mycert.pem [npn h2,http/1.1] Support include "npn", "alpn", "verify", "ca_file", "crl_file", "ecdhe", "ciphers" configuration and ssl options. "crt-base" is also supported to fetch certificates.
2016-12-29 12:26:15 -05:00
const char *ecdhe = (ssl_conf && ssl_conf->ecdhe) ? ssl_conf->ecdhe :
MEDIUM: ssl: Handle early data with OpenSSL 1.1.1 When compiled with Openssl >= 1.1.1, before attempting to do the handshake, try to read any early data. If any early data is present, then we'll create the session, read the data, and handle the request before we're doing the handshake. For this, we add a new connection flag, CO_FL_EARLY_SSL_HS, which is not part of the CO_FL_HANDSHAKE set, allowing to proceed with a session even before an SSL handshake is completed. As early data do have security implication, we let the origin server know the request comes from early data by adding the "Early-Data" header, as specified in this draft from the HTTP working group : https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-replay
2017-09-22 12:26:28 -04:00
(bind_conf->ssl_conf.ecdhe ? bind_conf->ssl_conf.ecdhe :
NULL);
MINOR: ssl: Remove EC_KEY related calls when preparing SSL context The ecdhe option relies on the SSL_CTX_set_tmp_ecdh function which has been marked as deprecated in OpenSSLv3. As advised in the SSL_CTX_set_tmp_ecdh manpage, this function should be replaced by the SSL_CTX_set1_groups one (or the SSL_CTX_set1_curves one in our case which does the same but existed on older OpenSSL versions as well). When using the "curves" option we have a different behaviour with OpenSSL1.0.2 compared to later versions. On this early version an SSL backend using a P-256 ECDSA certificate manages to connect to an SSL frontend having a "curves P-384" option (when it fails with later versions). Even if the API used for later version than OpenSSL 1.0.2 already existed then, for some reason the behaviour is not the same on the older version which explains why the original code with the deprecated API is kept for this version (otherwise we would risk breaking everything on a version that might still be used by some people despite being pretty old). This patch should be strictly isofunctional.
2022-02-08 11:45:54 -05:00
if (ecdhe && SSL_CTX_set1_curves_list(ctx, ecdhe) == 0) {
memprintf(err, "%sProxy '%s': unable to set elliptic named curve to '%s' for bind '%s' at [%s:%d].\n",
err && *err ? *err : "", curproxy->id, ecdhe, bind_conf->arg, bind_conf->file, bind_conf->line);
cfgerr |= ERR_ALERT | ERR_FATAL;
MEDIUM: ssl: Handle early data with OpenSSL 1.1.1 When compiled with Openssl >= 1.1.1, before attempting to do the handshake, try to read any early data. If any early data is present, then we'll create the session, read the data, and handle the request before we're doing the handshake. For this, we add a new connection flag, CO_FL_EARLY_SSL_HS, which is not part of the CO_FL_HANDSHAKE set, allowing to proceed with a session even before an SSL handshake is completed. As early data do have security implication, we let the origin server know the request comes from early data by adding the "Early-Data" header, as specified in this draft from the HTTP working group : https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-replay
2017-09-22 12:26:28 -04:00
}
MINOR: ssl: Remove EC_KEY related calls when preparing SSL context The ecdhe option relies on the SSL_CTX_set_tmp_ecdh function which has been marked as deprecated in OpenSSLv3. As advised in the SSL_CTX_set_tmp_ecdh manpage, this function should be replaced by the SSL_CTX_set1_groups one (or the SSL_CTX_set1_curves one in our case which does the same but existed on older OpenSSL versions as well). When using the "curves" option we have a different behaviour with OpenSSL1.0.2 compared to later versions. On this early version an SSL backend using a P-256 ECDSA certificate manages to connect to an SSL frontend having a "curves P-384" option (when it fails with later versions). Even if the API used for later version than OpenSSL 1.0.2 already existed then, for some reason the behaviour is not the same on the older version which explains why the original code with the deprecated API is kept for this version (otherwise we would risk breaking everything on a version that might still be used by some people despite being pretty old). This patch should be strictly isofunctional.
2022-02-08 11:45:54 -05:00
#endif /* defined(SSL_CTX_set1_curves_list) */
MEDIUM: ssl: Handle early data with OpenSSL 1.1.1 When compiled with Openssl >= 1.1.1, before attempting to do the handshake, try to read any early data. If any early data is present, then we'll create the session, read the data, and handle the request before we're doing the handshake. For this, we add a new connection flag, CO_FL_EARLY_SSL_HS, which is not part of the CO_FL_HANDSHAKE set, allowing to proceed with a session even before an SSL handshake is completed. As early data do have security implication, we let the origin server know the request comes from early data by adding the "Early-Data" header, as specified in this draft from the HTTP working group : https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-replay
2017-09-22 12:26:28 -04:00
#else
MINOR: ssl: Remove EC_KEY related calls when preparing SSL context The ecdhe option relies on the SSL_CTX_set_tmp_ecdh function which has been marked as deprecated in OpenSSLv3. As advised in the SSL_CTX_set_tmp_ecdh manpage, this function should be replaced by the SSL_CTX_set1_groups one (or the SSL_CTX_set1_curves one in our case which does the same but existed on older OpenSSL versions as well). When using the "curves" option we have a different behaviour with OpenSSL1.0.2 compared to later versions. On this early version an SSL backend using a P-256 ECDSA certificate manages to connect to an SSL frontend having a "curves P-384" option (when it fails with later versions). Even if the API used for later version than OpenSSL 1.0.2 already existed then, for some reason the behaviour is not the same on the older version which explains why the original code with the deprecated API is kept for this version (otherwise we would risk breaking everything on a version that might still be used by some people despite being pretty old). This patch should be strictly isofunctional.
2022-02-08 11:45:54 -05:00
#if defined(SSL_CTX_set_tmp_ecdh) && !defined(OPENSSL_NO_ECDH)
int i;
EC_KEY *ecdh;
MEDIUM: ssl: Handle early data with OpenSSL 1.1.1 When compiled with Openssl >= 1.1.1, before attempting to do the handshake, try to read any early data. If any early data is present, then we'll create the session, read the data, and handle the request before we're doing the handshake. For this, we add a new connection flag, CO_FL_EARLY_SSL_HS, which is not part of the CO_FL_HANDSHAKE set, allowing to proceed with a session even before an SSL handshake is completed. As early data do have security implication, we let the origin server know the request comes from early data by adding the "Early-Data" header, as specified in this draft from the HTTP working group : https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-replay
2017-09-22 12:26:28 -04:00
const char *ecdhe = (ssl_conf && ssl_conf->ecdhe) ? ssl_conf->ecdhe :
(bind_conf->ssl_conf.ecdhe ? bind_conf->ssl_conf.ecdhe :
ECDHE_DEFAULT_CURVE);
MINOR: ssl: add elliptic curve Diffie-Hellman support for ssl key generation Add 'ecdhe' on 'bind' statement: to set named curve used to generate ECDHE keys (ex: ecdhe secp521r1)
2012-09-20 11:10:03 -04:00
MAJOR: ssl: bind configuration per certificat crt-list is extend to support ssl configuration. You can now have such line in crt-list <file>: mycert.pem [npn h2,http/1.1] Support include "npn", "alpn", "verify", "ca_file", "crl_file", "ecdhe", "ciphers" configuration and ssl options. "crt-base" is also supported to fetch certificates.
2016-12-29 12:26:15 -05:00
i = OBJ_sn2nid(ecdhe);
MINOR: ssl: add elliptic curve Diffie-Hellman support for ssl key generation Add 'ecdhe' on 'bind' statement: to set named curve used to generate ECDHE keys (ex: ecdhe secp521r1)
2012-09-20 11:10:03 -04:00
if (!i || ((ecdh = EC_KEY_new_by_curve_name(i)) == NULL)) {
CLEANUP: ssl: Clean up error handling This commit removes the explicit checks for `if (err)` before passing `err` to `memprintf`. `memprintf` already checks itself whether the `**out*` parameter is `NULL` before doing anything. This reduces the indentation depth and makes the code more readable, before there is less boilerplate code. Instead move the check into the ternary conditional when the error message should be appended to a previous message. This is consistent with the rest of ssl_sock.c and with the rest of HAProxy. Thus this patch is the arguably cleaner fix for issue #374 and builds upon 5f1fa7db86c53827c97f8a8c3f5fa75bfcb5be9a and 8b453912ce9a4e1a3b1329efb2af04d1e470852e Additionally it fixes a few places where the check *still* was missing.
2019-11-23 17:45:10 -05:00
memprintf(err, "%sProxy '%s': unable to set elliptic named curve to '%s' for bind '%s' at [%s:%d].\n",
MINOR: ssl: Remove EC_KEY related calls when preparing SSL context The ecdhe option relies on the SSL_CTX_set_tmp_ecdh function which has been marked as deprecated in OpenSSLv3. As advised in the SSL_CTX_set_tmp_ecdh manpage, this function should be replaced by the SSL_CTX_set1_groups one (or the SSL_CTX_set1_curves one in our case which does the same but existed on older OpenSSL versions as well). When using the "curves" option we have a different behaviour with OpenSSL1.0.2 compared to later versions. On this early version an SSL backend using a P-256 ECDSA certificate manages to connect to an SSL frontend having a "curves P-384" option (when it fails with later versions). Even if the API used for later version than OpenSSL 1.0.2 already existed then, for some reason the behaviour is not the same on the older version which explains why the original code with the deprecated API is kept for this version (otherwise we would risk breaking everything on a version that might still be used by some people despite being pretty old). This patch should be strictly isofunctional.
2022-02-08 11:45:54 -05:00
err && *err ? *err : "", curproxy->id, ecdhe, bind_conf->arg, bind_conf->file, bind_conf->line);
MINOR: ssl: ssl_sock_prepare_ctx() return an error code Rework ssl_sock_prepare_ctx() so it fills a buffer with the error messages instead of using ha_alert()/ha_warning(). Also returns an error code (ERR_*) instead of the number of errors.
2019-11-21 09:48:10 -05:00
cfgerr |= ERR_ALERT | ERR_FATAL;
MINOR: ssl: add elliptic curve Diffie-Hellman support for ssl key generation Add 'ecdhe' on 'bind' statement: to set named curve used to generate ECDHE keys (ex: ecdhe secp521r1)
2012-09-20 11:10:03 -04:00
}
else {
SSL_CTX_set_tmp_ecdh(ctx, ecdh);
EC_KEY_free(ecdh);
}
MINOR: ssl: Remove EC_KEY related calls when preparing SSL context The ecdhe option relies on the SSL_CTX_set_tmp_ecdh function which has been marked as deprecated in OpenSSLv3. As advised in the SSL_CTX_set_tmp_ecdh manpage, this function should be replaced by the SSL_CTX_set1_groups one (or the SSL_CTX_set1_curves one in our case which does the same but existed on older OpenSSL versions as well). When using the "curves" option we have a different behaviour with OpenSSL1.0.2 compared to later versions. On this early version an SSL backend using a P-256 ECDSA certificate manages to connect to an SSL frontend having a "curves P-384" option (when it fails with later versions). Even if the API used for later version than OpenSSL 1.0.2 already existed then, for some reason the behaviour is not the same on the older version which explains why the original code with the deprecated API is kept for this version (otherwise we would risk breaking everything on a version that might still be used by some people despite being pretty old). This patch should be strictly isofunctional.
2022-02-08 11:45:54 -05:00
#endif /* defined(SSL_CTX_set_tmp_ecdh) && !defined(OPENSSL_NO_ECDH) */
#endif /* HA_OPENSSL_VERSION_NUMBER >= 0x10101000L */
MINOR: ssl: add elliptic curve Diffie-Hellman support for ssl key generation Add 'ecdhe' on 'bind' statement: to set named curve used to generate ECDHE keys (ex: ecdhe secp521r1)
2012-09-20 11:10:03 -04:00
}
MINOR: ssl: allow to change the server signature algorithm This patch introduces the "sigalgs" keyword for the bind line, which allows to configure the list of server signature algorithms negociated during the handshake. Also available as "ssl-default-bind-sigalgs" in the default section. This patch was originally written by Bruno Henc.
2023-05-04 09:33:55 -04:00
#if defined(SSL_CTX_set1_sigalgs_list)
conf_sigalgs = (ssl_conf && ssl_conf->sigalgs) ? ssl_conf->sigalgs : bind_conf->ssl_conf.sigalgs;
if (conf_sigalgs) {
if (!SSL_CTX_set1_sigalgs_list(ctx, conf_sigalgs)) {
memprintf(err, "%sProxy '%s': unable to set SSL Signature Algorithm list to '%s' for bind '%s' at [%s:%d].\n",
err && *err ? *err : "", curproxy->id, conf_sigalgs, bind_conf->arg, bind_conf->file, bind_conf->line);
cfgerr |= ERR_ALERT | ERR_FATAL;
}
}
#endif
MINOR: ssl: allow to change the signature algorithm for client authentication This commit introduces the keyword "client-sigalgs" for the bind line, which does the same as "sigalgs" but for the client authentication. "ssl-default-bind-client-sigalgs" allows to set the default parameter for all the bind lines. This patch should fix issue #2081.
2023-05-04 18:05:46 -04:00
#if defined(SSL_CTX_set1_client_sigalgs_list)
conf_client_sigalgs = (ssl_conf && ssl_conf->client_sigalgs) ? ssl_conf->client_sigalgs : bind_conf->ssl_conf.client_sigalgs;
if (conf_client_sigalgs) {
if (!SSL_CTX_set1_client_sigalgs_list(ctx, conf_client_sigalgs)) {
memprintf(err, "%sProxy '%s': unable to set SSL Signature Algorithm list to '%s' for bind '%s' at [%s:%d].\n",
err && *err ? *err : "", curproxy->id, conf_client_sigalgs, bind_conf->arg, bind_conf->file, bind_conf->line);
cfgerr |= ERR_ALERT | ERR_FATAL;
}
}
#endif
MINOR: quic: Initialize TLS contexts for QUIC openssl wrapper When the QUIC OpenSSL wrapper use is enabled, all the TLS contexts (SSL_CTX) must be configured to support it. This is done calling quic_tls_compat_init() from ssl_sock_prepare_ctx(). Note that quic_tls_compat_init() ignore the TLS context which are not linked to non-QUIC TLS sessions/connections. Required for the QUIC openssl wrapper support.
2023-06-07 05:19:51 -04:00
#ifdef USE_QUIC_OPENSSL_COMPAT
if (!quic_tls_compat_init(bind_conf, ctx))
cfgerr |= ERR_ALERT | ERR_FATAL;
#endif
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
return cfgerr;
}
MEDIUM: ssl: Chain ckch instances in ca-file entries Each ca-file entry of the tree will now hold a list of the ckch instances that use it so that we can iterate over them when updating the ca-file via a cli command. Since the link between the SSL contexts and the CA file tree entries is only built during the ssl_sock_prepare_ctx function, which are called after all the ckch instances are created, we need to add a little post processing after each ssl_sock_prepare_ctx that builds the link between the corresponding ckch instance and CA file tree entries. In order to manage the ca-file and ca-verify-file options, any ckch instance can be linked to multiple CA file tree entries and any CA file entry can link multiple ckch instances. This is done thanks to a dedicated list of ckch_inst references stored in the CA file tree entries over which we can iterate (during an update for instance). We avoid having one of those instances go stale by keeping a list of references to those references in the instances. When deleting a ckch_inst, we can then remove all the ckch_inst_link instances that reference it, and when deleting a cafile_entry, we iterate over the list of ckch_inst reference and clear the corresponding entry in their own list of ckch_inst_link references.
2021-02-19 11:41:55 -05:00
/*
* Prepare the SSL_CTX based on the bind line configuration.
* Since the CA file loading is made depending on the verify option of the bind
* line, the link between the SSL_CTX and the CA file tree entry is made here.
* If we want to create a link between the CA file entry and the corresponding
* ckch instance (for CA file hot update), it needs to be done after
* ssl_sock_prepare_ctx.
* Returns 0 in case of success.
*/
int ssl_sock_prep_ctx_and_inst(struct bind_conf *bind_conf, struct ssl_bind_conf *ssl_conf,
SSL_CTX *ctx, struct ckch_inst *ckch_inst, char **err)
{
int errcode = 0;
errcode |= ssl_sock_prepare_ctx(bind_conf, ssl_conf, ctx, err);
if (!errcode && ckch_inst)
ckch_inst_add_cafile_link(ckch_inst, bind_conf, ssl_conf, NULL);
return errcode;
}
MINOR: ssl: Add statement 'verifyhost' to "server" statements verifyhost allows you to specify a hostname that the remote server's SSL certificate must match. Connections that don't match will be closed with an SSL error.
2013-06-27 03:05:25 -04:00
static int ssl_sock_srv_hostcheck(const char *pattern, const char *hostname)
{
const char *pattern_wildcard, *pattern_left_label_end, *hostname_left_label_end;
size_t prefixlen, suffixlen;
/* Trivial case */
BUG/MINOR: ssl: verifyhost is case sensitive In bug #835, @arjenzorgdoc reported that the verifyhost option on the server line is case-sensitive, that shouldn't be the case. This patch fixes the issue by replacing memcmp by strncasecmp and strcmp by strcasecmp. The patch was suggested by @arjenzorgdoc. This must be backported in all versions supporting the verifyhost option.
2020-09-14 09:20:10 -04:00
if (strcasecmp(pattern, hostname) == 0)
MINOR: ssl: Add statement 'verifyhost' to "server" statements verifyhost allows you to specify a hostname that the remote server's SSL certificate must match. Connections that don't match will be closed with an SSL error.
2013-06-27 03:05:25 -04:00
return 1;
/* The rest of this logic is based on RFC 6125, section 6.4.3
* (http://tools.ietf.org/html/rfc6125#section-6.4.3) */
MINOR: ssl: optimization of verifyhost on wildcard certificates. Optimizes verifyhost on wildcard certificates avoiding travel several times the same string.
2013-10-08 05:27:28 -04:00
pattern_wildcard = NULL;
pattern_left_label_end = pattern;
while (*pattern_left_label_end != '.') {
switch (*pattern_left_label_end) {
case 0:
/* End of label not found */
return 0;
case '*':
/* If there is more than one wildcards */
if (pattern_wildcard)
return 0;
pattern_wildcard = pattern_left_label_end;
break;
}
pattern_left_label_end++;
}
/* If it's not trivial and there is no wildcard, it can't
* match */
if (!pattern_wildcard)
MINOR: ssl: Add statement 'verifyhost' to "server" statements verifyhost allows you to specify a hostname that the remote server's SSL certificate must match. Connections that don't match will be closed with an SSL error.
2013-06-27 03:05:25 -04:00
return 0;
/* Make sure all labels match except the leftmost */
hostname_left_label_end = strchr(hostname, '.');
if (!hostname_left_label_end
BUG/MINOR: ssl: verifyhost is case sensitive In bug #835, @arjenzorgdoc reported that the verifyhost option on the server line is case-sensitive, that shouldn't be the case. This patch fixes the issue by replacing memcmp by strncasecmp and strcmp by strcasecmp. The patch was suggested by @arjenzorgdoc. This must be backported in all versions supporting the verifyhost option.
2020-09-14 09:20:10 -04:00
|| strcasecmp(pattern_left_label_end, hostname_left_label_end) != 0)
MINOR: ssl: Add statement 'verifyhost' to "server" statements verifyhost allows you to specify a hostname that the remote server's SSL certificate must match. Connections that don't match will be closed with an SSL error.
2013-06-27 03:05:25 -04:00
return 0;
/* Make sure the leftmost label of the hostname is long enough
* that the wildcard can match */
BUG/MINOR: ssl: verifyhost does not match empty strings on wildcard. RFC6125 does not specify if wildcard matches empty strings but classical browsers implementations does. After the fix foo*bar.exemple.om matches foobar.exemple.com.
2013-10-08 05:39:35 -04:00
if (hostname_left_label_end - hostname < (pattern_left_label_end - pattern) - 1)
MINOR: ssl: Add statement 'verifyhost' to "server" statements verifyhost allows you to specify a hostname that the remote server's SSL certificate must match. Connections that don't match will be closed with an SSL error.
2013-06-27 03:05:25 -04:00
return 0;
/* Finally compare the string on either side of the
* wildcard */
prefixlen = pattern_wildcard - pattern;
suffixlen = pattern_left_label_end - (pattern_wildcard + 1);
BUG/MINOR: ssl: verifyhost is case sensitive In bug #835, @arjenzorgdoc reported that the verifyhost option on the server line is case-sensitive, that shouldn't be the case. This patch fixes the issue by replacing memcmp by strncasecmp and strcmp by strcasecmp. The patch was suggested by @arjenzorgdoc. This must be backported in all versions supporting the verifyhost option.
2020-09-14 09:20:10 -04:00
if ((prefixlen && (strncasecmp(pattern, hostname, prefixlen) != 0))
|| (suffixlen && (strncasecmp(pattern_wildcard + 1, hostname_left_label_end - suffixlen, suffixlen) != 0)))
MINOR: ssl: Add statement 'verifyhost' to "server" statements verifyhost allows you to specify a hostname that the remote server's SSL certificate must match. Connections that don't match will be closed with an SSL error.
2013-06-27 03:05:25 -04:00
return 0;
return 1;
}
static int ssl_sock_srv_verifycbk(int ok, X509_STORE_CTX *ctx)
{
SSL *ssl;
struct connection *conn;
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
struct ssl_sock_ctx *ssl_ctx;
MINOR: ssl: compare server certificate names to the SNI on outgoing connections When support for passing SNI to the server was added in 1.6-dev3, there was no way to validate that the certificate presented by the server would really match the name requested in the SNI, which is quite a problem as it allows other (valid) certificates to be presented instead (when hitting the wrong server or due to a man in the middle). This patch adds the missing check against the value passed in the SNI. The "verifyhost" value keeps precedence if set. If no SNI is used and no verifyhost directive is specified, then the certificate name is not checked (this is unchanged). In order to extract the SNI value, it was necessary to make use of SSL_SESSION_get0_hostname(), which appeared in openssl 1.1.0. This is a trivial function which returns the value of s->tlsext_hostname, so it was provided in the compat layer for older versions. After some refinements from Emmanuel, it now builds with openssl 1.0.2, openssl 1.1.0 and boringssl. A test file was provided to ease testing all cases. After some careful observation period it may make sense to backport this to 1.7 and 1.6 as some users rightfully consider this limitation as a bug. Cc: Emmanuel Hocdet <manu@gandi.net> Signed-off-by: Willy Tarreau <w@1wt.eu>
2017-07-05 12:23:03 -04:00
const char *servername;
MINOR: ssl: add a new error codes for wrong server certificates If a server presents an unexpected certificate to haproxy, that is, a certificate that doesn't match the expected name as configured in verifyhost or as requested using SNI, we want to store that precious information. Fortunately we have access to the connection in the verification callback so it's possible to store an error code there. For this purpose we use CO_ER_SSL_MISMATCH_SNI (for when the cert name didn't match the one requested using SNI) and CO_ER_SSL_MISMATCH for when it doesn't match verifyhost.
2017-07-26 14:09:56 -04:00
const char *sni;
MINOR: ssl: Add statement 'verifyhost' to "server" statements verifyhost allows you to specify a hostname that the remote server's SSL certificate must match. Connections that don't match will be closed with an SSL error.
2013-06-27 03:05:25 -04:00
int depth;
X509 *cert;
STACK_OF(GENERAL_NAME) *alt_names;
int i;
X509_NAME *cert_subject;
char *str;
if (ok == 0)
return ok;
ssl = X509_STORE_CTX_get_ex_data(ctx, SSL_get_ex_data_X509_STORE_CTX_idx());
BUG/MAJOR: ssl: OpenSSL context is stored in non-reserved memory slot We never saw unexplicated crash with SSL, so I suppose that we are luck, or the slot 0 is always reserved. Anyway the usage of the macro SSL_get_app_data() and SSL_set_app_data() seem wrong. This patch change the deprecated functions SSL_get_app_data() and SSL_set_app_data() by the new functions SSL_get_ex_data() and SSL_set_ex_data(), and it reserves the slot in the SSL memory space. For information, this is the two declaration which seems wrong or incomplete in the OpenSSL ssl.h file. We can see the usage of the slot 0 whoch is hardcoded, but never reserved. #define SSL_set_app_data(s,arg) (SSL_set_ex_data(s,0,(char *)arg)) #define SSL_get_app_data(s) (SSL_get_ex_data(s,0)) This patch must be backported at least in 1.8, maybe in other versions.
2018-06-17 15:37:05 -04:00
conn = SSL_get_ex_data(ssl, ssl_app_data_index);
BUILD: ssl: add an unchecked version of __conn_get_ssl_sock_ctx() First gcc, then now coverity report possible null derefs in situations where we know these cannot happen since we call the functions in contexts that guarantee the existence of the connection and the method used. Let's introduce an unchecked version of the function for such cases, just like we had to do with objt_*. This allows us to remove the ALREADY_CHECKED() statements (which coverity doesn't see), and addresses github issues #1643, #1644, #1647.
2022-04-12 01:31:06 -04:00
ssl_ctx = __conn_get_ssl_sock_ctx(conn);
MINOR: ssl: Add statement 'verifyhost' to "server" statements verifyhost allows you to specify a hostname that the remote server's SSL certificate must match. Connections that don't match will be closed with an SSL error.
2013-06-27 03:05:25 -04:00
BUG/MINOR: ssl: make use of the name in SNI before verifyhost Commit 2ab8867 ("MINOR: ssl: compare server certificate names to the SNI on outgoing connections") introduced the ability to check server cert names against the name provided with in the SNI, but verifyhost was kept as a way to force the name to check against. This was a mistake, because : - if an SNI is used, any static hostname in verifyhost will be wrong ; worse, if it matches and doesn't match the SNI, the server presented the wrong certificate ; - there's no way to have a default name to check against for health checks anymore because the point above mandates the removal of the verifyhost directive This patch reverses the ordering of the check : whenever SNI is used, the name provided always has precedence (ie the server must always present a certificate that matches the requested name). And if no SNI is provided, then verifyhost is used, and will be configured to match the server's default certificate name. This will work both when SNI is not used and for health checks. If the commit 2ab8867 is backported in 1.7 and/or 1.6, this one must be backported too.
2017-07-28 05:38:41 -04:00
/* We're checking if the provided hostnames match the desired one. The
* desired hostname comes from the SNI we presented if any, or if not
* provided then it may have been explicitly stated using a "verifyhost"
* directive. If neither is set, we don't care about the name so the
* verification is OK.
MINOR: ssl: compare server certificate names to the SNI on outgoing connections When support for passing SNI to the server was added in 1.6-dev3, there was no way to validate that the certificate presented by the server would really match the name requested in the SNI, which is quite a problem as it allows other (valid) certificates to be presented instead (when hitting the wrong server or due to a man in the middle). This patch adds the missing check against the value passed in the SNI. The "verifyhost" value keeps precedence if set. If no SNI is used and no verifyhost directive is specified, then the certificate name is not checked (this is unchanged). In order to extract the SNI value, it was necessary to make use of SSL_SESSION_get0_hostname(), which appeared in openssl 1.1.0. This is a trivial function which returns the value of s->tlsext_hostname, so it was provided in the compat layer for older versions. After some refinements from Emmanuel, it now builds with openssl 1.0.2, openssl 1.1.0 and boringssl. A test file was provided to ease testing all cases. After some careful observation period it may make sense to backport this to 1.7 and 1.6 as some users rightfully consider this limitation as a bug. Cc: Emmanuel Hocdet <manu@gandi.net> Signed-off-by: Willy Tarreau <w@1wt.eu>
2017-07-05 12:23:03 -04:00
*/
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
servername = SSL_get_servername(ssl_ctx->ssl, TLSEXT_NAMETYPE_host_name);
MINOR: ssl: add a new error codes for wrong server certificates If a server presents an unexpected certificate to haproxy, that is, a certificate that doesn't match the expected name as configured in verifyhost or as requested using SNI, we want to store that precious information. Fortunately we have access to the connection in the verification callback so it's possible to store an error code there. For this purpose we use CO_ER_SSL_MISMATCH_SNI (for when the cert name didn't match the one requested using SNI) and CO_ER_SSL_MISMATCH for when it doesn't match verifyhost.
2017-07-26 14:09:56 -04:00
sni = servername;
MINOR: ssl: compare server certificate names to the SNI on outgoing connections When support for passing SNI to the server was added in 1.6-dev3, there was no way to validate that the certificate presented by the server would really match the name requested in the SNI, which is quite a problem as it allows other (valid) certificates to be presented instead (when hitting the wrong server or due to a man in the middle). This patch adds the missing check against the value passed in the SNI. The "verifyhost" value keeps precedence if set. If no SNI is used and no verifyhost directive is specified, then the certificate name is not checked (this is unchanged). In order to extract the SNI value, it was necessary to make use of SSL_SESSION_get0_hostname(), which appeared in openssl 1.1.0. This is a trivial function which returns the value of s->tlsext_hostname, so it was provided in the compat layer for older versions. After some refinements from Emmanuel, it now builds with openssl 1.0.2, openssl 1.1.0 and boringssl. A test file was provided to ease testing all cases. After some careful observation period it may make sense to backport this to 1.7 and 1.6 as some users rightfully consider this limitation as a bug. Cc: Emmanuel Hocdet <manu@gandi.net> Signed-off-by: Willy Tarreau <w@1wt.eu>
2017-07-05 12:23:03 -04:00
if (!servername) {
BUILD: ssl_sock: remove build warnings on potential null-derefs When building with -Wnull-dereferences, gcc sees some cases where a pointer is dereferenced after a check may set it to null. While all of these are already guarded by either a preliminary test or the code's construction (eg: listeners code being called only on listeners), it cannot be blamed for not "seeing" this, so better use the unguarded calls everywhere this happens, particularly after checks. This is a step towards building with -Wextra.
2018-09-20 04:57:52 -04:00
servername = __objt_server(conn->target)->ssl_ctx.verify_host;
MINOR: ssl: compare server certificate names to the SNI on outgoing connections When support for passing SNI to the server was added in 1.6-dev3, there was no way to validate that the certificate presented by the server would really match the name requested in the SNI, which is quite a problem as it allows other (valid) certificates to be presented instead (when hitting the wrong server or due to a man in the middle). This patch adds the missing check against the value passed in the SNI. The "verifyhost" value keeps precedence if set. If no SNI is used and no verifyhost directive is specified, then the certificate name is not checked (this is unchanged). In order to extract the SNI value, it was necessary to make use of SSL_SESSION_get0_hostname(), which appeared in openssl 1.1.0. This is a trivial function which returns the value of s->tlsext_hostname, so it was provided in the compat layer for older versions. After some refinements from Emmanuel, it now builds with openssl 1.0.2, openssl 1.1.0 and boringssl. A test file was provided to ease testing all cases. After some careful observation period it may make sense to backport this to 1.7 and 1.6 as some users rightfully consider this limitation as a bug. Cc: Emmanuel Hocdet <manu@gandi.net> Signed-off-by: Willy Tarreau <w@1wt.eu>
2017-07-05 12:23:03 -04:00
if (!servername)
return ok;
}
MINOR: ssl: Add statement 'verifyhost' to "server" statements verifyhost allows you to specify a hostname that the remote server's SSL certificate must match. Connections that don't match will be closed with an SSL error.
2013-06-27 03:05:25 -04:00
/* We only need to verify the CN on the actual server cert,
* not the indirect CAs */
depth = X509_STORE_CTX_get_error_depth(ctx);
if (depth != 0)
return ok;
/* At this point, the cert is *not* OK unless we can find a
* hostname match */
ok = 0;
cert = X509_STORE_CTX_get_current_cert(ctx);
/* It seems like this might happen if verify peer isn't set */
if (!cert)
return ok;
alt_names = X509_get_ext_d2i(cert, NID_subject_alt_name, NULL, NULL);
if (alt_names) {
for (i = 0; !ok && i < sk_GENERAL_NAME_num(alt_names); i++) {
GENERAL_NAME *name = sk_GENERAL_NAME_value(alt_names, i);
if (name->type == GEN_DNS) {
CLEANUP: ssl-sock: use HA_OPENSSL_VERSION_NUMBER instead of OPENSSL_VERSION_NUMBER Most tests on OPENSSL_VERSION_NUMBER have become complex and break all the time because this number is fake for some derivatives like LibreSSL. This patch creates a new macro, HA_OPENSSL_VERSION_NUMBER, which will carry the real openssl version defining the compatibility level, and this version will be adjusted depending on the variants.
2019-05-09 07:26:41 -04:00
#if HA_OPENSSL_VERSION_NUMBER < 0x00907000L
BUILD: ssl: compilation issue with openssl v0.9.6. Failed to compile with openssl 0.9.6 since the 'verifyhost' feature.
2013-09-17 09:47:48 -04:00
if (ASN1_STRING_to_UTF8((unsigned char **)&str, name->d.ia5) >= 0) {
#else
MINOR: ssl: Add statement 'verifyhost' to "server" statements verifyhost allows you to specify a hostname that the remote server's SSL certificate must match. Connections that don't match will be closed with an SSL error.
2013-06-27 03:05:25 -04:00
if (ASN1_STRING_to_UTF8((unsigned char **)&str, name->d.dNSName) >= 0) {
BUILD: ssl: compilation issue with openssl v0.9.6. Failed to compile with openssl 0.9.6 since the 'verifyhost' feature.
2013-09-17 09:47:48 -04:00
#endif
MINOR: ssl: Add statement 'verifyhost' to "server" statements verifyhost allows you to specify a hostname that the remote server's SSL certificate must match. Connections that don't match will be closed with an SSL error.
2013-06-27 03:05:25 -04:00
ok = ssl_sock_srv_hostcheck(str, servername);
OPENSSL_free(str);
}
}
}
BUG/MEDIUM: ssl: potential memory leak using verifyhost If server certificate presents dns aliases, a memory leak appears on health checks when 'verifyhost' statement is used.
2013-09-17 09:19:54 -04:00
sk_GENERAL_NAME_pop_free(alt_names, GENERAL_NAME_free);
MINOR: ssl: Add statement 'verifyhost' to "server" statements verifyhost allows you to specify a hostname that the remote server's SSL certificate must match. Connections that don't match will be closed with an SSL error.
2013-06-27 03:05:25 -04:00
}
cert_subject = X509_get_subject_name(cert);
i = -1;
while (!ok && (i = X509_NAME_get_index_by_NID(cert_subject, NID_commonName, i)) != -1) {
X509_NAME_ENTRY *entry = X509_NAME_get_entry(cert_subject, i);
MEDIUM: ssl: Add support for OpenSSL 1.1.0 In the last release a lot of the structures have become opaque for an end user. This means the code using these needs to be changed to use the proper functions to interact with these structures instead of trying to manipulate them directly. This does not fix any deprecations yet that are part of 1.1.0, it only ensures that it can be compiled against that version and is still compatible with older ones. [wt: openssl-0.9.8 doesn't build with it, there are conflicts on certain function prototypes which we declare as inline here and which are defined differently there. But openssl-0.9.8 is not supported anymore so probably it's OK to go without it for now and we'll see later if some users still need it. Emeric has reviewed this change and didn't spot anything obvious which requires special care. Let's try it for real now]
2016-08-29 07:26:37 -04:00
ASN1_STRING *value;
value = X509_NAME_ENTRY_get_data(entry);
if (ASN1_STRING_to_UTF8((unsigned char **)&str, value) >= 0) {
MINOR: ssl: Add statement 'verifyhost' to "server" statements verifyhost allows you to specify a hostname that the remote server's SSL certificate must match. Connections that don't match will be closed with an SSL error.
2013-06-27 03:05:25 -04:00
ok = ssl_sock_srv_hostcheck(str, servername);
OPENSSL_free(str);
}
}
MINOR: ssl: add a new error codes for wrong server certificates If a server presents an unexpected certificate to haproxy, that is, a certificate that doesn't match the expected name as configured in verifyhost or as requested using SNI, we want to store that precious information. Fortunately we have access to the connection in the verification callback so it's possible to store an error code there. For this purpose we use CO_ER_SSL_MISMATCH_SNI (for when the cert name didn't match the one requested using SNI) and CO_ER_SSL_MISMATCH for when it doesn't match verifyhost.
2017-07-26 14:09:56 -04:00
/* report the mismatch and indicate if SNI was used or not */
if (!ok && !conn->err_code)
conn->err_code = sni ? CO_ER_SSL_MISMATCH_SNI : CO_ER_SSL_MISMATCH;
MINOR: ssl: Add statement 'verifyhost' to "server" statements verifyhost allows you to specify a hostname that the remote server's SSL certificate must match. Connections that don't match will be closed with an SSL error.
2013-06-27 03:05:25 -04:00
return ok;
}
MINOR: ssl: move ssl context init for servers from cfgparse.c to ssl_sock.c
2012-10-11 08:00:19 -04:00
/* prepare ssl context from servers options. Returns an error count */
MEDIUM: ssl: remote the proxy argument from most functions Most of the SSL functions used to have a proxy argument which was mostly used to be able to emit clean errors using Alert(). First, many of them were converted to memprintf() and don't require this pointer anymore. Second, the rare which still need it also have either a bind_conf argument or a server argument, both of which carry a pointer to the relevant proxy. So let's now get rid of it, it needlessly complicates the API and certain functions already have many arguments.
2016-12-22 11:08:28 -05:00
int ssl_sock_prepare_srv_ctx(struct server *srv)
MINOR: ssl: move ssl context init for servers from cfgparse.c to ssl_sock.c
2012-10-11 08:00:19 -04:00
{
int cfgerr = 0;
BUG/MEDIUM: ssl: initialize correctly ssl w/ default-server This bug was introduced by d817dc73 ("MEDIUM: ssl: Load client certificates in a ckch for backend servers") in which the creation of the SSL_CTX for a server was moved to the configuration parser when using a "crt" keyword instead of being done in ssl_sock_prepare_srv_ctx(). The patch 0498fa40 ("BUG/MINOR: ssl: Default-server configuration ignored by server") made it worse by setting the same SSL_CTX for every servers using a default-server. Resulting in any SSL option on a server applied to every server in its backend. This patch fixes the issue by reintroducing a string which store the path of certificate inside the server structure, and loading the certificate in ssl_sock_prepare_srv_ctx() again. This is a quick fix to backport, a cleaner way can be achieve by always creating the SSL_CTX in ssl_sock_prepare_srv_ctx() and splitting properly the ssl_sock_load_srv_cert() function. This patch fixes issue #1488. Must be backported as far as 2.4.
2021-12-28 12:47:17 -05:00
SSL_CTX *ctx;
BUG/MINOR: startup: don't use internal proxies to compute the maxconn With internal proxies using the SSL activated (httpclient for example) the automatic computation of the maxconn is wrong because these proxies are always activated by default. This patch fixes the issue by not counting these internal proxies during the computation. Must be backported as far as 2.5.
2022-12-13 12:17:44 -05:00
/* Automatic memory computations need to know we use SSL there
* If this is an internal proxy, don't use it for the computation */
CLEANUP: ssl: remove check on srv->proxy Remove a useless check on srv->proxy which triggers coverity. Should fix issue #1965.
2022-12-14 04:34:36 -05:00
if (!(srv->proxy->cap & PR_CAP_INT))
BUG/MINOR: startup: don't use internal proxies to compute the maxconn With internal proxies using the SSL activated (httpclient for example) the automatic computation of the maxconn is wrong because these proxies are always activated by default. This patch fixes the issue by not counting these internal proxies during the computation. Must be backported as far as 2.5.
2022-12-13 12:17:44 -05:00
global.ssl_used_backend = 1;
MINOR: global: always export some SSL-specific metrics We'll need to know the number of SSL connections, their use and their cost soon. In order to avoid getting tons of ifdefs everywhere, always export SSL information in the global section. We add two flags to know whether or not SSL is used in a frontend and in a backend.
2015-01-15 15:32:40 -05:00
/* Initiate SSL context for current server */
MAJOR: threads/ssl: Make SSL part thread-safe First, OpenSSL is now initialized to be thread-safe. This is done by setting 2 callbacks. The first one is ssl_locking_function. It handles the locks and unlocks. The second one is ssl_id_function. It returns the current thread id. During the init step, we create as much as R/W locks as needed, ie the number returned by CRYPTO_num_locks function. Next, The reusable SSL session in the server context is now thread-local. Shctx is now also initialized if HAProxy is started with several threads. And finally, a global lock has been added to protect the LRU cache used to store generated certificates. The function ssl_sock_get_generated_cert is now deprecated because the retrieved certificate can be removed by another threads in same time. Instead, a new function has been added, ssl_sock_assign_generated_cert. It must be used to search a certificate in the cache and set it immediatly if found.
2017-06-15 10:37:39 -04:00
if (!srv->ssl_ctx.reused_sess) {
MINOR: SSL: Store the ASN1 representation of client sessions. Instead of storing the SSL_SESSION pointer directly in the struct server, store the ASN1 representation, otherwise, session resumption is broken with TLS 1.3, when multiple outgoing connections want to use the same session.
2017-11-16 11:42:52 -05:00
if ((srv->ssl_ctx.reused_sess = calloc(1, global.nbthread*sizeof(*srv->ssl_ctx.reused_sess))) == NULL) {
REORG: config: use parsing ctx for server config check Initialize the parsing context when checking server config validity. Adjust the log messages to remove redundant config file/line and server name. Do a similar cleaning in prepare_srv from ssl_sock as this function is called at the same stage. This will standardize the stderr output on startup with the parse_server function.
2021-05-28 04:34:01 -04:00
ha_alert("out of memory.\n");
MAJOR: threads/ssl: Make SSL part thread-safe First, OpenSSL is now initialized to be thread-safe. This is done by setting 2 callbacks. The first one is ssl_locking_function. It handles the locks and unlocks. The second one is ssl_id_function. It returns the current thread id. During the init step, we create as much as R/W locks as needed, ie the number returned by CRYPTO_num_locks function. Next, The reusable SSL session in the server context is now thread-local. Shctx is now also initialized if HAProxy is started with several threads. And finally, a global lock has been added to protect the LRU cache used to store generated certificates. The function ssl_sock_get_generated_cert is now deprecated because the retrieved certificate can be removed by another threads in same time. Instead, a new function has been added, ssl_sock_assign_generated_cert. It must be used to search a certificate in the cache and set it immediatly if found.
2017-06-15 10:37:39 -04:00
cfgerr++;
return cfgerr;
}
}
BUG/MINOR: checks: Respect the no-check-ssl option This options is used to force a non-SSL connection to check a SSL server or to invert a check-ssl option inherited from the default section. The use_ssl field in the check structure is used to know if a SSL connection must be used (use_ssl=1) or not (use_ssl=0). The server configuration is used by default. The problem is that we cannot distinguish the default case (no specific SSL check option) and the case of an explicit non-SSL check. In both, use_ssl is set to 0. So the server configuration is always used. For a SSL server, when no-check-ssl option is set, the check is still performed using a SSL configuration. To fix the bug, instead of a boolean value (0=TCP, 1=SSL), we use a ternary value : * 0 = use server config * 1 = force SSL * -1 = force non-SSL The same is done for the server parameter. It is not really necessary for now. But it is a good way to know is the server no-ssl option is set. In addition, the PR_O_TCPCHK_SSL proxy option is no longer used to set use_ssl to 1 for a check. Instead the flag is directly tested to prepare or destroy the server SSL context. This patch should be backported as far as 1.8.
2020-03-27 13:55:49 -04:00
if (srv->use_ssl == 1)
MINOR: ssl: move ssl context init for servers from cfgparse.c to ssl_sock.c
2012-10-11 08:00:19 -04:00
srv->xprt = &ssl_sock;
BUG/MEDIUM: ssl: initialize correctly ssl w/ default-server This bug was introduced by d817dc73 ("MEDIUM: ssl: Load client certificates in a ckch for backend servers") in which the creation of the SSL_CTX for a server was moved to the configuration parser when using a "crt" keyword instead of being done in ssl_sock_prepare_srv_ctx(). The patch 0498fa40 ("BUG/MINOR: ssl: Default-server configuration ignored by server") made it worse by setting the same SSL_CTX for every servers using a default-server. Resulting in any SSL option on a server applied to every server in its backend. This patch fixes the issue by reintroducing a string which store the path of certificate inside the server structure, and loading the certificate in ssl_sock_prepare_srv_ctx() again. This is a quick fix to backport, a cleaner way can be achieve by always creating the SSL_CTX in ssl_sock_prepare_srv_ctx() and splitting properly the ssl_sock_load_srv_cert() function. This patch fixes issue #1488. Must be backported as far as 2.4.
2021-12-28 12:47:17 -05:00
if (srv->ssl_ctx.client_crt) {
const int create_if_none = srv->flags & SRV_F_DYNAMIC ? 0 : 1;
char *err = NULL;
int err_code = 0;
/* If there is a crt keyword there, the SSL_CTX will be created here. */
err_code = ssl_sock_load_srv_cert(srv->ssl_ctx.client_crt, srv, create_if_none, &err);
if (err_code != ERR_NONE) {
if ((err_code & ERR_WARN) && !(err_code & ERR_ALERT))
ha_warning("%s", err);
else
ha_alert("%s", err);
if (err_code & (ERR_FATAL|ERR_ABORT))
cfgerr++;
}
ha_free(&err);
}
ctx = srv->ssl_ctx.ctx;
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
/* The context will be uninitialized if there wasn't any "cert" option
* in the server line. */
MINOR: ssl: removes SSL_CTX_set_ssl_version call and cleanup CTX creation. BoringSSL doesn't support SSL_CTX_set_ssl_version. To remove this call, the CTX creation is cleanup to clarify what is happening. SSL_CTX_new is used to match the original behavior, in order: force-<method> according the method version then the default method with no-<method> options. OPENSSL_NO_SSL3 error message is now in force-sslv3 parsing (as force-tls*). For CTX creation in bind environement, all CTX set related to the initial ctx are aggregate to ssl_sock_new_ctx function for clarity. Tests with crt-list have shown that server_method, options and mode are linked to the initial CTX (default_ctx): all ssl-options are link to each bind line and must be removed from crt-list.
2017-03-03 06:21:32 -05:00
if (!ctx) {
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
ctx = SSL_CTX_new(SSLv23_client_method());
if (!ctx) {
REORG: config: use parsing ctx for server config check Initialize the parsing context when checking server config validity. Adjust the log messages to remove redundant config file/line and server name. Do a similar cleaning in prepare_srv from ssl_sock as this function is called at the same stage. This will standardize the stderr output on startup with the parse_server function.
2021-05-28 04:34:01 -04:00
ha_alert("unable to allocate ssl context.\n");
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
cfgerr++;
return cfgerr;
}
MEDIUM: ssl: allow to change the OpenSSL security level from global section The new "ssl-security-level" option allows one to change the OpenSSL security level without having to change the openssl.cnf global file of your distribution. This directives applies on every SSL_CTX context. People sometimes change their security level directly in the ciphers directive, however there are some cases when the security level change is not applied in the right order (for example when applying a DH param). Before this patch, it was to possible to trick by using a specific openssl.cnf file and start haproxy this way: OPENSSL_CONF=./openssl.cnf ./haproxy -f bug-2468.cfg Values for the security level can be found there: https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_security_level.html This was discussed in github issue #2468.
2024-03-12 11:22:34 -04:00
if (global_ssl.security_level > -1)
SSL_CTX_set_security_level(ctx, global_ssl.security_level);
MEDIUM: ssl: ssl_methods implementation is reworked and factored for min/max tlsxx Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. This patch introduce internal min/max and replace force-tlsxx implementation. SSL method configuration is store in 'struct tls_version_filter'. SSL method configuration to openssl setting is abstract in 'methodVersions' table. With openssl < 1.1.0, SSL_CTX_set_ssl_version is used for force (min == max). With openssl >= 1.1.0, SSL_CTX_set_min/max_proto_version is used.
2017-03-30 13:19:37 -04:00
MEDIUM: ssl: Load client certificates in a ckch for backend servers In order for the backend server's certificate to be hot-updatable, it needs to fit into the implementation used for the "bind" certificates. This patch follows the architecture implemented for the frontend implementation and reuses its structures and general function calls (adapted for the server side). The ckch store logic is kept and a dedicated ckch instance is used (one per server). The whole sni_ctx logic was not kept though because it is not needed. All the new functions added in this patch are basically server-side copies of functions that already exist on the frontend side with all the sni and bind_cond references removed. The ckch_inst structure has a new 'is_server_instance' flag which is used to distinguish regular instances from the server-side ones, and a new pointer to the server's structure in case of backend instance. Since the new server ckch instances are linked to a standard ckch_store, a lookup in the ckch store table will succeed so the cli code used to update bind certificates needs to be covered to manage those new server side ckch instances.
2021-01-25 11:19:43 -05:00
srv->ssl_ctx.ctx = ctx;
}
MINOR: ssl: Server ssl context prepare function refactoring Split the server's ssl context initialization into the general ssl related initializations and the actual initialization of a single SSL_CTX structure. This way the context's initialization will be usable by itself from elsewhere.
2021-01-25 11:19:41 -05:00
MEDIUM: ssl: Chain ckch instances in ca-file entries Each ca-file entry of the tree will now hold a list of the ckch instances that use it so that we can iterate over them when updating the ca-file via a cli command. Since the link between the SSL contexts and the CA file tree entries is only built during the ssl_sock_prepare_ctx function, which are called after all the ckch instances are created, we need to add a little post processing after each ssl_sock_prepare_ctx that builds the link between the corresponding ckch instance and CA file tree entries. In order to manage the ca-file and ca-verify-file options, any ckch instance can be linked to multiple CA file tree entries and any CA file entry can link multiple ckch instances. This is done thanks to a dedicated list of ckch_inst references stored in the CA file tree entries over which we can iterate (during an update for instance). We avoid having one of those instances go stale by keeping a list of references to those references in the instances. When deleting a ckch_inst, we can then remove all the ckch_inst_link instances that reference it, and when deleting a cafile_entry, we iterate over the list of ckch_inst reference and clear the corresponding entry in their own list of ckch_inst_link references.
2021-02-19 11:41:55 -05:00
cfgerr += ssl_sock_prep_srv_ctx_and_inst(srv, srv->ssl_ctx.ctx, srv->ssl_ctx.inst);
MINOR: ssl: Server ssl context prepare function refactoring Split the server's ssl context initialization into the general ssl related initializations and the actual initialization of a single SSL_CTX structure. This way the context's initialization will be usable by itself from elsewhere.
2021-01-25 11:19:41 -05:00
return cfgerr;
}
/* Initialize an SSL context that will be used on the backend side.
* Returns an error count.
*/
MEDIUM: ssl: Chain ckch instances in ca-file entries Each ca-file entry of the tree will now hold a list of the ckch instances that use it so that we can iterate over them when updating the ca-file via a cli command. Since the link between the SSL contexts and the CA file tree entries is only built during the ssl_sock_prepare_ctx function, which are called after all the ckch instances are created, we need to add a little post processing after each ssl_sock_prepare_ctx that builds the link between the corresponding ckch instance and CA file tree entries. In order to manage the ca-file and ca-verify-file options, any ckch instance can be linked to multiple CA file tree entries and any CA file entry can link multiple ckch instances. This is done thanks to a dedicated list of ckch_inst references stored in the CA file tree entries over which we can iterate (during an update for instance). We avoid having one of those instances go stale by keeping a list of references to those references in the instances. When deleting a ckch_inst, we can then remove all the ckch_inst_link instances that reference it, and when deleting a cafile_entry, we iterate over the list of ckch_inst reference and clear the corresponding entry in their own list of ckch_inst_link references.
2021-02-19 11:41:55 -05:00
static int ssl_sock_prepare_srv_ssl_ctx(const struct server *srv, SSL_CTX *ctx)
MINOR: ssl: Server ssl context prepare function refactoring Split the server's ssl context initialization into the general ssl related initializations and the actual initialization of a single SSL_CTX structure. This way the context's initialization will be usable by itself from elsewhere.
2021-01-25 11:19:41 -05:00
{
struct proxy *curproxy = srv->proxy;
int cfgerr = 0;
long options =
SSL_OP_ALL | /* all known workarounds for bugs */
SSL_OP_NO_SSLv2 |
SSL_OP_NO_COMPRESSION;
long mode =
SSL_MODE_ENABLE_PARTIAL_WRITE |
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER |
SSL_MODE_RELEASE_BUFFERS |
SSL_MODE_SMALL_BUFFERS;
int verify = SSL_VERIFY_NONE;
const struct tls_version_filter *conf_ssl_methods = &srv->ssl_ctx.methods;
int i, min, max, hole;
int flags = MC_SSL_O_ALL;
MINOR: ssl: allow to change the server signature algorithm on server lines This patch introduces the "sigalgs" keyword for the server line, which allows to configure the list of server signature algorithms negociated during the handshake. Also available as "ssl-default-server-sigalgs" in the global section.
2023-06-29 07:29:59 -04:00
#if defined(SSL_CTX_set1_sigalgs_list)
const char *conf_sigalgs = NULL;
#endif
MINOR: ssl: allow to change the client-sigalgs on server lines This patch introduces the "client-sigalgs" keyword for the server line, which allows to configure the list of server signature algorithms negociated during the handshake. Also available as "ssl-default-server-client-sigalgs" in the global section.
2023-06-29 08:11:46 -04:00
#if defined(SSL_CTX_set1_client_sigalgs_list)
const char *conf_client_sigalgs = NULL;
#endif
MINOR: ssl: add support for 'curves' keyword on server lines This patch implements the 'curves' keyword on server lines as well as the 'ssl-default-server-curves' keyword in the global section. It also add the keyword on the server line in the ssl_curves reg-test. These keywords allow the configuration of the curves list for a server.
2023-09-07 17:13:15 -04:00
#if defined(SSL_CTX_set1_curves_list)
const char *conf_curves = NULL;
#endif
MINOR: ssl: Server ssl context prepare function refactoring Split the server's ssl context initialization into the general ssl related initializations and the actual initialization of a single SSL_CTX structure. This way the context's initialization will be usable by itself from elsewhere.
2021-01-25 11:19:41 -05:00
MEDIUM: ssl: ssl-min-ver and ssl-max-ver compatibility. In haproxy < 1.8, no-sslv3/no-tlsv1x are ignored when force-sslv3/force-tlsv1x is used (without warning). With this patch, no-sslv3/no-tlsv1x are ignored when ssl-min-ver or ssl-max-ver is used (with warning). When all SSL/TLS versions are disable: generate an error, not a warning. example: ssl-min-ver TLSV1.3 (or force-tlsv13) with a openssl <= 1.1.0.
2017-05-05 12:06:12 -04:00
if (conf_ssl_methods->flags && (conf_ssl_methods->min || conf_ssl_methods->max))
REORG: config: use parsing ctx for server config check Initialize the parsing context when checking server config validity. Adjust the log messages to remove redundant config file/line and server name. Do a similar cleaning in prepare_srv from ssl_sock as this function is called at the same stage. This will standardize the stderr output on startup with the parse_server function.
2021-05-28 04:34:01 -04:00
ha_warning("no-sslv3/no-tlsv1x are ignored for this server. "
"Use only 'ssl-min-ver' and 'ssl-max-ver' to fix.\n");
MEDIUM: ssl: ssl-min-ver and ssl-max-ver compatibility. In haproxy < 1.8, no-sslv3/no-tlsv1x are ignored when force-sslv3/force-tlsv1x is used (without warning). With this patch, no-sslv3/no-tlsv1x are ignored when ssl-min-ver or ssl-max-ver is used (with warning). When all SSL/TLS versions are disable: generate an error, not a warning. example: ssl-min-ver TLSV1.3 (or force-tlsv13) with a openssl <= 1.1.0.
2017-05-05 12:06:12 -04:00
else
flags = conf_ssl_methods->flags;
MEDIUM: ssl: calculate the real min/max TLS version and find holes Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. Find the real min/max versions (openssl capabilities and haproxy configuration) and generate warning with bad versions range. 'no-tlsxx' can generate 'holes': "The list of protocols available can be further limited using the SSL_OP_NO_X options of the SSL_CTX_set_options or SSL_set_options functions. Clients should avoid creating 'holes' in the set of protocols they support, when disabling a protocol, make sure that you also disable either all previous or all subsequent protocol versions. In clients, when a protocol version is disabled without disabling all previous protocol versions, the effect is to also disable all subsequent protocol versions." To not break compatibility, "holes" is authorized with warning, because openssl 1.1.0 and boringssl deal with it (keep the upper or lower range depending the case and version).
2017-03-30 13:25:07 -04:00
/* Real min and max should be determinate with configuration and openssl's capabilities */
if (conf_ssl_methods->min)
MEDIUM: ssl: ssl-min-ver and ssl-max-ver compatibility. In haproxy < 1.8, no-sslv3/no-tlsv1x are ignored when force-sslv3/force-tlsv1x is used (without warning). With this patch, no-sslv3/no-tlsv1x are ignored when ssl-min-ver or ssl-max-ver is used (with warning). When all SSL/TLS versions are disable: generate an error, not a warning. example: ssl-min-ver TLSV1.3 (or force-tlsv13) with a openssl <= 1.1.0.
2017-05-05 12:06:12 -04:00
flags |= (methodVersions[conf_ssl_methods->min].flag - 1);
MEDIUM: ssl: calculate the real min/max TLS version and find holes Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. Find the real min/max versions (openssl capabilities and haproxy configuration) and generate warning with bad versions range. 'no-tlsxx' can generate 'holes': "The list of protocols available can be further limited using the SSL_OP_NO_X options of the SSL_CTX_set_options or SSL_set_options functions. Clients should avoid creating 'holes' in the set of protocols they support, when disabling a protocol, make sure that you also disable either all previous or all subsequent protocol versions. In clients, when a protocol version is disabled without disabling all previous protocol versions, the effect is to also disable all subsequent protocol versions." To not break compatibility, "holes" is authorized with warning, because openssl 1.1.0 and boringssl deal with it (keep the upper or lower range depending the case and version).
2017-03-30 13:25:07 -04:00
if (conf_ssl_methods->max)
MEDIUM: ssl: ssl-min-ver and ssl-max-ver compatibility. In haproxy < 1.8, no-sslv3/no-tlsv1x are ignored when force-sslv3/force-tlsv1x is used (without warning). With this patch, no-sslv3/no-tlsv1x are ignored when ssl-min-ver or ssl-max-ver is used (with warning). When all SSL/TLS versions are disable: generate an error, not a warning. example: ssl-min-ver TLSV1.3 (or force-tlsv13) with a openssl <= 1.1.0.
2017-05-05 12:06:12 -04:00
flags |= ~((methodVersions[conf_ssl_methods->max].flag << 1) - 1);
MEDIUM: ssl: calculate the real min/max TLS version and find holes Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. Find the real min/max versions (openssl capabilities and haproxy configuration) and generate warning with bad versions range. 'no-tlsxx' can generate 'holes': "The list of protocols available can be further limited using the SSL_OP_NO_X options of the SSL_CTX_set_options or SSL_set_options functions. Clients should avoid creating 'holes' in the set of protocols they support, when disabling a protocol, make sure that you also disable either all previous or all subsequent protocol versions. In clients, when a protocol version is disabled without disabling all previous protocol versions, the effect is to also disable all subsequent protocol versions." To not break compatibility, "holes" is authorized with warning, because openssl 1.1.0 and boringssl deal with it (keep the upper or lower range depending the case and version).
2017-03-30 13:25:07 -04:00
MEDIUM: ssl: ctx_set_version/ssl_set_version func for methodVersions table This patch cleanup the usage of set_version func with a more suitable name: ctx_set_version. It introduce ssl_set_version func (unused for the moment).
2017-05-18 06:33:19 -04:00
/* find min, max and holes */
MEDIUM: ssl: calculate the real min/max TLS version and find holes Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. Find the real min/max versions (openssl capabilities and haproxy configuration) and generate warning with bad versions range. 'no-tlsxx' can generate 'holes': "The list of protocols available can be further limited using the SSL_OP_NO_X options of the SSL_CTX_set_options or SSL_set_options functions. Clients should avoid creating 'holes' in the set of protocols they support, when disabling a protocol, make sure that you also disable either all previous or all subsequent protocol versions. In clients, when a protocol version is disabled without disabling all previous protocol versions, the effect is to also disable all subsequent protocol versions." To not break compatibility, "holes" is authorized with warning, because openssl 1.1.0 and boringssl deal with it (keep the upper or lower range depending the case and version).
2017-03-30 13:25:07 -04:00
min = max = CONF_TLSV_NONE;
hole = 0;
MEDIUM: ssl: ssl_methods implementation is reworked and factored for min/max tlsxx Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. This patch introduce internal min/max and replace force-tlsxx implementation. SSL method configuration is store in 'struct tls_version_filter'. SSL method configuration to openssl setting is abstract in 'methodVersions' table. With openssl < 1.1.0, SSL_CTX_set_ssl_version is used for force (min == max). With openssl >= 1.1.0, SSL_CTX_set_min/max_proto_version is used.
2017-03-30 13:19:37 -04:00
for (i = CONF_TLSV_MIN; i <= CONF_TLSV_MAX; i++)
MEDIUM: ssl: calculate the real min/max TLS version and find holes Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. Find the real min/max versions (openssl capabilities and haproxy configuration) and generate warning with bad versions range. 'no-tlsxx' can generate 'holes': "The list of protocols available can be further limited using the SSL_OP_NO_X options of the SSL_CTX_set_options or SSL_set_options functions. Clients should avoid creating 'holes' in the set of protocols they support, when disabling a protocol, make sure that you also disable either all previous or all subsequent protocol versions. In clients, when a protocol version is disabled without disabling all previous protocol versions, the effect is to also disable all subsequent protocol versions." To not break compatibility, "holes" is authorized with warning, because openssl 1.1.0 and boringssl deal with it (keep the upper or lower range depending the case and version).
2017-03-30 13:25:07 -04:00
/* version is in openssl && version not disable in configuration */
MEDIUM: ssl: ssl-min-ver and ssl-max-ver compatibility. In haproxy < 1.8, no-sslv3/no-tlsv1x are ignored when force-sslv3/force-tlsv1x is used (without warning). With this patch, no-sslv3/no-tlsv1x are ignored when ssl-min-ver or ssl-max-ver is used (with warning). When all SSL/TLS versions are disable: generate an error, not a warning. example: ssl-min-ver TLSV1.3 (or force-tlsv13) with a openssl <= 1.1.0.
2017-05-05 12:06:12 -04:00
if (methodVersions[i].option && !(flags & methodVersions[i].flag)) {
MEDIUM: ssl: calculate the real min/max TLS version and find holes Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. Find the real min/max versions (openssl capabilities and haproxy configuration) and generate warning with bad versions range. 'no-tlsxx' can generate 'holes': "The list of protocols available can be further limited using the SSL_OP_NO_X options of the SSL_CTX_set_options or SSL_set_options functions. Clients should avoid creating 'holes' in the set of protocols they support, when disabling a protocol, make sure that you also disable either all previous or all subsequent protocol versions. In clients, when a protocol version is disabled without disabling all previous protocol versions, the effect is to also disable all subsequent protocol versions." To not break compatibility, "holes" is authorized with warning, because openssl 1.1.0 and boringssl deal with it (keep the upper or lower range depending the case and version).
2017-03-30 13:25:07 -04:00
if (min) {
if (hole) {
MINOR: errors: specify prefix "config" for parsing output Set "config :" as a prefix for the user messages context before starting the configuration parsing. All following stderr output will be prefixed by it. As a consequence, remove extraneous prefix "config" already specified in various ha_alert/warning/notice calls.
2021-06-04 12:22:08 -04:00
ha_warning("%s '%s': SSL/TLS versions range not contiguous for server '%s'. "
CLEANUP: log: Rename Alert/Warning in ha_alert/ha_warning
2017-11-24 10:50:31 -05:00
"Hole find for %s. Use only 'ssl-min-ver' and 'ssl-max-ver' to fix.\n",
proxy_type_str(curproxy), curproxy->id, srv->id,
methodVersions[hole].name);
MEDIUM: ssl: calculate the real min/max TLS version and find holes Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. Find the real min/max versions (openssl capabilities and haproxy configuration) and generate warning with bad versions range. 'no-tlsxx' can generate 'holes': "The list of protocols available can be further limited using the SSL_OP_NO_X options of the SSL_CTX_set_options or SSL_set_options functions. Clients should avoid creating 'holes' in the set of protocols they support, when disabling a protocol, make sure that you also disable either all previous or all subsequent protocol versions. In clients, when a protocol version is disabled without disabling all previous protocol versions, the effect is to also disable all subsequent protocol versions." To not break compatibility, "holes" is authorized with warning, because openssl 1.1.0 and boringssl deal with it (keep the upper or lower range depending the case and version).
2017-03-30 13:25:07 -04:00
hole = 0;
}
max = i;
}
else {
min = max = i;
}
}
else {
if (min)
hole = i;
}
MEDIUM: ssl: ssl-min-ver and ssl-max-ver compatibility. In haproxy < 1.8, no-sslv3/no-tlsv1x are ignored when force-sslv3/force-tlsv1x is used (without warning). With this patch, no-sslv3/no-tlsv1x are ignored when ssl-min-ver or ssl-max-ver is used (with warning). When all SSL/TLS versions are disable: generate an error, not a warning. example: ssl-min-ver TLSV1.3 (or force-tlsv13) with a openssl <= 1.1.0.
2017-05-05 12:06:12 -04:00
if (!min) {
MINOR: errors: specify prefix "config" for parsing output Set "config :" as a prefix for the user messages context before starting the configuration parsing. All following stderr output will be prefixed by it. As a consequence, remove extraneous prefix "config" already specified in various ha_alert/warning/notice calls.
2021-06-04 12:22:08 -04:00
ha_alert("%s '%s': all SSL/TLS versions are disabled for server '%s'.\n",
CLEANUP: log: Rename Alert/Warning in ha_alert/ha_warning
2017-11-24 10:50:31 -05:00
proxy_type_str(curproxy), curproxy->id, srv->id);
MEDIUM: ssl: ssl-min-ver and ssl-max-ver compatibility. In haproxy < 1.8, no-sslv3/no-tlsv1x are ignored when force-sslv3/force-tlsv1x is used (without warning). With this patch, no-sslv3/no-tlsv1x are ignored when ssl-min-ver or ssl-max-ver is used (with warning). When all SSL/TLS versions are disable: generate an error, not a warning. example: ssl-min-ver TLSV1.3 (or force-tlsv13) with a openssl <= 1.1.0.
2017-05-05 12:06:12 -04:00
cfgerr += 1;
}
MEDIUM: ssl: ssl_methods implementation is reworked and factored for min/max tlsxx Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. This patch introduce internal min/max and replace force-tlsxx implementation. SSL method configuration is store in 'struct tls_version_filter'. SSL method configuration to openssl setting is abstract in 'methodVersions' table. With openssl < 1.1.0, SSL_CTX_set_ssl_version is used for force (min == max). With openssl >= 1.1.0, SSL_CTX_set_min/max_proto_version is used.
2017-03-30 13:19:37 -04:00
CLEANUP: ssl-sock: use HA_OPENSSL_VERSION_NUMBER instead of OPENSSL_VERSION_NUMBER Most tests on OPENSSL_VERSION_NUMBER have become complex and break all the time because this number is fake for some derivatives like LibreSSL. This patch creates a new macro, HA_OPENSSL_VERSION_NUMBER, which will carry the real openssl version defining the compatibility level, and this version will be adjusted depending on the variants.
2019-05-09 07:26:41 -04:00
#if (HA_OPENSSL_VERSION_NUMBER < 0x1010000fL)
MEDIUM: ssl: ssl_methods implementation is reworked and factored for min/max tlsxx Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. This patch introduce internal min/max and replace force-tlsxx implementation. SSL method configuration is store in 'struct tls_version_filter'. SSL method configuration to openssl setting is abstract in 'methodVersions' table. With openssl < 1.1.0, SSL_CTX_set_ssl_version is used for force (min == max). With openssl >= 1.1.0, SSL_CTX_set_min/max_proto_version is used.
2017-03-30 13:19:37 -04:00
/* Keep force-xxx implementation as it is in older haproxy. It's a
CLEANUP: fix typos in the ssl_sock subsystem Fix some typos found in the code comments of the ssl_sock subsystem.
2018-11-15 12:07:59 -05:00
precautionary measure to avoid any surprise with older openssl version. */
MEDIUM: ssl: ssl_methods implementation is reworked and factored for min/max tlsxx Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. This patch introduce internal min/max and replace force-tlsxx implementation. SSL method configuration is store in 'struct tls_version_filter'. SSL method configuration to openssl setting is abstract in 'methodVersions' table. With openssl < 1.1.0, SSL_CTX_set_ssl_version is used for force (min == max). With openssl >= 1.1.0, SSL_CTX_set_min/max_proto_version is used.
2017-03-30 13:19:37 -04:00
if (min == max)
MEDIUM: ssl: ctx_set_version/ssl_set_version func for methodVersions table This patch cleanup the usage of set_version func with a more suitable name: ctx_set_version. It introduce ssl_set_version func (unused for the moment).
2017-05-18 06:33:19 -04:00
methodVersions[min].ctx_set_version(ctx, SET_CLIENT);
MEDIUM: ssl: ssl-min-ver and ssl-max-ver compatibility. In haproxy < 1.8, no-sslv3/no-tlsv1x are ignored when force-sslv3/force-tlsv1x is used (without warning). With this patch, no-sslv3/no-tlsv1x are ignored when ssl-min-ver or ssl-max-ver is used (with warning). When all SSL/TLS versions are disable: generate an error, not a warning. example: ssl-min-ver TLSV1.3 (or force-tlsv13) with a openssl <= 1.1.0.
2017-05-05 12:06:12 -04:00
else
for (i = CONF_TLSV_MIN; i <= CONF_TLSV_MAX; i++)
if (flags & methodVersions[i].flag)
options |= methodVersions[i].option;
MEDIUM: ssl: ssl_methods implementation is reworked and factored for min/max tlsxx Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. This patch introduce internal min/max and replace force-tlsxx implementation. SSL method configuration is store in 'struct tls_version_filter'. SSL method configuration to openssl setting is abstract in 'methodVersions' table. With openssl < 1.1.0, SSL_CTX_set_ssl_version is used for force (min == max). With openssl >= 1.1.0, SSL_CTX_set_min/max_proto_version is used.
2017-03-30 13:19:37 -04:00
#else /* openssl >= 1.1.0 */
MEDIUM: ssl: calculate the real min/max TLS version and find holes Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. Find the real min/max versions (openssl capabilities and haproxy configuration) and generate warning with bad versions range. 'no-tlsxx' can generate 'holes': "The list of protocols available can be further limited using the SSL_OP_NO_X options of the SSL_CTX_set_options or SSL_set_options functions. Clients should avoid creating 'holes' in the set of protocols they support, when disabling a protocol, make sure that you also disable either all previous or all subsequent protocol versions. In clients, when a protocol version is disabled without disabling all previous protocol versions, the effect is to also disable all subsequent protocol versions." To not break compatibility, "holes" is authorized with warning, because openssl 1.1.0 and boringssl deal with it (keep the upper or lower range depending the case and version).
2017-03-30 13:25:07 -04:00
/* set the max_version is required to cap TLS version or activate new TLS (v1.3) */
MEDIUM: ssl: ctx_set_version/ssl_set_version func for methodVersions table This patch cleanup the usage of set_version func with a more suitable name: ctx_set_version. It introduce ssl_set_version func (unused for the moment).
2017-05-18 06:33:19 -04:00
methodVersions[min].ctx_set_version(ctx, SET_MIN);
methodVersions[max].ctx_set_version(ctx, SET_MAX);
MEDIUM: ssl: ssl_methods implementation is reworked and factored for min/max tlsxx Plan is to add min-tlsxx max-tlsxx configuration, more consistent than no-tlsxx. This patch introduce internal min/max and replace force-tlsxx implementation. SSL method configuration is store in 'struct tls_version_filter'. SSL method configuration to openssl setting is abstract in 'methodVersions' table. With openssl < 1.1.0, SSL_CTX_set_ssl_version is used for force (min == max). With openssl >= 1.1.0, SSL_CTX_set_min/max_proto_version is used.
2017-03-30 13:19:37 -04:00
#endif
if (srv->ssl_ctx.options & SRV_SSL_O_NO_TLS_TICKETS)
options |= SSL_OP_NO_TICKET;
MINOR: ssl: removes SSL_CTX_set_ssl_version call and cleanup CTX creation. BoringSSL doesn't support SSL_CTX_set_ssl_version. To remove this call, the CTX creation is cleanup to clarify what is happening. SSL_CTX_new is used to match the original behavior, in order: force-<method> according the method version then the default method with no-<method> options. OPENSSL_NO_SSL3 error message is now in force-sslv3 parsing (as force-tls*). For CTX creation in bind environement, all CTX set related to the initial ctx are aggregate to ssl_sock_new_ctx function for clarity. Tests with crt-list have shown that server_method, options and mode are linked to the initial CTX (default_ctx): all ssl-options are link to each bind line and must be removed from crt-list.
2017-03-03 06:21:32 -05:00
SSL_CTX_set_options(ctx, options);
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
BUILD: ssl: use SSL_MODE_ASYNC macro instead of OPENSSL_VERSION
2020-11-13 15:56:34 -05:00
#ifdef SSL_MODE_ASYNC
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
if (global_ssl.async)
mode |= SSL_MODE_ASYNC;
#endif
MINOR: ssl: removes SSL_CTX_set_ssl_version call and cleanup CTX creation. BoringSSL doesn't support SSL_CTX_set_ssl_version. To remove this call, the CTX creation is cleanup to clarify what is happening. SSL_CTX_new is used to match the original behavior, in order: force-<method> according the method version then the default method with no-<method> options. OPENSSL_NO_SSL3 error message is now in force-sslv3 parsing (as force-tls*). For CTX creation in bind environement, all CTX set related to the initial ctx are aggregate to ssl_sock_new_ctx function for clarity. Tests with crt-list have shown that server_method, options and mode are linked to the initial CTX (default_ctx): all ssl-options are link to each bind line and must be removed from crt-list.
2017-03-03 06:21:32 -05:00
SSL_CTX_set_mode(ctx, mode);
MEDIUM: ssl: Set verify 'required' as global default for servers side. If no CA file specified on a server line, the config parser will show an error. Adds an cmdline option '-dV' to re-set verify 'none' as global default on servers side (previous behavior). Also adds 'ssl-server-verify' global statement to set global default to 'none' or 'required'. WARNING: this changes the default verify mode from "none" to "required" on the server side, and it *will* break insecure setups.
2014-01-29 06:24:34 -05:00
if (global.ssl_server_verify == SSL_SERVER_VERIFY_REQUIRED)
verify = SSL_VERIFY_PEER;
switch (srv->ssl_ctx.verify) {
case SSL_SOCK_VERIFY_NONE:
verify = SSL_VERIFY_NONE;
break;
case SSL_SOCK_VERIFY_REQUIRED:
verify = SSL_VERIFY_PEER;
break;
}
MINOR: ssl: Server ssl context prepare function refactoring Split the server's ssl context initialization into the general ssl related initializations and the actual initialization of a single SSL_CTX structure. This way the context's initialization will be usable by itself from elsewhere.
2021-01-25 11:19:41 -05:00
SSL_CTX_set_verify(ctx, verify,
MINOR: ssl: compare server certificate names to the SNI on outgoing connections When support for passing SNI to the server was added in 1.6-dev3, there was no way to validate that the certificate presented by the server would really match the name requested in the SNI, which is quite a problem as it allows other (valid) certificates to be presented instead (when hitting the wrong server or due to a man in the middle). This patch adds the missing check against the value passed in the SNI. The "verifyhost" value keeps precedence if set. If no SNI is used and no verifyhost directive is specified, then the certificate name is not checked (this is unchanged). In order to extract the SNI value, it was necessary to make use of SSL_SESSION_get0_hostname(), which appeared in openssl 1.1.0. This is a trivial function which returns the value of s->tlsext_hostname, so it was provided in the compat layer for older versions. After some refinements from Emmanuel, it now builds with openssl 1.0.2, openssl 1.1.0 and boringssl. A test file was provided to ease testing all cases. After some careful observation period it may make sense to backport this to 1.7 and 1.6 as some users rightfully consider this limitation as a bug. Cc: Emmanuel Hocdet <manu@gandi.net> Signed-off-by: Willy Tarreau <w@1wt.eu>
2017-07-05 12:23:03 -04:00
(srv->ssl_ctx.verify_host || (verify & SSL_VERIFY_PEER)) ? ssl_sock_srv_verifycbk : NULL);
MEDIUM: ssl: Set verify 'required' as global default for servers side. If no CA file specified on a server line, the config parser will show an error. Adds an cmdline option '-dV' to re-set verify 'none' as global default on servers side (previous behavior). Also adds 'ssl-server-verify' global statement to set global default to 'none' or 'required'. WARNING: this changes the default verify mode from "none" to "required" on the server side, and it *will* break insecure setups.
2014-01-29 06:24:34 -05:00
if (verify & SSL_VERIFY_PEER) {
MINOR: ssl: add statements 'verify', 'ca-file' and 'crl-file' on servers. It now becomes possible to verify the server's certificate using the "verify" directive. This one only supports "none" and "required", as it does not make much sense to also support "optional" here.
2012-10-11 10:11:36 -04:00
if (srv->ssl_ctx.ca_file) {
MINOR: ssl: deduplicate ca-file Typically server line like: 'server-template srv 1-1000 *:443 ssl ca-file ca-certificates.crt' load ca-certificates.crt 1000 times and stay duplicated in memory. Same case for bind line: ca-file is loaded for each certificate. Same 'ca-file' can be load one time only and stay deduplicated in memory. As a corollary, this will prevent file access for ca-file when updating a certificate via CLI.
2019-10-24 05:32:47 -04:00
/* set CAfile to verify */
MINOR: ssl: Server ssl context prepare function refactoring Split the server's ssl context initialization into the general ssl related initializations and the actual initialization of a single SSL_CTX structure. This way the context's initialization will be usable by itself from elsewhere.
2021-01-25 11:19:41 -05:00
if (!ssl_set_verify_locations_file(ctx, srv->ssl_ctx.ca_file)) {
REORG: config: use parsing ctx for server config check Initialize the parsing context when checking server config validity. Adjust the log messages to remove redundant config file/line and server name. Do a similar cleaning in prepare_srv from ssl_sock as this function is called at the same stage. This will standardize the stderr output on startup with the parse_server function.
2021-05-28 04:34:01 -04:00
ha_alert("unable to set CA file '%s'.\n",
srv->ssl_ctx.ca_file);
MINOR: ssl: add statements 'verify', 'ca-file' and 'crl-file' on servers. It now becomes possible to verify the server's certificate using the "verify" directive. This one only supports "none" and "required", as it does not make much sense to also support "optional" here.
2012-10-11 10:11:36 -04:00
cfgerr++;
}
}
MEDIUM: ssl: Set verify 'required' as global default for servers side. If no CA file specified on a server line, the config parser will show an error. Adds an cmdline option '-dV' to re-set verify 'none' as global default on servers side (previous behavior). Also adds 'ssl-server-verify' global statement to set global default to 'none' or 'required'. WARNING: this changes the default verify mode from "none" to "required" on the server side, and it *will* break insecure setups.
2014-01-29 06:24:34 -05:00
else {
if (global.ssl_server_verify == SSL_SERVER_VERIFY_REQUIRED)
REORG: config: use parsing ctx for server config check Initialize the parsing context when checking server config validity. Adjust the log messages to remove redundant config file/line and server name. Do a similar cleaning in prepare_srv from ssl_sock as this function is called at the same stage. This will standardize the stderr output on startup with the parse_server function.
2021-05-28 04:34:01 -04:00
ha_alert("verify is enabled by default but no CA file specified. If you're running on a LAN where you're certain to trust the server's certificate, please set an explicit 'verify none' statement on the 'server' line, or use 'ssl-server-verify none' in the global section to disable server-side verifications by default.\n");
MEDIUM: ssl: Set verify 'required' as global default for servers side. If no CA file specified on a server line, the config parser will show an error. Adds an cmdline option '-dV' to re-set verify 'none' as global default on servers side (previous behavior). Also adds 'ssl-server-verify' global statement to set global default to 'none' or 'required'. WARNING: this changes the default verify mode from "none" to "required" on the server side, and it *will* break insecure setups.
2014-01-29 06:24:34 -05:00
else
REORG: config: use parsing ctx for server config check Initialize the parsing context when checking server config validity. Adjust the log messages to remove redundant config file/line and server name. Do a similar cleaning in prepare_srv from ssl_sock as this function is called at the same stage. This will standardize the stderr output on startup with the parse_server function.
2021-05-28 04:34:01 -04:00
ha_alert("verify is enabled but no CA file specified.\n");
MEDIUM: ssl: Set verify 'required' as global default for servers side. If no CA file specified on a server line, the config parser will show an error. Adds an cmdline option '-dV' to re-set verify 'none' as global default on servers side (previous behavior). Also adds 'ssl-server-verify' global statement to set global default to 'none' or 'required'. WARNING: this changes the default verify mode from "none" to "required" on the server side, and it *will* break insecure setups.
2014-01-29 06:24:34 -05:00
cfgerr++;
}
MINOR: ssl: add statements 'verify', 'ca-file' and 'crl-file' on servers. It now becomes possible to verify the server's certificate using the "verify" directive. This one only supports "none" and "required", as it does not make much sense to also support "optional" here.
2012-10-11 10:11:36 -04:00
#ifdef X509_V_FLAG_CRL_CHECK
if (srv->ssl_ctx.crl_file) {
MINOR: ssl: Server ssl context prepare function refactoring Split the server's ssl context initialization into the general ssl related initializations and the actual initialization of a single SSL_CTX structure. This way the context's initialization will be usable by itself from elsewhere.
2021-01-25 11:19:41 -05:00
X509_STORE *store = SSL_CTX_get_cert_store(ctx);
MINOR: ssl: add statements 'verify', 'ca-file' and 'crl-file' on servers. It now becomes possible to verify the server's certificate using the "verify" directive. This one only supports "none" and "required", as it does not make much sense to also support "optional" here.
2012-10-11 10:11:36 -04:00
MINOR: ssl: deduplicate crl-file Load file for crl or ca-cert is realy done with the same function in OpenSSL, via X509_STORE_load_locations. Accordingly, deduplicate crl-file and ca-file can share the same function.
2019-11-21 13:09:31 -05:00
if (!ssl_set_cert_crl_file(store, srv->ssl_ctx.crl_file)) {
REORG: config: use parsing ctx for server config check Initialize the parsing context when checking server config validity. Adjust the log messages to remove redundant config file/line and server name. Do a similar cleaning in prepare_srv from ssl_sock as this function is called at the same stage. This will standardize the stderr output on startup with the parse_server function.
2021-05-28 04:34:01 -04:00
ha_alert("unable to configure CRL file '%s'.\n",
srv->ssl_ctx.crl_file);
MINOR: ssl: add statements 'verify', 'ca-file' and 'crl-file' on servers. It now becomes possible to verify the server's certificate using the "verify" directive. This one only supports "none" and "required", as it does not make much sense to also support "optional" here.
2012-10-11 10:11:36 -04:00
cfgerr++;
}
else {
X509_STORE_set_flags(store, X509_V_FLAG_CRL_CHECK|X509_V_FLAG_CRL_CHECK_ALL);
}
}
#endif
}
MINOR: ssl: Server ssl context prepare function refactoring Split the server's ssl context initialization into the general ssl related initializations and the actual initialization of a single SSL_CTX structure. This way the context's initialization will be usable by itself from elsewhere.
2021-01-25 11:19:41 -05:00
SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_CLIENT | SSL_SESS_CACHE_NO_INTERNAL_STORE);
SSL_CTX_sess_set_new_cb(ctx, ssl_sess_new_srv_cb);
MINOR: ssl: move ssl context init for servers from cfgparse.c to ssl_sock.c
2012-10-11 08:00:19 -04:00
if (srv->ssl_ctx.ciphers &&
MINOR: ssl: Server ssl context prepare function refactoring Split the server's ssl context initialization into the general ssl related initializations and the actual initialization of a single SSL_CTX structure. This way the context's initialization will be usable by itself from elsewhere.
2021-01-25 11:19:41 -05:00
!SSL_CTX_set_cipher_list(ctx, srv->ssl_ctx.ciphers)) {
REORG: config: use parsing ctx for server config check Initialize the parsing context when checking server config validity. Adjust the log messages to remove redundant config file/line and server name. Do a similar cleaning in prepare_srv from ssl_sock as this function is called at the same stage. This will standardize the stderr output on startup with the parse_server function.
2021-05-28 04:34:01 -04:00
ha_alert("unable to set SSL cipher list to '%s'.\n",
srv->ssl_ctx.ciphers);
MINOR: ssl: move ssl context init for servers from cfgparse.c to ssl_sock.c
2012-10-11 08:00:19 -04:00
cfgerr++;
}
BUILD: SSL: guard TLS13 ciphersuites with HAVE_SSL_CTX_SET_CIPHERSUITES HAVE_SSL_CTX_SET_CIPHERSUITES is newly defined macro set in openssl-compat.h, which helps to identify ssl libs (currently OpenSSL-1.1.1 only) that supports TLS13 cipersuites manipulation on TLS13 context
2020-11-21 04:37:34 -05:00
#ifdef HAVE_SSL_CTX_SET_CIPHERSUITES
MEDIUM: ssl: add support for ciphersuites option for TLSv1.3 OpenSSL released support for TLSv1.3. It also added a separate function SSL_CTX_set_ciphersuites that is used to set the ciphers used in the TLS 1.3 handshake. This change adds support for that new configuration option by adding a ciphersuites configuration variable that works essentially the same as the existing ciphers setting. Note that it should likely be backported to 1.8 in order to ease usage of the now released openssl-1.1.1.
2018-09-14 05:14:21 -04:00
if (srv->ssl_ctx.ciphersuites &&
MINOR: ssl: Server ssl context prepare function refactoring Split the server's ssl context initialization into the general ssl related initializations and the actual initialization of a single SSL_CTX structure. This way the context's initialization will be usable by itself from elsewhere.
2021-01-25 11:19:41 -05:00
!SSL_CTX_set_ciphersuites(ctx, srv->ssl_ctx.ciphersuites)) {
REORG: config: use parsing ctx for server config check Initialize the parsing context when checking server config validity. Adjust the log messages to remove redundant config file/line and server name. Do a similar cleaning in prepare_srv from ssl_sock as this function is called at the same stage. This will standardize the stderr output on startup with the parse_server function.
2021-05-28 04:34:01 -04:00
ha_alert("unable to set TLS 1.3 cipher suites to '%s'.\n",
srv->ssl_ctx.ciphersuites);
MEDIUM: ssl: add support for ciphersuites option for TLSv1.3 OpenSSL released support for TLSv1.3. It also added a separate function SSL_CTX_set_ciphersuites that is used to set the ciphers used in the TLS 1.3 handshake. This change adds support for that new configuration option by adding a ciphersuites configuration variable that works essentially the same as the existing ciphers setting. Note that it should likely be backported to 1.8 in order to ease usage of the now released openssl-1.1.1.
2018-09-14 05:14:21 -04:00
cfgerr++;
}
#endif
MINOR: server: Add "alpn" and "npn" keywords. Add new keywords to "server" lines, alpn and npn. If set, when connecting through SSL, those alpn/npn will be negociated during the SSL handshake.
2018-11-20 17:33:50 -05:00
#if defined(OPENSSL_NPN_NEGOTIATED) && !defined(OPENSSL_NO_NEXTPROTONEG)
if (srv->ssl_ctx.npn_str)
MINOR: ssl: Server ssl context prepare function refactoring Split the server's ssl context initialization into the general ssl related initializations and the actual initialization of a single SSL_CTX structure. This way the context's initialization will be usable by itself from elsewhere.
2021-01-25 11:19:41 -05:00
SSL_CTX_set_next_proto_select_cb(ctx, ssl_sock_srv_select_protos, (struct server*)srv);
MINOR: server: Add "alpn" and "npn" keywords. Add new keywords to "server" lines, alpn and npn. If set, when connecting through SSL, those alpn/npn will be negociated during the SSL handshake.
2018-11-20 17:33:50 -05:00
#endif
#ifdef TLSEXT_TYPE_application_layer_protocol_negotiation
MINOR: ssl: do not set ALPN callback with the empty string While it does not have any effect, it's better not to try to setup an ALPN callback nor to try to lookup algorithms when the configured ALPN string is empty as a result of "no-alpn" being used.
2023-04-19 03:05:49 -04:00
if (srv->ssl_ctx.alpn_str && srv->ssl_ctx.alpn_len)
MINOR: server: Add "alpn" and "npn" keywords. Add new keywords to "server" lines, alpn and npn. If set, when connecting through SSL, those alpn/npn will be negociated during the SSL handshake.
2018-11-20 17:33:50 -05:00
SSL_CTX_set_alpn_protos(ctx, (unsigned char *)srv->ssl_ctx.alpn_str, srv->ssl_ctx.alpn_len);
#endif
MINOR: ssl: allow to change the server signature algorithm on server lines This patch introduces the "sigalgs" keyword for the server line, which allows to configure the list of server signature algorithms negociated during the handshake. Also available as "ssl-default-server-sigalgs" in the global section.
2023-06-29 07:29:59 -04:00
#if defined(SSL_CTX_set1_sigalgs_list)
conf_sigalgs = srv->ssl_ctx.sigalgs;
if (conf_sigalgs) {
if (!SSL_CTX_set1_sigalgs_list(ctx, conf_sigalgs)) {
ha_alert("Proxy '%s': unable to set SSL Signature Algorithm list to '%s' for server '%s'.\n",
curproxy->id, conf_sigalgs, srv->id);
cfgerr++;
}
}
#endif
MINOR: ssl: allow to change the client-sigalgs on server lines This patch introduces the "client-sigalgs" keyword for the server line, which allows to configure the list of server signature algorithms negociated during the handshake. Also available as "ssl-default-server-client-sigalgs" in the global section.
2023-06-29 08:11:46 -04:00
#if defined(SSL_CTX_set1_client_sigalgs_list)
conf_client_sigalgs = srv->ssl_ctx.client_sigalgs;
if (conf_client_sigalgs) {
if (!SSL_CTX_set1_client_sigalgs_list(ctx, conf_client_sigalgs)) {
ha_alert("Proxy '%s': unable to set SSL Client Signature Algorithm list to '%s' for server '%s'.\n",
curproxy->id, conf_client_sigalgs, srv->id);
cfgerr++;
}
}
#endif
MEDIUM: ssl: add support for ciphersuites option for TLSv1.3 OpenSSL released support for TLSv1.3. It also added a separate function SSL_CTX_set_ciphersuites that is used to set the ciphers used in the TLS 1.3 handshake. This change adds support for that new configuration option by adding a ciphersuites configuration variable that works essentially the same as the existing ciphers setting. Note that it should likely be backported to 1.8 in order to ease usage of the now released openssl-1.1.1.
2018-09-14 05:14:21 -04:00
MINOR: ssl: add support for 'curves' keyword on server lines This patch implements the 'curves' keyword on server lines as well as the 'ssl-default-server-curves' keyword in the global section. It also add the keyword on the server line in the ssl_curves reg-test. These keywords allow the configuration of the curves list for a server.
2023-09-07 17:13:15 -04:00
#if defined(SSL_CTX_set1_curves_list)
conf_curves = srv->ssl_ctx.curves;
if (conf_curves) {
if (!SSL_CTX_set1_curves_list(ctx, conf_curves)) {
ha_alert("Proxy '%s': unable to set SSL curves list to '%s' for server '%s'.\n",
curproxy->id, conf_curves, srv->id);
cfgerr++;
}
}
#endif /* defined(SSL_CTX_set1_curves_list) */
MINOR: ssl: move ssl context init for servers from cfgparse.c to ssl_sock.c
2012-10-11 08:00:19 -04:00
return cfgerr;
}
MEDIUM: ssl: Chain ckch instances in ca-file entries Each ca-file entry of the tree will now hold a list of the ckch instances that use it so that we can iterate over them when updating the ca-file via a cli command. Since the link between the SSL contexts and the CA file tree entries is only built during the ssl_sock_prepare_ctx function, which are called after all the ckch instances are created, we need to add a little post processing after each ssl_sock_prepare_ctx that builds the link between the corresponding ckch instance and CA file tree entries. In order to manage the ca-file and ca-verify-file options, any ckch instance can be linked to multiple CA file tree entries and any CA file entry can link multiple ckch instances. This is done thanks to a dedicated list of ckch_inst references stored in the CA file tree entries over which we can iterate (during an update for instance). We avoid having one of those instances go stale by keeping a list of references to those references in the instances. When deleting a ckch_inst, we can then remove all the ckch_inst_link instances that reference it, and when deleting a cafile_entry, we iterate over the list of ckch_inst reference and clear the corresponding entry in their own list of ckch_inst_link references.
2021-02-19 11:41:55 -05:00
/*
* Prepare the frontend's SSL_CTX based on the server line configuration.
* Since the CA file loading is made depending on the verify option of the
* server line, the link between the SSL_CTX and the CA file tree entry is
* made here.
* If we want to create a link between the CA file entry and the corresponding
* ckch instance (for CA file hot update), it needs to be done after
* ssl_sock_prepare_srv_ssl_ctx.
* Returns an error count.
*/
int ssl_sock_prep_srv_ctx_and_inst(const struct server *srv, SSL_CTX *ctx,
struct ckch_inst *ckch_inst)
{
int cfgerr = 0;
cfgerr += ssl_sock_prepare_srv_ssl_ctx(srv, ctx);
if (!cfgerr && ckch_inst)
ckch_inst_add_cafile_link(ckch_inst, NULL, NULL, srv);
return cfgerr;
}
MINOR: ssl: SSL CTX initialization modifications for QUIC. Makes TLS/TCP and QUIC share the same CTX initializer so that not to modify the caller which is an XPRT callback used both by the QUIC xprt and the SSL xprt over TCP.
2020-11-23 08:33:30 -05:00
/*
* Create an initial CTX used to start the SSL connections.
* May be used by QUIC xprt which makes usage of SSL sessions initialized from SSL_CTXs.
* Returns 0 if succeeded, or something >0 if not.
*/
#ifdef USE_QUIC
static int ssl_initial_ctx(struct bind_conf *bind_conf)
{
if (bind_conf->xprt == xprt_get(XPRT_QUIC))
return ssl_quic_initial_ctx(bind_conf);
else
return ssl_sock_initial_ctx(bind_conf);
}
#else
static int ssl_initial_ctx(struct bind_conf *bind_conf)
{
return ssl_sock_initial_ctx(bind_conf);
}
#endif
MEDIUM: config: replace ssl_conf by bind_conf Some settings need to be merged per-bind config line and are not necessarily SSL-specific. It becomes quite inconvenient to have this ssl_conf SSL-specific, so let's replace it with something more generic.
2012-09-13 11:54:29 -04:00
/* Walks down the two trees in bind_conf and prepares all certs. The pointer may
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
* be NULL, in which case nothing is done. Returns the number of errors
* encountered.
*/
MEDIUM: ssl: remote the proxy argument from most functions Most of the SSL functions used to have a proxy argument which was mostly used to be able to emit clean errors using Alert(). First, many of them were converted to memprintf() and don't require this pointer anymore. Second, the rare which still need it also have either a bind_conf argument or a server argument, both of which carry a pointer to the relevant proxy. So let's now get rid of it, it needlessly complicates the API and certain functions already have many arguments.
2016-12-22 11:08:28 -05:00
int ssl_sock_prepare_all_ctx(struct bind_conf *bind_conf)
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
{
struct ebmb_node *node;
struct sni_ctx *sni;
int err = 0;
MINOR: ssl: ssl_sock_prepare_ctx() return an error code Rework ssl_sock_prepare_ctx() so it fills a buffer with the error messages instead of using ha_alert()/ha_warning(). Also returns an error code (ERR_*) instead of the number of errors.
2019-11-21 09:48:10 -05:00
int errcode = 0;
char *errmsg = NULL;
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
MINOR: global: always export some SSL-specific metrics We'll need to know the number of SSL connections, their use and their cost soon. In order to avoid getting tons of ifdefs everywhere, always export SSL information in the global section. We add two flags to know whether or not SSL is used in a frontend and in a backend.
2015-01-15 15:32:40 -05:00
/* Automatic memory computations need to know we use SSL there */
global.ssl_used_frontend = 1;
BUG/MEDIUM: ssl: in bind line, ssl-options after 'crt' are ignored. Bug introduced with "removes SSL_CTX_set_ssl_version call and cleanup CTX creation": ssl_sock_new_ctx is called before all the bind line is parsed. The fix consists of separating the use of default_ctx as the initialization context of the SSL connection via bind_conf->initial_ctx. Initial_ctx contains all the necessary parameters before performing the selection of the CTX: default_ctx is processed as others ctx without unnecessary parameters.
2017-03-06 09:34:44 -05:00
/* Create initial_ctx used to start the ssl connection before do switchctx */
if (!bind_conf->initial_ctx) {
MINOR: ssl: SSL CTX initialization modifications for QUIC. Makes TLS/TCP and QUIC share the same CTX initializer so that not to modify the caller which is an XPRT callback used both by the QUIC xprt and the SSL xprt over TCP.
2020-11-23 08:33:30 -05:00
err += ssl_initial_ctx(bind_conf);
BUG/MEDIUM: ssl: in bind line, ssl-options after 'crt' are ignored. Bug introduced with "removes SSL_CTX_set_ssl_version call and cleanup CTX creation": ssl_sock_new_ctx is called before all the bind line is parsed. The fix consists of separating the use of default_ctx as the initialization context of the SSL connection via bind_conf->initial_ctx. Initial_ctx contains all the necessary parameters before performing the selection of the CTX: default_ctx is processed as others ctx without unnecessary parameters.
2017-03-06 09:34:44 -05:00
/* It should not be necessary to call this function, but it's
necessary first to check and move all initialisation related
MINOR: ssl: SSL CTX initialization modifications for QUIC. Makes TLS/TCP and QUIC share the same CTX initializer so that not to modify the caller which is an XPRT callback used both by the QUIC xprt and the SSL xprt over TCP.
2020-11-23 08:33:30 -05:00
to initial_ctx in ssl_initial_ctx. */
MEDIUM: ssl: Chain ckch instances in ca-file entries Each ca-file entry of the tree will now hold a list of the ckch instances that use it so that we can iterate over them when updating the ca-file via a cli command. Since the link between the SSL contexts and the CA file tree entries is only built during the ssl_sock_prepare_ctx function, which are called after all the ckch instances are created, we need to add a little post processing after each ssl_sock_prepare_ctx that builds the link between the corresponding ckch instance and CA file tree entries. In order to manage the ca-file and ca-verify-file options, any ckch instance can be linked to multiple CA file tree entries and any CA file entry can link multiple ckch instances. This is done thanks to a dedicated list of ckch_inst references stored in the CA file tree entries over which we can iterate (during an update for instance). We avoid having one of those instances go stale by keeping a list of references to those references in the instances. When deleting a ckch_inst, we can then remove all the ckch_inst_link instances that reference it, and when deleting a cafile_entry, we iterate over the list of ckch_inst reference and clear the corresponding entry in their own list of ckch_inst_link references.
2021-02-19 11:41:55 -05:00
errcode |= ssl_sock_prep_ctx_and_inst(bind_conf, NULL, bind_conf->initial_ctx, NULL, &errmsg);
}
BUG/MINOR: ssl: correctly initialize ssl ctx for invalid certificates Bug reported by John Leach: no-sslv3 does not work using some certificates. It appears that ssl ctx is not updated with configured options if the CommonName of the certificate's subject is not found. It applies only on the first cerificate of a configured bind line. There is no security impact, because only invalid nameless certficates are concerned. This fix must be backported to 1.5
2014-10-30 14:25:24 -04:00
MEDIUM: config: replace ssl_conf by bind_conf Some settings need to be merged per-bind config line and are not necessarily SSL-specific. It becomes quite inconvenient to have this ssl_conf SSL-specific, so let's replace it with something more generic.
2012-09-13 11:54:29 -04:00
node = ebmb_first(&bind_conf->sni_ctx);
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
while (node) {
sni = ebmb_entry(node, struct sni_ctx, name);
MEDIUM: ssl: does not use default_ctx for 'generate-certificate' option The 'generate-certificates' option does not need its dedicated SSL_CTX *, it only needs the default SSL_CTX. Use the default SSL_CTX found in the sni_ctx to generate certificates. It allows to remove all the specific default_ctx initialization, as well as the default_ssl_conf and 'default_inst'.
2024-01-11 09:10:33 -05:00
if (!sni->order) {
/* only initialize the CTX on its first occurrence */
MEDIUM: ssl: Chain ckch instances in ca-file entries Each ca-file entry of the tree will now hold a list of the ckch instances that use it so that we can iterate over them when updating the ca-file via a cli command. Since the link between the SSL contexts and the CA file tree entries is only built during the ssl_sock_prepare_ctx function, which are called after all the ckch instances are created, we need to add a little post processing after each ssl_sock_prepare_ctx that builds the link between the corresponding ckch instance and CA file tree entries. In order to manage the ca-file and ca-verify-file options, any ckch instance can be linked to multiple CA file tree entries and any CA file entry can link multiple ckch instances. This is done thanks to a dedicated list of ckch_inst references stored in the CA file tree entries over which we can iterate (during an update for instance). We avoid having one of those instances go stale by keeping a list of references to those references in the instances. When deleting a ckch_inst, we can then remove all the ckch_inst_link instances that reference it, and when deleting a cafile_entry, we iterate over the list of ckch_inst reference and clear the corresponding entry in their own list of ckch_inst_link references.
2021-02-19 11:41:55 -05:00
errcode |= ssl_sock_prep_ctx_and_inst(bind_conf, sni->conf, sni->ctx, sni->ckch_inst, &errmsg);
}
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
node = ebmb_next(node);
}
MEDIUM: config: replace ssl_conf by bind_conf Some settings need to be merged per-bind config line and are not necessarily SSL-specific. It becomes quite inconvenient to have this ssl_conf SSL-specific, so let's replace it with something more generic.
2012-09-13 11:54:29 -04:00
node = ebmb_first(&bind_conf->sni_w_ctx);
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
while (node) {
sni = ebmb_entry(node, struct sni_ctx, name);
MEDIUM: ssl: does not use default_ctx for 'generate-certificate' option The 'generate-certificates' option does not need its dedicated SSL_CTX *, it only needs the default SSL_CTX. Use the default SSL_CTX found in the sni_ctx to generate certificates. It allows to remove all the specific default_ctx initialization, as well as the default_ssl_conf and 'default_inst'.
2024-01-11 09:10:33 -05:00
if (!sni->order) {
/* only initialize the CTX on its first occurrence */
MEDIUM: ssl: Chain ckch instances in ca-file entries Each ca-file entry of the tree will now hold a list of the ckch instances that use it so that we can iterate over them when updating the ca-file via a cli command. Since the link between the SSL contexts and the CA file tree entries is only built during the ssl_sock_prepare_ctx function, which are called after all the ckch instances are created, we need to add a little post processing after each ssl_sock_prepare_ctx that builds the link between the corresponding ckch instance and CA file tree entries. In order to manage the ca-file and ca-verify-file options, any ckch instance can be linked to multiple CA file tree entries and any CA file entry can link multiple ckch instances. This is done thanks to a dedicated list of ckch_inst references stored in the CA file tree entries over which we can iterate (during an update for instance). We avoid having one of those instances go stale by keeping a list of references to those references in the instances. When deleting a ckch_inst, we can then remove all the ckch_inst_link instances that reference it, and when deleting a cafile_entry, we iterate over the list of ckch_inst reference and clear the corresponding entry in their own list of ckch_inst_link references.
2021-02-19 11:41:55 -05:00
errcode |= ssl_sock_prep_ctx_and_inst(bind_conf, sni->conf, sni->ctx, sni->ckch_inst, &errmsg);
MINOR: ssl: ssl_sock_prepare_ctx() return an error code Rework ssl_sock_prepare_ctx() so it fills a buffer with the error messages instead of using ha_alert()/ha_warning(). Also returns an error code (ERR_*) instead of the number of errors.
2019-11-21 09:48:10 -05:00
}
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
node = ebmb_next(node);
}
MINOR: ssl: ssl_sock_prepare_ctx() return an error code Rework ssl_sock_prepare_ctx() so it fills a buffer with the error messages instead of using ha_alert()/ha_warning(). Also returns an error code (ERR_*) instead of the number of errors.
2019-11-21 09:48:10 -05:00
if (errcode & ERR_WARN) {
BUG/MINOR: ssl: Stop passing dynamic strings as format arguments gcc complains rightfully: src/ssl_sock.c: In function ‘ssl_sock_prepare_all_ctx’: src/ssl_sock.c:5507:3: warning: format not a string literal and no format arguments [-Wformat-security] ha_warning(errmsg); ^ src/ssl_sock.c:5509:3: warning: format not a string literal and no format arguments [-Wformat-security] ha_alert(errmsg); ^ src/ssl_sock.c: In function ‘cli_io_handler_commit_cert’: src/ssl_sock.c:10208:3: warning: format not a string literal and no format arguments [-Wformat-security] chunk_appendf(trash, err); Introduced in 8b453912ce9a4e1a3b1329efb2af04d1e470852e.
2019-11-23 17:52:30 -05:00
ha_warning("%s", errmsg);
MINOR: ssl: ssl_sock_prepare_ctx() return an error code Rework ssl_sock_prepare_ctx() so it fills a buffer with the error messages instead of using ha_alert()/ha_warning(). Also returns an error code (ERR_*) instead of the number of errors.
2019-11-21 09:48:10 -05:00
} else if (errcode & ERR_CODE) {
BUG/MINOR: ssl: Stop passing dynamic strings as format arguments gcc complains rightfully: src/ssl_sock.c: In function ‘ssl_sock_prepare_all_ctx’: src/ssl_sock.c:5507:3: warning: format not a string literal and no format arguments [-Wformat-security] ha_warning(errmsg); ^ src/ssl_sock.c:5509:3: warning: format not a string literal and no format arguments [-Wformat-security] ha_alert(errmsg); ^ src/ssl_sock.c: In function ‘cli_io_handler_commit_cert’: src/ssl_sock.c:10208:3: warning: format not a string literal and no format arguments [-Wformat-security] chunk_appendf(trash, err); Introduced in 8b453912ce9a4e1a3b1329efb2af04d1e470852e.
2019-11-23 17:52:30 -05:00
ha_alert("%s", errmsg);
MINOR: ssl: ssl_sock_prepare_ctx() return an error code Rework ssl_sock_prepare_ctx() so it fills a buffer with the error messages instead of using ha_alert()/ha_warning(). Also returns an error code (ERR_*) instead of the number of errors.
2019-11-21 09:48:10 -05:00
err++;
}
free(errmsg);
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
return err;
}
MEDIUM: ssl_sock: implement ssl_sock_prepare_bind_conf() Instead of hard-coding all SSL preparation in cfgparse.c, we now register this new function as the transport layer's prepare_bind_conf() and call it only when definied. This removes some non-obvious SSL-specific code from cfgparse.c as well as a #ifdef.
2016-12-21 17:38:39 -05:00
/* Prepares all the contexts for a bind_conf and allocates the shared SSL
* context if needed. Returns < 0 on error, 0 on success. The warnings and
* alerts are directly emitted since the rest of the stack does it below.
*/
int ssl_sock_prepare_bind_conf(struct bind_conf *bind_conf)
{
struct proxy *px = bind_conf->frontend;
int alloc_ctx;
int err;
MEDIUM: ssl: generate '*' SNI filters for default certificates This patch follows the previous one about default certificate selection ("MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection"). This patch generates '*" SNI filters for the first certificate of a bind line, it will be used to match default certificates. Instead of setting the default_ctx pointer in the bind line. Since the filters are in the SNI tree, it allows to have multiple default certificate and restore the ecdsa/rsa selection with a multi-cert bundle. This configuration: # foobar.pem.ecdsa and foobar.pem.rsa bind *:8443 ssl crt foobar.pem crt next.pem will use "foobar.pem.ecdsa" and "foobar.pem.rsa" as default certificates. Note: there is still cleanup needed around default_ctx. This was discussed in github issue #2392.
2024-01-10 10:07:17 -05:00
/* check if some certificates were loaded but no ssl keyword is used */
CLEANUP: listener: replace all uses of bind_conf->is_ssl with BC_O_USE_SSL The new flag will now replace this boolean variable that was only set and tested.
2022-05-20 09:56:32 -04:00
if (!(bind_conf->options & BC_O_USE_SSL)) {
MEDIUM: ssl: generate '*' SNI filters for default certificates This patch follows the previous one about default certificate selection ("MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection"). This patch generates '*" SNI filters for the first certificate of a bind line, it will be used to match default certificates. Instead of setting the default_ctx pointer in the bind line. Since the filters are in the SNI tree, it allows to have multiple default certificate and restore the ecdsa/rsa selection with a multi-cert bundle. This configuration: # foobar.pem.ecdsa and foobar.pem.rsa bind *:8443 ssl crt foobar.pem crt next.pem will use "foobar.pem.ecdsa" and "foobar.pem.rsa" as default certificates. Note: there is still cleanup needed around default_ctx. This was discussed in github issue #2392.
2024-01-10 10:07:17 -05:00
if (!eb_is_empty(&bind_conf->sni_ctx) || !eb_is_empty(&bind_conf->sni_w_ctx)) {
CLEANUP: log: Rename Alert/Warning in ha_alert/ha_warning
2017-11-24 10:50:31 -05:00
ha_warning("Proxy '%s': A certificate was specified but SSL was not enabled on bind '%s' at [%s:%d] (use 'ssl').\n",
px->id, bind_conf->arg, bind_conf->file, bind_conf->line);
MEDIUM: ssl_sock: implement ssl_sock_prepare_bind_conf() Instead of hard-coding all SSL preparation in cfgparse.c, we now register this new function as the transport layer's prepare_bind_conf() and call it only when definied. This removes some non-obvious SSL-specific code from cfgparse.c as well as a #ifdef.
2016-12-21 17:38:39 -05:00
}
return 0;
}
MEDIUM: ssl: generate '*' SNI filters for default certificates This patch follows the previous one about default certificate selection ("MEDIUM: ssl: allow multiple fallback certificate to allow ECDSA/RSA selection"). This patch generates '*" SNI filters for the first certificate of a bind line, it will be used to match default certificates. Instead of setting the default_ctx pointer in the bind line. Since the filters are in the SNI tree, it allows to have multiple default certificate and restore the ecdsa/rsa selection with a multi-cert bundle. This configuration: # foobar.pem.ecdsa and foobar.pem.rsa bind *:8443 ssl crt foobar.pem crt next.pem will use "foobar.pem.ecdsa" and "foobar.pem.rsa" as default certificates. Note: there is still cleanup needed around default_ctx. This was discussed in github issue #2392.
2024-01-10 10:07:17 -05:00
/* check if we have certificates */
if (eb_is_empty(&bind_conf->sni_ctx) && eb_is_empty(&bind_conf->sni_w_ctx)) {
CLEANUP: listener: replace bind_conf->generate_cers with BC_O_GENERATE_CERTS The new flag will now replace this boolean variable.
2022-05-20 10:03:18 -04:00
if (bind_conf->strict_sni && !(bind_conf->options & BC_O_GENERATE_CERTS)) {
CLEANUP: log: Rename Alert/Warning in ha_alert/ha_warning
2017-11-24 10:50:31 -05:00
ha_warning("Proxy '%s': no SSL certificate specified for bind '%s' at [%s:%d], ssl connections will fail (use 'crt').\n",
px->id, bind_conf->arg, bind_conf->file, bind_conf->line);
MINOR: ssl: allow to start without certificate if strict-sni is set With strict-sni, ssl connection will fail if no certificate match. Have no certificate in bind line, fail on all ssl connections. It's ok with the behavior of strict-sni. When 'generate-certificates' is set 'strict-sni' is never used. When 'strict-sni' is set, default_ctx is never used. Allow to start without certificate only in this case. Use case is to start haproxy with ssl before customer start to use certificates. Typically with 'crt' on a empty directory and 'strict-sni' parameters.
2017-08-09 05:24:25 -04:00
}
else {
CLEANUP: log: Rename Alert/Warning in ha_alert/ha_warning
2017-11-24 10:50:31 -05:00
ha_alert("Proxy '%s': no SSL certificate specified for bind '%s' at [%s:%d] (use 'crt').\n",
px->id, bind_conf->arg, bind_conf->file, bind_conf->line);
MINOR: ssl: allow to start without certificate if strict-sni is set With strict-sni, ssl connection will fail if no certificate match. Have no certificate in bind line, fail on all ssl connections. It's ok with the behavior of strict-sni. When 'generate-certificates' is set 'strict-sni' is never used. When 'strict-sni' is set, default_ctx is never used. Allow to start without certificate only in this case. Use case is to start haproxy with ssl before customer start to use certificates. Typically with 'crt' on a empty directory and 'strict-sni' parameters.
2017-08-09 05:24:25 -04:00
return -1;
}
MEDIUM: ssl_sock: implement ssl_sock_prepare_bind_conf() Instead of hard-coding all SSL preparation in cfgparse.c, we now register this new function as the transport layer's prepare_bind_conf() and call it only when definied. This removes some non-obvious SSL-specific code from cfgparse.c as well as a #ifdef.
2016-12-21 17:38:39 -05:00
}
MEDIUM: ssl: does not use default_ctx for 'generate-certificate' option The 'generate-certificates' option does not need its dedicated SSL_CTX *, it only needs the default SSL_CTX. Use the default SSL_CTX found in the sni_ctx to generate certificates. It allows to remove all the specific default_ctx initialization, as well as the default_ssl_conf and 'default_inst'.
2024-01-11 09:10:33 -05:00
if ((bind_conf->options & BC_O_GENERATE_CERTS)) {
struct sni_ctx *sni_ctx;
/* if we use the generate-certificates option, look for the first default cert available */
sni_ctx = ssl_sock_chose_sni_ctx(bind_conf, "", 1, 1);
if (!sni_ctx) {
ha_alert("Proxy '%s': no SSL certificate specified for bind '%s' and 'generate-certificates' option at [%s:%d] (use 'crt').\n",
px->id, bind_conf->arg, bind_conf->file, bind_conf->line);
return -1;
}
}
BUG/MINOR: ssl: support tune.ssl.cachesize 0 again Since the split of the shctx and the ssl cache, we lost the ability to disable the cache with tune.ssl.cachesize 0. Worst than that, when using this configuration, haproxy segfaults during the configuration parsing. Must be backported to 1.8.
2017-12-04 12:46:39 -05:00
if (!ssl_shctx && global.tune.sslcachesize) {
BUG/MEDIUM: ssl: don't allocate shctx several time The shctx_init() function does not check anymore if the pointer is not NULL, this check must be done is the caller. The consequence was to allocate one shctx per ssl bind. Bug introduced by 4f45bb9 ("MEDIUM: shctx: separate ssl and shctx") Thanks to Maciej Zdeb for reporting this bug. Must be backported to 1.8.
2017-11-28 05:04:43 -05:00
alloc_ctx = shctx_init(&ssl_shctx, global.tune.sslcachesize,
MINOR: shctx: Add a maximum object size parameter. This patch adds a new parameter to shctx_init() function to be used to limit the size of each shared object, -1 value meaning "no limit".
2018-10-22 10:21:39 -04:00
sizeof(struct sh_ssl_sess_hdr) + SHSESS_BLOCK_MIN_SIZE, -1,
MINOR: shctx: Remove 'use_shared_mem' variable This global variable was used to avoid using locks on shared_contexts in the unlikely case of nbthread==1. Since the locks do not do anything when USE_THREAD is not defined, it will be more beneficial to simply remove this variable and the systematic test on its value in the shared context locking functions.
2023-11-16 11:38:27 -05:00
sizeof(*sh_ssl_sess_tree));
BUG/MINOR: ssl: Wrong usage of shctx_init(). With this patch we check that shctx_init() does not return 0. Must be backported to 1.8.
2018-10-25 14:22:46 -04:00
if (alloc_ctx <= 0) {
BUG/MEDIUM: ssl: don't allocate shctx several time The shctx_init() function does not check anymore if the pointer is not NULL, this check must be done is the caller. The consequence was to allocate one shctx per ssl bind. Bug introduced by 4f45bb9 ("MEDIUM: shctx: separate ssl and shctx") Thanks to Maciej Zdeb for reporting this bug. Must be backported to 1.8.
2017-11-28 05:04:43 -05:00
if (alloc_ctx == SHCTX_E_INIT_LOCK)
ha_alert("Unable to initialize the lock for the shared SSL session cache. You can retry using the global statement 'tune.ssl.force-private-cache' but it could increase CPU usage due to renegotiations if nbproc > 1.\n");
else
ha_alert("Unable to allocate SSL session cache.\n");
return -1;
}
/* free block callback */
ssl_shctx->free_block = sh_ssl_sess_free_blocks;
/* init the root tree within the extra space */
sh_ssl_sess_tree = (void *)ssl_shctx + sizeof(struct shared_context);
*sh_ssl_sess_tree = EB_ROOT_UNIQUE;
MEDIUM: ssl_sock: implement ssl_sock_prepare_bind_conf() Instead of hard-coding all SSL preparation in cfgparse.c, we now register this new function as the transport layer's prepare_bind_conf() and call it only when definied. This removes some non-obvious SSL-specific code from cfgparse.c as well as a #ifdef.
2016-12-21 17:38:39 -05:00
}
err = 0;
/* initialize all certificate contexts */
err += ssl_sock_prepare_all_ctx(bind_conf);
/* initialize CA variables if the certificates generation is enabled */
err += ssl_sock_load_ca(bind_conf);
return -err;
}
MINOR: ssl: Release Servers SSL context when HAProxy is shut down [wt: could be backported to 1.5 as well]
2015-07-29 07:02:40 -04:00
BUG/MINOR: ssl: free the fields in srv->ssl_ctx A lot of free are missing in ssl_sock_free_srv_ctx(), this could result in memory leaking when removing dynamically a server via the CLI. This must be backported in every branches, by removing the fields that does not exist in the previous branches.
2021-12-30 05:25:43 -05:00
/* release ssl context allocated for servers. Most of the field free here
* must also be allocated in srv_ssl_settings_cpy() */
MINOR: ssl: Release Servers SSL context when HAProxy is shut down [wt: could be backported to 1.5 as well]
2015-07-29 07:02:40 -04:00
void ssl_sock_free_srv_ctx(struct server *srv)
{
MINOR: server: Add "alpn" and "npn" keywords. Add new keywords to "server" lines, alpn and npn. If set, when connecting through SSL, those alpn/npn will be negociated during the SSL handshake.
2018-11-20 17:33:50 -05:00
#ifdef TLSEXT_TYPE_application_layer_protocol_negotiation
BUG/MINOR: ssl: free the fields in srv->ssl_ctx A lot of free are missing in ssl_sock_free_srv_ctx(), this could result in memory leaking when removing dynamically a server via the CLI. This must be backported in every branches, by removing the fields that does not exist in the previous branches.
2021-12-30 05:25:43 -05:00
ha_free(&srv->ssl_ctx.alpn_str);
MINOR: server: Add "alpn" and "npn" keywords. Add new keywords to "server" lines, alpn and npn. If set, when connecting through SSL, those alpn/npn will be negociated during the SSL handshake.
2018-11-20 17:33:50 -05:00
#endif
BUILD/MINOR: ssl: fix build with non-alpn/non-npn libssl In commit c7566001 ("MINOR: server: Add "alpn" and "npn" keywords") and commit 201b9f4e ("MAJOR: connections: Defer mux creation for outgoing connection if alpn is set"), the build was broken on older OpenSSL releases. Move the #ifdef's around so that we build again with older OpenSSL releases (0.9.8 was tested).
2018-11-25 07:21:27 -05:00
#ifdef OPENSSL_NPN_NEGOTIATED
BUG/MINOR: ssl: free the fields in srv->ssl_ctx A lot of free are missing in ssl_sock_free_srv_ctx(), this could result in memory leaking when removing dynamically a server via the CLI. This must be backported in every branches, by removing the fields that does not exist in the previous branches.
2021-12-30 05:25:43 -05:00
ha_free(&srv->ssl_ctx.npn_str);
MINOR: ssl: free ctx when libssl doesn't support NPN The previous fix da95fd90 ("BUILD/MINOR: ssl: fix build with non-alpn/ non-npn libssl") does fix the build in old OpenSSL release, but I overlooked that the ctx is only freed when NPN is supported. Fix this by moving the #endif to the proper place (this was broken in c7566001 ("MINOR: server: Add "alpn" and "npn" keywords")).
2018-11-26 16:57:17 -05:00
#endif
CLEANUP: ssl: Release cached SSL sessions on deinit On deinit, when the server SSL ctx is released, we must take care to release the cached SSL sessions stored in the array <ssl_ctx.reused_sess>. There are global.nbthread entries in this array, each one may have a pointer on a cached session. This patch should fix the issue #802. No backport needed.
2020-10-07 07:20:23 -04:00
if (srv->ssl_ctx.reused_sess) {
int i;
BUG/MEDIUM: ssl: backend TLS resumption with sni and TLSv1.3 When establishing an outboud connection, haproxy checks if the cached TLS session has the same SNI as the connection we are trying to resume. This test was done by calling SSL_get_servername() which in TLSv1.2 returned the SNI. With TLSv1.3 this is not the case anymore and this function returns NULL, which invalidates any outboud connection we are trying to resume if it uses the sni keyword on its server line. This patch fixes the problem by storing the SNI in the "reused_sess" structure beside the session itself. The ssl_sock_set_servername() now has a RWLOCK because this session cache entry could be accessed by the CLI when trying to update a certificate on the backend. This fix must be backported in every maintained version, however the RWLOCK only exists since version 2.4.
2021-11-16 20:59:21 -05:00
for (i = 0; i < global.nbthread; i++) {
CLEANUP: ssl: make ssl_sock_free_srv_ctx() zero the pointers after free In ssl_sock_free_srv_ctx() there are some calls to free() which are not followed by a zeroing of the pointers. For now this function is only used during deinit but it could be used at run time in the near future, so better secure this.
2021-02-26 15:06:32 -05:00
ha_free(&srv->ssl_ctx.reused_sess[i].ptr);
BUG/MEDIUM: ssl: backend TLS resumption with sni and TLSv1.3 When establishing an outboud connection, haproxy checks if the cached TLS session has the same SNI as the connection we are trying to resume. This test was done by calling SSL_get_servername() which in TLSv1.2 returned the SNI. With TLSv1.3 this is not the case anymore and this function returns NULL, which invalidates any outboud connection we are trying to resume if it uses the sni keyword on its server line. This patch fixes the problem by storing the SNI in the "reused_sess" structure beside the session itself. The ssl_sock_set_servername() now has a RWLOCK because this session cache entry could be accessed by the CLI when trying to update a certificate on the backend. This fix must be backported in every maintained version, however the RWLOCK only exists since version 2.4.
2021-11-16 20:59:21 -05:00
ha_free(&srv->ssl_ctx.reused_sess[i].sni);
}
CLEANUP: ssl: make ssl_sock_free_srv_ctx() zero the pointers after free In ssl_sock_free_srv_ctx() there are some calls to free() which are not followed by a zeroing of the pointers. For now this function is only used during deinit but it could be used at run time in the near future, so better secure this.
2021-02-26 15:06:32 -05:00
ha_free(&srv->ssl_ctx.reused_sess);
CLEANUP: ssl: Release cached SSL sessions on deinit On deinit, when the server SSL ctx is released, we must take care to release the cached SSL sessions stored in the array <ssl_ctx.reused_sess>. There are global.nbthread entries in this array, each one may have a pointer on a cached session. This patch should fix the issue #802. No backport needed.
2020-10-07 07:20:23 -04:00
}
CLEANUP: ssl: make ssl_sock_free_srv_ctx() zero the pointers after free In ssl_sock_free_srv_ctx() there are some calls to free() which are not followed by a zeroing of the pointers. For now this function is only used during deinit but it could be used at run time in the near future, so better secure this.
2021-02-26 15:06:32 -05:00
if (srv->ssl_ctx.ctx) {
MINOR: ssl: Release Servers SSL context when HAProxy is shut down [wt: could be backported to 1.5 as well]
2015-07-29 07:02:40 -04:00
SSL_CTX_free(srv->ssl_ctx.ctx);
CLEANUP: ssl: make ssl_sock_free_srv_ctx() zero the pointers after free In ssl_sock_free_srv_ctx() there are some calls to free() which are not followed by a zeroing of the pointers. For now this function is only used during deinit but it could be used at run time in the near future, so better secure this.
2021-02-26 15:06:32 -05:00
srv->ssl_ctx.ctx = NULL;
}
BUG/MINOR: ssl: free the fields in srv->ssl_ctx A lot of free are missing in ssl_sock_free_srv_ctx(), this could result in memory leaking when removing dynamically a server via the CLI. This must be backported in every branches, by removing the fields that does not exist in the previous branches.
2021-12-30 05:25:43 -05:00
ha_free(&srv->ssl_ctx.ca_file);
ha_free(&srv->ssl_ctx.crl_file);
ha_free(&srv->ssl_ctx.client_crt);
ha_free(&srv->ssl_ctx.verify_host);
#ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME
ha_free(&srv->sni_expr);
BUG/MINOR: server/ssl: free the SNI sample expression ASAN complains about the SNI expression not being free upon an haproxy -c. Indeed the httpclient is now initialized with a sni expression and this one is never free in the server release code. Must be backported in 2.5 and could be backported in every stable versions.
2022-03-16 12:48:19 -04:00
release_sample_expr(srv->ssl_ctx.sni);
srv->ssl_ctx.sni = NULL;
BUG/MINOR: ssl: free the fields in srv->ssl_ctx A lot of free are missing in ssl_sock_free_srv_ctx(), this could result in memory leaking when removing dynamically a server via the CLI. This must be backported in every branches, by removing the fields that does not exist in the previous branches.
2021-12-30 05:25:43 -05:00
#endif
ha_free(&srv->ssl_ctx.ciphers);
#ifdef HAVE_SSL_CTX_SET_CIPHERSUITES
ha_free(&srv->ssl_ctx.ciphersuites);
#endif
BUG/MEDIUM: ssl: free the ckch instance linked to a server This patch unlinks and frees the ckch instance linked to a server during the free of this server. This could have locked certificates in a "Used" state when removing servers dynamically from the CLI. And could provoke a segfault once we try to dynamically update the certificate after that. This must be backported as far as 2.4.
2021-12-30 08:45:19 -05:00
/* If there is a certificate we must unlink the ckch instance */
ckch_inst_free(srv->ssl_ctx.inst);
MINOR: ssl: Release Servers SSL context when HAProxy is shut down [wt: could be backported to 1.5 as well]
2015-07-29 07:02:40 -04:00
}
MEDIUM: config: replace ssl_conf by bind_conf Some settings need to be merged per-bind config line and are not necessarily SSL-specific. It becomes quite inconvenient to have this ssl_conf SSL-specific, so let's replace it with something more generic.
2012-09-13 11:54:29 -04:00
/* Walks down the two trees in bind_conf and frees all the certs. The pointer may
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
* be NULL, in which case nothing is done. The default_ctx is nullified too.
*/
MEDIUM: config: replace ssl_conf by bind_conf Some settings need to be merged per-bind config line and are not necessarily SSL-specific. It becomes quite inconvenient to have this ssl_conf SSL-specific, so let's replace it with something more generic.
2012-09-13 11:54:29 -04:00
void ssl_sock_free_all_ctx(struct bind_conf *bind_conf)
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
{
struct ebmb_node *node, *back;
struct sni_ctx *sni;
MEDIUM: config: replace ssl_conf by bind_conf Some settings need to be merged per-bind config line and are not necessarily SSL-specific. It becomes quite inconvenient to have this ssl_conf SSL-specific, so let's replace it with something more generic.
2012-09-13 11:54:29 -04:00
node = ebmb_first(&bind_conf->sni_ctx);
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
while (node) {
sni = ebmb_entry(node, struct sni_ctx, name);
back = ebmb_next(node);
ebmb_delete(node);
CLEANUP: ssl: use the refcount for the SSL_CTX' Use the refcount of the SSL_CTX' to free them instead of freeing them on certains conditions. That way we can free the SSL_CTX everywhere its pointer is used.
2020-04-08 10:11:26 -04:00
SSL_CTX_free(sni->ctx);
CLEANUP: lists/tree-wide: rename some list operations to avoid some confusion The current "ADD" vs "ADDQ" is confusing because when thinking in terms of appending at the end of a list, "ADD" naturally comes to mind, but here it does the opposite, it inserts. Several times already it's been incorrectly used where ADDQ was expected, the latest of which was a fortunate accident explained in 6fa922562 ("CLEANUP: stream: explain why we queue the stream at the head of the server list"). Let's use more explicit (but slightly longer) names now: LIST_ADD -> LIST_INSERT LIST_ADDQ -> LIST_APPEND LIST_ADDED -> LIST_INLIST LIST_DEL -> LIST_DELETE The same is true for MT_LISTs, including their "TRY" variant. LIST_DEL_INIT keeps its short name to encourage to use it instead of the lazier LIST_DELETE which is often less safe. The change is large (~674 non-comment entries) but is mechanical enough to remain safe. No permutation was performed, so any out-of-tree code can easily map older names to new ones. The list doc was updated.
2021-04-21 01:32:39 -04:00
LIST_DELETE(&sni->by_ckch_inst);
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
free(sni);
node = back;
}
MEDIUM: config: replace ssl_conf by bind_conf Some settings need to be merged per-bind config line and are not necessarily SSL-specific. It becomes quite inconvenient to have this ssl_conf SSL-specific, so let's replace it with something more generic.
2012-09-13 11:54:29 -04:00
node = ebmb_first(&bind_conf->sni_w_ctx);
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
while (node) {
sni = ebmb_entry(node, struct sni_ctx, name);
back = ebmb_next(node);
ebmb_delete(node);
CLEANUP: ssl: use the refcount for the SSL_CTX' Use the refcount of the SSL_CTX' to free them instead of freeing them on certains conditions. That way we can free the SSL_CTX everywhere its pointer is used.
2020-04-08 10:11:26 -04:00
SSL_CTX_free(sni->ctx);
CLEANUP: lists/tree-wide: rename some list operations to avoid some confusion The current "ADD" vs "ADDQ" is confusing because when thinking in terms of appending at the end of a list, "ADD" naturally comes to mind, but here it does the opposite, it inserts. Several times already it's been incorrectly used where ADDQ was expected, the latest of which was a fortunate accident explained in 6fa922562 ("CLEANUP: stream: explain why we queue the stream at the head of the server list"). Let's use more explicit (but slightly longer) names now: LIST_ADD -> LIST_INSERT LIST_ADDQ -> LIST_APPEND LIST_ADDED -> LIST_INLIST LIST_DEL -> LIST_DELETE The same is true for MT_LISTs, including their "TRY" variant. LIST_DEL_INIT keeps its short name to encourage to use it instead of the lazier LIST_DELETE which is often less safe. The change is large (~674 non-comment entries) but is mechanical enough to remain safe. No permutation was performed, so any out-of-tree code can easily map older names to new ones. The list doc was updated.
2021-04-21 01:32:39 -04:00
LIST_DELETE(&sni->by_ckch_inst);
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
free(sni);
node = back;
}
MINOR: ssl: move the ckch/crtlist deinit to ssl_sock.c Move the ckch_deinit() and crtlist_deinit() call to ssl_sock.c, also unlink the SNI from the ckch_inst because they are free'd before in ssl_sock_free_all_ctx().
2020-06-24 03:54:29 -04:00
BUG/MEDIUM: ssl: in bind line, ssl-options after 'crt' are ignored. Bug introduced with "removes SSL_CTX_set_ssl_version call and cleanup CTX creation": ssl_sock_new_ctx is called before all the bind line is parsed. The fix consists of separating the use of default_ctx as the initialization context of the SSL connection via bind_conf->initial_ctx. Initial_ctx contains all the necessary parameters before performing the selection of the CTX: default_ctx is processed as others ctx without unnecessary parameters.
2017-03-06 09:34:44 -05:00
SSL_CTX_free(bind_conf->initial_ctx);
bind_conf->initial_ctx = NULL;
MEDIUM: ssl: add support for SNI and wildcard certificates A side effect of this change is that the "ssl" keyword on "bind" lines is now just a boolean and that "crt" is needed to designate certificate files or directories. Note that much refcounting was needed to have the free() work correctly due to the number of cert aliases which can make a context be shared by multiple names.
2012-09-07 11:30:07 -04:00
}
MINOR: ssl: move the ckch/crtlist deinit to ssl_sock.c Move the ckch_deinit() and crtlist_deinit() call to ssl_sock.c, also unlink the SNI from the ckch_inst because they are free'd before in ssl_sock_free_all_ctx().
2020-06-24 03:54:29 -04:00
void ssl_sock_deinit()
{
crtlist_deinit(); /* must be free'd before the ckchs */
ckch_deinit();
}
REGISTER_POST_DEINIT(ssl_sock_deinit);
MINOR: ssl_sock: implement ssl_sock_destroy_bind_conf() Instead of hard-coding all SSL destruction in cfgparse.c and haproxy.c, we now register this new function as the transport layer's destroy_bind_conf() and call it only when defined. This removes some non-obvious SSL-specific code and #ifdefs from cfgparse.c and haproxy.c
2016-12-22 11:30:54 -05:00
/* Destroys all the contexts for a bind_conf. This is used during deinit(). */
void ssl_sock_destroy_bind_conf(struct bind_conf *bind_conf)
{
ssl_sock_free_ca(bind_conf);
ssl_sock_free_all_ctx(bind_conf);
MAJOR: ssl: bind configuration per certificat crt-list is extend to support ssl configuration. You can now have such line in crt-list <file>: mycert.pem [npn h2,http/1.1] Support include "npn", "alpn", "verify", "ca_file", "crl_file", "ecdhe", "ciphers" configuration and ssl options. "crt-base" is also supported to fetch certificates.
2016-12-29 12:26:15 -05:00
ssl_sock_free_ssl_conf(&bind_conf->ssl_conf);
MINOR: ssl_sock: implement ssl_sock_destroy_bind_conf() Instead of hard-coding all SSL destruction in cfgparse.c and haproxy.c, we now register this new function as the transport layer's destroy_bind_conf() and call it only when defined. This removes some non-obvious SSL-specific code and #ifdefs from cfgparse.c and haproxy.c
2016-12-22 11:30:54 -05:00
free(bind_conf->ca_sign_file);
free(bind_conf->ca_sign_pass);
BUG/MINOR: ssl: properly ref-count the tls_keys entries Commit 200b0fa ("MEDIUM: Add support for updating TLS ticket keys via socket") introduced support for updating TLS ticket keys from the CLI, but missed a small corner case : if multiple bind lines reference the same tls_keys file, the same reference is used (as expected), but during the clean shutdown, it will lead to a double free when destroying the bind_conf contexts since none of the lines knows if others still use it. The impact is very low however, mostly a core and/or a message in the system's log upon old process termination. Let's introduce some basic refcounting to prevent this from happening, so that only the last bind_conf frees it. Thanks to Janusz Dziemidowicz and Thierry Fournier for both reporting the same issue with an easy reproducer. This fix needs to be backported from 1.6 to 1.8.
2018-07-17 04:05:32 -04:00
if (bind_conf->keys_ref && !--bind_conf->keys_ref->refcount) {
MINOR: ssl_sock: implement ssl_sock_destroy_bind_conf() Instead of hard-coding all SSL destruction in cfgparse.c and haproxy.c, we now register this new function as the transport layer's destroy_bind_conf() and call it only when defined. This removes some non-obvious SSL-specific code and #ifdefs from cfgparse.c and haproxy.c
2016-12-22 11:30:54 -05:00
free(bind_conf->keys_ref->filename);
free(bind_conf->keys_ref->tlskeys);
CLEANUP: lists/tree-wide: rename some list operations to avoid some confusion The current "ADD" vs "ADDQ" is confusing because when thinking in terms of appending at the end of a list, "ADD" naturally comes to mind, but here it does the opposite, it inserts. Several times already it's been incorrectly used where ADDQ was expected, the latest of which was a fortunate accident explained in 6fa922562 ("CLEANUP: stream: explain why we queue the stream at the head of the server list"). Let's use more explicit (but slightly longer) names now: LIST_ADD -> LIST_INSERT LIST_ADDQ -> LIST_APPEND LIST_ADDED -> LIST_INLIST LIST_DEL -> LIST_DELETE The same is true for MT_LISTs, including their "TRY" variant. LIST_DEL_INIT keeps its short name to encourage to use it instead of the lazier LIST_DELETE which is often less safe. The change is large (~674 non-comment entries) but is mechanical enough to remain safe. No permutation was performed, so any out-of-tree code can easily map older names to new ones. The list doc was updated.
2021-04-21 01:32:39 -04:00
LIST_DELETE(&bind_conf->keys_ref->list);
MINOR: ssl_sock: implement ssl_sock_destroy_bind_conf() Instead of hard-coding all SSL destruction in cfgparse.c and haproxy.c, we now register this new function as the transport layer's destroy_bind_conf() and call it only when defined. This removes some non-obvious SSL-specific code and #ifdefs from cfgparse.c and haproxy.c
2016-12-22 11:30:54 -05:00
free(bind_conf->keys_ref);
}
bind_conf->keys_ref = NULL;
bind_conf->ca_sign_pass = NULL;
bind_conf->ca_sign_file = NULL;
}
MINOR: ssl_sock: Initialize BIO and SSL objects outside of ssl_sock_init() This patch extraces the code which initializes the BIO and SSL session objects so that to reuse it elsewhere later for QUIC conections which only needs SSL and BIO objects at th TLS layer stack level to work.
2020-11-09 09:59:23 -05:00
/*
* Try to allocate the BIO and SSL session objects of <conn> connection with <bio> and
* <ssl> as addresses, <bio_meth> as BIO method and <ssl_ctx> as SSL context inherited settings.
* Connect the allocated BIO to the allocated SSL session. Also set <ctx> as address of custom
* data for the BIO and store <conn> as user data of the SSL session object.
CLEANUP: assorted typo fixes in the code and comments This is 14th iteration of typo fixes
2021-01-05 12:10:46 -05:00
* This is the responsibility of the caller to check the validity of all the pointers passed
MINOR: ssl_sock: Initialize BIO and SSL objects outside of ssl_sock_init() This patch extraces the code which initializes the BIO and SSL session objects so that to reuse it elsewhere later for QUIC conections which only needs SSL and BIO objects at th TLS layer stack level to work.
2020-11-09 09:59:23 -05:00
* as parameters to this function.
* Return 0 if succeeded, -1 if not. If failed, sets the ->err_code member of <conn> to
* CO_ER_SSL_NO_MEM.
*/
int ssl_bio_and_sess_init(struct connection *conn, SSL_CTX *ssl_ctx,
SSL **ssl, BIO **bio, BIO_METHOD *bio_meth, void *ctx)
{
int retry = 1;
retry:
/* Alloc a new SSL session. */
*ssl = SSL_new(ssl_ctx);
if (!*ssl) {
if (!retry--)
goto err;
pool_gc(NULL);
goto retry;
}
*bio = BIO_new(bio_meth);
if (!*bio) {
SSL_free(*ssl);
*ssl = NULL;
if (!retry--)
goto err;
pool_gc(NULL);
goto retry;
}
BIO_set_data(*bio, ctx);
SSL_set_bio(*ssl, *bio, *bio);
/* set connection pointer. */
if (!SSL_set_ex_data(*ssl, ssl_app_data_index, conn)) {
SSL_free(*ssl);
*ssl = NULL;
if (!retry--)
goto err;
pool_gc(NULL);
goto retry;
}
return 0;
err:
conn->err_code = CO_ER_SSL_NO_MEM;
return -1;
}
MEDIUM: connections: Implement a start() method in ssl_sock. Add a start() method to ssl_sock. It is responsible with initiating the SSL handshake, currently by just scheduling the tasklet, instead of doing it in the init() method, when all the XPRT may not have been initialized.
2021-03-05 17:47:00 -05:00
/* This function is called when all the XPRT have been initialized. We can
* now attempt to start the SSL handshake.
*/
static int ssl_sock_start(struct connection *conn, void *xprt_ctx)
{
struct ssl_sock_ctx *ctx = xprt_ctx;
if (ctx->xprt->start) {
int ret;
ret = ctx->xprt->start(conn, ctx->xprt_ctx);
if (ret < 0)
return ret;
}
tasklet_wakeup(ctx->wait_event.tasklet);
return 0;
}
BUG/MINOR: ssl: use a thread-safe sslconns increment Each time a new SSL context is allocated, global.sslconns is incremented. If global.maxsslconn is reached, the allocation is cancelled. This procedure was not entirely thread-safe due to the check and increment operations conducted at different stage. This could lead to global.maxsslconn slightly exceeded when several threads allocate SSL context while sslconns is near the limit. To fix this, use a CAS operation in a do/while loop. This code is similar to the actconn/maxconn increment for connection. A new function increment_sslconn() is defined for this operation. For the moment, only SSL code is using it. However, it is expected that QUIC will also use it to count QUIC connections as SSL ones. This should be backported to all stable releases. Note that prior to the 2.6, sslconns was outside of global struct, so this commit should be slightly adjusted.
2023-10-25 09:38:04 -04:00
/* Similar to increment_actconn() but for SSL connections. */
int increment_sslconn()
{
unsigned int count, next_sslconn;
do {
count = global.sslconns;
if (global.maxsslconn && count >= global.maxsslconn) {
/* maxconn reached */
next_sslconn = 0;
goto end;
}
/* try to increment sslconns */
next_sslconn = count + 1;
} while (!_HA_ATOMIC_CAS(&global.sslconns, &count, next_sslconn) && __ha_cpu_relax());
end:
return next_sslconn;
}
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
/*
* This function is called if SSL * context is not yet allocated. The function
* is designed to be called before any other data-layer operation and sets the
* handshake flag on the connection. It is safe to call it multiple times.
* It returns 0 on success and -1 in error case.
*/
MEDIUM: connections: Provide a xprt_ctx for each xprt method. For most of the xprt methods, provide a xprt_ctx. This will be useful later when we'll want to be able to stack xprts. The init() method now has to create and provide the said xprt_ctx if needed.
2019-03-21 13:27:17 -04:00
static int ssl_sock_init(struct connection *conn, void **xprt_ctx)
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
{
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
struct ssl_sock_ctx *ctx;
BUG/MINOR: ssl: use a thread-safe sslconns increment Each time a new SSL context is allocated, global.sslconns is incremented. If global.maxsslconn is reached, the allocation is cancelled. This procedure was not entirely thread-safe due to the check and increment operations conducted at different stage. This could lead to global.maxsslconn slightly exceeded when several threads allocate SSL context while sslconns is near the limit. To fix this, use a CAS operation in a do/while loop. This code is similar to the actconn/maxconn increment for connection. A new function increment_sslconn() is defined for this operation. For the moment, only SSL code is using it. However, it is expected that QUIC will also use it to count QUIC connections as SSL ones. This should be backported to all stable releases. Note that prior to the 2.6, sslconns was outside of global struct, so this commit should be slightly adjusted.
2023-10-25 09:38:04 -04:00
int next_sslconn = 0;
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
/* already initialized */
MEDIUM: connections: Provide a xprt_ctx for each xprt method. For most of the xprt methods, provide a xprt_ctx. This will be useful later when we'll want to be able to stack xprts. The init() method now has to create and provide the said xprt_ctx if needed.
2019-03-21 13:27:17 -04:00
if (*xprt_ctx)
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
return 0;
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
ctx = pool_alloc(ssl_sock_ctx_pool);
if (!ctx) {
conn->err_code = CO_ER_SSL_NO_MEM;
return -1;
}
CLEANUP: connection: rename the wait_event.task field to .tasklet It's really confusing to call it a task because it's a tasklet and used in places where tasks and tasklets are used together. Let's rename it to tasklet to remove this confusion.
2019-06-14 08:42:29 -04:00
ctx->wait_event.tasklet = tasklet_new();
if (!ctx->wait_event.tasklet) {
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
conn->err_code = CO_ER_SSL_NO_MEM;
pool_free(ssl_sock_ctx_pool, ctx);
return -1;
}
CLEANUP: connection: rename the wait_event.task field to .tasklet It's really confusing to call it a task because it's a tasklet and used in places where tasks and tasklets are used together. Let's rename it to tasklet to remove this confusion.
2019-06-14 08:42:29 -04:00
ctx->wait_event.tasklet->process = ssl_sock_io_cb;
ctx->wait_event.tasklet->context = ctx;
MINOR: ssl: mark the SSL handshake tasklet as heavy There's a fairness issue between SSL and clear text. A full end-to-end cleartext connection can require up to ~7.7 wakeups on average, plus 3.3 for the SSL tasklet, one of which is particularly expensive. So if we accept to process many handshakes taking 1ms each, we significantly increase the processing time of regular tasks just by adding an extra delay between their calls. Ideally in order to be fair we should have a 1:18 call ratio, but this requires a bit more accounting. With very little effort we can mark the SSL handshake tasklet as TASK_HEAVY until the handshake completes, and remove it once done. Doing so reduces from 14 to 3.0 ms the total response time experienced by HTTP clients running in parallel to 1000 SSL clients doing full handshakes in loops. Better, when tune.sched.low-latency is set to "on", the latency further drops to 1.8 ms. The tasks latency distribution explain pretty well what is happening: Without the patch: $ socat - /tmp/sock1 <<< "show profiling" Per-task CPU profiling : on # set profiling tasks {on|auto|off} Tasks activity: function calls cpu_tot cpu_avg lat_tot lat_avg ssl_sock_io_cb 2785375 19.35m 416.9us 5.401h 6.980ms h1_io_cb 1868949 9.853s 5.271us 4.829h 9.302ms process_stream 1864066 7.582s 4.067us 2.058h 3.974ms si_cs_io_cb 1733808 1.932s 1.114us 26.83m 928.5us h1_timeout_task 935760 - - 1.033h 3.975ms accept_queue_process 303606 4.627s 15.24us 16.65m 3.291ms srv_cleanup_toremove_connections452 64.31ms 142.3us 2.447s 5.415ms task_run_applet 47 5.149ms 109.6us 57.09ms 1.215ms srv_cleanup_idle_connections 34 2.210ms 65.00us 87.49ms 2.573ms With the patch: $ socat - /tmp/sock1 <<< "show profiling" Per-task CPU profiling : on # set profiling tasks {on|auto|off} Tasks activity: function calls cpu_tot cpu_avg lat_tot lat_avg ssl_sock_io_cb 3000365 21.08m 421.6us 20.30h 24.36ms h1_io_cb 2031932 9.278s 4.565us 46.70m 1.379ms process_stream 2010682 7.391s 3.675us 22.83m 681.2us si_cs_io_cb 1702070 1.571s 922.0ns 8.732m 307.8us h1_timeout_task 1009594 - - 17.63m 1.048ms accept_queue_process 339595 4.792s 14.11us 3.714m 656.2us srv_cleanup_toremove_connections779 75.42ms 96.81us 438.3ms 562.6us srv_cleanup_idle_connections 48 2.498ms 52.05us 178.1us 3.709us task_run_applet 17 1.738ms 102.3us 11.29ms 663.9us other 1 947.8us 947.8us 202.6us 202.6us => h1_io_cb() and process_stream() are divided by 6 while ssl_sock_io_cb() is multipled by 4 And with low-latency on: $ socat - /tmp/sock1 <<< "show profiling" Per-task CPU profiling : on # set profiling tasks {on|auto|off} Tasks activity: function calls cpu_tot cpu_avg lat_tot lat_avg ssl_sock_io_cb 3000565 20.96m 419.1us 20.74h 24.89ms h1_io_cb 2019702 9.294s 4.601us 49.22m 1.462ms process_stream 2009755 6.570s 3.269us 1.493m 44.57us si_cs_io_cb 1997820 1.566s 783.0ns 2.985m 89.66us h1_timeout_task 1009742 - - 1.647m 97.86us accept_queue_process 494509 4.697s 9.498us 1.240m 150.4us srv_cleanup_toremove_connections1120 92.32ms 82.43us 463.0ms 413.4us srv_cleanup_idle_connections 70 2.703ms 38.61us 204.5us 2.921us task_run_applet 13 1.303ms 100.3us 85.12us 6.548us => process_stream() is divided by 100 while ssl_sock_io_cb() is multipled by 4 Interestingly, the total HTTPS response time doesn't increase and even very slightly decreases, with an overall ~1% higher request rate. The net effect here is a redistribution of the CPU resources between internal tasks, and in the case of SSL, handshakes wait bit more but everything after completes faster. This was made simple enough to be backportable if it helps some users suffering from high latencies in mixed traffic.
2021-02-25 09:31:00 -05:00
ctx->wait_event.tasklet->state |= TASK_HEAVY; // assign it to the bulk queue during handshake
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
ctx->wait_event.events = 0;
MEDIUM: connections: Move some fields from struct connection to ssl_sock_ctx. Move xprt_st, tmp_early_data and sent_early_data from struct connection to struct ssl_sock_ctx, as they are only used in the SSL code.
2019-02-28 12:10:45 -05:00
ctx->sent_early_data = 0;
BUG/MEDIUM: ssl: Revamp the way early data are handled. Instead of attempting to read the early data only when the upper layer asks for data, allocate a temporary buffer, stored in the ssl_sock_ctx, and put all the early data in there. Requiring that the upper layer takes care of it means that if for some reason the upper layer wants to emit data before it has totally read the early data, we will be stuck forever. This should be backported to 2.1 and 2.0. This may fix github issue #411.
2019-12-19 09:02:39 -05:00
ctx->early_buf = BUF_NULL;
MEDIUM: ssl: provide our own BIO. Instead of letting the OpenSSL code handle the file descriptor directly, provide a custom BIO, that will use the underlying XPRT to send/recv data. This will let us implement QUIC later, and probably clean the upper layer, if/when the SSL code provide its own subscribe code, so that the upper layers won't have to care if we're still waiting for the handshake to complete or not.
2019-04-07 16:00:38 -04:00
ctx->conn = conn;
MEDIUM: ssl: merge recv_wait and send_wait in ssl_sock This is the same principle as previous commit, but for ssl_sock.
2020-01-10 03:20:26 -05:00
ctx->subs = NULL;
BUG/MAJOR: ssl: ssl_sock was not fully initialized. 'ssl_sock' wasn't fully initialized so a new session can inherit some flags from an old one. This causes some fetches, related to client's certificate presence or its verify status and errors, returning erroneous values. This issue could generate other unexpected behaviors because a new session could also inherit other flags such as SSL_SOCK_ST_FL_16K_WBFSIZE, SSL_SOCK_SEND_UNLIMITED, or SSL_SOCK_RECV_HEARTBEAT from an old session. This must be backported to 2.0 but it's useless for previous.
2019-09-06 09:36:02 -04:00
ctx->xprt_st = 0;
ctx->xprt_ctx = NULL;
MINOR: ssl: Rename ssl_bc_hsk_err to ssl_bc_err The ssl_bc_hsk_err sample fetch will need to raise more errors than only handshake related ones hence its renaming to a more generic ssl_bc_err. This patch is required because some handshake failures that should have been caught by this fetch (verify error on the server side for instance) were missed. This is caused by a change in TLS1.3 in which the 'Finished' state on the client is reached before its certificate is sent (and verified) on the server side (see the "Protocol Overview" part of RFC 8446). This means that the SSL_do_handshake call is finished long before the server can verify and potentially reject the client certificate. The ssl_bc_hsk_err will then need to be expanded to catch other types of errors. This change is also applied to the frontend fetches (ssl_fc_hsk_err becomes ssl_fc_err) and to their string counterparts.
2021-09-29 12:56:52 -04:00
ctx->error_code = 0;
MEDIUM: ssl: provide our own BIO. Instead of letting the OpenSSL code handle the file descriptor directly, provide a custom BIO, that will use the underlying XPRT to send/recv data. This will let us implement QUIC later, and probably clean the upper layer, if/when the SSL code provide its own subscribe code, so that the upper layers won't have to care if we're still waiting for the handshake to complete or not.
2019-04-07 16:00:38 -04:00
BUG/MINOR: ssl: use a thread-safe sslconns increment Each time a new SSL context is allocated, global.sslconns is incremented. If global.maxsslconn is reached, the allocation is cancelled. This procedure was not entirely thread-safe due to the check and increment operations conducted at different stage. This could lead to global.maxsslconn slightly exceeded when several threads allocate SSL context while sslconns is near the limit. To fix this, use a CAS operation in a do/while loop. This code is similar to the actconn/maxconn increment for connection. A new function increment_sslconn() is defined for this operation. For the moment, only SSL code is using it. However, it is expected that QUIC will also use it to count QUIC connections as SSL ones. This should be backported to all stable releases. Note that prior to the 2.6, sslconns was outside of global struct, so this commit should be slightly adjusted.
2023-10-25 09:38:04 -04:00
next_sslconn = increment_sslconn();
if (!next_sslconn) {
conn->err_code = CO_ER_SSL_TOO_MANY;
goto err;
}
MEDIUM: ssl: provide our own BIO. Instead of letting the OpenSSL code handle the file descriptor directly, provide a custom BIO, that will use the underlying XPRT to send/recv data. This will let us implement QUIC later, and probably clean the upper layer, if/when the SSL code provide its own subscribe code, so that the upper layers won't have to care if we're still waiting for the handshake to complete or not.
2019-04-07 16:00:38 -04:00
/* Only work with sockets for now, this should be adapted when we'll
* add QUIC support.
*/
ctx->xprt = xprt_get(XPRT_RAW);
MINOR: ssl: Make sure the underlying xprt's init method doesn't fail. In ssl_sock_init(), when initting the underlying xprt, check the return value, and give up if it fails.
2019-05-23 12:24:07 -04:00
if (ctx->xprt->init) {
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
if (ctx->xprt->init(conn, &ctx->xprt_ctx) != 0)
goto err;
MINOR: ssl: Make sure the underlying xprt's init method doesn't fail. In ssl_sock_init(), when initting the underlying xprt, check the return value, and give up if it fails.
2019-05-23 12:24:07 -04:00
}
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
/* If it is in client mode initiate SSL session
in connect state otherwise accept state */
MAJOR: connection: replace struct target with a pointer to an enum Instead of storing a couple of (int, ptr) in the struct connection and the struct session, we use a different method : we only store a pointer to an integer which is stored inside the target object and which contains a unique type identifier. That way, the pointer allows us to retrieve the object type (by dereferencing it) and the object's address (by computing the displacement in the target structure). The NULL pointer always corresponds to OBJ_TYPE_NONE. This reduces the size of the connection and session structs. It also simplifies target assignment and compare. In order to improve the generated code, we try to put the obj_type element at the beginning of all the structs (listener, server, proxy, si_applet), so that the original and target pointers are always equal. A lot of code was touched by massive replaces, but the changes are not that important.
2012-11-11 18:42:33 -05:00
if (objt_server(conn->target)) {
CLEANUP: ssl: keep a pointer to the server in ssl_sock_init() We're using about 6 times "__objt_server(conn->target)" there, it's not quite easy to read, let's keep a pointer to the server.
2023-08-30 06:00:29 -04:00
struct server *srv = __objt_server(conn->target);
if (ssl_bio_and_sess_init(conn, srv->ssl_ctx.ctx,
MINOR: ssl_sock: Initialize BIO and SSL objects outside of ssl_sock_init() This patch extraces the code which initializes the BIO and SSL session objects so that to reuse it elsewhere later for QUIC conections which only needs SSL and BIO objects at th TLS layer stack level to work.
2020-11-09 09:59:23 -05:00
&ctx->ssl, &ctx->bio, ha_meth, ctx) == -1)
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
goto err;
BUG/MEDIUM: ssl: fix bad ssl context init can cause segfault in case of OOM. Some SSL context's init functions errors were not handled and can cause a segfault due to an incomplete SSL context initialization. This fix must be backported to 1.5.
2014-11-12 11:35:37 -05:00
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
SSL_set_connect_state(ctx->ssl);
CLEANUP: ssl: keep a pointer to the server in ssl_sock_init() We're using about 6 times "__objt_server(conn->target)" there, it's not quite easy to read, let's keep a pointer to the server.
2023-08-30 06:00:29 -04:00
HA_RWLOCK_RDLOCK(SSL_SERVER_LOCK, &srv->ssl_ctx.lock);
if (srv->ssl_ctx.reused_sess[tid].ptr) {
DOC: ssl: add some comments about the non-obvious session allocation stuff The SSL session allocation/reuse part is far from being trivial, and there are some necessary tricks such as allocating then immediately freeing that are required by the API due to internal refcount. All of this is particularly hard to grasp, even with the scarce man pages. Let's document a little bit what's granted and expected along this path to help the reader later.
2023-08-21 05:17:10 -04:00
/* let's recreate a session from (ptr,size) and assign
* it to ctx->ssl. Its refcount will be updated by the
* creation and by the assignment, so after assigning
* it or failing to, we must always free it to decrement
* the refcount.
*/
CLEANUP: ssl: keep a pointer to the server in ssl_sock_init() We're using about 6 times "__objt_server(conn->target)" there, it's not quite easy to read, let's keep a pointer to the server.
2023-08-30 06:00:29 -04:00
const unsigned char *ptr = srv->ssl_ctx.reused_sess[tid].ptr;
SSL_SESSION *sess = d2i_SSL_SESSION(NULL, &ptr, srv->ssl_ctx.reused_sess[tid].size);
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
if (sess && !SSL_set_session(ctx->ssl, sess)) {
MINOR: server/ssl: clear the shared good session index on failure If we fail to set the session using SSL_set_session(), we want to quickly erase our index from the shared one so that any other thread with a valid session replaces it.
2023-08-21 06:04:01 -04:00
uint old_tid = HA_ATOMIC_LOAD(&srv->ssl_ctx.last_ssl_sess_tid); // 0=none, >0 = tid + 1
if (old_tid == tid + 1)
HA_ATOMIC_CAS(&srv->ssl_ctx.last_ssl_sess_tid, &old_tid, 0); // no more valid
MINOR: SSL: Store the ASN1 representation of client sessions. Instead of storing the SSL_SESSION pointer directly in the struct server, store the ASN1 representation, otherwise, session resumption is broken with TLS 1.3, when multiple outgoing connections want to use the same session.
2017-11-16 11:42:52 -05:00
SSL_SESSION_free(sess);
MEDIUM: server/ssl: place an rwlock in the per-thread ssl server session The goal will be to permit a thread to update its session while having it shared with other threads. For now we only place the lock and arrange the code around it so that this is quite light. For now only the owner thread uses this lock so there is no contention. Note that there is a subtlety in the openssl API regarding i2s_SSL_SESSION() in that it fills the area pointed to by its argument with a dump of the session and returns a size that's equal to the previously allocated one. As such, it does modify the shared area even if that's not obvious at first glance.
2023-08-21 02:41:49 -04:00
HA_RWLOCK_WRLOCK(SSL_SERVER_LOCK, &srv->ssl_ctx.reused_sess[tid].sess_lock);
CLEANUP: ssl: keep a pointer to the server in ssl_sock_init() We're using about 6 times "__objt_server(conn->target)" there, it's not quite easy to read, let's keep a pointer to the server.
2023-08-30 06:00:29 -04:00
ha_free(&srv->ssl_ctx.reused_sess[tid].ptr);
MEDIUM: server/ssl: place an rwlock in the per-thread ssl server session The goal will be to permit a thread to update its session while having it shared with other threads. For now we only place the lock and arrange the code around it so that this is quite light. For now only the owner thread uses this lock so there is no contention. Note that there is a subtlety in the openssl API regarding i2s_SSL_SESSION() in that it fills the area pointed to by its argument with a dump of the session and returns a size that's equal to the previously allocated one. As such, it does modify the shared area even if that's not obvious at first glance.
2023-08-21 02:41:49 -04:00
HA_RWLOCK_WRTORD(SSL_SERVER_LOCK, &srv->ssl_ctx.reused_sess[tid].sess_lock);
MEDIUM: ssl_sock: always use the SSL's server name, not the one from the tid In ssl_sock_set_servername(), we're retrieving the current server name from the current thread, hoping it will not have changed. This is a bit dangerous as strictly speaking it's not easy to prove that no other connection had to use one between the moment it was retrieved in ssl_sock_init() and the moment it's being read here. In addition, this forces us to maintain one session per thread while this is not the real need, in practice we only need one session per SNI. And the current model prevents us from sharing sessions between threads. This had been done in 2.5 via commit e18d4e828 ("BUG/MEDIUM: ssl: backend TLS resumption with sni and TLSv1.3"), but as analyzed with William, it turns out that a saner approach consists in keeping the call to SSL_get_servername() there and instead to always assign the SNI to the current SSL context via SSL_set_tlsext_host_name() immediately when the session is retreived. This way the session and SNI are consulted atomically and the host name is only checked from the session and not from possibly changing elements. As a bonus the rdlock that was added by that commit could now be removed, though it didn't cost much.
2023-08-30 06:02:33 -04:00
if (srv->ssl_ctx.reused_sess[tid].sni)
SSL_set_tlsext_host_name(ctx->ssl, srv->ssl_ctx.reused_sess[tid].sni);
MEDIUM: server/ssl: place an rwlock in the per-thread ssl server session The goal will be to permit a thread to update its session while having it shared with other threads. For now we only place the lock and arrange the code around it so that this is quite light. For now only the owner thread uses this lock so there is no contention. Note that there is a subtlety in the openssl API regarding i2s_SSL_SESSION() in that it fills the area pointed to by its argument with a dump of the session and returns a size that's equal to the previously allocated one. As such, it does modify the shared area even if that's not obvious at first glance.
2023-08-21 02:41:49 -04:00
HA_RWLOCK_RDUNLOCK(SSL_SERVER_LOCK, &srv->ssl_ctx.reused_sess[tid].sess_lock);
MINOR: SSL: Store the ASN1 representation of client sessions. Instead of storing the SSL_SESSION pointer directly in the struct server, store the ASN1 representation, otherwise, session resumption is broken with TLS 1.3, when multiple outgoing connections want to use the same session.
2017-11-16 11:42:52 -05:00
} else if (sess) {
DOC: ssl: add some comments about the non-obvious session allocation stuff The SSL session allocation/reuse part is far from being trivial, and there are some necessary tricks such as allocating then immediately freeing that are required by the API due to internal refcount. All of this is particularly hard to grasp, even with the scarce man pages. Let's document a little bit what's granted and expected along this path to help the reader later.
2023-08-21 05:17:10 -04:00
/* already assigned, not needed anymore */
MINOR: SSL: Store the ASN1 representation of client sessions. Instead of storing the SSL_SESSION pointer directly in the struct server, store the ASN1 representation, otherwise, session resumption is broken with TLS 1.3, when multiple outgoing connections want to use the same session.
2017-11-16 11:42:52 -05:00
SSL_SESSION_free(sess);
MEDIUM: server/ssl: place an rwlock in the per-thread ssl server session The goal will be to permit a thread to update its session while having it shared with other threads. For now we only place the lock and arrange the code around it so that this is quite light. For now only the owner thread uses this lock so there is no contention. Note that there is a subtlety in the openssl API regarding i2s_SSL_SESSION() in that it fills the area pointed to by its argument with a dump of the session and returns a size that's equal to the previously allocated one. As such, it does modify the shared area even if that's not obvious at first glance.
2023-08-21 02:41:49 -04:00
HA_RWLOCK_RDLOCK(SSL_SERVER_LOCK, &srv->ssl_ctx.reused_sess[tid].sess_lock);
MEDIUM: ssl_sock: always use the SSL's server name, not the one from the tid In ssl_sock_set_servername(), we're retrieving the current server name from the current thread, hoping it will not have changed. This is a bit dangerous as strictly speaking it's not easy to prove that no other connection had to use one between the moment it was retrieved in ssl_sock_init() and the moment it's being read here. In addition, this forces us to maintain one session per thread while this is not the real need, in practice we only need one session per SNI. And the current model prevents us from sharing sessions between threads. This had been done in 2.5 via commit e18d4e828 ("BUG/MEDIUM: ssl: backend TLS resumption with sni and TLSv1.3"), but as analyzed with William, it turns out that a saner approach consists in keeping the call to SSL_get_servername() there and instead to always assign the SNI to the current SSL context via SSL_set_tlsext_host_name() immediately when the session is retreived. This way the session and SNI are consulted atomically and the host name is only checked from the session and not from possibly changing elements. As a bonus the rdlock that was added by that commit could now be removed, though it didn't cost much.
2023-08-30 06:02:33 -04:00
if (srv->ssl_ctx.reused_sess[tid].sni)
SSL_set_tlsext_host_name(ctx->ssl, srv->ssl_ctx.reused_sess[tid].sni);
MEDIUM: server/ssl: place an rwlock in the per-thread ssl server session The goal will be to permit a thread to update its session while having it shared with other threads. For now we only place the lock and arrange the code around it so that this is quite light. For now only the owner thread uses this lock so there is no contention. Note that there is a subtlety in the openssl API regarding i2s_SSL_SESSION() in that it fills the area pointed to by its argument with a dump of the session and returns a size that's equal to the previously allocated one. As such, it does modify the shared area even if that's not obvious at first glance.
2023-08-21 02:41:49 -04:00
HA_RWLOCK_RDUNLOCK(SSL_SERVER_LOCK, &srv->ssl_ctx.reused_sess[tid].sess_lock);
BUG/MEDIUM: ssl: fix bad ssl context init can cause segfault in case of OOM. Some SSL context's init functions errors were not handled and can cause a segfault due to an incomplete SSL context initialization. This fix must be backported to 1.5.
2014-11-12 11:35:37 -05:00
}
MEDIUM: server/ssl: pick another thread's session when we have none yet The per-thread SSL context in servers causes a burst of connection renegotiations on startup, both for the forwarded traffic and for the health checks. Health checks have been seen to continue to cause SSL rekeying for several minutes after a restart on large thread-count machines. The reason is that the context is exlusively per-thread and that the more threads there are, the more likely it is for a new connection to start on a thread that doesn't have such a context yet. In order to improve this situation, this commit ensures that a thread starting an SSL connection to a server without a session will first look at the last session that was updated by another thread, and will try to use it. In order to minimize the contention, we're using a read lock here to protect the data, and the first-level index is an integer containing the thread number, that is always valid and may always be dereferenced. This way the session retrieval algorithm becomes quite simple: - if the last thread index is valid, then try to use the same session under a read lock ; - if any error happens, then atomically nuke the index so that other threads don't use it and the next one to update a connection updates it again And for the ssl_sess_new_srv_cb(), we have this: - update the entry under a write lock if the new session is valid, otherwise kill it if the session is not valid; - atomically update the index if it was 0 and the new one is valid, otherwise atomically nuke it if the session failed. Note that even if only the pointer is destroyed, the element will be re-allocated by the next thread during the sess_new_srv_sb(). Right now a session is picked even if the SNI doesn't match, because we don't know the SNI yet during ssl_sock_init(), but that's essentially a matter of API, since connect_server() figures the SNI very early, then calls conn_prepare() which calls ssl_sock_init(). Thus in the future we could easily imaging storing a number of SNI-based contexts instead of storing contexts per thread. It could be worth backporting this to one LTS version after some observation, though this is not strictly necessary. the current commit depends on the following ones: BUG/MINOR: ssl_sock: fix possible memory leak on OOM MINOR: ssl_sock: avoid iterating realloc(+1) on stored context DOC: ssl: add some comments about the non-obvious session allocation stuff CLEANUP: ssl: keep a pointer to the server in ssl_sock_init() MEDIUM: ssl_sock: always use the SSL's server name, not the one from the tid MEDIUM: server/ssl: place an rwlock in the per-thread ssl server session MINOR: server/ssl: maintain an index of the last known valid SSL session MINOR: server/ssl: clear the shared good session index on failure MEDIUM: server/ssl: pick another thread's session when we have none yet
2023-08-21 06:12:12 -04:00
} else {
/* No session available yet, let's see if we can pick one
* from another thread. If old_tid is non-null, it designates
* the index of a recently updated thread that might still have
* a usable session. All threads are collectively responsible
* for resetting the index if it fails.
*/
const unsigned char *ptr;
SSL_SESSION *sess;
uint old_tid = HA_ATOMIC_LOAD(&srv->ssl_ctx.last_ssl_sess_tid); // 0=none, >0 = tid + 1
if (old_tid) {
HA_RWLOCK_RDLOCK(SSL_SERVER_LOCK, &srv->ssl_ctx.reused_sess[old_tid-1].sess_lock);
ptr = srv->ssl_ctx.reused_sess[old_tid-1].ptr;
if (ptr) {
sess = d2i_SSL_SESSION(NULL, &ptr, srv->ssl_ctx.reused_sess[old_tid-1].size);
if (sess) {
if (!SSL_set_session(ctx->ssl, sess))
HA_ATOMIC_CAS(&srv->ssl_ctx.last_ssl_sess_tid, &old_tid, 0); // no more valid
SSL_SESSION_free(sess);
}
}
if (srv->ssl_ctx.reused_sess[old_tid-1].sni)
SSL_set_tlsext_host_name(ctx->ssl, srv->ssl_ctx.reused_sess[old_tid-1].sni);
HA_RWLOCK_RDUNLOCK(SSL_SERVER_LOCK, &srv->ssl_ctx.reused_sess[old_tid-1].sess_lock);
}
BUG/MEDIUM: ssl: fix bad ssl context init can cause segfault in case of OOM. Some SSL context's init functions errors were not handled and can cause a segfault due to an incomplete SSL context initialization. This fix must be backported to 1.5.
2014-11-12 11:35:37 -05:00
}
CLEANUP: ssl: keep a pointer to the server in ssl_sock_init() We're using about 6 times "__objt_server(conn->target)" there, it's not quite easy to read, let's keep a pointer to the server.
2023-08-30 06:00:29 -04:00
HA_RWLOCK_RDUNLOCK(SSL_SERVER_LOCK, &srv->ssl_ctx.lock);
MINOR: ssl: Add statement 'verifyhost' to "server" statements verifyhost allows you to specify a hostname that the remote server's SSL certificate must match. Connections that don't match will be closed with an SSL error.
2013-06-27 03:05:25 -04:00
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
/* leave init state and start handshake */
BUG: ssl: mark the connection as waiting for an SSL connection during the handshake The WAIT_L6_CONN was designed especially to ensure that the connection was not marked ready before the SSL layer was OK, but we forgot to set the flag, resulting in a rejected handshake when ssl was combined with accept-proxy because accept-proxy would validate the connection alone and the SSL handshake would then believe in a client-initiated reneg and kill it.
2012-09-04 02:03:39 -04:00
conn->flags |= CO_FL_SSL_WAIT_HS | CO_FL_WAIT_L6_CONN;
MEDIUM: config: implement maxsslconn in the global section SSL connections take a huge amount of memory, and unfortunately openssl does not check malloc() returns and easily segfaults when too many connections are used. The only solution against this is to provide a global maxsslconn setting to reject SSL connections above the limit in order to avoid reaching unsafe limits.
2012-09-06 05:58:37 -04:00
REORG: ssl-sock: move the sslconns/totalsslconns counters to global These two counters were the only ones not in the global struct, while the SSL freq counters or the req counts are already in it, this forces stats.c to include ssl_sock just to know about them. Let's move them over there with their friends. This reduces from 408 to 384 the number of includes of opensslconf.h.
2021-10-06 06:15:18 -04:00
_HA_ATOMIC_INC(&global.totalsslconns);
MEDIUM: connections: Provide a xprt_ctx for each xprt method. For most of the xprt methods, provide a xprt_ctx. This will be useful later when we'll want to be able to stack xprts. The init() method now has to create and provide the said xprt_ctx if needed.
2019-03-21 13:27:17 -04:00
*xprt_ctx = ctx;
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
return 0;
}
MAJOR: connection: replace struct target with a pointer to an enum Instead of storing a couple of (int, ptr) in the struct connection and the struct session, we use a different method : we only store a pointer to an integer which is stored inside the target object and which contains a unique type identifier. That way, the pointer allows us to retrieve the object type (by dereferencing it) and the object's address (by computing the displacement in the target structure). The NULL pointer always corresponds to OBJ_TYPE_NONE. This reduces the size of the connection and session structs. It also simplifies target assignment and compare. In order to improve the generated code, we try to put the obj_type element at the beginning of all the structs (listener, server, proxy, si_applet), so that the original and target pointers are always equal. A lot of code was touched by massive replaces, but the changes are not that important.
2012-11-11 18:42:33 -05:00
else if (objt_listener(conn->target)) {
MINOR: ssl_sock: Initialize BIO and SSL objects outside of ssl_sock_init() This patch extraces the code which initializes the BIO and SSL session objects so that to reuse it elsewhere later for QUIC conections which only needs SSL and BIO objects at th TLS layer stack level to work.
2020-11-09 09:59:23 -05:00
struct bind_conf *bc = __objt_listener(conn->target)->bind_conf;
if (ssl_bio_and_sess_init(conn, bc->initial_ctx,
&ctx->ssl, &ctx->bio, ha_meth, ctx) == -1)
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
goto err;
BUG/MEDIUM: ssl: fix bad ssl context init can cause segfault in case of OOM. Some SSL context's init functions errors were not handled and can cause a segfault due to an incomplete SSL context initialization. This fix must be backported to 1.5.
2014-11-12 11:35:37 -05:00
BUILD: ssl: more elegant OpenSSL early data support check BorinSSL pretends to be 1.1.1 version of OpenSSL. It messes some version based feature presense checks. For example, OpenSSL specific early data support. Let us change that feature detction to SSL_READ_EARLY_DATA_SUCCESS macro check instead of version comparision.
2020-10-24 14:42:30 -04:00
#ifdef SSL_READ_EARLY_DATA_SUCCESS
MINOR: ssl_sock: Initialize BIO and SSL objects outside of ssl_sock_init() This patch extraces the code which initializes the BIO and SSL session objects so that to reuse it elsewhere later for QUIC conections which only needs SSL and BIO objects at th TLS layer stack level to work.
2020-11-09 09:59:23 -05:00
if (bc->ssl_conf.early_data) {
BUG/MINOR: ssl: Possible memleak when allowing the 0RTT data buffer. ​ As the server early data buffer is allocated in the middle of the loop used to allocate the SSL session without being freed before retrying, this leads to a memory leak. ​ To fix this we move the section of code responsible of this early data buffer alloction after the one reponsible of allocating the SSL session. ​ Must be backported to 2.1 and 2.0.
2020-01-24 08:56:18 -05:00
b_alloc(&ctx->early_buf);
SSL_set_max_early_data(ctx->ssl,
/* Only allow early data if we managed to allocate
* a buffer.
*/
(!b_is_null(&ctx->early_buf)) ?
global.tune.bufsize - global.tune.maxrewrite : 0);
}
#endif
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
SSL_set_accept_state(ctx->ssl);
MEDIUM: ssl: protect against client-initiated renegociation CVE-2009-3555 suggests that client-initiated renegociation should be prevented in the middle of data. The workaround here consists in having the SSL layer notify our callback about a handshake occurring, which in turn causes the connection to be marked in the error state if it was already considered established (which means if a previous handshake was completed). The result is that the connection with the client is immediately aborted and any pending data are dropped.
2012-09-03 14:36:47 -04:00
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
/* leave init state and start handshake */
BUG: ssl: mark the connection as waiting for an SSL connection during the handshake The WAIT_L6_CONN was designed especially to ensure that the connection was not marked ready before the SSL layer was OK, but we forgot to set the flag, resulting in a rejected handshake when ssl was combined with accept-proxy because accept-proxy would validate the connection alone and the SSL handshake would then believe in a client-initiated reneg and kill it.
2012-09-04 02:03:39 -04:00
conn->flags |= CO_FL_SSL_WAIT_HS | CO_FL_WAIT_L6_CONN;
BUILD: ssl: more elegant OpenSSL early data support check BorinSSL pretends to be 1.1.1 version of OpenSSL. It messes some version based feature presense checks. For example, OpenSSL specific early data support. Let us change that feature detction to SSL_READ_EARLY_DATA_SUCCESS macro check instead of version comparision.
2020-10-24 14:42:30 -04:00
#ifdef SSL_READ_EARLY_DATA_SUCCESS
BUG/MINOR: ssl: do not try to use early data if not configured The CO_FL_EARLY_SSL_HS flag was inconditionally set on the connection, resulting in SSL_read_early_data() always being used first in handshake calculations. While this seems to work well (probably that there are fallback paths inside openssl), it's particularly confusing and makes the debugging quite complicated. It possibly is not optimal by the way. This flag ought to be set only when early_data is configured on the bind line. Apparently there used to be a good reason for doing it this way in 1.8 times, but it really does not make sense anymore. It may be OK to backport this to 2.3 if this helps with troubleshooting, but better not go too far as it's unlikely to fix any real issue while it could introduce some in old versions.
2021-02-03 05:21:38 -05:00
if (bc->ssl_conf.early_data)
conn->flags |= CO_FL_EARLY_SSL_HS;
MEDIUM: ssl: Handle early data with OpenSSL 1.1.1 When compiled with Openssl >= 1.1.1, before attempting to do the handshake, try to read any early data. If any early data is present, then we'll create the session, read the data, and handle the request before we're doing the handshake. For this, we add a new connection flag, CO_FL_EARLY_SSL_HS, which is not part of the CO_FL_HANDSHAKE set, allowing to proceed with a session even before an SSL handshake is completed. As early data do have security implication, we let the origin server know the request comes from early data by adding the "Early-Data" header, as specified in this draft from the HTTP working group : https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-replay
2017-09-22 12:26:28 -04:00
#endif
MEDIUM: config: implement maxsslconn in the global section SSL connections take a huge amount of memory, and unfortunately openssl does not check malloc() returns and easily segfaults when too many connections are used. The only solution against this is to provide a global maxsslconn setting to reject SSL connections above the limit in order to avoid reaching unsafe limits.
2012-09-06 05:58:37 -04:00
REORG: ssl-sock: move the sslconns/totalsslconns counters to global These two counters were the only ones not in the global struct, while the SSL freq counters or the req counts are already in it, this forces stats.c to include ssl_sock just to know about them. Let's move them over there with their friends. This reduces from 408 to 384 the number of includes of opensslconf.h.
2021-10-06 06:15:18 -04:00
_HA_ATOMIC_INC(&global.totalsslconns);
MEDIUM: connections: Provide a xprt_ctx for each xprt method. For most of the xprt methods, provide a xprt_ctx. This will be useful later when we'll want to be able to stack xprts. The init() method now has to create and provide the said xprt_ctx if needed.
2019-03-21 13:27:17 -04:00
*xprt_ctx = ctx;
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
return 0;
}
/* don't know how to handle such a target */
MEDIUM: connection: add error reporting for the SSL Get a bit more info in the logs when client-side SSL handshakes fail.
2012-12-03 10:32:10 -05:00
conn->err_code = CO_ER_SSL_NO_TARGET;
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
err:
BUG/MINOR: ssl: use a thread-safe sslconns increment Each time a new SSL context is allocated, global.sslconns is incremented. If global.maxsslconn is reached, the allocation is cancelled. This procedure was not entirely thread-safe due to the check and increment operations conducted at different stage. This could lead to global.maxsslconn slightly exceeded when several threads allocate SSL context while sslconns is near the limit. To fix this, use a CAS operation in a do/while loop. This code is similar to the actconn/maxconn increment for connection. A new function increment_sslconn() is defined for this operation. For the moment, only SSL code is using it. However, it is expected that QUIC will also use it to count QUIC connections as SSL ones. This should be backported to all stable releases. Note that prior to the 2.6, sslconns was outside of global struct, so this commit should be slightly adjusted.
2023-10-25 09:38:04 -04:00
if (next_sslconn)
_HA_ATOMIC_DEC(&global.sslconns);
CLEANUP: connection: rename the wait_event.task field to .tasklet It's really confusing to call it a task because it's a tasklet and used in places where tasks and tasklets are used together. Let's rename it to tasklet to remove this confusion.
2019-06-14 08:42:29 -04:00
if (ctx && ctx->wait_event.tasklet)
tasklet_free(ctx->wait_event.tasklet);
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
pool_free(ssl_sock_ctx_pool, ctx);
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
return -1;
}
/* This is the callback which is used when an SSL handshake is pending. It
* updates the FD status if it wants some polling before being called again.
* It returns 0 if it fails in a fatal way or needs to poll to go further,
* otherwise it returns non-zero and removes itself from the connection's
* flags (the bit is provided in <flag> by the caller).
*/
MINOR: ssl: Make ssl_sock_handshake() static. ssl_sock_handshake is now only used by the ssl code itself, there's no need to export it anymore, so make it static.
2019-05-23 08:45:12 -04:00
static int ssl_sock_handshake(struct connection *conn, unsigned int flag)
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
{
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
struct ssl_sock_ctx *ctx = conn_get_ssl_sock_ctx(conn);
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
int ret;
BUILD: ssl: silence build warning on uninitialised counters Since commit d0447a7c3 ("MINOR: ssl: add counters for ssl sessions"), gcc 9+ complains about this: CC src/ssl_sock.o src/ssl_sock.c: In function 'ssl_sock_io_cb': src/ssl_sock.c:5416:3: warning: 'counters_px' may be used uninitialized in this function [-Wmaybe-uninitialized] 5416 | ++counters_px->reused_sess; | ^~~~~~~~~~~~~~~~~~~~~~~~~~ src/ssl_sock.c:5133:23: note: 'counters_px' was declared here 5133 | struct ssl_counters *counters, *counters_px; | ^~~~~~~~~~~ Either a listener or a server are expected there, so ther counters are always initialized and the compiler cannot know this. Let's preset them and test before updating the counter, we're not in a hot path here. No backport is needed.
2020-11-06 07:19:18 -05:00
struct ssl_counters *counters = NULL;
struct ssl_counters *counters_px = NULL;
MINOR: ssl: add counters for ssl sessions Add counters for newly established and resumed sessions.
2020-11-03 11:10:02 -05:00
struct listener *li;
struct server *srv;
BUG/MEDIUM: ssl: check a connection's status before computing a handshake As spotted in issue #822, we're having a problem with error detection in the SSL layer. The problem is that on an overwhelmed machine, accepted connections can start to pile up, each of them requiring a slow handshake, and during all this time if the client aborts, the handshake will still be calculated. The error controls are properly placed, it's just that the SSL layer reads records exactly of the advertised size, without having the ability to encounter a pending connection error. As such if injecting many TLS connections to a listener with a huge backlog, it's fairly possible to meet this situation: 12:50:48.236056 accept4(8, {sa_family=AF_INET, sin_port=htons(62794), sin_addr=inet_addr("127.0.0.1")}, [128->16], SOCK_NONBLOCK) = 1109 12:50:48.236071 setsockopt(1109, SOL_TCP, TCP_NODELAY, [1], 4) = 0 (process other connections' handshakes) 12:50:48.257270 getsockopt(1109, SOL_SOCKET, SO_ERROR, [ECONNRESET], [4]) = 0 (proof that error was detectable there but this code was added for the PoC) 12:50:48.257297 recvfrom(1109, "\26\3\1\2\0", 5, 0, NULL, NULL) = 5 12:50:48.257310 recvfrom(1109, "\1\0\1\3"..., 512, 0, NULL, NULL) = 512 (handshake calculation taking 700us) 12:50:48.258004 sendto(1109, "\26\3\3\0z"..., 1421, MSG_DONTWAIT|MSG_NOSIGNAL, NULL, 0) = -1 EPIPE (Broken pipe) 12:50:48.258036 close(1109) = 0 The situation was amplified by the multi-queue accept code, as it resulted in many incoming connections to be accepted long before they could be handled. Prior to this they would have been accepted and the handshake immediately started, which would have resulted in most of the connections waiting in the the system's accept queue, and dying there when the client aborted, thus the error would have been detected before even trying to pass them to the handshake code. As a result, with a listener running on a very large backlog, it's possible to quickly accept tens of thousands of connections and waste time slowly running their handshakes while they get replaced by other ones. This patch adds an SO_ERROR check on the connection's FD before starting the handshake. This is not pretty as it requires to access the FD, but it does the job. Some improvements should be made over the long term so that the transport layers can report extra information with their ->rcv_buf() call, or at the very least, implement a ->get_conn_status() function to report various flags such as shutr, shutw, error at various stages, allowing an upper layer to inquire for the relevance of engaging into a long operation if it's known the connection is not usable anymore. An even simpler step could probably consist in implementing this in the control layer. This patch is simple enough to be backported as far as 2.0. Many thanks to @ngaugler for his numerous tests with detailed feedback.
2021-02-02 09:42:25 -05:00
socklen_t lskerr;
int skerr;
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
CLEANUP: connection: use conn_ctrl_ready() instead of checking the flag It's easier and safer to rely on conn_ctrl_ready() everywhere than to check the flag itself. It will also simplify adding extra checks later if needed. Some useless controls for !ctrl have been removed, as the CTRL_READY flag itself guarantees ctrl is set.
2014-01-23 07:50:42 -05:00
if (!conn_ctrl_ready(conn))
MAJOR: connection: add two new flags to indicate readiness of control/transport Currently the control and transport layers of a connection are supposed to be initialized when their respective pointers are not NULL. This will not work anymore when we plan to reuse connections, because there is an asymmetry between the accept() side and the connect() side : - on accept() side, the fd is set first, then the ctrl layer then the transport layer ; upon error, they must be undone in the reverse order, then the FD must be closed. The FD must not be deleted if the control layer was not yet initialized ; - on the connect() side, the fd is set last and there is no reliable way to know if it has been initialized or not. In practice it's initialized to -1 first but this is hackish and supposes that local FDs only will be used forever. Also, there are even less solutions for keeping trace of the transport layer's state. Also it is possible to support delayed close() when something (eg: logs) tracks some information requiring the transport and/or control layers, making it even more difficult to clean them. So the proposed solution is to add two flags to the connection : - CO_FL_CTRL_READY is set when the control layer is initialized (fd_insert) and cleared after it's released (fd_delete). - CO_FL_XPRT_READY is set when the control layer is initialized (xprt->init) and cleared after it's released (xprt->close). The functions have been adapted to rely on this and not on the pointers anymore. conn_xprt_close() was unused and dangerous : it did not close the control layer (eg: the socket itself) but still marks the transport layer as closed, preventing any future call to conn_full_close() from finishing the job. The problem comes from conn_full_close() in fact. It needs to close the xprt and ctrl layers independantly. After that we're still having an issue : we don't know based on ->ctrl alone whether the fd was registered or not. For this we use the two new flags CO_FL_XPRT_READY and CO_FL_CTRL_READY. We now rely on this and not on conn->xprt nor conn->ctrl anymore to decide what remains to be done on the connection. In order not to miss some flag assignments, we introduce conn_ctrl_init() to initialize the control layer, register the fd using fd_insert() and set the flag, and conn_ctrl_close() which unregisters the fd and removes the flag, but only if the transport layer was closed. Similarly, at the transport layer, conn_xprt_init() calls ->init and sets the flag, while conn_xprt_close() checks the flag, calls ->close and clears the flag, regardless xprt_ctx or xprt_st. This also ensures that the ->init and the ->close functions are called only once each and in the correct order. Note that conn_xprt_close() does nothing if the transport layer is still tracked. conn_full_close() now simply calls conn_xprt_close() then conn_full_close() in turn, which do nothing if CO_FL_XPRT_TRACKED is set. In order to handle the error path, we also provide conn_force_close() which ignores CO_FL_XPRT_TRACKED and closes the transport and the control layers in turns. All relevant instances of fd_delete() have been replaced with conn_force_close(). Now we always know what state the connection is in and we can expect to split its initialization.
2013-10-21 10:30:56 -04:00
return 0;
MEDIUM: stats: add counters for failed handshake Report on ssl stats the total number of handshakes terminated in a failure.
2020-11-13 10:05:00 -05:00
/* get counters */
switch (obj_type(conn->target)) {
case OBJ_TYPE_LISTENER:
MINOR: ssl: use __objt_* variant when retrieving counters Use non-checked function to retrieve listener/server via obj_type. This is done as a previous obj_type function ensure that the type is well known and the instance is not NULL. Incidentally, this should prevent the coverity report from the #1335 github issue which warns about a possible NULL dereference.
2021-07-26 03:59:06 -04:00
li = __objt_listener(conn->target);
MEDIUM: stats: add counters for failed handshake Report on ssl stats the total number of handshakes terminated in a failure.
2020-11-13 10:05:00 -05:00
counters = EXTRA_COUNTERS_GET(li->extra_counters, &ssl_stats_module);
counters_px = EXTRA_COUNTERS_GET(li->bind_conf->frontend->extra_counters_fe,
&ssl_stats_module);
break;
case OBJ_TYPE_SERVER:
MINOR: ssl: use __objt_* variant when retrieving counters Use non-checked function to retrieve listener/server via obj_type. This is done as a previous obj_type function ensure that the type is well known and the instance is not NULL. Incidentally, this should prevent the coverity report from the #1335 github issue which warns about a possible NULL dereference.
2021-07-26 03:59:06 -04:00
srv = __objt_server(conn->target);
MEDIUM: stats: add counters for failed handshake Report on ssl stats the total number of handshakes terminated in a failure.
2020-11-13 10:05:00 -05:00
counters = EXTRA_COUNTERS_GET(srv->extra_counters, &ssl_stats_module);
counters_px = EXTRA_COUNTERS_GET(srv->proxy->extra_counters_be,
&ssl_stats_module);
break;
default:
break;
}
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
if (!ctx)
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
goto out_error;
BUG/MEDIUM: ssl: check a connection's status before computing a handshake As spotted in issue #822, we're having a problem with error detection in the SSL layer. The problem is that on an overwhelmed machine, accepted connections can start to pile up, each of them requiring a slow handshake, and during all this time if the client aborts, the handshake will still be calculated. The error controls are properly placed, it's just that the SSL layer reads records exactly of the advertised size, without having the ability to encounter a pending connection error. As such if injecting many TLS connections to a listener with a huge backlog, it's fairly possible to meet this situation: 12:50:48.236056 accept4(8, {sa_family=AF_INET, sin_port=htons(62794), sin_addr=inet_addr("127.0.0.1")}, [128->16], SOCK_NONBLOCK) = 1109 12:50:48.236071 setsockopt(1109, SOL_TCP, TCP_NODELAY, [1], 4) = 0 (process other connections' handshakes) 12:50:48.257270 getsockopt(1109, SOL_SOCKET, SO_ERROR, [ECONNRESET], [4]) = 0 (proof that error was detectable there but this code was added for the PoC) 12:50:48.257297 recvfrom(1109, "\26\3\1\2\0", 5, 0, NULL, NULL) = 5 12:50:48.257310 recvfrom(1109, "\1\0\1\3"..., 512, 0, NULL, NULL) = 512 (handshake calculation taking 700us) 12:50:48.258004 sendto(1109, "\26\3\3\0z"..., 1421, MSG_DONTWAIT|MSG_NOSIGNAL, NULL, 0) = -1 EPIPE (Broken pipe) 12:50:48.258036 close(1109) = 0 The situation was amplified by the multi-queue accept code, as it resulted in many incoming connections to be accepted long before they could be handled. Prior to this they would have been accepted and the handshake immediately started, which would have resulted in most of the connections waiting in the the system's accept queue, and dying there when the client aborted, thus the error would have been detected before even trying to pass them to the handshake code. As a result, with a listener running on a very large backlog, it's possible to quickly accept tens of thousands of connections and waste time slowly running their handshakes while they get replaced by other ones. This patch adds an SO_ERROR check on the connection's FD before starting the handshake. This is not pretty as it requires to access the FD, but it does the job. Some improvements should be made over the long term so that the transport layers can report extra information with their ->rcv_buf() call, or at the very least, implement a ->get_conn_status() function to report various flags such as shutr, shutw, error at various stages, allowing an upper layer to inquire for the relevance of engaging into a long operation if it's known the connection is not usable anymore. An even simpler step could probably consist in implementing this in the control layer. This patch is simple enough to be backported as far as 2.0. Many thanks to @ngaugler for his numerous tests with detailed feedback.
2021-02-02 09:42:25 -05:00
/* don't start calculating a handshake on a dead connection */
if (conn->flags & (CO_FL_ERROR | CO_FL_SOCK_RD_SH | CO_FL_SOCK_WR_SH))
goto out_error;
/* FIXME/WT: for now we don't have a clear way to inspect the connection
* status from the lower layers, so let's check the FD directly. Ideally
* the xprt layers should provide some status indicating their knowledge
* of shutdowns or error.
*/
MEDIUM: connection: panic when calling FD-specific functions on FD-less conns Certain functions cannot be called on an FD-less conn because they are normally called as part of the protocol-specific setup/teardown sequence. Better place a few BUG_ON() to make sure none of them is called in other situations. If any of them would trigger in ambiguous conditions, it would always be possible to replace it with an error.
2022-04-11 12:07:03 -04:00
BUG_ON(conn->flags & CO_FL_FDLESS);
BUG/MEDIUM: ssl: check a connection's status before computing a handshake As spotted in issue #822, we're having a problem with error detection in the SSL layer. The problem is that on an overwhelmed machine, accepted connections can start to pile up, each of them requiring a slow handshake, and during all this time if the client aborts, the handshake will still be calculated. The error controls are properly placed, it's just that the SSL layer reads records exactly of the advertised size, without having the ability to encounter a pending connection error. As such if injecting many TLS connections to a listener with a huge backlog, it's fairly possible to meet this situation: 12:50:48.236056 accept4(8, {sa_family=AF_INET, sin_port=htons(62794), sin_addr=inet_addr("127.0.0.1")}, [128->16], SOCK_NONBLOCK) = 1109 12:50:48.236071 setsockopt(1109, SOL_TCP, TCP_NODELAY, [1], 4) = 0 (process other connections' handshakes) 12:50:48.257270 getsockopt(1109, SOL_SOCKET, SO_ERROR, [ECONNRESET], [4]) = 0 (proof that error was detectable there but this code was added for the PoC) 12:50:48.257297 recvfrom(1109, "\26\3\1\2\0", 5, 0, NULL, NULL) = 5 12:50:48.257310 recvfrom(1109, "\1\0\1\3"..., 512, 0, NULL, NULL) = 512 (handshake calculation taking 700us) 12:50:48.258004 sendto(1109, "\26\3\3\0z"..., 1421, MSG_DONTWAIT|MSG_NOSIGNAL, NULL, 0) = -1 EPIPE (Broken pipe) 12:50:48.258036 close(1109) = 0 The situation was amplified by the multi-queue accept code, as it resulted in many incoming connections to be accepted long before they could be handled. Prior to this they would have been accepted and the handshake immediately started, which would have resulted in most of the connections waiting in the the system's accept queue, and dying there when the client aborted, thus the error would have been detected before even trying to pass them to the handshake code. As a result, with a listener running on a very large backlog, it's possible to quickly accept tens of thousands of connections and waste time slowly running their handshakes while they get replaced by other ones. This patch adds an SO_ERROR check on the connection's FD before starting the handshake. This is not pretty as it requires to access the FD, but it does the job. Some improvements should be made over the long term so that the transport layers can report extra information with their ->rcv_buf() call, or at the very least, implement a ->get_conn_status() function to report various flags such as shutr, shutw, error at various stages, allowing an upper layer to inquire for the relevance of engaging into a long operation if it's known the connection is not usable anymore. An even simpler step could probably consist in implementing this in the control layer. This patch is simple enough to be backported as far as 2.0. Many thanks to @ngaugler for his numerous tests with detailed feedback.
2021-02-02 09:42:25 -05:00
skerr = 0;
lskerr = sizeof(skerr);
if ((getsockopt(conn->handle.fd, SOL_SOCKET, SO_ERROR, &skerr, &lskerr) < 0) ||
skerr != 0)
goto out_error;
BUILD: ssl: more elegant OpenSSL early data support check BorinSSL pretends to be 1.1.1 version of OpenSSL. It messes some version based feature presense checks. For example, OpenSSL specific early data support. Let us change that feature detction to SSL_READ_EARLY_DATA_SUCCESS macro check instead of version comparision.
2020-10-24 14:42:30 -04:00
#ifdef SSL_READ_EARLY_DATA_SUCCESS
MEDIUM: ssl: Handle early data with OpenSSL 1.1.1 When compiled with Openssl >= 1.1.1, before attempting to do the handshake, try to read any early data. If any early data is present, then we'll create the session, read the data, and handle the request before we're doing the handshake. For this, we add a new connection flag, CO_FL_EARLY_SSL_HS, which is not part of the CO_FL_HANDSHAKE set, allowing to proceed with a session even before an SSL handshake is completed. As early data do have security implication, we let the origin server know the request comes from early data by adding the "Early-Data" header, as specified in this draft from the HTTP working group : https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-replay
2017-09-22 12:26:28 -04:00
/*
* Check if we have early data. If we do, we have to read them
* before SSL_do_handshake() is called, And there's no way to
* detect early data, except to try to read them
*/
if (conn->flags & CO_FL_EARLY_SSL_HS) {
BUG/MEDIUM: ssl: Revamp the way early data are handled. Instead of attempting to read the early data only when the upper layer asks for data, allocate a temporary buffer, stored in the ssl_sock_ctx, and put all the early data in there. Requiring that the upper layer takes care of it means that if for some reason the upper layer wants to emit data before it has totally read the early data, we will be stuck forever. This should be backported to 2.1 and 2.0. This may fix github issue #411.
2019-12-19 09:02:39 -05:00
size_t read_data = 0;
while (1) {
ret = SSL_read_early_data(ctx->ssl,
b_tail(&ctx->early_buf), b_room(&ctx->early_buf),
&read_data);
if (ret == SSL_READ_EARLY_DATA_ERROR)
goto check_error;
if (read_data > 0) {
conn->flags |= CO_FL_EARLY_DATA;
b_add(&ctx->early_buf, read_data);
}
if (ret == SSL_READ_EARLY_DATA_FINISH) {
conn->flags &= ~CO_FL_EARLY_SSL_HS;
if (!b_data(&ctx->early_buf))
b_free(&ctx->early_buf);
break;
}
}
MEDIUM: ssl: Handle early data with OpenSSL 1.1.1 When compiled with Openssl >= 1.1.1, before attempting to do the handshake, try to read any early data. If any early data is present, then we'll create the session, read the data, and handle the request before we're doing the handshake. For this, we add a new connection flag, CO_FL_EARLY_SSL_HS, which is not part of the CO_FL_HANDSHAKE set, allowing to proceed with a session even before an SSL handshake is completed. As early data do have security implication, we let the origin server know the request comes from early data by adding the "Early-Data" header, as specified in this draft from the HTTP working group : https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-replay
2017-09-22 12:26:28 -04:00
}
#endif
BUG/MEDIUM: ssl: Fix sometimes reneg fails if requested by server. SSL_do_handshake is not appropriate for reneg, it's only appropriate at the beginning of a connection. OpenSSL correctly handles renegs using the data functions, so we use SSL_peek() here to make its state machine progress if SSL_renegotiate_pending() says a reneg is pending.
2012-11-08 13:21:55 -05:00
/* If we use SSL_do_handshake to process a reneg initiated by
* the remote peer, it sometimes returns SSL_ERROR_SSL.
* Usually SSL_write and SSL_read are used and process implicitly
* the reneg handshake.
* Here we use SSL_peek as a workaround for reneg.
*/
MEDIUM: connection: remove CO_FL_CONNECTED and only rely on CO_FL_WAIT_* Commit 477902bd2e ("MEDIUM: connections: Get ride of the xprt_done callback.") broke the master CLI for a very obscure reason. It happens that short requests immediately terminated by a shutdown are properly received, CS_FL_EOS is correctly set, but in si_cs_recv(), we refrain from setting CF_SHUTR on the channel because CO_FL_CONNECTED was not yet set on the connection since we've not passed again through conn_fd_handler() and it was not done in conn_complete_session(). While commit a8a415d31a ("BUG/MEDIUM: connections: Set CO_FL_CONNECTED in conn_complete_session()") fixed the issue, such accident may happen again as the root cause is deeper and actually comes down to the fact that CO_FL_CONNECTED is lazily set at various check points in the code but not every time we drop one wait bit. It is not the first time we face this situation. Originally this flag was used to detect the transition between WAIT_* and CONNECTED in order to call ->wake() from the FD handler. But since at least 1.8-dev1 with commit 7bf3fa3c23 ("BUG/MAJOR: connection: update CO_FL_CONNECTED before calling the data layer"), CO_FL_CONNECTED is always synchronized against the two others before being checked. Moreover, with the I/Os moved to tasklets, the decision to call the ->wake() function is performed after the I/Os in si_cs_process() and equivalent, which don't care about this transition either. So in essence, checking for CO_FL_CONNECTED has become a lazy wait to check for (CO_FL_WAIT_L4_CONN | CO_FL_WAIT_L6_CONN), but that always relies on someone else having synchronized it. This patch addresses it once for all by killing this flag and only checking the two others (for which a composite mask CO_FL_WAIT_L4L6 was added). This revealed a number of inconsistencies that were purposely not addressed here for the sake of bisectability: - while most places do check both L4+L6 and HANDSHAKE at the same time, some places like assign_server() or back_handle_st_con() and a few sample fetches looking for proxy protocol do check for L4+L6 but don't care about HANDSHAKE ; these ones will probably fail on TCP request session rules if the handshake is not complete. - some handshake handlers do validate that a connection is established at L4 but didn't clear CO_FL_WAIT_L4_CONN - the ->ctl method of mux_fcgi, mux_pt and mux_h1 only checks for L4+L6 before declaring the mux ready while the snd_buf function also checks for the handshake's completion. Likely the former should validate the handshake as well and we should get rid of these extra tests in snd_buf. - raw_sock_from_buf() would directly set CO_FL_CONNECTED and would only later clear CO_FL_WAIT_L4_CONN. - xprt_handshake would set CO_FL_CONNECTED itself without actually clearing CO_FL_WAIT_L4_CONN, which could apparently happen only if waiting for a pure Rx handshake. - most places in ssl_sock that were checking CO_FL_CONNECTED don't need to include the L4 check as an L6 check is enough to decide whether to wait for more info or not. It also becomes obvious when reading the test in si_cs_recv() that caused the failure mentioned above that once converted it doesn't make any sense anymore: having CS_FL_EOS set while still waiting for L4 and L6 to complete cannot happen since for CS_FL_EOS to be set, the other ones must have been validated. Some of these parts will still deserve further cleanup, and some of the observations above may induce some backports of potential bug fixes once totally analyzed in their context. The risk of breaking existing stuff is too high to blindly backport everything.
2020-01-23 03:11:58 -05:00
if (!(conn->flags & CO_FL_WAIT_L6_CONN) && SSL_renegotiate_pending(ctx->ssl)) {
BUG/MEDIUM: ssl: Fix sometimes reneg fails if requested by server. SSL_do_handshake is not appropriate for reneg, it's only appropriate at the beginning of a connection. OpenSSL correctly handles renegs using the data functions, so we use SSL_peek() here to make its state machine progress if SSL_renegotiate_pending() says a reneg is pending.
2012-11-08 13:21:55 -05:00
char c;
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
ret = SSL_peek(ctx->ssl, &c, 1);
BUG/MEDIUM: ssl: Fix sometimes reneg fails if requested by server. SSL_do_handshake is not appropriate for reneg, it's only appropriate at the beginning of a connection. OpenSSL correctly handles renegs using the data functions, so we use SSL_peek() here to make its state machine progress if SSL_renegotiate_pending() says a reneg is pending.
2012-11-08 13:21:55 -05:00
if (ret <= 0) {
/* handshake may have not been completed, let's find why */
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
ret = SSL_get_error(ctx->ssl, ret);
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
BUG/MEDIUM: ssl: Fix sometimes reneg fails if requested by server. SSL_do_handshake is not appropriate for reneg, it's only appropriate at the beginning of a connection. OpenSSL correctly handles renegs using the data functions, so we use SSL_peek() here to make its state machine progress if SSL_renegotiate_pending() says a reneg is pending.
2012-11-08 13:21:55 -05:00
if (ret == SSL_ERROR_WANT_WRITE) {
/* SSL handshake needs to write, L4 connection may not be ready */
MEDIUM: connections: Remove CONN_FL_SOCK* Now that the various handshakes come with their own XPRT, there's no need for the CONN_FL_SOCK* flags, and the conn_sock_want|stop functions, so garbage-collect them.
2019-05-28 04:12:02 -04:00
if (!(ctx->wait_event.events & SUB_RETRY_SEND))
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
ctx->xprt->subscribe(conn, ctx->xprt_ctx, SUB_RETRY_SEND, &ctx->wait_event);
BUG/MEDIUM: ssl: Fix sometimes reneg fails if requested by server. SSL_do_handshake is not appropriate for reneg, it's only appropriate at the beginning of a connection. OpenSSL correctly handles renegs using the data functions, so we use SSL_peek() here to make its state machine progress if SSL_renegotiate_pending() says a reneg is pending.
2012-11-08 13:21:55 -05:00
return 0;
}
else if (ret == SSL_ERROR_WANT_READ) {
/* handshake may have been completed but we have
* no more data to read.
*/
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
if (!SSL_renegotiate_pending(ctx->ssl)) {
BUG/MEDIUM: ssl: Fix sometimes reneg fails if requested by server. SSL_do_handshake is not appropriate for reneg, it's only appropriate at the beginning of a connection. OpenSSL correctly handles renegs using the data functions, so we use SSL_peek() here to make its state machine progress if SSL_renegotiate_pending() says a reneg is pending.
2012-11-08 13:21:55 -05:00
ret = 1;
goto reneg_ok;
}
/* SSL handshake needs to read, L4 connection is ready */
MEDIUM: connections: Remove CONN_FL_SOCK* Now that the various handshakes come with their own XPRT, there's no need for the CONN_FL_SOCK* flags, and the conn_sock_want|stop functions, so garbage-collect them.
2019-05-28 04:12:02 -04:00
if (!(ctx->wait_event.events & SUB_RETRY_RECV))
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
ctx->xprt->subscribe(conn, ctx->xprt_ctx, SUB_RETRY_RECV, &ctx->wait_event);
BUG/MEDIUM: ssl: Fix sometimes reneg fails if requested by server. SSL_do_handshake is not appropriate for reneg, it's only appropriate at the beginning of a connection. OpenSSL correctly handles renegs using the data functions, so we use SSL_peek() here to make its state machine progress if SSL_renegotiate_pending() says a reneg is pending.
2012-11-08 13:21:55 -05:00
return 0;
}
BUILD: ssl: use SSL_MODE_ASYNC macro instead of OPENSSL_VERSION
2020-11-13 15:56:34 -05:00
#ifdef SSL_MODE_ASYNC
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
else if (ret == SSL_ERROR_WANT_ASYNC) {
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
ssl_async_process_fds(ctx);
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
return 0;
}
#endif
BUG/MEDIUM: ssl: Fix sometimes reneg fails if requested by server. SSL_do_handshake is not appropriate for reneg, it's only appropriate at the beginning of a connection. OpenSSL correctly handles renegs using the data functions, so we use SSL_peek() here to make its state machine progress if SSL_renegotiate_pending() says a reneg is pending.
2012-11-08 13:21:55 -05:00
else if (ret == SSL_ERROR_SYSCALL) {
/* if errno is null, then connection was successfully established */
if (!errno && conn->flags & CO_FL_WAIT_L4_CONN)
conn->flags &= ~CO_FL_WAIT_L4_CONN;
MEDIUM: connection: add error reporting for the SSL Get a bit more info in the logs when client-side SSL handshakes fail.
2012-12-03 10:32:10 -05:00
if (!conn->err_code) {
BUG/MINOR: ssl: revert empty handshake detection in OpenSSL <= 1.0.2 Commit 54832b97 ("BUILD: enable several LibreSSL hacks, including") changed empty handshake detection in OpenSSL <= 1.0.2 and LibreSSL, from accessing packet_length directly (not available in LibreSSL) to calling SSL_state() instead. However, SSL_state() appears to be fully broken in both OpenSSL and LibreSSL. Since there is no possibility in LibreSSL to detect an empty handshake, let's not try (like BoringSSL) and restore this functionality for OpenSSL 1.0.2 and older, by reverting to the previous behavior. Should be backported to 2.0.
2019-07-08 08:29:15 -04:00
#if defined(OPENSSL_IS_BORINGSSL) || defined(LIBRESSL_VERSION_NUMBER)
/* do not handle empty handshakes in BoringSSL or LibreSSL */
BUILD: ssl: fix to build (again) with boringssl Limitations: . disable force-ssl/tls (need more work) should be set earlier with SSL_CTX_new (SSL_CTX_set_ssl_version is removed) . disable generate-certificates (need more work) introduce SSL_NO_GENERATE_CERTIFICATES to disable generate-certificates. Cleanup some #ifdef and type related to boringssl env.
2017-01-13 11:48:18 -05:00
conn->err_code = CO_ER_SSL_HANDSHAKE;
#else
MEDIUM: ssl: Add support for OpenSSL 1.1.0 In the last release a lot of the structures have become opaque for an end user. This means the code using these needs to be changed to use the proper functions to interact with these structures instead of trying to manipulate them directly. This does not fix any deprecations yet that are part of 1.1.0, it only ensures that it can be compiled against that version and is still compatible with older ones. [wt: openssl-0.9.8 doesn't build with it, there are conflicts on certain function prototypes which we declare as inline here and which are defined differently there. But openssl-0.9.8 is not supported anymore so probably it's OK to go without it for now and we'll see later if some users still need it. Emeric has reviewed this change and didn't spot anything obvious which requires special care. Let's try it for real now]
2016-08-29 07:26:37 -04:00
int empty_handshake;
CLEANUP: ssl: remove 57 occurrences of useless tests on LIBRESSL_VERSION_NUMBER They were all check to comply with the advertised openssl version. Now that libressl doesn't pretend to be a more recent openssl anymore, we can simply rely on the regular openssl version tests without having to deal with exceptions for libressl.
2019-05-09 08:13:35 -04:00
#if (HA_OPENSSL_VERSION_NUMBER >= 0x1010000fL)
BUG/MINOR: ssl: revert empty handshake detection in OpenSSL <= 1.0.2 Commit 54832b97 ("BUILD: enable several LibreSSL hacks, including") changed empty handshake detection in OpenSSL <= 1.0.2 and LibreSSL, from accessing packet_length directly (not available in LibreSSL) to calling SSL_state() instead. However, SSL_state() appears to be fully broken in both OpenSSL and LibreSSL. Since there is no possibility in LibreSSL to detect an empty handshake, let's not try (like BoringSSL) and restore this functionality for OpenSSL 1.0.2 and older, by reverting to the previous behavior. Should be backported to 2.0.
2019-07-08 08:29:15 -04:00
/* use SSL_get_state() in OpenSSL >= 1.1.0; SSL_state() is broken */
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
OSSL_HANDSHAKE_STATE state = SSL_get_state((SSL *)ctx->ssl);
MEDIUM: ssl: Add support for OpenSSL 1.1.0 In the last release a lot of the structures have become opaque for an end user. This means the code using these needs to be changed to use the proper functions to interact with these structures instead of trying to manipulate them directly. This does not fix any deprecations yet that are part of 1.1.0, it only ensures that it can be compiled against that version and is still compatible with older ones. [wt: openssl-0.9.8 doesn't build with it, there are conflicts on certain function prototypes which we declare as inline here and which are defined differently there. But openssl-0.9.8 is not supported anymore so probably it's OK to go without it for now and we'll see later if some users still need it. Emeric has reviewed this change and didn't spot anything obvious which requires special care. Let's try it for real now]
2016-08-29 07:26:37 -04:00
empty_handshake = state == TLS_ST_BEFORE;
#else
BUG/MINOR: ssl: revert empty handshake detection in OpenSSL <= 1.0.2 Commit 54832b97 ("BUILD: enable several LibreSSL hacks, including") changed empty handshake detection in OpenSSL <= 1.0.2 and LibreSSL, from accessing packet_length directly (not available in LibreSSL) to calling SSL_state() instead. However, SSL_state() appears to be fully broken in both OpenSSL and LibreSSL. Since there is no possibility in LibreSSL to detect an empty handshake, let's not try (like BoringSSL) and restore this functionality for OpenSSL 1.0.2 and older, by reverting to the previous behavior. Should be backported to 2.0.
2019-07-08 08:29:15 -04:00
/* access packet_length directly in OpenSSL <= 1.0.2; SSL_state() is broken */
empty_handshake = !ctx->ssl->packet_length;
MEDIUM: ssl: Add support for OpenSSL 1.1.0 In the last release a lot of the structures have become opaque for an end user. This means the code using these needs to be changed to use the proper functions to interact with these structures instead of trying to manipulate them directly. This does not fix any deprecations yet that are part of 1.1.0, it only ensures that it can be compiled against that version and is still compatible with older ones. [wt: openssl-0.9.8 doesn't build with it, there are conflicts on certain function prototypes which we declare as inline here and which are defined differently there. But openssl-0.9.8 is not supported anymore so probably it's OK to go without it for now and we'll see later if some users still need it. Emeric has reviewed this change and didn't spot anything obvious which requires special care. Let's try it for real now]
2016-08-29 07:26:37 -04:00
#endif
if (empty_handshake) {
MEDIUM: ssl: explicitly log failed handshakes after a heartbeat Add a callback to receive the heartbeat notification. There, we add SSL_SOCK_RECV_HEARTBEAT flag on the ssl session if a heartbeat is seen. If a handshake fails, we log a different message to mention the fact that a heartbeat was seen. The test is only performed on the frontend side.
2014-04-25 13:05:36 -04:00
if (!errno) {
MEDIUM: connections: Move some fields from struct connection to ssl_sock_ctx. Move xprt_st, tmp_early_data and sent_early_data from struct connection to struct ssl_sock_ctx, as they are only used in the SSL code.
2019-02-28 12:10:45 -05:00
if (ctx->xprt_st & SSL_SOCK_RECV_HEARTBEAT)
MEDIUM: ssl: explicitly log failed handshakes after a heartbeat Add a callback to receive the heartbeat notification. There, we add SSL_SOCK_RECV_HEARTBEAT flag on the ssl session if a heartbeat is seen. If a handshake fails, we log a different message to mention the fact that a heartbeat was seen. The test is only performed on the frontend side.
2014-04-25 13:05:36 -04:00
conn->err_code = CO_ER_SSL_HANDSHAKE_HB;
else
conn->err_code = CO_ER_SSL_EMPTY;
}
else {
MEDIUM: connections: Move some fields from struct connection to ssl_sock_ctx. Move xprt_st, tmp_early_data and sent_early_data from struct connection to struct ssl_sock_ctx, as they are only used in the SSL code.
2019-02-28 12:10:45 -05:00
if (ctx->xprt_st & SSL_SOCK_RECV_HEARTBEAT)
MEDIUM: ssl: explicitly log failed handshakes after a heartbeat Add a callback to receive the heartbeat notification. There, we add SSL_SOCK_RECV_HEARTBEAT flag on the ssl session if a heartbeat is seen. If a handshake fails, we log a different message to mention the fact that a heartbeat was seen. The test is only performed on the frontend side.
2014-04-25 13:05:36 -04:00
conn->err_code = CO_ER_SSL_HANDSHAKE_HB;
else
conn->err_code = CO_ER_SSL_ABORT;
}
}
else {
MEDIUM: connections: Move some fields from struct connection to ssl_sock_ctx. Move xprt_st, tmp_early_data and sent_early_data from struct connection to struct ssl_sock_ctx, as they are only used in the SSL code.
2019-02-28 12:10:45 -05:00
if (ctx->xprt_st & SSL_SOCK_RECV_HEARTBEAT)
MEDIUM: ssl: explicitly log failed handshakes after a heartbeat Add a callback to receive the heartbeat notification. There, we add SSL_SOCK_RECV_HEARTBEAT flag on the ssl session if a heartbeat is seen. If a handshake fails, we log a different message to mention the fact that a heartbeat was seen. The test is only performed on the frontend side.
2014-04-25 13:05:36 -04:00
conn->err_code = CO_ER_SSL_HANDSHAKE_HB;
MEDIUM: connection: add error reporting for the SSL Get a bit more info in the logs when client-side SSL handshakes fail.
2012-12-03 10:32:10 -05:00
else
MEDIUM: ssl: explicitly log failed handshakes after a heartbeat Add a callback to receive the heartbeat notification. There, we add SSL_SOCK_RECV_HEARTBEAT flag on the ssl session if a heartbeat is seen. If a handshake fails, we log a different message to mention the fact that a heartbeat was seen. The test is only performed on the frontend side.
2014-04-25 13:05:36 -04:00
conn->err_code = CO_ER_SSL_HANDSHAKE;
}
BUG/MINOR: ssl: revert empty handshake detection in OpenSSL <= 1.0.2 Commit 54832b97 ("BUILD: enable several LibreSSL hacks, including") changed empty handshake detection in OpenSSL <= 1.0.2 and LibreSSL, from accessing packet_length directly (not available in LibreSSL) to calling SSL_state() instead. However, SSL_state() appears to be fully broken in both OpenSSL and LibreSSL. Since there is no possibility in LibreSSL to detect an empty handshake, let's not try (like BoringSSL) and restore this functionality for OpenSSL 1.0.2 and older, by reverting to the previous behavior. Should be backported to 2.0.
2019-07-08 08:29:15 -04:00
#endif /* BoringSSL or LibreSSL */
MEDIUM: connection: add error reporting for the SSL Get a bit more info in the logs when client-side SSL handshakes fail.
2012-12-03 10:32:10 -05:00
}
BUG/MEDIUM: ssl: Fix sometimes reneg fails if requested by server. SSL_do_handshake is not appropriate for reneg, it's only appropriate at the beginning of a connection. OpenSSL correctly handles renegs using the data functions, so we use SSL_peek() here to make its state machine progress if SSL_renegotiate_pending() says a reneg is pending.
2012-11-08 13:21:55 -05:00
goto out_error;
}
else {
/* Fail on all other handshake errors */
/* Note: OpenSSL may leave unread bytes in the socket's
* buffer, causing an RST to be emitted upon close() on
* TCP sockets. We first try to drain possibly pending
* data to avoid this as much as possible.
*/
MINOR: connection: make conn_sock_drain() use the control layer's ->drain() Now we don't touch the fd anymore there, instead we rely on the ->drain() provided by the control layer. As such the function was renamed to conn_ctrl_drain().
2020-12-11 10:20:34 -05:00
conn_ctrl_drain(conn);
MEDIUM: connection: add error reporting for the SSL Get a bit more info in the logs when client-side SSL handshakes fail.
2012-12-03 10:32:10 -05:00
if (!conn->err_code)
MEDIUM: connections: Move some fields from struct connection to ssl_sock_ctx. Move xprt_st, tmp_early_data and sent_early_data from struct connection to struct ssl_sock_ctx, as they are only used in the SSL code.
2019-02-28 12:10:45 -05:00
conn->err_code = (ctx->xprt_st & SSL_SOCK_RECV_HEARTBEAT) ?
MEDIUM: ssl: implement a workaround for the OpenSSL heartbleed attack Using the previous callback, it's trivial to block the heartbeat attack, first we control the message length, then we emit an SSL error if it is out of bounds. A special log is emitted, indicating that a heartbleed attack was stopped so that they are not confused with other failures. That way, haproxy can protect itself even when running on an unpatched SSL stack. Tests performed with openssl-1.0.1c indicate a total success.
2014-04-25 14:02:39 -04:00
CO_ER_SSL_KILLED_HB : CO_ER_SSL_HANDSHAKE;
BUG/MEDIUM: ssl: Fix sometimes reneg fails if requested by server. SSL_do_handshake is not appropriate for reneg, it's only appropriate at the beginning of a connection. OpenSSL correctly handles renegs using the data functions, so we use SSL_peek() here to make its state machine progress if SSL_renegotiate_pending() says a reneg is pending.
2012-11-08 13:21:55 -05:00
goto out_error;
}
}
/* read some data: consider handshake completed */
goto reneg_ok;
}
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
ret = SSL_do_handshake(ctx->ssl);
MEDIUM: ssl: Handle early data with OpenSSL 1.1.1 When compiled with Openssl >= 1.1.1, before attempting to do the handshake, try to read any early data. If any early data is present, then we'll create the session, read the data, and handle the request before we're doing the handshake. For this, we add a new connection flag, CO_FL_EARLY_SSL_HS, which is not part of the CO_FL_HANDSHAKE set, allowing to proceed with a session even before an SSL handshake is completed. As early data do have security implication, we let the origin server know the request comes from early data by adding the "Early-Data" header, as specified in this draft from the HTTP working group : https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-replay
2017-09-22 12:26:28 -04:00
check_error:
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
if (ret != 1) {
/* handshake did not complete, let's find why */
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
ret = SSL_get_error(ctx->ssl, ret);
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
MINOR: ssl: Rename ssl_bc_hsk_err to ssl_bc_err The ssl_bc_hsk_err sample fetch will need to raise more errors than only handshake related ones hence its renaming to a more generic ssl_bc_err. This patch is required because some handshake failures that should have been caught by this fetch (verify error on the server side for instance) were missed. This is caused by a change in TLS1.3 in which the 'Finished' state on the client is reached before its certificate is sent (and verified) on the server side (see the "Protocol Overview" part of RFC 8446). This means that the SSL_do_handshake call is finished long before the server can verify and potentially reject the client certificate. The ssl_bc_hsk_err will then need to be expanded to catch other types of errors. This change is also applied to the frontend fetches (ssl_fc_hsk_err becomes ssl_fc_err) and to their string counterparts.
2021-09-29 12:56:52 -04:00
if (!ctx->error_code)
ctx->error_code = ERR_peek_error();
MINOR: ssl: Add new ssl_fc_hsk_err sample fetch This new sample fetch along the ssl_fc_hsk_err_str fetch contain the last SSL error of the error stack that occurred during the SSL handshake (from the frontend's perspective). The errors happening during the client's certificate verification will still be given by the ssl_c_err and ssl_c_ca_err fetches. This new fetch will only hold errors retrieved by the OpenSSL ERR_get_error function.
2021-07-29 03:45:51 -04:00
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
if (ret == SSL_ERROR_WANT_WRITE) {
/* SSL handshake needs to write, L4 connection may not be ready */
MEDIUM: connections: Remove CONN_FL_SOCK* Now that the various handshakes come with their own XPRT, there's no need for the CONN_FL_SOCK* flags, and the conn_sock_want|stop functions, so garbage-collect them.
2019-05-28 04:12:02 -04:00
if (!(ctx->wait_event.events & SUB_RETRY_SEND))
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
ctx->xprt->subscribe(conn, ctx->xprt_ctx, SUB_RETRY_SEND, &ctx->wait_event);
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
return 0;
}
else if (ret == SSL_ERROR_WANT_READ) {
/* SSL handshake needs to read, L4 connection is ready */
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
if (!(ctx->wait_event.events & SUB_RETRY_RECV))
ctx->xprt->subscribe(conn, ctx->xprt_ctx,
SUB_RETRY_RECV, &ctx->wait_event);
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
return 0;
}
BUILD: ssl: use SSL_MODE_ASYNC macro instead of OPENSSL_VERSION
2020-11-13 15:56:34 -05:00
#ifdef SSL_MODE_ASYNC
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
else if (ret == SSL_ERROR_WANT_ASYNC) {
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
ssl_async_process_fds(ctx);
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
return 0;
}
#endif
BUG/MINOR: ssl: report the L4 connection as established when possible If we get an SSL error during the handshake, we at least try to see if a syscall reported an error or not. In case of an error, it generally means that the connection failed. If there is no error, then the connection established successfully. The difference is important for health checks which report the precise cause to the logs and to the stats.
2012-09-28 14:22:13 -04:00
else if (ret == SSL_ERROR_SYSCALL) {
/* if errno is null, then connection was successfully established */
if (!errno && conn->flags & CO_FL_WAIT_L4_CONN)
conn->flags &= ~CO_FL_WAIT_L4_CONN;
BUILD: ssl: fix to build (again) with boringssl Limitations: . disable force-ssl/tls (need more work) should be set earlier with SSL_CTX_new (SSL_CTX_set_ssl_version is removed) . disable generate-certificates (need more work) introduce SSL_NO_GENERATE_CERTIFICATES to disable generate-certificates. Cleanup some #ifdef and type related to boringssl env.
2017-01-13 11:48:18 -05:00
if (!conn->err_code) {
BUG/MINOR: ssl: revert empty handshake detection in OpenSSL <= 1.0.2 Commit 54832b97 ("BUILD: enable several LibreSSL hacks, including") changed empty handshake detection in OpenSSL <= 1.0.2 and LibreSSL, from accessing packet_length directly (not available in LibreSSL) to calling SSL_state() instead. However, SSL_state() appears to be fully broken in both OpenSSL and LibreSSL. Since there is no possibility in LibreSSL to detect an empty handshake, let's not try (like BoringSSL) and restore this functionality for OpenSSL 1.0.2 and older, by reverting to the previous behavior. Should be backported to 2.0.
2019-07-08 08:29:15 -04:00
#if defined(OPENSSL_IS_BORINGSSL) || defined(LIBRESSL_VERSION_NUMBER)
/* do not handle empty handshakes in BoringSSL or LibreSSL */
BUILD: ssl: fix to build (again) with boringssl Limitations: . disable force-ssl/tls (need more work) should be set earlier with SSL_CTX_new (SSL_CTX_set_ssl_version is removed) . disable generate-certificates (need more work) introduce SSL_NO_GENERATE_CERTIFICATES to disable generate-certificates. Cleanup some #ifdef and type related to boringssl env.
2017-01-13 11:48:18 -05:00
conn->err_code = CO_ER_SSL_HANDSHAKE;
#else
int empty_handshake;
CLEANUP: ssl: remove 57 occurrences of useless tests on LIBRESSL_VERSION_NUMBER They were all check to comply with the advertised openssl version. Now that libressl doesn't pretend to be a more recent openssl anymore, we can simply rely on the regular openssl version tests without having to deal with exceptions for libressl.
2019-05-09 08:13:35 -04:00
#if (HA_OPENSSL_VERSION_NUMBER >= 0x1010000fL)
BUG/MINOR: ssl: revert empty handshake detection in OpenSSL <= 1.0.2 Commit 54832b97 ("BUILD: enable several LibreSSL hacks, including") changed empty handshake detection in OpenSSL <= 1.0.2 and LibreSSL, from accessing packet_length directly (not available in LibreSSL) to calling SSL_state() instead. However, SSL_state() appears to be fully broken in both OpenSSL and LibreSSL. Since there is no possibility in LibreSSL to detect an empty handshake, let's not try (like BoringSSL) and restore this functionality for OpenSSL 1.0.2 and older, by reverting to the previous behavior. Should be backported to 2.0.
2019-07-08 08:29:15 -04:00
/* use SSL_get_state() in OpenSSL >= 1.1.0; SSL_state() is broken */
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
OSSL_HANDSHAKE_STATE state = SSL_get_state(ctx->ssl);
BUILD: ssl: fix to build (again) with boringssl Limitations: . disable force-ssl/tls (need more work) should be set earlier with SSL_CTX_new (SSL_CTX_set_ssl_version is removed) . disable generate-certificates (need more work) introduce SSL_NO_GENERATE_CERTIFICATES to disable generate-certificates. Cleanup some #ifdef and type related to boringssl env.
2017-01-13 11:48:18 -05:00
empty_handshake = state == TLS_ST_BEFORE;
MEDIUM: ssl: Add support for OpenSSL 1.1.0 In the last release a lot of the structures have become opaque for an end user. This means the code using these needs to be changed to use the proper functions to interact with these structures instead of trying to manipulate them directly. This does not fix any deprecations yet that are part of 1.1.0, it only ensures that it can be compiled against that version and is still compatible with older ones. [wt: openssl-0.9.8 doesn't build with it, there are conflicts on certain function prototypes which we declare as inline here and which are defined differently there. But openssl-0.9.8 is not supported anymore so probably it's OK to go without it for now and we'll see later if some users still need it. Emeric has reviewed this change and didn't spot anything obvious which requires special care. Let's try it for real now]
2016-08-29 07:26:37 -04:00
#else
BUG/MINOR: ssl: revert empty handshake detection in OpenSSL <= 1.0.2 Commit 54832b97 ("BUILD: enable several LibreSSL hacks, including") changed empty handshake detection in OpenSSL <= 1.0.2 and LibreSSL, from accessing packet_length directly (not available in LibreSSL) to calling SSL_state() instead. However, SSL_state() appears to be fully broken in both OpenSSL and LibreSSL. Since there is no possibility in LibreSSL to detect an empty handshake, let's not try (like BoringSSL) and restore this functionality for OpenSSL 1.0.2 and older, by reverting to the previous behavior. Should be backported to 2.0.
2019-07-08 08:29:15 -04:00
/* access packet_length directly in OpenSSL <= 1.0.2; SSL_state() is broken */
empty_handshake = !ctx->ssl->packet_length;
MEDIUM: ssl: Add support for OpenSSL 1.1.0 In the last release a lot of the structures have become opaque for an end user. This means the code using these needs to be changed to use the proper functions to interact with these structures instead of trying to manipulate them directly. This does not fix any deprecations yet that are part of 1.1.0, it only ensures that it can be compiled against that version and is still compatible with older ones. [wt: openssl-0.9.8 doesn't build with it, there are conflicts on certain function prototypes which we declare as inline here and which are defined differently there. But openssl-0.9.8 is not supported anymore so probably it's OK to go without it for now and we'll see later if some users still need it. Emeric has reviewed this change and didn't spot anything obvious which requires special care. Let's try it for real now]
2016-08-29 07:26:37 -04:00
#endif
BUILD: ssl: fix to build (again) with boringssl Limitations: . disable force-ssl/tls (need more work) should be set earlier with SSL_CTX_new (SSL_CTX_set_ssl_version is removed) . disable generate-certificates (need more work) introduce SSL_NO_GENERATE_CERTIFICATES to disable generate-certificates. Cleanup some #ifdef and type related to boringssl env.
2017-01-13 11:48:18 -05:00
if (empty_handshake) {
if (!errno) {
MEDIUM: connections: Move some fields from struct connection to ssl_sock_ctx. Move xprt_st, tmp_early_data and sent_early_data from struct connection to struct ssl_sock_ctx, as they are only used in the SSL code.
2019-02-28 12:10:45 -05:00
if (ctx->xprt_st & SSL_SOCK_RECV_HEARTBEAT)
BUILD: ssl: fix to build (again) with boringssl Limitations: . disable force-ssl/tls (need more work) should be set earlier with SSL_CTX_new (SSL_CTX_set_ssl_version is removed) . disable generate-certificates (need more work) introduce SSL_NO_GENERATE_CERTIFICATES to disable generate-certificates. Cleanup some #ifdef and type related to boringssl env.
2017-01-13 11:48:18 -05:00
conn->err_code = CO_ER_SSL_HANDSHAKE_HB;
else
conn->err_code = CO_ER_SSL_EMPTY;
}
else {
MEDIUM: connections: Move some fields from struct connection to ssl_sock_ctx. Move xprt_st, tmp_early_data and sent_early_data from struct connection to struct ssl_sock_ctx, as they are only used in the SSL code.
2019-02-28 12:10:45 -05:00
if (ctx->xprt_st & SSL_SOCK_RECV_HEARTBEAT)
BUILD: ssl: fix to build (again) with boringssl Limitations: . disable force-ssl/tls (need more work) should be set earlier with SSL_CTX_new (SSL_CTX_set_ssl_version is removed) . disable generate-certificates (need more work) introduce SSL_NO_GENERATE_CERTIFICATES to disable generate-certificates. Cleanup some #ifdef and type related to boringssl env.
2017-01-13 11:48:18 -05:00
conn->err_code = CO_ER_SSL_HANDSHAKE_HB;
else
conn->err_code = CO_ER_SSL_ABORT;
}
MEDIUM: ssl: explicitly log failed handshakes after a heartbeat Add a callback to receive the heartbeat notification. There, we add SSL_SOCK_RECV_HEARTBEAT flag on the ssl session if a heartbeat is seen. If a handshake fails, we log a different message to mention the fact that a heartbeat was seen. The test is only performed on the frontend side.
2014-04-25 13:05:36 -04:00
}
else {
MEDIUM: connections: Move some fields from struct connection to ssl_sock_ctx. Move xprt_st, tmp_early_data and sent_early_data from struct connection to struct ssl_sock_ctx, as they are only used in the SSL code.
2019-02-28 12:10:45 -05:00
if (ctx->xprt_st & SSL_SOCK_RECV_HEARTBEAT)
MEDIUM: ssl: explicitly log failed handshakes after a heartbeat Add a callback to receive the heartbeat notification. There, we add SSL_SOCK_RECV_HEARTBEAT flag on the ssl session if a heartbeat is seen. If a handshake fails, we log a different message to mention the fact that a heartbeat was seen. The test is only performed on the frontend side.
2014-04-25 13:05:36 -04:00
conn->err_code = CO_ER_SSL_HANDSHAKE_HB;
else
BUILD: ssl: fix to build (again) with boringssl Limitations: . disable force-ssl/tls (need more work) should be set earlier with SSL_CTX_new (SSL_CTX_set_ssl_version is removed) . disable generate-certificates (need more work) introduce SSL_NO_GENERATE_CERTIFICATES to disable generate-certificates. Cleanup some #ifdef and type related to boringssl env.
2017-01-13 11:48:18 -05:00
conn->err_code = CO_ER_SSL_HANDSHAKE;
MEDIUM: ssl: explicitly log failed handshakes after a heartbeat Add a callback to receive the heartbeat notification. There, we add SSL_SOCK_RECV_HEARTBEAT flag on the ssl session if a heartbeat is seen. If a handshake fails, we log a different message to mention the fact that a heartbeat was seen. The test is only performed on the frontend side.
2014-04-25 13:05:36 -04:00
}
BUG/MINOR: ssl: revert empty handshake detection in OpenSSL <= 1.0.2 Commit 54832b97 ("BUILD: enable several LibreSSL hacks, including") changed empty handshake detection in OpenSSL <= 1.0.2 and LibreSSL, from accessing packet_length directly (not available in LibreSSL) to calling SSL_state() instead. However, SSL_state() appears to be fully broken in both OpenSSL and LibreSSL. Since there is no possibility in LibreSSL to detect an empty handshake, let's not try (like BoringSSL) and restore this functionality for OpenSSL 1.0.2 and older, by reverting to the previous behavior. Should be backported to 2.0.
2019-07-08 08:29:15 -04:00
#endif /* BoringSSL or LibreSSL */
MEDIUM: ssl: explicitly log failed handshakes after a heartbeat Add a callback to receive the heartbeat notification. There, we add SSL_SOCK_RECV_HEARTBEAT flag on the ssl session if a heartbeat is seen. If a handshake fails, we log a different message to mention the fact that a heartbeat was seen. The test is only performed on the frontend side.
2014-04-25 13:05:36 -04:00
}
BUG/MINOR: ssl: report the L4 connection as established when possible If we get an SSL error during the handshake, we at least try to see if a syscall reported an error or not. In case of an error, it generally means that the connection failed. If there is no error, then the connection established successfully. The difference is important for health checks which report the precise cause to the logs and to the stats.
2012-09-28 14:22:13 -04:00
goto out_error;
MEDIUM: ssl: handle the SSL_ERROR_ZERO_RETURN during the handshake During a SSL_do_handshake(), SSL_ERROR_ZERO_RETURN can be returned in case the remote peer sent a close_notify alert. Previously this would set the connection error to CO_ER_SSL_HANDSHAKE, this patch sets it to CO_ER_SSL_ABORT to have a more acurate error.
2023-06-26 11:42:09 -04:00
} else if (ret == SSL_ERROR_ZERO_RETURN) {
/* The peer has closed the SSL session for writing by
* sending a close_notify alert */
conn_ctrl_drain(conn);
BUG/MINOR: ssl: SSL_ERROR_ZERO_RETURN returns CO_ER_SSL_EMPTY Return a more acurate error than the previous patch, CO_ER_SSL_EMPTY is the code for "Connection closed during SSL handshake" which is more precise than CO_ER_SSL_ABORT ("Connection error during SSL handshake"). No backport needed.
2023-06-26 13:08:00 -04:00
conn->err_code = CO_ER_SSL_EMPTY;
MEDIUM: ssl: handle the SSL_ERROR_ZERO_RETURN during the handshake During a SSL_do_handshake(), SSL_ERROR_ZERO_RETURN can be returned in case the remote peer sent a close_notify alert. Previously this would set the connection error to CO_ER_SSL_HANDSHAKE, this patch sets it to CO_ER_SSL_ABORT to have a more acurate error.
2023-06-26 11:42:09 -04:00
goto out_error;
BUG/MINOR: ssl: report the L4 connection as established when possible If we get an SSL error during the handshake, we at least try to see if a syscall reported an error or not. In case of an error, it generally means that the connection failed. If there is no error, then the connection established successfully. The difference is important for health checks which report the precise cause to the logs and to the stats.
2012-09-28 14:22:13 -04:00
}
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
else {
/* Fail on all other handshake errors */
MINOR: ssl: improve socket behaviour upon handshake abort. While checking haproxy's SSL stack with www.ssllabs.com, it appeared that immediately closing upon a failed handshake caused a TCP reset to be emitted. This is because OpenSSL does not consume pending data in the socket buffers. One side effect is that if the reset packet is lost, the client might not get it. So now when a handshake fails, we try to clean the socket buffers before closing, resulting in a clean FIN instead of an RST.
2012-10-19 14:52:18 -04:00
/* Note: OpenSSL may leave unread bytes in the socket's
* buffer, causing an RST to be emitted upon close() on
* TCP sockets. We first try to drain possibly pending
* data to avoid this as much as possible.
*/
MINOR: connection: make conn_sock_drain() use the control layer's ->drain() Now we don't touch the fd anymore there, instead we rely on the ->drain() provided by the control layer. As such the function was renamed to conn_ctrl_drain().
2020-12-11 10:20:34 -05:00
conn_ctrl_drain(conn);
MEDIUM: connection: add error reporting for the SSL Get a bit more info in the logs when client-side SSL handshakes fail.
2012-12-03 10:32:10 -05:00
if (!conn->err_code)
MEDIUM: connections: Move some fields from struct connection to ssl_sock_ctx. Move xprt_st, tmp_early_data and sent_early_data from struct connection to struct ssl_sock_ctx, as they are only used in the SSL code.
2019-02-28 12:10:45 -05:00
conn->err_code = (ctx->xprt_st & SSL_SOCK_RECV_HEARTBEAT) ?
MEDIUM: ssl: implement a workaround for the OpenSSL heartbleed attack Using the previous callback, it's trivial to block the heartbeat attack, first we control the message length, then we emit an SSL error if it is out of bounds. A special log is emitted, indicating that a heartbleed attack was stopped so that they are not confused with other failures. That way, haproxy can protect itself even when running on an unpatched SSL stack. Tests performed with openssl-1.0.1c indicate a total success.
2014-04-25 14:02:39 -04:00
CO_ER_SSL_KILLED_HB : CO_ER_SSL_HANDSHAKE;
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
goto out_error;
}
}
BUILD: ssl: more elegant OpenSSL early data support check BorinSSL pretends to be 1.1.1 version of OpenSSL. It messes some version based feature presense checks. For example, OpenSSL specific early data support. Let us change that feature detction to SSL_READ_EARLY_DATA_SUCCESS macro check instead of version comparision.
2020-10-24 14:42:30 -04:00
#ifdef SSL_READ_EARLY_DATA_SUCCESS
MINOR: ssl: Handle sending early data to server. This adds a new keyword on the "server" line, "allow-0rtt", if set, we'll try to send early data to the server, as long as the client sent early data, as in case the server rejects the early data, we no longer have them, and can't resend them, so the only option we have is to send back a 425, and we need to be sure the client knows how to interpret it correctly.
2017-11-03 11:27:47 -04:00
else {
/*
* If the server refused the early data, we have to send a
* 425 to the client, as we no longer have the data to sent
* them again.
*/
if ((conn->flags & CO_FL_EARLY_DATA) && (objt_server(conn->target))) {
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
if (SSL_get_early_data_status(ctx->ssl) == SSL_EARLY_DATA_REJECTED) {
MINOR: ssl: Handle sending early data to server. This adds a new keyword on the "server" line, "allow-0rtt", if set, we'll try to send early data to the server, as long as the client sent early data, as in case the server rejects the early data, we no longer have them, and can't resend them, so the only option we have is to send back a 425, and we need to be sure the client knows how to interpret it correctly.
2017-11-03 11:27:47 -04:00
conn->err_code = CO_ER_SSL_EARLY_FAILED;
goto out_error;
}
}
}
#endif
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
BUG/MEDIUM: ssl: Fix sometimes reneg fails if requested by server. SSL_do_handshake is not appropriate for reneg, it's only appropriate at the beginning of a connection. OpenSSL correctly handles renegs using the data functions, so we use SSL_peek() here to make its state machine progress if SSL_renegotiate_pending() says a reneg is pending.
2012-11-08 13:21:55 -05:00
reneg_ok:
BUG/MAJOR: ssl: buffer overflow using offloaded ciphering on async engine The Openssl's ASYNC API does'nt support moving buffers on SSL_read/write This patch disables the ASYNC mode dynamically when the handshake is left and re-enables it on reneg.
2017-06-06 08:35:14 -04:00
BUILD: ssl: use SSL_MODE_ASYNC macro instead of OPENSSL_VERSION
2020-11-13 15:56:34 -05:00
#ifdef SSL_MODE_ASYNC
BUG/MAJOR: ssl: buffer overflow using offloaded ciphering on async engine The Openssl's ASYNC API does'nt support moving buffers on SSL_read/write This patch disables the ASYNC mode dynamically when the handshake is left and re-enables it on reneg.
2017-06-06 08:35:14 -04:00
/* ASYNC engine API doesn't support moving read/write
* buffers. So we disable ASYNC mode right after
CLEANUP: assorted typo fixes in the code and comments These are mostly comments in the code. A few error messages were fixed and are of low enough importance not to deserve a backport. Some regtests were also fixed.
2020-03-10 03:06:11 -04:00
* the handshake to avoid buffer overflow.
BUG/MAJOR: ssl: buffer overflow using offloaded ciphering on async engine The Openssl's ASYNC API does'nt support moving buffers on SSL_read/write This patch disables the ASYNC mode dynamically when the handshake is left and re-enables it on reneg.
2017-06-06 08:35:14 -04:00
*/
if (global_ssl.async)
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
SSL_clear_mode(ctx->ssl, SSL_MODE_ASYNC);
BUG/MAJOR: ssl: buffer overflow using offloaded ciphering on async engine The Openssl's ASYNC API does'nt support moving buffers on SSL_read/write This patch disables the ASYNC mode dynamically when the handshake is left and re-enables it on reneg.
2017-06-06 08:35:14 -04:00
#endif
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
/* Handshake succeeded */
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
if (!SSL_session_reused(ctx->ssl)) {
MINOR: stats: report SSL key computations per second It's commonly needed to know how many SSL asymmetric keys are computed per second on either side (frontend or backend), and to know the SSL session reuse ratio. Now we compute these values and report them in "show info".
2014-05-28 06:28:58 -04:00
if (objt_server(conn->target)) {
update_freq_ctr(&global.ssl_be_keys_per_sec, 1);
if (global.ssl_be_keys_per_sec.curr_ctr > global.ssl_be_keys_max)
global.ssl_be_keys_max = global.ssl_be_keys_per_sec.curr_ctr;
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
}
MINOR: stats: report SSL key computations per second It's commonly needed to know how many SSL asymmetric keys are computed per second on either side (frontend or backend), and to know the SSL session reuse ratio. Now we compute these values and report them in "show info".
2014-05-28 06:28:58 -04:00
else {
update_freq_ctr(&global.ssl_fe_keys_per_sec, 1);
if (global.ssl_fe_keys_per_sec.curr_ctr > global.ssl_fe_keys_max)
global.ssl_fe_keys_max = global.ssl_fe_keys_per_sec.curr_ctr;
}
MINOR: ssl: add counters for ssl sessions Add counters for newly established and resumed sessions.
2020-11-03 11:10:02 -05:00
BUILD: ssl: silence build warning on uninitialised counters Since commit d0447a7c3 ("MINOR: ssl: add counters for ssl sessions"), gcc 9+ complains about this: CC src/ssl_sock.o src/ssl_sock.c: In function 'ssl_sock_io_cb': src/ssl_sock.c:5416:3: warning: 'counters_px' may be used uninitialized in this function [-Wmaybe-uninitialized] 5416 | ++counters_px->reused_sess; | ^~~~~~~~~~~~~~~~~~~~~~~~~~ src/ssl_sock.c:5133:23: note: 'counters_px' was declared here 5133 | struct ssl_counters *counters, *counters_px; | ^~~~~~~~~~~ Either a listener or a server are expected there, so ther counters are always initialized and the compiler cannot know this. Let's preset them and test before updating the counter, we're not in a hot path here. No backport is needed.
2020-11-06 07:19:18 -05:00
if (counters) {
BUG/MINOR: ssl: make SSL counters atomic SSL counters were added with commit d0447a7c3 ("MINOR: ssl: add counters for ssl sessions") in 2.4, but their updates were not atomic, so it's likely that under significant loads they are not correct. This needs to be backported to 2.4.
2021-11-22 11:46:13 -05:00
HA_ATOMIC_INC(&counters->sess);
HA_ATOMIC_INC(&counters_px->sess);
BUILD: ssl: silence build warning on uninitialised counters Since commit d0447a7c3 ("MINOR: ssl: add counters for ssl sessions"), gcc 9+ complains about this: CC src/ssl_sock.o src/ssl_sock.c: In function 'ssl_sock_io_cb': src/ssl_sock.c:5416:3: warning: 'counters_px' may be used uninitialized in this function [-Wmaybe-uninitialized] 5416 | ++counters_px->reused_sess; | ^~~~~~~~~~~~~~~~~~~~~~~~~~ src/ssl_sock.c:5133:23: note: 'counters_px' was declared here 5133 | struct ssl_counters *counters, *counters_px; | ^~~~~~~~~~~ Either a listener or a server are expected there, so ther counters are always initialized and the compiler cannot know this. Let's preset them and test before updating the counter, we're not in a hot path here. No backport is needed.
2020-11-06 07:19:18 -05:00
}
MINOR: ssl: add counters for ssl sessions Add counters for newly established and resumed sessions.
2020-11-03 11:10:02 -05:00
}
BUILD: ssl: silence build warning on uninitialised counters Since commit d0447a7c3 ("MINOR: ssl: add counters for ssl sessions"), gcc 9+ complains about this: CC src/ssl_sock.o src/ssl_sock.c: In function 'ssl_sock_io_cb': src/ssl_sock.c:5416:3: warning: 'counters_px' may be used uninitialized in this function [-Wmaybe-uninitialized] 5416 | ++counters_px->reused_sess; | ^~~~~~~~~~~~~~~~~~~~~~~~~~ src/ssl_sock.c:5133:23: note: 'counters_px' was declared here 5133 | struct ssl_counters *counters, *counters_px; | ^~~~~~~~~~~ Either a listener or a server are expected there, so ther counters are always initialized and the compiler cannot know this. Let's preset them and test before updating the counter, we're not in a hot path here. No backport is needed.
2020-11-06 07:19:18 -05:00
else if (counters) {
BUG/MINOR: ssl: make SSL counters atomic SSL counters were added with commit d0447a7c3 ("MINOR: ssl: add counters for ssl sessions") in 2.4, but their updates were not atomic, so it's likely that under significant loads they are not correct. This needs to be backported to 2.4.
2021-11-22 11:46:13 -05:00
HA_ATOMIC_INC(&counters->reused_sess);
HA_ATOMIC_INC(&counters_px->reused_sess);
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
}
/* The connection is now established at both layers, it's time to leave */
conn->flags &= ~(flag | CO_FL_WAIT_L4_CONN | CO_FL_WAIT_L6_CONN);
return 1;
out_error:
BUG/MEDIUM: ssl: Prevent ssl error from affecting other connections. J. Maurice reported that ssllabs.com test affects unrelated legitimate traffic and cause SSL errors and broken connections. Sometimes openssl store read/write/handshake errors in a global stack. This stack is not specific to the current session. Openssl API does not clean the stack at the beginning of a new read/write. And the function used to retrieve error ID after read/write, returns the generic error SSL_ERROR_SSL if the global stack is not empty. The fix consists in cleaning the errors stack after read/write/handshake errors.
2012-12-14 05:21:13 -05:00
/* Clear openssl global errors stack */
BUG/MINOR: quic: Possible crash when verifying certificates This verification is done by ssl_sock_bind_verifycbk() which is set at different locations in the ssl_sock.c code . About QUIC connections, there are a lot of chances the connection object is not initialized when entering this function. What must be accessed is the SSL object to retrieve the connection or quic_conn objects, then the bind_conf object of the listener. If the connection object is not found, we try to find the quic_conn object. Modify ssl_sock_dump_errors() interface which takes a connection object as parameter to also passed a quic_conn object as parameter. Again this function try first to access the connection object if not NULL or the quic_conn object if not. There is a remaining thing to do for QUIC: store the certificate verification error code as it is currently stored in the connection object. This error code is at least used by the "bc_err" and "fc_err" sample fetches. There are chances this bug is in relation with GH #1851. Thank you to @tasavis for the report. Must be merged into 2.6.
2022-09-06 13:37:08 -04:00
ssl_sock_dump_errors(conn, NULL);
BUG/MEDIUM: ssl: Prevent ssl error from affecting other connections. J. Maurice reported that ssllabs.com test affects unrelated legitimate traffic and cause SSL errors and broken connections. Sometimes openssl store read/write/handshake errors in a global stack. This stack is not specific to the current session. Openssl API does not clean the stack at the beginning of a new read/write. And the function used to retrieve error ID after read/write, returns the generic error SSL_ERROR_SSL if the global stack is not empty. The fix consists in cleaning the errors stack after read/write/handshake errors.
2012-12-14 05:21:13 -05:00
ERR_clear_error();
BUG/MEDIUM: ssl: subsequent handshakes fail after server configuration changes On server's configuration change, if the previously used cipher is disabled, all subsequent connect attempts fail. Fix consists in freeing cached session on handshake failure.
2012-10-04 11:09:56 -04:00
/* free resumed session if exists */
MEDIUM: ssl: add a rwlock for SSL server session cache When adding the server side support for certificate update over the CLI we encountered a design problem with the SSL session cache which was not locked. Indeed, once a certificate is updated we need to flush the cache, but we also need to ensure that the cache is not used during the update. To prevent the use of the cache during an update, this patch introduce a rwlock for the SSL server session cache. In the SSL session part this patch only lock in read, even if it writes. The reason behind this, is that in the session part, there is one cache storage per thread so it is not a problem to write in the cache from several threads. The problem is only when trying to write in the cache from the CLI (which could be on any thread) when a session is trying to access the cache. So there is a write lock in the CLI part to prevent simultaneous access by a session and the CLI. This patch also remove the thread_isolate attempt which is eating too much CPU time and was not protecting from the use of a free ptr in the session.
2021-02-08 04:43:44 -05:00
if (objt_server(conn->target)) {
struct server *s = __objt_server(conn->target);
/* RWLOCK: only rdlock the SSL cache even when writing in it because there is
* one cache per thread, it only prevents to flush it from the CLI in
* another thread */
HA_RWLOCK_RDLOCK(SSL_SERVER_LOCK, &s->ssl_ctx.lock);
CLEANUP: tree-wide: replace free(x);x=NULL with ha_free(&x) This makes the code more readable and less prone to copy-paste errors. In addition, it allows to place some __builtin_constant_p() predicates to trigger a link-time error in case the compiler knows that the freed area is constant. It will also produce compile-time error if trying to free something that is not a regular pointer (e.g. a function). The DEBUG_MEM_STATS macro now also defines an instance for ha_free() so that all these calls can be checked. 178 occurrences were converted. The vast majority of them were handled by the following Coccinelle script, some slightly refined to better deal with "&*x" or with long lines: @ rule @ expression E; @@ - free(E); - E = NULL; + ha_free(&E); It was verified that the resulting code is the same, more or less a handful of cases where the compiler optimized slightly differently the temporary variable that holds the copy of the pointer. A non-negligible amount of {free(str);str=NULL;str_len=0;} are still present in the config part (mostly header names in proxies). These ones should also be cleaned for the same reasons, and probably be turned into ist strings.
2021-02-20 04:46:51 -05:00
if (s->ssl_ctx.reused_sess[tid].ptr)
ha_free(&s->ssl_ctx.reused_sess[tid].ptr);
MEDIUM: ssl: add a rwlock for SSL server session cache When adding the server side support for certificate update over the CLI we encountered a design problem with the SSL session cache which was not locked. Indeed, once a certificate is updated we need to flush the cache, but we also need to ensure that the cache is not used during the update. To prevent the use of the cache during an update, this patch introduce a rwlock for the SSL server session cache. In the SSL session part this patch only lock in read, even if it writes. The reason behind this, is that in the session part, there is one cache storage per thread so it is not a problem to write in the cache from several threads. The problem is only when trying to write in the cache from the CLI (which could be on any thread) when a session is trying to access the cache. So there is a write lock in the CLI part to prevent simultaneous access by a session and the CLI. This patch also remove the thread_isolate attempt which is eating too much CPU time and was not protecting from the use of a free ptr in the session.
2021-02-08 04:43:44 -05:00
HA_RWLOCK_RDUNLOCK(SSL_SERVER_LOCK, &s->ssl_ctx.lock);
BUG/MEDIUM: ssl: subsequent handshakes fail after server configuration changes On server's configuration change, if the previously used cipher is disabled, all subsequent connect attempts fail. Fix consists in freeing cached session on handshake failure.
2012-10-04 11:09:56 -04:00
}
MEDIUM: stats: add counters for failed handshake Report on ssl stats the total number of handshakes terminated in a failure.
2020-11-13 10:05:00 -05:00
if (counters) {
BUG/MINOR: ssl: make SSL counters atomic SSL counters were added with commit d0447a7c3 ("MINOR: ssl: add counters for ssl sessions") in 2.4, but their updates were not atomic, so it's likely that under significant loads they are not correct. This needs to be backported to 2.4.
2021-11-22 11:46:13 -05:00
HA_ATOMIC_INC(&counters->failed_handshake);
HA_ATOMIC_INC(&counters_px->failed_handshake);
MEDIUM: stats: add counters for failed handshake Report on ssl stats the total number of handshakes terminated in a failure.
2020-11-13 10:05:00 -05:00
}
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
/* Fail on all other handshake errors */
conn->flags |= CO_FL_ERROR;
MEDIUM: connection: add error reporting for the SSL Get a bit more info in the logs when client-side SSL handshakes fail.
2012-12-03 10:32:10 -05:00
if (!conn->err_code)
conn->err_code = CO_ER_SSL_HANDSHAKE;
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
return 0;
}
MINOR: connection: make the last arg of subscribe() a struct wait_event* The subscriber used to be passed as a "void *param" that was systematically cast to a struct wait_event*. By now it appears clear that the subscribe() call at every layer is well defined and always takes a pointer to an event subscriber of type wait_event, so let's enforce this in the functions' prototypes, remove the intermediary variables used to cast it and clean up the comments to clarify what all these functions do in their context.
2020-01-17 01:52:13 -05:00
/* Called from the upper layer, to subscribe <es> to events <event_type>. The
* event subscriber <es> is not allowed to change from a previous call as long
* as at least one event is still subscribed. The <event_type> must only be a
* combination of SUB_RETRY_RECV and SUB_RETRY_SEND. It always returns 0,
* unless the transport layer was already released.
*/
static int ssl_subscribe(struct connection *conn, void *xprt_ctx, int event_type, struct wait_event *es)
MEDIUM: ssl: provide its own subscribe/unsubscribe function. In order to prepare for the possibility of using different kinds of xprt with ssl, make the ssl code provide its own subscribe and unsubscribe functions, right now it just calls conn_subscribe and conn_unsubsribe.
2019-03-21 11:30:07 -04:00
{
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
struct ssl_sock_ctx *ctx = xprt_ctx;
MEDIUM: connections: Provide a xprt_ctx for each xprt method. For most of the xprt methods, provide a xprt_ctx. This will be useful later when we'll want to be able to stack xprts. The init() method now has to create and provide the said xprt_ctx if needed.
2019-03-21 13:27:17 -04:00
BUG/MEDIUM: ssl: Don't do anything in ssl_subscribe if we have no ctx. In ssl_subscribe(), make sure we have a ssl_sock_ctx before doing anything. When ssl_sock_close() is called, it wakes any subscriber up, and that subscriber may decide to subscribe again, for some reason. If we no longer have a context, there's not much we can do. This should be backported to 2.0.
2019-06-24 12:57:39 -04:00
if (!ctx)
return -1;
MEDIUM: ssl: merge recv_wait and send_wait in ssl_sock This is the same principle as previous commit, but for ssl_sock.
2020-01-10 03:20:26 -05:00
BUG_ON(event_type & ~(SUB_RETRY_SEND|SUB_RETRY_RECV));
MINOR: connection: make the last arg of subscribe() a struct wait_event* The subscriber used to be passed as a "void *param" that was systematically cast to a struct wait_event*. By now it appears clear that the subscribe() call at every layer is well defined and always takes a pointer to an event subscriber of type wait_event, so let's enforce this in the functions' prototypes, remove the intermediary variables used to cast it and clean up the comments to clarify what all these functions do in their context.
2020-01-17 01:52:13 -05:00
BUG_ON(ctx->subs && ctx->subs != es);
MEDIUM: ssl: merge recv_wait and send_wait in ssl_sock This is the same principle as previous commit, but for ssl_sock.
2020-01-10 03:20:26 -05:00
MINOR: connection: make the last arg of subscribe() a struct wait_event* The subscriber used to be passed as a "void *param" that was systematically cast to a struct wait_event*. By now it appears clear that the subscribe() call at every layer is well defined and always takes a pointer to an event subscriber of type wait_event, so let's enforce this in the functions' prototypes, remove the intermediary variables used to cast it and clean up the comments to clarify what all these functions do in their context.
2020-01-17 01:52:13 -05:00
ctx->subs = es;
es->events |= event_type;
MEDIUM: ssl: merge recv_wait and send_wait in ssl_sock This is the same principle as previous commit, but for ssl_sock.
2020-01-10 03:20:26 -05:00
/* we may have to subscribe to lower layers for new events */
event_type &= ~ctx->wait_event.events;
if (event_type && !(conn->flags & CO_FL_SSL_WAIT_HS))
ctx->xprt->subscribe(conn, ctx->xprt_ctx, event_type, &ctx->wait_event);
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
return 0;
MEDIUM: ssl: provide its own subscribe/unsubscribe function. In order to prepare for the possibility of using different kinds of xprt with ssl, make the ssl code provide its own subscribe and unsubscribe functions, right now it just calls conn_subscribe and conn_unsubsribe.
2019-03-21 11:30:07 -04:00
}
MINOR: connection: make the last arg of subscribe() a struct wait_event* The subscriber used to be passed as a "void *param" that was systematically cast to a struct wait_event*. By now it appears clear that the subscribe() call at every layer is well defined and always takes a pointer to an event subscriber of type wait_event, so let's enforce this in the functions' prototypes, remove the intermediary variables used to cast it and clean up the comments to clarify what all these functions do in their context.
2020-01-17 01:52:13 -05:00
/* Called from the upper layer, to unsubscribe <es> from events <event_type>.
* The <es> pointer is not allowed to differ from the one passed to the
* subscribe() call. It always returns zero.
*/
static int ssl_unsubscribe(struct connection *conn, void *xprt_ctx, int event_type, struct wait_event *es)
MEDIUM: ssl: provide its own subscribe/unsubscribe function. In order to prepare for the possibility of using different kinds of xprt with ssl, make the ssl code provide its own subscribe and unsubscribe functions, right now it just calls conn_subscribe and conn_unsubsribe.
2019-03-21 11:30:07 -04:00
{
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
struct ssl_sock_ctx *ctx = xprt_ctx;
MEDIUM: ssl: merge recv_wait and send_wait in ssl_sock This is the same principle as previous commit, but for ssl_sock.
2020-01-10 03:20:26 -05:00
BUG_ON(event_type & ~(SUB_RETRY_SEND|SUB_RETRY_RECV));
MINOR: connection: make the last arg of subscribe() a struct wait_event* The subscriber used to be passed as a "void *param" that was systematically cast to a struct wait_event*. By now it appears clear that the subscribe() call at every layer is well defined and always takes a pointer to an event subscriber of type wait_event, so let's enforce this in the functions' prototypes, remove the intermediary variables used to cast it and clean up the comments to clarify what all these functions do in their context.
2020-01-17 01:52:13 -05:00
BUG_ON(ctx->subs && ctx->subs != es);
MEDIUM: connections: Provide a xprt_ctx for each xprt method. For most of the xprt methods, provide a xprt_ctx. This will be useful later when we'll want to be able to stack xprts. The init() method now has to create and provide the said xprt_ctx if needed.
2019-03-21 13:27:17 -04:00
MINOR: connection: make the last arg of subscribe() a struct wait_event* The subscriber used to be passed as a "void *param" that was systematically cast to a struct wait_event*. By now it appears clear that the subscribe() call at every layer is well defined and always takes a pointer to an event subscriber of type wait_event, so let's enforce this in the functions' prototypes, remove the intermediary variables used to cast it and clean up the comments to clarify what all these functions do in their context.
2020-01-17 01:52:13 -05:00
es->events &= ~event_type;
if (!es->events)
MEDIUM: ssl: merge recv_wait and send_wait in ssl_sock This is the same principle as previous commit, but for ssl_sock.
2020-01-10 03:20:26 -05:00
ctx->subs = NULL;
/* If we subscribed, and we're not doing the handshake,
* then we subscribed because the upper layer asked for it,
* as the upper layer is no longer interested, we can
* unsubscribe too.
*/
event_type &= ctx->wait_event.events;
if (event_type && !(ctx->conn->flags & CO_FL_SSL_WAIT_HS))
conn_unsubscribe(conn, ctx->xprt_ctx, event_type, &ctx->wait_event);
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
return 0;
}
BUG/MEDIUM: connections: Let the xprt layer know a takeover happened. When we takeover a connection, let the xprt layer know. If it has its own tasklet, and it is already scheduled, then it has to be destroyed, otherwise it may run the new mux tasklet on the old thread. Note that we only do this for the ssl xprt for now, because the only other one that might wake the mux up is the handshake one, which is supposed to disappear before idle connections exist. No backport is needed, this is for 2.2.
2020-07-03 08:01:21 -04:00
/* The connection has been taken over, so destroy the old tasklet and create
* a new one. The original thread ID must be passed into orig_tid
* It should be called with the takeover lock for the old thread held.
* Returns 0 on success, and -1 on failure
*/
MINOR: connection: extend takeover with release option Extend takeover API both for MUX and XPRT with a new boolean argument <release>. Its purpose is to signal if the connection will be freed immediately after the takeover, rendering new resources allocation unnecessary. For the moment, release argument is always false. However, it will be set to true on delete server CLI handler to proactively close server idle connections.
2024-03-15 10:36:33 -04:00
static int ssl_takeover(struct connection *conn, void *xprt_ctx, int orig_tid, int release)
BUG/MEDIUM: connections: Let the xprt layer know a takeover happened. When we takeover a connection, let the xprt layer know. If it has its own tasklet, and it is already scheduled, then it has to be destroyed, otherwise it may run the new mux tasklet on the old thread. Note that we only do this for the ssl xprt for now, because the only other one that might wake the mux up is the handshake one, which is supposed to disappear before idle connections exist. No backport is needed, this is for 2.2.
2020-07-03 08:01:21 -04:00
{
struct ssl_sock_ctx *ctx = xprt_ctx;
MINOR: connection: extend takeover with release option Extend takeover API both for MUX and XPRT with a new boolean argument <release>. Its purpose is to signal if the connection will be freed immediately after the takeover, rendering new resources allocation unnecessary. For the moment, release argument is always false. However, it will be set to true on delete server CLI handler to proactively close server idle connections.
2024-03-15 10:36:33 -04:00
struct tasklet *tl = NULL;
BUG/MEDIUM: connections: Let the xprt layer know a takeover happened. When we takeover a connection, let the xprt layer know. If it has its own tasklet, and it is already scheduled, then it has to be destroyed, otherwise it may run the new mux tasklet on the old thread. Note that we only do this for the ssl xprt for now, because the only other one that might wake the mux up is the handshake one, which is supposed to disappear before idle connections exist. No backport is needed, this is for 2.2.
2020-07-03 08:01:21 -04:00
MINOR: connection: extend takeover with release option Extend takeover API both for MUX and XPRT with a new boolean argument <release>. Its purpose is to signal if the connection will be freed immediately after the takeover, rendering new resources allocation unnecessary. For the moment, release argument is always false. However, it will be set to true on delete server CLI handler to proactively close server idle connections.
2024-03-15 10:36:33 -04:00
if (!release) {
tl = tasklet_new();
if (!tl)
return -1;
}
BUG/MEDIUM: connections: Let the xprt layer know a takeover happened. When we takeover a connection, let the xprt layer know. If it has its own tasklet, and it is already scheduled, then it has to be destroyed, otherwise it may run the new mux tasklet on the old thread. Note that we only do this for the ssl xprt for now, because the only other one that might wake the mux up is the handshake one, which is supposed to disappear before idle connections exist. No backport is needed, this is for 2.2.
2020-07-03 08:01:21 -04:00
ctx->wait_event.tasklet->context = NULL;
tasklet_wakeup_on(ctx->wait_event.tasklet, orig_tid);
MINOR: connection: extend takeover with release option Extend takeover API both for MUX and XPRT with a new boolean argument <release>. Its purpose is to signal if the connection will be freed immediately after the takeover, rendering new resources allocation unnecessary. For the moment, release argument is always false. However, it will be set to true on delete server CLI handler to proactively close server idle connections.
2024-03-15 10:36:33 -04:00
BUG/MEDIUM: connections: Let the xprt layer know a takeover happened. When we takeover a connection, let the xprt layer know. If it has its own tasklet, and it is already scheduled, then it has to be destroyed, otherwise it may run the new mux tasklet on the old thread. Note that we only do this for the ssl xprt for now, because the only other one that might wake the mux up is the handshake one, which is supposed to disappear before idle connections exist. No backport is needed, this is for 2.2.
2020-07-03 08:01:21 -04:00
ctx->wait_event.tasklet = tl;
MINOR: connection: extend takeover with release option Extend takeover API both for MUX and XPRT with a new boolean argument <release>. Its purpose is to signal if the connection will be freed immediately after the takeover, rendering new resources allocation unnecessary. For the moment, release argument is always false. However, it will be set to true on delete server CLI handler to proactively close server idle connections.
2024-03-15 10:36:33 -04:00
if (!release) {
ctx->wait_event.tasklet->process = ssl_sock_io_cb;
ctx->wait_event.tasklet->context = ctx;
}
BUG/MEDIUM: connections: Let the xprt layer know a takeover happened. When we takeover a connection, let the xprt layer know. If it has its own tasklet, and it is already scheduled, then it has to be destroyed, otherwise it may run the new mux tasklet on the old thread. Note that we only do this for the ssl xprt for now, because the only other one that might wake the mux up is the handshake one, which is supposed to disappear before idle connections exist. No backport is needed, this is for 2.2.
2020-07-03 08:01:21 -04:00
return 0;
}
MEDIUM: ssl: implement xprt_set_used and xprt_set_idle to relax context checks Currently the SSL layer checks the validity of its tasklet's context just in case it would have been stolen, had the connection been idle. Now it will be able to be notified by the mux when this situation happens so as not to have to grab the idle connection lock on each pass. This reuses the TASK_F_USR1 flag just as the muxes do.
2021-03-02 11:29:56 -05:00
/* notify the next xprt that the connection is about to become idle and that it
* may be stolen at any time after the function returns and that any tasklet in
* the chain must be careful before dereferencing its context.
*/
static void ssl_set_idle(struct connection *conn, void *xprt_ctx)
{
struct ssl_sock_ctx *ctx = xprt_ctx;
if (!ctx || !ctx->wait_event.tasklet)
return;
HA_ATOMIC_OR(&ctx->wait_event.tasklet->state, TASK_F_USR1);
if (ctx->xprt)
xprt_set_idle(conn, ctx->xprt, ctx->xprt_ctx);
}
/* notify the next xprt that the connection is not idle anymore and that it may
* not be stolen before the next xprt_set_idle().
*/
static void ssl_set_used(struct connection *conn, void *xprt_ctx)
{
struct ssl_sock_ctx *ctx = xprt_ctx;
if (!ctx || !ctx->wait_event.tasklet)
return;
HA_ATOMIC_OR(&ctx->wait_event.tasklet->state, TASK_F_USR1);
if (ctx->xprt)
xprt_set_used(conn, ctx->xprt, ctx->xprt_ctx);
}
MINOR: connections: Add a new xprt method, add_xprt(). Add a new method to xprt_ops, add_xprt(), that changes the underlying xprt to the one provided, and optionally provide the old one.
2019-05-27 13:50:12 -04:00
/* Use the provided XPRT as an underlying XPRT, and provide the old one.
* Returns 0 on success, and non-zero on failure.
*/
static int ssl_add_xprt(struct connection *conn, void *xprt_ctx, void *toadd_ctx, const struct xprt_ops *toadd_ops, void **oldxprt_ctx, const struct xprt_ops **oldxprt_ops)
{
struct ssl_sock_ctx *ctx = xprt_ctx;
if (oldxprt_ops != NULL)
*oldxprt_ops = ctx->xprt;
if (oldxprt_ctx != NULL)
*oldxprt_ctx = ctx->xprt_ctx;
ctx->xprt = toadd_ops;
ctx->xprt_ctx = toadd_ctx;
return 0;
}
MINOR: connections: Add a new xprt method, remove_xprt. Add a new method to xprt_ops, remove_xprt. When called, if the provided xprt_ctx is the same as the xprt's underlying xprt_ctx, it then uses the new xprt provided, otherwise it calls the remove_xprt method of the next xprt. The goal is to be able to add a temporary xprt, that removes itself from the chain when it did what it had to do. This will be used to implement a pseudo-xprt for anything that just requires a handshake (such as the proxy protocol).
2019-05-23 11:47:36 -04:00
/* Remove the specified xprt. If if it our underlying XPRT, remove it and
* return 0, otherwise just call the remove_xprt method from the underlying
* XPRT.
*/
static int ssl_remove_xprt(struct connection *conn, void *xprt_ctx, void *toremove_ctx, const struct xprt_ops *newops, void *newctx)
{
struct ssl_sock_ctx *ctx = xprt_ctx;
if (ctx->xprt_ctx == toremove_ctx) {
ctx->xprt_ctx = newctx;
ctx->xprt = newops;
return 0;
}
return (ctx->xprt->remove_xprt(conn, ctx->xprt_ctx, toremove_ctx, newops, newctx));
}
MEDIUM: task: extend the state field to 32 bits It's been too short for quite a while now and is now full. It's still time to extend it to 32-bits since we have room for this without wasting any space, so we now gained 16 new bits for future flags. The values were not reassigned just in case there would be a few hidden u16 or short somewhere in which these flags are placed (as it used to be the case with stream->pending_events). The patch is tagged MEDIUM because this required to update the task's process() prototype to use an int instead of a short, that's quite a bunch of places.
2021-03-02 10:09:26 -05:00
struct task *ssl_sock_io_cb(struct task *t, void *context, unsigned int state)
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
{
BUG/MEDIUM: connections: Let the xprt layer know a takeover happened. When we takeover a connection, let the xprt layer know. If it has its own tasklet, and it is already scheduled, then it has to be destroyed, otherwise it may run the new mux tasklet on the old thread. Note that we only do this for the ssl xprt for now, because the only other one that might wake the mux up is the handshake one, which is supposed to disappear before idle connections exist. No backport is needed, this is for 2.2.
2020-07-03 08:01:21 -04:00
struct tasklet *tl = (struct tasklet *)t;
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
struct ssl_sock_ctx *ctx = context;
BUG/MEDIUM: connections: Let the xprt layer know a takeover happened. When we takeover a connection, let the xprt layer know. If it has its own tasklet, and it is already scheduled, then it has to be destroyed, otherwise it may run the new mux tasklet on the old thread. Note that we only do this for the ssl xprt for now, because the only other one that might wake the mux up is the handshake one, which is supposed to disappear before idle connections exist. No backport is needed, this is for 2.2.
2020-07-03 08:01:21 -04:00
struct connection *conn;
int conn_in_list;
int ret = 0;
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
MEDIUM: ssl: implement xprt_set_used and xprt_set_idle to relax context checks Currently the SSL layer checks the validity of its tasklet's context just in case it would have been stolen, had the connection been idle. Now it will be able to be notified by the mux when this situation happens so as not to have to grab the idle connection lock on each pass. This reuses the TASK_F_USR1 flag just as the muxes do.
2021-03-02 11:29:56 -05:00
if (state & TASK_F_USR1) {
/* the tasklet was idling on an idle connection, it might have
* been stolen, let's be careful!
*/
HA_SPIN_LOCK(IDLE_CONNS_LOCK, &idle_conns[tid].idle_conns_lock);
if (tl->context == NULL) {
HA_SPIN_UNLOCK(IDLE_CONNS_LOCK, &idle_conns[tid].idle_conns_lock);
tasklet_free(tl);
return NULL;
}
conn = ctx->conn;
BUG/MAJOR: connection: make sure to always remove a connection from the tree Since commit 5afcb686b ("MAJOR: connection: purge idle conn by last usage") in 2.9-dev4, the test on conn->toremove_list added to conn_get_idle_flag() in 2.8 by commit 3a7b539b1 ("BUG/MEDIUM: connection: Preserve flags when a conn is removed from an idle list") becomes misleading. Indeed, now both toremove_list and idle_list are shared by a union since the presence in these lists is mutually exclusive. However, in conn_get_idle_flag() we check for the presence in the toremove_list to decide whether or not to delete the connection from the tree. This test now fails because instead it sees the presence in the idle or safe list via the union, and concludes the element must not be removed. Thus the element remains in the tree and can be found later after the connection is released, causing crashes that Tristan reported in issue #2292. The following config is sufficient to reproduce it with 2 threads: defaults mode http timeout client 5s timeout server 5s timeout connect 1s listen front bind :8001 server next 127.0.0.1:8002 frontend next bind :8002 timeout http-keep-alive 1 http-request redirect location / Sending traffic with a few concurrent connections and some short timeouts suffices to instantly crash it after ~10k reqs: $ h2load -t 4 -c 16 -n 10000 -m 1 -w 1 http://0:8001/ With Amaury we analyzed the conditions in which the function is called in order to figure a better condition for the test and concluded that ->toremove_list is never filled there so we can safely remove that part from the test and just move the flag retrieval back to what it was prior to the 2.8 patch above. Note that the patch is not reverted though, as the parts that would drop the unexpected flags removal are unchanged. This patch must NOT be backported. The code in 2.8 works correctly, it's only the change in 2.9 that makes it misbehave.
2023-10-12 08:01:49 -04:00
conn_in_list = conn->flags & CO_FL_LIST_MASK;
MEDIUM: ssl: implement xprt_set_used and xprt_set_idle to relax context checks Currently the SSL layer checks the validity of its tasklet's context just in case it would have been stolen, had the connection been idle. Now it will be able to be notified by the mux when this situation happens so as not to have to grab the idle connection lock on each pass. This reuses the TASK_F_USR1 flag just as the muxes do.
2021-03-02 11:29:56 -05:00
if (conn_in_list)
MINOR: connection: simplify removal of idle conns from their trees Small change of API for conn_delete_from_tree(). Now the connection instance is taken as argument instead of its inner node. No functional change introduced with this commit. This simplifies slightly invocation of conn_delete_from_tree(). The most useful changes is that this function will be extended in the next patch to be able to remove the connection from its new idle list at the same time as in its idle tree.
2023-08-21 08:24:17 -04:00
conn_delete_from_tree(conn);
MEDIUM: connection: protect idle conn lists with locks This is a preparation work for connection reuse with sni/proxy protocol/specific src-dst addresses. Protect every access to idle conn lists with a lock. This is currently strictly not needed because the access to the list are made with atomic operations. However, to be able to reuse connection with specific parameters, the list storage will be converted to eb-trees. As this structure does not have atomic operation, it is mandatory to protect it with a lock. For this, the takeover lock is reused. Its role was to protect during connection takeover. As it is now extended to general idle conns usage, it is renamed to idle_conns_lock. A new lock section is also instantiated named IDLE_CONNS_LOCK to isolate its impact on performance.
2021-01-11 03:21:52 -05:00
HA_SPIN_UNLOCK(IDLE_CONNS_LOCK, &idle_conns[tid].idle_conns_lock);
MEDIUM: ssl: implement xprt_set_used and xprt_set_idle to relax context checks Currently the SSL layer checks the validity of its tasklet's context just in case it would have been stolen, had the connection been idle. Now it will be able to be notified by the mux when this situation happens so as not to have to grab the idle connection lock on each pass. This reuses the TASK_F_USR1 flag just as the muxes do.
2021-03-02 11:29:56 -05:00
} else {
conn = ctx->conn;
conn_in_list = 0;
BUG/MEDIUM: connections: Let the xprt layer know a takeover happened. When we takeover a connection, let the xprt layer know. If it has its own tasklet, and it is already scheduled, then it has to be destroyed, otherwise it may run the new mux tasklet on the old thread. Note that we only do this for the ssl xprt for now, because the only other one that might wake the mux up is the handshake one, which is supposed to disappear before idle connections exist. No backport is needed, this is for 2.2.
2020-07-03 08:01:21 -04:00
}
MEDIUM: ssl: implement xprt_set_used and xprt_set_idle to relax context checks Currently the SSL layer checks the validity of its tasklet's context just in case it would have been stolen, had the connection been idle. Now it will be able to be notified by the mux when this situation happens so as not to have to grab the idle connection lock on each pass. This reuses the TASK_F_USR1 flag just as the muxes do.
2021-03-02 11:29:56 -05:00
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
/* First if we're doing an handshake, try that */
MINOR: ssl: mark the SSL handshake tasklet as heavy There's a fairness issue between SSL and clear text. A full end-to-end cleartext connection can require up to ~7.7 wakeups on average, plus 3.3 for the SSL tasklet, one of which is particularly expensive. So if we accept to process many handshakes taking 1ms each, we significantly increase the processing time of regular tasks just by adding an extra delay between their calls. Ideally in order to be fair we should have a 1:18 call ratio, but this requires a bit more accounting. With very little effort we can mark the SSL handshake tasklet as TASK_HEAVY until the handshake completes, and remove it once done. Doing so reduces from 14 to 3.0 ms the total response time experienced by HTTP clients running in parallel to 1000 SSL clients doing full handshakes in loops. Better, when tune.sched.low-latency is set to "on", the latency further drops to 1.8 ms. The tasks latency distribution explain pretty well what is happening: Without the patch: $ socat - /tmp/sock1 <<< "show profiling" Per-task CPU profiling : on # set profiling tasks {on|auto|off} Tasks activity: function calls cpu_tot cpu_avg lat_tot lat_avg ssl_sock_io_cb 2785375 19.35m 416.9us 5.401h 6.980ms h1_io_cb 1868949 9.853s 5.271us 4.829h 9.302ms process_stream 1864066 7.582s 4.067us 2.058h 3.974ms si_cs_io_cb 1733808 1.932s 1.114us 26.83m 928.5us h1_timeout_task 935760 - - 1.033h 3.975ms accept_queue_process 303606 4.627s 15.24us 16.65m 3.291ms srv_cleanup_toremove_connections452 64.31ms 142.3us 2.447s 5.415ms task_run_applet 47 5.149ms 109.6us 57.09ms 1.215ms srv_cleanup_idle_connections 34 2.210ms 65.00us 87.49ms 2.573ms With the patch: $ socat - /tmp/sock1 <<< "show profiling" Per-task CPU profiling : on # set profiling tasks {on|auto|off} Tasks activity: function calls cpu_tot cpu_avg lat_tot lat_avg ssl_sock_io_cb 3000365 21.08m 421.6us 20.30h 24.36ms h1_io_cb 2031932 9.278s 4.565us 46.70m 1.379ms process_stream 2010682 7.391s 3.675us 22.83m 681.2us si_cs_io_cb 1702070 1.571s 922.0ns 8.732m 307.8us h1_timeout_task 1009594 - - 17.63m 1.048ms accept_queue_process 339595 4.792s 14.11us 3.714m 656.2us srv_cleanup_toremove_connections779 75.42ms 96.81us 438.3ms 562.6us srv_cleanup_idle_connections 48 2.498ms 52.05us 178.1us 3.709us task_run_applet 17 1.738ms 102.3us 11.29ms 663.9us other 1 947.8us 947.8us 202.6us 202.6us => h1_io_cb() and process_stream() are divided by 6 while ssl_sock_io_cb() is multipled by 4 And with low-latency on: $ socat - /tmp/sock1 <<< "show profiling" Per-task CPU profiling : on # set profiling tasks {on|auto|off} Tasks activity: function calls cpu_tot cpu_avg lat_tot lat_avg ssl_sock_io_cb 3000565 20.96m 419.1us 20.74h 24.89ms h1_io_cb 2019702 9.294s 4.601us 49.22m 1.462ms process_stream 2009755 6.570s 3.269us 1.493m 44.57us si_cs_io_cb 1997820 1.566s 783.0ns 2.985m 89.66us h1_timeout_task 1009742 - - 1.647m 97.86us accept_queue_process 494509 4.697s 9.498us 1.240m 150.4us srv_cleanup_toremove_connections1120 92.32ms 82.43us 463.0ms 413.4us srv_cleanup_idle_connections 70 2.703ms 38.61us 204.5us 2.921us task_run_applet 13 1.303ms 100.3us 85.12us 6.548us => process_stream() is divided by 100 while ssl_sock_io_cb() is multipled by 4 Interestingly, the total HTTPS response time doesn't increase and even very slightly decreases, with an overall ~1% higher request rate. The net effect here is a redistribution of the CPU resources between internal tasks, and in the case of SSL, handshakes wait bit more but everything after completes faster. This was made simple enough to be backportable if it helps some users suffering from high latencies in mixed traffic.
2021-02-25 09:31:00 -05:00
if (ctx->conn->flags & CO_FL_SSL_WAIT_HS) {
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
ssl_sock_handshake(ctx->conn, CO_FL_SSL_WAIT_HS);
MINOR: ssl: mark the SSL handshake tasklet as heavy There's a fairness issue between SSL and clear text. A full end-to-end cleartext connection can require up to ~7.7 wakeups on average, plus 3.3 for the SSL tasklet, one of which is particularly expensive. So if we accept to process many handshakes taking 1ms each, we significantly increase the processing time of regular tasks just by adding an extra delay between their calls. Ideally in order to be fair we should have a 1:18 call ratio, but this requires a bit more accounting. With very little effort we can mark the SSL handshake tasklet as TASK_HEAVY until the handshake completes, and remove it once done. Doing so reduces from 14 to 3.0 ms the total response time experienced by HTTP clients running in parallel to 1000 SSL clients doing full handshakes in loops. Better, when tune.sched.low-latency is set to "on", the latency further drops to 1.8 ms. The tasks latency distribution explain pretty well what is happening: Without the patch: $ socat - /tmp/sock1 <<< "show profiling" Per-task CPU profiling : on # set profiling tasks {on|auto|off} Tasks activity: function calls cpu_tot cpu_avg lat_tot lat_avg ssl_sock_io_cb 2785375 19.35m 416.9us 5.401h 6.980ms h1_io_cb 1868949 9.853s 5.271us 4.829h 9.302ms process_stream 1864066 7.582s 4.067us 2.058h 3.974ms si_cs_io_cb 1733808 1.932s 1.114us 26.83m 928.5us h1_timeout_task 935760 - - 1.033h 3.975ms accept_queue_process 303606 4.627s 15.24us 16.65m 3.291ms srv_cleanup_toremove_connections452 64.31ms 142.3us 2.447s 5.415ms task_run_applet 47 5.149ms 109.6us 57.09ms 1.215ms srv_cleanup_idle_connections 34 2.210ms 65.00us 87.49ms 2.573ms With the patch: $ socat - /tmp/sock1 <<< "show profiling" Per-task CPU profiling : on # set profiling tasks {on|auto|off} Tasks activity: function calls cpu_tot cpu_avg lat_tot lat_avg ssl_sock_io_cb 3000365 21.08m 421.6us 20.30h 24.36ms h1_io_cb 2031932 9.278s 4.565us 46.70m 1.379ms process_stream 2010682 7.391s 3.675us 22.83m 681.2us si_cs_io_cb 1702070 1.571s 922.0ns 8.732m 307.8us h1_timeout_task 1009594 - - 17.63m 1.048ms accept_queue_process 339595 4.792s 14.11us 3.714m 656.2us srv_cleanup_toremove_connections779 75.42ms 96.81us 438.3ms 562.6us srv_cleanup_idle_connections 48 2.498ms 52.05us 178.1us 3.709us task_run_applet 17 1.738ms 102.3us 11.29ms 663.9us other 1 947.8us 947.8us 202.6us 202.6us => h1_io_cb() and process_stream() are divided by 6 while ssl_sock_io_cb() is multipled by 4 And with low-latency on: $ socat - /tmp/sock1 <<< "show profiling" Per-task CPU profiling : on # set profiling tasks {on|auto|off} Tasks activity: function calls cpu_tot cpu_avg lat_tot lat_avg ssl_sock_io_cb 3000565 20.96m 419.1us 20.74h 24.89ms h1_io_cb 2019702 9.294s 4.601us 49.22m 1.462ms process_stream 2009755 6.570s 3.269us 1.493m 44.57us si_cs_io_cb 1997820 1.566s 783.0ns 2.985m 89.66us h1_timeout_task 1009742 - - 1.647m 97.86us accept_queue_process 494509 4.697s 9.498us 1.240m 150.4us srv_cleanup_toremove_connections1120 92.32ms 82.43us 463.0ms 413.4us srv_cleanup_idle_connections 70 2.703ms 38.61us 204.5us 2.921us task_run_applet 13 1.303ms 100.3us 85.12us 6.548us => process_stream() is divided by 100 while ssl_sock_io_cb() is multipled by 4 Interestingly, the total HTTPS response time doesn't increase and even very slightly decreases, with an overall ~1% higher request rate. The net effect here is a redistribution of the CPU resources between internal tasks, and in the case of SSL, handshakes wait bit more but everything after completes faster. This was made simple enough to be backportable if it helps some users suffering from high latencies in mixed traffic.
2021-02-25 09:31:00 -05:00
if (!(ctx->conn->flags & CO_FL_SSL_WAIT_HS)) {
/* handshake completed, leave the bulk queue */
BUG/MEDIUM: ssl: properly remove the TASK_HEAVY flag at end of handshake Emeric found that SSL+keepalive traffic had dropped quite a bit in the recent changes, which could be bisected to recent commit 9205ab31d ("MINOR: ssl: mark the SSL handshake tasklet as heavy"). Indeed, a first incarnation of this commit made use of the TASK_SELF_WAKING flag but the last version directly used TASK_HEAVY, but it would still continue to remove the already absent TASK_SELF_WAKING one instead of TASK_HEAVY. As such, the SSL traffic remained processed with low granularity. No backport is needed as this is only 2.4.
2021-03-09 11:58:02 -05:00
_HA_ATOMIC_AND(&tl->state, ~TASK_HEAVY);
MINOR: ssl: mark the SSL handshake tasklet as heavy There's a fairness issue between SSL and clear text. A full end-to-end cleartext connection can require up to ~7.7 wakeups on average, plus 3.3 for the SSL tasklet, one of which is particularly expensive. So if we accept to process many handshakes taking 1ms each, we significantly increase the processing time of regular tasks just by adding an extra delay between their calls. Ideally in order to be fair we should have a 1:18 call ratio, but this requires a bit more accounting. With very little effort we can mark the SSL handshake tasklet as TASK_HEAVY until the handshake completes, and remove it once done. Doing so reduces from 14 to 3.0 ms the total response time experienced by HTTP clients running in parallel to 1000 SSL clients doing full handshakes in loops. Better, when tune.sched.low-latency is set to "on", the latency further drops to 1.8 ms. The tasks latency distribution explain pretty well what is happening: Without the patch: $ socat - /tmp/sock1 <<< "show profiling" Per-task CPU profiling : on # set profiling tasks {on|auto|off} Tasks activity: function calls cpu_tot cpu_avg lat_tot lat_avg ssl_sock_io_cb 2785375 19.35m 416.9us 5.401h 6.980ms h1_io_cb 1868949 9.853s 5.271us 4.829h 9.302ms process_stream 1864066 7.582s 4.067us 2.058h 3.974ms si_cs_io_cb 1733808 1.932s 1.114us 26.83m 928.5us h1_timeout_task 935760 - - 1.033h 3.975ms accept_queue_process 303606 4.627s 15.24us 16.65m 3.291ms srv_cleanup_toremove_connections452 64.31ms 142.3us 2.447s 5.415ms task_run_applet 47 5.149ms 109.6us 57.09ms 1.215ms srv_cleanup_idle_connections 34 2.210ms 65.00us 87.49ms 2.573ms With the patch: $ socat - /tmp/sock1 <<< "show profiling" Per-task CPU profiling : on # set profiling tasks {on|auto|off} Tasks activity: function calls cpu_tot cpu_avg lat_tot lat_avg ssl_sock_io_cb 3000365 21.08m 421.6us 20.30h 24.36ms h1_io_cb 2031932 9.278s 4.565us 46.70m 1.379ms process_stream 2010682 7.391s 3.675us 22.83m 681.2us si_cs_io_cb 1702070 1.571s 922.0ns 8.732m 307.8us h1_timeout_task 1009594 - - 17.63m 1.048ms accept_queue_process 339595 4.792s 14.11us 3.714m 656.2us srv_cleanup_toremove_connections779 75.42ms 96.81us 438.3ms 562.6us srv_cleanup_idle_connections 48 2.498ms 52.05us 178.1us 3.709us task_run_applet 17 1.738ms 102.3us 11.29ms 663.9us other 1 947.8us 947.8us 202.6us 202.6us => h1_io_cb() and process_stream() are divided by 6 while ssl_sock_io_cb() is multipled by 4 And with low-latency on: $ socat - /tmp/sock1 <<< "show profiling" Per-task CPU profiling : on # set profiling tasks {on|auto|off} Tasks activity: function calls cpu_tot cpu_avg lat_tot lat_avg ssl_sock_io_cb 3000565 20.96m 419.1us 20.74h 24.89ms h1_io_cb 2019702 9.294s 4.601us 49.22m 1.462ms process_stream 2009755 6.570s 3.269us 1.493m 44.57us si_cs_io_cb 1997820 1.566s 783.0ns 2.985m 89.66us h1_timeout_task 1009742 - - 1.647m 97.86us accept_queue_process 494509 4.697s 9.498us 1.240m 150.4us srv_cleanup_toremove_connections1120 92.32ms 82.43us 463.0ms 413.4us srv_cleanup_idle_connections 70 2.703ms 38.61us 204.5us 2.921us task_run_applet 13 1.303ms 100.3us 85.12us 6.548us => process_stream() is divided by 100 while ssl_sock_io_cb() is multipled by 4 Interestingly, the total HTTPS response time doesn't increase and even very slightly decreases, with an overall ~1% higher request rate. The net effect here is a redistribution of the CPU resources between internal tasks, and in the case of SSL, handshakes wait bit more but everything after completes faster. This was made simple enough to be backportable if it helps some users suffering from high latencies in mixed traffic.
2021-02-25 09:31:00 -05:00
}
}
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
/* If we had an error, or the handshake is done and I/O is available,
* let the upper layer know.
MEDIUM: connections: Get ride of the xprt_done callback. The xprt_done_cb callback was used to defer some connection initialization until we're connected and the handshake are done. As it mostly consists of creating the mux, instead of using the callback, introduce a conn_create_mux() function, that will just call conn_complete_session() for frontend, and create the mux for backend. In h2_wake(), make sure we call the wake method of the stream_interface, as we no longer wakeup the stream task.
2020-01-22 12:08:48 -05:00
* If no mux was set up yet, then call conn_create_mux()
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
* we can't be sure conn_fd_handler() will be called again.
*/
if ((ctx->conn->flags & CO_FL_ERROR) ||
!(ctx->conn->flags & CO_FL_SSL_WAIT_HS)) {
int woke = 0;
/* On error, wake any waiter */
MEDIUM: ssl: merge recv_wait and send_wait in ssl_sock This is the same principle as previous commit, but for ssl_sock.
2020-01-10 03:20:26 -05:00
if (ctx->subs) {
tasklet_wakeup(ctx->subs->tasklet);
ctx->subs->events = 0;
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
woke = 1;
MEDIUM: ssl: merge recv_wait and send_wait in ssl_sock This is the same principle as previous commit, but for ssl_sock.
2020-01-10 03:20:26 -05:00
ctx->subs = NULL;
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
}
MEDIUM: ssl: merge recv_wait and send_wait in ssl_sock This is the same principle as previous commit, but for ssl_sock.
2020-01-10 03:20:26 -05:00
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
/* If we're the first xprt for the connection, let the
MEDIUM: connections: Get ride of the xprt_done callback. The xprt_done_cb callback was used to defer some connection initialization until we're connected and the handshake are done. As it mostly consists of creating the mux, instead of using the callback, introduce a conn_create_mux() function, that will just call conn_complete_session() for frontend, and create the mux for backend. In h2_wake(), make sure we call the wake method of the stream_interface, as we no longer wakeup the stream task.
2020-01-22 12:08:48 -05:00
* upper layers know. If we have no mux, create it,
* and once we have a mux, call its wake method if we didn't
* woke a tasklet already.
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
*/
if (ctx->conn->xprt_ctx == ctx) {
MEDIUM: connections: Get ride of the xprt_done callback. The xprt_done_cb callback was used to defer some connection initialization until we're connected and the handshake are done. As it mostly consists of creating the mux, instead of using the callback, introduce a conn_create_mux() function, that will just call conn_complete_session() for frontend, and create the mux for backend. In h2_wake(), make sure we call the wake method of the stream_interface, as we no longer wakeup the stream task.
2020-01-22 12:08:48 -05:00
if (!ctx->conn->mux)
ret = conn_create_mux(ctx->conn);
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
if (ret >= 0 && !woke && ctx->conn->mux && ctx->conn->mux->wake)
BUG/MEDIUM: connections: Let the xprt layer know a takeover happened. When we takeover a connection, let the xprt layer know. If it has its own tasklet, and it is already scheduled, then it has to be destroyed, otherwise it may run the new mux tasklet on the old thread. Note that we only do this for the ssl xprt for now, because the only other one that might wake the mux up is the handshake one, which is supposed to disappear before idle connections exist. No backport is needed, this is for 2.2.
2020-07-03 08:01:21 -04:00
ret = ctx->conn->mux->wake(ctx->conn);
goto leave;
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
}
}
BUILD: ssl: guard openssl specific with SSL_READ_EARLY_DATA_SUCCESS let us switch to SSL_READ_EARLY_DATA_SUCCESS instead of openssl versions
2021-01-07 01:59:58 -05:00
#ifdef SSL_READ_EARLY_DATA_SUCCESS
BUG/MEDIUM: ssl: Revamp the way early data are handled. Instead of attempting to read the early data only when the upper layer asks for data, allocate a temporary buffer, stored in the ssl_sock_ctx, and put all the early data in there. Requiring that the upper layer takes care of it means that if for some reason the upper layer wants to emit data before it has totally read the early data, we will be stuck forever. This should be backported to 2.1 and 2.0. This may fix github issue #411.
2019-12-19 09:02:39 -05:00
/* If we have early data and somebody wants to receive, let them */
MEDIUM: ssl: merge recv_wait and send_wait in ssl_sock This is the same principle as previous commit, but for ssl_sock.
2020-01-10 03:20:26 -05:00
else if (b_data(&ctx->early_buf) && ctx->subs &&
ctx->subs->events & SUB_RETRY_RECV) {
tasklet_wakeup(ctx->subs->tasklet);
ctx->subs->events &= ~SUB_RETRY_RECV;
if (!ctx->subs->events)
ctx->subs = NULL;
BUG/MEDIUM: ssl: Revamp the way early data are handled. Instead of attempting to read the early data only when the upper layer asks for data, allocate a temporary buffer, stored in the ssl_sock_ctx, and put all the early data in there. Requiring that the upper layer takes care of it means that if for some reason the upper layer wants to emit data before it has totally read the early data, we will be stuck forever. This should be backported to 2.1 and 2.0. This may fix github issue #411.
2019-12-19 09:02:39 -05:00
}
#endif
BUG/MEDIUM: connections: Let the xprt layer know a takeover happened. When we takeover a connection, let the xprt layer know. If it has its own tasklet, and it is already scheduled, then it has to be destroyed, otherwise it may run the new mux tasklet on the old thread. Note that we only do this for the ssl xprt for now, because the only other one that might wake the mux up is the handshake one, which is supposed to disappear before idle connections exist. No backport is needed, this is for 2.2.
2020-07-03 08:01:21 -04:00
leave:
if (!ret && conn_in_list) {
struct server *srv = objt_server(conn->target);
MEDIUM: connection: protect idle conn lists with locks This is a preparation work for connection reuse with sni/proxy protocol/specific src-dst addresses. Protect every access to idle conn lists with a lock. This is currently strictly not needed because the access to the list are made with atomic operations. However, to be able to reuse connection with specific parameters, the list storage will be converted to eb-trees. As this structure does not have atomic operation, it is mandatory to protect it with a lock. For this, the takeover lock is reused. Its role was to protect during connection takeover. As it is now extended to general idle conns usage, it is renamed to idle_conns_lock. A new lock section is also instantiated named IDLE_CONNS_LOCK to isolate its impact on performance.
2021-01-11 03:21:52 -05:00
HA_SPIN_LOCK(IDLE_CONNS_LOCK, &idle_conns[tid].idle_conns_lock);
MINOR: server: move idle tree insert in a dedicated function Define a new function _srv_add_idle(). This is a simple wrapper to insert a connection in the server idle tree. This is reserved for simple usage and require to idle_conns lock. In most cases, srv_add_to_idle_list() should be used. This patch does not have any functional change. However, it will help with the next patch as idle connection will be always inserted in a list as secondary storage along with idle/safe trees.
2023-08-25 09:48:39 -04:00
_srv_add_idle(srv, conn, conn_in_list == CO_FL_SAFE_LIST);
MEDIUM: connection: protect idle conn lists with locks This is a preparation work for connection reuse with sni/proxy protocol/specific src-dst addresses. Protect every access to idle conn lists with a lock. This is currently strictly not needed because the access to the list are made with atomic operations. However, to be able to reuse connection with specific parameters, the list storage will be converted to eb-trees. As this structure does not have atomic operation, it is mandatory to protect it with a lock. For this, the takeover lock is reused. Its role was to protect during connection takeover. As it is now extended to general idle conns usage, it is renamed to idle_conns_lock. A new lock section is also instantiated named IDLE_CONNS_LOCK to isolate its impact on performance.
2021-01-11 03:21:52 -05:00
HA_SPIN_UNLOCK(IDLE_CONNS_LOCK, &idle_conns[tid].idle_conns_lock);
BUG/MEDIUM: connections: Let the xprt layer know a takeover happened. When we takeover a connection, let the xprt layer know. If it has its own tasklet, and it is already scheduled, then it has to be destroyed, otherwise it may run the new mux tasklet on the old thread. Note that we only do this for the ssl xprt for now, because the only other one that might wake the mux up is the handshake one, which is supposed to disappear before idle connections exist. No backport is needed, this is for 2.2.
2020-07-03 08:01:21 -04:00
}
CLEANUP: task: make sure tasklet handlers always indicate their statuses When tasklets were derived from tasks, there was no immediate need for the scheduler to know their status after execution, and in a spirit of simplicity they just started to always return NULL. The problem is that it simply prevents the scheduler from 1) accounting their execution time, and 2) keeping track of their current execution status. Indeed, a remote wake-up could very well end up manipulating a tasklet that's currently being executed. And this is the reason why those handlers have to take the idle lock before checking their context. In 2.5 we'll take care of making tasklets and tasks work more similarly, but trouble is to be expected if we continue to propagate the trend of returning NULL everywhere, especially if some fixes relying on a stricter model later need to be backported. For this reason this patch updates all known tasklet handlers to make them return NULL only when the tasklet was freed. It has no effect for now and isn't even guaranteed to always be 100% safe but it puts the code into the right direction for this.
2021-03-13 05:30:19 -05:00
return t;
MEDIUM: ssl: provide its own subscribe/unsubscribe function. In order to prepare for the possibility of using different kinds of xprt with ssl, make the ssl code provide its own subscribe and unsubscribe functions, right now it just calls conn_subscribe and conn_unsubsribe.
2019-03-21 11:30:07 -04:00
}
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
/* Receive up to <count> bytes from connection <conn>'s socket and store them
BUG/MAJOR: connection: fix mismatch between rcv_buf's API and usage Steve Ruiz reported some reproducible crashes with HTTP health checks on a certain page returning a huge length. The traces he provided clearly showed that the recv() call was performed twice for a total size exceeding the buffer's length. Cyril Bont tracked down the problem to be caused by the full buffer size being passed to rcv_buf() in event_srv_chk_r() instead of passing just the remaining amount of space. Indeed, this change happened during the connection rework in 1.5-dev13 with the following commit : f150317 MAJOR: checks: completely use the connection transport layer But one of the problems is also that the comments at the top of the rcv_buf() functions suggest that the caller only has to ensure the requested size doesn't overflow the buffer's size. Also, these functions already have to care about the buffer's size to handle wrapping free space when there are pending data in the buffer. So let's change the API instead to more closely match what could be expected from these functions : - the caller asks for the maximum amount of bytes it wants to read ; This means that only the caller is responsible for enforcing the reserve if it wants to (eg: checks don't). - the rcv_buf() functions fix their computations to always consider this size as a max, and always perform validity checks based on the buffer's free space. As a result, the code is simplified and reduced, and made more robust for callers which now just have to care about whether they want the buffer to be filled or not. Since the bug was introduced in 1.5-dev13, no backport to stable versions is needed.
2014-01-14 05:31:27 -05:00
* into buffer <buf>. Only one call to recv() is performed, unless the
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
* buffer wraps, in which case a second call may be performed. The connection's
* flags are updated with whatever special event is detected (error, read0,
* empty). The caller is responsible for taking care of those events and
* avoiding the call if inappropriate. The function does not call the
* connection's polling update function, so the caller is responsible for this.
*/
MEDIUM: connections: Provide a xprt_ctx for each xprt method. For most of the xprt methods, provide a xprt_ctx. This will be useful later when we'll want to be able to stack xprts. The init() method now has to create and provide the said xprt_ctx if needed.
2019-03-21 13:27:17 -04:00
static size_t ssl_sock_to_buf(struct connection *conn, void *xprt_ctx, struct buffer *buf, size_t count, int flags)
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
{
MEDIUM: connections: Provide a xprt_ctx for each xprt method. For most of the xprt methods, provide a xprt_ctx. This will be useful later when we'll want to be able to stack xprts. The init() method now has to create and provide the said xprt_ctx if needed.
2019-03-21 13:27:17 -04:00
struct ssl_sock_ctx *ctx = xprt_ctx;
MEDIUM: connection: make xprt->rcv_buf() use size_t for the count Just like we have a size_t for xprt->snd_buf(), we adjust to use size_t for rcv_buf()'s count argument and return value. It also removes the ambiguity related to the possibility to see a negative value there.
2018-07-18 05:22:03 -04:00
ssize_t ret;
size_t try, done = 0;
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
MEDIUM: connections: Provide a xprt_ctx for each xprt method. For most of the xprt methods, provide a xprt_ctx. This will be useful later when we'll want to be able to stack xprts. The init() method now has to create and provide the said xprt_ctx if needed.
2019-03-21 13:27:17 -04:00
if (!ctx)
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
goto out_error;
BUILD: ssl: guard openssl specific with SSL_READ_EARLY_DATA_SUCCESS let us switch to SSL_READ_EARLY_DATA_SUCCESS instead of openssl versions
2021-01-07 01:59:58 -05:00
#ifdef SSL_READ_EARLY_DATA_SUCCESS
BUG/MEDIUM: ssl: Revamp the way early data are handled. Instead of attempting to read the early data only when the upper layer asks for data, allocate a temporary buffer, stored in the ssl_sock_ctx, and put all the early data in there. Requiring that the upper layer takes care of it means that if for some reason the upper layer wants to emit data before it has totally read the early data, we will be stuck forever. This should be backported to 2.1 and 2.0. This may fix github issue #411.
2019-12-19 09:02:39 -05:00
if (b_data(&ctx->early_buf)) {
try = b_contig_space(buf);
if (try > b_data(&ctx->early_buf))
try = b_data(&ctx->early_buf);
memcpy(b_tail(buf), b_head(&ctx->early_buf), try);
b_add(buf, try);
b_del(&ctx->early_buf, try);
if (b_data(&ctx->early_buf) == 0)
b_free(&ctx->early_buf);
return try;
}
#endif
MEDIUM: connection: use CO_FL_WAIT_XPRT more consistently than L4/L6/HANDSHAKE As mentioned in commit c192b0ab95 ("MEDIUM: connection: remove CO_FL_CONNECTED and only rely on CO_FL_WAIT_*"), there is a lack of consistency on which flags are checked among L4/L6/HANDSHAKE depending on the code areas. A number of sample fetch functions only check for L4L6 to report MAY_CHANGE, some places only check for HANDSHAKE and many check both L4L6 and HANDSHAKE. This patch starts to make all of this more consistent by introducing a new mask CO_FL_WAIT_XPRT which is the union of L4/L6/HANDSHAKE and reports whether the transport layer is ready or not. All inconsistent call places were updated to rely on this one each time the goal was to check for the readiness of the transport layer.
2020-01-23 10:27:54 -05:00
if (conn->flags & (CO_FL_WAIT_XPRT | CO_FL_SSL_WAIT_HS))
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
/* a handshake was requested */
return 0;
/* read the largest possible block. For this, we perform only one call
* to recv() unless the buffer wraps and we exactly fill the first hunk,
* in which case we accept to do it once again. A new attempt is made on
* EINTR too.
*/
BUG/MAJOR: ssl: fix breakage caused by recent fix abf08d9 Recent commit abf08d9 ("BUG/MAJOR: connection: fix mismatch between rcv_buf's API and usage") accidentely broke SSL by relying on an uninitialized value to enter the read loop. Many thanks to Cyril Bont and Steve Ruiz for reporting this issue.
2014-01-17 05:09:40 -05:00
while (count > 0) {
MEDIUM: ssl: Handle early data with OpenSSL 1.1.1 When compiled with Openssl >= 1.1.1, before attempting to do the handshake, try to read any early data. If any early data is present, then we'll create the session, read the data, and handle the request before we're doing the handshake. For this, we add a new connection flag, CO_FL_EARLY_SSL_HS, which is not part of the CO_FL_HANDSHAKE set, allowing to proceed with a session even before an SSL handshake is completed. As early data do have security implication, we let the origin server know the request comes from early data by adding the "Early-Data" header, as specified in this draft from the HTTP working group : https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-replay
2017-09-22 12:26:28 -04:00
MINOR: buffer: use b_orig() to replace most references to b->data This patch updates most users of b->data to use b_orig().
2018-06-15 11:21:00 -04:00
try = b_contig_space(buf);
if (!try)
break;
BUG/MAJOR: connection: fix mismatch between rcv_buf's API and usage Steve Ruiz reported some reproducible crashes with HTTP health checks on a certain page returning a huge length. The traces he provided clearly showed that the recv() call was performed twice for a total size exceeding the buffer's length. Cyril Bont tracked down the problem to be caused by the full buffer size being passed to rcv_buf() in event_srv_chk_r() instead of passing just the remaining amount of space. Indeed, this change happened during the connection rework in 1.5-dev13 with the following commit : f150317 MAJOR: checks: completely use the connection transport layer But one of the problems is also that the comments at the top of the rcv_buf() functions suggest that the caller only has to ensure the requested size doesn't overflow the buffer's size. Also, these functions already have to care about the buffer's size to handle wrapping free space when there are pending data in the buffer. So let's change the API instead to more closely match what could be expected from these functions : - the caller asks for the maximum amount of bytes it wants to read ; This means that only the caller is responsible for enforcing the reserve if it wants to (eg: checks don't). - the rcv_buf() functions fix their computations to always consider this size as a max, and always perform validity checks based on the buffer's free space. As a result, the code is simplified and reduced, and made more robust for callers which now just have to care about whether they want the buffer to be filled or not. Since the bug was introduced in 1.5-dev13, no backport to stable versions is needed.
2014-01-14 05:31:27 -05:00
if (try > count)
try = count;
MINOR: buffer: use b_orig() to replace most references to b->data This patch updates most users of b->data to use b_orig().
2018-06-15 11:21:00 -04:00
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
ret = SSL_read(ctx->ssl, b_tail(buf), try);
BUG/MINOR: ssl: fix 0-RTT for BoringSSL Since BoringSSL commit 777a2391 "Hold off flushing NewSessionTicket until write.", 0-RTT doesn't work. It appears that half-RTT data (response from 0-RTT) never worked before the BoringSSL fix. For HAProxy the regression come from 010941f8 "BUG/MEDIUM: ssl: Use the early_data API the right way.": the problem is link to the logic of CO_FL_EARLY_SSL_HS used for OpenSSL. With BoringSSL, handshake is done before reading early data, 0-RTT data and half-RTT data are processed as normal data: CO_FL_EARLY_SSL_HS/CO_FL_EARLY_DATA is not needed, simply remove it. This should be backported to all versions till 1.8.
2019-08-05 12:04:16 -04:00
MEDIUM: ssl: protect against client-initiated renegociation CVE-2009-3555 suggests that client-initiated renegociation should be prevented in the middle of data. The workaround here consists in having the SSL layer notify our callback about a handshake occurring, which in turn causes the connection to be marked in the error state if it was already considered established (which means if a previous handshake was completed). The result is that the connection with the client is immediately aborted and any pending data are dropped.
2012-09-03 14:36:47 -04:00
if (conn->flags & CO_FL_ERROR) {
/* CO_FL_ERROR may be set by ssl_sock_infocbk */
BUG/MEDIUM: ssl: Prevent ssl error from affecting other connections. J. Maurice reported that ssllabs.com test affects unrelated legitimate traffic and cause SSL errors and broken connections. Sometimes openssl store read/write/handshake errors in a global stack. This stack is not specific to the current session. Openssl API does not clean the stack at the beginning of a new read/write. And the function used to retrieve error ID after read/write, returns the generic error SSL_ERROR_SSL if the global stack is not empty. The fix consists in cleaning the errors stack after read/write/handshake errors.
2012-12-14 05:21:13 -05:00
goto out_error;
MEDIUM: ssl: protect against client-initiated renegociation CVE-2009-3555 suggests that client-initiated renegociation should be prevented in the middle of data. The workaround here consists in having the SSL layer notify our callback about a handshake occurring, which in turn causes the connection to be marked in the error state if it was already considered established (which means if a previous handshake was completed). The result is that the connection with the client is immediately aborted and any pending data are dropped.
2012-09-03 14:36:47 -04:00
}
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
if (ret > 0) {
MINOR: buffer: Use b_add()/bo_add() instead of accessing b->i/b->o. Use the newly available functions instead of using the buffer fields directly.
2018-06-28 12:17:23 -04:00
b_add(buf, ret);
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
done += ret;
count -= ret;
}
else {
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
ret = SSL_get_error(ctx->ssl, ret);
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
if (ret == SSL_ERROR_WANT_WRITE) {
BUG/MEDIUM: ssl: review polling on reneg. SSL may return SSL_ERROR_WANT_WRITE or SSL_ERROR_WANT_READ when switching from data to handshake even if it does not need to poll first.
2012-11-08 11:56:20 -05:00
/* handshake is running, and it needs to enable write */
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
conn->flags |= CO_FL_SSL_WAIT_HS;
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
ctx->xprt->subscribe(conn, ctx->xprt_ctx, SUB_RETRY_SEND, &ctx->wait_event);
BUILD: ssl: use SSL_MODE_ASYNC macro instead of OPENSSL_VERSION
2020-11-13 15:56:34 -05:00
#ifdef SSL_MODE_ASYNC
BUG/MAJOR: ssl: buffer overflow using offloaded ciphering on async engine The Openssl's ASYNC API does'nt support moving buffers on SSL_read/write This patch disables the ASYNC mode dynamically when the handshake is left and re-enables it on reneg.
2017-06-06 08:35:14 -04:00
/* Async mode can be re-enabled, because we're leaving data state.*/
if (global_ssl.async)
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
SSL_set_mode(ctx->ssl, SSL_MODE_ASYNC);
BUG/MAJOR: ssl: buffer overflow using offloaded ciphering on async engine The Openssl's ASYNC API does'nt support moving buffers on SSL_read/write This patch disables the ASYNC mode dynamically when the handshake is left and re-enables it on reneg.
2017-06-06 08:35:14 -04:00
#endif
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
break;
}
else if (ret == SSL_ERROR_WANT_READ) {
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
if (SSL_renegotiate_pending(ctx->ssl)) {
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
ctx->xprt->subscribe(conn, ctx->xprt_ctx,
SUB_RETRY_RECV,
&ctx->wait_event);
BUG/MEDIUM: ssl: Fix some reneg cases not correctly handled. SSL may decide to switch to a handshake in the middle of a transfer due to a reneg. In this case we don't want to re-enable polling because data might have been left pending in the buffer. We just want to switch immediately to the handshake mode.
2012-11-08 12:02:56 -05:00
/* handshake is running, and it may need to re-enable read */
conn->flags |= CO_FL_SSL_WAIT_HS;
BUILD: ssl: use SSL_MODE_ASYNC macro instead of OPENSSL_VERSION
2020-11-13 15:56:34 -05:00
#ifdef SSL_MODE_ASYNC
BUG/MAJOR: ssl: buffer overflow using offloaded ciphering on async engine The Openssl's ASYNC API does'nt support moving buffers on SSL_read/write This patch disables the ASYNC mode dynamically when the handshake is left and re-enables it on reneg.
2017-06-06 08:35:14 -04:00
/* Async mode can be re-enabled, because we're leaving data state.*/
if (global_ssl.async)
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
SSL_set_mode(ctx->ssl, SSL_MODE_ASYNC);
BUG/MAJOR: ssl: buffer overflow using offloaded ciphering on async engine The Openssl's ASYNC API does'nt support moving buffers on SSL_read/write This patch disables the ASYNC mode dynamically when the handshake is left and re-enables it on reneg.
2017-06-06 08:35:14 -04:00
#endif
BUG/MEDIUM: ssl: Fix some reneg cases not correctly handled. SSL may decide to switch to a handshake in the middle of a transfer due to a reneg. In this case we don't want to re-enable polling because data might have been left pending in the buffer. We just want to switch immediately to the handshake mode.
2012-11-08 12:02:56 -05:00
break;
}
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
break;
MEDIUM: ssl: Handle early data with OpenSSL 1.1.1 When compiled with Openssl >= 1.1.1, before attempting to do the handshake, try to read any early data. If any early data is present, then we'll create the session, read the data, and handle the request before we're doing the handshake. For this, we add a new connection flag, CO_FL_EARLY_SSL_HS, which is not part of the CO_FL_HANDSHAKE set, allowing to proceed with a session even before an SSL handshake is completed. As early data do have security implication, we let the origin server know the request comes from early data by adding the "Early-Data" header, as specified in this draft from the HTTP working group : https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-replay
2017-09-22 12:26:28 -04:00
} else if (ret == SSL_ERROR_ZERO_RETURN)
goto read0;
MINOR: ssl: Set connection error code in case of SSL read or write fatal failure In case of a connection error happening after the SSL handshake is completed, the error code stored in the connection structure would not always be set, hence having some connection failures being described as successful in the fc_conn_err or bc_conn_err sample fetches. The most common case in which it could happen is when the SSL server rejects the client's certificate. The SSL_do_handshake call on the client side would be sucessful because the client effectively sent its client hello and certificate information to the server, but the next call to SSL_read on the client side would raise an SSL_ERROR_SSL code (through the SSL_get_error function) which is decribed in OpenSSL documentation as a non-recoverable and fatal SSL error. This patch ensures that in such a case, the connection's error code is set to a special CO_ERR_SSL_FATAL value.
2021-09-29 12:56:51 -04:00
else if (ret == SSL_ERROR_SSL) {
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
struct ssl_sock_ctx *ctx = conn_get_ssl_sock_ctx(conn);
if (ctx && !ctx->error_code)
MINOR: ssl: Store the last SSL error code in case of read or write failure In case of error while calling a SSL_read or SSL_write, the SSL_get_error function is called in order to know more about the error that happened. If the error code is SSL_ERROR_SSL or SSL_ERROR_SYSCALL, the error queue might contain more information on the error. This error code was not used until now. But we now need to store it in order for backend error fetches to catch all handshake related errors. The change was required because the previous backend fetch would not have raised anything if the client's certificate was rejected by the server (and the connection interrupted). This happens because starting from TLS1.3, the 'Finished' state on the client is reached before its certificate is sent to the server (see the "Protocol Overview" part of RFC 8446). The only place where we can detect that the server rejected the certificate is after the first SSL_read call after the SSL_do_handshake function. This patch then adds an extra ERR_peek_error after the SSL_read and SSL_write calls in ssl_sock_to_buf and ssl_sock_from_buf. This means that it could set an error code in the SSL context a long time after the handshake is over, hence the change in the error fetches.
2021-09-29 12:56:53 -04:00
ctx->error_code = ERR_peek_error();
MINOR: ssl: Set connection error code in case of SSL read or write fatal failure In case of a connection error happening after the SSL handshake is completed, the error code stored in the connection structure would not always be set, hence having some connection failures being described as successful in the fc_conn_err or bc_conn_err sample fetches. The most common case in which it could happen is when the SSL server rejects the client's certificate. The SSL_do_handshake call on the client side would be sucessful because the client effectively sent its client hello and certificate information to the server, but the next call to SSL_read on the client side would raise an SSL_ERROR_SSL code (through the SSL_get_error function) which is decribed in OpenSSL documentation as a non-recoverable and fatal SSL error. This patch ensures that in such a case, the connection's error code is set to a special CO_ERR_SSL_FATAL value.
2021-09-29 12:56:51 -04:00
conn->err_code = CO_ERR_SSL_FATAL;
}
BUG/MEDIUM: ssl: Shutdown the connection for reading on SSL_ERROR_SYSCALL When SSL_read returns SSL_ERROR_SYSCALL and errno is unset or set to EAGAIN, the connection must be shut down for reading. Else, the connection loops infinitly, consuming all the CPU. The bug was introduced in the commit 7e2e50500 ("BUG/MEDIUM: ssl: Don't always treat SSL_ERROR_SYSCALL as unrecovarable."). This patch must be backported in 1.8 too.
2018-02-19 08:25:15 -05:00
/* For SSL_ERROR_SYSCALL, make sure to clear the error
* stack before shutting down the connection for
* reading. */
MINOR: tree-wide: always consider EWOULDBLOCK in addition to EAGAIN Some older systems may routinely return EWOULDBLOCK for some syscalls while we tend to check only for EAGAIN nowadays. Modern systems define EWOULDBLOCK as EAGAIN so that solves it, but on a few older ones (AIX, VMS etc) both are different, and for portability we'd need to test for both or we never know if we risk to confuse some status codes with plain errors. There were few entries, the most annoying ones are the switch/case because they require to only add the entry when it differs, but the other ones are really trivial.
2022-04-25 14:32:15 -04:00
if (ret == SSL_ERROR_SYSCALL && (!errno || errno == EAGAIN || errno == EWOULDBLOCK))
BUG/MEDIUM: ssl: Don't always treat SSL_ERROR_SYSCALL as unrecovarable. Bart Geesink reported some random errors appearing under the form of termination flags SD in the logs for connections involving SSL traffic to reach the servers. Tomek Gacek and Mateusz Malek finally narrowed down the problem to commit c2aae74 ("MEDIUM: ssl: Handle early data with OpenSSL 1.1.1"). It happens that the special case of SSL_ERROR_SYSCALL isn't handled anymore since this commit. SSL_read() might return <= 0, and SSL_get_erro() return SSL_ERROR_SYSCALL, without meaning the connection is gone. Before flagging the connection as in error, check the errno value. This should be backported to 1.8.
2018-02-13 09:17:23 -05:00
goto clear_ssl_error;
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
/* otherwise it's a real error */
goto out_error;
}
}
MINOR: ssl_sock: make use of CO_FL_WILL_UPDATE Now when ssl_sock_{to,from}_buf are called, if the connection doesn't feature CO_FL_WILL_UPDATE, they will first retrieve the updated flags using conn_refresh_polling_flags() before changing any flag, then call conn_cond_update_sock_polling() before leaving, to commit such changes.
2017-10-25 03:32:15 -04:00
leave:
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
return done;
BUG/MEDIUM: ssl: Shutdown the connection for reading on SSL_ERROR_SYSCALL When SSL_read returns SSL_ERROR_SYSCALL and errno is unset or set to EAGAIN, the connection must be shut down for reading. Else, the connection loops infinitly, consuming all the CPU. The bug was introduced in the commit 7e2e50500 ("BUG/MEDIUM: ssl: Don't always treat SSL_ERROR_SYSCALL as unrecovarable."). This patch must be backported in 1.8 too.
2018-02-19 08:25:15 -05:00
clear_ssl_error:
/* Clear openssl global errors stack */
BUG/MINOR: quic: Possible crash when verifying certificates This verification is done by ssl_sock_bind_verifycbk() which is set at different locations in the ssl_sock.c code . About QUIC connections, there are a lot of chances the connection object is not initialized when entering this function. What must be accessed is the SSL object to retrieve the connection or quic_conn objects, then the bind_conf object of the listener. If the connection object is not found, we try to find the quic_conn object. Modify ssl_sock_dump_errors() interface which takes a connection object as parameter to also passed a quic_conn object as parameter. Again this function try first to access the connection object if not NULL or the quic_conn object if not. There is a remaining thing to do for QUIC: store the certificate verification error code as it is currently stored in the connection object. This error code is at least used by the "bc_err" and "fc_err" sample fetches. There are chances this bug is in relation with GH #1851. Thank you to @tasavis for the report. Must be merged into 2.6.
2022-09-06 13:37:08 -04:00
ssl_sock_dump_errors(conn, NULL);
BUG/MEDIUM: ssl: Shutdown the connection for reading on SSL_ERROR_SYSCALL When SSL_read returns SSL_ERROR_SYSCALL and errno is unset or set to EAGAIN, the connection must be shut down for reading. Else, the connection loops infinitly, consuming all the CPU. The bug was introduced in the commit 7e2e50500 ("BUG/MEDIUM: ssl: Don't always treat SSL_ERROR_SYSCALL as unrecovarable."). This patch must be backported in 1.8 too.
2018-02-19 08:25:15 -05:00
ERR_clear_error();
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
read0:
conn_sock_read0(conn);
MINOR: ssl_sock: make use of CO_FL_WILL_UPDATE Now when ssl_sock_{to,from}_buf are called, if the connection doesn't feature CO_FL_WILL_UPDATE, they will first retrieve the updated flags using conn_refresh_polling_flags() before changing any flag, then call conn_cond_update_sock_polling() before leaving, to commit such changes.
2017-10-25 03:32:15 -04:00
goto leave;
BUG/MEDIUM: ssl: Shutdown the connection for reading on SSL_ERROR_SYSCALL When SSL_read returns SSL_ERROR_SYSCALL and errno is unset or set to EAGAIN, the connection must be shut down for reading. Else, the connection loops infinitly, consuming all the CPU. The bug was introduced in the commit 7e2e50500 ("BUG/MEDIUM: ssl: Don't always treat SSL_ERROR_SYSCALL as unrecovarable."). This patch must be backported in 1.8 too.
2018-02-19 08:25:15 -05:00
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
out_error:
BUG/MEDIUM: ssl: Don't always treat SSL_ERROR_SYSCALL as unrecovarable. Bart Geesink reported some random errors appearing under the form of termination flags SD in the logs for connections involving SSL traffic to reach the servers. Tomek Gacek and Mateusz Malek finally narrowed down the problem to commit c2aae74 ("MEDIUM: ssl: Handle early data with OpenSSL 1.1.1"). It happens that the special case of SSL_ERROR_SYSCALL isn't handled anymore since this commit. SSL_read() might return <= 0, and SSL_get_erro() return SSL_ERROR_SYSCALL, without meaning the connection is gone. Before flagging the connection as in error, check the errno value. This should be backported to 1.8.
2018-02-13 09:17:23 -05:00
conn->flags |= CO_FL_ERROR;
BUG/MEDIUM: ssl: Prevent ssl error from affecting other connections. J. Maurice reported that ssllabs.com test affects unrelated legitimate traffic and cause SSL errors and broken connections. Sometimes openssl store read/write/handshake errors in a global stack. This stack is not specific to the current session. Openssl API does not clean the stack at the beginning of a new read/write. And the function used to retrieve error ID after read/write, returns the generic error SSL_ERROR_SSL if the global stack is not empty. The fix consists in cleaning the errors stack after read/write/handshake errors.
2012-12-14 05:21:13 -05:00
/* Clear openssl global errors stack */
BUG/MINOR: quic: Possible crash when verifying certificates This verification is done by ssl_sock_bind_verifycbk() which is set at different locations in the ssl_sock.c code . About QUIC connections, there are a lot of chances the connection object is not initialized when entering this function. What must be accessed is the SSL object to retrieve the connection or quic_conn objects, then the bind_conf object of the listener. If the connection object is not found, we try to find the quic_conn object. Modify ssl_sock_dump_errors() interface which takes a connection object as parameter to also passed a quic_conn object as parameter. Again this function try first to access the connection object if not NULL or the quic_conn object if not. There is a remaining thing to do for QUIC: store the certificate verification error code as it is currently stored in the connection object. This error code is at least used by the "bc_err" and "fc_err" sample fetches. There are chances this bug is in relation with GH #1851. Thank you to @tasavis for the report. Must be merged into 2.6.
2022-09-06 13:37:08 -04:00
ssl_sock_dump_errors(conn, NULL);
BUG/MEDIUM: ssl: Prevent ssl error from affecting other connections. J. Maurice reported that ssllabs.com test affects unrelated legitimate traffic and cause SSL errors and broken connections. Sometimes openssl store read/write/handshake errors in a global stack. This stack is not specific to the current session. Openssl API does not clean the stack at the beginning of a new read/write. And the function used to retrieve error ID after read/write, returns the generic error SSL_ERROR_SSL if the global stack is not empty. The fix consists in cleaning the errors stack after read/write/handshake errors.
2012-12-14 05:21:13 -05:00
ERR_clear_error();
MINOR: ssl_sock: make use of CO_FL_WILL_UPDATE Now when ssl_sock_{to,from}_buf are called, if the connection doesn't feature CO_FL_WILL_UPDATE, they will first retrieve the updated flags using conn_refresh_polling_flags() before changing any flag, then call conn_cond_update_sock_polling() before leaving, to commit such changes.
2017-10-25 03:32:15 -04:00
goto leave;
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
}
MEDIUM: connection: make xprt->snd_buf() take the byte count in argument This way the senders don't need to modify the buffer's metadata anymore nor to know about the output's split point. This way the functions can take a const buffer and it's clearer who's in charge of updating the buffer after a send. That's why the buffer realignment is now performed by the caller of the transport's snd_buf() functions. The return type was updated to return a size_t to comply with the count argument.
2018-06-14 12:31:46 -04:00
/* Send up to <count> pending bytes from buffer <buf> to connection <conn>'s
* socket. <flags> may contain some CO_SFL_* flags to hint the system about
* other pending data for example, but this flag is ignored at the moment.
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
* Only one call to send() is performed, unless the buffer wraps, in which case
* a second call may be performed. The connection's flags are updated with
* whatever special event is detected (error, empty). The caller is responsible
* for taking care of those events and avoiding the call if inappropriate. The
* function does not call the connection's polling update function, so the caller
MEDIUM: connection: make xprt->snd_buf() take the byte count in argument This way the senders don't need to modify the buffer's metadata anymore nor to know about the output's split point. This way the functions can take a const buffer and it's clearer who's in charge of updating the buffer after a send. That's why the buffer realignment is now performed by the caller of the transport's snd_buf() functions. The return type was updated to return a size_t to comply with the count argument.
2018-06-14 12:31:46 -04:00
* is responsible for this. The buffer's output is not adjusted, it's up to the
* caller to take care of this. It's up to the caller to update the buffer's
* contents based on the return value.
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
*/
MEDIUM: connections: Provide a xprt_ctx for each xprt method. For most of the xprt methods, provide a xprt_ctx. This will be useful later when we'll want to be able to stack xprts. The init() method now has to create and provide the said xprt_ctx if needed.
2019-03-21 13:27:17 -04:00
static size_t ssl_sock_from_buf(struct connection *conn, void *xprt_ctx, const struct buffer *buf, size_t count, int flags)
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
{
MEDIUM: connections: Provide a xprt_ctx for each xprt method. For most of the xprt methods, provide a xprt_ctx. This will be useful later when we'll want to be able to stack xprts. The init() method now has to create and provide the said xprt_ctx if needed.
2019-03-21 13:27:17 -04:00
struct ssl_sock_ctx *ctx = xprt_ctx;
MEDIUM: connection: make xprt->snd_buf() take the byte count in argument This way the senders don't need to modify the buffer's metadata anymore nor to know about the output's split point. This way the functions can take a const buffer and it's clearer who's in charge of updating the buffer after a send. That's why the buffer realignment is now performed by the caller of the transport's snd_buf() functions. The return type was updated to return a size_t to comply with the count argument.
2018-06-14 12:31:46 -04:00
ssize_t ret;
size_t try, done;
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
done = 0;
MEDIUM: connections: Provide a xprt_ctx for each xprt method. For most of the xprt methods, provide a xprt_ctx. This will be useful later when we'll want to be able to stack xprts. The init() method now has to create and provide the said xprt_ctx if needed.
2019-03-21 13:27:17 -04:00
if (!ctx)
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
goto out_error;
MEDIUM: connection: use CO_FL_WAIT_XPRT more consistently than L4/L6/HANDSHAKE As mentioned in commit c192b0ab95 ("MEDIUM: connection: remove CO_FL_CONNECTED and only rely on CO_FL_WAIT_*"), there is a lack of consistency on which flags are checked among L4/L6/HANDSHAKE depending on the code areas. A number of sample fetch functions only check for L4L6 to report MAY_CHANGE, some places only check for HANDSHAKE and many check both L4L6 and HANDSHAKE. This patch starts to make all of this more consistent by introducing a new mask CO_FL_WAIT_XPRT which is the union of L4/L6/HANDSHAKE and reports whether the transport layer is ready or not. All inconsistent call places were updated to rely on this one each time the goal was to check for the readiness of the transport layer.
2020-01-23 10:27:54 -05:00
if (conn->flags & (CO_FL_WAIT_XPRT | CO_FL_SSL_WAIT_HS | CO_FL_EARLY_SSL_HS))
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
/* a handshake was requested */
return 0;
/* send the largest possible block. For this we perform only one call
* to send() unless the buffer wraps and we exactly fill the first hunk,
* in which case we accept to do it once again.
*/
MEDIUM: connection: make xprt->snd_buf() take the byte count in argument This way the senders don't need to modify the buffer's metadata anymore nor to know about the output's split point. This way the functions can take a const buffer and it's clearer who's in charge of updating the buffer after a send. That's why the buffer realignment is now performed by the caller of the transport's snd_buf() functions. The return type was updated to return a size_t to comply with the count argument.
2018-06-14 12:31:46 -04:00
while (count) {
BUILD: ssl: more elegant OpenSSL early data support check BorinSSL pretends to be 1.1.1 version of OpenSSL. It messes some version based feature presense checks. For example, OpenSSL specific early data support. Let us change that feature detction to SSL_READ_EARLY_DATA_SUCCESS macro check instead of version comparision.
2020-10-24 14:42:30 -04:00
#ifdef SSL_READ_EARLY_DATA_SUCCESS
MEDIUM: ssl: Handle early data with OpenSSL 1.1.1 When compiled with Openssl >= 1.1.1, before attempting to do the handshake, try to read any early data. If any early data is present, then we'll create the session, read the data, and handle the request before we're doing the handshake. For this, we add a new connection flag, CO_FL_EARLY_SSL_HS, which is not part of the CO_FL_HANDSHAKE set, allowing to proceed with a session even before an SSL handshake is completed. As early data do have security implication, we let the origin server know the request comes from early data by adding the "Early-Data" header, as specified in this draft from the HTTP working group : https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-replay
2017-09-22 12:26:28 -04:00
size_t written_data;
#endif
MEDIUM: connection: make xprt->snd_buf() take the byte count in argument This way the senders don't need to modify the buffer's metadata anymore nor to know about the output's split point. This way the functions can take a const buffer and it's clearer who's in charge of updating the buffer after a send. That's why the buffer realignment is now performed by the caller of the transport's snd_buf() functions. The return type was updated to return a size_t to comply with the count argument.
2018-06-14 12:31:46 -04:00
try = b_contig_data(buf, done);
if (try > count)
try = count;
MINOR: ssl: add a global tunable for the max SSL/TLS record size Add new tunable "tune.ssl.maxrecord". Over SSL/TLS, the client can decipher the data only once it has received a full record. With large records, it means that clients might have to download up to 16kB of data before starting to process them. Limiting the record size can improve page load times on browsers located over high latency or low bandwidth networks. It is suggested to find optimal values which fit into 1 or 2 TCP segments (generally 1448 bytes over Ethernet with TCP timestamps enabled, or 1460 when timestamps are disabled), keeping in mind that SSL/TLS add some overhead. Typical values of 1419 and 2859 gave good results during tests. Use "strace -e trace=write" to find the best value. This trick was first suggested by Mike Belshe : http://www.belshe.com/2010/12/17/performance-and-the-tls-record-size/ Then requested again by Ilya Grigorik who provides some hints here : http://ofps.oreilly.com/titles/9781449344764/_transport_layer_security_tls.html#ch04_00000101
2013-02-21 01:46:09 -05:00
MINOR: ssl: add a new global option "tune.ssl.hard-maxrecord" Low footprint client machines may not have enough memory to download a complete 16KB TLS record at once. With the new option the maximum record size can be defined on the server side. Note: Before limiting the the record size on the server side, a client should consider using the TLS Maximum Fragment Length Negotiation Extension defined in RFC6066. This patch fixes GitHub issue #1679.
2022-04-27 07:04:54 -04:00
if (global_ssl.hard_max_record && try > global_ssl.hard_max_record)
try = global_ssl.hard_max_record;
OPTIM: ssl: implement dynamic record size adjustment By having the stream interface pass the CF_STREAMER flag to the snd_buf() primitive, we're able to tell the send layer whether we're sending large chunks or small ones. We use this information in SSL to adjust the max record dynamically. This results in small chunks respecting tune.ssl.maxrecord at the beginning of a transfer or for small transfers, with an automatic switch to full records if the exchanges last long. This allows the receiver to parse HTML contents on the fly without having to retrieve 16kB of data, which is even more important with small initcwnd since the receiver does not need to wait for round trips to start fetching new objects. However, sending large files still produces large chunks. For example, with tune.ssl.maxrecord = 2859, we see 5 write(2885) sent in two segments each and 6 write(16421). This idea was first proposed on the haproxy mailing list by Ilya Grigorik.
2014-02-01 20:00:24 -05:00
if (!(flags & CO_SFL_STREAMER) &&
MEDIUM: connections: Move some fields from struct connection to ssl_sock_ctx. Move xprt_st, tmp_early_data and sent_early_data from struct connection to struct ssl_sock_ctx, as they are only used in the SSL code.
2019-02-28 12:10:45 -05:00
!(ctx->xprt_st & SSL_SOCK_SEND_UNLIMITED) &&
CLEANUP: ssl: move most ssl-specific global settings to ssl_sock.c Historically a lot of SSL global settings were stored into the global struct, but we've reached a point where there are 3 ifdefs in it just for this, and others in haproxy.c to initialize it. This patch moves all the private fields to a new struct "global_ssl" stored in ssl_sock.c. This includes : char *crt_base; char *ca_base; char *listen_default_ciphers; char *connect_default_ciphers; int listen_default_ssloptions; int connect_default_ssloptions; int tune.sslprivatecache; /* Force to use a private session cache even if nbproc > 1 */ unsigned int tune.ssllifetime; /* SSL session lifetime in seconds */ unsigned int tune.ssl_max_record; /* SSL max record size */ unsigned int tune.ssl_default_dh_param; /* SSL maximum DH parameter size */ int tune.ssl_ctx_cache; /* max number of entries in the ssl_ctx cache. */ The "tune" part was removed (useless here) and the occasional "ssl" prefixes were removed as well. Thus for example instead of global.tune.ssl_default_dh_param we now have : global_ssl.default_dh_param A few initializers were present in the constructor, they could be brought back to the structure declaration. A few other entries had to stay in global for now. They concern memory calculationn (used in haproxy.c) and stats (used in stats.c). The code is already much cleaner now, especially for global.h and haproxy.c which become readable.
2016-12-22 17:12:01 -05:00
global_ssl.max_record && try > global_ssl.max_record) {
try = global_ssl.max_record;
BUG/MEDIUM: ssl: always send a full buffer after EAGAIN Igor Chan reported a very interesting bug which was triggered by the recent dynamic size change in SSL. The OpenSSL API refuses to send less data than any failed previous attempt. So what's happening is that if an SSL_write() in streaming mode sends 5kB of data and the openssl layer cannot send them all, it returns SSL_ERROR_WANT_WRITE, which haproxy reacts to by enabling polling on the file descriptor. In the mean time, haproxy may detect that the buffer was almost full and will disable streaming mode. Upon write notification, it will try to send again, but less data this time (limited to tune.ssl_max_record). OpenSSL disagrees with this and returns a generic error SSL_ERROR_SSL. The solution which was found consists in adding a flag to the SSL context to remind that we must not shrink writes after a failed attempt. Thus, if EAGAIN is encountered, the next send() will not be limited in order to retry the same size as before.
2014-02-17 09:43:01 -05:00
}
else {
/* we need to keep the information about the fact that
* we're not limiting the upcoming send(), because if it
* fails, we'll have to retry with at least as many data.
*/
MEDIUM: connections: Move some fields from struct connection to ssl_sock_ctx. Move xprt_st, tmp_early_data and sent_early_data from struct connection to struct ssl_sock_ctx, as they are only used in the SSL code.
2019-02-28 12:10:45 -05:00
ctx->xprt_st |= SSL_SOCK_SEND_UNLIMITED;
BUG/MEDIUM: ssl: always send a full buffer after EAGAIN Igor Chan reported a very interesting bug which was triggered by the recent dynamic size change in SSL. The OpenSSL API refuses to send less data than any failed previous attempt. So what's happening is that if an SSL_write() in streaming mode sends 5kB of data and the openssl layer cannot send them all, it returns SSL_ERROR_WANT_WRITE, which haproxy reacts to by enabling polling on the file descriptor. In the mean time, haproxy may detect that the buffer was almost full and will disable streaming mode. Upon write notification, it will try to send again, but less data this time (limited to tune.ssl_max_record). OpenSSL disagrees with this and returns a generic error SSL_ERROR_SSL. The solution which was found consists in adding a flag to the SSL context to remind that we must not shrink writes after a failed attempt. Thus, if EAGAIN is encountered, the next send() will not be limited in order to retry the same size as before.
2014-02-17 09:43:01 -05:00
}
MINOR: ssl: add a global tunable for the max SSL/TLS record size Add new tunable "tune.ssl.maxrecord". Over SSL/TLS, the client can decipher the data only once it has received a full record. With large records, it means that clients might have to download up to 16kB of data before starting to process them. Limiting the record size can improve page load times on browsers located over high latency or low bandwidth networks. It is suggested to find optimal values which fit into 1 or 2 TCP segments (generally 1448 bytes over Ethernet with TCP timestamps enabled, or 1460 when timestamps are disabled), keeping in mind that SSL/TLS add some overhead. Typical values of 1419 and 2859 gave good results during tests. Use "strace -e trace=write" to find the best value. This trick was first suggested by Mike Belshe : http://www.belshe.com/2010/12/17/performance-and-the-tls-record-size/ Then requested again by Ilya Grigorik who provides some hints here : http://ofps.oreilly.com/titles/9781449344764/_transport_layer_security_tls.html#ch04_00000101
2013-02-21 01:46:09 -05:00
MINOR: ssl-sock: pass the CO_SFL_MSG_MORE info down the stack Despite having replaced the SSL BIOs to use our own raw_sock layer, we still didn't exploit the CO_SFL_MSG_MORE flag which is pretty useful to avoid sending incomplete packets. It's particularly important for SSL since the extra overhead almost guarantees that each send() will be followed by an incomplete (and often odd-sided) segment. We already have an xprt_st set of flags to pass info to the various layers, so let's just add a new one, SSL_SOCK_SEND_MORE, that is set or cleared during ssl_sock_from_buf() to transfer the knowledge of CO_SFL_MSG_MORE. This way we can recover this information and pass it to raw_sock. This alone is sufficient to increase by ~5-10% the H2 bandwidth over SSL when multiple streams are used in parallel.
2023-03-17 11:13:05 -04:00
if (try < count || flags & CO_SFL_MSG_MORE)
ctx->xprt_st |= SSL_SOCK_SEND_MORE;
else
ctx->xprt_st &= ~SSL_SOCK_SEND_MORE;
BUILD: ssl: more elegant OpenSSL early data support check BorinSSL pretends to be 1.1.1 version of OpenSSL. It messes some version based feature presense checks. For example, OpenSSL specific early data support. Let us change that feature detction to SSL_READ_EARLY_DATA_SUCCESS macro check instead of version comparision.
2020-10-24 14:42:30 -04:00
#ifdef SSL_READ_EARLY_DATA_SUCCESS
BUG/MEDIUM: ssl: Use the early_data API the right way. We can only read early data if we're a server, and write if we're a client, so don't attempt to mix both. This should be backported to 1.8 and 1.9.
2019-05-03 14:56:19 -04:00
if (!SSL_is_init_finished(ctx->ssl) && conn_is_back(conn)) {
MEDIUM: ssl: Handle early data with OpenSSL 1.1.1 When compiled with Openssl >= 1.1.1, before attempting to do the handshake, try to read any early data. If any early data is present, then we'll create the session, read the data, and handle the request before we're doing the handshake. For this, we add a new connection flag, CO_FL_EARLY_SSL_HS, which is not part of the CO_FL_HANDSHAKE set, allowing to proceed with a session even before an SSL handshake is completed. As early data do have security implication, we let the origin server know the request comes from early data by adding the "Early-Data" header, as specified in this draft from the HTTP working group : https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-replay
2017-09-22 12:26:28 -04:00
unsigned int max_early;
MINOR: ssl: Handle sending early data to server. This adds a new keyword on the "server" line, "allow-0rtt", if set, we'll try to send early data to the server, as long as the client sent early data, as in case the server rejects the early data, we no longer have them, and can't resend them, so the only option we have is to send back a 425, and we need to be sure the client knows how to interpret it correctly.
2017-11-03 11:27:47 -04:00
if (objt_listener(conn->target))
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
max_early = SSL_get_max_early_data(ctx->ssl);
MINOR: ssl: Handle sending early data to server. This adds a new keyword on the "server" line, "allow-0rtt", if set, we'll try to send early data to the server, as long as the client sent early data, as in case the server rejects the early data, we no longer have them, and can't resend them, so the only option we have is to send back a 425, and we need to be sure the client knows how to interpret it correctly.
2017-11-03 11:27:47 -04:00
else {
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
if (SSL_get0_session(ctx->ssl))
max_early = SSL_SESSION_get_max_early_data(SSL_get0_session(ctx->ssl));
MINOR: ssl: Handle sending early data to server. This adds a new keyword on the "server" line, "allow-0rtt", if set, we'll try to send early data to the server, as long as the client sent early data, as in case the server rejects the early data, we no longer have them, and can't resend them, so the only option we have is to send back a 425, and we need to be sure the client knows how to interpret it correctly.
2017-11-03 11:27:47 -04:00
else
max_early = 0;
}
MEDIUM: connections: Move some fields from struct connection to ssl_sock_ctx. Move xprt_st, tmp_early_data and sent_early_data from struct connection to struct ssl_sock_ctx, as they are only used in the SSL code.
2019-02-28 12:10:45 -05:00
if (try + ctx->sent_early_data > max_early) {
try -= (try + ctx->sent_early_data) - max_early;
MINOR: ssl: Handle sending early data to server. This adds a new keyword on the "server" line, "allow-0rtt", if set, we'll try to send early data to the server, as long as the client sent early data, as in case the server rejects the early data, we no longer have them, and can't resend them, so the only option we have is to send back a 425, and we need to be sure the client knows how to interpret it correctly.
2017-11-03 11:27:47 -04:00
if (try <= 0) {
BUG/MEDIUM: ssl: Use the early_data API the right way. We can only read early data if we're a server, and write if we're a client, so don't attempt to mix both. This should be backported to 1.8 and 1.9.
2019-05-03 14:56:19 -04:00
conn->flags |= CO_FL_SSL_WAIT_HS | CO_FL_WAIT_L6_CONN;
BUG/MEDIUM: ssl: Make sure we initiate the handshake after using early data. When we're done sending/receiving early data, and we add the handshake flags on the connection, make sure we wake the associated tasklet up, so that the handshake will be initiated.
2019-06-15 14:59:30 -04:00
tasklet_wakeup(ctx->wait_event.tasklet);
MEDIUM: ssl: Handle early data with OpenSSL 1.1.1 When compiled with Openssl >= 1.1.1, before attempting to do the handshake, try to read any early data. If any early data is present, then we'll create the session, read the data, and handle the request before we're doing the handshake. For this, we add a new connection flag, CO_FL_EARLY_SSL_HS, which is not part of the CO_FL_HANDSHAKE set, allowing to proceed with a session even before an SSL handshake is completed. As early data do have security implication, we let the origin server know the request comes from early data by adding the "Early-Data" header, as specified in this draft from the HTTP working group : https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-replay
2017-09-22 12:26:28 -04:00
break;
MINOR: ssl: Handle sending early data to server. This adds a new keyword on the "server" line, "allow-0rtt", if set, we'll try to send early data to the server, as long as the client sent early data, as in case the server rejects the early data, we no longer have them, and can't resend them, so the only option we have is to send back a 425, and we need to be sure the client knows how to interpret it correctly.
2017-11-03 11:27:47 -04:00
}
MEDIUM: ssl: Handle early data with OpenSSL 1.1.1 When compiled with Openssl >= 1.1.1, before attempting to do the handshake, try to read any early data. If any early data is present, then we'll create the session, read the data, and handle the request before we're doing the handshake. For this, we add a new connection flag, CO_FL_EARLY_SSL_HS, which is not part of the CO_FL_HANDSHAKE set, allowing to proceed with a session even before an SSL handshake is completed. As early data do have security implication, we let the origin server know the request comes from early data by adding the "Early-Data" header, as specified in this draft from the HTTP working group : https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-replay
2017-09-22 12:26:28 -04:00
}
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
ret = SSL_write_early_data(ctx->ssl, b_peek(buf, done), try, &written_data);
MEDIUM: ssl: Handle early data with OpenSSL 1.1.1 When compiled with Openssl >= 1.1.1, before attempting to do the handshake, try to read any early data. If any early data is present, then we'll create the session, read the data, and handle the request before we're doing the handshake. For this, we add a new connection flag, CO_FL_EARLY_SSL_HS, which is not part of the CO_FL_HANDSHAKE set, allowing to proceed with a session even before an SSL handshake is completed. As early data do have security implication, we let the origin server know the request comes from early data by adding the "Early-Data" header, as specified in this draft from the HTTP working group : https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-replay
2017-09-22 12:26:28 -04:00
if (ret == 1) {
ret = written_data;
MEDIUM: connections: Move some fields from struct connection to ssl_sock_ctx. Move xprt_st, tmp_early_data and sent_early_data from struct connection to struct ssl_sock_ctx, as they are only used in the SSL code.
2019-02-28 12:10:45 -05:00
ctx->sent_early_data += ret;
BUG/MEDIUM: ssl: Make sure we initiate the handshake after using early data. When we're done sending/receiving early data, and we add the handshake flags on the connection, make sure we wake the associated tasklet up, so that the handshake will be initiated.
2019-06-15 14:59:30 -04:00
if (objt_server(conn->target)) {
MINOR: ssl: Handle sending early data to server. This adds a new keyword on the "server" line, "allow-0rtt", if set, we'll try to send early data to the server, as long as the client sent early data, as in case the server rejects the early data, we no longer have them, and can't resend them, so the only option we have is to send back a 425, and we need to be sure the client knows how to interpret it correctly.
2017-11-03 11:27:47 -04:00
conn->flags |= CO_FL_SSL_WAIT_HS | CO_FL_WAIT_L6_CONN | CO_FL_EARLY_DATA;
BUG/MEDIUM: ssl: Make sure we initiate the handshake after using early data. When we're done sending/receiving early data, and we add the handshake flags on the connection, make sure we wake the associated tasklet up, so that the handshake will be initiated.
2019-06-15 14:59:30 -04:00
/* Initiate the handshake, now */
tasklet_wakeup(ctx->wait_event.tasklet);
}
MINOR: ssl: Handle sending early data to server. This adds a new keyword on the "server" line, "allow-0rtt", if set, we'll try to send early data to the server, as long as the client sent early data, as in case the server rejects the early data, we no longer have them, and can't resend them, so the only option we have is to send back a 425, and we need to be sure the client knows how to interpret it correctly.
2017-11-03 11:27:47 -04:00
MEDIUM: ssl: Handle early data with OpenSSL 1.1.1 When compiled with Openssl >= 1.1.1, before attempting to do the handshake, try to read any early data. If any early data is present, then we'll create the session, read the data, and handle the request before we're doing the handshake. For this, we add a new connection flag, CO_FL_EARLY_SSL_HS, which is not part of the CO_FL_HANDSHAKE set, allowing to proceed with a session even before an SSL handshake is completed. As early data do have security implication, we let the origin server know the request comes from early data by adding the "Early-Data" header, as specified in this draft from the HTTP working group : https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-replay
2017-09-22 12:26:28 -04:00
}
} else
#endif
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
ret = SSL_write(ctx->ssl, b_peek(buf, done), try);
BUG/MEDIUM: ssl: always send a full buffer after EAGAIN Igor Chan reported a very interesting bug which was triggered by the recent dynamic size change in SSL. The OpenSSL API refuses to send less data than any failed previous attempt. So what's happening is that if an SSL_write() in streaming mode sends 5kB of data and the openssl layer cannot send them all, it returns SSL_ERROR_WANT_WRITE, which haproxy reacts to by enabling polling on the file descriptor. In the mean time, haproxy may detect that the buffer was almost full and will disable streaming mode. Upon write notification, it will try to send again, but less data this time (limited to tune.ssl_max_record). OpenSSL disagrees with this and returns a generic error SSL_ERROR_SSL. The solution which was found consists in adding a flag to the SSL context to remind that we must not shrink writes after a failed attempt. Thus, if EAGAIN is encountered, the next send() will not be limited in order to retry the same size as before.
2014-02-17 09:43:01 -05:00
MEDIUM: ssl: protect against client-initiated renegociation CVE-2009-3555 suggests that client-initiated renegociation should be prevented in the middle of data. The workaround here consists in having the SSL layer notify our callback about a handshake occurring, which in turn causes the connection to be marked in the error state if it was already considered established (which means if a previous handshake was completed). The result is that the connection with the client is immediately aborted and any pending data are dropped.
2012-09-03 14:36:47 -04:00
if (conn->flags & CO_FL_ERROR) {
/* CO_FL_ERROR may be set by ssl_sock_infocbk */
BUG/MEDIUM: ssl: Prevent ssl error from affecting other connections. J. Maurice reported that ssllabs.com test affects unrelated legitimate traffic and cause SSL errors and broken connections. Sometimes openssl store read/write/handshake errors in a global stack. This stack is not specific to the current session. Openssl API does not clean the stack at the beginning of a new read/write. And the function used to retrieve error ID after read/write, returns the generic error SSL_ERROR_SSL if the global stack is not empty. The fix consists in cleaning the errors stack after read/write/handshake errors.
2012-12-14 05:21:13 -05:00
goto out_error;
MEDIUM: ssl: protect against client-initiated renegociation CVE-2009-3555 suggests that client-initiated renegociation should be prevented in the middle of data. The workaround here consists in having the SSL layer notify our callback about a handshake occurring, which in turn causes the connection to be marked in the error state if it was already considered established (which means if a previous handshake was completed). The result is that the connection with the client is immediately aborted and any pending data are dropped.
2012-09-03 14:36:47 -04:00
}
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
if (ret > 0) {
MEDIUM: connection: remove CO_FL_CONNECTED and only rely on CO_FL_WAIT_* Commit 477902bd2e ("MEDIUM: connections: Get ride of the xprt_done callback.") broke the master CLI for a very obscure reason. It happens that short requests immediately terminated by a shutdown are properly received, CS_FL_EOS is correctly set, but in si_cs_recv(), we refrain from setting CF_SHUTR on the channel because CO_FL_CONNECTED was not yet set on the connection since we've not passed again through conn_fd_handler() and it was not done in conn_complete_session(). While commit a8a415d31a ("BUG/MEDIUM: connections: Set CO_FL_CONNECTED in conn_complete_session()") fixed the issue, such accident may happen again as the root cause is deeper and actually comes down to the fact that CO_FL_CONNECTED is lazily set at various check points in the code but not every time we drop one wait bit. It is not the first time we face this situation. Originally this flag was used to detect the transition between WAIT_* and CONNECTED in order to call ->wake() from the FD handler. But since at least 1.8-dev1 with commit 7bf3fa3c23 ("BUG/MAJOR: connection: update CO_FL_CONNECTED before calling the data layer"), CO_FL_CONNECTED is always synchronized against the two others before being checked. Moreover, with the I/Os moved to tasklets, the decision to call the ->wake() function is performed after the I/Os in si_cs_process() and equivalent, which don't care about this transition either. So in essence, checking for CO_FL_CONNECTED has become a lazy wait to check for (CO_FL_WAIT_L4_CONN | CO_FL_WAIT_L6_CONN), but that always relies on someone else having synchronized it. This patch addresses it once for all by killing this flag and only checking the two others (for which a composite mask CO_FL_WAIT_L4L6 was added). This revealed a number of inconsistencies that were purposely not addressed here for the sake of bisectability: - while most places do check both L4+L6 and HANDSHAKE at the same time, some places like assign_server() or back_handle_st_con() and a few sample fetches looking for proxy protocol do check for L4+L6 but don't care about HANDSHAKE ; these ones will probably fail on TCP request session rules if the handshake is not complete. - some handshake handlers do validate that a connection is established at L4 but didn't clear CO_FL_WAIT_L4_CONN - the ->ctl method of mux_fcgi, mux_pt and mux_h1 only checks for L4+L6 before declaring the mux ready while the snd_buf function also checks for the handshake's completion. Likely the former should validate the handshake as well and we should get rid of these extra tests in snd_buf. - raw_sock_from_buf() would directly set CO_FL_CONNECTED and would only later clear CO_FL_WAIT_L4_CONN. - xprt_handshake would set CO_FL_CONNECTED itself without actually clearing CO_FL_WAIT_L4_CONN, which could apparently happen only if waiting for a pure Rx handshake. - most places in ssl_sock that were checking CO_FL_CONNECTED don't need to include the L4 check as an L6 check is enough to decide whether to wait for more info or not. It also becomes obvious when reading the test in si_cs_recv() that caused the failure mentioned above that once converted it doesn't make any sense anymore: having CS_FL_EOS set while still waiting for L4 and L6 to complete cannot happen since for CS_FL_EOS to be set, the other ones must have been validated. Some of these parts will still deserve further cleanup, and some of the observations above may induce some backports of potential bug fixes once totally analyzed in their context. The risk of breaking existing stuff is too high to blindly backport everything.
2020-01-23 03:11:58 -05:00
/* A send succeeded, so we can consider ourself connected */
conn->flags &= ~CO_FL_WAIT_L4L6;
MEDIUM: connections: Move some fields from struct connection to ssl_sock_ctx. Move xprt_st, tmp_early_data and sent_early_data from struct connection to struct ssl_sock_ctx, as they are only used in the SSL code.
2019-02-28 12:10:45 -05:00
ctx->xprt_st &= ~SSL_SOCK_SEND_UNLIMITED;
MEDIUM: connection: make xprt->snd_buf() take the byte count in argument This way the senders don't need to modify the buffer's metadata anymore nor to know about the output's split point. This way the functions can take a const buffer and it's clearer who's in charge of updating the buffer after a send. That's why the buffer realignment is now performed by the caller of the transport's snd_buf() functions. The return type was updated to return a size_t to comply with the count argument.
2018-06-14 12:31:46 -04:00
count -= ret;
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
done += ret;
}
else {
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
ret = SSL_get_error(ctx->ssl, ret);
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
if (ret == SSL_ERROR_WANT_WRITE) {
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
if (SSL_renegotiate_pending(ctx->ssl)) {
BUG/MEDIUM: ssl: Fix some reneg cases not correctly handled. SSL may decide to switch to a handshake in the middle of a transfer due to a reneg. In this case we don't want to re-enable polling because data might have been left pending in the buffer. We just want to switch immediately to the handshake mode.
2012-11-08 12:02:56 -05:00
/* handshake is running, and it may need to re-enable write */
conn->flags |= CO_FL_SSL_WAIT_HS;
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
ctx->xprt->subscribe(conn, ctx->xprt_ctx, SUB_RETRY_SEND, &ctx->wait_event);
BUILD: ssl: use SSL_MODE_ASYNC macro instead of OPENSSL_VERSION
2020-11-13 15:56:34 -05:00
#ifdef SSL_MODE_ASYNC
BUG/MAJOR: ssl: buffer overflow using offloaded ciphering on async engine The Openssl's ASYNC API does'nt support moving buffers on SSL_read/write This patch disables the ASYNC mode dynamically when the handshake is left and re-enables it on reneg.
2017-06-06 08:35:14 -04:00
/* Async mode can be re-enabled, because we're leaving data state.*/
if (global_ssl.async)
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
SSL_set_mode(ctx->ssl, SSL_MODE_ASYNC);
BUG/MAJOR: ssl: buffer overflow using offloaded ciphering on async engine The Openssl's ASYNC API does'nt support moving buffers on SSL_read/write This patch disables the ASYNC mode dynamically when the handshake is left and re-enables it on reneg.
2017-06-06 08:35:14 -04:00
#endif
BUG/MEDIUM: ssl: Fix some reneg cases not correctly handled. SSL may decide to switch to a handshake in the middle of a transfer due to a reneg. In this case we don't want to re-enable polling because data might have been left pending in the buffer. We just want to switch immediately to the handshake mode.
2012-11-08 12:02:56 -05:00
break;
}
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
break;
}
else if (ret == SSL_ERROR_WANT_READ) {
BUG/MEDIUM: ssl: review polling on reneg. SSL may return SSL_ERROR_WANT_WRITE or SSL_ERROR_WANT_READ when switching from data to handshake even if it does not need to poll first.
2012-11-08 11:56:20 -05:00
/* handshake is running, and it needs to enable read */
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
conn->flags |= CO_FL_SSL_WAIT_HS;
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
ctx->xprt->subscribe(conn, ctx->xprt_ctx,
SUB_RETRY_RECV,
&ctx->wait_event);
BUILD: ssl: use SSL_MODE_ASYNC macro instead of OPENSSL_VERSION
2020-11-13 15:56:34 -05:00
#ifdef SSL_MODE_ASYNC
BUG/MAJOR: ssl: buffer overflow using offloaded ciphering on async engine The Openssl's ASYNC API does'nt support moving buffers on SSL_read/write This patch disables the ASYNC mode dynamically when the handshake is left and re-enables it on reneg.
2017-06-06 08:35:14 -04:00
/* Async mode can be re-enabled, because we're leaving data state.*/
if (global_ssl.async)
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
SSL_set_mode(ctx->ssl, SSL_MODE_ASYNC);
BUG/MAJOR: ssl: buffer overflow using offloaded ciphering on async engine The Openssl's ASYNC API does'nt support moving buffers on SSL_read/write This patch disables the ASYNC mode dynamically when the handshake is left and re-enables it on reneg.
2017-06-06 08:35:14 -04:00
#endif
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
break;
}
MINOR: ssl: Set connection error code in case of SSL read or write fatal failure In case of a connection error happening after the SSL handshake is completed, the error code stored in the connection structure would not always be set, hence having some connection failures being described as successful in the fc_conn_err or bc_conn_err sample fetches. The most common case in which it could happen is when the SSL server rejects the client's certificate. The SSL_do_handshake call on the client side would be sucessful because the client effectively sent its client hello and certificate information to the server, but the next call to SSL_read on the client side would raise an SSL_ERROR_SSL code (through the SSL_get_error function) which is decribed in OpenSSL documentation as a non-recoverable and fatal SSL error. This patch ensures that in such a case, the connection's error code is set to a special CO_ERR_SSL_FATAL value.
2021-09-29 12:56:51 -04:00
else if (ret == SSL_ERROR_SSL || ret == SSL_ERROR_SYSCALL) {
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
struct ssl_sock_ctx *ctx = conn_get_ssl_sock_ctx(conn);
BUILD: ssl: add an unchecked version of __conn_get_ssl_sock_ctx() First gcc, then now coverity report possible null derefs in situations where we know these cannot happen since we call the functions in contexts that guarantee the existence of the connection and the method used. Let's introduce an unchecked version of the function for such cases, just like we had to do with objt_*. This allows us to remove the ALREADY_CHECKED() statements (which coverity doesn't see), and addresses github issues #1643, #1644, #1647.
2022-04-12 01:31:06 -04:00
if (ctx && !ctx->error_code)
MINOR: ssl: Store the last SSL error code in case of read or write failure In case of error while calling a SSL_read or SSL_write, the SSL_get_error function is called in order to know more about the error that happened. If the error code is SSL_ERROR_SSL or SSL_ERROR_SYSCALL, the error queue might contain more information on the error. This error code was not used until now. But we now need to store it in order for backend error fetches to catch all handshake related errors. The change was required because the previous backend fetch would not have raised anything if the client's certificate was rejected by the server (and the connection interrupted). This happens because starting from TLS1.3, the 'Finished' state on the client is reached before its certificate is sent to the server (see the "Protocol Overview" part of RFC 8446). The only place where we can detect that the server rejected the certificate is after the first SSL_read call after the SSL_do_handshake function. This patch then adds an extra ERR_peek_error after the SSL_read and SSL_write calls in ssl_sock_to_buf and ssl_sock_from_buf. This means that it could set an error code in the SSL context a long time after the handshake is over, hence the change in the error fetches.
2021-09-29 12:56:53 -04:00
ctx->error_code = ERR_peek_error();
MINOR: ssl: Set connection error code in case of SSL read or write fatal failure In case of a connection error happening after the SSL handshake is completed, the error code stored in the connection structure would not always be set, hence having some connection failures being described as successful in the fc_conn_err or bc_conn_err sample fetches. The most common case in which it could happen is when the SSL server rejects the client's certificate. The SSL_do_handshake call on the client side would be sucessful because the client effectively sent its client hello and certificate information to the server, but the next call to SSL_read on the client side would raise an SSL_ERROR_SSL code (through the SSL_get_error function) which is decribed in OpenSSL documentation as a non-recoverable and fatal SSL error. This patch ensures that in such a case, the connection's error code is set to a special CO_ERR_SSL_FATAL value.
2021-09-29 12:56:51 -04:00
conn->err_code = CO_ERR_SSL_FATAL;
}
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
goto out_error;
}
}
MINOR: ssl_sock: make use of CO_FL_WILL_UPDATE Now when ssl_sock_{to,from}_buf are called, if the connection doesn't feature CO_FL_WILL_UPDATE, they will first retrieve the updated flags using conn_refresh_polling_flags() before changing any flag, then call conn_cond_update_sock_polling() before leaving, to commit such changes.
2017-10-25 03:32:15 -04:00
leave:
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
return done;
out_error:
BUG/MEDIUM: ssl: Prevent ssl error from affecting other connections. J. Maurice reported that ssllabs.com test affects unrelated legitimate traffic and cause SSL errors and broken connections. Sometimes openssl store read/write/handshake errors in a global stack. This stack is not specific to the current session. Openssl API does not clean the stack at the beginning of a new read/write. And the function used to retrieve error ID after read/write, returns the generic error SSL_ERROR_SSL if the global stack is not empty. The fix consists in cleaning the errors stack after read/write/handshake errors.
2012-12-14 05:21:13 -05:00
/* Clear openssl global errors stack */
BUG/MINOR: quic: Possible crash when verifying certificates This verification is done by ssl_sock_bind_verifycbk() which is set at different locations in the ssl_sock.c code . About QUIC connections, there are a lot of chances the connection object is not initialized when entering this function. What must be accessed is the SSL object to retrieve the connection or quic_conn objects, then the bind_conf object of the listener. If the connection object is not found, we try to find the quic_conn object. Modify ssl_sock_dump_errors() interface which takes a connection object as parameter to also passed a quic_conn object as parameter. Again this function try first to access the connection object if not NULL or the quic_conn object if not. There is a remaining thing to do for QUIC: store the certificate verification error code as it is currently stored in the connection object. This error code is at least used by the "bc_err" and "fc_err" sample fetches. There are chances this bug is in relation with GH #1851. Thank you to @tasavis for the report. Must be merged into 2.6.
2022-09-06 13:37:08 -04:00
ssl_sock_dump_errors(conn, NULL);
BUG/MEDIUM: ssl: Prevent ssl error from affecting other connections. J. Maurice reported that ssllabs.com test affects unrelated legitimate traffic and cause SSL errors and broken connections. Sometimes openssl store read/write/handshake errors in a global stack. This stack is not specific to the current session. Openssl API does not clean the stack at the beginning of a new read/write. And the function used to retrieve error ID after read/write, returns the generic error SSL_ERROR_SSL if the global stack is not empty. The fix consists in cleaning the errors stack after read/write/handshake errors.
2012-12-14 05:21:13 -05:00
ERR_clear_error();
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
conn->flags |= CO_FL_ERROR;
MINOR: ssl_sock: make use of CO_FL_WILL_UPDATE Now when ssl_sock_{to,from}_buf are called, if the connection doesn't feature CO_FL_WILL_UPDATE, they will first retrieve the updated flags using conn_refresh_polling_flags() before changing any flag, then call conn_cond_update_sock_polling() before leaving, to commit such changes.
2017-10-25 03:32:15 -04:00
goto leave;
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
}
DEBUG: ssl: export ssl_sock_close() to see its symbol resolved in profiling This function is one of the few high-profile, unresolved ones in the memory profile output, let's have it resolve to ease matching of SSL allocations, which are not easy to follow.
2021-05-13 04:11:03 -04:00
void ssl_sock_close(struct connection *conn, void *xprt_ctx) {
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
MEDIUM: connections: Provide a xprt_ctx for each xprt method. For most of the xprt methods, provide a xprt_ctx. This will be useful later when we'll want to be able to stack xprts. The init() method now has to create and provide the said xprt_ctx if needed.
2019-03-21 13:27:17 -04:00
struct ssl_sock_ctx *ctx = xprt_ctx;
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
MEDIUM: connections: Provide a xprt_ctx for each xprt method. For most of the xprt methods, provide a xprt_ctx. This will be useful later when we'll want to be able to stack xprts. The init() method now has to create and provide the said xprt_ctx if needed.
2019-03-21 13:27:17 -04:00
if (ctx) {
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
if (ctx->wait_event.events != 0)
ctx->xprt->unsubscribe(ctx->conn, ctx->xprt_ctx,
ctx->wait_event.events,
&ctx->wait_event);
MEDIUM: ssl: merge recv_wait and send_wait in ssl_sock This is the same principle as previous commit, but for ssl_sock.
2020-01-10 03:20:26 -05:00
if (ctx->subs) {
ctx->subs->events = 0;
tasklet_wakeup(ctx->subs->tasklet);
MEDIUM: ssl: Handle subscribe by itself. As the SSL code may have different needs than the upper layer, ie it may want to receive when the upper layer wants to right, instead of directly forwarding the subscribe to the underlying xprt, handle it ourself. The SSL code will know remember any subscribe call, and wake the tasklet when it is ready for more I/O.
2019-05-20 08:02:16 -04:00
}
MEDIUM: ssl: merge recv_wait and send_wait in ssl_sock This is the same principle as previous commit, but for ssl_sock.
2020-01-10 03:20:26 -05:00
MINOR: ssl: Don't forget to call the close method of the underlying xprt. In ssl_sock_close(), don't forget to call the underlying xprt's close method if it exists. For now it's harmless not to do so, because the only available layer is the raw socket, which doesn't have a close method, but that will change when we implement QUIC.
2019-05-23 12:41:47 -04:00
if (ctx->xprt->close)
ctx->xprt->close(conn, ctx->xprt_ctx);
BUILD: ssl: use SSL_MODE_ASYNC macro instead of OPENSSL_VERSION
2020-11-13 15:56:34 -05:00
#ifdef SSL_MODE_ASYNC
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
if (global_ssl.async) {
OSSL_ASYNC_FD all_fd[32], afd;
size_t num_all_fds = 0;
int i;
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
SSL_get_all_async_fds(ctx->ssl, NULL, &num_all_fds);
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
if (num_all_fds > 32) {
send_log(NULL, LOG_EMERG, "haproxy: openssl returns too many async fds. It seems a bug. Process may crash\n");
return;
}
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
SSL_get_all_async_fds(ctx->ssl, all_fd, &num_all_fds);
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
/* If an async job is pending, we must try to
to catch the end using polling before calling
SSL_free */
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
if (num_all_fds && SSL_waiting_for_async(ctx->ssl)) {
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
for (i=0 ; i < num_all_fds ; i++) {
/* switch on an handler designed to
* handle the SSL_free
*/
afd = all_fd[i];
fdtab[afd].iocb = ssl_async_fd_free;
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
fdtab[afd].owner = ctx->ssl;
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
fd_want_recv(afd);
BUG/MAJOR: ssl: fix segfault on connection close using async engines. This patch ensure that the ASYNC fd handlers won't be wake up too early, disabling the event cache for this fd on connection close and when a WANT_ASYNC is rised by Openssl. The calls to SSL_read/SSL_write/SSL_do_handshake before rising a real read event from the ASYNC fd, generated an EAGAIN followed by a context switch for some engines, or a blocked read for the others. On connection close it resulted in a too early call to SSL_free followed by a segmentation fault.
2017-05-31 06:02:53 -04:00
/* To ensure that the fd cache won't be used
* and we'll catch a real RD event.
*/
fd_cant_recv(afd);
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
}
CLEANUP: connection: rename the wait_event.task field to .tasklet It's really confusing to call it a task because it's a tasklet and used in places where tasks and tasklets are used together. Let's rename it to tasklet to remove this confusion.
2019-06-14 08:42:29 -04:00
tasklet_free(ctx->wait_event.tasklet);
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
pool_free(ssl_sock_ctx_pool, ctx);
CLEANUP: atomic/tree-wide: replace single increments/decrements with inc/dec This patch replaces roughly all occurrences of an HA_ATOMIC_ADD(&foo, 1) or HA_ATOMIC_SUB(&foo, 1) with the equivalent HA_ATOMIC_INC(&foo) and HA_ATOMIC_DEC(&foo) respectively. These are 507 changes over 45 files.
2021-04-06 07:53:36 -04:00
_HA_ATOMIC_INC(&jobs);
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
return;
}
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
/* Else we can remove the fds from the fdtab
* and call SSL_free.
MEDIUM: fd: replace usages of fd_remove() with fd_stop_both() We used to require fd_remove() to remove an FD from a poller when we still had the FD cache and it was not possible to directly act on the pollers. Nowadays we don't need this anymore as the pollers will automatically unregister disabled FDs. The fd_remove() hack is particularly problematic because it additionally hides the FD from the known FD list and could make one think it's closed. It's used at two places: - with the async SSL engine - with the listeners (when unbinding from an fd for another process) Let's just use fd_stop_both() instead, which will propagate down the stack to do the right thing, without removing the FD from the array of known ones. Now when dumping FDs using "show fd" on a process which still knows some of the other workers' FDs, the FD will properly be listed with a listener state equal to "ZOM" for "zombie". This guarantees that the FD is still known and will properly be passed using _getsocks().
2020-08-26 05:44:17 -04:00
* note: we do a fd_stop_both and not a delete
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
* because the fd is owned by the engine.
* the engine is responsible to close
*/
BUG/MEDIUM: ssl/fd: unexpected fd close using async engine Before 2.3, after an async crypto processing or on session close, the engine async file's descriptors were removed from the fdtab but not closed because it is the engine which has created the file descriptor, and it is responsible for closing it. In 2.3 the fd_remove() call was replaced by fd_stop_both() which stops the polling but does not remove the fd from the fdtab and the fd remains indefinitively in the fdtab. A simple replacement by fd_delete() is not a valid fix because fd_delete() removes the fd from the fdtab but also closes the fd. And the fd will be closed twice: by the haproxy's core and by the engine itself. Instead, let's set FD_DISOWN on the FD before calling fd_delete() which will take care of not closing it. This patch must be backported on branches >= 2.3, and it relies on this previous patch: MINOR: fd: add a new FD_DISOWN flag to prevent from closing a deleted FD As mentioned in the patch above, a different flag will be needed in 2.3.
2022-07-01 11:36:50 -04:00
for (i=0 ; i < num_all_fds ; i++) {
/* We want to remove the fd from the fdtab
* but we flag it to disown because the
* close is performed by the engine itself
*/
fdtab[all_fd[i]].state |= FD_DISOWN;
fd_delete(all_fd[i]);
}
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
}
#endif
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
SSL_free(ctx->ssl);
BUG/MEDIUM: ssl: Revamp the way early data are handled. Instead of attempting to read the early data only when the upper layer asks for data, allocate a temporary buffer, stored in the ssl_sock_ctx, and put all the early data in there. Requiring that the upper layer takes care of it means that if for some reason the upper layer wants to emit data before it has totally read the early data, we will be stuck forever. This should be backported to 2.1 and 2.0. This may fix github issue #411.
2019-12-19 09:02:39 -05:00
b_free(&ctx->early_buf);
CLEANUP: connection: rename the wait_event.task field to .tasklet It's really confusing to call it a task because it's a tasklet and used in places where tasks and tasklets are used together. Let's rename it to tasklet to remove this confusion.
2019-06-14 08:42:29 -04:00
tasklet_free(ctx->wait_event.tasklet);
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
pool_free(ssl_sock_ctx_pool, ctx);
REORG: ssl-sock: move the sslconns/totalsslconns counters to global These two counters were the only ones not in the global struct, while the SSL freq counters or the req counts are already in it, this forces stats.c to include ssl_sock just to know about them. Let's move them over there with their friends. This reduces from 408 to 384 the number of includes of opensslconf.h.
2021-10-06 06:15:18 -04:00
_HA_ATOMIC_DEC(&global.sslconns);
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
}
}
/* This function tries to perform a clean shutdown on an SSL connection, and in
* any case, flags the connection as reusable if no handshake was in progress.
*/
MEDIUM: connections: Provide a xprt_ctx for each xprt method. For most of the xprt methods, provide a xprt_ctx. This will be useful later when we'll want to be able to stack xprts. The init() method now has to create and provide the said xprt_ctx if needed.
2019-03-21 13:27:17 -04:00
static void ssl_sock_shutw(struct connection *conn, void *xprt_ctx, int clean)
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
{
MEDIUM: connections: Provide a xprt_ctx for each xprt method. For most of the xprt methods, provide a xprt_ctx. This will be useful later when we'll want to be able to stack xprts. The init() method now has to create and provide the said xprt_ctx if needed.
2019-03-21 13:27:17 -04:00
struct ssl_sock_ctx *ctx = xprt_ctx;
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
MEDIUM: connection: use CO_FL_WAIT_XPRT more consistently than L4/L6/HANDSHAKE As mentioned in commit c192b0ab95 ("MEDIUM: connection: remove CO_FL_CONNECTED and only rely on CO_FL_WAIT_*"), there is a lack of consistency on which flags are checked among L4/L6/HANDSHAKE depending on the code areas. A number of sample fetch functions only check for L4L6 to report MAY_CHANGE, some places only check for HANDSHAKE and many check both L4L6 and HANDSHAKE. This patch starts to make all of this more consistent by introducing a new mask CO_FL_WAIT_XPRT which is the union of L4/L6/HANDSHAKE and reports whether the transport layer is ready or not. All inconsistent call places were updated to rely on this one each time the goal was to check for the readiness of the transport layer.
2020-01-23 10:27:54 -05:00
if (conn->flags & (CO_FL_WAIT_XPRT | CO_FL_SSL_WAIT_HS))
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
return;
BUG/MINOR: ssl: assert on SSL_set_shutdown with BoringSSL With BoringSSL: SSL_set_shutdown: Assertion `(SSL_get_shutdown(ssl) & mode) == SSL_get_shutdown(ssl)' failed. "SSL_set_shutdown causes ssl to behave as if the shutdown bitmask (see SSL_get_shutdown) were mode. This may be used to skip sending or receiving close_notify in SSL_shutdown by causing the implementation to believe the events already happened. It is an error to use SSL_set_shutdown to unset a bit that has already been set. Doing so will trigger an assert in debug builds and otherwise be ignored. Use SSL_CTX_set_quiet_shutdown instead." Change logic to not notify on SSL_shutdown when connection is not clean.
2017-01-08 08:07:39 -05:00
if (!clean)
/* don't sent notify on SSL_shutdown */
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
SSL_set_quiet_shutdown(ctx->ssl, 1);
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
/* no handshake was in progress, try a clean ssl shutdown */
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
if (SSL_shutdown(ctx->ssl) <= 0) {
BUG/MEDIUM: ssl: Prevent ssl error from affecting other connections. J. Maurice reported that ssllabs.com test affects unrelated legitimate traffic and cause SSL errors and broken connections. Sometimes openssl store read/write/handshake errors in a global stack. This stack is not specific to the current session. Openssl API does not clean the stack at the beginning of a new read/write. And the function used to retrieve error ID after read/write, returns the generic error SSL_ERROR_SSL if the global stack is not empty. The fix consists in cleaning the errors stack after read/write/handshake errors.
2012-12-14 05:21:13 -05:00
/* Clear openssl global errors stack */
BUG/MINOR: quic: Possible crash when verifying certificates This verification is done by ssl_sock_bind_verifycbk() which is set at different locations in the ssl_sock.c code . About QUIC connections, there are a lot of chances the connection object is not initialized when entering this function. What must be accessed is the SSL object to retrieve the connection or quic_conn objects, then the bind_conf object of the listener. If the connection object is not found, we try to find the quic_conn object. Modify ssl_sock_dump_errors() interface which takes a connection object as parameter to also passed a quic_conn object as parameter. Again this function try first to access the connection object if not NULL or the quic_conn object if not. There is a remaining thing to do for QUIC: store the certificate verification error code as it is currently stored in the connection object. This error code is at least used by the "bc_err" and "fc_err" sample fetches. There are chances this bug is in relation with GH #1851. Thank you to @tasavis for the report. Must be merged into 2.6.
2022-09-06 13:37:08 -04:00
ssl_sock_dump_errors(conn, NULL);
BUG/MEDIUM: ssl: Prevent ssl error from affecting other connections. J. Maurice reported that ssllabs.com test affects unrelated legitimate traffic and cause SSL errors and broken connections. Sometimes openssl store read/write/handshake errors in a global stack. This stack is not specific to the current session. Openssl API does not clean the stack at the beginning of a new read/write. And the function used to retrieve error ID after read/write, returns the generic error SSL_ERROR_SSL if the global stack is not empty. The fix consists in cleaning the errors stack after read/write/handshake errors.
2012-12-14 05:21:13 -05:00
ERR_clear_error();
}
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
}
MINOR: ssl: add ssl_sock_get_pkey_algo function ssl_sock_get_pkey_algo can be used to report pkey algorithm to log and ppv2 (RSA2048, EC256,...). Extract pkey information is not free in ssl api (lock/alloc/free): haproxy can use the pkey information computed in load_certificate. Store and use this information in a SSL ex_data when available, compute it if not (SSL multicert bundled and generated cert).
2017-10-31 10:46:07 -04:00
CLEANUP: assorted typo fixes in the code and comments These are mostly comments in the code. A few error messages were fixed and are of low enough importance not to deserve a backport. Some regtests were also fixed.
2020-03-10 03:06:11 -04:00
/* used for ppv2 pkey algo (can be used for logging) */
MINOR: ssl/cli: 'show ssl cert' give information on the certificates Implement the 'show ssl cert' command on the CLI which list the frontend certificates. With a certificate name in parameter it will show more details.
2019-12-05 04:26:40 -05:00
int ssl_sock_get_pkey_algo(struct connection *conn, struct buffer *out)
{
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
struct ssl_sock_ctx *ctx = conn_get_ssl_sock_ctx(conn);
MINOR: ssl/cli: 'show ssl cert' give information on the certificates Implement the 'show ssl cert' command on the CLI which list the frontend certificates. With a certificate name in parameter it will show more details.
2019-12-05 04:26:40 -05:00
X509 *crt;
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
if (!ctx)
MINOR: ssl/cli: 'show ssl cert' give information on the certificates Implement the 'show ssl cert' command on the CLI which list the frontend certificates. With a certificate name in parameter it will show more details.
2019-12-05 04:26:40 -05:00
return 0;
crt = SSL_get_certificate(ctx->ssl);
if (!crt)
return 0;
return cert_get_pkey_algo(crt, out);
}
MINOR: ssl: add ssl_sock_get_cert_sig function ssl_sock_get_cert_sig can be used to report cert signature short name to log and ppv2 (RSA-SHA256).
2017-11-02 09:05:23 -04:00
/* used for ppv2 cert signature (can be used for logging) */
const char *ssl_sock_get_cert_sig(struct connection *conn)
{
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
struct ssl_sock_ctx *ctx = conn_get_ssl_sock_ctx(conn);
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
MINOR: ssl: add ssl_sock_get_cert_sig function ssl_sock_get_cert_sig can be used to report cert signature short name to log and ppv2 (RSA-SHA256).
2017-11-02 09:05:23 -04:00
__OPENSSL_110_CONST__ ASN1_OBJECT *algorithm;
X509 *crt;
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
if (!ctx)
MINOR: ssl: add ssl_sock_get_cert_sig function ssl_sock_get_cert_sig can be used to report cert signature short name to log and ppv2 (RSA-SHA256).
2017-11-02 09:05:23 -04:00
return NULL;
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
crt = SSL_get_certificate(ctx->ssl);
MINOR: ssl: add ssl_sock_get_cert_sig function ssl_sock_get_cert_sig can be used to report cert signature short name to log and ppv2 (RSA-SHA256).
2017-11-02 09:05:23 -04:00
if (!crt)
return NULL;
X509_ALGOR_get0(&algorithm, NULL, NULL, X509_get0_tbs_sigalg(crt));
return OBJ_nid2sn(OBJ_obj2nid(algorithm));
}
MINOR: connection: add proxy-v2-options authority This patch add option PP2_TYPE_AUTHORITY to proxy protocol v2 when a TLS connection was negotiated. In this case, authority corresponds to the sni.
2018-02-01 12:29:59 -05:00
/* used for ppv2 authority */
const char *ssl_sock_get_sni(struct connection *conn)
{
#ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
struct ssl_sock_ctx *ctx = conn_get_ssl_sock_ctx(conn);
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
if (!ctx)
MINOR: connection: add proxy-v2-options authority This patch add option PP2_TYPE_AUTHORITY to proxy protocol v2 when a TLS connection was negotiated. In this case, authority corresponds to the sni.
2018-02-01 12:29:59 -05:00
return NULL;
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
return SSL_get_servername(ctx->ssl, TLSEXT_NAMETYPE_host_name);
MINOR: connection: add proxy-v2-options authority This patch add option PP2_TYPE_AUTHORITY to proxy protocol v2 when a TLS connection was negotiated. In this case, authority corresponds to the sni.
2018-02-01 12:29:59 -05:00
#else
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
return NULL;
MINOR: connection: add proxy-v2-options authority This patch add option PP2_TYPE_AUTHORITY to proxy protocol v2 when a TLS connection was negotiated. In this case, authority corresponds to the sni.
2018-02-01 12:29:59 -05:00
#endif
}
MINOR: merge ssl_sock_get calls for log and ppv2 Merge ssl_sock_get_version and ssl_sock_get_proto_version. Change ssl_sock_get_cipher to be used in ppv2.
2017-10-13 10:59:49 -04:00
/* used for logging/ppv2, may be changed for a sample fetch later */
MEDIUM: log: report SSL ciphers and version in logs using logformat %sslc/%sslv These two new log-format tags report the SSL protocol version (%sslv) and the SSL ciphers (%sslc) used for the connection with the client. For instance, to append these information just after the client's IP/port address information on an HTTP log line, use the following configuration : log-format %Ci:%Cp\ %sslv:%sslc\ [%t]\ %ft\ %b/%s\ %Tq/%Tw/%Tc/%Tr/%Tt\ %st\ %B\ %cc\ \ %cs\ %tsc\ %ac/%fc/%bc/%sc/%rc\ %sq/%bq\ %hr\ %hs\ %{+Q}r It will report a line such as the following one : Oct 12 20:47:30 haproxy[9643]: 127.0.0.1:43602 TLSv1:AES-SHA [12/Oct/2012:20:47:30.303] stick2~ stick2/s1 7/0/12/0/19 200 145 - - ---- 0/0/0/0/0 0/0 "GET /?t=0 HTTP/1.0"
2012-10-12 14:17:54 -04:00
const char *ssl_sock_get_cipher_name(struct connection *conn)
{
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
struct ssl_sock_ctx *ctx = conn_get_ssl_sock_ctx(conn);
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
if (!ctx)
MEDIUM: log: report SSL ciphers and version in logs using logformat %sslc/%sslv These two new log-format tags report the SSL protocol version (%sslv) and the SSL ciphers (%sslc) used for the connection with the client. For instance, to append these information just after the client's IP/port address information on an HTTP log line, use the following configuration : log-format %Ci:%Cp\ %sslv:%sslc\ [%t]\ %ft\ %b/%s\ %Tq/%Tw/%Tc/%Tr/%Tt\ %st\ %B\ %cc\ \ %cs\ %tsc\ %ac/%fc/%bc/%sc/%rc\ %sq/%bq\ %hr\ %hs\ %{+Q}r It will report a line such as the following one : Oct 12 20:47:30 haproxy[9643]: 127.0.0.1:43602 TLSv1:AES-SHA [12/Oct/2012:20:47:30.303] stick2~ stick2/s1 7/0/12/0/19 200 145 - - ---- 0/0/0/0/0 0/0 "GET /?t=0 HTTP/1.0"
2012-10-12 14:17:54 -04:00
return NULL;
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
return SSL_get_cipher_name(ctx->ssl);
MEDIUM: log: report SSL ciphers and version in logs using logformat %sslc/%sslv These two new log-format tags report the SSL protocol version (%sslv) and the SSL ciphers (%sslc) used for the connection with the client. For instance, to append these information just after the client's IP/port address information on an HTTP log line, use the following configuration : log-format %Ci:%Cp\ %sslv:%sslc\ [%t]\ %ft\ %b/%s\ %Tq/%Tw/%Tc/%Tr/%Tt\ %st\ %B\ %cc\ \ %cs\ %tsc\ %ac/%fc/%bc/%sc/%rc\ %sq/%bq\ %hr\ %hs\ %{+Q}r It will report a line such as the following one : Oct 12 20:47:30 haproxy[9643]: 127.0.0.1:43602 TLSv1:AES-SHA [12/Oct/2012:20:47:30.303] stick2~ stick2/s1 7/0/12/0/19 200 145 - - ---- 0/0/0/0/0 0/0 "GET /?t=0 HTTP/1.0"
2012-10-12 14:17:54 -04:00
}
MINOR: merge ssl_sock_get calls for log and ppv2 Merge ssl_sock_get_version and ssl_sock_get_proto_version. Change ssl_sock_get_cipher to be used in ppv2.
2017-10-13 10:59:49 -04:00
/* used for logging/ppv2, may be changed for a sample fetch later */
MEDIUM: log: report SSL ciphers and version in logs using logformat %sslc/%sslv These two new log-format tags report the SSL protocol version (%sslv) and the SSL ciphers (%sslc) used for the connection with the client. For instance, to append these information just after the client's IP/port address information on an HTTP log line, use the following configuration : log-format %Ci:%Cp\ %sslv:%sslc\ [%t]\ %ft\ %b/%s\ %Tq/%Tw/%Tc/%Tr/%Tt\ %st\ %B\ %cc\ \ %cs\ %tsc\ %ac/%fc/%bc/%sc/%rc\ %sq/%bq\ %hr\ %hs\ %{+Q}r It will report a line such as the following one : Oct 12 20:47:30 haproxy[9643]: 127.0.0.1:43602 TLSv1:AES-SHA [12/Oct/2012:20:47:30.303] stick2~ stick2/s1 7/0/12/0/19 200 145 - - ---- 0/0/0/0/0 0/0 "GET /?t=0 HTTP/1.0"
2012-10-12 14:17:54 -04:00
const char *ssl_sock_get_proto_version(struct connection *conn)
{
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
struct ssl_sock_ctx *ctx = conn_get_ssl_sock_ctx(conn);
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
if (!ctx)
MEDIUM: log: report SSL ciphers and version in logs using logformat %sslc/%sslv These two new log-format tags report the SSL protocol version (%sslv) and the SSL ciphers (%sslc) used for the connection with the client. For instance, to append these information just after the client's IP/port address information on an HTTP log line, use the following configuration : log-format %Ci:%Cp\ %sslv:%sslc\ [%t]\ %ft\ %b/%s\ %Tq/%Tw/%Tc/%Tr/%Tt\ %st\ %B\ %cc\ \ %cs\ %tsc\ %ac/%fc/%bc/%sc/%rc\ %sq/%bq\ %hr\ %hs\ %{+Q}r It will report a line such as the following one : Oct 12 20:47:30 haproxy[9643]: 127.0.0.1:43602 TLSv1:AES-SHA [12/Oct/2012:20:47:30.303] stick2~ stick2/s1 7/0/12/0/19 200 145 - - ---- 0/0/0/0/0 0/0 "GET /?t=0 HTTP/1.0"
2012-10-12 14:17:54 -04:00
return NULL;
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
return SSL_get_version(ctx->ssl);
MEDIUM: log: report SSL ciphers and version in logs using logformat %sslc/%sslv These two new log-format tags report the SSL protocol version (%sslv) and the SSL ciphers (%sslc) used for the connection with the client. For instance, to append these information just after the client's IP/port address information on an HTTP log line, use the following configuration : log-format %Ci:%Cp\ %sslv:%sslc\ [%t]\ %ft\ %b/%s\ %Tq/%Tw/%Tc/%Tr/%Tt\ %st\ %B\ %cc\ \ %cs\ %tsc\ %ac/%fc/%bc/%sc/%rc\ %sq/%bq\ %hr\ %hs\ %{+Q}r It will report a line such as the following one : Oct 12 20:47:30 haproxy[9643]: 127.0.0.1:43602 TLSv1:AES-SHA [12/Oct/2012:20:47:30.303] stick2~ stick2/s1 7/0/12/0/19 200 145 - - ---- 0/0/0/0/0 0/0 "GET /?t=0 HTTP/1.0"
2012-10-12 14:17:54 -04:00
}
MINOR: ssl: Add ssl_sock_set_alpn(). Add a new function, ssl_sock_set_alpn(), to be able to change the ALPN for a connection, instead of relying of the one defined in the SSL_CTX.
2018-12-21 13:45:40 -05:00
void ssl_sock_set_alpn(struct connection *conn, const unsigned char *alpn, int len)
{
#ifdef TLSEXT_TYPE_application_layer_protocol_negotiation
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
struct ssl_sock_ctx *ctx = conn_get_ssl_sock_ctx(conn);
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
if (!ctx)
BUG/MEDIUM: ssl: Don't attempt to set alpn if we're not using SSL. Checks use ssl_sock_set_alpn() to set the ALPN if check-alpn is used, however check-alpn failed to check if the connection was indeed using SSL, and thus, would crash if check-alpn was used on a non-SSL connection. Fix this by making sure the connection uses SSL before attempting to set the ALPN. This should be backported to 2.0 and 1.9.
2019-06-28 08:10:33 -04:00
return;
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
SSL_set_alpn_protos(ctx->ssl, alpn, len);
MINOR: ssl: Add ssl_sock_set_alpn(). Add a new function, ssl_sock_set_alpn(), to be able to change the ALPN for a connection, instead of relying of the one defined in the SSL_CTX.
2018-12-21 13:45:40 -05:00
#endif
}
BUG/MEDIUM: ssl: for a handshake when server-side SNI changes Calling SSL_set_tlsext_host_name() on the current SSL ctx has no effect if the session is being resumed because the hostname is already stored in the session and is not advertised again in subsequent connections. It's visible when enabling SNI and health checks at the same time because checks do not send an SNI and regular traffic reuses the same connection, resulting in no SNI being sent. The only short-term solution is to reset the reused session when the SNI changes compared to the previous one. It can make the server-side performance suffer when SNIs are interleaved but it will work. A better long-term solution would be to keep a small cache of a few contexts for a few SNIs. Now with SSL_set_session(ctx, NULL) it works. This needs to be double- checked though. The man says that SSL_set_session() frees any previously existing context. Some people report a bit of breakage when calling SSL_set_session(NULL) on openssl 1.1.0a (freed session not reusable at all though it's not an issue for now). This needs to be backported to 1.7 and 1.6.
2016-12-22 15:58:38 -05:00
/* Sets advertised SNI for outgoing connections. Please set <hostname> to NULL
* to disable SNI.
*/
MINOR: ssl: provide ia function to set the SNI extension on a connection ssl_sock_set_servername() is used to set the SNI hostname on an outgoing connection. This function comes from code originally provided by Christopher Faulet of Qualys.
2015-07-10 05:33:32 -04:00
void ssl_sock_set_servername(struct connection *conn, const char *hostname)
{
#ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
struct ssl_sock_ctx *ctx = conn_get_ssl_sock_ctx(conn);
BUG/MEDIUM: ssl: for a handshake when server-side SNI changes Calling SSL_set_tlsext_host_name() on the current SSL ctx has no effect if the session is being resumed because the hostname is already stored in the session and is not advertised again in subsequent connections. It's visible when enabling SNI and health checks at the same time because checks do not send an SNI and regular traffic reuses the same connection, resulting in no SNI being sent. The only short-term solution is to reset the reused session when the SNI changes compared to the previous one. It can make the server-side performance suffer when SNIs are interleaved but it will work. A better long-term solution would be to keep a small cache of a few contexts for a few SNIs. Now with SSL_set_session(ctx, NULL) it works. This needs to be double- checked though. The man says that SSL_set_session() frees any previously existing context. Some people report a bit of breakage when calling SSL_set_session(NULL) on openssl 1.1.0a (freed session not reusable at all though it's not an issue for now). This needs to be backported to 1.7 and 1.6.
2016-12-22 15:58:38 -05:00
char *prev_name;
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
if (!ctx)
MINOR: ssl: provide ia function to set the SNI extension on a connection ssl_sock_set_servername() is used to set the SNI hostname on an outgoing connection. This function comes from code originally provided by Christopher Faulet of Qualys.
2015-07-10 05:33:32 -04:00
return;
DEBUG: ssl: make sure we never change a servername on established connections Since this case was already met previously with commit 655dec81b ("BUG/MINOR: backend: do not set sni on connection reuse"), let's make sure that we don't change reused connection settings. This could be generalized to most settings that are only in effect before the handshake in fact (like set_alpn and a few other ones).
2021-12-23 05:12:13 -05:00
BUG_ON(!(conn->flags & CO_FL_WAIT_L6_CONN));
BUG_ON(!(conn->flags & CO_FL_SSL_WAIT_HS));
BUG/MEDIUM: ssl: for a handshake when server-side SNI changes Calling SSL_set_tlsext_host_name() on the current SSL ctx has no effect if the session is being resumed because the hostname is already stored in the session and is not advertised again in subsequent connections. It's visible when enabling SNI and health checks at the same time because checks do not send an SNI and regular traffic reuses the same connection, resulting in no SNI being sent. The only short-term solution is to reset the reused session when the SNI changes compared to the previous one. It can make the server-side performance suffer when SNIs are interleaved but it will work. A better long-term solution would be to keep a small cache of a few contexts for a few SNIs. Now with SSL_set_session(ctx, NULL) it works. This needs to be double- checked though. The man says that SSL_set_session() frees any previously existing context. Some people report a bit of breakage when calling SSL_set_session(NULL) on openssl 1.1.0a (freed session not reusable at all though it's not an issue for now). This needs to be backported to 1.7 and 1.6.
2016-12-22 15:58:38 -05:00
/* if the SNI changes, we must destroy the reusable context so that a
BUG/MEDIUM: ssl: backend TLS resumption with sni and TLSv1.3 When establishing an outboud connection, haproxy checks if the cached TLS session has the same SNI as the connection we are trying to resume. This test was done by calling SSL_get_servername() which in TLSv1.2 returned the SNI. With TLSv1.3 this is not the case anymore and this function returns NULL, which invalidates any outboud connection we are trying to resume if it uses the sni keyword on its server line. This patch fixes the problem by storing the SNI in the "reused_sess" structure beside the session itself. The ssl_sock_set_servername() now has a RWLOCK because this session cache entry could be accessed by the CLI when trying to update a certificate on the backend. This fix must be backported in every maintained version, however the RWLOCK only exists since version 2.4.
2021-11-16 20:59:21 -05:00
* new connection will present a new SNI. compare with the SNI
MEDIUM: ssl_sock: always use the SSL's server name, not the one from the tid In ssl_sock_set_servername(), we're retrieving the current server name from the current thread, hoping it will not have changed. This is a bit dangerous as strictly speaking it's not easy to prove that no other connection had to use one between the moment it was retrieved in ssl_sock_init() and the moment it's being read here. In addition, this forces us to maintain one session per thread while this is not the real need, in practice we only need one session per SNI. And the current model prevents us from sharing sessions between threads. This had been done in 2.5 via commit e18d4e828 ("BUG/MEDIUM: ssl: backend TLS resumption with sni and TLSv1.3"), but as analyzed with William, it turns out that a saner approach consists in keeping the call to SSL_get_servername() there and instead to always assign the SNI to the current SSL context via SSL_set_tlsext_host_name() immediately when the session is retreived. This way the session and SNI are consulted atomically and the host name is only checked from the session and not from possibly changing elements. As a bonus the rdlock that was added by that commit could now be removed, though it didn't cost much.
2023-08-30 06:02:33 -04:00
* previously stored in the reused_sess. If the session was reused,
* the associated SNI (if any) has already been assigned to the SSL
* during ssl_sock_init() so SSL_get_servername() will properly
* retrieve the currently known hostname for the SSL.
*/
BUG/MEDIUM: ssl: backend TLS resumption with sni and TLSv1.3 When establishing an outboud connection, haproxy checks if the cached TLS session has the same SNI as the connection we are trying to resume. This test was done by calling SSL_get_servername() which in TLSv1.2 returned the SNI. With TLSv1.3 this is not the case anymore and this function returns NULL, which invalidates any outboud connection we are trying to resume if it uses the sni keyword on its server line. This patch fixes the problem by storing the SNI in the "reused_sess" structure beside the session itself. The ssl_sock_set_servername() now has a RWLOCK because this session cache entry could be accessed by the CLI when trying to update a certificate on the backend. This fix must be backported in every maintained version, however the RWLOCK only exists since version 2.4.
2021-11-16 20:59:21 -05:00
MEDIUM: ssl_sock: always use the SSL's server name, not the one from the tid In ssl_sock_set_servername(), we're retrieving the current server name from the current thread, hoping it will not have changed. This is a bit dangerous as strictly speaking it's not easy to prove that no other connection had to use one between the moment it was retrieved in ssl_sock_init() and the moment it's being read here. In addition, this forces us to maintain one session per thread while this is not the real need, in practice we only need one session per SNI. And the current model prevents us from sharing sessions between threads. This had been done in 2.5 via commit e18d4e828 ("BUG/MEDIUM: ssl: backend TLS resumption with sni and TLSv1.3"), but as analyzed with William, it turns out that a saner approach consists in keeping the call to SSL_get_servername() there and instead to always assign the SNI to the current SSL context via SSL_set_tlsext_host_name() immediately when the session is retreived. This way the session and SNI are consulted atomically and the host name is only checked from the session and not from possibly changing elements. As a bonus the rdlock that was added by that commit could now be removed, though it didn't cost much.
2023-08-30 06:02:33 -04:00
prev_name = (char *)SSL_get_servername(ctx->ssl, TLSEXT_NAMETYPE_host_name);
BUG/MEDIUM: ssl: for a handshake when server-side SNI changes Calling SSL_set_tlsext_host_name() on the current SSL ctx has no effect if the session is being resumed because the hostname is already stored in the session and is not advertised again in subsequent connections. It's visible when enabling SNI and health checks at the same time because checks do not send an SNI and regular traffic reuses the same connection, resulting in no SNI being sent. The only short-term solution is to reset the reused session when the SNI changes compared to the previous one. It can make the server-side performance suffer when SNIs are interleaved but it will work. A better long-term solution would be to keep a small cache of a few contexts for a few SNIs. Now with SSL_set_session(ctx, NULL) it works. This needs to be double- checked though. The man says that SSL_set_session() frees any previously existing context. Some people report a bit of breakage when calling SSL_set_session(NULL) on openssl 1.1.0a (freed session not reusable at all though it's not an issue for now). This needs to be backported to 1.7 and 1.6.
2016-12-22 15:58:38 -05:00
if ((!prev_name && hostname) ||
MEDIUM: ssl_sock: always use the SSL's server name, not the one from the tid In ssl_sock_set_servername(), we're retrieving the current server name from the current thread, hoping it will not have changed. This is a bit dangerous as strictly speaking it's not easy to prove that no other connection had to use one between the moment it was retrieved in ssl_sock_init() and the moment it's being read here. In addition, this forces us to maintain one session per thread while this is not the real need, in practice we only need one session per SNI. And the current model prevents us from sharing sessions between threads. This had been done in 2.5 via commit e18d4e828 ("BUG/MEDIUM: ssl: backend TLS resumption with sni and TLSv1.3"), but as analyzed with William, it turns out that a saner approach consists in keeping the call to SSL_get_servername() there and instead to always assign the SNI to the current SSL context via SSL_set_tlsext_host_name() immediately when the session is retreived. This way the session and SNI are consulted atomically and the host name is only checked from the session and not from possibly changing elements. As a bonus the rdlock that was added by that commit could now be removed, though it didn't cost much.
2023-08-30 06:02:33 -04:00
!hostname ||
strcmp(hostname, prev_name) != 0) {
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
SSL_set_session(ctx->ssl, NULL);
MEDIUM: ssl_sock: always use the SSL's server name, not the one from the tid In ssl_sock_set_servername(), we're retrieving the current server name from the current thread, hoping it will not have changed. This is a bit dangerous as strictly speaking it's not easy to prove that no other connection had to use one between the moment it was retrieved in ssl_sock_init() and the moment it's being read here. In addition, this forces us to maintain one session per thread while this is not the real need, in practice we only need one session per SNI. And the current model prevents us from sharing sessions between threads. This had been done in 2.5 via commit e18d4e828 ("BUG/MEDIUM: ssl: backend TLS resumption with sni and TLSv1.3"), but as analyzed with William, it turns out that a saner approach consists in keeping the call to SSL_get_servername() there and instead to always assign the SNI to the current SSL context via SSL_set_tlsext_host_name() immediately when the session is retreived. This way the session and SNI are consulted atomically and the host name is only checked from the session and not from possibly changing elements. As a bonus the rdlock that was added by that commit could now be removed, though it didn't cost much.
2023-08-30 06:02:33 -04:00
SSL_set_tlsext_host_name(ctx->ssl, hostname);
}
MINOR: ssl: provide ia function to set the SNI extension on a connection ssl_sock_set_servername() is used to set the SNI hostname on an outgoing connection. This function comes from code originally provided by Christopher Faulet of Qualys.
2015-07-10 05:33:32 -04:00
#endif
}
BUG/MINOR: ssl: Fix external function in order not to return a pointer on an internal trash buffer. 'ssl_sock_get_common_name' applied to a connection was also renamed 'ssl_sock_get_remote_common_name'. Currently, this function is only used with protocol PROXYv2 to retrieve the client certificate's common name. A further usage could be to retrieve the server certificate's common name on an outgoing connection.
2014-06-24 12:26:41 -04:00
/* Extract peer certificate's common name into the chunk dest
* Returns
* the len of the extracted common name
* or 0 if no CN found in DN
* or -1 on error case (i.e. no peer certificate)
*/
MAJOR: chunks: replace struct chunk with struct buffer Now all the code used to manipulate chunks uses a struct buffer instead. The functions are still called "chunk*", and some of them will progressively move to the generic buffer handling code as they are cleaned up.
2018-07-13 05:56:34 -04:00
int ssl_sock_get_remote_common_name(struct connection *conn,
struct buffer *dest)
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
{
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
struct ssl_sock_ctx *ctx = conn_get_ssl_sock_ctx(conn);
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
X509 *crt = NULL;
X509_NAME *name;
const char find_cn[] = "CN";
MAJOR: chunks: replace struct chunk with struct buffer Now all the code used to manipulate chunks uses a struct buffer instead. The functions are still called "chunk*", and some of them will progressively move to the generic buffer handling code as they are cleaned up.
2018-07-13 05:56:34 -04:00
const struct buffer find_cn_chunk = {
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
.area = (char *)&find_cn,
.data = sizeof(find_cn)-1
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
};
BUG/MINOR: ssl: Fix external function in order not to return a pointer on an internal trash buffer. 'ssl_sock_get_common_name' applied to a connection was also renamed 'ssl_sock_get_remote_common_name'. Currently, this function is only used with protocol PROXYv2 to retrieve the client certificate's common name. A further usage could be to retrieve the server certificate's common name on an outgoing connection.
2014-06-24 12:26:41 -04:00
int result = -1;
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
if (!ctx)
BUG/MINOR: ssl: Fix external function in order not to return a pointer on an internal trash buffer. 'ssl_sock_get_common_name' applied to a connection was also renamed 'ssl_sock_get_remote_common_name'. Currently, this function is only used with protocol PROXYv2 to retrieve the client certificate's common name. A further usage could be to retrieve the server certificate's common name on an outgoing connection.
2014-06-24 12:26:41 -04:00
goto out;
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
/* SSL_get_peer_certificate, it increase X509 * ref count */
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
crt = SSL_get_peer_certificate(ctx->ssl);
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
if (!crt)
goto out;
name = X509_get_subject_name(crt);
if (!name)
goto out;
BUG/MINOR: ssl: Fix external function in order not to return a pointer on an internal trash buffer. 'ssl_sock_get_common_name' applied to a connection was also renamed 'ssl_sock_get_remote_common_name'. Currently, this function is only used with protocol PROXYv2 to retrieve the client certificate's common name. A further usage could be to retrieve the server certificate's common name on an outgoing connection.
2014-06-24 12:26:41 -04:00
result = ssl_sock_get_dn_entry(name, &find_cn_chunk, 1, dest);
out:
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
if (crt)
X509_free(crt);
return result;
}
MEDIUM: connection: add new bit in Proxy Protocol V2 There are two sample commands to get information about the presence of a client certificate. ssl_fc_has_crt is true if there is a certificate present in the current connection ssl_c_used is true if there is a certificate present in the session. If a session has stopped and resumed, then ssl_c_used could be true, while ssl_fc_has_crt is false. In the client byte of the TLS TLV of Proxy Protocol V2, there is only one bit to indicate whether a certificate is present on the connection. The attached patch adds a second bit to indicate the presence for the session. This maintains backward compatibility. [wt: this should be backported to 1.5 to help maintain compatibility between versions]
2014-07-30 10:39:13 -04:00
/* returns 1 if client passed a certificate for this session, 0 if not */
int ssl_sock_get_cert_used_sess(struct connection *conn)
{
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
struct ssl_sock_ctx *ctx = conn_get_ssl_sock_ctx(conn);
MEDIUM: connection: add new bit in Proxy Protocol V2 There are two sample commands to get information about the presence of a client certificate. ssl_fc_has_crt is true if there is a certificate present in the current connection ssl_c_used is true if there is a certificate present in the session. If a session has stopped and resumed, then ssl_c_used could be true, while ssl_fc_has_crt is false. In the client byte of the TLS TLV of Proxy Protocol V2, there is only one bit to indicate whether a certificate is present on the connection. The attached patch adds a second bit to indicate the presence for the session. This maintains backward compatibility. [wt: this should be backported to 1.5 to help maintain compatibility between versions]
2014-07-30 10:39:13 -04:00
X509 *crt = NULL;
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
if (!ctx)
MEDIUM: connection: add new bit in Proxy Protocol V2 There are two sample commands to get information about the presence of a client certificate. ssl_fc_has_crt is true if there is a certificate present in the current connection ssl_c_used is true if there is a certificate present in the session. If a session has stopped and resumed, then ssl_c_used could be true, while ssl_fc_has_crt is false. In the client byte of the TLS TLV of Proxy Protocol V2, there is only one bit to indicate whether a certificate is present on the connection. The attached patch adds a second bit to indicate the presence for the session. This maintains backward compatibility. [wt: this should be backported to 1.5 to help maintain compatibility between versions]
2014-07-30 10:39:13 -04:00
return 0;
/* SSL_get_peer_certificate, it increase X509 * ref count */
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
crt = SSL_get_peer_certificate(ctx->ssl);
MEDIUM: connection: add new bit in Proxy Protocol V2 There are two sample commands to get information about the presence of a client certificate. ssl_fc_has_crt is true if there is a certificate present in the current connection ssl_c_used is true if there is a certificate present in the session. If a session has stopped and resumed, then ssl_c_used could be true, while ssl_fc_has_crt is false. In the client byte of the TLS TLV of Proxy Protocol V2, there is only one bit to indicate whether a certificate is present on the connection. The attached patch adds a second bit to indicate the presence for the session. This maintains backward compatibility. [wt: this should be backported to 1.5 to help maintain compatibility between versions]
2014-07-30 10:39:13 -04:00
if (!crt)
return 0;
X509_free(crt);
return 1;
}
/* returns 1 if client passed a certificate for this connection, 0 if not */
int ssl_sock_get_cert_used_conn(struct connection *conn)
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
{
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
struct ssl_sock_ctx *ctx = conn_get_ssl_sock_ctx(conn);
MEDIUM: connections: Move some fields from struct connection to ssl_sock_ctx. Move xprt_st, tmp_early_data and sent_early_data from struct connection to struct ssl_sock_ctx, as they are only used in the SSL code.
2019-02-28 12:10:45 -05:00
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
if (!ctx)
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
return 0;
MEDIUM: connections: Move some fields from struct connection to ssl_sock_ctx. Move xprt_st, tmp_early_data and sent_early_data from struct connection to struct ssl_sock_ctx, as they are only used in the SSL code.
2019-02-28 12:10:45 -05:00
return SSL_SOCK_ST_FL_VERIFY_DONE & ctx->xprt_st ? 1 : 0;
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
}
/* returns result from SSL verify */
unsigned int ssl_sock_get_verify_result(struct connection *conn)
{
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
struct ssl_sock_ctx *ctx = conn_get_ssl_sock_ctx(conn);
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
MEDIUM: ssl: stop using conn->xprt_ctx to access the ssl_sock_ctx The SSL functions must not use conn->xprt_ctx anymore but find the context by calling conn_get_ssl_sock_ctx(), which will properly pass through the transport layers to retrieve the desired information. Otherwise when the functions are called on a QUIC connection, they refuse to work for not being called on the proper transport.
2022-04-11 05:29:11 -04:00
if (!ctx)
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
return (unsigned int)X509_V_ERR_APPLICATION_VERIFICATION;
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
return (unsigned int)SSL_get_verify_result(ctx->ssl);
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
}
MINOR: ssl: add a get_alpn() method to ssl_sock This is used to retrieve the TLS ALPN information from a connection. We also support a fallback to NPN if ALPN doesn't find anything or is not available on the existing implementation. It happens that depending on the library version, either one or the other is available. NPN was present in openssl 1.0.1 (very common) while ALPN is in 1.0.2 and onwards (still uncommon at the time of writing). Clients are used to send either one or the other to ensure a smooth transition.
2016-12-04 12:44:29 -05:00
/* Returns the application layer protocol name in <str> and <len> when known.
* Zero is returned if the protocol name was not found, otherwise non-zero is
* returned. The string is allocated in the SSL context and doesn't have to be
* freed by the caller. NPN is also checked if available since older versions
* of openssl (1.0.1) which are more common in field only support this one.
*/
MEDIUM: quic: inspect ALPN to install app_ops Remove the hardcoded initialization of h3 layer on mux init. Now the ALPN is looked just after the SSL handshake. The app layer is then installed if the ALPN negotiation returned a supported protocol. This required to add a get_alpn on the ssl_quic layer which is just a call to ssl_sock_get_alpn() from ssl_sock. This is mandatory to be able to use conn_get_alpn().
2021-11-12 05:23:29 -05:00
int ssl_sock_get_alpn(const struct connection *conn, void *xprt_ctx, const char **str, int *len)
MINOR: ssl: add a get_alpn() method to ssl_sock This is used to retrieve the TLS ALPN information from a connection. We also support a fallback to NPN if ALPN doesn't find anything or is not available on the existing implementation. It happens that depending on the library version, either one or the other is available. NPN was present in openssl 1.0.1 (very common) while ALPN is in 1.0.2 and onwards (still uncommon at the time of writing). Clients are used to send either one or the other to ensure a smooth transition.
2016-12-04 12:44:29 -05:00
{
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
#if defined(TLSEXT_TYPE_application_layer_protocol_negotiation) || \
defined(OPENSSL_NPN_NEGOTIATED) && !defined(OPENSSL_NO_NEXTPROTONEG)
MEDIUM: connections: Provide a xprt_ctx for each xprt method. For most of the xprt methods, provide a xprt_ctx. This will be useful later when we'll want to be able to stack xprts. The init() method now has to create and provide the said xprt_ctx if needed.
2019-03-21 13:27:17 -04:00
struct ssl_sock_ctx *ctx = xprt_ctx;
if (!ctx)
MINOR: ssl: add a get_alpn() method to ssl_sock This is used to retrieve the TLS ALPN information from a connection. We also support a fallback to NPN if ALPN doesn't find anything or is not available on the existing implementation. It happens that depending on the library version, either one or the other is available. NPN was present in openssl 1.0.1 (very common) while ALPN is in 1.0.2 and onwards (still uncommon at the time of writing). Clients are used to send either one or the other to ensure a smooth transition.
2016-12-04 12:44:29 -05:00
return 0;
*str = NULL;
#ifdef TLSEXT_TYPE_application_layer_protocol_negotiation
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
SSL_get0_alpn_selected(ctx->ssl, (const unsigned char **)str, (unsigned *)len);
MINOR: ssl: add a get_alpn() method to ssl_sock This is used to retrieve the TLS ALPN information from a connection. We also support a fallback to NPN if ALPN doesn't find anything or is not available on the existing implementation. It happens that depending on the library version, either one or the other is available. NPN was present in openssl 1.0.1 (very common) while ALPN is in 1.0.2 and onwards (still uncommon at the time of writing). Clients are used to send either one or the other to ensure a smooth transition.
2016-12-04 12:44:29 -05:00
if (*str)
return 1;
#endif
BUILD: ssl: Fix build with OpenSSL without NPN capability OpenSSL can be built without NEXTPROTONEG support by passing -no-npn to the configure script. This sets the OPENSSL_NO_NEXTPROTONEG flag in opensslconf.h Since NEXTPROTONEG is now considered deprecated, it is superseeded by ALPN (Application Layer Protocol Next), HAProxy should allow building withough NPN support.
2018-02-15 07:34:58 -05:00
#if defined(OPENSSL_NPN_NEGOTIATED) && !defined(OPENSSL_NO_NEXTPROTONEG)
MEDIUM: ssl: Give ssl_sock its own context. Instead of using directly a SSL * as xprt_ctx, give ssl_sock its own context. It's useless for now, but will be useful later when we'll want to be able to stack xprts.
2019-02-26 12:37:15 -05:00
SSL_get0_next_proto_negotiated(ctx->ssl, (const unsigned char **)str, (unsigned *)len);
MINOR: ssl: add a get_alpn() method to ssl_sock This is used to retrieve the TLS ALPN information from a connection. We also support a fallback to NPN if ALPN doesn't find anything or is not available on the existing implementation. It happens that depending on the library version, either one or the other is available. NPN was present in openssl 1.0.1 (very common) while ALPN is in 1.0.2 and onwards (still uncommon at the time of writing). Clients are used to send either one or the other to ensure a smooth transition.
2016-12-04 12:44:29 -05:00
if (*str)
return 1;
#endif
MEDIUM: connections: Provide a xprt_ctx for each xprt method. For most of the xprt methods, provide a xprt_ctx. This will be useful later when we'll want to be able to stack xprts. The init() method now has to create and provide the said xprt_ctx if needed.
2019-03-21 13:27:17 -04:00
#endif
MINOR: ssl: add a get_alpn() method to ssl_sock This is used to retrieve the TLS ALPN information from a connection. We also support a fallback to NPN if ALPN doesn't find anything or is not available on the existing implementation. It happens that depending on the library version, either one or the other is available. NPN was present in openssl 1.0.1 (very common) while ALPN is in 1.0.2 and onwards (still uncommon at the time of writing). Clients are used to send either one or the other to ensure a smooth transition.
2016-12-04 12:44:29 -05:00
return 0;
}
MINOR: ssl: add "issuers-chain-path" directive. Certificates loaded with "crt" and "crt-list" commonly share the same intermediate certificate in PEM file. "issuers-chain-path" is a global directive to share intermediate chain certificates in a directory. If certificates chain is not included in certificate PEM file, haproxy will complete chain if issuer match the first certificate of the chain stored via "issuers-chain-path" directive. Such chains will be shared in memory.
2019-01-04 05:08:20 -05:00
/* "issuers-chain-path" load chain certificate in global */
REORG: ssl: move ssl configuration to cfgparse-ssl.c Move all the configuration parsing of the ssl keywords in cfgparse-ssl.c
2020-05-14 11:47:32 -04:00
int ssl_load_global_issuer_from_BIO(BIO *in, char *fp, char **err)
MINOR: ssl: add "issuers-chain-path" directive. Certificates loaded with "crt" and "crt-list" commonly share the same intermediate certificate in PEM file. "issuers-chain-path" is a global directive to share intermediate chain certificates in a directory. If certificates chain is not included in certificate PEM file, haproxy will complete chain if issuer match the first certificate of the chain stored via "issuers-chain-path" directive. Such chains will be shared in memory.
2019-01-04 05:08:20 -05:00
{
X509 *ca;
X509_NAME *name = NULL;
ASN1_OCTET_STRING *skid = NULL;
STACK_OF(X509) *chain = NULL;
struct issuer_chain *issuer;
struct eb64_node *node;
char *path;
u64 key;
int ret = 0;
while ((ca = PEM_read_bio_X509(in, NULL, NULL, NULL))) {
if (chain == NULL) {
chain = sk_X509_new_null();
skid = X509_get_ext_d2i(ca, NID_subject_key_identifier, NULL, NULL);
name = X509_get_subject_name(ca);
}
if (!sk_X509_push(chain, ca)) {
X509_free(ca);
goto end;
}
}
if (!chain) {
memprintf(err, "unable to load issuers-chain %s : pem certificate not found.\n", fp);
goto end;
}
if (!skid) {
memprintf(err, "unable to load issuers-chain %s : SubjectKeyIdentifier not found.\n", fp);
goto end;
}
if (!name) {
memprintf(err, "unable to load issuers-chain %s : SubjectName not found.\n", fp);
goto end;
}
MEDIUM: xxhash: use the XXH3 functions to generate 64-bit hashes Replace the XXH64() function calls with the XXH3 variant function XXH3_64bits_withSeed() where possible.
2020-12-22 07:22:34 -05:00
key = XXH3(ASN1_STRING_get0_data(skid), ASN1_STRING_length(skid), 0);
CLEANUP: ssl: move issuer_chain tree and definition Move the cert_issuer_tree outside the global_ssl structure since it's not a configuration variable. And move the declaration of the issuer_chain structure in types/ssl_sock.h
2020-02-25 08:53:06 -05:00
for (node = eb64_lookup(&cert_issuer_tree, key); node; node = eb64_next(node)) {
MINOR: ssl: add "issuers-chain-path" directive. Certificates loaded with "crt" and "crt-list" commonly share the same intermediate certificate in PEM file. "issuers-chain-path" is a global directive to share intermediate chain certificates in a directory. If certificates chain is not included in certificate PEM file, haproxy will complete chain if issuer match the first certificate of the chain stored via "issuers-chain-path" directive. Such chains will be shared in memory.
2019-01-04 05:08:20 -05:00
issuer = container_of(node, typeof(*issuer), node);
if (!X509_NAME_cmp(name, X509_get_subject_name(sk_X509_value(issuer->chain, 0)))) {
memprintf(err, "duplicate issuers-chain %s: %s already in store\n", fp, issuer->path);
goto end;
}
}
issuer = calloc(1, sizeof *issuer);
path = strdup(fp);
if (!issuer || !path) {
free(issuer);
free(path);
goto end;
}
issuer->node.key = key;
issuer->path = path;
issuer->chain = chain;
chain = NULL;
CLEANUP: ssl: move issuer_chain tree and definition Move the cert_issuer_tree outside the global_ssl structure since it's not a configuration variable. And move the declaration of the issuer_chain structure in types/ssl_sock.h
2020-02-25 08:53:06 -05:00
eb64_insert(&cert_issuer_tree, &issuer->node);
MINOR: ssl: add "issuers-chain-path" directive. Certificates loaded with "crt" and "crt-list" commonly share the same intermediate certificate in PEM file. "issuers-chain-path" is a global directive to share intermediate chain certificates in a directory. If certificates chain is not included in certificate PEM file, haproxy will complete chain if issuer match the first certificate of the chain stored via "issuers-chain-path" directive. Such chains will be shared in memory.
2019-01-04 05:08:20 -05:00
ret = 1;
end:
if (skid)
ASN1_OCTET_STRING_free(skid);
if (chain)
sk_X509_pop_free(chain, X509_free);
return ret;
}
REORG: ssl: move the CLI 'cert' functions to src/ssl_ckch.c Move the 'ssl cert' CLI functions to src/ssl_ckch.c.
2020-05-14 04:14:37 -04:00
struct issuer_chain* ssl_get0_issuer_chain(X509 *cert)
MINOR: ssl: move find certificate chain code to its own function New function ssl_get_issuer_chain(cert) to find an issuer_chain entry from "issers-chain-path" tree.
2020-02-18 09:19:24 -05:00
{
AUTHORITY_KEYID *akid;
struct issuer_chain *issuer = NULL;
akid = X509_get_ext_d2i(cert, NID_authority_key_identifier, NULL, NULL);
BUG/MINOR: ssl: segv on startup when AKID but no keyid In bug #959 it was reported that haproxy segfault on startup when trying to load a certifcate which use the X509v3 AKID extension but without the keyid field. This field is not mandatory and could be replaced by the serial or the DirName. For example: X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Subject Key Identifier: 42:7D:5F:6C:3E:0D:B7:2C:FD:6A:8A:32:C6:C6:B9:90:05:D1:B2:9B X509v3 Authority Key Identifier: DirName:/O=HAProxy Technologies/CN=HAProxy Test Intermediate CA serial:F2:AB:C1:41:9F:AB:45:8E:86:23:AD:C5:54:ED:DF:FA This bug was introduced by 70df7b ("MINOR: ssl: add "issuers-chain-path" directive"). This patch must be backported as far as 2.2.
2020-11-19 10:24:13 -05:00
if (akid && akid->keyid) {
MINOR: ssl: move find certificate chain code to its own function New function ssl_get_issuer_chain(cert) to find an issuer_chain entry from "issers-chain-path" tree.
2020-02-18 09:19:24 -05:00
struct eb64_node *node;
u64 hk;
MEDIUM: xxhash: use the XXH3 functions to generate 64-bit hashes Replace the XXH64() function calls with the XXH3 variant function XXH3_64bits_withSeed() where possible.
2020-12-22 07:22:34 -05:00
hk = XXH3(ASN1_STRING_get0_data(akid->keyid), ASN1_STRING_length(akid->keyid), 0);
MINOR: ssl: move find certificate chain code to its own function New function ssl_get_issuer_chain(cert) to find an issuer_chain entry from "issers-chain-path" tree.
2020-02-18 09:19:24 -05:00
for (node = eb64_lookup(&cert_issuer_tree, hk); node; node = eb64_next(node)) {
struct issuer_chain *ti = container_of(node, typeof(*issuer), node);
if (X509_check_issued(sk_X509_value(ti->chain, 0), cert) == X509_V_OK) {
issuer = ti;
break;
}
}
}
BUG/MINOR: ssl: Memory leak of AUTHORITY_KEYID struct when loading issuer When calling ssl_get0_issuer_chain, if akid is not NULL but its keyid is, then the AUTHORITY_KEYID is not freed. This patch can be backported to all stable branches.
2022-11-03 10:16:48 -04:00
AUTHORITY_KEYID_free(akid);
MINOR: ssl: move find certificate chain code to its own function New function ssl_get_issuer_chain(cert) to find an issuer_chain entry from "issers-chain-path" tree.
2020-02-18 09:19:24 -05:00
return issuer;
}
REORG: ssl: move ssl configuration to cfgparse-ssl.c Move all the configuration parsing of the ssl keywords in cfgparse-ssl.c
2020-05-14 11:47:32 -04:00
void ssl_free_global_issuers(void)
MINOR: ssl: add "issuers-chain-path" directive. Certificates loaded with "crt" and "crt-list" commonly share the same intermediate certificate in PEM file. "issuers-chain-path" is a global directive to share intermediate chain certificates in a directory. If certificates chain is not included in certificate PEM file, haproxy will complete chain if issuer match the first certificate of the chain stored via "issuers-chain-path" directive. Such chains will be shared in memory.
2019-01-04 05:08:20 -05:00
{
struct eb64_node *node, *back;
struct issuer_chain *issuer;
CLEANUP: ssl: move issuer_chain tree and definition Move the cert_issuer_tree outside the global_ssl structure since it's not a configuration variable. And move the declaration of the issuer_chain structure in types/ssl_sock.h
2020-02-25 08:53:06 -05:00
node = eb64_first(&cert_issuer_tree);
MINOR: ssl: add "issuers-chain-path" directive. Certificates loaded with "crt" and "crt-list" commonly share the same intermediate certificate in PEM file. "issuers-chain-path" is a global directive to share intermediate chain certificates in a directory. If certificates chain is not included in certificate PEM file, haproxy will complete chain if issuer match the first certificate of the chain stored via "issuers-chain-path" directive. Such chains will be shared in memory.
2019-01-04 05:08:20 -05:00
while (node) {
issuer = container_of(node, typeof(*issuer), node);
back = eb64_next(node);
eb64_delete(node);
free(issuer->path);
sk_X509_pop_free(issuer->chain, X509_free);
free(issuer);
node = back;
}
}
BUILD: ssl: add USE_ENGINE and disable the openssl engine by default The OpenSSL engine API is deprecated starting with OpenSSL 3.0. In order to have a clean build this feature is now disabled by default. It can be reactivated with USE_ENGINE=1 on the build line.
2022-04-11 12:41:24 -04:00
#if defined(USE_ENGINE) && !defined(OPENSSL_NO_ENGINE)
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
static int ssl_check_async_engine_count(void) {
CLEANUP: config: Return ERR_NONE from config callbacks instead of 0 Return ERR_NONE instead of 0 on success for all config callbacks that should return ERR_* codes. There is no change because ERR_NONE is a macro equals to 0. But this makes the return value more explicit.
2020-11-06 09:24:23 -05:00
int err_code = ERR_NONE;
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
MEDIUM: ssl: handle multiple async engines This patch adds the support of a maximum of 32 engines in async mode. Some tests have been done using 2 engines simultaneously. This patch also removes specific 'async' attribute from the connection structure. All the code relies only on Openssl functions.
2017-05-17 14:42:48 -04:00
if (global_ssl.async && (openssl_engines_initialized > 32)) {
CLEANUP: log: Rename Alert/Warning in ha_alert/ha_warning
2017-11-24 10:50:31 -05:00
ha_alert("ssl-mode-async only supports a maximum of 32 engines.\n");
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
err_code = ERR_ABORT;
}
return err_code;
}
MEDIUM: cfgparse: move all tune.ssl.* keywords to ssl_sock The following keywords were still parsed in cfgparse and were moved to ssl_sock to remove some #ifdefs : "tune.ssl.cachesize", "tune.ssl.default-dh-param", "tune.ssl.force-private-cache", "tune.ssl.lifetime", "tune.ssl.maxrecord", "tune.ssl.ssl-ctx-cache-size". It's worth mentionning that some of them used to have incorrect sign checks possibly resulting in some negative values being used. All of them are now checked for being positive.
2016-12-21 17:13:03 -05:00
#endif
MINOR: ssl: provide a "show fd" helper to report important SSL information The SSL context contains a lot of important details that are currently missing from debug outputs. Now that we detect ssl_sock, we can perform some sanity checks, print the next xprt, the subscriber callback's context, handler and number of calls. The process function is also resolved. This now gives for example on an H2 connection: 1029 : st=0x21(R:rA W:Ra) ev=0x01(heopI) [lc] tmask=0x2 umask=0x2 owner=0x7fc714881700 iocb=0x65b528(sock_conn_iocb) back=0 cflg=0x00001300 fe=recv mux=H2 ctx=0x7fc734545e50 h2c.st0=FRH .err=0 .maxid=217 .lastid=-1 .flg=0x0000 .nbst=0 .nbcs=0 .fctl_cnt=0 .send_cnt=0 .tree_cnt=0 .orph_cnt=0 .sub=1 .dsi=217 .dbuf=0@(nil)+0/0 .msi=-1 .mbuf=[1..1|32],h=[0@(nil)+0/0],t=[0@(nil)+0/0] xprt=SSL xprt_ctx=0x7fc73478f230 xctx.st=0 .xprt=RAW .wait.ev=1 .subs=0x7fc734546350(ev=1 tl=0x7fc7346702e0 tl.calls=278 tl.ctx=0x7fc734545e50 tl.fct=main-0x144efa) .sent_early=0 .early_in=0
2021-01-20 08:41:29 -05:00
/* "show fd" helper to dump ssl internals. Warning: the output buffer is often
MINOR: ssl/show_fd: report some FDs as suspicious when possible If a subscriber's tasklet was called more than one million times, if the ssl_ctx's connection doesn't match the current one, or if the connection appears closed in one direction while the SSL stack is still subscribed, the FD is reported as suspicious. The close cases may occasionally trigger a false positive during very short and rare windows. Similarly the 1M calls will trigger after 16GB are transferred over a given connection. These are rare enough events to be reported as suspicious.
2021-01-21 02:53:50 -05:00
* the common trash! It returns non-zero if the connection entry looks suspicious.
MINOR: ssl: provide a "show fd" helper to report important SSL information The SSL context contains a lot of important details that are currently missing from debug outputs. Now that we detect ssl_sock, we can perform some sanity checks, print the next xprt, the subscriber callback's context, handler and number of calls. The process function is also resolved. This now gives for example on an H2 connection: 1029 : st=0x21(R:rA W:Ra) ev=0x01(heopI) [lc] tmask=0x2 umask=0x2 owner=0x7fc714881700 iocb=0x65b528(sock_conn_iocb) back=0 cflg=0x00001300 fe=recv mux=H2 ctx=0x7fc734545e50 h2c.st0=FRH .err=0 .maxid=217 .lastid=-1 .flg=0x0000 .nbst=0 .nbcs=0 .fctl_cnt=0 .send_cnt=0 .tree_cnt=0 .orph_cnt=0 .sub=1 .dsi=217 .dbuf=0@(nil)+0/0 .msi=-1 .mbuf=[1..1|32],h=[0@(nil)+0/0],t=[0@(nil)+0/0] xprt=SSL xprt_ctx=0x7fc73478f230 xctx.st=0 .xprt=RAW .wait.ev=1 .subs=0x7fc734546350(ev=1 tl=0x7fc7346702e0 tl.calls=278 tl.ctx=0x7fc734545e50 tl.fct=main-0x144efa) .sent_early=0 .early_in=0
2021-01-20 08:41:29 -05:00
*/
MINOR: cli: give the show_fd helpers the ability to report a suspicious entry Now the show_fd helpers at the transport and mux levels return an integer which indicates whether or not the inspected entry looks suspicious. When an entry is reported as suspicious, "show fd" will suffix it with an exclamation mark ('!') in the dump, that is supposed to help detecting them. For now, helpers were adjusted to adapt to the new API but none of them reports any suspicious entry yet.
2021-01-21 02:26:06 -05:00
static int ssl_sock_show_fd(struct buffer *buf, const struct connection *conn, const void *ctx)
MINOR: ssl: provide a "show fd" helper to report important SSL information The SSL context contains a lot of important details that are currently missing from debug outputs. Now that we detect ssl_sock, we can perform some sanity checks, print the next xprt, the subscriber callback's context, handler and number of calls. The process function is also resolved. This now gives for example on an H2 connection: 1029 : st=0x21(R:rA W:Ra) ev=0x01(heopI) [lc] tmask=0x2 umask=0x2 owner=0x7fc714881700 iocb=0x65b528(sock_conn_iocb) back=0 cflg=0x00001300 fe=recv mux=H2 ctx=0x7fc734545e50 h2c.st0=FRH .err=0 .maxid=217 .lastid=-1 .flg=0x0000 .nbst=0 .nbcs=0 .fctl_cnt=0 .send_cnt=0 .tree_cnt=0 .orph_cnt=0 .sub=1 .dsi=217 .dbuf=0@(nil)+0/0 .msi=-1 .mbuf=[1..1|32],h=[0@(nil)+0/0],t=[0@(nil)+0/0] xprt=SSL xprt_ctx=0x7fc73478f230 xctx.st=0 .xprt=RAW .wait.ev=1 .subs=0x7fc734546350(ev=1 tl=0x7fc7346702e0 tl.calls=278 tl.ctx=0x7fc734545e50 tl.fct=main-0x144efa) .sent_early=0 .early_in=0
2021-01-20 08:41:29 -05:00
{
const struct ssl_sock_ctx *sctx = ctx;
MINOR: ssl/show_fd: report some FDs as suspicious when possible If a subscriber's tasklet was called more than one million times, if the ssl_ctx's connection doesn't match the current one, or if the connection appears closed in one direction while the SSL stack is still subscribed, the FD is reported as suspicious. The close cases may occasionally trigger a false positive during very short and rare windows. Similarly the 1M calls will trigger after 16GB are transferred over a given connection. These are rare enough events to be reported as suspicious.
2021-01-21 02:53:50 -05:00
int ret = 0;
MINOR: ssl: provide a "show fd" helper to report important SSL information The SSL context contains a lot of important details that are currently missing from debug outputs. Now that we detect ssl_sock, we can perform some sanity checks, print the next xprt, the subscriber callback's context, handler and number of calls. The process function is also resolved. This now gives for example on an H2 connection: 1029 : st=0x21(R:rA W:Ra) ev=0x01(heopI) [lc] tmask=0x2 umask=0x2 owner=0x7fc714881700 iocb=0x65b528(sock_conn_iocb) back=0 cflg=0x00001300 fe=recv mux=H2 ctx=0x7fc734545e50 h2c.st0=FRH .err=0 .maxid=217 .lastid=-1 .flg=0x0000 .nbst=0 .nbcs=0 .fctl_cnt=0 .send_cnt=0 .tree_cnt=0 .orph_cnt=0 .sub=1 .dsi=217 .dbuf=0@(nil)+0/0 .msi=-1 .mbuf=[1..1|32],h=[0@(nil)+0/0],t=[0@(nil)+0/0] xprt=SSL xprt_ctx=0x7fc73478f230 xctx.st=0 .xprt=RAW .wait.ev=1 .subs=0x7fc734546350(ev=1 tl=0x7fc7346702e0 tl.calls=278 tl.ctx=0x7fc734545e50 tl.fct=main-0x144efa) .sent_early=0 .early_in=0
2021-01-20 08:41:29 -05:00
if (!sctx)
MINOR: ssl/show_fd: report some FDs as suspicious when possible If a subscriber's tasklet was called more than one million times, if the ssl_ctx's connection doesn't match the current one, or if the connection appears closed in one direction while the SSL stack is still subscribed, the FD is reported as suspicious. The close cases may occasionally trigger a false positive during very short and rare windows. Similarly the 1M calls will trigger after 16GB are transferred over a given connection. These are rare enough events to be reported as suspicious.
2021-01-21 02:53:50 -05:00
return ret;
MINOR: ssl: provide a "show fd" helper to report important SSL information The SSL context contains a lot of important details that are currently missing from debug outputs. Now that we detect ssl_sock, we can perform some sanity checks, print the next xprt, the subscriber callback's context, handler and number of calls. The process function is also resolved. This now gives for example on an H2 connection: 1029 : st=0x21(R:rA W:Ra) ev=0x01(heopI) [lc] tmask=0x2 umask=0x2 owner=0x7fc714881700 iocb=0x65b528(sock_conn_iocb) back=0 cflg=0x00001300 fe=recv mux=H2 ctx=0x7fc734545e50 h2c.st0=FRH .err=0 .maxid=217 .lastid=-1 .flg=0x0000 .nbst=0 .nbcs=0 .fctl_cnt=0 .send_cnt=0 .tree_cnt=0 .orph_cnt=0 .sub=1 .dsi=217 .dbuf=0@(nil)+0/0 .msi=-1 .mbuf=[1..1|32],h=[0@(nil)+0/0],t=[0@(nil)+0/0] xprt=SSL xprt_ctx=0x7fc73478f230 xctx.st=0 .xprt=RAW .wait.ev=1 .subs=0x7fc734546350(ev=1 tl=0x7fc7346702e0 tl.calls=278 tl.ctx=0x7fc734545e50 tl.fct=main-0x144efa) .sent_early=0 .early_in=0
2021-01-20 08:41:29 -05:00
MINOR: ssl/show_fd: report some FDs as suspicious when possible If a subscriber's tasklet was called more than one million times, if the ssl_ctx's connection doesn't match the current one, or if the connection appears closed in one direction while the SSL stack is still subscribed, the FD is reported as suspicious. The close cases may occasionally trigger a false positive during very short and rare windows. Similarly the 1M calls will trigger after 16GB are transferred over a given connection. These are rare enough events to be reported as suspicious.
2021-01-21 02:53:50 -05:00
if (sctx->conn != conn) {
chunk_appendf(&trash, " xctx.conn=%p(BOGUS)", sctx->conn);
ret = 1;
}
DEBUG: ssl-sock/show_fd: Display SSL error code Like for connection error code, when FD are dumps, the ssl error code is now displayed. This may help to diagnose why a connection error occurred. This patch may be backported to help debugging.
2023-03-14 10:51:33 -04:00
chunk_appendf(&trash, " xctx.st=%d .err=%ld", sctx->xprt_st, sctx->error_code);
MINOR: ssl: provide a "show fd" helper to report important SSL information The SSL context contains a lot of important details that are currently missing from debug outputs. Now that we detect ssl_sock, we can perform some sanity checks, print the next xprt, the subscriber callback's context, handler and number of calls. The process function is also resolved. This now gives for example on an H2 connection: 1029 : st=0x21(R:rA W:Ra) ev=0x01(heopI) [lc] tmask=0x2 umask=0x2 owner=0x7fc714881700 iocb=0x65b528(sock_conn_iocb) back=0 cflg=0x00001300 fe=recv mux=H2 ctx=0x7fc734545e50 h2c.st0=FRH .err=0 .maxid=217 .lastid=-1 .flg=0x0000 .nbst=0 .nbcs=0 .fctl_cnt=0 .send_cnt=0 .tree_cnt=0 .orph_cnt=0 .sub=1 .dsi=217 .dbuf=0@(nil)+0/0 .msi=-1 .mbuf=[1..1|32],h=[0@(nil)+0/0],t=[0@(nil)+0/0] xprt=SSL xprt_ctx=0x7fc73478f230 xctx.st=0 .xprt=RAW .wait.ev=1 .subs=0x7fc734546350(ev=1 tl=0x7fc7346702e0 tl.calls=278 tl.ctx=0x7fc734545e50 tl.fct=main-0x144efa) .sent_early=0 .early_in=0
2021-01-20 08:41:29 -05:00
if (sctx->xprt) {
chunk_appendf(&trash, " .xprt=%s", sctx->xprt->name);
if (sctx->xprt_ctx)
chunk_appendf(&trash, " .xctx=%p", sctx->xprt_ctx);
}
chunk_appendf(&trash, " .wait.ev=%d", sctx->wait_event.events);
MINOR: ssl/show_fd: report some FDs as suspicious when possible If a subscriber's tasklet was called more than one million times, if the ssl_ctx's connection doesn't match the current one, or if the connection appears closed in one direction while the SSL stack is still subscribed, the FD is reported as suspicious. The close cases may occasionally trigger a false positive during very short and rare windows. Similarly the 1M calls will trigger after 16GB are transferred over a given connection. These are rare enough events to be reported as suspicious.
2021-01-21 02:53:50 -05:00
/* as soon as a shutdown is reported the lower layer unregisters its
* subscriber, so the situations below are transient and rare enough to
* be reported as suspicious. In any case they shouldn't last.
*/
if ((sctx->wait_event.events & 1) && (conn->flags & (CO_FL_SOCK_RD_SH|CO_FL_ERROR)))
ret = 1;
if ((sctx->wait_event.events & 2) && (conn->flags & (CO_FL_SOCK_WR_SH|CO_FL_ERROR)))
ret = 1;
MINOR: ssl: provide a "show fd" helper to report important SSL information The SSL context contains a lot of important details that are currently missing from debug outputs. Now that we detect ssl_sock, we can perform some sanity checks, print the next xprt, the subscriber callback's context, handler and number of calls. The process function is also resolved. This now gives for example on an H2 connection: 1029 : st=0x21(R:rA W:Ra) ev=0x01(heopI) [lc] tmask=0x2 umask=0x2 owner=0x7fc714881700 iocb=0x65b528(sock_conn_iocb) back=0 cflg=0x00001300 fe=recv mux=H2 ctx=0x7fc734545e50 h2c.st0=FRH .err=0 .maxid=217 .lastid=-1 .flg=0x0000 .nbst=0 .nbcs=0 .fctl_cnt=0 .send_cnt=0 .tree_cnt=0 .orph_cnt=0 .sub=1 .dsi=217 .dbuf=0@(nil)+0/0 .msi=-1 .mbuf=[1..1|32],h=[0@(nil)+0/0],t=[0@(nil)+0/0] xprt=SSL xprt_ctx=0x7fc73478f230 xctx.st=0 .xprt=RAW .wait.ev=1 .subs=0x7fc734546350(ev=1 tl=0x7fc7346702e0 tl.calls=278 tl.ctx=0x7fc734545e50 tl.fct=main-0x144efa) .sent_early=0 .early_in=0
2021-01-20 08:41:29 -05:00
chunk_appendf(&trash, " .subs=%p", sctx->subs);
if (sctx->subs) {
chunk_appendf(&trash, "(ev=%d tl=%p", sctx->subs->events, sctx->subs->tasklet);
MINOR: ssl/show_fd: report some FDs as suspicious when possible If a subscriber's tasklet was called more than one million times, if the ssl_ctx's connection doesn't match the current one, or if the connection appears closed in one direction while the SSL stack is still subscribed, the FD is reported as suspicious. The close cases may occasionally trigger a false positive during very short and rare windows. Similarly the 1M calls will trigger after 16GB are transferred over a given connection. These are rare enough events to be reported as suspicious.
2021-01-21 02:53:50 -05:00
if (sctx->subs->tasklet->calls >= 1000000)
ret = 1;
MINOR: ssl: provide a "show fd" helper to report important SSL information The SSL context contains a lot of important details that are currently missing from debug outputs. Now that we detect ssl_sock, we can perform some sanity checks, print the next xprt, the subscriber callback's context, handler and number of calls. The process function is also resolved. This now gives for example on an H2 connection: 1029 : st=0x21(R:rA W:Ra) ev=0x01(heopI) [lc] tmask=0x2 umask=0x2 owner=0x7fc714881700 iocb=0x65b528(sock_conn_iocb) back=0 cflg=0x00001300 fe=recv mux=H2 ctx=0x7fc734545e50 h2c.st0=FRH .err=0 .maxid=217 .lastid=-1 .flg=0x0000 .nbst=0 .nbcs=0 .fctl_cnt=0 .send_cnt=0 .tree_cnt=0 .orph_cnt=0 .sub=1 .dsi=217 .dbuf=0@(nil)+0/0 .msi=-1 .mbuf=[1..1|32],h=[0@(nil)+0/0],t=[0@(nil)+0/0] xprt=SSL xprt_ctx=0x7fc73478f230 xctx.st=0 .xprt=RAW .wait.ev=1 .subs=0x7fc734546350(ev=1 tl=0x7fc7346702e0 tl.calls=278 tl.ctx=0x7fc734545e50 tl.fct=main-0x144efa) .sent_early=0 .early_in=0
2021-01-20 08:41:29 -05:00
chunk_appendf(&trash, " tl.calls=%d tl.ctx=%p tl.fct=",
sctx->subs->tasklet->calls,
sctx->subs->tasklet->context);
resolve_sym_name(&trash, NULL, sctx->subs->tasklet->process);
chunk_appendf(&trash, ")");
}
chunk_appendf(&trash, " .sent_early=%d", sctx->sent_early_data);
chunk_appendf(&trash, " .early_in=%d", (int)sctx->early_buf.data);
MINOR: ssl/show_fd: report some FDs as suspicious when possible If a subscriber's tasklet was called more than one million times, if the ssl_ctx's connection doesn't match the current one, or if the connection appears closed in one direction while the SSL stack is still subscribed, the FD is reported as suspicious. The close cases may occasionally trigger a false positive during very short and rare windows. Similarly the 1M calls will trigger after 16GB are transferred over a given connection. These are rare enough events to be reported as suspicious.
2021-01-21 02:53:50 -05:00
return ret;
MINOR: ssl: provide a "show fd" helper to report important SSL information The SSL context contains a lot of important details that are currently missing from debug outputs. Now that we detect ssl_sock, we can perform some sanity checks, print the next xprt, the subscriber callback's context, handler and number of calls. The process function is also resolved. This now gives for example on an H2 connection: 1029 : st=0x21(R:rA W:Ra) ev=0x01(heopI) [lc] tmask=0x2 umask=0x2 owner=0x7fc714881700 iocb=0x65b528(sock_conn_iocb) back=0 cflg=0x00001300 fe=recv mux=H2 ctx=0x7fc734545e50 h2c.st0=FRH .err=0 .maxid=217 .lastid=-1 .flg=0x0000 .nbst=0 .nbcs=0 .fctl_cnt=0 .send_cnt=0 .tree_cnt=0 .orph_cnt=0 .sub=1 .dsi=217 .dbuf=0@(nil)+0/0 .msi=-1 .mbuf=[1..1|32],h=[0@(nil)+0/0],t=[0@(nil)+0/0] xprt=SSL xprt_ctx=0x7fc73478f230 xctx.st=0 .xprt=RAW .wait.ev=1 .subs=0x7fc734546350(ev=1 tl=0x7fc7346702e0 tl.calls=278 tl.ctx=0x7fc734545e50 tl.fct=main-0x144efa) .sent_early=0 .early_in=0
2021-01-20 08:41:29 -05:00
}
MINOR: ssl: make tlskeys_list_get_next() take a list element As reported in issue #1010, gcc-11 as of 2021-01-05 is overzealous in its -Warray-bounds check as it considers that a cast of a global struct accesses the entire struct even if only one specific element is accessed. This instantly breaks all lists making use of container_of() to build their iterators as soon as the starting point is known if the next element is retrieved from the list head in a way that is visible to the compiler's optimizer, because it decides that accessing the list's next element dereferences the list as a larger struct (which it does not). The temporary workaround consisted in disabling -Warray-bounds, but this warning is traditionally quite effective at spotting real bugs, and we actually have is a single occurrence of this issue in the whole code. By changing the tlskeys_list_get_next() function to take a list element as the starting point instead of the current element, we can avoid the starting point issue but this requires to change all call places to write hideous casts made of &((struct blah*)ref)->list. At the moment we only have two such call places, the first one being used to initialize the list (which is the one causing the warning) and which is thus easy to simplify, and the second one for which we already have an aliased pointer to the reference that is still valid at the call place, and given the original pointer also remained unchanged, we can safely use this alias, and this is safer than leaving a cast there. Let's make this change now while it's still easy. The generated code only changed in function cli_io_handler_tlskeys_files() due to register allocation and the change of variable scope between the old one and the new one.
2021-01-05 04:44:30 -05:00
#if (defined SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB && TLS_TICKETS_NO > 0)
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
/* This function is used with TLS ticket keys management. It permits to browse
MINOR: ssl: make tlskeys_list_get_next() take a list element As reported in issue #1010, gcc-11 as of 2021-01-05 is overzealous in its -Warray-bounds check as it considers that a cast of a global struct accesses the entire struct even if only one specific element is accessed. This instantly breaks all lists making use of container_of() to build their iterators as soon as the starting point is known if the next element is retrieved from the list head in a way that is visible to the compiler's optimizer, because it decides that accessing the list's next element dereferences the list as a larger struct (which it does not). The temporary workaround consisted in disabling -Warray-bounds, but this warning is traditionally quite effective at spotting real bugs, and we actually have is a single occurrence of this issue in the whole code. By changing the tlskeys_list_get_next() function to take a list element as the starting point instead of the current element, we can avoid the starting point issue but this requires to change all call places to write hideous casts made of &((struct blah*)ref)->list. At the moment we only have two such call places, the first one being used to initialize the list (which is the one causing the warning) and which is thus easy to simplify, and the second one for which we already have an aliased pointer to the reference that is still valid at the call place, and given the original pointer also remained unchanged, we can safely use this alias, and this is safer than leaving a cast there. Let's make this change now while it's still easy. The generated code only changed in function cli_io_handler_tlskeys_files() due to register allocation and the change of variable scope between the old one and the new one.
2021-01-05 04:44:30 -05:00
* each reference. The variable <ref> must point to the current node's list
* element (which starts by the root), and <end> must point to the root node.
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
*/
static inline
MINOR: ssl: make tlskeys_list_get_next() take a list element As reported in issue #1010, gcc-11 as of 2021-01-05 is overzealous in its -Warray-bounds check as it considers that a cast of a global struct accesses the entire struct even if only one specific element is accessed. This instantly breaks all lists making use of container_of() to build their iterators as soon as the starting point is known if the next element is retrieved from the list head in a way that is visible to the compiler's optimizer, because it decides that accessing the list's next element dereferences the list as a larger struct (which it does not). The temporary workaround consisted in disabling -Warray-bounds, but this warning is traditionally quite effective at spotting real bugs, and we actually have is a single occurrence of this issue in the whole code. By changing the tlskeys_list_get_next() function to take a list element as the starting point instead of the current element, we can avoid the starting point issue but this requires to change all call places to write hideous casts made of &((struct blah*)ref)->list. At the moment we only have two such call places, the first one being used to initialize the list (which is the one causing the warning) and which is thus easy to simplify, and the second one for which we already have an aliased pointer to the reference that is still valid at the call place, and given the original pointer also remained unchanged, we can safely use this alias, and this is safer than leaving a cast there. Let's make this change now while it's still easy. The generated code only changed in function cli_io_handler_tlskeys_files() due to register allocation and the change of variable scope between the old one and the new one.
2021-01-05 04:44:30 -05:00
struct tls_keys_ref *tlskeys_list_get_next(struct list *ref, struct list *end)
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
{
CLEANUP: ssl: Remove useless loop in tlskeys_list_get_next() This loop was always exited in the first iteration by `return`.
2021-01-02 19:29:55 -05:00
/* Get next list entry. */
MINOR: ssl: make tlskeys_list_get_next() take a list element As reported in issue #1010, gcc-11 as of 2021-01-05 is overzealous in its -Warray-bounds check as it considers that a cast of a global struct accesses the entire struct even if only one specific element is accessed. This instantly breaks all lists making use of container_of() to build their iterators as soon as the starting point is known if the next element is retrieved from the list head in a way that is visible to the compiler's optimizer, because it decides that accessing the list's next element dereferences the list as a larger struct (which it does not). The temporary workaround consisted in disabling -Warray-bounds, but this warning is traditionally quite effective at spotting real bugs, and we actually have is a single occurrence of this issue in the whole code. By changing the tlskeys_list_get_next() function to take a list element as the starting point instead of the current element, we can avoid the starting point issue but this requires to change all call places to write hideous casts made of &((struct blah*)ref)->list. At the moment we only have two such call places, the first one being used to initialize the list (which is the one causing the warning) and which is thus easy to simplify, and the second one for which we already have an aliased pointer to the reference that is still valid at the call place, and given the original pointer also remained unchanged, we can safely use this alias, and this is safer than leaving a cast there. Let's make this change now while it's still easy. The generated code only changed in function cli_io_handler_tlskeys_files() due to register allocation and the change of variable scope between the old one and the new one.
2021-01-05 04:44:30 -05:00
ref = ref->n;
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
CLEANUP: ssl: Remove useless loop in tlskeys_list_get_next() This loop was always exited in the first iteration by `return`.
2021-01-02 19:29:55 -05:00
/* If the entry is the last of the list, return NULL. */
MINOR: ssl: make tlskeys_list_get_next() take a list element As reported in issue #1010, gcc-11 as of 2021-01-05 is overzealous in its -Warray-bounds check as it considers that a cast of a global struct accesses the entire struct even if only one specific element is accessed. This instantly breaks all lists making use of container_of() to build their iterators as soon as the starting point is known if the next element is retrieved from the list head in a way that is visible to the compiler's optimizer, because it decides that accessing the list's next element dereferences the list as a larger struct (which it does not). The temporary workaround consisted in disabling -Warray-bounds, but this warning is traditionally quite effective at spotting real bugs, and we actually have is a single occurrence of this issue in the whole code. By changing the tlskeys_list_get_next() function to take a list element as the starting point instead of the current element, we can avoid the starting point issue but this requires to change all call places to write hideous casts made of &((struct blah*)ref)->list. At the moment we only have two such call places, the first one being used to initialize the list (which is the one causing the warning) and which is thus easy to simplify, and the second one for which we already have an aliased pointer to the reference that is still valid at the call place, and given the original pointer also remained unchanged, we can safely use this alias, and this is safer than leaving a cast there. Let's make this change now while it's still easy. The generated code only changed in function cli_io_handler_tlskeys_files() due to register allocation and the change of variable scope between the old one and the new one.
2021-01-05 04:44:30 -05:00
if (ref == end)
CLEANUP: ssl: Remove useless loop in tlskeys_list_get_next() This loop was always exited in the first iteration by `return`.
2021-01-02 19:29:55 -05:00
return NULL;
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
MINOR: ssl: make tlskeys_list_get_next() take a list element As reported in issue #1010, gcc-11 as of 2021-01-05 is overzealous in its -Warray-bounds check as it considers that a cast of a global struct accesses the entire struct even if only one specific element is accessed. This instantly breaks all lists making use of container_of() to build their iterators as soon as the starting point is known if the next element is retrieved from the list head in a way that is visible to the compiler's optimizer, because it decides that accessing the list's next element dereferences the list as a larger struct (which it does not). The temporary workaround consisted in disabling -Warray-bounds, but this warning is traditionally quite effective at spotting real bugs, and we actually have is a single occurrence of this issue in the whole code. By changing the tlskeys_list_get_next() function to take a list element as the starting point instead of the current element, we can avoid the starting point issue but this requires to change all call places to write hideous casts made of &((struct blah*)ref)->list. At the moment we only have two such call places, the first one being used to initialize the list (which is the one causing the warning) and which is thus easy to simplify, and the second one for which we already have an aliased pointer to the reference that is still valid at the call place, and given the original pointer also remained unchanged, we can safely use this alias, and this is safer than leaving a cast there. Let's make this change now while it's still easy. The generated code only changed in function cli_io_handler_tlskeys_files() due to register allocation and the change of variable scope between the old one and the new one.
2021-01-05 04:44:30 -05:00
return LIST_ELEM(ref, struct tls_keys_ref *, list);
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
}
static inline
struct tls_keys_ref *tlskeys_ref_lookup_ref(const char *reference)
{
int id;
char *error;
/* If the reference starts by a '#', this is numeric id. */
if (reference[0] == '#') {
/* Try to convert the numeric id. If the conversion fails, the lookup fails. */
id = strtol(reference + 1, &error, 10);
if (*error != '\0')
return NULL;
/* Perform the unique id lookup. */
return tlskeys_ref_lookupid(id);
}
/* Perform the string lookup. */
return tlskeys_ref_lookup(reference);
}
#endif
#if (defined SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB && TLS_TICKETS_NO > 0)
CLEANUP: ssl/cli: stop using ctx.cli.i0/i1/p0 for "show tls-keys" This creates a local context of type show_keys_ctx which contains the equivalent fields with more natural names.
2022-05-05 02:50:17 -04:00
/* dumps all tls keys. Relies on the show_keys_ctx context from the appctx. */
CLEANUP: ssl/cli: add a new "dump_entries" field to "show_keys_ref" This gets rid of a ugly hack consisting in checking the IO handler's address while one is defined as an inline function calling the second.
2022-05-05 02:59:17 -04:00
static int cli_io_handler_tlskeys_files(struct appctx *appctx)
{
CLEANUP: ssl/cli: stop using ctx.cli.i0/i1/p0 for "show tls-keys" This creates a local context of type show_keys_ctx which contains the equivalent fields with more natural names.
2022-05-05 02:50:17 -04:00
struct show_keys_ctx *ctx = appctx->svcctx;
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
CLEANUP: ssl/cli: make "show tlskeys" not use appctx->st2 anymore A new "state" enum was added to "show_keys_ctx" for this, and only 3 states are needed.
2022-05-05 03:03:44 -04:00
switch (ctx->state) {
case SHOW_KEYS_INIT:
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
/* Display the column headers. If the message cannot be sent,
CLEANUP: fix typos in the ssl_sock subsystem Fix some typos found in the code comments of the ssl_sock subsystem.
2018-11-15 12:07:59 -05:00
* quit the function with returning 0. The function is called
CLEANUP: ssl/cli: make "show tlskeys" not use appctx->st2 anymore A new "state" enum was added to "show_keys_ctx" for this, and only 3 states are needed.
2022-05-05 03:03:44 -04:00
* later and restart at the state "SHOW_KEYS_INIT".
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
*/
chunk_reset(&trash);
CLEANUP: ssl/cli: add a new "dump_entries" field to "show_keys_ref" This gets rid of a ugly hack consisting in checking the IO handler's address while one is defined as an inline function calling the second.
2022-05-05 02:59:17 -04:00
if (ctx->dump_entries)
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
chunk_appendf(&trash, "# id secret\n");
else
chunk_appendf(&trash, "# id (file)\n");
CLEANUP: applet: use applet_put*() everywhere possible This applies the change so that the applet code stops using ci_putchk() and friends everywhere possible, for the much saferapplet_put*() instead. The change is mechanical but large. Two or three functions used to have no appctx and a cs derived from the appctx instead, which was a reminiscence of old times' stream_interface. These were simply changed to directly take the appctx. No sensitive change was performed, and the old (more complex) API is still usable when needed (e.g. the channel is already known). The change touched roughly a hundred of locations, with no less than 124 lines removed. It's worth noting that the stats applet, the oldest of the series, could get a serious lifting, as it's still very channel-centric instead of propagating the appctx along the chain. Given that this code doesn't change often, there's no emergency to clean it up but it would look better.
2022-05-18 09:07:19 -04:00
if (applet_putchk(appctx, &trash) == -1)
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
return 0;
/* Now, we start the browsing of the references lists.
* Note that the following call to LIST_ELEM return bad pointer. The only
* available field of this pointer is <list>. It is used with the function
CLEANUP: assorted typo fixes in the code and comments This is 37th iteration of typo fixes
2023-11-21 13:54:16 -05:00
* tlskeys_list_get_next() for returning the first available entry
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
*/
CLEANUP: ssl/cli: stop using ctx.cli.i0/i1/p0 for "show tls-keys" This creates a local context of type show_keys_ctx which contains the equivalent fields with more natural names.
2022-05-05 02:50:17 -04:00
if (ctx->next_ref == NULL)
ctx->next_ref = tlskeys_list_get_next(&tlskeys_reference, &tlskeys_reference);
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
CLEANUP: ssl/cli: make "show tlskeys" not use appctx->st2 anymore A new "state" enum was added to "show_keys_ctx" for this, and only 3 states are needed.
2022-05-05 03:03:44 -04:00
ctx->state = SHOW_KEYS_LIST;
BUILD: ssl: use __fallthrough in cli_io_handler_tlskeys_files() This avoids two build warnings when preprocessing happens before compiling with gcc >= 7.
2022-11-14 01:34:43 -05:00
__fallthrough;
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
CLEANUP: ssl/cli: make "show tlskeys" not use appctx->st2 anymore A new "state" enum was added to "show_keys_ctx" for this, and only 3 states are needed.
2022-05-05 03:03:44 -04:00
case SHOW_KEYS_LIST:
CLEANUP: ssl/cli: stop using ctx.cli.i0/i1/p0 for "show tls-keys" This creates a local context of type show_keys_ctx which contains the equivalent fields with more natural names.
2022-05-05 02:50:17 -04:00
while (ctx->next_ref) {
struct tls_keys_ref *ref = ctx->next_ref;
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
chunk_reset(&trash);
CLEANUP: ssl/cli: add a new "dump_entries" field to "show_keys_ref" This gets rid of a ugly hack consisting in checking the IO handler's address while one is defined as an inline function calling the second.
2022-05-05 02:59:17 -04:00
if (ctx->dump_entries && ctx->next_index == 0)
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
chunk_appendf(&trash, "# ");
MINOR: appctx/cli: remove the "tlskeys" entry from the appctx union This one now migrates to the general purpose cli.p0 for the ref pointer, cli.i0 for the dump_all flag and cli.i1 for the dump_keys_index. A few comments were added. The applet.h file doesn't depend on openssl anymore. It's worth noting that the previous dependency was accidental and only used to work because all files including this one used to have openssl included prior to loading this file.
2016-12-16 12:47:27 -05:00
CLEANUP: ssl/cli: stop using ctx.cli.i0/i1/p0 for "show tls-keys" This creates a local context of type show_keys_ctx which contains the equivalent fields with more natural names.
2022-05-05 02:50:17 -04:00
if (ctx->next_index == 0)
MINOR: appctx/cli: remove the "tlskeys" entry from the appctx union This one now migrates to the general purpose cli.p0 for the ref pointer, cli.i0 for the dump_all flag and cli.i1 for the dump_keys_index. A few comments were added. The applet.h file doesn't depend on openssl anymore. It's worth noting that the previous dependency was accidental and only used to work because all files including this one used to have openssl included prior to loading this file.
2016-12-16 12:47:27 -05:00
chunk_appendf(&trash, "%d (%s)\n", ref->unique_id, ref->filename);
CLEANUP: ssl/cli: add a new "dump_entries" field to "show_keys_ref" This gets rid of a ugly hack consisting in checking the IO handler's address while one is defined as an inline function calling the second.
2022-05-05 02:59:17 -04:00
if (ctx->dump_entries) {
BUG/MINOR: ssl/threads: Make management of the TLS ticket keys files thread-safe A TLS ticket keys file can be updated on the CLI and used in same time. So we need to protect it to be sure all accesses are thread-safe. Because updates are infrequent, a R/W lock has been used. This patch must be backported in 1.8
2018-02-16 05:23:49 -05:00
int head;
HA_RWLOCK_RDLOCK(TLSKEYS_REF_LOCK, &ref->lock);
head = ref->tls_ticket_enc_index;
CLEANUP: ssl/cli: stop using ctx.cli.i0/i1/p0 for "show tls-keys" This creates a local context of type show_keys_ctx which contains the equivalent fields with more natural names.
2022-05-05 02:50:17 -04:00
while (ctx->next_index < TLS_TICKETS_NO) {
MAJOR: chunks: replace struct chunk with struct buffer Now all the code used to manipulate chunks uses a struct buffer instead. The functions are still called "chunk*", and some of them will progressively move to the generic buffer handling code as they are cleaned up.
2018-07-13 05:56:34 -04:00
struct buffer *t2 = get_trash_chunk();
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
chunk_reset(t2);
/* should never fail here because we dump only a key in the t2 buffer */
MINOR: ssl: add support of aes256 bits ticket keys on file and cli. Openssl switched from aes128 to aes256 since may 2016 to compute tls ticket secrets used by default. But Haproxy still handled only 128 bits keys for both tls key file and CLI. This patch permit the user to set aes256 keys throught CLI or the key file (80 bytes encoded in base64) in the same way that aes128 keys were handled (48 bytes encoded in base64): - first 16 bytes for the key name - next 16/32 bytes for aes 128/256 key bits key - last 16/32 bytes for hmac 128/256 bits Both sizes are now supported (but keys from same file must be of the same size and can but updated via CLI only using a key of the same size). Note: This feature need the fix "dec func ignores padding for output size checking."
2019-01-10 11:51:55 -05:00
if (ref->key_size_bits == 128) {
CLEANUP: ssl/cli: stop using ctx.cli.i0/i1/p0 for "show tls-keys" This creates a local context of type show_keys_ctx which contains the equivalent fields with more natural names.
2022-05-05 02:50:17 -04:00
t2->data = a2base64((char *)(ref->tlskeys + (head + 2 + ctx->next_index) % TLS_TICKETS_NO),
MINOR: ssl: add support of aes256 bits ticket keys on file and cli. Openssl switched from aes128 to aes256 since may 2016 to compute tls ticket secrets used by default. But Haproxy still handled only 128 bits keys for both tls key file and CLI. This patch permit the user to set aes256 keys throught CLI or the key file (80 bytes encoded in base64) in the same way that aes128 keys were handled (48 bytes encoded in base64): - first 16 bytes for the key name - next 16/32 bytes for aes 128/256 key bits key - last 16/32 bytes for hmac 128/256 bits Both sizes are now supported (but keys from same file must be of the same size and can but updated via CLI only using a key of the same size). Note: This feature need the fix "dec func ignores padding for output size checking."
2019-01-10 11:51:55 -05:00
sizeof(struct tls_sess_key_128),
t2->area, t2->size);
CLEANUP: ssl/cli: stop using ctx.cli.i0/i1/p0 for "show tls-keys" This creates a local context of type show_keys_ctx which contains the equivalent fields with more natural names.
2022-05-05 02:50:17 -04:00
chunk_appendf(&trash, "%d.%d %s\n", ref->unique_id, ctx->next_index,
MINOR: ssl: add support of aes256 bits ticket keys on file and cli. Openssl switched from aes128 to aes256 since may 2016 to compute tls ticket secrets used by default. But Haproxy still handled only 128 bits keys for both tls key file and CLI. This patch permit the user to set aes256 keys throught CLI or the key file (80 bytes encoded in base64) in the same way that aes128 keys were handled (48 bytes encoded in base64): - first 16 bytes for the key name - next 16/32 bytes for aes 128/256 key bits key - last 16/32 bytes for hmac 128/256 bits Both sizes are now supported (but keys from same file must be of the same size and can but updated via CLI only using a key of the same size). Note: This feature need the fix "dec func ignores padding for output size checking."
2019-01-10 11:51:55 -05:00
t2->area);
}
else if (ref->key_size_bits == 256) {
CLEANUP: ssl/cli: stop using ctx.cli.i0/i1/p0 for "show tls-keys" This creates a local context of type show_keys_ctx which contains the equivalent fields with more natural names.
2022-05-05 02:50:17 -04:00
t2->data = a2base64((char *)(ref->tlskeys + (head + 2 + ctx->next_index) % TLS_TICKETS_NO),
MINOR: ssl: add support of aes256 bits ticket keys on file and cli. Openssl switched from aes128 to aes256 since may 2016 to compute tls ticket secrets used by default. But Haproxy still handled only 128 bits keys for both tls key file and CLI. This patch permit the user to set aes256 keys throught CLI or the key file (80 bytes encoded in base64) in the same way that aes128 keys were handled (48 bytes encoded in base64): - first 16 bytes for the key name - next 16/32 bytes for aes 128/256 key bits key - last 16/32 bytes for hmac 128/256 bits Both sizes are now supported (but keys from same file must be of the same size and can but updated via CLI only using a key of the same size). Note: This feature need the fix "dec func ignores padding for output size checking."
2019-01-10 11:51:55 -05:00
sizeof(struct tls_sess_key_256),
t2->area, t2->size);
CLEANUP: ssl/cli: stop using ctx.cli.i0/i1/p0 for "show tls-keys" This creates a local context of type show_keys_ctx which contains the equivalent fields with more natural names.
2022-05-05 02:50:17 -04:00
chunk_appendf(&trash, "%d.%d %s\n", ref->unique_id, ctx->next_index,
MINOR: ssl: add support of aes256 bits ticket keys on file and cli. Openssl switched from aes128 to aes256 since may 2016 to compute tls ticket secrets used by default. But Haproxy still handled only 128 bits keys for both tls key file and CLI. This patch permit the user to set aes256 keys throught CLI or the key file (80 bytes encoded in base64) in the same way that aes128 keys were handled (48 bytes encoded in base64): - first 16 bytes for the key name - next 16/32 bytes for aes 128/256 key bits key - last 16/32 bytes for hmac 128/256 bits Both sizes are now supported (but keys from same file must be of the same size and can but updated via CLI only using a key of the same size). Note: This feature need the fix "dec func ignores padding for output size checking."
2019-01-10 11:51:55 -05:00
t2->area);
}
else {
/* This case should never happen */
CLEANUP: ssl/cli: stop using ctx.cli.i0/i1/p0 for "show tls-keys" This creates a local context of type show_keys_ctx which contains the equivalent fields with more natural names.
2022-05-05 02:50:17 -04:00
chunk_appendf(&trash, "%d.%d <unknown>\n", ref->unique_id, ctx->next_index);
MINOR: ssl: add support of aes256 bits ticket keys on file and cli. Openssl switched from aes128 to aes256 since may 2016 to compute tls ticket secrets used by default. But Haproxy still handled only 128 bits keys for both tls key file and CLI. This patch permit the user to set aes256 keys throught CLI or the key file (80 bytes encoded in base64) in the same way that aes128 keys were handled (48 bytes encoded in base64): - first 16 bytes for the key name - next 16/32 bytes for aes 128/256 key bits key - last 16/32 bytes for hmac 128/256 bits Both sizes are now supported (but keys from same file must be of the same size and can but updated via CLI only using a key of the same size). Note: This feature need the fix "dec func ignores padding for output size checking."
2019-01-10 11:51:55 -05:00
}
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
CLEANUP: applet: use applet_put*() everywhere possible This applies the change so that the applet code stops using ci_putchk() and friends everywhere possible, for the much saferapplet_put*() instead. The change is mechanical but large. Two or three functions used to have no appctx and a cs derived from the appctx instead, which was a reminiscence of old times' stream_interface. These were simply changed to directly take the appctx. No sensitive change was performed, and the old (more complex) API is still usable when needed (e.g. the channel is already known). The change touched roughly a hundred of locations, with no less than 124 lines removed. It's worth noting that the stats applet, the oldest of the series, could get a serious lifting, as it's still very channel-centric instead of propagating the appctx along the chain. Given that this code doesn't change often, there's no emergency to clean it up but it would look better.
2022-05-18 09:07:19 -04:00
if (applet_putchk(appctx, &trash) == -1) {
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
/* let's try again later from this stream. We add ourselves into
* this stream's users so that it can remove us upon termination.
*/
BUG/MINOR: ssl/threads: Make management of the TLS ticket keys files thread-safe A TLS ticket keys file can be updated on the CLI and used in same time. So we need to protect it to be sure all accesses are thread-safe. Because updates are infrequent, a R/W lock has been used. This patch must be backported in 1.8
2018-02-16 05:23:49 -05:00
HA_RWLOCK_RDUNLOCK(TLSKEYS_REF_LOCK, &ref->lock);
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
return 0;
}
CLEANUP: ssl/cli: stop using ctx.cli.i0/i1/p0 for "show tls-keys" This creates a local context of type show_keys_ctx which contains the equivalent fields with more natural names.
2022-05-05 02:50:17 -04:00
ctx->next_index++;
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
}
BUG/MINOR: ssl/threads: Make management of the TLS ticket keys files thread-safe A TLS ticket keys file can be updated on the CLI and used in same time. So we need to protect it to be sure all accesses are thread-safe. Because updates are infrequent, a R/W lock has been used. This patch must be backported in 1.8
2018-02-16 05:23:49 -05:00
HA_RWLOCK_RDUNLOCK(TLSKEYS_REF_LOCK, &ref->lock);
CLEANUP: ssl/cli: stop using ctx.cli.i0/i1/p0 for "show tls-keys" This creates a local context of type show_keys_ctx which contains the equivalent fields with more natural names.
2022-05-05 02:50:17 -04:00
ctx->next_index = 0;
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
}
CLEANUP: applet: use applet_put*() everywhere possible This applies the change so that the applet code stops using ci_putchk() and friends everywhere possible, for the much saferapplet_put*() instead. The change is mechanical but large. Two or three functions used to have no appctx and a cs derived from the appctx instead, which was a reminiscence of old times' stream_interface. These were simply changed to directly take the appctx. No sensitive change was performed, and the old (more complex) API is still usable when needed (e.g. the channel is already known). The change touched roughly a hundred of locations, with no less than 124 lines removed. It's worth noting that the stats applet, the oldest of the series, could get a serious lifting, as it's still very channel-centric instead of propagating the appctx along the chain. Given that this code doesn't change often, there's no emergency to clean it up but it would look better.
2022-05-18 09:07:19 -04:00
if (applet_putchk(appctx, &trash) == -1) {
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
/* let's try again later from this stream. We add ourselves into
* this stream's users so that it can remove us upon termination.
*/
return 0;
}
CLEANUP: ssl/cli: stop using ctx.cli.i0/i1/p0 for "show tls-keys" This creates a local context of type show_keys_ctx which contains the equivalent fields with more natural names.
2022-05-05 02:50:17 -04:00
if (ctx->names_only == 0) /* don't display everything if not necessary */
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
break;
/* get next list entry and check the end of the list */
CLEANUP: ssl/cli: stop using ctx.cli.i0/i1/p0 for "show tls-keys" This creates a local context of type show_keys_ctx which contains the equivalent fields with more natural names.
2022-05-05 02:50:17 -04:00
ctx->next_ref = tlskeys_list_get_next(&ref->list, &tlskeys_reference);
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
}
CLEANUP: ssl/cli: make "show tlskeys" not use appctx->st2 anymore A new "state" enum was added to "show_keys_ctx" for this, and only 3 states are needed.
2022-05-05 03:03:44 -04:00
ctx->state = SHOW_KEYS_DONE;
BUILD: ssl: use __fallthrough in cli_io_handler_tlskeys_files() This avoids two build warnings when preprocessing happens before compiling with gcc >= 7.
2022-11-14 01:34:43 -05:00
__fallthrough;
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
default:
return 1;
}
return 0;
}
CLEANUP: ssl/cli: stop using ctx.cli.i0/i1/p0 for "show tls-keys" This creates a local context of type show_keys_ctx which contains the equivalent fields with more natural names.
2022-05-05 02:50:17 -04:00
/* Prepares a "show_keys_ctx" and sets the appropriate io_handler if needed */
MEDIUM: cli: Add payload support In order to use arbitrary data in the CLI (multiple lines or group of words that must be considered as a whole, for example), it is now possible to add a payload to the commands. To do so, the first line needs to end with a special pattern: <<\n. Everything that follows will be left untouched by the CLI parser and will be passed to the commands parsers. Per-command support will need to be added to take advantage of this feature. Signed-off-by: Aurlien Nephtali <aurelien.nephtali@corp.ovh.com>
2018-04-18 07:26:46 -04:00
static int cli_parse_show_tlskeys(char **args, char *payload, struct appctx *appctx, void *private)
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
{
CLEANUP: ssl/cli: stop using ctx.cli.i0/i1/p0 for "show tls-keys" This creates a local context of type show_keys_ctx which contains the equivalent fields with more natural names.
2022-05-05 02:50:17 -04:00
struct show_keys_ctx *ctx = applet_reserve_svcctx(appctx, sizeof(*ctx));
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
/* no parameter, shows only file list */
MINOR: ssl: Move OCSP code to a dedicated source file This is a simple cleanup that moves OCSP related code to a dedicated file instead of interlacing it in some pure ssl connection code.
2022-12-20 05:11:17 -05:00
if (!*args[2]) {
ctx->names_only = 1;
return 0;
}
MINOR: ssl: Add new "show ssl ocsp-response" CLI command This patch adds the "show ssl ocsp-response [<id>]" CLI command. This command can be used to display the IDs of the OCSP tree entries along with details about the entries' certificate ID (issuer's name and key hash + serial number), or to display the details of a single ocsp-response if an ID is given. The details displayed in this latter case are the ones shown by a "openssl ocsp -respin <ocsp-response> -text" call.
2021-06-10 07:51:13 -04:00
MINOR: ssl: Move OCSP code to a dedicated source file This is a simple cleanup that moves OCSP related code to a dedicated file instead of interlacing it in some pure ssl connection code.
2022-12-20 05:11:17 -05:00
if (args[2][0] == '*') {
/* list every TLS ticket keys */
ctx->names_only = 1;
MINOR: ssl: Add new "show ssl ocsp-response" CLI command This patch adds the "show ssl ocsp-response [<id>]" CLI command. This command can be used to display the IDs of the OCSP tree entries along with details about the entries' certificate ID (issuer's name and key hash + serial number), or to display the details of a single ocsp-response if an ID is given. The details displayed in this latter case are the ones shown by a "openssl ocsp -respin <ocsp-response> -text" call.
2021-06-10 07:51:13 -04:00
} else {
MINOR: ssl: Move OCSP code to a dedicated source file This is a simple cleanup that moves OCSP related code to a dedicated file instead of interlacing it in some pure ssl connection code.
2022-12-20 05:11:17 -05:00
ctx->next_ref = tlskeys_ref_lookup_ref(args[2]);
if (!ctx->next_ref)
return cli_err(appctx, "'show tls-keys' unable to locate referenced filename\n");
MINOR: ssl: Add new "show ssl ocsp-response" CLI command This patch adds the "show ssl ocsp-response [<id>]" CLI command. This command can be used to display the IDs of the OCSP tree entries along with details about the entries' certificate ID (issuer's name and key hash + serial number), or to display the details of a single ocsp-response if an ID is given. The details displayed in this latter case are the ones shown by a "openssl ocsp -respin <ocsp-response> -text" call.
2021-06-10 07:51:13 -04:00
}
MINOR: ssl: Move OCSP code to a dedicated source file This is a simple cleanup that moves OCSP related code to a dedicated file instead of interlacing it in some pure ssl connection code.
2022-12-20 05:11:17 -05:00
ctx->dump_entries = 1;
return 0;
}
MINOR: ssl: Add new "show ssl ocsp-response" CLI command This patch adds the "show ssl ocsp-response [<id>]" CLI command. This command can be used to display the IDs of the OCSP tree entries along with details about the entries' certificate ID (issuer's name and key hash + serial number), or to display the details of a single ocsp-response if an ID is given. The details displayed in this latter case are the ones shown by a "openssl ocsp -respin <ocsp-response> -text" call.
2021-06-10 07:51:13 -04:00
MINOR: ssl: Move OCSP code to a dedicated source file This is a simple cleanup that moves OCSP related code to a dedicated file instead of interlacing it in some pure ssl connection code.
2022-12-20 05:11:17 -05:00
static int cli_parse_set_tlskeys(char **args, char *payload, struct appctx *appctx, void *private)
{
struct tls_keys_ref *ref;
int ret;
MINOR: ssl: Add new "show ssl ocsp-response" CLI command This patch adds the "show ssl ocsp-response [<id>]" CLI command. This command can be used to display the IDs of the OCSP tree entries along with details about the entries' certificate ID (issuer's name and key hash + serial number), or to display the details of a single ocsp-response if an ID is given. The details displayed in this latter case are the ones shown by a "openssl ocsp -respin <ocsp-response> -text" call.
2021-06-10 07:51:13 -04:00
MINOR: ssl: Move OCSP code to a dedicated source file This is a simple cleanup that moves OCSP related code to a dedicated file instead of interlacing it in some pure ssl connection code.
2022-12-20 05:11:17 -05:00
/* Expect two parameters: the filename and the new new TLS key in encoding */
if (!*args[3] || !*args[4])
return cli_err(appctx, "'set ssl tls-key' expects a filename and the new TLS key in base64 encoding.\n");
MINOR: ssl: Add new "show ssl ocsp-response" CLI command This patch adds the "show ssl ocsp-response [<id>]" CLI command. This command can be used to display the IDs of the OCSP tree entries along with details about the entries' certificate ID (issuer's name and key hash + serial number), or to display the details of a single ocsp-response if an ID is given. The details displayed in this latter case are the ones shown by a "openssl ocsp -respin <ocsp-response> -text" call.
2021-06-10 07:51:13 -04:00
MINOR: ssl: Move OCSP code to a dedicated source file This is a simple cleanup that moves OCSP related code to a dedicated file instead of interlacing it in some pure ssl connection code.
2022-12-20 05:11:17 -05:00
ref = tlskeys_ref_lookup_ref(args[3]);
if (!ref)
return cli_err(appctx, "'set ssl tls-key' unable to locate referenced filename\n");
MINOR: ssl: Add new "show ssl ocsp-response" CLI command This patch adds the "show ssl ocsp-response [<id>]" CLI command. This command can be used to display the IDs of the OCSP tree entries along with details about the entries' certificate ID (issuer's name and key hash + serial number), or to display the details of a single ocsp-response if an ID is given. The details displayed in this latter case are the ones shown by a "openssl ocsp -respin <ocsp-response> -text" call.
2021-06-10 07:51:13 -04:00
MINOR: ssl: Move OCSP code to a dedicated source file This is a simple cleanup that moves OCSP related code to a dedicated file instead of interlacing it in some pure ssl connection code.
2022-12-20 05:11:17 -05:00
ret = base64dec(args[4], strlen(args[4]), trash.area, trash.size);
if (ret < 0)
return cli_err(appctx, "'set ssl tls-key' received invalid base64 encoded TLS key.\n");
MINOR: ssl: Add new "show ssl ocsp-response" CLI command This patch adds the "show ssl ocsp-response [<id>]" CLI command. This command can be used to display the IDs of the OCSP tree entries along with details about the entries' certificate ID (issuer's name and key hash + serial number), or to display the details of a single ocsp-response if an ID is given. The details displayed in this latter case are the ones shown by a "openssl ocsp -respin <ocsp-response> -text" call.
2021-06-10 07:51:13 -04:00
MINOR: ssl: Move OCSP code to a dedicated source file This is a simple cleanup that moves OCSP related code to a dedicated file instead of interlacing it in some pure ssl connection code.
2022-12-20 05:11:17 -05:00
trash.data = ret;
if (ssl_sock_update_tlskey_ref(ref, &trash) < 0)
return cli_err(appctx, "'set ssl tls-key' received a key of wrong size.\n");
MINOR: ssl: Add new "show ssl ocsp-response" CLI command This patch adds the "show ssl ocsp-response [<id>]" CLI command. This command can be used to display the IDs of the OCSP tree entries along with details about the entries' certificate ID (issuer's name and key hash + serial number), or to display the details of a single ocsp-response if an ID is given. The details displayed in this latter case are the ones shown by a "openssl ocsp -respin <ocsp-response> -text" call.
2021-06-10 07:51:13 -04:00
MINOR: ssl: Move OCSP code to a dedicated source file This is a simple cleanup that moves OCSP related code to a dedicated file instead of interlacing it in some pure ssl connection code.
2022-12-20 05:11:17 -05:00
return cli_msg(appctx, LOG_INFO, "TLS ticket key updated!\n");
MINOR: ssl: Add new "show ssl ocsp-response" CLI command This patch adds the "show ssl ocsp-response [<id>]" CLI command. This command can be used to display the IDs of the OCSP tree entries along with details about the entries' certificate ID (issuer's name and key hash + serial number), or to display the details of a single ocsp-response if an ID is given. The details displayed in this latter case are the ones shown by a "openssl ocsp -respin <ocsp-response> -text" call.
2021-06-10 07:51:13 -04:00
}
MINOR: ssl: Move OCSP code to a dedicated source file This is a simple cleanup that moves OCSP related code to a dedicated file instead of interlacing it in some pure ssl connection code.
2022-12-20 05:11:17 -05:00
#endif
MINOR: ssl: Add new "show ssl ocsp-response" CLI command This patch adds the "show ssl ocsp-response [<id>]" CLI command. This command can be used to display the IDs of the OCSP tree entries along with details about the entries' certificate ID (issuer's name and key hash + serial number), or to display the details of a single ocsp-response if an ID is given. The details displayed in this latter case are the ones shown by a "openssl ocsp -respin <ocsp-response> -text" call.
2021-06-10 07:51:13 -04:00
MINOR: ssl: Add 'show ssl providers' cli command and providers list in -vv option Starting from OpenSSLv3, providers are at the core of cryptography functions. Depending on the provider used, the way the SSL functionalities work could change. This new 'show ssl providers' CLI command allows to show what providers were loaded by the SSL library. This is required because the provider configuration is exclusively done in the OpenSSL configuration file (/usr/local/ssl/openssl.cnf for instance). A new line is also added to the 'haproxy -vv' output containing the same information.
2022-04-21 06:06:41 -04:00
#ifdef HAVE_SSL_PROVIDERS
struct provider_name {
const char *name;
struct list list;
};
static int ssl_provider_get_name_cb(OSSL_PROVIDER *provider, void *cbdata)
{
struct list *provider_names = cbdata;
struct provider_name *item = NULL;
const char *name = OSSL_PROVIDER_get0_name(provider);
if (!provider_names)
return 0;
item = calloc(1, sizeof(*item));
if (!item)
return 0;
item->name = name;
LIST_APPEND(provider_names, &item->list);
return 1;
}
static void ssl_provider_get_name_list(struct list *provider_names)
{
if (!provider_names)
return;
OSSL_PROVIDER_do_all(NULL, ssl_provider_get_name_cb, provider_names);
}
static void ssl_provider_clear_name_list(struct list *provider_names)
{
struct provider_name *item = NULL, *item_s = NULL;
if (provider_names) {
list_for_each_entry_safe(item, item_s, provider_names, list) {
LIST_DELETE(&item->list);
free(item);
}
}
}
static int cli_io_handler_show_providers(struct appctx *appctx)
{
struct buffer *trash = get_trash_chunk();
struct list provider_names;
struct provider_name *name;
LIST_INIT(&provider_names);
chunk_appendf(trash, "Loaded providers : \n");
ssl_provider_get_name_list(&provider_names);
list_for_each_entry(name, &provider_names, list) {
chunk_appendf(trash, "\t- %s\n", name->name);
}
ssl_provider_clear_name_list(&provider_names);
CLEANUP: applet: use applet_put*() everywhere possible This applies the change so that the applet code stops using ci_putchk() and friends everywhere possible, for the much saferapplet_put*() instead. The change is mechanical but large. Two or three functions used to have no appctx and a cs derived from the appctx instead, which was a reminiscence of old times' stream_interface. These were simply changed to directly take the appctx. No sensitive change was performed, and the old (more complex) API is still usable when needed (e.g. the channel is already known). The change touched roughly a hundred of locations, with no less than 124 lines removed. It's worth noting that the stats applet, the oldest of the series, could get a serious lifting, as it's still very channel-centric instead of propagating the appctx along the chain. Given that this code doesn't change often, there's no emergency to clean it up but it would look better.
2022-05-18 09:07:19 -04:00
if (applet_putchk(appctx, trash) == -1)
MINOR: ssl: Add 'show ssl providers' cli command and providers list in -vv option Starting from OpenSSLv3, providers are at the core of cryptography functions. Depending on the provider used, the way the SSL functionalities work could change. This new 'show ssl providers' CLI command allows to show what providers were loaded by the SSL library. This is required because the provider configuration is exclusively done in the OpenSSL configuration file (/usr/local/ssl/openssl.cnf for instance). A new line is also added to the 'haproxy -vv' output containing the same information.
2022-04-21 06:06:41 -04:00
goto yield;
return 1;
yield:
return 0;
}
#endif
MINOR: ssl: Add new "show ssl ocsp-response" CLI command This patch adds the "show ssl ocsp-response [<id>]" CLI command. This command can be used to display the IDs of the OCSP tree entries along with details about the entries' certificate ID (issuer's name and key hash + serial number), or to display the details of a single ocsp-response if an ID is given. The details displayed in this latter case are the ones shown by a "openssl ocsp -respin <ocsp-response> -text" call.
2021-06-10 07:51:13 -04:00
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
/* register cli keywords */
static struct cli_kw_list cli_kws = {{ },{
#if (defined SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB && TLS_TICKETS_NO > 0)
MINOR: ssl: Add "update ssl ocsp-response" cli command The new "update ssl ocsp-response <certfile>" CLI command allows to update the stored OCSP response for a given certificate. It relies on the http_client which is used to send an HTTP request to the OCSP responder whose URI can be extracted from the certificate. This command won't work for a certificate that did not have a stored OCSP response yet.
2022-12-20 05:11:07 -05:00
{ { "show", "tls-keys", NULL }, "show tls-keys [id|*] : show tls keys references or dump tls ticket keys when id specified", cli_parse_show_tlskeys, cli_io_handler_tlskeys_files },
{ { "set", "ssl", "tls-key", NULL }, "set ssl tls-key [id|file] <key> : set the next TLS key for the <id> or <file> listener to <key>", cli_parse_set_tlskeys, NULL },
#endif
MINOR: ssl: Add 'show ssl providers' cli command and providers list in -vv option Starting from OpenSSLv3, providers are at the core of cryptography functions. Depending on the provider used, the way the SSL functionalities work could change. This new 'show ssl providers' CLI command allows to show what providers were loaded by the SSL library. This is required because the provider configuration is exclusively done in the OpenSSL configuration file (/usr/local/ssl/openssl.cnf for instance). A new line is also added to the 'haproxy -vv' output containing the same information.
2022-04-21 06:06:41 -04:00
#ifdef HAVE_SSL_PROVIDERS
{ { "show", "ssl", "providers", NULL }, "show ssl providers : show loaded SSL providers", NULL, cli_io_handler_show_providers },
#endif
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
{ { NULL }, NULL, NULL, NULL }
}};
MEDIUM: init: convert all trivial registration calls to initcalls This switches explicit calls to various trivial registration methods for keywords, muxes or protocols from constructors to INITCALL1 at stage STG_REGISTER. All these calls have in common to consume a single pointer and return void. Doing this removes 26 constructors. The following calls were addressed : - acl_register_keywords - bind_register_keywords - cfg_register_keywords - cli_register_kw - flt_register_keywords - http_req_keywords_register - http_res_keywords_register - protocol_register - register_mux_proto - sample_register_convs - sample_register_fetches - srv_register_keywords - tcp_req_conn_keywords_register - tcp_req_cont_keywords_register - tcp_req_sess_keywords_register - tcp_res_cont_keywords_register - flt_register_keywords
2018-11-25 13:14:37 -05:00
INITCALL1(STG_REGISTER, cli_register_kw, &cli_kws);
REORG: cli: move ssl CLI functions to ssl_sock.c Move ssl CLI functions to ssl_sock.c and use the cli keyword API to register ssl actions on the CLI.
2016-10-29 12:09:35 -04:00
REORG: connection: rename the data layer the "transport layer" While working on the changes required to make the health checks use the new connections, it started to become obvious that some naming was not logical at all in the connections. Specifically, it is not logical to call the "data layer" the layer which is in charge for all the handshake and which does not yet provide a data layer once established until a session has allocated all the required buffers. In fact, it's more a transport layer, which makes much more sense. The transport layer offers a medium on which data can transit, and it offers the functions to move these data when the upper layer requests this. And it is the upper layer which iterates over the transport layer's functions to move data which should be called the data layer. The use case where it's obvious is with embryonic sessions : an incoming SSL connection is accepted. Only the connection is allocated, not the buffers nor stream interface, etc... The connection handles the SSL handshake by itself. Once this handshake is complete, we can't use the data functions because the buffers and stream interface are not there yet. Hence we have to first call a specific function to complete the session initialization, after which we'll be able to use the data functions. This clearly proves that SSL here is only a transport layer and that the stream interface constitutes the data layer. A similar change will be performed to rename app_cb => data, but the two could not be in the same commit for obvious reasons.
2012-10-02 18:19:48 -04:00
/* transport-layer operations for SSL sockets */
REORG: ssl: move ssl configuration to cfgparse-ssl.c Move all the configuration parsing of the ssl keywords in cfgparse-ssl.c
2020-05-14 11:47:32 -04:00
struct xprt_ops ssl_sock = {
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
.snd_buf = ssl_sock_from_buf,
.rcv_buf = ssl_sock_to_buf,
MEDIUM: ssl: provide its own subscribe/unsubscribe function. In order to prepare for the possibility of using different kinds of xprt with ssl, make the ssl code provide its own subscribe and unsubscribe functions, right now it just calls conn_subscribe and conn_unsubsribe.
2019-03-21 11:30:07 -04:00
.subscribe = ssl_subscribe,
.unsubscribe = ssl_unsubscribe,
MINOR: connections: Add a new xprt method, remove_xprt. Add a new method to xprt_ops, remove_xprt. When called, if the provided xprt_ctx is the same as the xprt's underlying xprt_ctx, it then uses the new xprt provided, otherwise it calls the remove_xprt method of the next xprt. The goal is to be able to add a temporary xprt, that removes itself from the chain when it did what it had to do. This will be used to implement a pseudo-xprt for anything that just requires a handshake (such as the proxy protocol).
2019-05-23 11:47:36 -04:00
.remove_xprt = ssl_remove_xprt,
MINOR: connections: Add a new xprt method, add_xprt(). Add a new method to xprt_ops, add_xprt(), that changes the underlying xprt to the one provided, and optionally provide the old one.
2019-05-27 13:50:12 -04:00
.add_xprt = ssl_add_xprt,
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
.rcv_pipe = NULL,
.snd_pipe = NULL,
.shutr = NULL,
.shutw = ssl_sock_shutw,
.close = ssl_sock_close,
.init = ssl_sock_init,
MEDIUM: connections: Implement a start() method in ssl_sock. Add a start() method to ssl_sock. It is responsible with initiating the SSL handshake, currently by just scheduling the tasklet, instead of doing it in the init() method, when all the XPRT may not have been initialized.
2021-03-05 17:47:00 -05:00
.start = ssl_sock_start,
MEDIUM: ssl_sock: implement ssl_sock_prepare_bind_conf() Instead of hard-coding all SSL preparation in cfgparse.c, we now register this new function as the transport layer's prepare_bind_conf() and call it only when definied. This removes some non-obvious SSL-specific code from cfgparse.c as well as a #ifdef.
2016-12-21 17:38:39 -05:00
.prepare_bind_conf = ssl_sock_prepare_bind_conf,
MINOR: ssl_sock: implement ssl_sock_destroy_bind_conf() Instead of hard-coding all SSL destruction in cfgparse.c and haproxy.c, we now register this new function as the transport layer's destroy_bind_conf() and call it only when defined. This removes some non-obvious SSL-specific code and #ifdefs from cfgparse.c and haproxy.c
2016-12-22 11:30:54 -05:00
.destroy_bind_conf = ssl_sock_destroy_bind_conf,
MINOR: ssl_sock: implement and use prepare_srv()/destroy_srv() Now we can simply check the transport layer at run time and decide whether or not to initialize or destroy these entries. This removes other ifdefs and includes from cfgparse.c, haproxy.c and hlua.c.
2016-12-22 15:16:08 -05:00
.prepare_srv = ssl_sock_prepare_srv_ctx,
.destroy_srv = ssl_sock_free_srv_ctx,
MINOR: ssl: add a get_alpn() method to ssl_sock This is used to retrieve the TLS ALPN information from a connection. We also support a fallback to NPN if ALPN doesn't find anything or is not available on the existing implementation. It happens that depending on the library version, either one or the other is available. NPN was present in openssl 1.0.1 (very common) while ALPN is in 1.0.2 and onwards (still uncommon at the time of writing). Clients are used to send either one or the other to ensure a smooth transition.
2016-12-04 12:44:29 -05:00
.get_alpn = ssl_sock_get_alpn,
BUG/MEDIUM: connections: Let the xprt layer know a takeover happened. When we takeover a connection, let the xprt layer know. If it has its own tasklet, and it is already scheduled, then it has to be destroyed, otherwise it may run the new mux tasklet on the old thread. Note that we only do this for the ssl xprt for now, because the only other one that might wake the mux up is the handshake one, which is supposed to disappear before idle connections exist. No backport is needed, this is for 2.2.
2020-07-03 08:01:21 -04:00
.takeover = ssl_takeover,
MEDIUM: ssl: implement xprt_set_used and xprt_set_idle to relax context checks Currently the SSL layer checks the validity of its tasklet's context just in case it would have been stolen, had the connection been idle. Now it will be able to be notified by the mux when this situation happens so as not to have to grab the idle connection lock on each pass. This reuses the TASK_F_USR1 flag just as the muxes do.
2021-03-02 11:29:56 -05:00
.set_idle = ssl_set_idle,
.set_used = ssl_set_used,
MEDIUM: ssl: improve retrieval of ssl_sock_ctx and SSL detection Historically there was a single way to have an SSL transport on a connection, so detecting if the transport layer was SSL and a context was present was sufficient to detect SSL. With QUIC, things have changed because QUIC also relies on SSL, but the context is embedded inside the quic_conn and the transport layer doesn't match expectations outside, making it difficult to detect that SSL is in use over the connection. The approach taken here to improve this consists in adding a new method at the transport layer, get_ssl_sock_ctx(), to retrieve this often needed ssl_sock_ctx, and to use this to detect the presence of SSL. This will even allow some simplifications and cleanups to be made in the SSL code itself, and QUIC will be able to provide one to export its ssl_sock_ctx.
2022-04-11 04:43:28 -04:00
.get_ssl_sock_ctx = ssl_sock_get_ctx,
MINOR: connection: add names for transport and data layers This makes debugging easier and avoids having to put ugly checks against certain well-known internal struct pointers.
2016-11-24 10:58:12 -05:00
.name = "SSL",
MINOR: ssl: provide a "show fd" helper to report important SSL information The SSL context contains a lot of important details that are currently missing from debug outputs. Now that we detect ssl_sock, we can perform some sanity checks, print the next xprt, the subscriber callback's context, handler and number of calls. The process function is also resolved. This now gives for example on an H2 connection: 1029 : st=0x21(R:rA W:Ra) ev=0x01(heopI) [lc] tmask=0x2 umask=0x2 owner=0x7fc714881700 iocb=0x65b528(sock_conn_iocb) back=0 cflg=0x00001300 fe=recv mux=H2 ctx=0x7fc734545e50 h2c.st0=FRH .err=0 .maxid=217 .lastid=-1 .flg=0x0000 .nbst=0 .nbcs=0 .fctl_cnt=0 .send_cnt=0 .tree_cnt=0 .orph_cnt=0 .sub=1 .dsi=217 .dbuf=0@(nil)+0/0 .msi=-1 .mbuf=[1..1|32],h=[0@(nil)+0/0],t=[0@(nil)+0/0] xprt=SSL xprt_ctx=0x7fc73478f230 xctx.st=0 .xprt=RAW .wait.ev=1 .subs=0x7fc734546350(ev=1 tl=0x7fc7346702e0 tl.calls=278 tl.ctx=0x7fc734545e50 tl.fct=main-0x144efa) .sent_early=0 .early_in=0
2021-01-20 08:41:29 -05:00
.show_fd = ssl_sock_show_fd,
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
};
MINOR: ssl/proto_http: Add keywords to take care of early data. Add a new sample fetch, "ssl_fc_has_early", a boolean that will be true if early data were sent, and a new action, "wait-for-handshake", if used, the request won't be forwarded until the SSL handshake is done.
2017-10-02 05:51:03 -04:00
enum act_return ssl_action_wait_for_hs(struct act_rule *rule, struct proxy *px,
struct session *sess, struct stream *s, int flags)
{
struct connection *conn;
conn = objt_conn(sess->origin);
CLEANUP: sslsock: remove only occurrence of local variable "cs" In ssl_action_wait_for_hs() the local variables called "cs" is just a copy of s->scf that's only used once, so it can be removed. In addition the check was removed as well since it's not possible to have a NULL SC on a stream.
2022-05-27 04:44:39 -04:00
if (conn) {
MINOR: ssl/proto_http: Add keywords to take care of early data. Add a new sample fetch, "ssl_fc_has_early", a boolean that will be true if early data were sent, and a new action, "wait-for-handshake", if used, the request won't be forwarded until the SSL handshake is done.
2017-10-02 05:51:03 -04:00
if (conn->flags & (CO_FL_EARLY_SSL_HS | CO_FL_SSL_WAIT_HS)) {
CLEANUP: sslsock: remove only occurrence of local variable "cs" In ssl_action_wait_for_hs() the local variables called "cs" is just a copy of s->scf that's only used once, so it can be removed. In addition the check was removed as well since it's not possible to have a NULL SC on a stream.
2022-05-27 04:44:39 -04:00
sc_ep_set(s->scf, SE_FL_WAIT_FOR_HS);
REORG: channel: Rename CF_READ_NULL to CF_READ_EVENT CF_READ_NULL flag is not really useful and used. It is a transient event used to wakeup the stream. As we will see, all read events on a channel may be resumed to only one and are all used to wake up the stream. In this patch, we introduce CF_READ_EVENT flag as a replacement to CF_READ_NULL. There is no breaking change for now, it is just a rename. Gradually, other read events will be merged with this one.
2022-12-12 02:08:15 -05:00
s->req.flags |= CF_READ_EVENT;
MINOR: ssl/proto_http: Add keywords to take care of early data. Add a new sample fetch, "ssl_fc_has_early", a boolean that will be true if early data were sent, and a new action, "wait-for-handshake", if used, the request won't be forwarded until the SSL handshake is done.
2017-10-02 05:51:03 -04:00
return ACT_RET_YIELD;
}
}
return (ACT_RET_CONT);
}
static enum act_parse_ret ssl_parse_wait_for_hs(const char **args, int *orig_arg, struct proxy *px, struct act_rule *rule, char **err)
{
rule->action_ptr = ssl_action_wait_for_hs;
return ACT_RET_PRS_OK;
}
static struct action_kw_list http_req_actions = {ILH, {
{ "wait-for-handshake", ssl_parse_wait_for_hs },
{ /* END */ }
}};
MEDIUM: init: convert all trivial registration calls to initcalls This switches explicit calls to various trivial registration methods for keywords, muxes or protocols from constructors to INITCALL1 at stage STG_REGISTER. All these calls have in common to consume a single pointer and return void. Doing this removes 26 constructors. The following calls were addressed : - acl_register_keywords - bind_register_keywords - cfg_register_keywords - cli_register_kw - flt_register_keywords - http_req_keywords_register - http_res_keywords_register - protocol_register - register_mux_proto - sample_register_convs - sample_register_fetches - srv_register_keywords - tcp_req_conn_keywords_register - tcp_req_cont_keywords_register - tcp_req_sess_keywords_register - tcp_res_cont_keywords_register - flt_register_keywords
2018-11-25 13:14:37 -05:00
INITCALL1(STG_REGISTER, http_req_keywords_register, &http_req_actions);
BUILD: ssl: guard SSL_CTX_add_server_custom_ext with special macro special guard macros HAVE_SSL_CTX_ADD_SERVER_CUSTOM_EXT was defined earlier exactly for guarding SSL_CTX_add_server_custom_ext, let us use it wherever appropriate
2021-02-06 08:59:22 -05:00
#ifdef HAVE_SSL_CTX_ADD_SERVER_CUSTOM_EXT
MEDIUM: ssl: Certificate Transparency support Adds ability to include Signed Certificate Timestamp List in TLS extension. File containing SCTL must be present at the same path of the certificate file, suffixed with '.sctl'. This requires OpenSSL 1.0.2 or later.
2015-03-07 17:03:59 -05:00
static void ssl_sock_sctl_free_func(void *parent, void *ptr, CRYPTO_EX_DATA *ad, int idx, long argl, void *argp)
{
if (ptr) {
chunk_destroy(ptr);
free(ptr);
}
}
#endif
BUG/MEDIUM: ssl: memory leak of ocsp data at SSL_CTX_free() This bug affects all version of HAProxy since the OCSP data is not free in the deinit(), but leaking on exit() is not really an issue. However, when doing dynamic update of certificates over the CLI, those data are not free'd upon the free of the SSL_CTX. 3 leaks are happening, the first leak is the one of the ocsp_arg structure which serves the purpose of containing the pointers in the case of a multi-certificate bundle. The second leak is the one ocsp struct. And the third leak is the one of the struct buffer in the ocsp_struct. The problem lies with SSL_CTX_set_tlsext_status_arg() which does not provide a way to free the argument upon an SSL_CTX_free(). This fix uses ex index functions instead of registering a tlsext_status_arg(). This is really convenient because it allows to register a free callback which will free the ex index content upon a SSL_CTX_free(). A refcount was also added to the ocsp_response structure since it is stored in a tree and can be reused in another SSL_CTX. Should fix part of the issue #746. This must be backported in 2.2 and 2.1.
2020-08-04 11:41:39 -04:00
BUG/MINOR: ssl: fix cipherlist captures with sustainable SSL calls Use SSL_set_ex_data/SSL_get_ex_data standard API call to store capture. We need to avoid internal structures/undocumented calls usage to try to control the beast and limit painful compatibilities.
2017-03-07 12:34:58 -05:00
static void ssl_sock_capture_free_func(void *parent, void *ptr, CRYPTO_EX_DATA *ad, int idx, long argl, void *argp)
{
CLEANUP: pools: rename all pool functions and pointers to remove this "2" During the migration to the second version of the pools, the new functions and pool pointers were all called "pool_something2()" and "pool2_something". Now there's no more pool v1 code and it's a real pain to still have to deal with this. Let's clean this up now by removing the "2" everywhere, and by renaming the pool heads "pool_head_something".
2017-11-24 11:34:44 -05:00
pool_free(pool_head_ssl_capture, ptr);
BUG/MINOR: ssl: fix cipherlist captures with sustainable SSL calls Use SSL_set_ex_data/SSL_get_ex_data standard API call to store capture. We need to avoid internal structures/undocumented calls usage to try to control the beast and limit painful compatibilities.
2017-03-07 12:34:58 -05:00
}
MEDIUM: ssl: Certificate Transparency support Adds ability to include Signed Certificate Timestamp List in TLS extension. File containing SCTL must be present at the same path of the certificate file, suffixed with '.sctl'. This requires OpenSSL 1.0.2 or later.
2015-03-07 17:03:59 -05:00
BUILD: make tune.ssl.keylog available again Since commit 04a5a44 ("BUILD: ssl: use HAVE_OPENSSL_KEYLOG instead of OpenSSL versions") the "tune.ssl.keylog" feature is broken because HAVE_OPENSSL_KEYLOG does not exist. Replace this by a HAVE_SSL_KEYLOG which is defined in openssl-compat.h. Also add an error when not built with the right openssl version. Must be backported as far as 2.3.
2021-06-09 10:46:12 -04:00
#ifdef HAVE_SSL_KEYLOG
WIP/MINOR: ssl: add sample fetches for keylog in frontend OpenSSL 1.1.1 provides a callback registering function SSL_CTX_set_keylog_callback, which allows one to receive a string containing the keys to deciphers TLSv1.3. Unfortunately it is not possible to store this data in binary form and we can only get this information using the callback. Which means that we need to store it until the connection is closed. This patches add 2 pools, the first one, pool_head_ssl_keylog is used to store a struct ssl_keylog which will be inserted as a ex_data in a SSL *. The second one is pool_head_ssl_keylog_str which will be used to store the hexadecimal strings. To enable the capture of the keys, you need to set "tune.ssl.keylog on" in your configuration. The following fetches were implemented: ssl_fc_client_early_traffic_secret, ssl_fc_client_handshake_traffic_secret, ssl_fc_server_handshake_traffic_secret, ssl_fc_client_traffic_secret_0, ssl_fc_server_traffic_secret_0, ssl_fc_exporter_secret, ssl_fc_early_exporter_secret
2020-07-06 05:41:30 -04:00
static void ssl_sock_keylog_free_func(void *parent, void *ptr, CRYPTO_EX_DATA *ad, int idx, long argl, void *argp)
{
struct ssl_keylog *keylog;
if (!ptr)
return;
keylog = ptr;
pool_free(pool_head_ssl_keylog_str, keylog->client_random);
pool_free(pool_head_ssl_keylog_str, keylog->client_early_traffic_secret);
pool_free(pool_head_ssl_keylog_str, keylog->client_handshake_traffic_secret);
pool_free(pool_head_ssl_keylog_str, keylog->server_handshake_traffic_secret);
pool_free(pool_head_ssl_keylog_str, keylog->client_traffic_secret_0);
pool_free(pool_head_ssl_keylog_str, keylog->server_traffic_secret_0);
pool_free(pool_head_ssl_keylog_str, keylog->exporter_secret);
pool_free(pool_head_ssl_keylog_str, keylog->early_exporter_secret);
pool_free(pool_head_ssl_keylog, ptr);
}
#endif
MEDIUM: ssl: Keep a reference to the client's certificate for use in logs Most of the SSL sample fetches related to the client certificate were based on the SSL_get_peer_certificate function which returns NULL when the verification process failed. This made it impossible to use those fetches in a log format since they would always be empty. The patch adds a reference to the X509 object representing the client certificate in the SSL structure and makes use of this reference in the fetches. The reference can only be obtained in ssl_sock_bind_verifycbk which means that in case of an SSL error occurring before the verification process ("no shared cipher" for instance, which happens while processing the Client Hello), we won't ever start the verification process and it will be impossible to get information about the client certificate. This patch also allows most of the ssl_c_XXX fetches to return a usable value in case of connection failure (because of a verification error for instance) by making the "conn->flags & CO_FL_WAIT_XPRT" test (which requires a connection to be established) less strict. Thanks to this patch, a log-format such as the following should return usable information in case of an error occurring during the verification process : log-format "DN=%{+Q}[ssl_c_s_dn] serial=%[ssl_c_serial,hex] \ hash=%[ssl_c_sha1,hex]" It should answer to GitHub issue #693.
2021-08-19 12:06:30 -04:00
static void ssl_sock_clt_crt_free_func(void *parent, void *ptr, CRYPTO_EX_DATA *ad, int idx, long argl, void *argp)
{
if (!ptr)
return;
X509_free((X509*)ptr);
}
BUG/MINOR: ssl: Store client SNI in SSL context in case of ClientHello error If an error is raised during the ClientHello callback on the server side (ssl_sock_switchctx_cbk), the servername callback won't be called and the client's SNI will not be saved in the SSL context. But since we use the SSL_get_servername function to return this SNI in the ssl_fc_sni sample fetch, that means that in case of error, such as an SNI mismatch with a frontend having the strict-sni option enabled, the sample fetch would not work (making strict-sni related errors hard to debug). This patch fixes that by storing the SNI as an ex_data in the SSL context in case the ClientHello callback returns an error. This way the sample fetch can fallback to getting the SNI this way. It will still first call the SSL_get_servername function first since it is the proper way of getting a client's SNI when the handshake succeeded. In order to avoid memory allocations are runtime into this highly used runtime function, a new memory pool was created to store those client SNIs. Its entry size is set to 256 bytes since SNIs can't be longer than 255 characters. This fixes GitHub #1484. It can be backported in 2.5.
2022-01-07 11:12:01 -05:00
static void ssl_sock_clt_sni_free_func(void *parent, void *ptr, CRYPTO_EX_DATA *ad, int idx, long argl, void *argp)
{
pool_free(ssl_sock_client_sni_pool, ptr);
}
MEDIUM: ssl: move "server" keyword SSL options parsing to ssl_sock.c All SSL-specific "server" keywords are now processed in ssl_sock.c. At the moment, there is no more "not implemented" hint when SSL is disabled, but keywords could be added in server.c if needed.
2012-10-10 17:04:25 -04:00
static void __ssl_sock_init(void)
{
BUILD: ssl: fix latest LibreSSL reg-test error starting with OpenSSL 1.0.0 recommended way to disable compression is using SSL_OP_NO_COMPRESSION when creating context. manipulations with SSL_COMP_get_compression_methods, sk_SSL_COMP_num are only required for OpenSSL < 1.0.0
2019-05-25 10:30:50 -04:00
#if (!defined(OPENSSL_NO_COMP) && !defined(SSL_OP_NO_COMPRESSION))
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
STACK_OF(SSL_COMP)* cm;
BUG/MINOR: ssl_sock: Fix memory leak when disabling compression according to manpage: sk_TYPE_zero() sets the number of elements in sk to zero. It does not free sk so after this call sk is still valid. so we need to free all elements [wt: seems like it has been there forever and should be backported to all stable branches]
2019-05-24 18:38:14 -04:00
int n;
BUILD: ssl: fix latest LibreSSL reg-test error starting with OpenSSL 1.0.0 recommended way to disable compression is using SSL_OP_NO_COMPRESSION when creating context. manipulations with SSL_COMP_get_compression_methods, sk_SSL_COMP_num are only required for OpenSSL < 1.0.0
2019-05-25 10:30:50 -04:00
#endif
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
CLEANUP: ssl: move most ssl-specific global settings to ssl_sock.c Historically a lot of SSL global settings were stored into the global struct, but we've reached a point where there are 3 ifdefs in it just for this, and others in haproxy.c to initialize it. This patch moves all the private fields to a new struct "global_ssl" stored in ssl_sock.c. This includes : char *crt_base; char *ca_base; char *listen_default_ciphers; char *connect_default_ciphers; int listen_default_ssloptions; int connect_default_ssloptions; int tune.sslprivatecache; /* Force to use a private session cache even if nbproc > 1 */ unsigned int tune.ssllifetime; /* SSL session lifetime in seconds */ unsigned int tune.ssl_max_record; /* SSL max record size */ unsigned int tune.ssl_default_dh_param; /* SSL maximum DH parameter size */ int tune.ssl_ctx_cache; /* max number of entries in the ssl_ctx cache. */ The "tune" part was removed (useless here) and the occasional "ssl" prefixes were removed as well. Thus for example instead of global.tune.ssl_default_dh_param we now have : global_ssl.default_dh_param A few initializers were present in the constructor, they could be brought back to the structure declaration. A few other entries had to stay in global for now. They concern memory calculationn (used in haproxy.c) and stats (used in stats.c). The code is already much cleaner now, especially for global.h and haproxy.c which become readable.
2016-12-22 17:12:01 -05:00
if (global_ssl.listen_default_ciphers)
global_ssl.listen_default_ciphers = strdup(global_ssl.listen_default_ciphers);
if (global_ssl.connect_default_ciphers)
global_ssl.connect_default_ciphers = strdup(global_ssl.connect_default_ciphers);
BUILD: SSL: guard TLS13 ciphersuites with HAVE_SSL_CTX_SET_CIPHERSUITES HAVE_SSL_CTX_SET_CIPHERSUITES is newly defined macro set in openssl-compat.h, which helps to identify ssl libs (currently OpenSSL-1.1.1 only) that supports TLS13 cipersuites manipulation on TLS13 context
2020-11-21 04:37:34 -05:00
#ifdef HAVE_SSL_CTX_SET_CIPHERSUITES
MEDIUM: ssl: add support for ciphersuites option for TLSv1.3 OpenSSL released support for TLSv1.3. It also added a separate function SSL_CTX_set_ciphersuites that is used to set the ciphers used in the TLS 1.3 handshake. This change adds support for that new configuration option by adding a ciphersuites configuration variable that works essentially the same as the existing ciphers setting. Note that it should likely be backported to 1.8 in order to ease usage of the now released openssl-1.1.1.
2018-09-14 05:14:21 -04:00
if (global_ssl.listen_default_ciphersuites)
global_ssl.listen_default_ciphersuites = strdup(global_ssl.listen_default_ciphersuites);
if (global_ssl.connect_default_ciphersuites)
global_ssl.connect_default_ciphersuites = strdup(global_ssl.connect_default_ciphersuites);
#endif
MINOR: config: add global directives to set default SSL ciphers The ability to globally override the default client and server cipher suites has been requested multiple times since the introduction of SSL. This commit adds two new keywords to the global section for this : - ssl-default-bind-ciphers - ssl-default-server-ciphers It is still possible to preset them at build time by setting the macros LISTEN_DEFAULT_CIPHERS and CONNECT_DEFAULT_CIPHERS.
2014-02-13 05:36:41 -05:00
MINOR: connection: add a minimal transport layer registration system There are still a lot of #ifdef USE_OPENSSL in the code (still 43 occurences) because we never know if we can directly access ssl_sock or not. This patch attacks the problem differently by providing a way for transport layers to register themselves and for users to retrieve the pointer. Unregistered transport layers will point to NULL so it will be easy to check if SSL is registered or not. The mechanism is very inexpensive as it relies on a two-entries array of pointers, so the performance will not be affected.
2016-12-22 14:25:26 -05:00
xprt_register(XPRT_SSL, &ssl_sock);
CLEANUP: ssl-sock: use HA_OPENSSL_VERSION_NUMBER instead of OPENSSL_VERSION_NUMBER Most tests on OPENSSL_VERSION_NUMBER have become complex and break all the time because this number is fake for some derivatives like LibreSSL. This patch creates a new macro, HA_OPENSSL_VERSION_NUMBER, which will carry the real openssl version defining the compatibility level, and this version will be adjusted depending on the variants.
2019-05-09 07:26:41 -04:00
#if HA_OPENSSL_VERSION_NUMBER < 0x10100000L
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
SSL_library_init();
MEDIUM: ssl: initialize the SSL stack explicitely In issue #2448, users are complaining that FIPS is not working correctly since the removal of SSL_library_init(). This was removed because SSL_library_init() is deprecated with OpenSSL 3.x and emits a warning. But the initialization was not needed anymore because it is done at the first openssl API call. However it some cases it is needed. SSL_library_init() is now a define to OPENSSL_init_ssl(0, NULL). This patch adds OPENSSL_init_ssl(0, NULL) to the init. This could be backported in every stable branches, however let's wait before backporting it.
2024-03-12 07:03:07 -04:00
#elif HA_OPENSSL_VERSION_NUMBER >= 0x10100000L
OPENSSL_init_ssl(0, NULL);
BUILD: ssl: Fix compilation without deprecated OpenSSL 1.1 APIs Removing deprecated APIs is an optional part of OpenWrt's build system to save some space on embedded devices. Also added compatibility for LibreSSL. Signed-off-by: Rosen Penev <rosenp@gmail.com>
2018-12-14 11:47:02 -05:00
#endif
BUILD: ssl: fix latest LibreSSL reg-test error starting with OpenSSL 1.0.0 recommended way to disable compression is using SSL_OP_NO_COMPRESSION when creating context. manipulations with SSL_COMP_get_compression_methods, sk_SSL_COMP_num are only required for OpenSSL < 1.0.0
2019-05-25 10:30:50 -04:00
#if (!defined(OPENSSL_NO_COMP) && !defined(SSL_OP_NO_COMPRESSION))
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
cm = SSL_COMP_get_compression_methods();
BUG/MINOR: ssl_sock: Fix memory leak when disabling compression according to manpage: sk_TYPE_zero() sets the number of elements in sk to zero. It does not free sk so after this call sk is still valid. so we need to free all elements [wt: seems like it has been there forever and should be backported to all stable branches]
2019-05-24 18:38:14 -04:00
n = sk_SSL_COMP_num(cm);
while (n--) {
(void) sk_SSL_COMP_pop(cm);
}
BUILD: ssl: fix latest LibreSSL reg-test error starting with OpenSSL 1.0.0 recommended way to disable compression is using SSL_OP_NO_COMPRESSION when creating context. manipulations with SSL_COMP_get_compression_methods, sk_SSL_COMP_num are only required for OpenSSL < 1.0.0
2019-05-25 10:30:50 -04:00
#endif
BUG/MINOR: ssl_sock: Fix memory leak when disabling compression according to manpage: sk_TYPE_zero() sets the number of elements in sk to zero. It does not free sk so after this call sk is still valid. so we need to free all elements [wt: seems like it has been there forever and should be backported to all stable branches]
2019-05-24 18:38:14 -04:00
CLEANUP: ssl: remove 57 occurrences of useless tests on LIBRESSL_VERSION_NUMBER They were all check to comply with the advertised openssl version. Now that libressl doesn't pretend to be a more recent openssl anymore, we can simply rely on the regular openssl version tests without having to deal with exceptions for libressl.
2019-05-09 08:13:35 -04:00
#if defined(USE_THREAD) && (HA_OPENSSL_VERSION_NUMBER < 0x10100000L)
MAJOR: threads/ssl: Make SSL part thread-safe First, OpenSSL is now initialized to be thread-safe. This is done by setting 2 callbacks. The first one is ssl_locking_function. It handles the locks and unlocks. The second one is ssl_id_function. It returns the current thread id. During the init step, we create as much as R/W locks as needed, ie the number returned by CRYPTO_num_locks function. Next, The reusable SSL session in the server context is now thread-local. Shctx is now also initialized if HAProxy is started with several threads. And finally, a global lock has been added to protect the LRU cache used to store generated certificates. The function ssl_sock_get_generated_cert is now deprecated because the retrieved certificate can be removed by another threads in same time. Instead, a new function has been added, ssl_sock_assign_generated_cert. It must be used to search a certificate in the cache and set it immediatly if found.
2017-06-15 10:37:39 -04:00
ssl_locking_init();
#endif
BUILD: ssl: guard SSL_CTX_add_server_custom_ext with special macro special guard macros HAVE_SSL_CTX_ADD_SERVER_CUSTOM_EXT was defined earlier exactly for guarding SSL_CTX_add_server_custom_ext, let us use it wherever appropriate
2021-02-06 08:59:22 -05:00
#ifdef HAVE_SSL_CTX_ADD_SERVER_CUSTOM_EXT
MEDIUM: ssl: Certificate Transparency support Adds ability to include Signed Certificate Timestamp List in TLS extension. File containing SCTL must be present at the same path of the certificate file, suffixed with '.sctl'. This requires OpenSSL 1.0.2 or later.
2015-03-07 17:03:59 -05:00
sctl_ex_index = SSL_CTX_get_ex_new_index(0, NULL, NULL, NULL, ssl_sock_sctl_free_func);
#endif
BUG/MEDIUM: ssl: memory leak of ocsp data at SSL_CTX_free() This bug affects all version of HAProxy since the OCSP data is not free in the deinit(), but leaking on exit() is not really an issue. However, when doing dynamic update of certificates over the CLI, those data are not free'd upon the free of the SSL_CTX. 3 leaks are happening, the first leak is the one of the ocsp_arg structure which serves the purpose of containing the pointers in the case of a multi-certificate bundle. The second leak is the one ocsp struct. And the third leak is the one of the struct buffer in the ocsp_struct. The problem lies with SSL_CTX_set_tlsext_status_arg() which does not provide a way to free the argument upon an SSL_CTX_free(). This fix uses ex index functions instead of registering a tlsext_status_arg(). This is really convenient because it allows to register a free callback which will free the ex index content upon a SSL_CTX_free(). A refcount was also added to the ocsp_response structure since it is stored in a tree and can be reused in another SSL_CTX. Should fix part of the issue #746. This must be backported in 2.2 and 2.1.
2020-08-04 11:41:39 -04:00
#if ((defined SSL_CTRL_SET_TLSEXT_STATUS_REQ_CB && !defined OPENSSL_NO_OCSP) && !defined OPENSSL_IS_BORINGSSL)
ocsp_ex_index = SSL_CTX_get_ex_new_index(0, NULL, NULL, NULL, ssl_sock_ocsp_free_func);
#endif
BUG/MAJOR: ssl: OpenSSL context is stored in non-reserved memory slot We never saw unexplicated crash with SSL, so I suppose that we are luck, or the slot 0 is always reserved. Anyway the usage of the macro SSL_get_app_data() and SSL_set_app_data() seem wrong. This patch change the deprecated functions SSL_get_app_data() and SSL_set_app_data() by the new functions SSL_get_ex_data() and SSL_set_ex_data(), and it reserves the slot in the SSL memory space. For information, this is the two declaration which seems wrong or incomplete in the OpenSSL ssl.h file. We can see the usage of the slot 0 whoch is hardcoded, but never reserved. #define SSL_set_app_data(s,arg) (SSL_set_ex_data(s,0,(char *)arg)) #define SSL_get_app_data(s) (SSL_get_ex_data(s,0)) This patch must be backported at least in 1.8, maybe in other versions.
2018-06-17 15:37:05 -04:00
ssl_app_data_index = SSL_get_ex_new_index(0, NULL, NULL, NULL, NULL);
BUG/MAJOR: ssl: Random crash with cipherlist capture The cipher list capture struct is stored in the SSL memory space, but the slot is reserved in the SSL_CTX memory space. This causes ramdom crashes. This patch should be backported to 1.8
2018-06-17 15:33:01 -04:00
ssl_capture_ptr_index = SSL_get_ex_new_index(0, NULL, NULL, NULL, ssl_sock_capture_free_func);
MEDIUM: quic/ssl: add new ex data for quic_conn Allow to register quic_conn as ex-data in SSL callbacks. A new index is used to identify it as ssl_qc_app_data_index. Replace connection by quic_conn as SSL ex-data when initializing the QUIC SSL session. When using SSL callbacks in QUIC context, the connection is now NULL. Used quic_conn instead to retrieve the required parameters. Also clean up The same changes are conducted inside the QUIC SSL methods of xprt-quic : connection instance usage is replaced by quic_conn.
2022-01-19 04:03:30 -05:00
#ifdef USE_QUIC
ssl_qc_app_data_index = SSL_get_ex_new_index(0, NULL, NULL, NULL, NULL);
#endif /* USE_QUIC */
BUILD: make tune.ssl.keylog available again Since commit 04a5a44 ("BUILD: ssl: use HAVE_OPENSSL_KEYLOG instead of OpenSSL versions") the "tune.ssl.keylog" feature is broken because HAVE_OPENSSL_KEYLOG does not exist. Replace this by a HAVE_SSL_KEYLOG which is defined in openssl-compat.h. Also add an error when not built with the right openssl version. Must be backported as far as 2.3.
2021-06-09 10:46:12 -04:00
#ifdef HAVE_SSL_KEYLOG
WIP/MINOR: ssl: add sample fetches for keylog in frontend OpenSSL 1.1.1 provides a callback registering function SSL_CTX_set_keylog_callback, which allows one to receive a string containing the keys to deciphers TLSv1.3. Unfortunately it is not possible to store this data in binary form and we can only get this information using the callback. Which means that we need to store it until the connection is closed. This patches add 2 pools, the first one, pool_head_ssl_keylog is used to store a struct ssl_keylog which will be inserted as a ex_data in a SSL *. The second one is pool_head_ssl_keylog_str which will be used to store the hexadecimal strings. To enable the capture of the keys, you need to set "tune.ssl.keylog on" in your configuration. The following fetches were implemented: ssl_fc_client_early_traffic_secret, ssl_fc_client_handshake_traffic_secret, ssl_fc_server_handshake_traffic_secret, ssl_fc_client_traffic_secret_0, ssl_fc_server_traffic_secret_0, ssl_fc_exporter_secret, ssl_fc_early_exporter_secret
2020-07-06 05:41:30 -04:00
ssl_keylog_index = SSL_get_ex_new_index(0, NULL, NULL, NULL, ssl_sock_keylog_free_func);
#endif
MEDIUM: ssl: Keep a reference to the client's certificate for use in logs Most of the SSL sample fetches related to the client certificate were based on the SSL_get_peer_certificate function which returns NULL when the verification process failed. This made it impossible to use those fetches in a log format since they would always be empty. The patch adds a reference to the X509 object representing the client certificate in the SSL structure and makes use of this reference in the fetches. The reference can only be obtained in ssl_sock_bind_verifycbk which means that in case of an SSL error occurring before the verification process ("no shared cipher" for instance, which happens while processing the Client Hello), we won't ever start the verification process and it will be impossible to get information about the client certificate. This patch also allows most of the ssl_c_XXX fetches to return a usable value in case of connection failure (because of a verification error for instance) by making the "conn->flags & CO_FL_WAIT_XPRT" test (which requires a connection to be established) less strict. Thanks to this patch, a log-format such as the following should return usable information in case of an error occurring during the verification process : log-format "DN=%{+Q}[ssl_c_s_dn] serial=%[ssl_c_serial,hex] \ hash=%[ssl_c_sha1,hex]" It should answer to GitHub issue #693.
2021-08-19 12:06:30 -04:00
ssl_client_crt_ref_index = SSL_get_ex_new_index(0, NULL, NULL, NULL, ssl_sock_clt_crt_free_func);
BUG/MINOR: ssl: Store client SNI in SSL context in case of ClientHello error If an error is raised during the ClientHello callback on the server side (ssl_sock_switchctx_cbk), the servername callback won't be called and the client's SNI will not be saved in the SSL context. But since we use the SSL_get_servername function to return this SNI in the ssl_fc_sni sample fetch, that means that in case of error, such as an SNI mismatch with a frontend having the strict-sni option enabled, the sample fetch would not work (making strict-sni related errors hard to debug). This patch fixes that by storing the SNI as an ex_data in the SSL context in case the ClientHello callback returns an error. This way the sample fetch can fallback to getting the SNI this way. It will still first call the SSL_get_servername function first since it is the proper way of getting a client's SNI when the handshake succeeded. In order to avoid memory allocations are runtime into this highly used runtime function, a new memory pool was created to store those client SNIs. Its entry size is set to 256 bytes since SNIs can't be longer than 255 characters. This fixes GitHub #1484. It can be backported in 2.5.
2022-01-07 11:12:01 -05:00
ssl_client_sni_index = SSL_get_ex_new_index(0, NULL, NULL, NULL, ssl_sock_clt_sni_free_func);
BUILD: ssl: add USE_ENGINE and disable the openssl engine by default The OpenSSL engine API is deprecated starting with OpenSSL 3.0. In order to have a clean build this feature is now disabled by default. It can be reactivated with USE_ENGINE=1 on the build line.
2022-04-11 12:41:24 -04:00
#if defined(USE_ENGINE) && !defined(OPENSSL_NO_ENGINE)
MEDIUM: ssl: add basic support for OpenSSL crypto engine This patch adds the global 'ssl-engine' keyword. First arg is an engine identifier followed by a list of default_algorithms the engine will operate. If the openssl version is too old, an error is reported when the option is used.
2017-01-20 20:10:18 -05:00
ENGINE_load_builtin_engines();
MAJOR: ssl: add openssl async mode support ssl-mode-async is a global configuration parameter which enables asynchronous processing in OPENSSL for all SSL connections haproxy handles. With SSL_MODE_ASYNC set, TLS I/O operations may indicate a retry with SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable engine is used to perform cryptographic operations. Currently async mode only supports one async-capable engine. This is the latest version of the patchset which includes Emeric's updates : - improved async fd cleaning when openssl reports an fd to delete - prevent conn_fd_handler from calling SSL_{read,write,handshake} until the async fd is ready, as these operations are very slow and waste CPU - postpone of SSL_free to ensure the async operation can complete and does not cause a dereference a released SSL. - proper removal of async fd from the fdtab and removal of the unused async flag.
2017-01-13 20:42:15 -05:00
hap_register_post_check(ssl_check_async_engine_count);
BUILD: ssl: fix build with OPENSSL_NO_ENGINE Build is broken with openssl library without support of engin (like boringssl). Add OPENSSL_NO_ENGINE flag to fix that.
2017-05-29 08:36:20 -04:00
#endif
CLEANUP: ssl: move tlskeys_finalize_config() to a post_check callback tlskeys_finalize_config() was the only reason for haproxy.c to still require ifdef and includes for ssl_sock. This one fits perfectly well in the late initializers so it was changed to be registered with hap_register_post_check().
2016-12-22 16:46:15 -05:00
#if (defined SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB && TLS_TICKETS_NO > 0)
hap_register_post_check(tlskeys_finalize_config);
#endif
MINOR: global: report information about the cost of SSL connections An SSL connection takes some memory when it exists and during handshakes. We measured up to 16kB for an established endpoint, and up to 76 extra kB during a handshake. The SSL layer stores these values into the global struct during initialization. If other SSL libs are used, it's easy to change these values. Anyway they'll only be used as gross estimates in order to guess the max number of SSL conns that can be established when memory is constrained and the limit is not set.
2015-01-15 15:34:39 -05:00
MINOR: initcall: apply initcall to all register_build_opts() calls Most register_build_opts() calls use static strings. These ones were replaced with a trivial REGISTER_BUILD_OPTS() statement adding the string and its call to the STG_REGISTER section. A dedicated section could be made for this if needed, but there are very few such calls for this to be worth it. The calls made with computed strings however, like those which retrieve OpenSSL's version or zlib's version, were moved to a dedicated function to guarantee they are called late in the process. For example, the SSL call probably requires that SSL_library_init() has been called first.
2018-11-26 04:19:54 -05:00
global.ssl_session_max_cost = SSL_SESSION_MAX_COST;
global.ssl_handshake_max_cost = SSL_HANDSHAKE_MAX_COST;
MINOR: ssl: add "issuers-chain-path" directive. Certificates loaded with "crt" and "crt-list" commonly share the same intermediate certificate in PEM file. "issuers-chain-path" is a global directive to share intermediate chain certificates in a directory. If certificates chain is not included in certificate PEM file, haproxy will complete chain if issuer match the first certificate of the chain stored via "issuers-chain-path" directive. Such chains will be shared in memory.
2019-01-04 05:08:20 -05:00
hap_register_post_deinit(ssl_free_global_issuers);
MINOR: initcall: apply initcall to all register_build_opts() calls Most register_build_opts() calls use static strings. These ones were replaced with a trivial REGISTER_BUILD_OPTS() statement adding the string and its call to the STG_REGISTER section. A dedicated section could be made for this if needed, but there are very few such calls for this to be worth it. The calls made with computed strings however, like those which retrieve OpenSSL's version or zlib's version, were moved to a dedicated function to guarantee they are called late in the process. For example, the SSL call probably requires that SSL_library_init() has been called first.
2018-11-26 04:19:54 -05:00
#ifndef OPENSSL_NO_DH
ssl_dh_ptr_index = SSL_CTX_get_ex_new_index(0, NULL, NULL, NULL, NULL);
hap_register_post_deinit(ssl_free_dh);
#endif
BUILD: ssl: add USE_ENGINE and disable the openssl engine by default The OpenSSL engine API is deprecated starting with OpenSSL 3.0. In order to have a clean build this feature is now disabled by default. It can be reactivated with USE_ENGINE=1 on the build line.
2022-04-11 12:41:24 -04:00
#if defined(USE_ENGINE) && !defined(OPENSSL_NO_ENGINE)
MINOR: initcall: apply initcall to all register_build_opts() calls Most register_build_opts() calls use static strings. These ones were replaced with a trivial REGISTER_BUILD_OPTS() statement adding the string and its call to the STG_REGISTER section. A dedicated section could be made for this if needed, but there are very few such calls for this to be worth it. The calls made with computed strings however, like those which retrieve OpenSSL's version or zlib's version, were moved to a dedicated function to guarantee they are called late in the process. For example, the SSL call probably requires that SSL_library_init() has been called first.
2018-11-26 04:19:54 -05:00
hap_register_post_deinit(ssl_free_engines);
#endif
MINOR: ssl: Add 'ssl-provider' global option When HAProxy is linked to an OpenSSLv3 library, this option can be used to load a provider during init. You can specify multiple ssl-provider options, which will be loaded in the order they appear. This does not prevent OpenSSL from parsing its own configuration file in which some other providers might be specified. A linked list of the providers loaded from the configuration file is kept so that all those providers can be unloaded during cleanup. The providers loaded directly by OpenSSL will be freed by OpenSSL.
2022-05-16 10:24:33 -04:00
#ifdef HAVE_SSL_PROVIDERS
hap_register_post_deinit(ssl_unload_providers);
#endif
MINOR: ssl: Remove call to ERR_load_SSL_strings with OpenSSLv3 Starting from OpenSSLv3, error strings are loaded automatically so ERR_load_SSL_strings is not needed anymore and was marked as deprecated.
2022-02-11 06:04:45 -05:00
#if HA_OPENSSL_VERSION_NUMBER < 0x3000000fL
MINOR: initcall: apply initcall to all register_build_opts() calls Most register_build_opts() calls use static strings. These ones were replaced with a trivial REGISTER_BUILD_OPTS() statement adding the string and its call to the STG_REGISTER section. A dedicated section could be made for this if needed, but there are very few such calls for this to be worth it. The calls made with computed strings however, like those which retrieve OpenSSL's version or zlib's version, were moved to a dedicated function to guarantee they are called late in the process. For example, the SSL call probably requires that SSL_library_init() has been called first.
2018-11-26 04:19:54 -05:00
/* Load SSL string for the verbose & debug mode. */
ERR_load_SSL_strings();
MINOR: ssl: Remove call to ERR_load_SSL_strings with OpenSSLv3 Starting from OpenSSLv3, error strings are loaded automatically so ERR_load_SSL_strings is not needed anymore and was marked as deprecated.
2022-02-11 06:04:45 -05:00
#endif
MEDIUM: ssl: provide our own BIO. Instead of letting the OpenSSL code handle the file descriptor directly, provide a custom BIO, that will use the underlying XPRT to send/recv data. This will let us implement QUIC later, and probably clean the upper layer, if/when the SSL code provide its own subscribe code, so that the upper layers won't have to care if we're still waiting for the handshake to complete or not.
2019-04-07 16:00:38 -04:00
ha_meth = BIO_meth_new(0x666, "ha methods");
BUG/MINOR: ssl_sock: add check for ha_meth in __ssl_sock_init, BIO_meth_new may failed and return NULL if OPENSSL_zalloc failed. in this case, ha_meth will be NULL, and then crash happens in BIO_meth_set_write. So, we add a check for ha_meth.
2023-05-26 04:42:47 -04:00
if (ha_meth != NULL) {
BIO_meth_set_write(ha_meth, ha_ssl_write);
BIO_meth_set_read(ha_meth, ha_ssl_read);
BIO_meth_set_ctrl(ha_meth, ha_ssl_ctrl);
BIO_meth_set_create(ha_meth, ha_ssl_new);
BIO_meth_set_destroy(ha_meth, ha_ssl_free);
BIO_meth_set_puts(ha_meth, ha_ssl_puts);
BIO_meth_set_gets(ha_meth, ha_ssl_gets);
}
MEDIUM: ssl/cli: 'set ssl cert' updates a certificate from the CLI $ echo -e "set ssl cert certificate.pem <<\n$(cat certificate2.pem)\n" | \ socat stdio /var/run/haproxy.stat Certificate updated! The operation is locked at the ckch level with a HA_SPINLOCK_T which prevents the ckch architecture (ckch_store, ckch_inst..) to be modified at the same time. So you can't do a certificate update at the same time from multiple CLI connections. SNI trees are also locked with a HA_RWLOCK_T so reading operations are locked only during a certificate update. Bundles are supported but you need to update each file (.rsa|ecdsa|.dsa) independently. If a file is used in the configuration as a bundle AND as a unique certificate, both will be updated. Bundles, directories and crt-list are supported, however filters in crt-list are currently unsupported. The code tries to allocate every SNIs and certificate instances first, so it can rollback the operation if that was unsuccessful. If you have too much instances of the certificate (at least 20000 in my tests on my laptop), the function can take too much time and be killed by the watchdog. This will be fixed later. Also with too much certificates it's possible that socat exits before the end of the generation without displaying a message, consider changing the socat timeout in this case (-t2 for example). The size of the certificate is currently limited by the maximum size of a payload, that must fit in a buffer.
2019-09-19 11:12:49 -04:00
HA_SPIN_INIT(&ckch_lock);
MEDIUM: ssl: allow to register callbacks for SSL/TLS protocol messages This patch adds the ability to register callbacks for SSL/TLS protocol messages by using the function ssl_sock_register_msg_callback(). All registered callback functions will be called when observing received or sent SSL/TLS protocol messages.
2020-05-08 12:30:00 -04:00
MINOR: ssl: Add a lock to the OCSP response tree The tree that contains OCSP responses is never locked despite being used at runtime for OCSP stapling as well as the CLI through "set ssl cert" and "set ssl ocsp-response" commands. Everything works though because the certificate_ocsp structure is refcounted and the tree's entries are cleaned up when SSL_CTXs are destroyed (thanks to an ex_data entry in which the certificate_ocsp pointer is stored). This new lock will come to use when the OCSP auto update mechanism is fully implemented because this new feature will be based on another tree that stores the same certificate_ocsp members and updates their contents periodically.
2022-12-20 05:11:02 -05:00
HA_SPIN_INIT(&ocsp_tree_lock);
MEDIUM: ssl: split ssl_sock_msgcbk() and use a new callback mechanism Make use of ssl_sock_register_msg_callback(). Function ssl_sock_msgcbk() is now split into two dedicated functions for heartbeat and clienthello. They are both registered by using a new callback mechanism for SSL/TLS protocol messages.
2020-05-11 09:51:45 -04:00
/* Try to register dedicated SSL/TLS protocol message callbacks for
* heartbleed attack (CVE-2014-0160) and clienthello.
*/
hap_register_post_check(ssl_sock_register_msg_callbacks);
MEDIUM: ssl: allow to register callbacks for SSL/TLS protocol messages This patch adds the ability to register callbacks for SSL/TLS protocol messages by using the function ssl_sock_register_msg_callback(). All registered callback functions will be called when observing received or sent SSL/TLS protocol messages.
2020-05-08 12:30:00 -04:00
/* Try to free all callbacks that were registered by using
* ssl_sock_register_msg_callback().
*/
hap_register_post_deinit(ssl_sock_unregister_msg_callbacks);
MINOR: initcall: apply initcall to all register_build_opts() calls Most register_build_opts() calls use static strings. These ones were replaced with a trivial REGISTER_BUILD_OPTS() statement adding the string and its call to the STG_REGISTER section. A dedicated section could be made for this if needed, but there are very few such calls for this to be worth it. The calls made with computed strings however, like those which retrieve OpenSSL's version or zlib's version, were moved to a dedicated function to guarantee they are called late in the process. For example, the SSL call probably requires that SSL_library_init() has been called first.
2018-11-26 04:19:54 -05:00
}
BUILD: xprt: use an initcall to register the transport layers Transport layers (raw_sock, ssl_sock, xprt_handshake and xprt_quic) were using 4 constructors and 2 destructors. The 4 constructors were replaced with INITCALL and the destructors with REGISTER_POST_DEINIT() so that we do not depend on this anymore.
2022-04-25 13:18:24 -04:00
INITCALL0(STG_REGISTER, __ssl_sock_init);
MINOR: initcall: apply initcall to all register_build_opts() calls Most register_build_opts() calls use static strings. These ones were replaced with a trivial REGISTER_BUILD_OPTS() statement adding the string and its call to the STG_REGISTER section. A dedicated section could be made for this if needed, but there are very few such calls for this to be worth it. The calls made with computed strings however, like those which retrieve OpenSSL's version or zlib's version, were moved to a dedicated function to guarantee they are called late in the process. For example, the SSL call probably requires that SSL_library_init() has been called first.
2018-11-26 04:19:54 -05:00
/* Compute and register the version string */
static void ssl_register_build_options()
{
char *ptr = NULL;
int i;
CLEANUP: ssl: use the build options list to report the SSL details This removes 7 #ifdef from haproxy.c. The message indicating that openssl is *not* enabled is not there anymore.
2016-12-21 13:23:20 -05:00
memprintf(&ptr, "Built with OpenSSL version : "
#ifdef OPENSSL_IS_BORINGSSL
MINOR: ssl: show methods supported by openssl TLS v1.3 incoming, SSLv3 will disappears: it could be useful to list all methods supported by haproxy/openssl (with -vvv).
2017-03-24 10:20:03 -04:00
"BoringSSL");
CLEANUP: ssl: use the build options list to report the SSL details This removes 7 #ifdef from haproxy.c. The message indicating that openssl is *not* enabled is not there anymore.
2016-12-21 13:23:20 -05:00
#else /* OPENSSL_IS_BORINGSSL */
OPENSSL_VERSION_TEXT
"\nRunning on OpenSSL version : %s%s",
BUILD: ssl: Fix compilation without deprecated OpenSSL 1.1 APIs Removing deprecated APIs is an optional part of OpenWrt's build system to save some space on embedded devices. Also added compatibility for LibreSSL. Signed-off-by: Rosen Penev <rosenp@gmail.com>
2018-12-14 11:47:02 -05:00
OpenSSL_version(OPENSSL_VERSION),
BUILD: ssl: make libressl use its own version numbers LibreSSL causes lots of build issues by pretending to be OpenSSL 2.0.0, and it requires lots of care for each #if added to cover any specific OpenSSL features. This commit addresses the problem by making LibreSSL only advertise the version it forked from (1.0.1g) and by starting to use tests based on its real version to enable features instead of working by exclusion.
2019-05-09 07:41:45 -04:00
((OPENSSL_VERSION_NUMBER ^ OpenSSL_version_num()) >> 8) ? " (VERSIONS DIFFER!)" : "");
CLEANUP: ssl: use the build options list to report the SSL details This removes 7 #ifdef from haproxy.c. The message indicating that openssl is *not* enabled is not there anymore.
2016-12-21 13:23:20 -05:00
#endif
memprintf(&ptr, "%s\nOpenSSL library supports TLS extensions : "
CLEANUP: ssl-sock: use HA_OPENSSL_VERSION_NUMBER instead of OPENSSL_VERSION_NUMBER Most tests on OPENSSL_VERSION_NUMBER have become complex and break all the time because this number is fake for some derivatives like LibreSSL. This patch creates a new macro, HA_OPENSSL_VERSION_NUMBER, which will carry the real openssl version defining the compatibility level, and this version will be adjusted depending on the variants.
2019-05-09 07:26:41 -04:00
#if HA_OPENSSL_VERSION_NUMBER < 0x00907000L
CLEANUP: ssl: use the build options list to report the SSL details This removes 7 #ifdef from haproxy.c. The message indicating that openssl is *not* enabled is not there anymore.
2016-12-21 13:23:20 -05:00
"no (library version too old)"
#elif defined(OPENSSL_NO_TLSEXT)
"no (disabled via OPENSSL_NO_TLSEXT)"
#else
"yes"
#endif
"", ptr);
memprintf(&ptr, "%s\nOpenSSL library supports SNI : "
#ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME
"yes"
#else
#ifdef OPENSSL_NO_TLSEXT
"no (because of OPENSSL_NO_TLSEXT)"
#else
"no (version might be too old, 0.9.8f min needed)"
#endif
MINOR: ssl: show methods supported by openssl TLS v1.3 incoming, SSLv3 will disappears: it could be useful to list all methods supported by haproxy/openssl (with -vvv).
2017-03-24 10:20:03 -04:00
#endif
"", ptr);
MINOR: ssl: remove an unecessary SSL_OP_NO_* dependancy Use methodVersions table to display "OpenSSL library supports".
2017-07-12 08:25:38 -04:00
memprintf(&ptr, "%s\nOpenSSL library supports :", ptr);
for (i = CONF_TLSV_MIN; i <= CONF_TLSV_MAX; i++)
if (methodVersions[i].option)
memprintf(&ptr, "%s %s", ptr, methodVersions[i].name);
CLEANUP: ssl: use the build options list to report the SSL details This removes 7 #ifdef from haproxy.c. The message indicating that openssl is *not* enabled is not there anymore.
2016-12-21 13:23:20 -05:00
MINOR: ssl: Add 'show ssl providers' cli command and providers list in -vv option Starting from OpenSSLv3, providers are at the core of cryptography functions. Depending on the provider used, the way the SSL functionalities work could change. This new 'show ssl providers' CLI command allows to show what providers were loaded by the SSL library. This is required because the provider configuration is exclusively done in the OpenSSL configuration file (/usr/local/ssl/openssl.cnf for instance). A new line is also added to the 'haproxy -vv' output containing the same information.
2022-04-21 06:06:41 -04:00
#ifdef HAVE_SSL_PROVIDERS
{
struct list provider_names;
struct provider_name *name;
LIST_INIT(&provider_names);
ssl_provider_get_name_list(&provider_names);
memprintf(&ptr, "%s\nOpenSSL providers loaded :", ptr);
list_for_each_entry(name, &provider_names, list) {
memprintf(&ptr, "%s %s", ptr, name->name);
}
ssl_provider_clear_name_list(&provider_names);
}
#endif
CLEANUP: ssl: use the build options list to report the SSL details This removes 7 #ifdef from haproxy.c. The message indicating that openssl is *not* enabled is not there anymore.
2016-12-21 13:23:20 -05:00
hap_register_build_opts(ptr, 1);
MINOR: initcall: apply initcall to all register_build_opts() calls Most register_build_opts() calls use static strings. These ones were replaced with a trivial REGISTER_BUILD_OPTS() statement adding the string and its call to the STG_REGISTER section. A dedicated section could be made for this if needed, but there are very few such calls for this to be worth it. The calls made with computed strings however, like those which retrieve OpenSSL's version or zlib's version, were moved to a dedicated function to guarantee they are called late in the process. For example, the SSL call probably requires that SSL_library_init() has been called first.
2018-11-26 04:19:54 -05:00
}
CLEANUP: ssl: use the build options list to report the SSL details This removes 7 #ifdef from haproxy.c. The message indicating that openssl is *not* enabled is not there anymore.
2016-12-21 13:23:20 -05:00
MINOR: initcall: apply initcall to all register_build_opts() calls Most register_build_opts() calls use static strings. These ones were replaced with a trivial REGISTER_BUILD_OPTS() statement adding the string and its call to the STG_REGISTER section. A dedicated section could be made for this if needed, but there are very few such calls for this to be worth it. The calls made with computed strings however, like those which retrieve OpenSSL's version or zlib's version, were moved to a dedicated function to guarantee they are called late in the process. For example, the SSL call probably requires that SSL_library_init() has been called first.
2018-11-26 04:19:54 -05:00
INITCALL0(STG_REGISTER, ssl_register_build_options);
BUG/MEDIUM: ssl: fix tune.ssl.default-dh-param value being overwritten Herv Commowick reported that the logic used to avoid complaining about ssl-default-dh-param not being set when static DH params are present in the certificate file was clearly wrong when more than one sni_ctx is used. This patch stores whether static DH params are being used for each SSL_CTX individually, and does not overwrite the value of tune.ssl.default-dh-param.
2015-05-28 10:23:00 -04:00
BUILD: ssl: add USE_ENGINE and disable the openssl engine by default The OpenSSL engine API is deprecated starting with OpenSSL 3.0. In order to have a clean build this feature is now disabled by default. It can be reactivated with USE_ENGINE=1 on the build line.
2022-04-11 12:41:24 -04:00
#if defined(USE_ENGINE) && !defined(OPENSSL_NO_ENGINE)
MEDIUM: ssl: add basic support for OpenSSL crypto engine This patch adds the global 'ssl-engine' keyword. First arg is an engine identifier followed by a list of default_algorithms the engine will operate. If the openssl version is too old, an error is reported when the option is used.
2017-01-20 20:10:18 -05:00
void ssl_free_engines(void) {
struct ssl_engine_list *wl, *wlb;
/* free up engine list */
list_for_each_entry_safe(wl, wlb, &openssl_engines, list) {
ENGINE_finish(wl->e);
ENGINE_free(wl->e);
CLEANUP: lists/tree-wide: rename some list operations to avoid some confusion The current "ADD" vs "ADDQ" is confusing because when thinking in terms of appending at the end of a list, "ADD" naturally comes to mind, but here it does the opposite, it inserts. Several times already it's been incorrectly used where ADDQ was expected, the latest of which was a fortunate accident explained in 6fa922562 ("CLEANUP: stream: explain why we queue the stream at the head of the server list"). Let's use more explicit (but slightly longer) names now: LIST_ADD -> LIST_INSERT LIST_ADDQ -> LIST_APPEND LIST_ADDED -> LIST_INLIST LIST_DEL -> LIST_DELETE The same is true for MT_LISTs, including their "TRY" variant. LIST_DEL_INIT keeps its short name to encourage to use it instead of the lazier LIST_DELETE which is often less safe. The change is large (~674 non-comment entries) but is mechanical enough to remain safe. No permutation was performed, so any out-of-tree code can easily map older names to new ones. The list doc was updated.
2021-04-21 01:32:39 -04:00
LIST_DELETE(&wl->list);
MEDIUM: ssl: add basic support for OpenSSL crypto engine This patch adds the global 'ssl-engine' keyword. First arg is an engine identifier followed by a list of default_algorithms the engine will operate. If the openssl version is too old, an error is reported when the option is used.
2017-01-20 20:10:18 -05:00
free(wl);
}
}
BUILD: ssl: fix build with OPENSSL_NO_ENGINE Build is broken with openssl library without support of engin (like boringssl). Add OPENSSL_NO_ENGINE flag to fix that.
2017-05-29 08:36:20 -04:00
#endif
MEDIUM: ssl: Add options to forge SSL certificates With this patch, it is possible to configure HAProxy to forge the SSL certificate sent to a client using the SNI servername. We do it in the SNI callback. To enable this feature, you must pass following BIND options: * ca-sign-file <FILE> : This is the PEM file containing the CA certitifacte and the CA private key to create and sign server's certificates. * (optionally) ca-sign-pass <PASS>: This is the CA private key passphrase, if any. * generate-certificates: Enable the dynamic generation of certificates for a listener. Because generating certificates is expensive, there is a LRU cache to store them. Its size can be customized by setting the global parameter 'tune.ssl.ssl-ctx-cache-size'.
2015-06-09 11:29:50 -04:00
MINOR: ssl: Add 'ssl-provider' global option When HAProxy is linked to an OpenSSLv3 library, this option can be used to load a provider during init. You can specify multiple ssl-provider options, which will be loaded in the order they appear. This does not prevent OpenSSL from parsing its own configuration file in which some other providers might be specified. A linked list of the providers loaded from the configuration file is kept so that all those providers can be unloaded during cleanup. The providers loaded directly by OpenSSL will be freed by OpenSSL.
2022-05-16 10:24:33 -04:00
#ifdef HAVE_SSL_PROVIDERS
void ssl_unload_providers(void) {
struct ssl_provider_list *prov, *provb;
list_for_each_entry_safe(prov, provb, &openssl_providers, list) {
OSSL_PROVIDER_unload(prov->provider);
LIST_DELETE(&prov->list);
free(prov);
}
}
#endif
MINOR: ssl: add a destructor to free allocated SSL ressources Using valgrind or another memory leak tracking tool is easier when the memory internally allocated by OpenSSL is cleanly released at shutdown.
2015-05-28 10:39:47 -04:00
#ifndef OPENSSL_NO_DH
MEDIUM: ssl: add basic support for OpenSSL crypto engine This patch adds the global 'ssl-engine' keyword. First arg is an engine identifier followed by a list of default_algorithms the engine will operate. If the openssl version is too old, an error is reported when the option is used.
2017-01-20 20:10:18 -05:00
void ssl_free_dh(void) {
if (local_dh_1024) {
MEDIUM: ssl: Replace all DH objects by EVP_PKEY on OpenSSLv3 (via HASSL_DH type) DH structure is a low-level one that should not be used anymore with OpenSSLv3. All functions working on DH were marked as deprecated and this patch replaces the ones we used with new APIs recommended in OpenSSLv3, be it in the migration guide or the multiple new manpages they created. This patch replaces all mentions of the DH type by the HASSL_DH one, which will be replaced by EVP_PKEY with OpenSSLv3 and will remain DH on older versions. It also uses all the newly created helper functions that enable for instance to load DH parameters from a file into an EVP_PKEY, or to set DH parameters into an SSL_CTX for use in a DHE negotiation. The following deprecated functions will effectively disappear when building with OpenSSLv3 : DH_set0_pqg, PEM_read_bio_DHparams, DH_new, DH_free, DH_up_ref, SSL_CTX_set_tmp_dh.
2022-02-11 06:04:55 -05:00
HASSL_DH_free(local_dh_1024);
MEDIUM: ssl: add basic support for OpenSSL crypto engine This patch adds the global 'ssl-engine' keyword. First arg is an engine identifier followed by a list of default_algorithms the engine will operate. If the openssl version is too old, an error is reported when the option is used.
2017-01-20 20:10:18 -05:00
local_dh_1024 = NULL;
}
if (local_dh_2048) {
MEDIUM: ssl: Replace all DH objects by EVP_PKEY on OpenSSLv3 (via HASSL_DH type) DH structure is a low-level one that should not be used anymore with OpenSSLv3. All functions working on DH were marked as deprecated and this patch replaces the ones we used with new APIs recommended in OpenSSLv3, be it in the migration guide or the multiple new manpages they created. This patch replaces all mentions of the DH type by the HASSL_DH one, which will be replaced by EVP_PKEY with OpenSSLv3 and will remain DH on older versions. It also uses all the newly created helper functions that enable for instance to load DH parameters from a file into an EVP_PKEY, or to set DH parameters into an SSL_CTX for use in a DHE negotiation. The following deprecated functions will effectively disappear when building with OpenSSLv3 : DH_set0_pqg, PEM_read_bio_DHparams, DH_new, DH_free, DH_up_ref, SSL_CTX_set_tmp_dh.
2022-02-11 06:04:55 -05:00
HASSL_DH_free(local_dh_2048);
MEDIUM: ssl: add basic support for OpenSSL crypto engine This patch adds the global 'ssl-engine' keyword. First arg is an engine identifier followed by a list of default_algorithms the engine will operate. If the openssl version is too old, an error is reported when the option is used.
2017-01-20 20:10:18 -05:00
local_dh_2048 = NULL;
}
if (local_dh_4096) {
MEDIUM: ssl: Replace all DH objects by EVP_PKEY on OpenSSLv3 (via HASSL_DH type) DH structure is a low-level one that should not be used anymore with OpenSSLv3. All functions working on DH were marked as deprecated and this patch replaces the ones we used with new APIs recommended in OpenSSLv3, be it in the migration guide or the multiple new manpages they created. This patch replaces all mentions of the DH type by the HASSL_DH one, which will be replaced by EVP_PKEY with OpenSSLv3 and will remain DH on older versions. It also uses all the newly created helper functions that enable for instance to load DH parameters from a file into an EVP_PKEY, or to set DH parameters into an SSL_CTX for use in a DHE negotiation. The following deprecated functions will effectively disappear when building with OpenSSLv3 : DH_set0_pqg, PEM_read_bio_DHparams, DH_new, DH_free, DH_up_ref, SSL_CTX_set_tmp_dh.
2022-02-11 06:04:55 -05:00
HASSL_DH_free(local_dh_4096);
MEDIUM: ssl: add basic support for OpenSSL crypto engine This patch adds the global 'ssl-engine' keyword. First arg is an engine identifier followed by a list of default_algorithms the engine will operate. If the openssl version is too old, an error is reported when the option is used.
2017-01-20 20:10:18 -05:00
local_dh_4096 = NULL;
}
MEDIUM: ssl: add the possibility to use a global DH parameters file This patch adds the ssl-dh-param-file global setting. It sets the default DH parameters that will be used during the SSL/TLS handshake when ephemeral Diffie-Hellman (DHE) key exchange is used, for all "bind" lines which do not explicitely define theirs.
2015-05-29 09:53:22 -04:00
if (global_dh) {
MEDIUM: ssl: Replace all DH objects by EVP_PKEY on OpenSSLv3 (via HASSL_DH type) DH structure is a low-level one that should not be used anymore with OpenSSLv3. All functions working on DH were marked as deprecated and this patch replaces the ones we used with new APIs recommended in OpenSSLv3, be it in the migration guide or the multiple new manpages they created. This patch replaces all mentions of the DH type by the HASSL_DH one, which will be replaced by EVP_PKEY with OpenSSLv3 and will remain DH on older versions. It also uses all the newly created helper functions that enable for instance to load DH parameters from a file into an EVP_PKEY, or to set DH parameters into an SSL_CTX for use in a DHE negotiation. The following deprecated functions will effectively disappear when building with OpenSSLv3 : DH_set0_pqg, PEM_read_bio_DHparams, DH_new, DH_free, DH_up_ref, SSL_CTX_set_tmp_dh.
2022-02-11 06:04:55 -05:00
HASSL_DH_free(global_dh);
MEDIUM: ssl: add the possibility to use a global DH parameters file This patch adds the ssl-dh-param-file global setting. It sets the default DH parameters that will be used during the SSL/TLS handshake when ephemeral Diffie-Hellman (DHE) key exchange is used, for all "bind" lines which do not explicitely define theirs.
2015-05-29 09:53:22 -04:00
global_dh = NULL;
}
MEDIUM: ssl: add basic support for OpenSSL crypto engine This patch adds the global 'ssl-engine' keyword. First arg is an engine identifier followed by a list of default_algorithms the engine will operate. If the openssl version is too old, an error is reported when the option is used.
2017-01-20 20:10:18 -05:00
}
#endif
static void __ssl_sock_deinit(void)
{
MINOR: ssl: add a destructor to free allocated SSL ressources Using valgrind or another memory leak tracking tool is easier when the memory internally allocated by OpenSSL is cleanly released at shutdown.
2015-05-28 10:39:47 -04:00
CLEANUP: ssl: remove 57 occurrences of useless tests on LIBRESSL_VERSION_NUMBER They were all check to comply with the advertised openssl version. Now that libressl doesn't pretend to be a more recent openssl anymore, we can simply rely on the regular openssl version tests without having to deal with exceptions for libressl.
2019-05-09 08:13:35 -04:00
#if (HA_OPENSSL_VERSION_NUMBER < 0x10100000L)
MINOR: ssl: add a destructor to free allocated SSL ressources Using valgrind or another memory leak tracking tool is easier when the memory internally allocated by OpenSSL is cleanly released at shutdown.
2015-05-28 10:39:47 -04:00
ERR_remove_state(0);
ERR_free_strings();
EVP_cleanup();
BUILD: ssl: Fix compilation without deprecated OpenSSL 1.1 APIs Removing deprecated APIs is an optional part of OpenWrt's build system to save some space on embedded devices. Also added compatibility for LibreSSL. Signed-off-by: Rosen Penev <rosenp@gmail.com>
2018-12-14 11:47:02 -05:00
#endif
MINOR: ssl: add a destructor to free allocated SSL ressources Using valgrind or another memory leak tracking tool is easier when the memory internally allocated by OpenSSL is cleanly released at shutdown.
2015-05-28 10:39:47 -04:00
CLEANUP: ssl: remove 57 occurrences of useless tests on LIBRESSL_VERSION_NUMBER They were all check to comply with the advertised openssl version. Now that libressl doesn't pretend to be a more recent openssl anymore, we can simply rely on the regular openssl version tests without having to deal with exceptions for libressl.
2019-05-09 08:13:35 -04:00
#if (HA_OPENSSL_VERSION_NUMBER >= 0x00907000L) && (HA_OPENSSL_VERSION_NUMBER < 0x10100000L)
MINOR: ssl: add a destructor to free allocated SSL ressources Using valgrind or another memory leak tracking tool is easier when the memory internally allocated by OpenSSL is cleanly released at shutdown.
2015-05-28 10:39:47 -04:00
CRYPTO_cleanup_all_ex_data();
#endif
MEDIUM: ssl: provide our own BIO. Instead of letting the OpenSSL code handle the file descriptor directly, provide a custom BIO, that will use the underlying XPRT to send/recv data. This will let us implement QUIC later, and probably clean the upper layer, if/when the SSL code provide its own subscribe code, so that the upper layers won't have to care if we're still waiting for the handshake to complete or not.
2019-04-07 16:00:38 -04:00
BIO_meth_free(ha_meth);
MEDIUM: ssl: Add ocsp update task main function This patch contains the main function of the ocsp auto update mechanism as well as an init and destroy function of the task used for this. The task is not created in this patch but in a later one. The function has two distinct parts and the branching to one or the other is completely based on the fact that the cur_ocsp pointer of the ssl_ocsp_task_ctx member is set. If the pointer is not set, we need to look at the first item of the update tree and see if it needs to be updated. If it does not we simply wait until the time is right and let the task asleep. If it does need to be updated, we simply build and send the corresponding ocsp request thanks to the http_client. The task is then sent to sleep with an expire time set to infinity. The http_client will wake it back up once the response is received (or a timeout occurs). Just note that during this whole process the cetificate_ocsp object corresponding to the entry being updated is taken out of the update tree and only stored in the ssl_ocsp_task_ctx context. Once the task is waken up by the http_client, it branches on the response processing part of the function which basically checks that the response is valid and inserts it into the ocsp_response tree. The task then goes back to sleep until another entry needs to be updated.
2022-12-20 05:11:13 -05:00
#if !defined OPENSSL_NO_OCSP
ssl_destroy_ocsp_update_task();
#endif
MINOR: ssl: add a destructor to free allocated SSL ressources Using valgrind or another memory leak tracking tool is easier when the memory internally allocated by OpenSSL is cleanly released at shutdown.
2015-05-28 10:39:47 -04:00
}
BUILD: xprt: use an initcall to register the transport layers Transport layers (raw_sock, ssl_sock, xprt_handshake and xprt_quic) were using 4 constructors and 2 destructors. The 4 constructors were replaced with INITCALL and the destructors with REGISTER_POST_DEINIT() so that we do not depend on this anymore.
2022-04-25 13:18:24 -04:00
REGISTER_POST_DEINIT(__ssl_sock_deinit);
MINOR: ssl: add a destructor to free allocated SSL ressources Using valgrind or another memory leak tracking tool is easier when the memory internally allocated by OpenSSL is cleanly released at shutdown.
2015-05-28 10:39:47 -04:00
MEDIUM: cli/ssl: configure ssl on server at runtime in the context of a progressive backend migration, we want to be able to activate SSL on outgoing connections to the server at runtime without reloading. This patch adds a `set server ssl` command; in order to allow that: - add `srv_use_ssl` to `show servers state` command for compatibility, also update associated parsing - when using default-server ssl setting, and `no-ssl` on server line, init SSL ctx without activating it - when triggering ssl API, de/activate SSL connections as requested - clean ongoing connections as it is done for addr/port changes, without checking prior server state example config: backend be_foo default-server ssl server srv0 127.0.0.1:6011 weight 1 no-ssl show servers state: 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - -1 where srv0 can switch to ssl later during the runtime: set server be_foo/srv0 ssl on 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - 1 Also update existing tests and create a new one. Signed-off-by: William Dauchy <wdauchy@gmail.com>
2020-11-14 13:25:33 -05:00
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
/*
* Local variables:
* c-indent-level: 8
* c-basic-offset: 8
* End:
*/
Reference in a new issue Copy permalink