upstream/haproxy
1
0
Fork 0
mirror of https://github.com/haproxy/haproxy.git synced 2026-04-24 15:49:14 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 9
haproxy/src/ssl_sock.c

8315 lines
241 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>
REORG: rename cs_utils.h to sc_strm.h This file contains all the stream-connector functions that are specific to application layers of type stream. So let's name it accordingly so that it's easier to figure what's located there. The alphabetical ordering of include files was preserved.
2022-05-27 03:25:10 -04:00
#include <haproxy/sample.h>
#include <haproxy/sc_strm.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>
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: 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>
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
#include <haproxy/xprt_quic.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>
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
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 = 0
#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;
static void ssl_fill_stats(void *data, struct field *stats)
{
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: 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
stats[SSL_ST_SESS] = mkf_u64(FN_COUNTER, counters->sess);
stats[SSL_ST_REUSED_SESS] = mkf_u64(FN_COUNTER, counters->reused_sess);
stats[SSL_ST_FAILED_HANDSHAKE] = mkf_u64(FN_COUNTER, counters->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 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;
int ret;
ctx = BIO_get_data(h);
tmpbuf.size = num;
tmpbuf.area = (void *)(uintptr_t)buf;
tmpbuf.data = num;
tmpbuf.head = 0;
ret = ctx->xprt->snd_buf(ctx->conn, ctx->xprt_ctx, &tmpbuf, num, 0);
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/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
} else if (ret == 0)
BIO_clear_retry_flags(h);
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/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/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
} else if (ret == 0)
BIO_clear_retry_flags(h);
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;
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
static DH *ssl_get_tmp_dh_cbk(SSL *ssl, int export, int keylen);
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
static void ssl_sock_set_tmp_dh_from_pkey(SSL_CTX *ctx, EVP_PKEY *pkey);
#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
#endif /* OPENSSL_NO_DH */
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_CTRL_SET_TLSEXT_HOSTNAME && !defined SSL_NO_GENERATE_CERTIFICATES)
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
/* X509V3 Extensions that will be added on generated certificates */
#define X509V3_EXT_SIZE 5
static char *x509v3_ext_names[X509V3_EXT_SIZE] = {
"basicConstraints",
"nsComment",
"subjectKeyIdentifier",
"authorityKeyIdentifier",
"keyUsage",
};
static char *x509v3_ext_values[X509V3_EXT_SIZE] = {
"CA:FALSE",
"\"OpenSSL Generated Certificate\"",
"hash",
"keyid,issuer:always",
"nonRepudiation,digitalSignature,keyEncipherment"
};
/* LRU cache to store generated certificate */
static struct lru64_head *ssl_ctx_lru_tree = NULL;
static unsigned int ssl_ctx_lru_seed = 0;
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 unsigned int ssl_ctx_serial;
MEDIUM: init: use self-initializing spinlocks and rwlocks This patch replaces a number of __decl_hathread() followed by HA_SPIN_INIT or HA_RWLOCK_INIT by the new __decl_spinlock() or __decl_rwlock() which automatically registers the lock for initialization in during the STG_LOCK init stage. A few static modifiers were lost in the process, but since they were not essential at all it was not worth extending the API to provide such a variant.
2018-11-25 14:12:18 -05:00
__decl_rwlock(ssl_ctx_lru_rwlock);
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
BUILD: ssl: fix recent build breakage on older SSL libs Commit 31af49d ("MEDIUM: ssl: Add options to forge SSL certificates") introduced some dependencies on SSL_CTRL_SET_TLSEXT_HOSTNAME for which a few checks were missing, breaking the build on openssl 0.9.8.
2015-06-17 09:48:26 -04:00
#endif // SSL_CTRL_SET_TLSEXT_HOSTNAME
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
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: Use OpenSSL's ASN1_TIME convertor when available The ASN1_TIME_to_tm function was added in OpenSSL1.1.1 so with this version of the library we do not need our homemade time convertor anymore.
2021-06-11 04:28:09 -04:00
#if (defined SSL_CTRL_SET_TLSEXT_STATUS_REQ_CB && !defined OPENSSL_NO_OCSP && !defined HAVE_ASN1_TIME_TO_TM)
BUG/MEDIUM: ssl: Fix to not serve expired OCSP responses. For some browsers (firefox), an expired OCSP Response causes unwanted behavior. Haproxy stops serving OCSP response if nextupdate date minus the supported time skew (#define OCSP_MAX_RESPONSE_TIME_SKEW) is in the past.
2014-06-20 09:46:13 -04:00
/*
* This function returns the number of seconds elapsed
* since the Epoch, 1970-01-01 00:00:00 +0000 (UTC) and the
* date presented un ASN1_GENERALIZEDTIME.
*
* In parsing error case, it returns -1.
*/
static long asn1_generalizedtime_to_epoch(ASN1_GENERALIZEDTIME *d)
{
long epoch;
char *p, *end;
const unsigned short month_offset[12] = {
0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334
};
BUG/MINOR: ssl: OCSP stapling does not work if expire too far in the future The wey the "Next Update" field of the OCSP response is converted into a timestamp relies on the use of signed integers for the year and month so if the calculated timestamp happens to overflow INT_MAX, it ends up being seen as negative and the OCSP response being dwignored in ssl_sock_ocsp_stapling_cbk (because of the "ocsp->expire < now.tv_sec" test). It could be backported to all stable branches.
2021-06-09 11:16:18 -04:00
unsigned long year, month;
BUG/MEDIUM: ssl: Fix to not serve expired OCSP responses. For some browsers (firefox), an expired OCSP Response causes unwanted behavior. Haproxy stops serving OCSP response if nextupdate date minus the supported time skew (#define OCSP_MAX_RESPONSE_TIME_SKEW) is in the past.
2014-06-20 09:46:13 -04:00
if (!d || (d->type != V_ASN1_GENERALIZEDTIME)) return -1;
p = (char *)d->data;
end = p + d->length;
if (end - p < 4) return -1;
year = 1000 * (p[0] - '0') + 100 * (p[1] - '0') + 10 * (p[2] - '0') + p[3] - '0';
p += 4;
if (end - p < 2) return -1;
month = 10 * (p[0] - '0') + p[1] - '0';
if (month < 1 || month > 12) return -1;
/* Compute the number of seconds since 1 jan 1970 and the beginning of current month
We consider leap years and the current month (<marsh or not) */
epoch = ( ((year - 1970) * 365)
+ ((year - (month < 3)) / 4 - (year - (month < 3)) / 100 + (year - (month < 3)) / 400)
- ((1970 - 1) / 4 - (1970 - 1) / 100 + (1970 - 1) / 400)
+ month_offset[month-1]
) * 24 * 60 * 60;
p += 2;
if (end - p < 2) return -1;
/* Add the number of seconds of completed days of current month */
epoch += (10 * (p[0] - '0') + p[1] - '0' - 1) * 24 * 60 * 60;
p += 2;
if (end - p < 2) return -1;
/* Add the completed hours of the current day */
epoch += (10 * (p[0] - '0') + p[1] - '0') * 60 * 60;
p += 2;
if (end - p < 2) return -1;
/* Add the completed minutes of the current hour */
epoch += (10 * (p[0] - '0') + p[1] - '0') * 60;
p += 2;
if (p == end) return -1;
/* Test if there is available seconds */
if (p[0] < '0' || p[0] > '9')
goto nosec;
if (end - p < 2) return -1;
/* Add the seconds of the current minute */
epoch += 10 * (p[0] - '0') + p[1] - '0';
p += 2;
if (p == end) return -1;
/* Ignore seconds float part if present */
if (p[0] == '.') {
do {
if (++p == end) return -1;
} while (p[0] >= '0' && p[0] <= '9');
}
nosec:
if (p[0] == 'Z') {
if (end - p != 1) return -1;
return epoch;
}
else if (p[0] == '+') {
if (end - p != 5) return -1;
/* Apply timezone offset */
BUG/MEDIUM: ssl: fix OCSP expiry calculation The hour part of the timezone offset was multiplied by 60 instead of 3600, resulting in an inaccurate expiry. This bug was introduced in 1.6-dev1 by commit 4f3c87a ("BUG/MEDIUM: ssl: Fix to not serve expired OCSP responses."), so this fix must be backported into 1.7 and 1.6.
2017-10-16 10:37:31 -04:00
return epoch - ((10 * (p[1] - '0') + p[2] - '0') * 60 * 60 + (10 * (p[3] - '0') + p[4] - '0')) * 60;
BUG/MEDIUM: ssl: Fix to not serve expired OCSP responses. For some browsers (firefox), an expired OCSP Response causes unwanted behavior. Haproxy stops serving OCSP response if nextupdate date minus the supported time skew (#define OCSP_MAX_RESPONSE_TIME_SKEW) is in the past.
2014-06-20 09:46:13 -04:00
}
else if (p[0] == '-') {
if (end - p != 5) return -1;
/* Apply timezone offset */
BUG/MEDIUM: ssl: fix OCSP expiry calculation The hour part of the timezone offset was multiplied by 60 instead of 3600, resulting in an inaccurate expiry. This bug was introduced in 1.6-dev1 by commit 4f3c87a ("BUG/MEDIUM: ssl: Fix to not serve expired OCSP responses."), so this fix must be backported into 1.7 and 1.6.
2017-10-16 10:37:31 -04:00
return epoch + ((10 * (p[1] - '0') + p[2] - '0') * 60 * 60 + (10 * (p[3] - '0') + p[4] - '0')) * 60;
BUG/MEDIUM: ssl: Fix to not serve expired OCSP responses. For some browsers (firefox), an expired OCSP Response causes unwanted behavior. Haproxy stops serving OCSP response if nextupdate date minus the supported time skew (#define OCSP_MAX_RESPONSE_TIME_SKEW) is in the past.
2014-06-20 09:46:13 -04:00
}
return -1;
}
MINOR: ssl: Use OpenSSL's ASN1_TIME convertor when available The ASN1_TIME_to_tm function was added in OpenSSL1.1.1 so with this version of the library we do not need our homemade time convertor anymore.
2021-06-11 04:28:09 -04:00
#endif
BUG/MEDIUM: ssl: Fix to not serve expired OCSP responses. For some browsers (firefox), an expired OCSP Response causes unwanted behavior. Haproxy stops serving OCSP response if nextupdate date minus the supported time skew (#define OCSP_MAX_RESPONSE_TIME_SKEW) is in the past.
2014-06-20 09:46:13 -04:00
MINOR: ssl: Use OpenSSL's ASN1_TIME convertor when available The ASN1_TIME_to_tm function was added in OpenSSL1.1.1 so with this version of the library we do not need our homemade time convertor anymore.
2021-06-11 04:28:09 -04:00
#if (defined SSL_CTRL_SET_TLSEXT_STATUS_REQ_CB && !defined OPENSSL_NO_OCSP)
BUILD: ssl: wrong #ifdef for SSL engines code The SSL engines code was written below the OCSP #ifdef, which means you can't build the engines code if the OCSP is deactived in the SSL lib. Could be backported in every version since 1.8.
2019-10-14 08:14:59 -04:00
/*
* struct alignment works here such that the key.key is the same as key_data
* Do not change the placement of key_data
*/
struct certificate_ocsp {
struct ebmb_node key;
unsigned char key_data[OCSP_MAX_CERTID_ASN1_LENGTH];
MINOR: ssl: Keep the actual key length in the certificate_ocsp structure The OCSP tree entry key is a serialized version of the OCSP_CERTID of the entry which is stored in a buffer that can be at most 128 bytes. Depending on the length of the serial number, the actual non-zero part of the key can be smaller than 128 bytes and this new structure member allows to know how many of the bytes are filled. It will be useful when dumping the key (in a "show ssl cert <cert>" output for instance).
2021-06-10 07:51:12 -04:00
unsigned int key_length;
BUILD: ssl: wrong #ifdef for SSL engines code The SSL engines code was written below the OCSP #ifdef, which means you can't build the engines code if the OCSP is deactived in the SSL lib. Could be backported in every version since 1.8.
2019-10-14 08:14:59 -04:00
struct buffer response;
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
int refcount;
BUILD: ssl: wrong #ifdef for SSL engines code The SSL engines code was written below the OCSP #ifdef, which means you can't build the engines code if the OCSP is deactived in the SSL lib. Could be backported in every version since 1.8.
2019-10-14 08:14:59 -04:00
long expire;
};
struct ocsp_cbk_arg {
int is_single;
int single_kt;
union {
struct certificate_ocsp *s_ocsp;
/*
* m_ocsp will have multiple entries dependent on key type
* Entry 0 - DSA
* Entry 1 - ECDSA
* Entry 2 - RSA
*/
struct certificate_ocsp *m_ocsp[SSL_SOCK_NUM_KEYTYPES];
};
};
BUG/MINOR: ssl: Fix OCSP resp update fails with the same certificate configured twice.
2014-06-20 09:37:32 -04:00
static struct eb_root cert_ocsp_tree = EB_ROOT_UNIQUE;
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 starts to check if the OCSP response (in DER format) contained
* in chunk 'ocsp_response' is valid (else exits on error).
* If 'cid' is not NULL, it will be compared to the OCSP certificate ID
* contained in the OCSP Response and exits on error if no match.
* If it's a valid OCSP Response:
* If 'ocsp' is not NULL, the chunk is copied in the OCSP response's container
* pointed by 'ocsp'.
* If 'ocsp' is NULL, the function looks up into the OCSP response's
* containers tree (using as index the ASN1 form of the OCSP Certificate ID extracted
* from the response) and exits on error if not found. Finally, If an OCSP response is
* already present in the container, it will be overwritten.
*
* Note: OCSP response containing more than one OCSP Single response is not
* considered valid.
*
* Returns 0 on success, 1 in error case.
*/
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
static int ssl_sock_load_ocsp_response(struct buffer *ocsp_response,
struct certificate_ocsp *ocsp,
OCSP_CERTID *cid, char **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
{
OCSP_RESPONSE *resp;
OCSP_BASICRESP *bs = NULL;
OCSP_SINGLERESP *sr;
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
OCSP_CERTID *id;
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
unsigned char *p = (unsigned char *) ocsp_response->area;
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 rc , count_sr;
BUG/MINOR: ssl: rejects OCSP response without nextupdate. To cache an OCSP Response without expiration time is not safe.
2014-06-20 09:44:34 -04:00
ASN1_GENERALIZEDTIME *revtime, *thisupd, *nextupd = 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
int reason;
int ret = 1;
MINOR: ssl: Use OpenSSL's ASN1_TIME convertor when available The ASN1_TIME_to_tm function was added in OpenSSL1.1.1 so with this version of the library we do not need our homemade time convertor anymore.
2021-06-11 04:28:09 -04:00
#ifdef HAVE_ASN1_TIME_TO_TM
struct tm nextupd_tm = {0};
#endif
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: 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
resp = d2i_OCSP_RESPONSE(NULL, (const unsigned char **)&p,
ocsp_response->data);
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 (!resp) {
memprintf(err, "Unable to parse OCSP response");
goto out;
}
rc = OCSP_response_status(resp);
if (rc != OCSP_RESPONSE_STATUS_SUCCESSFUL) {
memprintf(err, "OCSP response status not successful");
goto out;
}
bs = OCSP_response_get1_basic(resp);
if (!bs) {
memprintf(err, "Failed to get basic response from OCSP Response");
goto out;
}
count_sr = OCSP_resp_count(bs);
if (count_sr > 1) {
memprintf(err, "OCSP response ignored because contains multiple single responses (%d)", count_sr);
goto out;
}
sr = OCSP_resp_get0(bs, 0);
if (!sr) {
memprintf(err, "Failed to get OCSP single response");
goto out;
}
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
id = (OCSP_CERTID*)OCSP_SINGLERESP_get0_id(sr);
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
rc = OCSP_single_get0_status(sr, &reason, &revtime, &thisupd, &nextupd);
BUG/MINOR: ssl: OCSP_single_get0_status can return -1 Commit 872085ce "BUG/MINOR: ssl: ocsp response with 'revoked' status is correct" introduce a regression. OCSP_single_get0_status can return -1 and haproxy must generate an error in this case. Thanks to Sander Hoentjen who have spotted the regression. This patch should be backported in 1.7, 1.6 and 1.5 if the patch above is backported.
2017-10-24 08:57:16 -04:00
if (rc != V_OCSP_CERTSTATUS_GOOD && rc != V_OCSP_CERTSTATUS_REVOKED) {
BUG/MINOR: ssl: ocsp response with 'revoked' status is correct ocsp_status can be 'good', 'revoked', or 'unknown'. 'revoked' status is a correct status and should not be dropped. In case of certificate with OCSP must-stapling extension, response with 'revoked' status must be provided as well as 'good' status. This patch can be backported in 1.7, 1.6 and 1.5.
2017-10-10 09:18:52 -04:00
memprintf(err, "OCSP single response: certificate status is unknown");
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;
}
BUG/MINOR: ssl: rejects OCSP response without nextupdate. To cache an OCSP Response without expiration time is not safe.
2014-06-20 09:44:34 -04:00
if (!nextupd) {
memprintf(err, "OCSP single response: missing nextupdate");
goto out;
}
MEDIUM: ssl: add 300s supported time skew on OCSP response update. OCSP_MAX_RESPONSE_TIME_SKEW can be set to a different value at compilation (default is 300 seconds).
2014-06-19 08:16:17 -04:00
rc = OCSP_check_validity(thisupd, nextupd, OCSP_MAX_RESPONSE_TIME_SKEW, -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 (!rc) {
memprintf(err, "OCSP single response: no longer valid.");
goto out;
}
if (cid) {
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 (OCSP_id_cmp(id, 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
memprintf(err, "OCSP single response: Certificate ID does not match certificate and issuer");
goto out;
}
}
if (!ocsp) {
unsigned char key[OCSP_MAX_CERTID_ASN1_LENGTH];
unsigned char *p;
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
rc = i2d_OCSP_CERTID(id, 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 (!rc) {
memprintf(err, "OCSP single response: Unable to encode Certificate ID");
goto out;
}
if (rc > OCSP_MAX_CERTID_ASN1_LENGTH) {
memprintf(err, "OCSP single response: Certificate ID too long");
goto out;
}
p = key;
memset(key, 0, OCSP_MAX_CERTID_ASN1_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
i2d_OCSP_CERTID(id, &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
ocsp = (struct certificate_ocsp *)ebmb_lookup(&cert_ocsp_tree, key, OCSP_MAX_CERTID_ASN1_LENGTH);
if (!ocsp) {
memprintf(err, "OCSP single response: Certificate ID does not match any certificate or issuer");
goto out;
}
}
/* According to comments on "chunk_dup", the
previous chunk buffer will be freed */
if (!chunk_dup(&ocsp->response, ocsp_response)) {
memprintf(err, "OCSP response: Memory allocation error");
goto out;
}
MINOR: ssl: Use OpenSSL's ASN1_TIME convertor when available The ASN1_TIME_to_tm function was added in OpenSSL1.1.1 so with this version of the library we do not need our homemade time convertor anymore.
2021-06-11 04:28:09 -04:00
#ifdef HAVE_ASN1_TIME_TO_TM
if (ASN1_TIME_to_tm(nextupd, &nextupd_tm) == 0) {
memprintf(err, "OCSP single response: Invalid \"Next Update\" time");
goto out;
}
ocsp->expire = my_timegm(&nextupd_tm) - OCSP_MAX_RESPONSE_TIME_SKEW;
#else
BUG/MEDIUM: ssl: Fix to not serve expired OCSP responses. For some browsers (firefox), an expired OCSP Response causes unwanted behavior. Haproxy stops serving OCSP response if nextupdate date minus the supported time skew (#define OCSP_MAX_RESPONSE_TIME_SKEW) is in the past.
2014-06-20 09:46:13 -04:00
ocsp->expire = asn1_generalizedtime_to_epoch(nextupd) - OCSP_MAX_RESPONSE_TIME_SKEW;
BUG/MINOR: ssl: OCSP stapling does not work if expire too far in the future The wey the "Next Update" field of the OCSP response is converted into a timestamp relies on the use of signed integers for the year and month so if the calculated timestamp happens to overflow INT_MAX, it ends up being seen as negative and the OCSP response being dwignored in ssl_sock_ocsp_stapling_cbk (because of the "ocsp->expire < now.tv_sec" test). It could be backported to all stable branches.
2021-06-09 11:16:18 -04:00
if (ocsp->expire < 0) {
memprintf(err, "OCSP single response: Invalid \"Next Update\" time");
goto out;
}
MINOR: ssl: Use OpenSSL's ASN1_TIME convertor when available The ASN1_TIME_to_tm function was added in OpenSSL1.1.1 so with this version of the library we do not need our homemade time convertor anymore.
2021-06-11 04:28:09 -04:00
#endif
BUG/MEDIUM: ssl: Fix to not serve expired OCSP responses. For some browsers (firefox), an expired OCSP Response causes unwanted behavior. Haproxy stops serving OCSP response if nextupdate date minus the supported time skew (#define OCSP_MAX_RESPONSE_TIME_SKEW) is in the past.
2014-06-20 09:46:13 -04: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
ret = 0;
out:
BUG/MEDIUM: ssl: Clear OpenSSL error stack after trying to parse OCSP file Invalid OCSP file (for example empty one that can be used to enable OCSP response to be set dynamically later) causes errors that are placed on OpenSSL error stack. Those errors are not cleared so anything that checks this stack later will fail. Following configuration: bind :443 ssl crt crt1.pem crt crt2.pem With following files: crt1.pem crt1.pem.ocsp - empty one crt2.pem.rsa crt2.pem.ecdsa Will fail to load. This patch should be backported to 1.7.
2017-03-08 10:59:41 -05:00
ERR_clear_error();
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 (bs)
OCSP_BASICRESP_free(bs);
if (resp)
OCSP_RESPONSE_free(resp);
return ret;
}
/*
* External function use to update the OCSP response in the OCSP response's
* containers tree. The chunk 'ocsp_response' must contain the OCSP response
* to update in DER format.
*
* Returns 0 on success, 1 in error case.
*/
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_ocsp_response(struct buffer *ocsp_response, char **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 ssl_sock_load_ocsp_response(ocsp_response, NULL, NULL, err);
}
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
#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 */
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(&tkr, &tlskeys_reference);
LIST_DELETE(&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 */
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
#ifndef OPENSSL_NO_OCSP
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
int ocsp_ex_index = -1;
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
int ssl_sock_get_ocsp_arg_kt_index(int evp_keytype)
{
switch (evp_keytype) {
case EVP_PKEY_RSA:
return 2;
case EVP_PKEY_DSA:
return 0;
case EVP_PKEY_EC:
return 1;
}
return -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
/*
* Callback used to set OCSP status extension content in server hello.
*/
int ssl_sock_ocsp_stapling_cbk(SSL *ssl, void *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 *ocsp;
struct ocsp_cbk_arg *ocsp_arg;
char *ssl_buf;
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 *ctx;
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
EVP_PKEY *ssl_pkey;
int key_type;
int index;
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
ctx = SSL_get_SSL_CTX(ssl);
if (!ctx)
return SSL_TLSEXT_ERR_NOACK;
ocsp_arg = SSL_CTX_get_ex_data(ctx, ocsp_ex_index);
if (!ocsp_arg)
return SSL_TLSEXT_ERR_NOACK;
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_pkey = SSL_get_privatekey(ssl);
if (!ssl_pkey)
return SSL_TLSEXT_ERR_NOACK;
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
key_type = EVP_PKEY_base_id(ssl_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
if (ocsp_arg->is_single && ocsp_arg->single_kt == key_type)
ocsp = ocsp_arg->s_ocsp;
else {
/* For multiple certs per context, we have to find the correct OCSP response based on
* the certificate type
*/
index = ssl_sock_get_ocsp_arg_kt_index(key_type);
if (index < 0)
return SSL_TLSEXT_ERR_NOACK;
ocsp = ocsp_arg->m_ocsp[index];
}
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 ||
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
!ocsp->response.area ||
!ocsp->response.data ||
BUG/MEDIUM: ssl: Fix to not serve expired OCSP responses. For some browsers (firefox), an expired OCSP Response causes unwanted behavior. Haproxy stops serving OCSP response if nextupdate date minus the supported time skew (#define OCSP_MAX_RESPONSE_TIME_SKEW) is in the past.
2014-06-20 09:46:13 -04:00
(ocsp->expire < now.tv_sec))
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 SSL_TLSEXT_ERR_NOACK;
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
ssl_buf = OPENSSL_malloc(ocsp->response.data);
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 (!ssl_buf)
return SSL_TLSEXT_ERR_NOACK;
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(ssl_buf, ocsp->response.area, ocsp->response.data);
SSL_set_tlsext_status_ocsp_resp(ssl, ssl_buf, ocsp->response.data);
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 SSL_TLSEXT_ERR_OK;
}
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
#endif
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)
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
/*
* Decrease the refcount of the struct ocsp_response and frees it if it's not
* used anymore. Also removes it from the tree if free'd.
*/
static void ssl_sock_free_ocsp(struct certificate_ocsp *ocsp)
{
if (!ocsp)
return;
ocsp->refcount--;
if (ocsp->refcount <= 0) {
ebmb_delete(&ocsp->key);
chunk_destroy(&ocsp->response);
free(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
/*
* 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: 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
static int ssl_sock_load_ocsp(SSL_CTX *ctx, const struct cert_key_and_chain *ckch, 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
OCSP_CERTID *cid = NULL;
int i, ret = -1;
struct certificate_ocsp *ocsp = NULL, *iocsp;
char *warn = NULL;
unsigned char *p;
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);
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
x = ckch->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: 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
issuer = ckch->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
cid = OCSP_cert_to_id(0, x, issuer);
if (!cid)
goto out;
i = i2d_OCSP_CERTID(cid, NULL);
if (!i || (i > OCSP_MAX_CERTID_ASN1_LENGTH))
goto out;
CLEANUP: uniformize last argument of malloc/calloc Instead of repeating the type of the LHS argument (sizeof(struct ...)) in calls to malloc/calloc, we directly use the pointer name (sizeof(*...)). The following Coccinelle patch was used: @@ type T; T *x; @@ x = malloc( - sizeof(T) + sizeof(*x) ) @@ type T; T *x; @@ x = calloc(1, - sizeof(T) + sizeof(*x) ) When the LHS is not just a variable name, no change is made. Moreover, the following patch was used to ensure that "1" is consistently used as a first argument of calloc, not the last one: @@ @@ calloc( + 1, ... - ,1 )
2016-04-03 07:48:43 -04:00
ocsp = calloc(1, sizeof(*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 (!ocsp)
goto out;
p = ocsp->key_data;
MINOR: ssl: Keep the actual key length in the certificate_ocsp structure The OCSP tree entry key is a serialized version of the OCSP_CERTID of the entry which is stored in a buffer that can be at most 128 bytes. Depending on the length of the serial number, the actual non-zero part of the key can be smaller than 128 bytes and this new structure member allows to know how many of the bytes are filled. It will be useful when dumping the key (in a "show ssl cert <cert>" output for instance).
2021-06-10 07:51:12 -04:00
ocsp->key_length = i2d_OCSP_CERTID(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
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);
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/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
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/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
iocsp->refcount++;
}
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
}
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;
BUG/MINOR: ssl: fix memory leak at OCSP loading Fix a memory leak when loading an OCSP file when the file was already loaded elsewhere in the configuration. Indeed, if the OCSP file already exists, a useless chunk_dup() will be done during the load. To fix it we reverts "ocsp" to "iocsp" like it was done previously. This was introduced by commit 246c024 ("MINOR: ssl: load the ocsp in/from the ckch"). Should fix part of the issue #746. It must be backported in 2.1 and 2.2.
2020-08-06 18:44:32 -04:00
if (ssl_sock_load_ocsp_response(ckch->ocsp_response, iocsp, 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
}
out:
if (cid)
OCSP_CERTID_free(cid);
if (ocsp)
free(ocsp);
if (warn)
free(warn);
return ret;
}
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: 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
static int ssl_sock_load_ocsp(SSL_CTX *ctx, const struct cert_key_and_chain *ckch, 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;
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 bind_conf *bind_conf;
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);
if (qc) {
bind_conf = qc->li->bind_conf;
ctx = qc->xprt_ctx;
}
}
#endif
if (!ctx || !bind_conf) {
/* Must never happen */
ABORT_NOW();
}
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/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 (err < 64 && bind_conf->ca_ignerr & (1ULL << err))
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/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 (err < 64 && bind_conf->crt_ignerr & (1ULL << err))
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
BUILD: ssl: fix recent build breakage on older SSL libs Commit 31af49d ("MEDIUM: ssl: Add options to forge SSL certificates") introduced some dependencies on SSL_CTRL_SET_TLSEXT_HOSTNAME for which a few checks were missing, breaking the build on openssl 0.9.8.
2015-06-17 09:48:26 -04:00
#ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME
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
#ifndef SSL_NO_GENERATE_CERTIFICATES
MINOR: ssl: Add callbacks to set DH/ECDH params for generated certificates Now, A callback is defined for generated certificates to set DH parameters for ephemeral key exchange when required. In same way, when possible, we also defined Elliptic Curve DH (ECDH) parameters.
2015-10-09 05:46:32 -04:00
MINOR: ssl: Support SAN extension for certificate generation The use of Common Name is fading out in favor of the RFC recommended way of using SAN extensions. For example, Chrome from version 58 will only match server name against SAN. The following patch adds SAN extension by default to all generated certificates. The SAN extension will be of type DNS and based on the server name.
2020-08-23 06:58:13 -04:00
/* Configure a DNS SAN extenion on a certificate. */
int ssl_sock_add_san_ext(X509V3_CTX* ctx, X509* cert, const char *servername) {
int failure = 0;
X509_EXTENSION *san_ext = NULL;
CONF *conf = NULL;
struct buffer *san_name = get_trash_chunk();
conf = NCONF_new(NULL);
if (!conf) {
failure = 1;
goto cleanup;
}
/* Build an extension based on the DNS entry above */
chunk_appendf(san_name, "DNS:%s", servername);
san_ext = X509V3_EXT_nconf_nid(conf, ctx, NID_subject_alt_name, san_name->area);
if (!san_ext) {
failure = 1;
goto cleanup;
}
/* Add the extension */
if (!X509_add_ext(cert, san_ext, -1 /* Add to end */)) {
failure = 1;
goto cleanup;
}
/* Success */
failure = 0;
cleanup:
if (NULL != san_ext) X509_EXTENSION_free(san_ext);
if (NULL != conf) NCONF_free(conf);
return failure;
}
MINOR: ssl: Export functions to manipulate generated certificates Following functions are now available in the SSL public API: * ssl_sock_create_cert * ssl_sock_get_generated_cert * ssl_sock_set_generated_cert * ssl_sock_generated_cert_serial These functions could be used to create a certificate by hand, set it in the cache used to store generated certificates and retrieve it. Here is an example (pseudo code): X509 *cacert = ...; EVP_PKEY *capkey = ...; char *servername = ...; unsigned int serial; serial = ssl_sock_generated_cert_serial(servername, strlen(servername)); if (!ssl_sock_get_generated_cert(serial, cacert)) { SSL_CTX *ctx = ssl_sock_create_cert(servername, serial, cacert, capkey); ssl_sock_set_generated_cert(ctx, serial, cacert); }
2015-06-11 07:39:32 -04:00
/* Create a X509 certificate with the specified servername and serial. This
* function returns a SSL_CTX object or NULL if an error occurs. */
MINOR: ssl: Add support for EC for the CA used to sign generated certificates This is done by adding EVP_PKEY_EC type in supported types for the CA private key when we get the message digest used to sign a generated X509 certificate. So now, we support DSA, RSA and EC private keys. And to be sure, when the type of the private key is not directly supported, we get its default message digest using the function 'EVP_PKEY_get_default_digest_nid'. We also use the key of the default certificate instead of generated it. So we are sure to use the same key type instead of always using a RSA key.
2015-10-09 05:15:03 -04:00
static SSL_CTX *
BUG/MINOR: ssl: Be sure to use unique serial for regenerated certificates The serial number for a generated certificate was computed using the requested servername, without any variable/random part. It is not a problem from the moment it is not regenerated. But if the cache is disabled or when the certificate is evicted from the cache, we may need to regenerate it. It is important to not reuse the same serial number for the new certificate. Else clients (especially browsers) trigger a warning because 2 certificates issued by the same CA have the same serial number. So now, the serial is a static variable initialized with now_ms (internal date in milliseconds) and incremented at each new certificate generation. (Ref MPS-2031)
2015-11-12 05:35:51 -05:00
ssl_sock_do_create_cert(const char *servername, struct bind_conf *bind_conf, SSL *ssl)
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
{
MEDIUM: ssl: Support certificate chaining for certificate generation haproxy supports generating SSL certificates based on SNI using a provided CA signing certificate. Because CA certificates may be signed by multiple CAs, in some scenarios, it is neccesary for the server to attach the trust chain in addition to the generated certificate. The following patch adds the ability to serve the entire trust chain with the generated certificate. The chain is loaded from the provided `ca-sign-file` PEM file.
2020-08-23 06:58:12 -04:00
X509 *cacert = bind_conf->ca_sign_ckch->cert;
EVP_PKEY *capkey = bind_conf->ca_sign_ckch->key;
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
SSL_CTX *ssl_ctx = NULL;
X509 *newcrt = NULL;
EVP_PKEY *pkey = NULL;
BUILD: ssl: replace SSL_CTX_get0_privatekey for openssl < 1.0.2 Commit 48a8332a introduce SSL_CTX_get0_privatekey in openssl-compat.h but SSL_CTX_get0_privatekey access internal structure and can't be a candidate to openssl-compat.h. The workaround with openssl < 1.0.2 is to use SSL_new then SSL_get_privatekey.
2017-08-11 04:56:00 -04:00
SSL *tmp_ssl = NULL;
MINOR: ssl: cleanup old openssl API call For generate-certificates, X509V3_EXT_conf is used but it's an old API call: X509V3_EXT_nconf must be preferred. Openssl compatibility is ok because it's inside #ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME, introduce 5 years after X509V3_EXT_nconf.
2018-10-01 12:41:36 -04:00
CONF *ctmp = NULL;
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
X509_NAME *name;
const EVP_MD *digest;
X509V3_CTX ctx;
unsigned int 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
int key_type;
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
BUG/MEDIUM: ssl: Fix regression about certificates generation Since the commit f6b37c67 ["BUG/MEDIUM: ssl: in bind line, ssl-options after 'crt' are ignored."], the certificates generation is broken. To generate a certificate, we retrieved the private key of the default certificate using the SSL object. But since the commit f6b37c67, the SSL object is created with a dummy certificate (initial_ctx). So to fix the bug, we use directly the default certificate in the bind_conf structure. We use SSL_CTX_get0_privatekey function to do so. Because this function does not exist for OpenSSL < 1.0.2 and for LibreSSL, it has been added in openssl-compat.h with the right #ifdef.
2017-07-28 10:56:09 -04:00
/* Get the private key of the default certificate and use it */
BUILD: ssl: fine guard for SSL_CTX_get0_privatekey call SSL_CTX_get0_privatekey is openssl/boringssl specific function present since openssl-1.0.2, let us define readable guard for it, not depending on HA_OPENSSL_VERSION
2020-12-18 17:12:12 -05:00
#ifdef HAVE_SSL_CTX_get0_privatekey
BUILD: ssl: replace SSL_CTX_get0_privatekey for openssl < 1.0.2 Commit 48a8332a introduce SSL_CTX_get0_privatekey in openssl-compat.h but SSL_CTX_get0_privatekey access internal structure and can't be a candidate to openssl-compat.h. The workaround with openssl < 1.0.2 is to use SSL_new then SSL_get_privatekey.
2017-08-11 04:56:00 -04:00
pkey = SSL_CTX_get0_privatekey(bind_conf->default_ctx);
#else
tmp_ssl = SSL_new(bind_conf->default_ctx);
if (tmp_ssl)
pkey = SSL_get_privatekey(tmp_ssl);
#endif
if (!pkey)
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
goto mkcert_error;
/* Create the certificate */
if (!(newcrt = X509_new()))
goto mkcert_error;
/* Set version number for the certificate (X509v3) and the serial
* number */
if (X509_set_version(newcrt, 2L) != 1)
goto mkcert_error;
CLEANUP: atomic: add an explicit _FETCH variant for add/sub/and/or Currently our atomic ops return a value but it's never known whether the fetch is done before or after the operation, which causes some confusion each time the value is desired. Let's create an explicit variant of these operations suffixed with _FETCH to explicitly mention that the fetch occurs after the operation, and make use of it at the few call places.
2021-04-06 05:44:07 -04:00
ASN1_INTEGER_set(X509_get_serialNumber(newcrt), _HA_ATOMIC_ADD_FETCH(&ssl_ctx_serial, 1));
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
/* Set duration for the certificate */
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
if (!X509_gmtime_adj(X509_getm_notBefore(newcrt), (long)-60*60*24) ||
!X509_gmtime_adj(X509_getm_notAfter(newcrt),(long)60*60*24*365))
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
goto mkcert_error;
/* set public key in the certificate */
if (X509_set_pubkey(newcrt, pkey) != 1)
goto mkcert_error;
/* Set issuer name from the CA */
if (!(name = X509_get_subject_name(cacert)))
goto mkcert_error;
if (X509_set_issuer_name(newcrt, name) != 1)
goto mkcert_error;
/* Set the subject name using the same, but the CN */
name = X509_NAME_dup(name);
if (X509_NAME_add_entry_by_txt(name, "CN", MBSTRING_ASC,
(const unsigned char *)servername,
-1, -1, 0) != 1) {
X509_NAME_free(name);
goto mkcert_error;
}
if (X509_set_subject_name(newcrt, name) != 1) {
X509_NAME_free(name);
goto mkcert_error;
}
X509_NAME_free(name);
/* Add x509v3 extensions as specified */
MINOR: ssl: cleanup old openssl API call For generate-certificates, X509V3_EXT_conf is used but it's an old API call: X509V3_EXT_nconf must be preferred. Openssl compatibility is ok because it's inside #ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME, introduce 5 years after X509V3_EXT_nconf.
2018-10-01 12:41:36 -04:00
ctmp = NCONF_new(NULL);
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
X509V3_set_ctx(&ctx, cacert, newcrt, NULL, NULL, 0);
for (i = 0; i < X509V3_EXT_SIZE; i++) {
X509_EXTENSION *ext;
MINOR: ssl: cleanup old openssl API call For generate-certificates, X509V3_EXT_conf is used but it's an old API call: X509V3_EXT_nconf must be preferred. Openssl compatibility is ok because it's inside #ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME, introduce 5 years after X509V3_EXT_nconf.
2018-10-01 12:41:36 -04:00
if (!(ext = X509V3_EXT_nconf(ctmp, &ctx, x509v3_ext_names[i], x509v3_ext_values[i])))
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
goto mkcert_error;
if (!X509_add_ext(newcrt, ext, -1)) {
X509_EXTENSION_free(ext);
goto mkcert_error;
}
X509_EXTENSION_free(ext);
}
MINOR: ssl: Support SAN extension for certificate generation The use of Common Name is fading out in favor of the RFC recommended way of using SAN extensions. For example, Chrome from version 58 will only match server name against SAN. The following patch adds SAN extension by default to all generated certificates. The SAN extension will be of type DNS and based on the server name.
2020-08-23 06:58:13 -04:00
/* Add SAN extension */
if (ssl_sock_add_san_ext(&ctx, newcrt, servername)) {
goto mkcert_error;
}
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
/* Sign the certificate with the CA private key */
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
key_type = EVP_PKEY_base_id(capkey);
if (key_type == EVP_PKEY_DSA)
digest = EVP_sha1();
else if (key_type == EVP_PKEY_RSA)
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
digest = EVP_sha256();
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 if (key_type == EVP_PKEY_EC)
MINOR: ssl: Add support for EC for the CA used to sign generated certificates This is done by adding EVP_PKEY_EC type in supported types for the CA private key when we get the message digest used to sign a generated X509 certificate. So now, we support DSA, RSA and EC private keys. And to be sure, when the type of the private key is not directly supported, we get its default message digest using the function 'EVP_PKEY_get_default_digest_nid'. We also use the key of the default certificate instead of generated it. So we are sure to use the same key type instead of always using a RSA key.
2015-10-09 05:15:03 -04:00
digest = EVP_sha256();
else {
BUILD: ssl: guard EVP_PKEY_get_default_digest_nid with ASN1_PKEY_CTRL_DEFAULT_MD_NID let us switch to openssl specific macro instead of versions
2021-01-07 01:57:42 -05:00
#ifdef ASN1_PKEY_CTRL_DEFAULT_MD_NID
MINOR: ssl: Add support for EC for the CA used to sign generated certificates This is done by adding EVP_PKEY_EC type in supported types for the CA private key when we get the message digest used to sign a generated X509 certificate. So now, we support DSA, RSA and EC private keys. And to be sure, when the type of the private key is not directly supported, we get its default message digest using the function 'EVP_PKEY_get_default_digest_nid'. We also use the key of the default certificate instead of generated it. So we are sure to use the same key type instead of always using a RSA key.
2015-10-09 05:15:03 -04:00
int nid;
if (EVP_PKEY_get_default_digest_nid(capkey, &nid) <= 0)
goto mkcert_error;
if (!(digest = EVP_get_digestbynid(nid)))
goto mkcert_error;
BUILD: ssl: fix build error introduced in commit 7969a3 with OpenSSL < 1.0.0 The function 'EVP_PKEY_get_default_digest_nid()' was introduced in OpenSSL 1.0.0. So for older version of OpenSSL, compiled with the SNI support, the HAProxy compilation fails with the following error: src/ssl_sock.c: In function 'ssl_sock_do_create_cert': src/ssl_sock.c:1096:7: warning: implicit declaration of function 'EVP_PKEY_get_default_digest_nid' if (EVP_PKEY_get_default_digest_nid(capkey, &nid) <= 0) [...] src/ssl_sock.c:1096: undefined reference to `EVP_PKEY_get_default_digest_nid' collect2: error: ld returned 1 exit status Makefile:760: recipe for target 'haproxy' failed make: *** [haproxy] Error 1 So we must add a #ifdef to check the OpenSSL version (>= 1.0.0) to use this function. It is used to get default signature digest associated to the private key used to sign generated X509 certificates. It is called when the private key differs than EVP_PKEY_RSA, EVP_PKEY_DSA and EVP_PKEY_EC. It should be enough for most of cases.
2015-10-19 07:59:24 -04:00
#else
goto mkcert_error;
#endif
MINOR: ssl: Add support for EC for the CA used to sign generated certificates This is done by adding EVP_PKEY_EC type in supported types for the CA private key when we get the message digest used to sign a generated X509 certificate. So now, we support DSA, RSA and EC private keys. And to be sure, when the type of the private key is not directly supported, we get its default message digest using the function 'EVP_PKEY_get_default_digest_nid'. We also use the key of the default certificate instead of generated it. So we are sure to use the same key type instead of always using a RSA key.
2015-10-09 05:15:03 -04:00
}
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
if (!(X509_sign(newcrt, capkey, digest)))
goto mkcert_error;
/* Create and set the new SSL_CTX */
if (!(ssl_ctx = SSL_CTX_new(SSLv23_server_method())))
goto mkcert_error;
if (!SSL_CTX_use_PrivateKey(ssl_ctx, pkey))
goto mkcert_error;
if (!SSL_CTX_use_certificate(ssl_ctx, newcrt))
goto mkcert_error;
if (!SSL_CTX_check_private_key(ssl_ctx))
goto mkcert_error;
MEDIUM: ssl: Support certificate chaining for certificate generation haproxy supports generating SSL certificates based on SNI using a provided CA signing certificate. Because CA certificates may be signed by multiple CAs, in some scenarios, it is neccesary for the server to attach the trust chain in addition to the generated certificate. The following patch adds the ability to serve the entire trust chain with the generated certificate. The chain is loaded from the provided `ca-sign-file` PEM file.
2020-08-23 06:58:12 -04:00
/* Build chaining the CA cert and the rest of the chain, keep these order */
#if defined(SSL_CTX_add1_chain_cert)
if (!SSL_CTX_add1_chain_cert(ssl_ctx, bind_conf->ca_sign_ckch->cert)) {
goto mkcert_error;
}
if (bind_conf->ca_sign_ckch->chain) {
for (i = 0; i < sk_X509_num(bind_conf->ca_sign_ckch->chain); i++) {
X509 *chain_cert = sk_X509_value(bind_conf->ca_sign_ckch->chain, i);
if (!SSL_CTX_add1_chain_cert(ssl_ctx, chain_cert)) {
goto mkcert_error;
}
}
}
#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
if (newcrt) X509_free(newcrt);
MINOR: ssl: Add support for EC for the CA used to sign generated certificates This is done by adding EVP_PKEY_EC type in supported types for the CA private key when we get the message digest used to sign a generated X509 certificate. So now, we support DSA, RSA and EC private keys. And to be sure, when the type of the private key is not directly supported, we get its default message digest using the function 'EVP_PKEY_get_default_digest_nid'. We also use the key of the default certificate instead of generated it. So we are sure to use the same key type instead of always using a RSA key.
2015-10-09 05:15:03 -04:00
BUILD: ssl: fix build with -DOPENSSL_NO_DH
2017-03-03 11:04:14 -05:00
#ifndef OPENSSL_NO_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
SSL_CTX_set_tmp_dh_callback(ssl_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
ssl_sock_set_tmp_dh_from_pkey(ssl_ctx, pkey);
#endif
BUILD: ssl: fix build with -DOPENSSL_NO_DH
2017-03-03 11:04:14 -05:00
#endif
MINOR: ssl: Remove EC_KEY related calls when creating a certificate In the context of the 'generate-certificates' bind line option, if an 'ecdhe' option is present on the bind line as well, we use the SSL_CTX_set_tmp_ecdh function which was 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). The ECDHE behaviour with OpenSSL 1.0.2 is not the same when using the SSL_CTX_set1_curves function as the one we have on newer versions. Instead of looking for a code that would work exactly the same regardless of the OpenSSL version, we will keep the original code on 1.0.2 and use newer APIs for other versions. This patch should be strictly isofunctional.
2022-02-08 11:45:56 -05:00
#if (HA_OPENSSL_VERSION_NUMBER >= 0x10101000L)
#if defined(SSL_CTX_set1_curves_list)
{
const char *ecdhe = (bind_conf->ssl_conf.ecdhe ? bind_conf->ssl_conf.ecdhe : ECDHE_DEFAULT_CURVE);
if (!SSL_CTX_set1_curves_list(ssl_ctx, ecdhe))
goto end;
}
#endif
#else
MINOR: ssl: Add callbacks to set DH/ECDH params for generated certificates Now, A callback is defined for generated certificates to set DH parameters for ephemeral key exchange when required. In same way, when possible, we also defined Elliptic Curve DH (ECDH) parameters.
2015-10-09 05:46:32 -04:00
#if defined(SSL_CTX_set_tmp_ecdh) && !defined(OPENSSL_NO_ECDH)
{
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 = (bind_conf->ssl_conf.ecdhe ? bind_conf->ssl_conf.ecdhe : ECDHE_DEFAULT_CURVE);
MINOR: ssl: Add callbacks to set DH/ECDH params for generated certificates Now, A callback is defined for generated certificates to set DH parameters for ephemeral key exchange when required. In same way, when possible, we also defined Elliptic Curve DH (ECDH) parameters.
2015-10-09 05:46:32 -04:00
EC_KEY *ecc;
int nid;
if ((nid = OBJ_sn2nid(ecdhe)) == NID_undef)
goto end;
if (!(ecc = EC_KEY_new_by_curve_name(nid)))
goto end;
SSL_CTX_set_tmp_ecdh(ssl_ctx, ecc);
EC_KEY_free(ecc);
}
MINOR: ssl: Remove EC_KEY related calls when creating a certificate In the context of the 'generate-certificates' bind line option, if an 'ecdhe' option is present on the bind line as well, we use the SSL_CTX_set_tmp_ecdh function which was 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). The ECDHE behaviour with OpenSSL 1.0.2 is not the same when using the SSL_CTX_set1_curves function as the one we have on newer versions. Instead of looking for a code that would work exactly the same regardless of the OpenSSL version, we will keep the original code on 1.0.2 and use newer APIs for other versions. This patch should be strictly isofunctional.
2022-02-08 11:45:56 -05:00
#endif /* defined(SSL_CTX_set_tmp_ecdh) && !defined(OPENSSL_NO_ECDH) */
#endif /* HA_OPENSSL_VERSION_NUMBER >= 0x10101000L */
MINOR: ssl: Add callbacks to set DH/ECDH params for generated certificates Now, A callback is defined for generated certificates to set DH parameters for ephemeral key exchange when required. In same way, when possible, we also defined Elliptic Curve DH (ECDH) parameters.
2015-10-09 05:46:32 -04:00
end:
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_ctx;
mkcert_error:
MINOR: ssl: cleanup old openssl API call For generate-certificates, X509V3_EXT_conf is used but it's an old API call: X509V3_EXT_nconf must be preferred. Openssl compatibility is ok because it's inside #ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME, introduce 5 years after X509V3_EXT_nconf.
2018-10-01 12:41:36 -04:00
if (ctmp) NCONF_free(ctmp);
BUILD: ssl: replace SSL_CTX_get0_privatekey for openssl < 1.0.2 Commit 48a8332a introduce SSL_CTX_get0_privatekey in openssl-compat.h but SSL_CTX_get0_privatekey access internal structure and can't be a candidate to openssl-compat.h. The workaround with openssl < 1.0.2 is to use SSL_new then SSL_get_privatekey.
2017-08-11 04:56:00 -04:00
if (tmp_ssl) SSL_free(tmp_ssl);
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
if (ssl_ctx) SSL_CTX_free(ssl_ctx);
if (newcrt) X509_free(newcrt);
return NULL;
}
MINOR: ssl: Add support for EC for the CA used to sign generated certificates This is done by adding EVP_PKEY_EC type in supported types for the CA private key when we get the message digest used to sign a generated X509 certificate. So now, we support DSA, RSA and EC private keys. And to be sure, when the type of the private key is not directly supported, we get its default message digest using the function 'EVP_PKEY_get_default_digest_nid'. We also use the key of the default certificate instead of generated it. So we are sure to use the same key type instead of always using a RSA key.
2015-10-09 05:15:03 -04:00
MINOR: ssl: Export functions to manipulate generated certificates Following functions are now available in the SSL public API: * ssl_sock_create_cert * ssl_sock_get_generated_cert * ssl_sock_set_generated_cert * ssl_sock_generated_cert_serial These functions could be used to create a certificate by hand, set it in the cache used to store generated certificates and retrieve it. Here is an example (pseudo code): X509 *cacert = ...; EVP_PKEY *capkey = ...; char *servername = ...; unsigned int serial; serial = ssl_sock_generated_cert_serial(servername, strlen(servername)); if (!ssl_sock_get_generated_cert(serial, cacert)) { SSL_CTX *ctx = ssl_sock_create_cert(servername, serial, cacert, capkey); ssl_sock_set_generated_cert(ctx, serial, cacert); }
2015-06-11 07:39:32 -04:00
/* Do a lookup for a certificate in the LRU cache used to store generated
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
* certificates and immediately assign it to the SSL session if not null. */
MINOR: ssl: Export functions to manipulate generated certificates Following functions are now available in the SSL public API: * ssl_sock_create_cert * ssl_sock_get_generated_cert * ssl_sock_set_generated_cert * ssl_sock_generated_cert_serial These functions could be used to create a certificate by hand, set it in the cache used to store generated certificates and retrieve it. Here is an example (pseudo code): X509 *cacert = ...; EVP_PKEY *capkey = ...; char *servername = ...; unsigned int serial; serial = ssl_sock_generated_cert_serial(servername, strlen(servername)); if (!ssl_sock_get_generated_cert(serial, cacert)) { SSL_CTX *ctx = ssl_sock_create_cert(servername, serial, cacert, capkey); ssl_sock_set_generated_cert(ctx, serial, cacert); }
2015-06-11 07:39:32 -04:00
SSL_CTX *
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_sock_assign_generated_cert(unsigned int key, struct bind_conf *bind_conf, SSL *ssl)
MINOR: ssl: Export functions to manipulate generated certificates Following functions are now available in the SSL public API: * ssl_sock_create_cert * ssl_sock_get_generated_cert * ssl_sock_set_generated_cert * ssl_sock_generated_cert_serial These functions could be used to create a certificate by hand, set it in the cache used to store generated certificates and retrieve it. Here is an example (pseudo code): X509 *cacert = ...; EVP_PKEY *capkey = ...; char *servername = ...; unsigned int serial; serial = ssl_sock_generated_cert_serial(servername, strlen(servername)); if (!ssl_sock_get_generated_cert(serial, cacert)) { SSL_CTX *ctx = ssl_sock_create_cert(servername, serial, cacert, capkey); ssl_sock_set_generated_cert(ctx, serial, cacert); }
2015-06-11 07:39:32 -04:00
{
struct lru64 *lru = NULL;
if (ssl_ctx_lru_tree) {
BUG/MEDIUM: ssl: properly protect SSL cert generation Commit 821bb9b ("MAJOR: threads/ssl: Make SSL part thread-safe") added insufficient locking to the cert lookup and generation code : it uses lru64_lookup(), which will automatically remove and add a list element to the LRU list. It cannot be simply read-locked. A long-term improvement should consist in using a lockless mechanism in lru64_lookup() to safely move the list element at the head. For now let's simply use a write lock during the lookup. The effect will be minimal since it's used only in conjunction with automatically generated certificates, which are much more expensive and rarely used. This fix must be backported to 1.8.
2018-05-17 04:56:47 -04:00
HA_RWLOCK_WRLOCK(SSL_GEN_CERTS_LOCK, &ssl_ctx_lru_rwlock);
MEDIUM: ssl: Support certificate chaining for certificate generation haproxy supports generating SSL certificates based on SNI using a provided CA signing certificate. Because CA certificates may be signed by multiple CAs, in some scenarios, it is neccesary for the server to attach the trust chain in addition to the generated certificate. The following patch adds the ability to serve the entire trust chain with the generated certificate. The chain is loaded from the provided `ca-sign-file` PEM file.
2020-08-23 06:58:12 -04:00
lru = lru64_lookup(key, ssl_ctx_lru_tree, bind_conf->ca_sign_ckch->cert, 0);
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 (lru && lru->domain) {
if (ssl)
SSL_set_SSL_CTX(ssl, (SSL_CTX *)lru->data);
BUG/MEDIUM: ssl: properly protect SSL cert generation Commit 821bb9b ("MAJOR: threads/ssl: Make SSL part thread-safe") added insufficient locking to the cert lookup and generation code : it uses lru64_lookup(), which will automatically remove and add a list element to the LRU list. It cannot be simply read-locked. A long-term improvement should consist in using a lockless mechanism in lru64_lookup() to safely move the list element at the head. For now let's simply use a write lock during the lookup. The effect will be minimal since it's used only in conjunction with automatically generated certificates, which are much more expensive and rarely used. This fix must be backported to 1.8.
2018-05-17 04:56:47 -04:00
HA_RWLOCK_WRUNLOCK(SSL_GEN_CERTS_LOCK, &ssl_ctx_lru_rwlock);
MINOR: ssl: Export functions to manipulate generated certificates Following functions are now available in the SSL public API: * ssl_sock_create_cert * ssl_sock_get_generated_cert * ssl_sock_set_generated_cert * ssl_sock_generated_cert_serial These functions could be used to create a certificate by hand, set it in the cache used to store generated certificates and retrieve it. Here is an example (pseudo code): X509 *cacert = ...; EVP_PKEY *capkey = ...; char *servername = ...; unsigned int serial; serial = ssl_sock_generated_cert_serial(servername, strlen(servername)); if (!ssl_sock_get_generated_cert(serial, cacert)) { SSL_CTX *ctx = ssl_sock_create_cert(servername, serial, cacert, capkey); ssl_sock_set_generated_cert(ctx, serial, cacert); }
2015-06-11 07:39:32 -04:00
return (SSL_CTX *)lru->data;
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
}
BUG/MEDIUM: ssl: properly protect SSL cert generation Commit 821bb9b ("MAJOR: threads/ssl: Make SSL part thread-safe") added insufficient locking to the cert lookup and generation code : it uses lru64_lookup(), which will automatically remove and add a list element to the LRU list. It cannot be simply read-locked. A long-term improvement should consist in using a lockless mechanism in lru64_lookup() to safely move the list element at the head. For now let's simply use a write lock during the lookup. The effect will be minimal since it's used only in conjunction with automatically generated certificates, which are much more expensive and rarely used. This fix must be backported to 1.8.
2018-05-17 04:56:47 -04:00
HA_RWLOCK_WRUNLOCK(SSL_GEN_CERTS_LOCK, &ssl_ctx_lru_rwlock);
MINOR: ssl: Export functions to manipulate generated certificates Following functions are now available in the SSL public API: * ssl_sock_create_cert * ssl_sock_get_generated_cert * ssl_sock_set_generated_cert * ssl_sock_generated_cert_serial These functions could be used to create a certificate by hand, set it in the cache used to store generated certificates and retrieve it. Here is an example (pseudo code): X509 *cacert = ...; EVP_PKEY *capkey = ...; char *servername = ...; unsigned int serial; serial = ssl_sock_generated_cert_serial(servername, strlen(servername)); if (!ssl_sock_get_generated_cert(serial, cacert)) { SSL_CTX *ctx = ssl_sock_create_cert(servername, serial, cacert, capkey); ssl_sock_set_generated_cert(ctx, serial, cacert); }
2015-06-11 07:39:32 -04:00
}
return NULL;
}
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
/* Same as <ssl_sock_assign_generated_cert> but without SSL session. This
* function is not thread-safe, it should only be used to check if a certificate
* exists in the lru cache (with no warranty it will not be removed by another
* thread). It is kept for backward compatibility. */
SSL_CTX *
ssl_sock_get_generated_cert(unsigned int key, struct bind_conf *bind_conf)
{
return ssl_sock_assign_generated_cert(key, bind_conf, NULL);
}
BUG/MINOR: ssl: fix management of the cache where forged certificates are stored First, the LRU cache must be initialized after the configuration parsing to correctly set its size. Next, the function 'ssl_sock_set_generated_cert' returns -1 when an error occurs (0 if success). In that case, the caller is responsible to free the memory allocated for the certificate. Finally, when a SSL certificate is generated by HAProxy but cannot be inserted in the cache, it must be freed when the SSL connection is closed. This happens when 'tune.ssl.ssl-ctx-cache-size' is set to 0.
2015-07-28 10:03:47 -04:00
/* Set a certificate int the LRU cache used to store generated
* certificate. Return 0 on success, otherwise -1 */
int
BUG/MINOR: ssl: Be sure to use unique serial for regenerated certificates The serial number for a generated certificate was computed using the requested servername, without any variable/random part. It is not a problem from the moment it is not regenerated. But if the cache is disabled or when the certificate is evicted from the cache, we may need to regenerate it. It is important to not reuse the same serial number for the new certificate. Else clients (especially browsers) trigger a warning because 2 certificates issued by the same CA have the same serial number. So now, the serial is a static variable initialized with now_ms (internal date in milliseconds) and incremented at each new certificate generation. (Ref MPS-2031)
2015-11-12 05:35:51 -05:00
ssl_sock_set_generated_cert(SSL_CTX *ssl_ctx, unsigned int key, struct bind_conf *bind_conf)
MINOR: ssl: Export functions to manipulate generated certificates Following functions are now available in the SSL public API: * ssl_sock_create_cert * ssl_sock_get_generated_cert * ssl_sock_set_generated_cert * ssl_sock_generated_cert_serial These functions could be used to create a certificate by hand, set it in the cache used to store generated certificates and retrieve it. Here is an example (pseudo code): X509 *cacert = ...; EVP_PKEY *capkey = ...; char *servername = ...; unsigned int serial; serial = ssl_sock_generated_cert_serial(servername, strlen(servername)); if (!ssl_sock_get_generated_cert(serial, cacert)) { SSL_CTX *ctx = ssl_sock_create_cert(servername, serial, cacert, capkey); ssl_sock_set_generated_cert(ctx, serial, cacert); }
2015-06-11 07:39:32 -04:00
{
struct lru64 *lru = NULL;
if (ssl_ctx_lru_tree) {
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_GEN_CERTS_LOCK, &ssl_ctx_lru_rwlock);
MEDIUM: ssl: Support certificate chaining for certificate generation haproxy supports generating SSL certificates based on SNI using a provided CA signing certificate. Because CA certificates may be signed by multiple CAs, in some scenarios, it is neccesary for the server to attach the trust chain in addition to the generated certificate. The following patch adds the ability to serve the entire trust chain with the generated certificate. The chain is loaded from the provided `ca-sign-file` PEM file.
2020-08-23 06:58:12 -04:00
lru = lru64_get(key, ssl_ctx_lru_tree, bind_conf->ca_sign_ckch->cert, 0);
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 (!lru) {
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_GEN_CERTS_LOCK, &ssl_ctx_lru_rwlock);
BUG/MINOR: ssl: fix management of the cache where forged certificates are stored First, the LRU cache must be initialized after the configuration parsing to correctly set its size. Next, the function 'ssl_sock_set_generated_cert' returns -1 when an error occurs (0 if success). In that case, the caller is responsible to free the memory allocated for the certificate. Finally, when a SSL certificate is generated by HAProxy but cannot be inserted in the cache, it must be freed when the SSL connection is closed. This happens when 'tune.ssl.ssl-ctx-cache-size' is set to 0.
2015-07-28 10:03:47 -04:00
return -1;
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: Export functions to manipulate generated certificates Following functions are now available in the SSL public API: * ssl_sock_create_cert * ssl_sock_get_generated_cert * ssl_sock_set_generated_cert * ssl_sock_generated_cert_serial These functions could be used to create a certificate by hand, set it in the cache used to store generated certificates and retrieve it. Here is an example (pseudo code): X509 *cacert = ...; EVP_PKEY *capkey = ...; char *servername = ...; unsigned int serial; serial = ssl_sock_generated_cert_serial(servername, strlen(servername)); if (!ssl_sock_get_generated_cert(serial, cacert)) { SSL_CTX *ctx = ssl_sock_create_cert(servername, serial, cacert, capkey); ssl_sock_set_generated_cert(ctx, serial, cacert); }
2015-06-11 07:39:32 -04:00
if (lru->domain && lru->data)
lru->free((SSL_CTX *)lru->data);
MEDIUM: ssl: Support certificate chaining for certificate generation haproxy supports generating SSL certificates based on SNI using a provided CA signing certificate. Because CA certificates may be signed by multiple CAs, in some scenarios, it is neccesary for the server to attach the trust chain in addition to the generated certificate. The following patch adds the ability to serve the entire trust chain with the generated certificate. The chain is loaded from the provided `ca-sign-file` PEM file.
2020-08-23 06:58:12 -04:00
lru64_commit(lru, ssl_ctx, bind_conf->ca_sign_ckch->cert, 0, (void (*)(void *))SSL_CTX_free);
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_GEN_CERTS_LOCK, &ssl_ctx_lru_rwlock);
BUG/MINOR: ssl: fix management of the cache where forged certificates are stored First, the LRU cache must be initialized after the configuration parsing to correctly set its size. Next, the function 'ssl_sock_set_generated_cert' returns -1 when an error occurs (0 if success). In that case, the caller is responsible to free the memory allocated for the certificate. Finally, when a SSL certificate is generated by HAProxy but cannot be inserted in the cache, it must be freed when the SSL connection is closed. This happens when 'tune.ssl.ssl-ctx-cache-size' is set to 0.
2015-07-28 10:03:47 -04:00
return 0;
MINOR: ssl: Export functions to manipulate generated certificates Following functions are now available in the SSL public API: * ssl_sock_create_cert * ssl_sock_get_generated_cert * ssl_sock_set_generated_cert * ssl_sock_generated_cert_serial These functions could be used to create a certificate by hand, set it in the cache used to store generated certificates and retrieve it. Here is an example (pseudo code): X509 *cacert = ...; EVP_PKEY *capkey = ...; char *servername = ...; unsigned int serial; serial = ssl_sock_generated_cert_serial(servername, strlen(servername)); if (!ssl_sock_get_generated_cert(serial, cacert)) { SSL_CTX *ctx = ssl_sock_create_cert(servername, serial, cacert, capkey); ssl_sock_set_generated_cert(ctx, serial, cacert); }
2015-06-11 07:39:32 -04:00
}
BUG/MINOR: ssl: fix management of the cache where forged certificates are stored First, the LRU cache must be initialized after the configuration parsing to correctly set its size. Next, the function 'ssl_sock_set_generated_cert' returns -1 when an error occurs (0 if success). In that case, the caller is responsible to free the memory allocated for the certificate. Finally, when a SSL certificate is generated by HAProxy but cannot be inserted in the cache, it must be freed when the SSL connection is closed. This happens when 'tune.ssl.ssl-ctx-cache-size' is set to 0.
2015-07-28 10:03:47 -04:00
return -1;
MINOR: ssl: Export functions to manipulate generated certificates Following functions are now available in the SSL public API: * ssl_sock_create_cert * ssl_sock_get_generated_cert * ssl_sock_set_generated_cert * ssl_sock_generated_cert_serial These functions could be used to create a certificate by hand, set it in the cache used to store generated certificates and retrieve it. Here is an example (pseudo code): X509 *cacert = ...; EVP_PKEY *capkey = ...; char *servername = ...; unsigned int serial; serial = ssl_sock_generated_cert_serial(servername, strlen(servername)); if (!ssl_sock_get_generated_cert(serial, cacert)) { SSL_CTX *ctx = ssl_sock_create_cert(servername, serial, cacert, capkey); ssl_sock_set_generated_cert(ctx, serial, cacert); }
2015-06-11 07:39:32 -04:00
}
BUG/MINOR: ssl: Be sure to use unique serial for regenerated certificates The serial number for a generated certificate was computed using the requested servername, without any variable/random part. It is not a problem from the moment it is not regenerated. But if the cache is disabled or when the certificate is evicted from the cache, we may need to regenerate it. It is important to not reuse the same serial number for the new certificate. Else clients (especially browsers) trigger a warning because 2 certificates issued by the same CA have the same serial number. So now, the serial is a static variable initialized with now_ms (internal date in milliseconds) and incremented at each new certificate generation. (Ref MPS-2031)
2015-11-12 05:35:51 -05:00
/* Compute the key of the certificate. */
MINOR: ssl: Export functions to manipulate generated certificates Following functions are now available in the SSL public API: * ssl_sock_create_cert * ssl_sock_get_generated_cert * ssl_sock_set_generated_cert * ssl_sock_generated_cert_serial These functions could be used to create a certificate by hand, set it in the cache used to store generated certificates and retrieve it. Here is an example (pseudo code): X509 *cacert = ...; EVP_PKEY *capkey = ...; char *servername = ...; unsigned int serial; serial = ssl_sock_generated_cert_serial(servername, strlen(servername)); if (!ssl_sock_get_generated_cert(serial, cacert)) { SSL_CTX *ctx = ssl_sock_create_cert(servername, serial, cacert, capkey); ssl_sock_set_generated_cert(ctx, serial, cacert); }
2015-06-11 07:39:32 -04:00
unsigned int
BUG/MINOR: ssl: Be sure to use unique serial for regenerated certificates The serial number for a generated certificate was computed using the requested servername, without any variable/random part. It is not a problem from the moment it is not regenerated. But if the cache is disabled or when the certificate is evicted from the cache, we may need to regenerate it. It is important to not reuse the same serial number for the new certificate. Else clients (especially browsers) trigger a warning because 2 certificates issued by the same CA have the same serial number. So now, the serial is a static variable initialized with now_ms (internal date in milliseconds) and incremented at each new certificate generation. (Ref MPS-2031)
2015-11-12 05:35:51 -05:00
ssl_sock_generated_cert_key(const void *data, size_t len)
MINOR: ssl: Export functions to manipulate generated certificates Following functions are now available in the SSL public API: * ssl_sock_create_cert * ssl_sock_get_generated_cert * ssl_sock_set_generated_cert * ssl_sock_generated_cert_serial These functions could be used to create a certificate by hand, set it in the cache used to store generated certificates and retrieve it. Here is an example (pseudo code): X509 *cacert = ...; EVP_PKEY *capkey = ...; char *servername = ...; unsigned int serial; serial = ssl_sock_generated_cert_serial(servername, strlen(servername)); if (!ssl_sock_get_generated_cert(serial, cacert)) { SSL_CTX *ctx = ssl_sock_create_cert(servername, serial, cacert, capkey); ssl_sock_set_generated_cert(ctx, serial, cacert); }
2015-06-11 07:39:32 -04:00
{
return XXH32(data, len, ssl_ctx_lru_seed);
}
BUG/MAJOR: ssl: free the generated SSL_CTX if the LRU cache is disabled Kim Seri reported that haproxy 1.6.0 crashes after a few requests when a bind line has SSL enabled with more than one certificate. This was caused by an insufficient condition to free generated certs during ssl_sock_close() which can also catch other certs. Christopher Faulet analysed the situation like this : ------- First the LRU tree is only initialized when the SSL certs generation is configured on a bind line. So, in the most of cases, it is NULL (it is not the same thing than empty). When the SSL certs generation is used, if the cache is not NULL, a such certificate is pushed in the cache and there is no need to release it when the connection is closed. But it can be disabled in the configuration. So in that case, we must free the generated certificate when the connection is closed. Then here, we have really a bug. Here is the buggy part: 3125) if (conn->xprt_ctx) { 3126) #ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME 3127) if (!ssl_ctx_lru_tree && objt_listener(conn->target)) { 3128) SSL_CTX *ctx = SSL_get_SSL_CTX(conn->xprt_ctx); 3129) if (ctx != 3130) SSL_CTX_free(ctx); 3131) } 3133) SSL_free(conn->xprt_ctx); 3134) conn->xprt_ctx = NULL; 3135) sslconns--; 3136) } The check on the line 3127 is not enough to determine if this is a generated certificate or not. Because ssl_ctx_lru_tree is NULL, generated certificates, if any, must be freed. But here ctx should also be compared to all SNI certificates and not only to default_ctx. Because of this bug, when a SNI certificate is used for a connection, it is erroneously freed when this connection is closed. ------- Christopher provided this reliable reproducer : ---------- global tune.ssl.default-dh-param 2048 daemon listen ssl_server mode tcp bind 127.0.0.1:4443 ssl crt srv1.test.com.pem crt srv2.test.com.pem timeout connect 5000 timeout client 30000 timeout server 30000 server srv A.B.C.D:80 You just need to generate 2 SSL certificates with 2 CN (here srv1.test.com and srv2.test.com). Then, by doing SSL requests with the first CN, there is no problem. But with the second CN, it should segfault on the 2nd request. openssl s_client -connect 127.0.0.1:4443 -servername srv1.test.com // OK openssl s_client -connect 127.0.0.1:4443 -servername srv1.test.com // OK But, openssl s_client -connect 127.0.0.1:4443 -servername srv2.test.com // OK openssl s_client -connect 127.0.0.1:4443 -servername srv2.test.com // KO ----------- A long discussion led to the following proposal which this patch implements : - the cert is generated. It gets a refcount = 1. - we assign it to the SSL. Its refcount becomes two. - we try to insert it into the tree. The tree will handle its freeing using SSL_CTX_free() during eviction. - if we can't insert into the tree because the tree is disabled, then we have to call SSL_CTX_free() ourselves, then we'd rather do it immediately. It will more closely mimmick the case where the cert is added to the tree and immediately evicted by concurrent activity on the cache. - we never have to call SSL_CTX_free() during ssl_sock_close() because the SSL session only relies on openssl doing the right thing based on the refcount only. - thus we never need to know how the cert was created since the SSL_CTX_free() is either guaranteed or already done for generated certs, and this protects other ones against any accidental call to SSL_CTX_free() without having to track where the cert comes from. This patch also reduces the inter-dependence between the LRU tree and the SSL stack, so it should cause less sweating to migrate to threads later. This bug is specific to 1.6.0, as it was introduced after dev7 by this fix : d2cab92 ("BUG/MINOR: ssl: fix management of the cache where forged certificates are stored") Thus a backport to 1.6 is required, but not to 1.5.
2015-10-20 09:16:01 -04:00
/* Generate a cert and immediately assign it to the SSL session so that the cert's
* refcount is maintained regardless of the cert's presence in the LRU cache.
*/
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
static int
MINOR: ssl: Add support for EC for the CA used to sign generated certificates This is done by adding EVP_PKEY_EC type in supported types for the CA private key when we get the message digest used to sign a generated X509 certificate. So now, we support DSA, RSA and EC private keys. And to be sure, when the type of the private key is not directly supported, we get its default message digest using the function 'EVP_PKEY_get_default_digest_nid'. We also use the key of the default certificate instead of generated it. So we are sure to use the same key type instead of always using a RSA key.
2015-10-09 05:15:03 -04:00
ssl_sock_generate_certificate(const char *servername, struct bind_conf *bind_conf, SSL *ssl)
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
{
MEDIUM: ssl: Support certificate chaining for certificate generation haproxy supports generating SSL certificates based on SNI using a provided CA signing certificate. Because CA certificates may be signed by multiple CAs, in some scenarios, it is neccesary for the server to attach the trust chain in addition to the generated certificate. The following patch adds the ability to serve the entire trust chain with the generated certificate. The chain is loaded from the provided `ca-sign-file` PEM file.
2020-08-23 06:58:12 -04:00
X509 *cacert = bind_conf->ca_sign_ckch->cert;
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
SSL_CTX *ssl_ctx = NULL;
struct lru64 *lru = NULL;
BUG/MINOR: ssl: Be sure to use unique serial for regenerated certificates The serial number for a generated certificate was computed using the requested servername, without any variable/random part. It is not a problem from the moment it is not regenerated. But if the cache is disabled or when the certificate is evicted from the cache, we may need to regenerate it. It is important to not reuse the same serial number for the new certificate. Else clients (especially browsers) trigger a warning because 2 certificates issued by the same CA have the same serial number. So now, the serial is a static variable initialized with now_ms (internal date in milliseconds) and incremented at each new certificate generation. (Ref MPS-2031)
2015-11-12 05:35:51 -05:00
unsigned int key;
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
BUG/MINOR: ssl: Be sure to use unique serial for regenerated certificates The serial number for a generated certificate was computed using the requested servername, without any variable/random part. It is not a problem from the moment it is not regenerated. But if the cache is disabled or when the certificate is evicted from the cache, we may need to regenerate it. It is important to not reuse the same serial number for the new certificate. Else clients (especially browsers) trigger a warning because 2 certificates issued by the same CA have the same serial number. So now, the serial is a static variable initialized with now_ms (internal date in milliseconds) and incremented at each new certificate generation. (Ref MPS-2031)
2015-11-12 05:35:51 -05:00
key = ssl_sock_generated_cert_key(servername, strlen(servername));
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
if (ssl_ctx_lru_tree) {
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_GEN_CERTS_LOCK, &ssl_ctx_lru_rwlock);
BUG/MINOR: ssl: Be sure to use unique serial for regenerated certificates The serial number for a generated certificate was computed using the requested servername, without any variable/random part. It is not a problem from the moment it is not regenerated. But if the cache is disabled or when the certificate is evicted from the cache, we may need to regenerate it. It is important to not reuse the same serial number for the new certificate. Else clients (especially browsers) trigger a warning because 2 certificates issued by the same CA have the same serial number. So now, the serial is a static variable initialized with now_ms (internal date in milliseconds) and incremented at each new certificate generation. (Ref MPS-2031)
2015-11-12 05:35:51 -05:00
lru = lru64_get(key, ssl_ctx_lru_tree, cacert, 0);
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
if (lru && lru->domain)
ssl_ctx = (SSL_CTX *)lru->data;
BUG/MINOR: ssl: fix management of the cache where forged certificates are stored First, the LRU cache must be initialized after the configuration parsing to correctly set its size. Next, the function 'ssl_sock_set_generated_cert' returns -1 when an error occurs (0 if success). In that case, the caller is responsible to free the memory allocated for the certificate. Finally, when a SSL certificate is generated by HAProxy but cannot be inserted in the cache, it must be freed when the SSL connection is closed. This happens when 'tune.ssl.ssl-ctx-cache-size' is set to 0.
2015-07-28 10:03:47 -04:00
if (!ssl_ctx && lru) {
BUG/MINOR: ssl: Be sure to use unique serial for regenerated certificates The serial number for a generated certificate was computed using the requested servername, without any variable/random part. It is not a problem from the moment it is not regenerated. But if the cache is disabled or when the certificate is evicted from the cache, we may need to regenerate it. It is important to not reuse the same serial number for the new certificate. Else clients (especially browsers) trigger a warning because 2 certificates issued by the same CA have the same serial number. So now, the serial is a static variable initialized with now_ms (internal date in milliseconds) and incremented at each new certificate generation. (Ref MPS-2031)
2015-11-12 05:35:51 -05:00
ssl_ctx = ssl_sock_do_create_cert(servername, bind_conf, ssl);
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
lru64_commit(lru, ssl_ctx, cacert, 0, (void (*)(void *))SSL_CTX_free);
BUG/MINOR: ssl: fix management of the cache where forged certificates are stored First, the LRU cache must be initialized after the configuration parsing to correctly set its size. Next, the function 'ssl_sock_set_generated_cert' returns -1 when an error occurs (0 if success). In that case, the caller is responsible to free the memory allocated for the certificate. Finally, when a SSL certificate is generated by HAProxy but cannot be inserted in the cache, it must be freed when the SSL connection is closed. This happens when 'tune.ssl.ssl-ctx-cache-size' is set to 0.
2015-07-28 10:03:47 -04:00
}
BUG/MAJOR: ssl: free the generated SSL_CTX if the LRU cache is disabled Kim Seri reported that haproxy 1.6.0 crashes after a few requests when a bind line has SSL enabled with more than one certificate. This was caused by an insufficient condition to free generated certs during ssl_sock_close() which can also catch other certs. Christopher Faulet analysed the situation like this : ------- First the LRU tree is only initialized when the SSL certs generation is configured on a bind line. So, in the most of cases, it is NULL (it is not the same thing than empty). When the SSL certs generation is used, if the cache is not NULL, a such certificate is pushed in the cache and there is no need to release it when the connection is closed. But it can be disabled in the configuration. So in that case, we must free the generated certificate when the connection is closed. Then here, we have really a bug. Here is the buggy part: 3125) if (conn->xprt_ctx) { 3126) #ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME 3127) if (!ssl_ctx_lru_tree && objt_listener(conn->target)) { 3128) SSL_CTX *ctx = SSL_get_SSL_CTX(conn->xprt_ctx); 3129) if (ctx != 3130) SSL_CTX_free(ctx); 3131) } 3133) SSL_free(conn->xprt_ctx); 3134) conn->xprt_ctx = NULL; 3135) sslconns--; 3136) } The check on the line 3127 is not enough to determine if this is a generated certificate or not. Because ssl_ctx_lru_tree is NULL, generated certificates, if any, must be freed. But here ctx should also be compared to all SNI certificates and not only to default_ctx. Because of this bug, when a SNI certificate is used for a connection, it is erroneously freed when this connection is closed. ------- Christopher provided this reliable reproducer : ---------- global tune.ssl.default-dh-param 2048 daemon listen ssl_server mode tcp bind 127.0.0.1:4443 ssl crt srv1.test.com.pem crt srv2.test.com.pem timeout connect 5000 timeout client 30000 timeout server 30000 server srv A.B.C.D:80 You just need to generate 2 SSL certificates with 2 CN (here srv1.test.com and srv2.test.com). Then, by doing SSL requests with the first CN, there is no problem. But with the second CN, it should segfault on the 2nd request. openssl s_client -connect 127.0.0.1:4443 -servername srv1.test.com // OK openssl s_client -connect 127.0.0.1:4443 -servername srv1.test.com // OK But, openssl s_client -connect 127.0.0.1:4443 -servername srv2.test.com // OK openssl s_client -connect 127.0.0.1:4443 -servername srv2.test.com // KO ----------- A long discussion led to the following proposal which this patch implements : - the cert is generated. It gets a refcount = 1. - we assign it to the SSL. Its refcount becomes two. - we try to insert it into the tree. The tree will handle its freeing using SSL_CTX_free() during eviction. - if we can't insert into the tree because the tree is disabled, then we have to call SSL_CTX_free() ourselves, then we'd rather do it immediately. It will more closely mimmick the case where the cert is added to the tree and immediately evicted by concurrent activity on the cache. - we never have to call SSL_CTX_free() during ssl_sock_close() because the SSL session only relies on openssl doing the right thing based on the refcount only. - thus we never need to know how the cert was created since the SSL_CTX_free() is either guaranteed or already done for generated certs, and this protects other ones against any accidental call to SSL_CTX_free() without having to track where the cert comes from. This patch also reduces the inter-dependence between the LRU tree and the SSL stack, so it should cause less sweating to migrate to threads later. This bug is specific to 1.6.0, as it was introduced after dev7 by this fix : d2cab92 ("BUG/MINOR: ssl: fix management of the cache where forged certificates are stored") Thus a backport to 1.6 is required, but not to 1.5.
2015-10-20 09:16:01 -04:00
SSL_set_SSL_CTX(ssl, ssl_ctx);
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_GEN_CERTS_LOCK, &ssl_ctx_lru_rwlock);
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 1;
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
}
BUG/MAJOR: ssl: free the generated SSL_CTX if the LRU cache is disabled Kim Seri reported that haproxy 1.6.0 crashes after a few requests when a bind line has SSL enabled with more than one certificate. This was caused by an insufficient condition to free generated certs during ssl_sock_close() which can also catch other certs. Christopher Faulet analysed the situation like this : ------- First the LRU tree is only initialized when the SSL certs generation is configured on a bind line. So, in the most of cases, it is NULL (it is not the same thing than empty). When the SSL certs generation is used, if the cache is not NULL, a such certificate is pushed in the cache and there is no need to release it when the connection is closed. But it can be disabled in the configuration. So in that case, we must free the generated certificate when the connection is closed. Then here, we have really a bug. Here is the buggy part: 3125) if (conn->xprt_ctx) { 3126) #ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME 3127) if (!ssl_ctx_lru_tree && objt_listener(conn->target)) { 3128) SSL_CTX *ctx = SSL_get_SSL_CTX(conn->xprt_ctx); 3129) if (ctx != 3130) SSL_CTX_free(ctx); 3131) } 3133) SSL_free(conn->xprt_ctx); 3134) conn->xprt_ctx = NULL; 3135) sslconns--; 3136) } The check on the line 3127 is not enough to determine if this is a generated certificate or not. Because ssl_ctx_lru_tree is NULL, generated certificates, if any, must be freed. But here ctx should also be compared to all SNI certificates and not only to default_ctx. Because of this bug, when a SNI certificate is used for a connection, it is erroneously freed when this connection is closed. ------- Christopher provided this reliable reproducer : ---------- global tune.ssl.default-dh-param 2048 daemon listen ssl_server mode tcp bind 127.0.0.1:4443 ssl crt srv1.test.com.pem crt srv2.test.com.pem timeout connect 5000 timeout client 30000 timeout server 30000 server srv A.B.C.D:80 You just need to generate 2 SSL certificates with 2 CN (here srv1.test.com and srv2.test.com). Then, by doing SSL requests with the first CN, there is no problem. But with the second CN, it should segfault on the 2nd request. openssl s_client -connect 127.0.0.1:4443 -servername srv1.test.com // OK openssl s_client -connect 127.0.0.1:4443 -servername srv1.test.com // OK But, openssl s_client -connect 127.0.0.1:4443 -servername srv2.test.com // OK openssl s_client -connect 127.0.0.1:4443 -servername srv2.test.com // KO ----------- A long discussion led to the following proposal which this patch implements : - the cert is generated. It gets a refcount = 1. - we assign it to the SSL. Its refcount becomes two. - we try to insert it into the tree. The tree will handle its freeing using SSL_CTX_free() during eviction. - if we can't insert into the tree because the tree is disabled, then we have to call SSL_CTX_free() ourselves, then we'd rather do it immediately. It will more closely mimmick the case where the cert is added to the tree and immediately evicted by concurrent activity on the cache. - we never have to call SSL_CTX_free() during ssl_sock_close() because the SSL session only relies on openssl doing the right thing based on the refcount only. - thus we never need to know how the cert was created since the SSL_CTX_free() is either guaranteed or already done for generated certs, and this protects other ones against any accidental call to SSL_CTX_free() without having to track where the cert comes from. This patch also reduces the inter-dependence between the LRU tree and the SSL stack, so it should cause less sweating to migrate to threads later. This bug is specific to 1.6.0, as it was introduced after dev7 by this fix : d2cab92 ("BUG/MINOR: ssl: fix management of the cache where forged certificates are stored") Thus a backport to 1.6 is required, but not to 1.5.
2015-10-20 09:16:01 -04:00
else {
BUG/MINOR: ssl: Be sure to use unique serial for regenerated certificates The serial number for a generated certificate was computed using the requested servername, without any variable/random part. It is not a problem from the moment it is not regenerated. But if the cache is disabled or when the certificate is evicted from the cache, we may need to regenerate it. It is important to not reuse the same serial number for the new certificate. Else clients (especially browsers) trigger a warning because 2 certificates issued by the same CA have the same serial number. So now, the serial is a static variable initialized with now_ms (internal date in milliseconds) and incremented at each new certificate generation. (Ref MPS-2031)
2015-11-12 05:35:51 -05:00
ssl_ctx = ssl_sock_do_create_cert(servername, bind_conf, ssl);
BUG/MAJOR: ssl: free the generated SSL_CTX if the LRU cache is disabled Kim Seri reported that haproxy 1.6.0 crashes after a few requests when a bind line has SSL enabled with more than one certificate. This was caused by an insufficient condition to free generated certs during ssl_sock_close() which can also catch other certs. Christopher Faulet analysed the situation like this : ------- First the LRU tree is only initialized when the SSL certs generation is configured on a bind line. So, in the most of cases, it is NULL (it is not the same thing than empty). When the SSL certs generation is used, if the cache is not NULL, a such certificate is pushed in the cache and there is no need to release it when the connection is closed. But it can be disabled in the configuration. So in that case, we must free the generated certificate when the connection is closed. Then here, we have really a bug. Here is the buggy part: 3125) if (conn->xprt_ctx) { 3126) #ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME 3127) if (!ssl_ctx_lru_tree && objt_listener(conn->target)) { 3128) SSL_CTX *ctx = SSL_get_SSL_CTX(conn->xprt_ctx); 3129) if (ctx != 3130) SSL_CTX_free(ctx); 3131) } 3133) SSL_free(conn->xprt_ctx); 3134) conn->xprt_ctx = NULL; 3135) sslconns--; 3136) } The check on the line 3127 is not enough to determine if this is a generated certificate or not. Because ssl_ctx_lru_tree is NULL, generated certificates, if any, must be freed. But here ctx should also be compared to all SNI certificates and not only to default_ctx. Because of this bug, when a SNI certificate is used for a connection, it is erroneously freed when this connection is closed. ------- Christopher provided this reliable reproducer : ---------- global tune.ssl.default-dh-param 2048 daemon listen ssl_server mode tcp bind 127.0.0.1:4443 ssl crt srv1.test.com.pem crt srv2.test.com.pem timeout connect 5000 timeout client 30000 timeout server 30000 server srv A.B.C.D:80 You just need to generate 2 SSL certificates with 2 CN (here srv1.test.com and srv2.test.com). Then, by doing SSL requests with the first CN, there is no problem. But with the second CN, it should segfault on the 2nd request. openssl s_client -connect 127.0.0.1:4443 -servername srv1.test.com // OK openssl s_client -connect 127.0.0.1:4443 -servername srv1.test.com // OK But, openssl s_client -connect 127.0.0.1:4443 -servername srv2.test.com // OK openssl s_client -connect 127.0.0.1:4443 -servername srv2.test.com // KO ----------- A long discussion led to the following proposal which this patch implements : - the cert is generated. It gets a refcount = 1. - we assign it to the SSL. Its refcount becomes two. - we try to insert it into the tree. The tree will handle its freeing using SSL_CTX_free() during eviction. - if we can't insert into the tree because the tree is disabled, then we have to call SSL_CTX_free() ourselves, then we'd rather do it immediately. It will more closely mimmick the case where the cert is added to the tree and immediately evicted by concurrent activity on the cache. - we never have to call SSL_CTX_free() during ssl_sock_close() because the SSL session only relies on openssl doing the right thing based on the refcount only. - thus we never need to know how the cert was created since the SSL_CTX_free() is either guaranteed or already done for generated certs, and this protects other ones against any accidental call to SSL_CTX_free() without having to track where the cert comes from. This patch also reduces the inter-dependence between the LRU tree and the SSL stack, so it should cause less sweating to migrate to threads later. This bug is specific to 1.6.0, as it was introduced after dev7 by this fix : d2cab92 ("BUG/MINOR: ssl: fix management of the cache where forged certificates are stored") Thus a backport to 1.6 is required, but not to 1.5.
2015-10-20 09:16:01 -04:00
SSL_set_SSL_CTX(ssl, ssl_ctx);
/* No LRU cache, this CTX will be released as soon as the session dies */
SSL_CTX_free(ssl_ctx);
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 1;
BUG/MAJOR: ssl: free the generated SSL_CTX if the LRU cache is disabled Kim Seri reported that haproxy 1.6.0 crashes after a few requests when a bind line has SSL enabled with more than one certificate. This was caused by an insufficient condition to free generated certs during ssl_sock_close() which can also catch other certs. Christopher Faulet analysed the situation like this : ------- First the LRU tree is only initialized when the SSL certs generation is configured on a bind line. So, in the most of cases, it is NULL (it is not the same thing than empty). When the SSL certs generation is used, if the cache is not NULL, a such certificate is pushed in the cache and there is no need to release it when the connection is closed. But it can be disabled in the configuration. So in that case, we must free the generated certificate when the connection is closed. Then here, we have really a bug. Here is the buggy part: 3125) if (conn->xprt_ctx) { 3126) #ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME 3127) if (!ssl_ctx_lru_tree && objt_listener(conn->target)) { 3128) SSL_CTX *ctx = SSL_get_SSL_CTX(conn->xprt_ctx); 3129) if (ctx != 3130) SSL_CTX_free(ctx); 3131) } 3133) SSL_free(conn->xprt_ctx); 3134) conn->xprt_ctx = NULL; 3135) sslconns--; 3136) } The check on the line 3127 is not enough to determine if this is a generated certificate or not. Because ssl_ctx_lru_tree is NULL, generated certificates, if any, must be freed. But here ctx should also be compared to all SNI certificates and not only to default_ctx. Because of this bug, when a SNI certificate is used for a connection, it is erroneously freed when this connection is closed. ------- Christopher provided this reliable reproducer : ---------- global tune.ssl.default-dh-param 2048 daemon listen ssl_server mode tcp bind 127.0.0.1:4443 ssl crt srv1.test.com.pem crt srv2.test.com.pem timeout connect 5000 timeout client 30000 timeout server 30000 server srv A.B.C.D:80 You just need to generate 2 SSL certificates with 2 CN (here srv1.test.com and srv2.test.com). Then, by doing SSL requests with the first CN, there is no problem. But with the second CN, it should segfault on the 2nd request. openssl s_client -connect 127.0.0.1:4443 -servername srv1.test.com // OK openssl s_client -connect 127.0.0.1:4443 -servername srv1.test.com // OK But, openssl s_client -connect 127.0.0.1:4443 -servername srv2.test.com // OK openssl s_client -connect 127.0.0.1:4443 -servername srv2.test.com // KO ----------- A long discussion led to the following proposal which this patch implements : - the cert is generated. It gets a refcount = 1. - we assign it to the SSL. Its refcount becomes two. - we try to insert it into the tree. The tree will handle its freeing using SSL_CTX_free() during eviction. - if we can't insert into the tree because the tree is disabled, then we have to call SSL_CTX_free() ourselves, then we'd rather do it immediately. It will more closely mimmick the case where the cert is added to the tree and immediately evicted by concurrent activity on the cache. - we never have to call SSL_CTX_free() during ssl_sock_close() because the SSL session only relies on openssl doing the right thing based on the refcount only. - thus we never need to know how the cert was created since the SSL_CTX_free() is either guaranteed or already done for generated certs, and this protects other ones against any accidental call to SSL_CTX_free() without having to track where the cert comes from. This patch also reduces the inter-dependence between the LRU tree and the SSL stack, so it should cause less sweating to migrate to threads later. This bug is specific to 1.6.0, as it was introduced after dev7 by this fix : d2cab92 ("BUG/MINOR: ssl: fix management of the cache where forged certificates are stored") Thus a backport to 1.6 is required, but not to 1.5.
2015-10-20 09:16:01 -04: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
return 0;
}
static int
ssl_sock_generate_certificate_from_conn(struct bind_conf *bind_conf, SSL *ssl)
{
unsigned int key;
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: 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
MINOR: ssl: switch to conn_get_dst() to retrieve the destination address This replaces conn_get_to_addr() and the subsequent check.
2019-07-17 05:29:32 -04:00
if (conn_get_dst(conn)) {
MINOR: ssl-sock: use conn->dst instead of &conn->addr.to This part can be definitive as the check was already in place.
2019-07-17 08:47:35 -04:00
key = ssl_sock_generated_cert_key(conn->dst, get_addr_len(conn->dst));
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 (ssl_sock_assign_generated_cert(key, bind_conf, 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 1;
}
return 0;
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
}
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 /* !defined SSL_NO_GENERATE_CERTIFICATES */
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
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);
}
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: 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
char *wildp = NULL;
const uint8_t *servername;
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 servername_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
struct ebmb_node *node, *n, *node_ecdsa = NULL, *node_rsa = NULL, *node_anonymous = NULL;
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: Compatible version negotiation implementation (draft-08) At this time haproxy supported only incompatible version negotiation feature which consists in sending a Version Negotiation packet after having received a long packet without compatible value in its version field. This version value is the version use to build the current packet. This patch does not modify this behavior. This patch adds the support for compatible version negotiation feature which allows endpoints to negotiate during the first flight or packets sent by the client the QUIC version to use for the connection (or after the first flight). This is done thanks to "version_information" parameter sent by both endpoints. To be short, the client offers a list of supported versions by preference order. The server (or haproxy listener) chooses the first version it also supported as negotiated version. This implementation has an impact on the tranport parameters handling (in both direcetions). Indeed, the server must sent its version information, but only after received and parsed the client transport parameters). So we cannot encode these parameters at the same time we instantiated a new connection. Add QUIC_TP_DRAFT_VERSION_INFORMATION(0xff73db) new transport parameter. Add tp_version_information new C struct to handle this new parameter. Implement quic_transport_param_enc_version_info() (resp. quic_transport_param_dec_version_info()) to encode (resp. decode) this parameter. Add qc_conn_finalize() which encodes the transport parameters and configure the TLS stack to send them. Add ->negotiated_ictx quic_conn C struct new member to store the Initial QUIC TLS context for the negotiated version. The Initial secrets derivation is version dependent. Rename ->version to ->original_version and add ->negotiated_version to this C struct to reflect the QUIC-VN RFC denomination. Modify most of the QUIC TLS API functions to pass a version as parameter. Export the QUIC version definitions to be reused at least from quic_tp.c (transport parameters. Move the token check after the QUIC connection lookup. As this is the original version which is sent into a Retry packet, and because this original version is stored into the connection, we must check the token after having retreived this connection. Add packet version to traces. See https://datatracker.ietf.org/doc/html/draft-ietf-quic-version-negotiation-08 for more information about this new feature.
2022-06-14 11:40:39 -04:00
extension_data + extension_len) ||
!qc_conn_finalize(qc, 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
goto abort;
}
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;
servername = extension_data;
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: 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
/* without SNI extension, is the default_ctx (need SSL_TLSEXT_ERR_NOACK) */
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) {
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_RDLOCK(SNI_LOCK, &s->sni_lock);
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_sock_switchctx_set(ssl, s->default_ctx);
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: 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;
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
}
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;
}
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;
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
MINOR: ssl: build with recent BoringSSL library BoringSSL switch OPENSSL_VERSION_NUMBER to 1.1.0 for compatibility. Fix BoringSSL call and openssl-compat.h/#define occordingly. This will not break openssl/libressl compat.
2017-10-02 11:12:06 -04:00
if (cipher && SSL_CIPHER_get_auth_nid(cipher) == NID_auth_ecdsa) {
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: 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
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]);
if (!wildp && (trash.area[i] == '.'))
wildp = &trash.area[i];
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: 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: 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: 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
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
/* Look for an ECDSA, RSA and DSA certificate, first in the single
* name and if not found in the wildcard */
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
for (i = 0; i < 2; i++) {
if (i == 0) /* lookup in full qualified names */
node = ebst_lookup(&s->sni_ctx, trash.area);
BUG/MEDIUM: ssl: crt-list negative filters don't work The negative filters which are supposed to exclude a SNI from a wildcard, never worked. Indeed the negative filters were skipped in the code. To fix the issue, this patch looks for negative filters that are on the same line as a the wildcard that just matched. This patch should fix issue #818. It must be backported in 2.2. The problem also exists in versions > 1.8 but the infrastructure required to fix this was only introduced in 2.1. In older versions we should probably change the documentation to state that negative filters are useless.
2020-08-17 08:31:19 -04:00
else if (i == 1 && wildp) /* lookup in wildcards names */
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
node = ebst_lookup(&s->sni_w_ctx, wildp);
else
break;
BUG/MEDIUM: ssl: crt-list negative filters don't work The negative filters which are supposed to exclude a SNI from a wildcard, never worked. Indeed the negative filters were skipped in the code. To fix the issue, this patch looks for negative filters that are on the same line as a the wildcard that just matched. This patch should fix issue #818. It must be backported in 2.2. The problem also exists in versions > 1.8 but the infrastructure required to fix this was only introduced in 2.1. In older versions we should probably change the documentation to state that negative filters are useless.
2020-08-17 08:31:19 -04:00
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
for (n = node; n; n = ebmb_next_dup(n)) {
BUG/MEDIUM: ssl: crt-list negative filters don't work The negative filters which are supposed to exclude a SNI from a wildcard, never worked. Indeed the negative filters were skipped in the code. To fix the issue, this patch looks for negative filters that are on the same line as a the wildcard that just matched. This patch should fix issue #818. It must be backported in 2.2. The problem also exists in versions > 1.8 but the infrastructure required to fix this was only introduced in 2.1. In older versions we should probably change the documentation to state that negative filters are useless.
2020-08-17 08:31:19 -04:00
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
/* lookup a not neg filter */
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 (!container_of(n, struct sni_ctx, name)->neg) {
BUG/MEDIUM: ssl: crt-list negative filters don't work The negative filters which are supposed to exclude a SNI from a wildcard, never worked. Indeed the negative filters were skipped in the code. To fix the issue, this patch looks for negative filters that are on the same line as a the wildcard that just matched. This patch should fix issue #818. It must be backported in 2.2. The problem also exists in versions > 1.8 but the infrastructure required to fix this was only introduced in 2.1. In older versions we should probably change the documentation to state that negative filters are useless.
2020-08-17 08:31:19 -04:00
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) {
CLEANUP: Compare the return value of `XXXcmp()` functions with zero According to coding-style.txt it is recommended to use: `strcmp(a, b) == 0` instead of `!strcmp(a, b)` So let's do this. The change was performed by running the following (very long) coccinelle patch on src/: @@ statement S; expression E; expression F; @@ if ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) ( S | { ... } ) @@ statement S; expression E; expression F; @@ if ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) ( S | { ... } ) @@ expression E; expression F; expression G; @@ ( G && ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( G || ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 && G ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 || G ) @@ expression E; expression F; expression G; @@ ( G && - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( G || - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 && G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 || G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 )
2021-01-02 16:31:53 -05:00
if (sni_tmp->neg && (strcmp((const char *)sni_tmp->name.key, trash.area) == 0)) {
BUG/MEDIUM: ssl: crt-list negative filters don't work The negative filters which are supposed to exclude a SNI from a wildcard, never worked. Indeed the negative filters were skipped in the code. To fix the issue, this patch looks for negative filters that are on the same line as a the wildcard that just matched. This patch should fix issue #818. It must be backported in 2.2. The problem also exists in versions > 1.8 but the infrastructure required to fix this was only introduced in 2.1. In older versions we should probably change the documentation to state that negative filters are useless.
2020-08-17 08:31:19 -04:00
skip = 1;
break;
}
}
if (skip)
continue;
}
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
switch(container_of(n, struct sni_ctx, name)->kinfo.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
case TLSEXT_signature_ecdsa:
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 (!node_ecdsa)
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
node_ecdsa = n;
break;
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
if (!node_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
node_rsa = n;
break;
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
default: /* TLSEXT_signature_anonymous|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
if (!node_anonymous)
node_anonymous = n;
break;
}
}
}
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
}
/* Once the certificates are found, select them depending on what is
* supported in the client and by key_signature priority order: EDSA >
* RSA > DSA */
CLEANUP: ssl: remove poorly readable nested ternary Replace a four level nested ternary expression by an if/else expression in ssl_sock_switchctx_cbk()
2020-08-14 09:30:13 -04:00
if (has_ecdsa_sig && node_ecdsa)
node = node_ecdsa;
else if (has_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) */
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 (node) {
/* switch ctx */
struct ssl_bind_conf *conf = container_of(node, struct sni_ctx, name)->conf;
ssl_sock_switchctx_set(ssl, container_of(node, struct sni_ctx, name)->ctx);
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)
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(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
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) {
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
/* no certificate match, is the default_ctx */
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_RDLOCK(SNI_LOCK, &s->sni_lock);
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_sock_switchctx_set(ssl, s->default_ctx);
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);
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
goto allow_early;
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) {
strncpy(client_sni, trash.area, TLSEXT_MAXLEN_host_name);
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;
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,
extension_data + extension_len) ||
!qc_conn_finalize(qc, 0)) {
return SSL_TLSEXT_ERR_NOACK;
}
}
#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;
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_RDLOCK(SNI_LOCK, &s->sni_lock);
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_switchctx_set(ssl, s->default_ctx);
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);
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
return SSL_TLSEXT_ERR_NOACK;
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: 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: 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
if (s->strict_sni) {
HA_RWLOCK_RDUNLOCK(SNI_LOCK, &s->sni_lock);
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
return SSL_TLSEXT_ERR_ALERT_FATAL;
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
}
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_switchctx_set(ssl, s->default_ctx);
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);
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
return SSL_TLSEXT_ERR_OK;
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
#endif /* SSL_CTRL_SET_TLSEXT_HOSTNAME */
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);
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 */
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_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)
static void ssl_sock_set_tmp_dh_from_pkey(SSL_CTX *ctx, EVP_PKEY *pkey)
{
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: 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 wild = 0, neg = 0;
if (*name == '!') {
neg = 1;
name++;
}
if (*name == '*') {
wild = 1;
name++;
}
/* !* filter is a nop */
if (neg && wild)
return order;
if (*name) {
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
}
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
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
/* replace the default_ctx if required with the instance's ctx. */
if (ckch_inst->is_default) {
SSL_CTX_free(bind_conf->default_ctx);
SSL_CTX_up_ref(ckch_inst->ctx);
bind_conf->default_ctx = ckch_inst->ctx;
MINOR: ssl: Add reference to default ckch instance in bind_conf In order for the link between the cafile_entry and the default ckch instance to be built, we need to give a pointer to the instance during the ssl_sock_prepare_ctx call.
2021-04-13 10:07:29 -04:00
bind_conf->default_inst = 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
}
}
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
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
static int ssl_sock_load_dh_params(SSL_CTX *ctx, const struct cert_key_and_chain *ckch,
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
BUG/MEDIUM: ssl: does not try to free a DH in a ckch ssl_sock_load_dh_params() should not free the DH * of a ckch, or the ckch won't be usable during the next call.
2019-07-31 12:31:34 -04:00
if (ckch && ckch->dh) {
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
dh = ckch->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: 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_sock_set_tmp_dh_from_pkey(ctx, ckch ? ckch->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
* 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
*/
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
static int ssl_sock_load_cert_chain(const char *path, const struct cert_key_and_chain *ckch,
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: 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
}
if (!SSL_CTX_use_certificate(ctx, ckch->cert)) {
memprintf(err, "%sunable to load SSL certificate into SSL Context '%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
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
}
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 (ckch->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
*find_chain = ckch->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;
CLEANUP: ssl: rename ssl_get_issuer_chain to ssl_get0_issuer_chain Rename ssl_get_issuer_chain to ssl_get0_issuer_chain to be consistent with openssl >= 1.0.2 API.
2020-03-23 06:29:11 -04:00
issuer = ssl_get0_issuer_chain(ckch->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)
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 = 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
}
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
/* Load all certs in the ckch into the ctx_chain for the ssl_ctx */
#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)) {
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
memprintf(err, "%sunable to load chain certificate into SSL Context '%s'. Make sure you are linking against Openssl >= 1.0.2.\n",
err && *err ? *err : "", path);
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;
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
STACK_OF(X509) *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
chain = X509_chain_up_ref(*find_chain);
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
while ((ca = sk_X509_shift(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);
sk_X509_pop_free(chain, X509_free);
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.
*/
static int ssl_sock_put_ckch_into_ctx(const char *path, const struct cert_key_and_chain *ckch, SSL_CTX *ctx, char **err)
{
int errcode = 0;
STACK_OF(X509) *find_chain = NULL;
if (SSL_CTX_use_PrivateKey(ctx, ckch->key) <= 0) {
memprintf(err, "%sunable to load SSL private key into SSL Context '%s'.\n",
err && *err ? *err : "", path);
errcode |= ERR_ALERT | ERR_FATAL;
return errcode;
}
/* Load certificate chain */
errcode |= ssl_sock_load_cert_chain(path, ckch, ctx, &find_chain, err);
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);
}
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
errcode |= ssl_sock_load_dh_params(ctx, ckch, path, err);
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
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 (sctl_ex_index >= 0 && ckch->sctl) {
if (ssl_sock_load_sctl(ctx, ckch->sctl) < 0) {
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)
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
/* Load OCSP Info into context */
if (ckch->ocsp_response) {
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
if (ssl_sock_load_ocsp(ctx, ckch, find_chain) < 0) {
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",
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 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:
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.
*/
static int ssl_sock_put_srv_ckch_into_ctx(const char *path, const struct cert_key_and_chain *ckch,
SSL_CTX *ctx, char **err)
{
int errcode = 0;
STACK_OF(X509) *find_chain = NULL;
/* Load the private key */
if (SSL_CTX_use_PrivateKey(ctx, ckch->key) <= 0) {
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 */
errcode |= ssl_sock_load_cert_chain(path, ckch, ctx, &find_chain, err);
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:
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,
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
struct ssl_bind_conf *ssl_conf, char **sni_filter, int fcount, 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: 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
struct cert_key_and_chain *ckch;
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
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
if (!ckchs || !ckchs->ckch)
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
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
ckch = ckchs->ckch;
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
}
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 |= ssl_sock_put_ckch_into_ctx(path, ckch, ctx, err);
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: 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
pkey = X509_get_pubkey(ckch->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: 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
names = X509_get_ext_d2i(ckch->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: 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
xname = X509_get_subject_name(ckch->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: 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
#ifndef SSL_CTRL_SET_TLSEXT_HOSTNAME
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
if (bind_conf->default_ctx) {
MINOR: standard: make memprintf() support a NULL destination Doing so removes many checks that were systematically made because the callees don't know if the caller passed a valid pointer.
2012-09-20 13:43:14 -04:00
memprintf(err, "%sthis version of openssl cannot load multiple SSL certificates.\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;
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
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 (!bind_conf->default_ctx) {
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
bind_conf->default_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
bind_conf->default_ssl_conf = ssl_conf;
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;
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);
MINOR: ssl: Add reference to default ckch instance in bind_conf In order for the link between the cafile_entry and the default ckch instance to be built, we need to give a pointer to the instance during the ssl_sock_prepare_ctx call.
2021-04-13 10:07:29 -04:00
bind_conf->default_inst = ckch_inst;
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) {
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
if (ckch_inst->is_default)
SSL_CTX_free(ctx);
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;
struct cert_key_and_chain *ckch;
struct ckch_inst *ckch_inst = NULL;
int errcode = 0;
*ckchi = NULL;
if (!ckchs || !ckchs->ckch)
return ERR_FATAL;
ckch = ckchs->ckch;
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;
}
errcode |= ssl_sock_put_srv_ckch_into_ctx(path, ckch, ctx, err);
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,
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
char **sni_filter, int fcount, 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 */
CLEANUP: ssl: remove utility functions for bundle Remove the last utility functions for handling the multi-cert bundles and remove the multi-variable from the ckch structure. With this patch, the bundles are completely removed.
2020-09-16 10:17:51 -04:00
errcode |= ckch_inst_new_load_store(path, ckchs, bind_conf, ssl_conf, sni_filter, fcount, 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;
store = entry->node.key;
cfgerr |= ssl_sock_load_ckchs(store->path, store, bind_conf, entry->ssl_conf, entry->filters, entry->fcount, &ckch_inst, err);
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>. */
int ssl_sock_load_cert(char *path, struct bind_conf *bind_conf, char **err)
{
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 ? */
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 */
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_ckchs(path, ckchs, bind_conf, NULL, NULL, 0, &ckch_inst, err);
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;
cfgerr |= ssl_sock_load_ckchs(path, ckchs, bind_conf, NULL, NULL, 0, &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))) {
cfgerr |= ssl_sock_load_ckchs(fp, ckchs, bind_conf, NULL, NULL, 0, &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: 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
cfgerr |= ssl_sock_load_ckchs(fp, ckchs, bind_conf, NULL, NULL, 0, &ckch_inst, err);
}
}
}
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;
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);
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
# 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
static inline void sh_ssl_sess_free_blocks(struct shared_block *first, struct shared_block *block)
{
if (first == block) {
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);
}
}
/* 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)
{
return (struct shared_block *)((unsigned char *)sh_ssl_sess - ((struct shared_block *)NULL)->data);
}
/* 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;
}
/* 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 */
shctx_row_dec_hot(ssl_shctx, first);
/* 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);
shctx_row_inc_hot(ssl_shctx, first);
first->len = sizeof(struct sh_ssl_sess_hdr);
}
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
if (shctx_row_data_append(ssl_shctx, first, NULL, data, data_len) < 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
shctx_row_dec_hot(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
}
shctx_row_dec_hot(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 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: 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
* another thread */
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
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);
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.reused_sess[tid].ptr && s->ssl_ctx.reused_sess[tid].allocated_size >= len) {
ptr = s->ssl_ctx.reused_sess[tid].ptr;
} else {
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
ptr = realloc(s->ssl_ctx.reused_sess[tid].ptr, len);
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;
}
if (s->ssl_ctx.reused_sess[tid].ptr) {
s->ssl_ctx.reused_sess[tid].size = i2d_SSL_SESSION(sess,
&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
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: 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);
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(&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);
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);
MINOR: shctx: rename lock functions Rename lock functions to shctx_lock() and shctx_unlock() to be coherent with the new API.
2017-10-30 18:44:40 -04:00
shctx_lock(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
/* 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);
MINOR: shctx: rename lock functions Rename lock functions to shctx_lock() and shctx_unlock() to be coherent with the new API.
2017-10-30 18:44:40 -04:00
shctx_unlock(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
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 */
MINOR: shctx: rename lock functions Rename lock functions to shctx_lock() and shctx_unlock() to be coherent with the new API.
2017-10-30 18:44:40 -04:00
shctx_lock(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 */
MINOR: shctx: rename lock functions Rename lock functions to shctx_lock() and shctx_unlock() to be coherent with the new API.
2017-10-30 18:44:40 -04:00
shctx_unlock(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
MINOR: shctx: rename lock functions Rename lock functions to shctx_lock() and shctx_unlock() to be coherent with the new API.
2017-10-30 18:44:40 -04:00
shctx_unlock(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;
}
MINOR: shctx: rename lock functions Rename lock functions to shctx_lock() and shctx_unlock() to be coherent with the new API.
2017-10-30 18:44:40 -04:00
shctx_lock(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 */
MINOR: shctx: rename lock functions Rename lock functions to shctx_lock() and shctx_unlock() to be coherent with the new API.
2017-10-30 18:44:40 -04:00
shctx_unlock(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;
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;
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
}
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
X509_STORE *store = SSL_CTX_get_cert_store(ctx);
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
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_CTX_set_keylog_callback(ctx, SSL_CTX_keylog);
#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;
if (ssl_conf_cur)
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
}
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;
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_backend = 1;
/* 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: 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;
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
if (srv->ssl_ctx.alpn_str)
SSL_CTX_set_alpn_protos(ctx, (unsigned char *)srv->ssl_ctx.alpn_str, srv->ssl_ctx.alpn_len);
#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: 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);
}
if (bind_conf->default_ctx) {
MINOR: ssl: Add reference to default ckch instance in bind_conf In order for the link between the cafile_entry and the default ckch instance to be built, we need to give a pointer to the instance during the ssl_sock_prepare_ctx call.
2021-04-13 10:07:29 -04:00
errcode |= ssl_sock_prep_ctx_and_inst(bind_conf, bind_conf->default_ssl_conf, bind_conf->default_ctx, bind_conf->default_inst, &errmsg);
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/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: 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
if (!sni->order && sni->ctx != bind_conf->default_ctx) {
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
/* only initialize the CTX on its first occurrence and
if it is not the default_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, 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);
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 (!sni->order && sni->ctx != bind_conf->default_ctx) {
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
/* only initialize the CTX on its first occurrence and
if it is not the default_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, 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;
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_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
if (bind_conf->default_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;
}
if (!bind_conf->default_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
}
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,
CLEANUP: global: remove the nbproc field from the global structure Let's use 1 in the rare places where it was still referenced since it's now its only possible value.
2021-06-15 02:08:04 -04:00
sizeof(*sh_ssl_sess_tree), (global.nbthread > 1));
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;
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(bind_conf->default_ctx);
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
bind_conf->default_ctx = NULL;
MINOR: ssl: Add reference to default ckch instance in bind_conf In order for the link between the cafile_entry and the default ckch instance to be built, we need to give a pointer to the instance during the ssl_sock_prepare_ctx call.
2021-04-13 10:07:29 -04:00
bind_conf->default_inst = NULL;
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
bind_conf->default_ssl_conf = 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;
}
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
/* Load CA cert file and private key used to generate certificates */
int
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
ssl_sock_load_ca(struct bind_conf *bind_conf)
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
{
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
struct proxy *px = bind_conf->frontend;
MEDIUM: ssl: Support certificate chaining for certificate generation haproxy supports generating SSL certificates based on SNI using a provided CA signing certificate. Because CA certificates may be signed by multiple CAs, in some scenarios, it is neccesary for the server to attach the trust chain in addition to the generated certificate. The following patch adds the ability to serve the entire trust chain with the generated certificate. The chain is loaded from the provided `ca-sign-file` PEM file.
2020-08-23 06:58:12 -04:00
struct cert_key_and_chain *ckch = NULL;
int ret = 0;
char *err = NULL;
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
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->options & BC_O_GENERATE_CERTS))
MEDIUM: ssl: Support certificate chaining for certificate generation haproxy supports generating SSL certificates based on SNI using a provided CA signing certificate. Because CA certificates may be signed by multiple CAs, in some scenarios, it is neccesary for the server to attach the trust chain in addition to the generated certificate. The following patch adds the ability to serve the entire trust chain with the generated certificate. The chain is loaded from the provided `ca-sign-file` PEM file.
2020-08-23 06:58:12 -04:00
return ret;
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
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_CTRL_SET_TLSEXT_HOSTNAME && !defined SSL_NO_GENERATE_CERTIFICATES)
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 (global_ssl.ctx_cache) {
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
ssl_ctx_lru_tree = lru64_new(global_ssl.ctx_cache);
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
}
BUG/MINOR: ssl: fix management of the cache where forged certificates are stored First, the LRU cache must be initialized after the configuration parsing to correctly set its size. Next, the function 'ssl_sock_set_generated_cert' returns -1 when an error occurs (0 if success). In that case, the caller is responsible to free the memory allocated for the certificate. Finally, when a SSL certificate is generated by HAProxy but cannot be inserted in the cache, it must be freed when the SSL connection is closed. This happens when 'tune.ssl.ssl-ctx-cache-size' is set to 0.
2015-07-28 10:03:47 -04:00
ssl_ctx_lru_seed = (unsigned int)time(NULL);
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_ctx_serial = now_ms;
BUILD: ssl: fix build error introduced by recent commit Commit d2cab92 ("BUG/MINOR: ssl: fix management of the cache where forged certificates are stored") removed some needed #ifdefs resulting in ssl not building on older openssl versions where SSL_CTRL_SET_TLSEXT_HOSTNAME is not defined : src/ssl_sock.c: In function 'ssl_sock_load_ca': src/ssl_sock.c:2504: error: 'ssl_ctx_lru_tree' undeclared (first use in this function) src/ssl_sock.c:2504: error: (Each undeclared identifier is reported only once src/ssl_sock.c:2504: error: for each function it appears in.) src/ssl_sock.c:2505: error: 'ssl_ctx_lru_seed' undeclared (first use in this function) src/ssl_sock.c: In function 'ssl_sock_close': src/ssl_sock.c:3095: error: 'ssl_ctx_lru_tree' undeclared (first use in this function) src/ssl_sock.c: In function '__ssl_sock_deinit': src/ssl_sock.c:5367: error: 'ssl_ctx_lru_tree' undeclared (first use in this function) make: *** [src/ssl_sock.o] Error 1 Reintroduce the ifdefs around the faulty areas.
2015-10-09 06:10:13 -04:00
#endif
BUG/MINOR: ssl: fix management of the cache where forged certificates are stored First, the LRU cache must be initialized after the configuration parsing to correctly set its size. Next, the function 'ssl_sock_set_generated_cert' returns -1 when an error occurs (0 if success). In that case, the caller is responsible to free the memory allocated for the certificate. Finally, when a SSL certificate is generated by HAProxy but cannot be inserted in the cache, it must be freed when the SSL connection is closed. This happens when 'tune.ssl.ssl-ctx-cache-size' is set to 0.
2015-07-28 10:03:47 -04:00
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
if (!bind_conf->ca_sign_file) {
CLEANUP: log: Rename Alert/Warning in ha_alert/ha_warning
2017-11-24 10:50:31 -05:00
ha_alert("Proxy '%s': cannot enable certificate generation, "
"no CA certificate File configured at [%s:%d].\n",
px->id, bind_conf->file, bind_conf->line);
MEDIUM: ssl: Support certificate chaining for certificate generation haproxy supports generating SSL certificates based on SNI using a provided CA signing certificate. Because CA certificates may be signed by multiple CAs, in some scenarios, it is neccesary for the server to attach the trust chain in addition to the generated certificate. The following patch adds the ability to serve the entire trust chain with the generated certificate. The chain is loaded from the provided `ca-sign-file` PEM file.
2020-08-23 06:58:12 -04:00
goto failed;
MINOR: ssl: Read the file used to generate certificates in any order the file specified by the SSL option 'ca-sign-file' can now contain the CA certificate used to dynamically generate certificates and its private key in any order.
2015-10-09 04:53:31 -04:00
}
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
MEDIUM: ssl: Support certificate chaining for certificate generation haproxy supports generating SSL certificates based on SNI using a provided CA signing certificate. Because CA certificates may be signed by multiple CAs, in some scenarios, it is neccesary for the server to attach the trust chain in addition to the generated certificate. The following patch adds the ability to serve the entire trust chain with the generated certificate. The chain is loaded from the provided `ca-sign-file` PEM file.
2020-08-23 06:58:12 -04:00
/* Allocate cert structure */
CLEANUP: Do not use a fixed type for 'sizeof' in 'calloc' Changes performed using the following coccinelle patch: @@ type T; expression E; expression t; @@ ( t = calloc(E, sizeof(*t)) | - t = calloc(E, sizeof(T)) + t = calloc(E, sizeof(*t)) ) Looking through the commit history, grepping for coccinelle shows that the same replacement with a different patch was already performed in the past in commit 02779b6263a177b1e462e53db6eaf57bcda574bc.
2020-09-12 14:26:43 -04:00
ckch = calloc(1, sizeof(*ckch));
MEDIUM: ssl: Support certificate chaining for certificate generation haproxy supports generating SSL certificates based on SNI using a provided CA signing certificate. Because CA certificates may be signed by multiple CAs, in some scenarios, it is neccesary for the server to attach the trust chain in addition to the generated certificate. The following patch adds the ability to serve the entire trust chain with the generated certificate. The chain is loaded from the provided `ca-sign-file` PEM file.
2020-08-23 06:58:12 -04:00
if (!ckch) {
ha_alert("Proxy '%s': Failed to read CA certificate file '%s' at [%s:%d]. Chain allocation failure\n",
px->id, bind_conf->ca_sign_file, bind_conf->file, bind_conf->line);
goto failed;
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
}
MEDIUM: ssl: Support certificate chaining for certificate generation haproxy supports generating SSL certificates based on SNI using a provided CA signing certificate. Because CA certificates may be signed by multiple CAs, in some scenarios, it is neccesary for the server to attach the trust chain in addition to the generated certificate. The following patch adds the ability to serve the entire trust chain with the generated certificate. The chain is loaded from the provided `ca-sign-file` PEM file.
2020-08-23 06:58:12 -04:00
/* Try to parse file */
if (ssl_sock_load_files_into_ckch(bind_conf->ca_sign_file, ckch, &err)) {
ha_alert("Proxy '%s': Failed to read CA certificate file '%s' at [%s:%d]. Chain loading failed: %s\n",
px->id, bind_conf->ca_sign_file, bind_conf->file, bind_conf->line, err);
CLEANUP: ssl: remove a useless "if" before freeing an error message Just an old "if (err) free(err)" that managed to escape cleanups.
2021-02-26 15:12:15 -05:00
free(err);
MEDIUM: ssl: Support certificate chaining for certificate generation haproxy supports generating SSL certificates based on SNI using a provided CA signing certificate. Because CA certificates may be signed by multiple CAs, in some scenarios, it is neccesary for the server to attach the trust chain in addition to the generated certificate. The following patch adds the ability to serve the entire trust chain with the generated certificate. The chain is loaded from the provided `ca-sign-file` PEM file.
2020-08-23 06:58:12 -04:00
goto failed;
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
}
MEDIUM: ssl: Support certificate chaining for certificate generation haproxy supports generating SSL certificates based on SNI using a provided CA signing certificate. Because CA certificates may be signed by multiple CAs, in some scenarios, it is neccesary for the server to attach the trust chain in addition to the generated certificate. The following patch adds the ability to serve the entire trust chain with the generated certificate. The chain is loaded from the provided `ca-sign-file` PEM file.
2020-08-23 06:58:12 -04:00
/* Fail if missing cert or pkey */
if ((!ckch->cert) || (!ckch->key)) {
ha_alert("Proxy '%s': Failed to read CA certificate file '%s' at [%s:%d]. Chain missing certificate or private key\n",
px->id, bind_conf->ca_sign_file, bind_conf->file, bind_conf->line);
goto failed;
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
}
MEDIUM: ssl: Support certificate chaining for certificate generation haproxy supports generating SSL certificates based on SNI using a provided CA signing certificate. Because CA certificates may be signed by multiple CAs, in some scenarios, it is neccesary for the server to attach the trust chain in addition to the generated certificate. The following patch adds the ability to serve the entire trust chain with the generated certificate. The chain is loaded from the provided `ca-sign-file` PEM file.
2020-08-23 06:58:12 -04:00
/* Final assignment to bind */
bind_conf->ca_sign_ckch = ckch;
return ret;
failed:
if (ckch) {
ssl_sock_free_cert_key_and_chain_contents(ckch);
free(ckch);
}
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
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
bind_conf->options &= ~BC_O_GENERATE_CERTS;
MEDIUM: ssl: Support certificate chaining for certificate generation haproxy supports generating SSL certificates based on SNI using a provided CA signing certificate. Because CA certificates may be signed by multiple CAs, in some scenarios, it is neccesary for the server to attach the trust chain in addition to the generated certificate. The following patch adds the ability to serve the entire trust chain with the generated certificate. The chain is loaded from the provided `ca-sign-file` PEM file.
2020-08-23 06:58:12 -04:00
ret++;
return ret;
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
}
/* Release CA cert and private key used to generate certificated */
void
ssl_sock_free_ca(struct bind_conf *bind_conf)
{
MEDIUM: ssl: Support certificate chaining for certificate generation haproxy supports generating SSL certificates based on SNI using a provided CA signing certificate. Because CA certificates may be signed by multiple CAs, in some scenarios, it is neccesary for the server to attach the trust chain in addition to the generated certificate. The following patch adds the ability to serve the entire trust chain with the generated certificate. The chain is loaded from the provided `ca-sign-file` PEM file.
2020-08-23 06:58:12 -04:00
if (bind_conf->ca_sign_ckch) {
ssl_sock_free_cert_key_and_chain_contents(bind_conf->ca_sign_ckch);
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(&bind_conf->ca_sign_ckch);
MEDIUM: ssl: Support certificate chaining for certificate generation haproxy supports generating SSL certificates based on SNI using a provided CA signing certificate. Because CA certificates may be signed by multiple CAs, in some scenarios, it is neccesary for the server to attach the trust chain in addition to the generated certificate. The following patch adds the ability to serve the entire trust chain with the generated certificate. The chain is loaded from the provided `ca-sign-file` PEM file.
2020-08-23 06:58:12 -04:00
}
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_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;
}
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;
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
/* 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
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
if (global.maxsslconn && global.sslconns >= global.maxsslconn) {
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_TOO_MANY;
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
goto err;
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
}
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
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)) {
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 (ssl_bio_and_sess_init(conn, __objt_server(conn->target)->ssl_ctx.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
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);
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, &(__objt_server(conn->target)->ssl_ctx.lock));
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
if (__objt_server(conn->target)->ssl_ctx.reused_sess[tid].ptr) {
const unsigned char *ptr = __objt_server(conn->target)->ssl_ctx.reused_sess[tid].ptr;
SSL_SESSION *sess = d2i_SSL_SESSION(NULL, &ptr, __objt_server(conn->target)->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: 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);
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(&__objt_server(conn->target)->ssl_ctx.reused_sess[tid].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
} else if (sess) {
SSL_SESSION_free(sess);
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: 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, &(__objt_server(conn->target)->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.sslconns);
_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.sslconns);
_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:
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: 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
*/
static int ssl_takeover(struct connection *conn, void *xprt_ctx, int orig_tid)
{
struct ssl_sock_ctx *ctx = xprt_ctx;
struct tasklet *tl = tasklet_new();
if (!tl)
return -1;
ctx->wait_event.tasklet->context = NULL;
tasklet_wakeup_on(ctx->wait_event.tasklet, orig_tid);
ctx->wait_event.tasklet = tl;
ctx->wait_event.tasklet->process = ssl_sock_io_cb;
ctx->wait_event.tasklet->context = ctx;
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;
conn_in_list = conn->flags & CO_FL_LIST_MASK;
if (conn_in_list)
conn_delete_from_tree(&conn->hash_node->node);
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);
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
if (conn_in_list == CO_FL_SAFE_LIST)
MINOR: server: allocate a per-thread struct for the per-thread connections stuff There are multiple per-thread lists in the listeners, which isn't the most efficient in terms of cache, and doesn't easily allow to store all the per-thread stuff. Now we introduce an srv_per_thread structure which the servers will have an array of, and place the idle/safe/avail conns tree heads into. Overall this was a fairly mechanical change, and the array is now always initialized for all servers since we'll put more stuff there. It's worth noting that the Lua code still has to deal with its own deinit by itself despite being in a global list, because its server is not dynamically allocated.
2021-03-04 03:45:32 -05:00
ebmb_insert(&srv->per_thr[tid].safe_conns, &conn->hash_node->node, sizeof(conn->hash_node->hash));
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
else
MINOR: server: allocate a per-thread struct for the per-thread connections stuff There are multiple per-thread lists in the listeners, which isn't the most efficient in terms of cache, and doesn't easily allow to store all the per-thread stuff. Now we introduce an srv_per_thread structure which the servers will have an array of, and place the idle/safe/avail conns tree heads into. Overall this was a fairly mechanical change, and the array is now always initialized for all servers since we'll put more stuff there. It's worth noting that the Lua code still has to deal with its own deinit by itself despite being in a global list, because its server is not dynamically allocated.
2021-03-04 03:45:32 -05:00
ebmb_insert(&srv->per_thr[tid].idle_conns, &conn->hash_node->node, sizeof(conn->hash_node->hash));
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
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: 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
struct server *s;
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: 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
s = __objt_server(conn->target);
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
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
* previously stored in the reused_sess */
/* the RWLOCK is used to ensure that we are not trying to flush the
* cache from the CLI */
HA_RWLOCK_RDLOCK(SSL_SERVER_LOCK, &s->ssl_ctx.lock);
prev_name = s->ssl_ctx.reused_sess[tid].sni;
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) ||
(prev_name && (!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);
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_RWLOCK_RDUNLOCK(SSL_SERVER_LOCK, &s->ssl_ctx.lock);
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
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_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;
}
}
AUTHORITY_KEYID_free(akid);
}
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;
}
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, " xctx.st=%d", sctx->xprt_st);
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
* tlskeys_list_get_next() for retruning the first available entry
*/
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;
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
/* fall through */
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;
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
/* fall through */
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 */
if (!*args[2]) {
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->names_only = 1;
BUG/MEDIUM: cli: fix "show stat resolvers" and "show tls-keys" The recent CLI reorganization managed to break these two commands by having their parser return 1 (indicating an end of processing) instead of 0 to indicate new calls to the io handler were needed. Namely the faulty commits are : 69e9644 ("REORG: cli: move show stat resolvers to dns.c") 32af203 ("REORG: cli: move ssl CLI functions to ssl_sock.c") The fix is trivial and there is no other loss of functionality. Thanks to Dragan Dosen for reporting the issue and the faulty commits. The backport is needed in 1.7.
2016-12-05 08:50:15 -05:00
return 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
}
if (args[2][0] == '*') {
/* list every TLS ticket keys */
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->names_only = 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
} else {
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_ref_lookup_ref(args[2]);
if (!ctx->next_ref)
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
return cli_err(appctx, "'show tls-keys' unable to locate referenced filename\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/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
ctx->dump_entries = 1;
BUG/MEDIUM: cli: fix "show stat resolvers" and "show tls-keys" The recent CLI reorganization managed to break these two commands by having their parser return 1 (indicating an end of processing) instead of 0 to indicate new calls to the io handler were needed. Namely the faulty commits are : 69e9644 ("REORG: cli: move show stat resolvers to dns.c") 32af203 ("REORG: cli: move ssl CLI functions to ssl_sock.c") The fix is trivial and there is no other loss of functionality. Thanks to Dragan Dosen for reporting the issue and the faulty commits. The backport is needed in 1.7.
2016-12-05 08:50:15 -05:00
return 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
}
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_set_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
{
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
struct tls_keys_ref *ref;
BUG/MEDIUM: cli/ssl: don't store base64dec() result in the trash's length By convenience or laziness we used to store base64dec()'s return code into trash.data and to compare it against 0 to check for conversion failure, but it's now unsigned since commit 843b7cb ("MEDIUM: chunks: make the chunk struct's fields match the buffer struct"). Let's clean this up and test the result itself without storing it first. No backport is needed.
2018-08-21 23:26:57 -04:00
int ret;
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
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
/* Expect two parameters: the filename and the new new TLS key in encoding */
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
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");
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: 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
ref = tlskeys_ref_lookup_ref(args[3]);
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
if (!ref)
return cli_err(appctx, "'set ssl tls-key' unable to locate referenced filename\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
BUG/MEDIUM: cli/ssl: don't store base64dec() result in the trash's length By convenience or laziness we used to store base64dec()'s return code into trash.data and to compare it against 0 to check for conversion failure, but it's now unsigned since commit 843b7cb ("MEDIUM: chunks: make the chunk struct's fields match the buffer struct"). Let's clean this up and test the result itself without storing it first. No backport is needed.
2018-08-21 23:26:57 -04:00
ret = base64dec(args[4], strlen(args[4]), trash.area, trash.size);
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
if (ret < 0)
return cli_err(appctx, "'set ssl tls-key' received invalid base64 encoded TLS key.\n");
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/MEDIUM: cli/ssl: don't store base64dec() result in the trash's length By convenience or laziness we used to store base64dec()'s return code into trash.data and to compare it against 0 to check for conversion failure, but it's now unsigned since commit 843b7cb ("MEDIUM: chunks: make the chunk struct's fields match the buffer struct"). Let's clean this up and test the result itself without storing it first. No backport is needed.
2018-08-21 23:26:57 -04:00
trash.data = ret;
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
if (ssl_sock_update_tlskey_ref(ref, &trash) < 0)
return cli_err(appctx, "'set ssl tls-key' received a key of wrong size.\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: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
return cli_msg(appctx, LOG_INFO, "TLS ticket key updated!\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
}
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
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
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_set_ocspresponse(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
{
#if (defined SSL_CTRL_SET_TLSEXT_STATUS_REQ_CB && !defined OPENSSL_NO_OCSP)
char *err = NULL;
BUG/MEDIUM: cli/ssl: don't store base64dec() result in the trash's length By convenience or laziness we used to store base64dec()'s return code into trash.data and to compare it against 0 to check for conversion failure, but it's now unsigned since commit 843b7cb ("MEDIUM: chunks: make the chunk struct's fields match the buffer struct"). Let's clean this up and test the result itself without storing it first. No backport is needed.
2018-08-21 23:26:57 -04:00
int i, j, ret;
MINOR: ssl: Add payload support to "set ssl ocsp-response" It is now possible to use a payload with the "set ssl ocsp-response" command. These syntaxes will work the same way: # echo "set ssl ocsp-response $(base64 -w 10000 ocsp.der)" | \ socat /tmp/sock1 - # echo -e "set ssl ocsp-response <<\n$(base64 ocsp.der)\n" | \ socat /tmp/sock1 - Signed-off-by: Aurlien Nephtali <aurelien.nephtali@corp.ovh.com>
2018-04-18 08:04:58 -04:00
if (!payload)
payload = args[3];
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
/* Expect one parameter: the new response in base64 encoding */
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
if (!*payload)
return cli_err(appctx, "'set ssl ocsp-response' expects response in base64 encoding.\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
MINOR: ssl: Add payload support to "set ssl ocsp-response" It is now possible to use a payload with the "set ssl ocsp-response" command. These syntaxes will work the same way: # echo "set ssl ocsp-response $(base64 -w 10000 ocsp.der)" | \ socat /tmp/sock1 - # echo -e "set ssl ocsp-response <<\n$(base64 ocsp.der)\n" | \ socat /tmp/sock1 - Signed-off-by: Aurlien Nephtali <aurelien.nephtali@corp.ovh.com>
2018-04-18 08:04:58 -04:00
/* remove \r and \n from the payload */
for (i = 0, j = 0; payload[i]; i++) {
if (payload[i] == '\r' || payload[i] == '\n')
continue;
payload[j++] = payload[i];
}
payload[j] = 0;
BUG/MEDIUM: cli/ssl: don't store base64dec() result in the trash's length By convenience or laziness we used to store base64dec()'s return code into trash.data and to compare it against 0 to check for conversion failure, but it's now unsigned since commit 843b7cb ("MEDIUM: chunks: make the chunk struct's fields match the buffer struct"). Let's clean this up and test the result itself without storing it first. No backport is needed.
2018-08-21 23:26:57 -04:00
ret = base64dec(payload, j, trash.area, trash.size);
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
if (ret < 0)
return cli_err(appctx, "'set ssl ocsp-response' received invalid base64 encoded response.\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
BUG/MEDIUM: cli/ssl: don't store base64dec() result in the trash's length By convenience or laziness we used to store base64dec()'s return code into trash.data and to compare it against 0 to check for conversion failure, but it's now unsigned since commit 843b7cb ("MEDIUM: chunks: make the chunk struct's fields match the buffer struct"). Let's clean this up and test the result itself without storing it first. No backport is needed.
2018-08-21 23:26:57 -04:00
trash.data = ret;
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
if (ssl_sock_update_ocsp_response(&trash, &err)) {
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
if (err)
return cli_dynerr(appctx, memprintf(&err, "%s.\n", err));
else
return cli_err(appctx, "Failed to update OCSP response.\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: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
return cli_msg(appctx, LOG_INFO, "OCSP Response updated!\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
#else
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
return cli_err(appctx, "HAProxy was compiled against a version of OpenSSL that doesn't support OCSP stapling.\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
#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
BUILD: ssl: Fix compilation with BoringSSL The ifdefs surrounding the "show ssl ocsp-response" functionality that were supposed to disable the code with BoringSSL were built the wrong way. It does not need to be backported.
2021-06-10 12:10:32 -04:00
#if ((defined SSL_CTRL_SET_TLSEXT_STATUS_REQ_CB && !defined OPENSSL_NO_OCSP) && !defined OPENSSL_IS_BORINGSSL)
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
static int cli_io_handler_show_ocspresponse_detail(struct appctx *appctx);
#endif
CLEANUP: ssl/cli: make "show ssl ocsp-response" not use cli.p0 anymore Instead the single-pointer context is placed into appctx->svcctx. There's no need to declare a structure there for this.
2022-05-05 03:09:15 -04:00
/* parsing function for 'show ssl ocsp-response [id]'. If an entry is forced,
* it's set into appctx->svcctx.
*/
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
static int cli_parse_show_ocspresponse(char **args, char *payload, struct appctx *appctx, void *private)
{
BUILD: ssl: Fix compilation with BoringSSL The ifdefs surrounding the "show ssl ocsp-response" functionality that were supposed to disable the code with BoringSSL were built the wrong way. It does not need to be backported.
2021-06-10 12:10:32 -04:00
#if ((defined SSL_CTRL_SET_TLSEXT_STATUS_REQ_CB && !defined OPENSSL_NO_OCSP) && !defined OPENSSL_IS_BORINGSSL)
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
if (*args[3]) {
struct certificate_ocsp *ocsp = NULL;
char *key = NULL;
int key_length = 0;
if (strlen(args[3]) > OCSP_MAX_CERTID_ASN1_LENGTH*2) {
return cli_err(appctx, "'show ssl ocsp-response' received a too big key.\n");
}
if (parse_binary(args[3], &key, &key_length, NULL)) {
char full_key[OCSP_MAX_CERTID_ASN1_LENGTH] = {};
memcpy(full_key, key, key_length);
ocsp = (struct certificate_ocsp *)ebmb_lookup(&cert_ocsp_tree, full_key, OCSP_MAX_CERTID_ASN1_LENGTH);
}
if (key)
ha_free(&key);
if (!ocsp) {
return cli_err(appctx, "Certificate ID does not match any certificate.\n");
}
CLEANUP: ssl/cli: make "show ssl ocsp-response" not use cli.p0 anymore Instead the single-pointer context is placed into appctx->svcctx. There's no need to declare a structure there for this.
2022-05-05 03:09:15 -04:00
appctx->svcctx = ocsp;
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
appctx->io_handler = cli_io_handler_show_ocspresponse_detail;
}
return 0;
#else
return cli_err(appctx, "HAProxy was compiled against a version of OpenSSL that doesn't support OCSP stapling.\n");
#endif
}
BUILD: ssl: Fix compilation with BoringSSL The ifdefs surrounding the "show ssl ocsp-response" functionality that were supposed to disable the code with BoringSSL were built the wrong way. It does not need to be backported.
2021-06-10 12:10:32 -04:00
#if ((defined SSL_CTRL_SET_TLSEXT_STATUS_REQ_CB && !defined OPENSSL_NO_OCSP) && !defined OPENSSL_IS_BORINGSSL)
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
/*
* This function dumps the details of an OCSP_CERTID. It is based on
* ocsp_certid_print in OpenSSL.
*/
static inline int ocsp_certid_print(BIO *bp, OCSP_CERTID *certid, int indent)
{
ASN1_OCTET_STRING *piNameHash = NULL;
ASN1_OCTET_STRING *piKeyHash = NULL;
ASN1_INTEGER *pSerial = NULL;
if (OCSP_id_get0_info(&piNameHash, NULL, &piKeyHash, &pSerial, certid)) {
BIO_printf(bp, "%*sCertificate ID:\n", indent, "");
indent += 2;
MINOR: ssl: Remove empty lines from "show ssl ocsp-response" output There were empty lines in the output of the CLI's "show ssl ocsp-response" command (after the certificate ID and between two certificates). This patch removes them since an empty line should mark the end of the output. Must be backported in 2.5.
2021-12-17 12:53:23 -05:00
BIO_printf(bp, "%*sIssuer Name Hash: ", indent, "");
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
i2a_ASN1_STRING(bp, piNameHash, 0);
BIO_printf(bp, "\n%*sIssuer Key Hash: ", indent, "");
i2a_ASN1_STRING(bp, piKeyHash, 0);
BIO_printf(bp, "\n%*sSerial Number: ", indent, "");
i2a_ASN1_INTEGER(bp, pSerial);
}
return 1;
}
#endif
/*
* IO handler of "show ssl ocsp-response". The command taking a specific ID
* is managed in cli_io_handler_show_ocspresponse_detail.
CLEANUP: ssl/cli: make "show ssl ocsp-response" not use cli.p0 anymore Instead the single-pointer context is placed into appctx->svcctx. There's no need to declare a structure there for this.
2022-05-05 03:09:15 -04:00
* The current entry is taken from appctx->svcctx.
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
*/
static int cli_io_handler_show_ocspresponse(struct appctx *appctx)
{
BUILD: ssl: Fix compilation with BoringSSL The ifdefs surrounding the "show ssl ocsp-response" functionality that were supposed to disable the code with BoringSSL were built the wrong way. It does not need to be backported.
2021-06-10 12:10:32 -04:00
#if ((defined SSL_CTRL_SET_TLSEXT_STATUS_REQ_CB && !defined OPENSSL_NO_OCSP) && !defined OPENSSL_IS_BORINGSSL)
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
struct buffer *trash = alloc_trash_chunk();
struct buffer *tmp = NULL;
struct ebmb_node *node;
struct certificate_ocsp *ocsp = NULL;
BIO *bio = NULL;
int write = -1;
if (trash == NULL)
return 1;
tmp = alloc_trash_chunk();
if (!tmp)
goto end;
if ((bio = BIO_new(BIO_s_mem())) == NULL)
goto end;
CLEANUP: ssl/cli: make "show ssl ocsp-response" not use cli.p0 anymore Instead the single-pointer context is placed into appctx->svcctx. There's no need to declare a structure there for this.
2022-05-05 03:09:15 -04:00
if (!appctx->svcctx) {
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
chunk_appendf(trash, "# Certificate IDs\n");
node = ebmb_first(&cert_ocsp_tree);
} else {
CLEANUP: ssl/cli: make "show ssl ocsp-response" not use cli.p0 anymore Instead the single-pointer context is placed into appctx->svcctx. There's no need to declare a structure there for this.
2022-05-05 03:09:15 -04:00
node = &((struct certificate_ocsp *)appctx->svcctx)->key;
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
}
while (node) {
OCSP_CERTID *certid = NULL;
const unsigned char *p = NULL;
int i;
ocsp = ebmb_entry(node, struct certificate_ocsp, key);
/* Dump the key in hexadecimal */
chunk_appendf(trash, "Certificate ID key : ");
for (i = 0; i < ocsp->key_length; ++i) {
chunk_appendf(trash, "%02x", ocsp->key_data[i]);
}
chunk_appendf(trash, "\n");
p = ocsp->key_data;
/* Decode the certificate ID (serialized into the key). */
d2i_OCSP_CERTID(&certid, &p, ocsp->key_length);
BUG/MINOR: ssl: Fix leak in "show ssl ocsp-response" CLI command When calling the "show ssl ocsp-response" CLI command some OpenSSL objects need to be created in order to get some information related to the OCSP response and some of them were not freed. It should be backported to 2.5.
2022-02-16 09:03:51 -05:00
if (!certid)
goto end;
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
/* Dump the CERTID info */
ocsp_certid_print(bio, certid, 1);
BUG/MINOR: ssl: Fix leak in "show ssl ocsp-response" CLI command When calling the "show ssl ocsp-response" CLI command some OpenSSL objects need to be created in order to get some information related to the OCSP response and some of them were not freed. It should be backported to 2.5.
2022-02-16 09:03:51 -05:00
OCSP_CERTID_free(certid);
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
write = BIO_read(bio, tmp->area, tmp->size-1);
MINOR: ssl: Remove empty lines from "show ssl ocsp-response" output There were empty lines in the output of the CLI's "show ssl ocsp-response" command (after the certificate ID and between two certificates). This patch removes them since an empty line should mark the end of the output. Must be backported in 2.5.
2021-12-17 12:53:23 -05:00
/* strip trailing LFs */
while (write > 0 && tmp->area[write-1] == '\n')
write--;
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
tmp->area[write] = '\0';
chunk_appendf(trash, "%s\n", tmp->area);
node = ebmb_next(node);
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 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
goto yield;
}
end:
CLEANUP: ssl/cli: make "show ssl ocsp-response" not use cli.p0 anymore Instead the single-pointer context is placed into appctx->svcctx. There's no need to declare a structure there for this.
2022-05-05 03:09:15 -04:00
appctx->svcctx = NULL;
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
if (trash)
free_trash_chunk(trash);
if (tmp)
free_trash_chunk(tmp);
if (bio)
BIO_free(bio);
return 1;
yield:
if (trash)
free_trash_chunk(trash);
if (tmp)
free_trash_chunk(tmp);
if (bio)
BIO_free(bio);
CLEANUP: ssl/cli: make "show ssl ocsp-response" not use cli.p0 anymore Instead the single-pointer context is placed into appctx->svcctx. There's no need to declare a structure there for this.
2022-05-05 03:09:15 -04:00
appctx->svcctx = ocsp;
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
return 0;
#else
return cli_err(appctx, "HAProxy was compiled against a version of OpenSSL that doesn't support OCSP stapling.\n");
#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
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
BUILD: ssl: Fix compilation with BoringSSL The ifdefs surrounding the "show ssl ocsp-response" functionality that were supposed to disable the code with BoringSSL were built the wrong way. It does not need to be backported.
2021-06-10 12:10:32 -04:00
#if ((defined SSL_CTRL_SET_TLSEXT_STATUS_REQ_CB && !defined OPENSSL_NO_OCSP) && !defined OPENSSL_IS_BORINGSSL)
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
/*
* Dump the details about an OCSP response in DER format stored in
* <ocsp_response> into buffer <out>.
* Returns 0 in case of success.
*/
int ssl_ocsp_response_print(struct buffer *ocsp_response, struct buffer *out)
{
BIO *bio = NULL;
int write = -1;
OCSP_RESPONSE *resp;
const unsigned char *p;
BUG/MINOR: ssl: Add missing return value check in ssl_ocsp_response_print The b_istput function called to append the last data block to the end of an OCSP response's detailed output was not checked in ssl_ocsp_response_print. The ssl_ocsp_response_print return value checks were added as well since some of them were missing. This error was raised by Coverity (CID 1469513). This patch fixes GitHub issue #1541. It can be backported to 2.5.
2022-02-16 08:42:22 -05:00
int retval = -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
if (!ocsp_response)
return -1;
if ((bio = BIO_new(BIO_s_mem())) == NULL)
return -1;
p = (const unsigned char*)ocsp_response->area;
resp = d2i_OCSP_RESPONSE(NULL, &p, ocsp_response->data);
if (!resp) {
chunk_appendf(out, "Unable to parse OCSP response");
BUG/MINOR: ssl: Fix leak in "show ssl ocsp-response" CLI command When calling the "show ssl ocsp-response" CLI command some OpenSSL objects need to be created in order to get some information related to the OCSP response and some of them were not freed. It should be backported to 2.5.
2022-02-16 09:03:51 -05:00
goto end;
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
}
if (OCSP_RESPONSE_print(bio, resp, 0) != 0) {
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
struct buffer *trash = get_trash_chunk();
struct ist ist_block = IST_NULL;
struct ist ist_double_lf = IST_NULL;
static struct ist double_lf = IST("\n\n");
write = BIO_read(bio, trash->area, trash->size - 1);
BUG/MINOR: ssl: Missing return value check in ssl_ocsp_response_print When calling ssl_ocsp_response_print which is used to display an OCSP response's details when calling the "show ssl ocsp-response" on the CLI, we use the BIO_read function that copies an OpenSSL BIO into a trash. The return value was not checked though, which could lead to some crashes since BIO_read can return a negative value in case of error. This patch should be backported to 2.5.
2022-02-16 09:17:09 -05:00
if (write <= 0)
goto end;
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
trash->data = write;
/* Look for empty lines in the 'trash' buffer and add a space to
* the beginning to avoid having empty lines in the output
* (without changing the appearance of the information
* displayed).
*/
ist_block = ist2(b_orig(trash), b_data(trash));
ist_double_lf = istist(ist_block, double_lf);
while (istlen(ist_double_lf)) {
/* istptr(ist_double_lf) points to the first \n of a
* \n\n pattern.
*/
uint empty_line_offset = istptr(ist_double_lf) + 1 - istptr(ist_block);
/* Write up to the first '\n' of the "\n\n" pattern into
* the output buffer.
*/
b_putblk(out, istptr(ist_block), empty_line_offset);
/* Add an extra space. */
b_putchr(out, ' ');
/* Keep looking for empty lines in the rest of the data. */
ist_block = istadv(ist_block, empty_line_offset);
ist_double_lf = istist(ist_block, double_lf);
}
BUG/MINOR: ssl: Add missing return value check in ssl_ocsp_response_print The b_istput function called to append the last data block to the end of an OCSP response's detailed output was not checked in ssl_ocsp_response_print. The ssl_ocsp_response_print return value checks were added as well since some of them were missing. This error was raised by Coverity (CID 1469513). This patch fixes GitHub issue #1541. It can be backported to 2.5.
2022-02-16 08:42:22 -05:00
retval = (b_istput(out, ist_block) <= 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
}
BUG/MINOR: ssl: Fix leak in "show ssl ocsp-response" CLI command When calling the "show ssl ocsp-response" CLI command some OpenSSL objects need to be created in order to get some information related to the OCSP response and some of them were not freed. It should be backported to 2.5.
2022-02-16 09:03:51 -05:00
end:
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
if (bio)
BIO_free(bio);
BUG/MINOR: ssl: Fix leak in "show ssl ocsp-response" CLI command When calling the "show ssl ocsp-response" CLI command some OpenSSL objects need to be created in order to get some information related to the OCSP response and some of them were not freed. It should be backported to 2.5.
2022-02-16 09:03:51 -05:00
OCSP_RESPONSE_free(resp);
BUG/MINOR: ssl: Add missing return value check in ssl_ocsp_response_print The b_istput function called to append the last data block to the end of an OCSP response's detailed output was not checked in ssl_ocsp_response_print. The ssl_ocsp_response_print return value checks were added as well since some of them were missing. This error was raised by Coverity (CID 1469513). This patch fixes GitHub issue #1541. It can be backported to 2.5.
2022-02-16 08:42:22 -05:00
return retval;
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
}
/*
* Dump the details of the OCSP response of ID <ocsp_certid> into buffer <out>.
* Returns 0 in case of success.
*/
int ssl_get_ocspresponse_detail(unsigned char *ocsp_certid, struct buffer *out)
{
struct certificate_ocsp *ocsp;
ocsp = (struct certificate_ocsp *)ebmb_lookup(&cert_ocsp_tree, ocsp_certid, OCSP_MAX_CERTID_ASN1_LENGTH);
if (!ocsp)
return -1;
return ssl_ocsp_response_print(&ocsp->response, out);
}
CLEANUP: ssl/cli: make "show ssl ocsp-response" not use cli.p0 anymore Instead the single-pointer context is placed into appctx->svcctx. There's no need to declare a structure there for this.
2022-05-05 03:09:15 -04:00
/* IO handler of details "show ssl ocsp-response <id>".
* The current entry is taken from appctx->svcctx.
*/
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
static int cli_io_handler_show_ocspresponse_detail(struct appctx *appctx)
{
struct buffer *trash = alloc_trash_chunk();
CLEANUP: ssl/cli: make "show ssl ocsp-response" not use cli.p0 anymore Instead the single-pointer context is placed into appctx->svcctx. There's no need to declare a structure there for this.
2022-05-05 03:09:15 -04:00
struct certificate_ocsp *ocsp = appctx->svcctx;
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
if (trash == NULL)
return 1;
BUG/MINOR: ssl: Add missing return value check in ssl_ocsp_response_print The b_istput function called to append the last data block to the end of an OCSP response's detailed output was not checked in ssl_ocsp_response_print. The ssl_ocsp_response_print return value checks were added as well since some of them were missing. This error was raised by Coverity (CID 1469513). This patch fixes GitHub issue #1541. It can be backported to 2.5.
2022-02-16 08:42:22 -05:00
if (ssl_ocsp_response_print(&ocsp->response, trash)) {
free_trash_chunk(trash);
return 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
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 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
goto yield;
CLEANUP: ssl/cli: make "show ssl ocsp-response" not use cli.p0 anymore Instead the single-pointer context is placed into appctx->svcctx. There's no need to declare a structure there for this.
2022-05-05 03:09:15 -04:00
appctx->svcctx = NULL;
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
if (trash)
free_trash_chunk(trash);
return 1;
yield:
if (trash)
free_trash_chunk(trash);
return 0;
}
#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
/* register cli keywords */
static struct cli_kw_list cli_kws = {{ },{
#if (defined SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB && TLS_TICKETS_NO > 0)
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
{ { "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 },
CLEANUP: cli/tree-wide: properly re-align the CLI commands' help messages There were 102 CLI commands whose help were zig-zagging all along the dump making them unreadable. This patch realigns all these messages so that the command now uses up to 40 characters before the delimiting colon. About a third of the commands did not correctly list their arguments which were added after the first version, so they were all updated. Some abuses of the term "id" were fixed to use a more explanatory term. The "set ssl ocsp-response" command was not listed because it lacked a help message, this was fixed as well. The deprecated enable/disable commands for agent/health/server were prominently written as deprecated. Whenever possible, clearer explanations were provided.
2021-05-07 05:38:37 -04:00
{ { "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 },
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
#endif
CLEANUP: cli/tree-wide: properly re-align the CLI commands' help messages There were 102 CLI commands whose help were zig-zagging all along the dump making them unreadable. This patch realigns all these messages so that the command now uses up to 40 characters before the delimiting colon. About a third of the commands did not correctly list their arguments which were added after the first version, so they were all updated. Some abuses of the term "id" were fixed to use a more explanatory term. The "set ssl ocsp-response" command was not listed because it lacked a help message, this was fixed as well. The deprecated enable/disable commands for agent/health/server were prominently written as deprecated. Whenever possible, clearer explanations were provided.
2021-05-07 05:38:37 -04:00
{ { "set", "ssl", "ocsp-response", NULL }, "set ssl ocsp-response <resp|payload> : update a certificate's OCSP Response from a base64-encode DER", cli_parse_set_ocspresponse, NULL },
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
{ { "show", "ssl", "ocsp-response", NULL },"show ssl ocsp-response [id] : display the IDs of the OCSP responses used in memory, or the details of a single OCSP response", cli_parse_show_ocspresponse, cli_io_handler_show_ocspresponse, NULL },
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);
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
s->req.flags |= CF_READ_NULL;
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
#if ((defined SSL_CTRL_SET_TLSEXT_STATUS_REQ_CB && !defined OPENSSL_NO_OCSP) && !defined OPENSSL_IS_BORINGSSL)
static void ssl_sock_ocsp_free_func(void *parent, void *ptr, CRYPTO_EX_DATA *ad, int idx, long argl, void *argp)
{
struct ocsp_cbk_arg *ocsp_arg;
if (ptr) {
ocsp_arg = ptr;
if (ocsp_arg->is_single) {
ssl_sock_free_ocsp(ocsp_arg->s_ocsp);
ocsp_arg->s_ocsp = NULL;
} else {
int i;
for (i = 0; i < SSL_SOCK_NUM_KEYTYPES; i++) {
ssl_sock_free_ocsp(ocsp_arg->m_ocsp[i]);
ocsp_arg->m_ocsp[i] = NULL;
}
}
free(ocsp_arg);
}
}
#endif
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();
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");
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
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)
{
#if (defined SSL_CTRL_SET_TLSEXT_HOSTNAME && !defined SSL_NO_GENERATE_CERTIFICATES)
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 (ssl_ctx_lru_tree) {
lru64_destroy(ssl_ctx_lru_tree);
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_DESTROY(&ssl_ctx_lru_rwlock);
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: 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
#endif
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);
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