RepoMirrors
/
haproxy
mirror of http://git.haproxy.org/git/haproxy.git/
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
haproxy/include/proto/ssl_sock.h

76 lines
2.7 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>
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 22:19:48 +00:00
extern struct xprt_ops ssl_sock;
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)
{
if (!conn || conn->xprt != &ssl_sock || !conn->xprt_ctx)
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);
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
int ssl_sock_prepare_ctx(struct bind_conf *bind_conf, SSL_CTX *ctx, struct proxy *proxy);
void ssl_sock_free_certs(struct bind_conf *bind_conf);
int ssl_sock_prepare_all_ctx(struct bind_conf *bind_conf, struct proxy *px);
MINOR: ssl: move ssl context init for servers from cfgparse.c to ssl_sock.c
2012-10-11 12:00:19 +00:00
int ssl_sock_prepare_srv_ctx(struct server *srv, struct proxy *px);
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: 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);
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
char *ssl_sock_get_version(struct connection *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 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);
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 16:26:41 +00:00
int ssl_sock_get_remote_common_name(struct connection *conn, struct chunk *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)
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
int ssl_sock_update_ocsp_response(struct chunk *ocsp_response, char **err);
#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)
int ssl_sock_update_tlskey(char *filename, struct chunk *tlskey, char **err);
struct tls_keys_ref *tlskeys_ref_lookup(const char *filename);
struct tls_keys_ref *tlskeys_ref_lookupid(int unique_id);
void tlskeys_finalize_config(void);
#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 13:47:34 +00:00
#endif /* _PROTO_SSL_SOCK_H */
/*
* Local variables:
* c-indent-level: 8
* c-basic-offset: 8
* End:
*/