[PATCH 3/3] DOC: Document new socket commands "show tls-keys" and "set ssl tls-key"
Signed-off-by: Nenad Merdanovic
---
doc/configuration.txt | 12
1 file changed, 12 insertions(+)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index 85d94d9..4ecde15 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -14678,6 +14678,13 @@ set ssl ocsp-response
echo "set ssl ocsp-response $(base64 -w 1 resp.der)" | \
socat stdio /var/run/haproxy.stat
+set ssl tls-key
+ Set the next TLS key for the listener to . This key becomes the
+ ultimate key, while the penultimate one is used for encryption (others just
+ decrypt). The oldest TLS key present is overwritten. is either a numeric
+ # or returned by "show tls-keys". is a base64 encoded 48
+ bit TLS ticket key (ex. openssl rand -base64 48).
+
set table key [data. ]*
Create or update a stick-table entry in the table. If the key is not present,
an entry is inserted. See stick-table in section 4.2 to find all possible
@@ -14912,6 +14919,11 @@ show table [ data. ] |
[ key ]
| fgrep 'key=' | cut -d' ' -f2 | cut -d= -f2 > abusers-ip.txt
( or | awk '/key/{ print a[split($2,a,"=")]; }' )
+show tls-keys
+ Dump all loaded TLS ticket keys. The TLS ticket key reference ID and the
+ file from which the keys have been loaded is shown. Both of those can be
+ used to update the TLS keys using "set ssl tls-key".
+
shutdown frontend
Completely delete the specified frontend. All the ports it was bound to will
be released. It will not be possible to enable the frontend anymore after
--
2.1.4
[PATCH 2/3] 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
---
include/proto/ssl_sock.h | 6 ++
include/types/applet.h | 5 ++
include/types/ssl_sock.h | 2 +
src/dumpstats.c | 161 +++
src/haproxy.c| 3 +
src/ssl_sock.c | 95
6 files changed, 272 insertions(+)
diff --git a/include/proto/ssl_sock.h b/include/proto/ssl_sock.h
index 6eb97eb..fa5eef5 100644
--- a/include/proto/ssl_sock.h
+++ b/include/proto/ssl_sock.h
@@ -58,6 +58,12 @@ unsigned int ssl_sock_get_verify_result(struct connection
*conn);
#if (defined SSL_CTRL_SET_TLSEXT_STATUS_REQ_CB && !defined OPENSSL_NO_OCSP)
int ssl_sock_update_ocsp_response(struct chunk *ocsp_response, char **err);
#endif
+#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
#endif /* _PROTO_SSL_SOCK_H */
diff --git a/include/types/applet.h b/include/types/applet.h
index c2db0ec..5efeea5 100644
--- a/include/types/applet.h
+++ b/include/types/applet.h
@@ -99,6 +99,11 @@ struct appctx {
struct pattern_expr *expr;
struct chunk chunk;
} map;
+#if (defined SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB && TLS_TICKETS_NO > 0)
+ struct {
+ struct tls_keys_ref *ref;
+ } tlskeys;
+#endif
struct {
int connected;
struct hlua_socket *socket;
diff --git a/include/types/ssl_sock.h b/include/types/ssl_sock.h
index 4642124..e71ba79 100644
--- a/include/types/ssl_sock.h
+++ b/include/types/ssl_sock.h
@@ -32,6 +32,8 @@ struct sni_ctx {
struct ebmb_node name;/* node holding the servername value */
};
+extern struct list tlskeys_reference;
+
struct tls_sess_key {
unsigned char name[16];
unsigned char aes_key[16];
diff --git a/src/dumpstats.c b/src/dumpstats.c
index b8e822f..a572e6a 100644
--- a/src/dumpstats.c
+++ b/src/dumpstats.c
@@ -66,6 +66,7 @@
#ifdef USE_OPENSSL
#include
+#include
#endif
/* stats socket states */
@@ -88,6 +89,7 @@ enum {
STAT_CLI_O_PAT, /* list all entries of a pattern */
STAT_CLI_O_MLOOK,/* lookup a map entry */
STAT_CLI_O_POOLS,/* dump memory pools */
+ STAT_CLI_O_TLSK, /* list all TLS ticket keys references */
};
/* Actions available for the stats admin forms */
@@ -134,6 +136,9 @@ static int stats_dump_stat_to_buffer(struct
stream_interface *si, struct uri_aut
static int stats_pats_list(struct stream_interface *si);
static int stats_pat_list(struct stream_interface *si);
static int stats_map_lookup(struct stream_interface *si);
+#if (defined SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB && TLS_TICKETS_NO > 0)
+static int stats_tlskeys_list(struct stream_interface *si);
+#endif
static void cli_release_handler(struct appctx *appctx);
/*
@@ -974,6 +979,51 @@ static struct server *expect_server_admin(struct stream
*s, struct stream_interf
return sv;
}
+/* This function is used with TLS ticket keys management. It permits to browse
+ * each reference. The variable must contain the current node,
+ * point to the root node.
+ */
+#if (defined SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB && TLS_TICKETS_NO > 0)
+static inline
+struct tls_keys_ref *tlskeys_list_get_next(struct tls_keys_ref *getnext,
struct list *end)
+{
+ struct tls_keys_ref *ref = getnext;
+
+ while (1) {
+
+ /* Get next list entry. */
+ ref = LIST_NEXT(&ref->list, struct tls_keys_ref *, list);
+
+ /* If the entry is the last of the list, return NULL. */
+ if (&ref->list == end)
+ return NULL;
+
+ return ref;
+ }
+}
+
+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
+
/* This function is used with map and acl management. It permits to brows
[PATCH 1/3] 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
---
include/types/listener.h | 3 +--
include/types/ssl_sock.h | 8
src/cfgparse.c | 6 +-
src/ssl_sock.c | 17 +++--
4 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/include/types/listener.h b/include/types/listener.h
index 142e845..895cd00 100644
--- a/include/types/listener.h
+++ b/include/types/listener.h
@@ -132,8 +132,7 @@ struct bind_conf {
int strict_sni;/* refuse negotiation if sni doesn't match a
certificate */
struct eb_root sni_ctx;/* sni_ctx tree of all known certs
full-names sorted by name */
struct eb_root sni_w_ctx; /* sni_ctx tree of all known certs wildcards
sorted by name */
- struct tls_sess_key *tls_ticket_keys; /* TLS ticket keys */
- int tls_ticket_enc_index; /* array index of the key to use for
encryption */
+ struct tls_keys_ref *keys_ref; /* TLS ticket keys reference */
#endif
int is_ssl;/* SSL is required for these listeners */
unsigned long bind_proc; /* bitmask of processes allowed to use these
listeners */
diff --git a/include/types/ssl_sock.h b/include/types/ssl_sock.h
index d769acd..4642124 100644
--- a/include/types/ssl_sock.h
+++ b/include/types/ssl_sock.h
@@ -38,4 +38,12 @@ struct tls_sess_key {
unsigned char hmac_key[16];
} __attribute__((packed));
+struct tls_keys_ref {
+ struct list list; /* Used to chain refs. */
+ char *filename;
+ int unique_id; /* Each pattern reference have unique id. */
+ struct tls_sess_key *tlskeys;
+ int tls_ticket_enc_index;
+};
+
#endif /* _TYPES_SSL_SOCK_H */
diff --git a/src/cfgparse.c b/src/cfgparse.c
index 8578bc5..e543dd8 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -7762,7 +7762,11 @@ out_uri_auth_compat:
free(bind_conf->ciphers);
free(bind_conf->ecdhe);
free(bind_conf->crl_file);
- free(bind_conf->tls_ticket_keys);
+ if(bind_conf->keys_ref) {
+ free(bind_conf->keys_ref->filename);
+ free(bind_conf->keys_ref->tlskeys);
+ free(bind_conf->keys_ref);
+ }
#endif /* USE_OPENSSL */
}
diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index eb1d88c..2029298 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -406,8 +406,8 @@ static int ssl_tlsext_ticket_key_cb(SSL *s, unsigned char
key_name[16], unsigned
int i;
conn = (struct connection *)SSL_get_app_data(s);
- keys = objt_listener(conn->target)->bind_conf->tls_ticket_keys;
- head = objt_listener(conn->target)->bind_conf->tls_ticket_enc_index;
+ keys = objt_listener(conn->target)->bind_conf->keys_ref->tlskeys;
+ head =
objt_listener(conn->target)->bind_conf->keys_ref->tls_ticket_enc_index;
if (enc) {
memcpy(key_name, keys[head].name, 16);
@@ -1783,7 +1783,7 @@ int ssl_sock_prepare_ctx(struct bind_conf *bind_conf,
SSL_CTX *ctx, struct proxy
}
#if (defined SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB && TLS_TICKETS_NO > 0)
- if(bind_conf->tls_ticket_keys) {
+ if(bind_conf->keys_ref) {
if (!SSL_CTX_set_tlsext_ticket_key_cb(ctx,
ssl_tlsext_ticket_key_cb)) {
Alert("Proxy '%s': unable to set callback for TLS
ticket validation for bind '%s' at [%s:%d].\n",
curproxy->id, bind_conf->arg, bind_conf->file,
bind_conf->line);
@@ -4359,6 +4359,7 @@ static int bind_parse_tls_ticket_keys(char **args, int
cur_arg, struct proxy *px
FILE *f;
int i = 0;
char thisline[LINESIZE];
+ struct tls_keys_ref *keys_ref;
if (!*args[cur_arg + 1]) {
if (err)
@@ -4366,7 +4367,8 @@ static int bind_parse_tls_ticket_keys(char **args, int
cur_arg, struct proxy *px
return ERR_ALERT | ERR_FATAL;
}
- conf->tls_ticket_keys = malloc(TLS_TICKETS_NO * sizeof(struct
tls_sess_key));
+ keys_ref = malloc(sizeof(struct tls_keys_ref));
+ keys_ref->tlskeys = malloc(TLS_TICKETS_NO * sizeof(struct
tls_sess_key));
if ((f = fopen(args[cur_arg + 1], "r")) == NULL) {
if (err)
@@ -4374,6 +4376,8 @@ static int bind_parse_tls_ticket_keys(char **args, int
cur_arg, struct proxy *px
return ERR_ALERT | ERR_FATAL;
}
+ keys_ref->filename = strdup(args[cur_arg + 1]);
+
while (fgets(thisline, sizeof(thisline), f) != NULL) {
int len = strlen(thisline);
/* Strip newline characters from the end */
@@ -4383,7 +4387,7 @@ static int bind_parse_tls_
[PATCH 0/3] Add support for TLS ticket key socket updates
This patchset adds support for updating TLS ticket keys using the admin socket. Nenad Merdanovic (3): MINOR: Add TLS ticket keys reference and use it in the listener struct MEDIUM: Add support for updating TLS ticket keys via socket DOC: Document new socket commands "show tls-keys" and "set ssl tls-key" doc/configuration.txt| 12 include/proto/ssl_sock.h | 6 ++ include/types/applet.h | 5 ++ include/types/listener.h | 3 +- include/types/ssl_sock.h | 10 +++ src/cfgparse.c | 6 +- src/dumpstats.c | 161 +++ src/haproxy.c| 3 + src/ssl_sock.c | 112 +++-- 9 files changed, 309 insertions(+), 9 deletions(-) -- 2.1.4
Re: Question on distribution not according to backend weight
Hi Babtiste, thanks a lot for your explanations! This totally makes sense, especially from a HA and throughput perspective. My use case is different and I'll try to explain how: * 30 servers are generating emails * 36 mail servers for sending out * relatively cheap h/w: 2 bonded 1Gbit interfaces, SAS h/w raid HAProxy is running locally on each of the email generating servers. HAProxy is distributing emails over all available SMTP servers. Running HAProxy on dedicated host(s) in between would create an SPOF and is not working from a throughput perspective (30 times 2Gbit). The email generating system is highly optimized and much quicker generating emails than the MTAs are able to spool to disk. I've configured the maxconn setting low to make sure the MTAs are not overwhelmed. The problem here is that since I use 30 servers upstream, I effectively get 30 times 2 max. concurrent sessions to a single MTA downstream. Increasing the value to 3 effectively means, 90. 4 means 120 concurrent connections and so on. I've looked into solving this differently using SMTP status codes like 4xx indicating resource exhaustion but that did not work well with the smtp_health check or the upstream generating email system. So why would I need a setting of weight 1 for a backend? Answer: configuration changes. E.g. when changing settings at the MTA I would like to run a small percentage of emails through this system and watch metrics before moving to full load. Maybe you have an idea how to solve this. Thanks for your time! Best regards, Frank 2015-05-08 6:23 GMT-07:00 Baptiste : > Hi Frank, > > > My problem: The weight setting for a backend seems to be ignored when the >> max concurrent session setting is reached. I was expecting the connection >> to get queued for this backend but it seems to flip over to the host that >> has connections available. >> > > This is expected. > The queue manager starts working as soon as at least one server as reached > its maxconn. It has > The weight is taken into account by the load-balancing algorithm, but > since the queue manager has precedence over it. > Hence as soon as a server has reached its maxconn, it is excluded from the > load-balancing algorithm. Then the relative weight of the remaining server > is applied. > > > >> I simplified my setup to 2 backend smtp servers, one with weight 100, the >> other with weight 1. The max connection setting is set to 2. I'm opening >> multiple SMTP connections simultaneously to this haproxy server. Attached >> screenshot from haproxy stats shows that backend with weight 1 gets way too >> many sessions. >> >> Increasing max concurrent sessions to 5 or more seem to prevent this >> behavior, but I'm not totally sure about this. >> > > The question is "Why do you need a maxconn to 2 on your servers?" > > > >> I would like to have only a small fraction (100:1) of requests go to the >> backend with the lower weight and wonder how to do this correctly. It's >> more important to me to have a defined distribution of connections going to >> backends than answering requests as quickly as possible regardless of what >> backend is used. >> >> > the weight is the good way to go, simply increase your maxconn, unless > there is a good reason for it to be as low as 2. > > Baptiste > > >
Re: Is FTP through haproxy at all viable?
On 5/8/2015 8:39 AM, Ben Timby wrote: > With some iptables rules you can use FTP active and passive mode via > haproxy. > > The key is to assign unique passive port ranges to each backend then > port forward those ranges. You must be able to configure each FTP server > daemon with it's own range. > > You must also be able to configure your FTP daemon to maquerade as the > load balancer so that it sends the proper address for port commands etc. > Most FTP servers support the necessary optiona. The FTP servers are ncftpd. If we configure it this way, then we will ONLY be able to access passive FTP through haproxy, whereas currently (with the old software) we can access it by going direct to the back end server *or* through the VIP. If this is the only way I can get it working, I'll do it, but I don't like losing functionality. I'm very curious why I can't simply use the kernel load balancer in 3.13 like I can in 2.6.18, and have it handle passive FTP with the ip_vs_ftp module. I've filed an ubuntu bug against the kernel: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/145318 I am starting to get the impression that I will need to enable the Linux firewall for either haproxy or LVS ... if that's the case, I will need instructions specific to ubuntu, so it will work properly with ufw. Thanks, Shawn
Re: Question on rewriting query string
Wow, very nice, regular expressions sure are powerful :-) Here is what I ended up with: defaults mode http timeout connect 1s timeout client 1s timeout server 1s listen HTTP-in bind 127.0.0.1:80 reqrep .*(sid=[a-z0-9A-Z]*)&(sid_guid=[^&]*)&.*(strid=[0-9a-zA-Z]*) \1&\2&\3&shopurl=search.aspx redirect code 301 prefix http://shop.companyx.com/shop.aspx? curl -i "http://localhost/?sid=100026264&sid_guid=342ca0f2-beb0-4132-b188-5f162941bb83"; HTTP/1.1 301 Moved Permanently Content-length: 0 Location: http://shop.companyx.com/shop.aspx/?sid=100026264&sid_guid=342ca0f2-beb0-4132-b188-5f162941bb83 Connection: close On May 07, 2015, at 05:27 PM, Aleksandar Lazic wrote: I would use "reqrep" https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4-reqrep Example: reqrep .*(sid=[a-z0-9A-Z]*)&(sid_guid=[^&]*)&.*(strid=[0-9a-zA-Z]*) http://shop.companyx.com/shop.aspx?\1&\2&\3&shopurl=search.aspx I have build the regex with https://regex101.com/ Maybe there is a option to use a more generic way as in lua with. https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#url_param BR Aleks
Re: Is FTP through haproxy at all viable?
With some iptables rules you can use FTP active and passive mode via haproxy. The key is to assign unique passive port ranges to each backend then port forward those ranges. You must be able to configure each FTP server daemon with it's own range. You must also be able to configure your FTP daemon to maquerade as the load balancer so that it sends the proper address for port commands etc. Most FTP servers support the necessary optiona. On May 8, 2015 10:20 AM, "Baptiste" wrote: > On Fri, May 8, 2015 at 4:02 PM, Shawn Heisey wrote: > > I have a load balancer setup with both haproxy and LVS-NAT. The LVS-NAT > > is giving us high availability for FTP. > > > > When I tried migrating everything from CentOS 5, where it all works, to > > Ubuntu 14 (for the newer kernel and because I find debian-based systems > > far easier to use), everything worked except passive FTP. > > > > Is there a viable solution for FTP through haproxy? The machine has > > public IP addresses on one side and private on the other, and is > > configured with ip forwarding turned on, so the redundant pair acts as > > the default gateway for the backend machines. Everything is behind a > > Cisco firewall, so I have disabled the ufw firewall that Ubuntu includes. > > > > Alternatively, if someone can help me make passive FTP work through > > LVS-NAT like it does on CentOS, I am fine with that. I've asked for > > help on that here: > > > > > http://askubuntu.com/questions/620853/lvs-nat-doesnt-work-with-passive-ftp-active-ftp-is-fine > > > > Thanks, > > Shawn > > > > > Hi Shawn, > > Well, FTP can work in active mode only. > To configure it, you must open port 21 and the active ports where you > FTP server expects the user to get connected to. > > Baptiste > >
Re: Is FTP through haproxy at all viable?
On Fri, May 8, 2015 at 4:02 PM, Shawn Heisey wrote: > I have a load balancer setup with both haproxy and LVS-NAT. The LVS-NAT > is giving us high availability for FTP. > > When I tried migrating everything from CentOS 5, where it all works, to > Ubuntu 14 (for the newer kernel and because I find debian-based systems > far easier to use), everything worked except passive FTP. > > Is there a viable solution for FTP through haproxy? The machine has > public IP addresses on one side and private on the other, and is > configured with ip forwarding turned on, so the redundant pair acts as > the default gateway for the backend machines. Everything is behind a > Cisco firewall, so I have disabled the ufw firewall that Ubuntu includes. > > Alternatively, if someone can help me make passive FTP work through > LVS-NAT like it does on CentOS, I am fine with that. I've asked for > help on that here: > > http://askubuntu.com/questions/620853/lvs-nat-doesnt-work-with-passive-ftp-active-ftp-is-fine > > Thanks, > Shawn > Hi Shawn, Well, FTP can work in active mode only. To configure it, you must open port 21 and the active ports where you FTP server expects the user to get connected to. Baptiste
Is FTP through haproxy at all viable?
I have a load balancer setup with both haproxy and LVS-NAT. The LVS-NAT is giving us high availability for FTP. When I tried migrating everything from CentOS 5, where it all works, to Ubuntu 14 (for the newer kernel and because I find debian-based systems far easier to use), everything worked except passive FTP. Is there a viable solution for FTP through haproxy? The machine has public IP addresses on one side and private on the other, and is configured with ip forwarding turned on, so the redundant pair acts as the default gateway for the backend machines. Everything is behind a Cisco firewall, so I have disabled the ufw firewall that Ubuntu includes. Alternatively, if someone can help me make passive FTP work through LVS-NAT like it does on CentOS, I am fine with that. I've asked for help on that here: http://askubuntu.com/questions/620853/lvs-nat-doesnt-work-with-passive-ftp-active-ftp-is-fine Thanks, Shawn
Re: Question on distribution not according to backend weight
Hi Frank, My problem: The weight setting for a backend seems to be ignored when the > max concurrent session setting is reached. I was expecting the connection > to get queued for this backend but it seems to flip over to the host that > has connections available. > This is expected. The queue manager starts working as soon as at least one server as reached its maxconn. It has The weight is taken into account by the load-balancing algorithm, but since the queue manager has precedence over it. Hence as soon as a server has reached its maxconn, it is excluded from the load-balancing algorithm. Then the relative weight of the remaining server is applied. > I simplified my setup to 2 backend smtp servers, one with weight 100, the > other with weight 1. The max connection setting is set to 2. I'm opening > multiple SMTP connections simultaneously to this haproxy server. Attached > screenshot from haproxy stats shows that backend with weight 1 gets way too > many sessions. > > Increasing max concurrent sessions to 5 or more seem to prevent this > behavior, but I'm not totally sure about this. > The question is "Why do you need a maxconn to 2 on your servers?" > I would like to have only a small fraction (100:1) of requests go to the > backend with the lower weight and wonder how to do this correctly. It's > more important to me to have a defined distribution of connections going to > backends than answering requests as quickly as possible regardless of what > backend is used. > > the weight is the good way to go, simply increase your maxconn, unless there is a good reason for it to be as low as 2. Baptiste
Re: Question on distribution not according to backend weight
> On 8 мая 2015 г., at 4:54, Frank Schubert wrote: > > Hi, > > first of all let me thank you for an amazing piece of software. I like > working with haproxy a lot! > > My problem: The weight setting for a backend seems to be ignored when the max > concurrent session setting is reached. I was expecting the connection to get > queued for this backend but it seems to flip over to the host that has > connections available. > > I simplified my setup to 2 backend smtp servers, one with weight 100, the > other with weight 1. The max connection setting is set to 2. I'm opening > multiple SMTP connections simultaneously to this haproxy server. Attached > screenshot from haproxy stats shows that backend with weight 1 gets way too > many sessions. > > Increasing max concurrent sessions to 5 or more seem to prevent this > behavior, but I'm not totally sure about this. > > I would like to have only a small fraction (100:1) of requests go to the > backend with the lower weight and wonder how to do this correctly. It's more > important to me to have a defined distribution of connections going to > backends than answering requests as quickly as possible regardless of what > backend is used. > > > This screenshot also illustrates incorrect Max Request Rate calculation I reported 2 years ago: http://www.serverphorums.com/read.php?10,623596
