RepoMirrors/haproxy
1
0
Fork 0
mirror of http://git.haproxy.org/git/haproxy.git/ synced 2024-12-24 13:42:16 +00:00
Code Issues Packages Projects Releases Wiki Activity
51e474136b
haproxy/include/proto/ssl_sock.h

104 lines
4.2 KiB
C
Raw Normal View History

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 13:47:34 +00:00
/*
* include/proto/ssl_sock.h
* This file contains definition for ssl stream socket operations
*
* Copyright (C) 2012 EXCELIANCE, Emeric Brun <ebrun@exceliance.fr>
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation, version 2.1
* exclusively.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
#ifndef _PROTO_SSL_SOCK_H
#define _PROTO_SSL_SOCK_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 15:30:07 +00:00
#include <openssl/ssl.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 13:47:34 +00:00
REORG: split "protocols" files into protocol and listener It was becoming confusing to have protocols and listeners in the same files, split them.
2012-09-12 20:58:11 +00:00
#include <types/connection.h>
#include <types/listener.h>
#include <types/proxy.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 13:47:34 +00:00
#include <types/stream_interface.h>
MINOR: cli: add more information to the "show info" output In addition to previous outputs, we also emit the cumulated number of connections, the cumulated number of requests, the maximum allowed SSL connection concurrency, the current number of SSL connections and the cumulated number of SSL connections. This will help troubleshoot systems which experience memory shortage due to SSL.
2014-01-28 14:19:44 +00:00
extern int sslconns;
extern int totalsslconns;
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-09 03:42:08 +00:00
/* boolean, returns true if connection is over SSL */
static inline
int ssl_sock_is_ssl(struct connection *conn)
{
CLEANUP: connection: unexport raw_sock and ssl_sock This way we're sure not to reuse them by accident.
2016-12-22 20:08:52 +00:00
if (!conn || conn->xprt != xprt_get(XPRT_SSL) || !conn->xprt_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-09 03:42:08 +00:00
return 0;
else
return 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 13:47:34 +00:00
int ssl_sock_handshake(struct connection *conn, unsigned int flag);
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 17:26:15 +00:00
int ssl_sock_prepare_ctx(struct bind_conf *bind_conf, struct ssl_bind_conf *, SSL_CTX *ctx);
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 16:08:28 +00:00
int ssl_sock_prepare_all_ctx(struct bind_conf *bind_conf);
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 22:38:39 +00:00
int ssl_sock_prepare_bind_conf(struct bind_conf *bind_conf);
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 16:08:28 +00:00
int ssl_sock_prepare_srv_ctx(struct server *srv);
MINOR: ssl: Release Servers SSL context when HAProxy is shut down [wt: could be backported to 1.5 as well]
2015-07-29 11:02:40 +00:00
void ssl_sock_free_srv_ctx(struct server *srv);
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 15:54:29 +00:00
void ssl_sock_free_all_ctx(struct bind_conf *bind_conf);
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 16:08:28 +00:00
int 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 15:29:50 +00:00
void ssl_sock_free_ca(struct bind_conf *bind_conf);
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 17:29:59 +00:00
const char *ssl_sock_get_sni(struct connection *conn);
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 13:05:23 +00:00
const char *ssl_sock_get_cert_sig(struct connection *conn);
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 18:17:54 +00:00
const char *ssl_sock_get_cipher_name(struct connection *conn);
const char *ssl_sock_get_proto_version(struct connection *conn);
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 09:33:32 +00:00
void ssl_sock_set_servername(struct connection *conn, const char *hostname);
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 14:39:13 +00:00
int ssl_sock_get_cert_used_sess(struct connection *conn);
int ssl_sock_get_cert_used_conn(struct connection *conn);
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 09:56:34 +00:00
int ssl_sock_get_remote_common_name(struct connection *conn,
struct buffer *out);
int ssl_sock_get_pkey_algo(struct connection *conn, struct buffer *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-09 03:42:08 +00:00
unsigned int ssl_sock_get_verify_result(struct connection *conn);
BUILD: ssl: use OPENSSL_NO_OCSP to detect OCSP support Since commit 656c5fa7e859 ("BUILD: ssl: disable OCSP when using boringssl) the OCSP code is bypassed when OPENSSL_IS_BORINGSSL is defined. The correct thing to do here is to use OPENSSL_NO_OCSP instead, which is defined for this exact purpose in openssl/opensslfeatures.h. This makes haproxy forward compatible if boringssl ever introduces full OCSP support with the additional benefit that it links fine against a OCSP-disabled openssl. Signed-off-by: Lukas Tribus <luky-37@hotmail.com>
2014-12-09 15:32:51 +00:00
#if (defined SSL_CTRL_SET_TLSEXT_STATUS_REQ_CB && !defined OPENSSL_NO_OCSP)
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 09:56:34 +00: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 16:36:30 +00:00
#endif
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 06:46:01 +00:00
#if (defined SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB && TLS_TICKETS_NO > 0)
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 09:56:34 +00:00
void ssl_sock_update_tlskey_ref(struct tls_keys_ref *ref,
struct buffer *tlskey);
int ssl_sock_update_tlskey(char *filename, struct buffer *tlskey, char **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 06:46:01 +00:00
struct tls_keys_ref *tlskeys_ref_lookup(const char *filename);
struct tls_keys_ref *tlskeys_ref_lookupid(int unique_id);
#endif
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 13:53:22 +00:00
#ifndef OPENSSL_NO_DH
int ssl_sock_load_global_dh_param_from_file(const char *filename);
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-21 01:10:18 +00:00
void ssl_free_dh(void);
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 13:53:22 +00: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-21 01:10:18 +00:00
void ssl_free_engines(void);
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 13:47:34 +00: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 10:35:51 +00:00
SSL_CTX *ssl_sock_create_cert(struct connection *conn, const char *servername, unsigned int key);
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 14:37:39 +00:00
SSL_CTX *ssl_sock_assign_generated_cert(unsigned int key, struct bind_conf *bind_conf, SSL *ssl);
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 10:35:51 +00:00
SSL_CTX *ssl_sock_get_generated_cert(unsigned int key, struct bind_conf *bind_conf);
int ssl_sock_set_generated_cert(SSL_CTX *ctx, unsigned int key, struct bind_conf *bind_conf);
unsigned int 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 11:39:32 +00: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 18:36:36 +00:00
/* ssl shctx macro */
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 19:08:51 +00:00
#define sh_ssl_sess_tree_delete(s) ebmb_delete(&(s)->key);
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 18:36:36 +00: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 19:08:51 +00:00
#define sh_ssl_sess_tree_insert(s) (struct sh_ssl_sess_hdr *)ebmb_insert(sh_ssl_sess_tree, \
&(s)->key, SSL_MAX_SSL_SESSION_ID_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 18:36:36 +00: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 19:08:51 +00:00
#define sh_ssl_sess_tree_lookup(k) (struct sh_ssl_sess_hdr *)ebmb_lookup(sh_ssl_sess_tree, \
(k), SSL_MAX_SSL_SESSION_ID_LENGTH);
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 13:47:34 +00:00
#endif /* _PROTO_SSL_SOCK_H */
/*
* Local variables:
* c-indent-level: 8
* c-basic-offset: 8
* End:
*/
Reference in New Issue Copy Permalink