Re: http-ignore-probes produces a warning in tcp frontend

[Dmitry Sivachenko]

> On 04 Feb 2016, at 07:04, Willy Tarreau  wrote:
> 
> Hello Dmitry,
> 
> On Thu, Jan 28, 2016 at 05:31:58PM +0300, Dmitry Sivachenko wrote:
>> Hello,
>> 
>> I have an option http-ignore-probes in defaults section.
>> When I declare frontend in "tcp" mode, I get the following warning:
>> 
>> [WARNING] 027/172718 (18281) : config : 'option http-ignore-probes' ignored
>> for frontend 'MYTEST-front' as it requires HTTP mode.
>> 
>> In defaults section I have other http-specific options (e.g.
>> http-keep-alive), which does not produce a warning in tcp backend.
>> Is it intended?  It looks logical to produce such a warning only if
>> http-specific option is used directly in tcp backend and silently ignore it
>> when used in defaults.
> 
> There's no difference between having the option in defaults or explicitly
> in the section itself. You should see defaults as templates for next
> sections. The error here is that http-keep-alive should also produce a
> warning. But I think I know why it doesn't, most options are handled by
> a generic parser which checks the proxy mode, and a few other more
> complex ones are implemented "by hand" and do not necessarily run such
> checks.
> 
> It's a very bad practise to mix TCP and HTTP proxies with the same defaults
> sections. This probably is something we should document better in the doc.
> A good practise is to have one (or several) defaults sections for HTTP mode
> and then other defaults sections for TCP mode. And most often you don't even
> have the same timeouts, log settings etc.
> 


Thanks for the explanation!

I just realized that there can be multiple defaults sections, so your arguments 
look valid.

Re: Protecting against slow HTTP POST queries

[Baptiste]

On Thu, Feb 4, 2016 at 9:44 AM, Sylvain Faivre
 wrote:
> Hi,
>
> Is there a timeout setting in HAproxy that can help protect against slow
> HTTP POST queries ?
>
> I'm not talking about "slow loris" type attacks (where the client sleeps
> between request headers) but "slow HTTP POST" (where the client sleeps
> between POST data lines).
>
> Here is an example :
>
> - Test 1 :
>
> root@proxy1>: telnet localhost 85
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> POST /test HTTP/1.1
> Host: host.domain.com
> User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
> Content-Type: application/json; charset=utf-8
> Content-Length: 1234
>
> test
>
> <>
>
> HTTP/1.1 408 Request Time-out
> Date: Wed, 03 Feb 2016 13:03:30 GMT
> Content-Length: 223
> Content-Type: text/html; charset=iso-8859-1
>
> 
> 
> 408 Request Time-out
> 
> Request Time-out
> Server timeout waiting for the HTTP request from the client.
> 
> Connection closed by foreign host.
>
>
> - Test 2 :
>
> Here we send the POST body very slowly (line by line, wait 10 seconds
> between each line).
>
> root@proxy1>: telnet localhost 85
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> POST /test HTTP/1.1
> Host: host.domain.com
> User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
> Content-Type: application/json; charset=utf-8
> Content-Length: 1234
>
> test
> <>
> test
> <>
> test
> <>
> test
> <>
> test
> <>
> test
> <>
> test
> <>
> Connection closed by foreign host.
>
>
> In each case, HAproxy log shows termination flags "SD--" which means the
> application server closed the connection.
>
> So, the app server timeouts after 30 seconds, but this duration is reset
> each time the client sends data in the POST body.
>
> Is there an option to set a timeout on this part of the request ? It should
> be similar to "timeout http-request" but work against the request body,
> instead of the request headers.
>
> We already have these settings, but none of them seems to act against HTTP
> POST content (I was able to stay connected while sending HTTP POST content
> for 5+ minutes) :
>
> timeout connect 5s
> timeout http-request12s
> timeout queue   180s
> timeout client  180s
> timeout server  180s
> timeout http-keep-alive 10s
> timeout tarpit  30s
>
>
> Best regards,
>
> Sylvain
>


Hi,

please run the same test against HAProxy 1.6 and enable "option
buffer-http-request":
http://cbonte.github.io/haproxy-dconv/snapshot/configuration-1.6.html#4-option%20http-buffer-request

Then your timeout http-request will also match the POSTed data.

Baptiste

Simulation et guide offert

[Loi Pinel]

Afficher la version web. (http://trk.mix.jajaris.fr/view/uK8-6HFFI.php) | 
Annuler votre abonnement. (http://trk.mix.jajaris.fr/usb/uK8-6HFFI.php) | 
Signaler comme courrier indésirable. (mailto:ab...@dgcnit.fr)

http://trk.mix.jajaris.fr/tk/uK8-6HFFI-wp3.php
http://trk.mix.jajaris.fr/tk/uK8-6HFFI-wp3.php
http://trk.mix.jajaris.fr/tk/uK8-6HFFI-wp3.php
http://trk.mix.jajaris.fr/tk/uK8-6HFFI-wp3.php
http://trk.mix.jajaris.fr/tk/uK8-6HFFI-wp3.php
http://trk.mix.jajaris.fr/tk/uK8-6HFFI-wp3.php
http://trk.mix.jajaris.fr/tk/uK8-6HFFI-wp3.php
http://trk.mix.jajaris.fr/tk/uK8-6HFFI-wp3.php 
http://trk.mix.jajaris.fr/tk/uK8-6HFFI-wp3.php
http://trk.mix.jajaris.fr/tk/uK8-6HFFI-wp3.php 
http://trk.mix.jajaris.fr/tk/uK8-6HFFI-wp3.php
http://trk.mix.jajaris.fr/tk/uK8-6HFFI-wp3.php

Conformément à la loi Informatique et Liberté n° 78-17 du 6 janvier 
1978 modifiée, vous bénéficiez d'un droit d'accès, de rectification, 
d'opposition et de suppression des données vous concernant.
Vous souhaitez vous désinscrire de cette liste ? Cliquez ici. 
(http://trk.mix.jajaris.fr/usb/uK8-6HFFI.php)

[PATCH] MAJOR: ssl: add 'tcp-fallback' bind option for SSL listeners

[Christopher Faulet]

 >From a3b372da2463e98b13e016c9b56344757b0e94bc Mon Sep 17 00:00:00 2001
From: Christopher Faulet 
Date: Wed, 29 Jul 2015 16:01:57 +0200
Subject: [PATCH] MAJOR: ssl: add 'tcp-fallback' bind option for SSL listeners

This option can be use to fall back on TCP when a non-SSL connection is
established on a SSL listener. A delay must be defined to set the maximum time
to decide if an incoming connection is a SSL connection or a TCP connection. If
the timeout is reached or if the SSL detection failed, we fall back on TCP. By
setting it to 0, haproxy will wait infinitely more data to detect the connection
type.

If used, this option must be set on a ssl bind line:

  bind 0.0.0.0:1234 ssl ... tcp-fallback 250ms

It is a good idea to set a timeout if you expect to handle 'server-initiated'
protocols, like SMTP. Else the connection will be blocked on the SSL
detection. If you are sure to handle 'client-initiated' protocols only, it is
safe to set it to 0.

Internally, the detection is inverted. Each connection is started as a TCP
connection and we try to switch it in SSL by parsing the first few bytes sent by
the client to detect SSL ClientHello message.
---
 doc/configuration.txt  |  12 +
 include/proto/connection.h |   1 +
 include/proto/ssl_sock.h   |   1 +
 include/types/connection.h |   5 ++-
 include/types/listener.h   |  29 +++-
 src/connection.c   |   4 ++
 src/listener.c |   7 ++-
 src/session.c  |   7 ++-
 src/ssl_sock.c | 107 -
 9 files changed, 156 insertions(+), 17 deletions(-)

diff --git a/doc/configuration.txt b/doc/configuration.txt
index 7dd5744..89dcd0a 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -9960,6 +9960,18 @@ strict-sni
   a certificate. The default certificate is not used.
   See the "crt" option for more information.
 
+tcp-fallback 
+  This setting is only available when support for OpenSSL was built in. It
+  enables a TCP fallback for SSL listeners when a non-SSL connection is
+  established or when the timeout is reached before the SSL ClientHello message
+  is received. By setting the delay to 0, haproxy will wait infinitely. It is a
+  good idea to set a delay if you expect to handle 'server-initiated'
+  protocols, like SMTP. Else the connection will be blocked, waiting a SSL
+  ClientHello message that could never be received. The drawback using this
+  option for such protocols is to add a latency for all non-SSL connections. If
+  you are sure to handle 'client-initiated' protocols only, it is safe to set
+  it to 0.
+
 tcp-ut 
   Sets the TCP User Timeout for all incoming connections instanciated from this
   listening socket. This option is available on Linux since version 2.6.37. It
diff --git a/include/proto/connection.h b/include/proto/connection.h
index 952f9ea..b63aef1 100644
--- a/include/proto/connection.h
+++ b/include/proto/connection.h
@@ -482,6 +482,7 @@ static inline void conn_init(struct connection *conn)
 	conn->target = NULL;
 	conn->proxy_netns = NULL;
 	LIST_INIT(>list);
+	conn->ssl_detection_exp = 0;
 }
 
 /* Tries to allocate a new connection and initialized its main fields. The
diff --git a/include/proto/ssl_sock.h b/include/proto/ssl_sock.h
index cb9a1e9..71dd727 100644
--- a/include/proto/ssl_sock.h
+++ b/include/proto/ssl_sock.h
@@ -43,6 +43,7 @@ int ssl_sock_is_ssl(struct connection *conn)
 }
 
 int ssl_sock_handshake(struct connection *conn, unsigned int flag);
+int ssl_sock_detection(struct connection *conn, int flag);
 int ssl_sock_prepare_ctx(struct bind_conf *bind_conf, SSL_CTX *ctx, struct proxy *proxy);
 int ssl_sock_prepare_all_ctx(struct bind_conf *bind_conf, struct proxy *px);
 int ssl_sock_prepare_srv_ctx(struct server *srv, struct proxy *px);
diff --git a/include/types/connection.h b/include/types/connection.h
index dfbff6a..185c630 100644
--- a/include/types/connection.h
+++ b/include/types/connection.h
@@ -107,10 +107,10 @@ enum {
 	CO_FL_SEND_PROXY= 0x0100,  /* send a valid PROXY protocol header */
 	CO_FL_SSL_WAIT_HS   = 0x0200,  /* wait for an SSL handshake to complete */
 	CO_FL_ACCEPT_PROXY  = 0x0400,  /* receive a valid PROXY protocol header */
-	/* unused : 0x0800 */
+	CO_FL_SSL_DETECTION = 0x0800,  /* try to detect ssl connection */
 
 	/* below we have all handshake flags grouped into one */
-	CO_FL_HANDSHAKE = CO_FL_SEND_PROXY | CO_FL_SSL_WAIT_HS | CO_FL_ACCEPT_PROXY,
+	CO_FL_HANDSHAKE = CO_FL_SEND_PROXY | CO_FL_SSL_WAIT_HS | CO_FL_ACCEPT_PROXY | CO_FL_SSL_DETECTION,
 
 	/* when any of these flags is set, polling is defined by socket-layer
 	 * operations, as opposed to data-layer. Transport is explicitly not
@@ -257,6 +257,7 @@ struct connection {
 	void *xprt_ctx;   /* general purpose pointer, initialized to NULL */
 	void *owner;  /* pointer to upper layer's entity (eg: stream interface) */
 	int xprt_st;  

Re: Protecting against slow HTTP POST queries

[Sylvain Faivre]

On 02/04/2016 12:06 PM, Baptiste wrote:

On Thu, Feb 4, 2016 at 9:44 AM, Sylvain Faivre
 wrote:

Hi,

Is there a timeout setting in HAproxy that can help protect against slow
HTTP POST queries ?


>> [...]



please run the same test against HAProxy 1.6 and enable "option
buffer-http-request":
http://cbonte.github.io/haproxy-dconv/snapshot/configuration-1.6.html#4-option%20http-buffer-request

Then your timeout http-request will also match the POSTed data.



Hi Baptiste,

This did the trick, thanks.

Sylvain

[PATCH] BUG/MINOR: ssl: Be sure to use unique serial for regenerated certificates

[Christopher Faulet]

 >From 5d3a89943c9eb855837c0d606ae361825b6e2800 Mon Sep 17 00:00:00 2001
From: Christopher Faulet 
Date: Thu, 12 Nov 2015 11:35:51 +0100
Subject: [PATCH] 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)
---
 include/proto/ssl_sock.h |  8 
 src/ssl_sock.c   | 42 +++---
 2 files changed, 27 insertions(+), 23 deletions(-)

diff --git a/include/proto/ssl_sock.h b/include/proto/ssl_sock.h
index 24b4330..cb9a1e9 100644
--- a/include/proto/ssl_sock.h
+++ b/include/proto/ssl_sock.h
@@ -71,10 +71,10 @@ void tlskeys_finalize_config(void);
 int ssl_sock_load_global_dh_param_from_file(const char *filename);
 #endif
 
-SSL_CTX *ssl_sock_create_cert(struct connection *conn, const char *servername, unsigned int serial);
-SSL_CTX *ssl_sock_get_generated_cert(unsigned int serial, struct bind_conf *bind_conf);
-int ssl_sock_set_generated_cert(SSL_CTX *ctx, unsigned int serial, struct bind_conf *bind_conf);
-unsigned int ssl_sock_generated_cert_serial(const void *data, size_t len);
+SSL_CTX *ssl_sock_create_cert(struct connection *conn, const char *servername, unsigned int key);
+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);
 
 #endif /* _PROTO_SSL_SOCK_H */
 
diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index 5200069..5cec6a4 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -1118,9 +1118,10 @@ static DH *ssl_get_tmp_dh(SSL *ssl, int export, int keylen);
 /* Create a X509 certificate with the specified servername and serial. This
  * function returns a SSL_CTX object or NULL if an error occurs. */
 static SSL_CTX *
-ssl_sock_do_create_cert(const char *servername, unsigned int serial,
-			struct bind_conf *bind_conf, SSL *ssl)
+ssl_sock_do_create_cert(const char *servername, struct bind_conf *bind_conf, SSL *ssl)
 {
+	static unsigned int serial = 0;
+
 	X509 *cacert  = bind_conf->ca_sign_cert;
 	EVP_PKEY *capkey  = bind_conf->ca_sign_pkey;
 	SSL_CTX  *ssl_ctx = NULL;
@@ -1143,7 +1144,9 @@ ssl_sock_do_create_cert(const char *servername, unsigned int serial,
 	 * number */
 	if (X509_set_version(newcrt, 2L) != 1)
 		goto mkcert_error;
-	ASN1_INTEGER_set(X509_get_serialNumber(newcrt), serial);
+	if (!serial)
+		serial = now_ms;
+	ASN1_INTEGER_set(X509_get_serialNumber(newcrt), serial++);
 
 	/* Set duration for the certificate */
 	if (!X509_gmtime_adj(X509_get_notBefore(newcrt), (long)-60*60*24) ||
@@ -1248,21 +1251,22 @@ ssl_sock_do_create_cert(const char *servername, unsigned int serial,
 }
 
 SSL_CTX *
-ssl_sock_create_cert(struct connection *conn, const char *servername, unsigned int serial)
+ssl_sock_create_cert(struct connection *conn, const char *servername, unsigned int key)
 {
 	struct bind_conf *bind_conf = objt_listener(conn->target)->bind_conf;
-	return ssl_sock_do_create_cert(servername, serial, bind_conf, conn->xprt_ctx);
+
+	return ssl_sock_do_create_cert(servername, bind_conf, conn->xprt_ctx);
 }
 
 /* Do a lookup for a certificate in the LRU cache used to store generated
  * certificates. */
 SSL_CTX *
-ssl_sock_get_generated_cert(unsigned int serial, struct bind_conf *bind_conf)
+ssl_sock_get_generated_cert(unsigned int key, struct bind_conf *bind_conf)
 {
 	struct lru64 *lru = NULL;
 
 	if (ssl_ctx_lru_tree) {
-		lru = lru64_lookup(serial, ssl_ctx_lru_tree, bind_conf->ca_sign_cert, 0);
+		lru = lru64_lookup(key, ssl_ctx_lru_tree, bind_conf->ca_sign_cert, 0);
 		if (lru && lru->domain)
 			return (SSL_CTX *)lru->data;
 	}
@@ -1272,12 +1276,12 @@ ssl_sock_get_generated_cert(unsigned int serial, struct bind_conf *bind_conf)
 /* Set a certificate int the LRU cache used to store generated
  * certificate. Return 0 on success, otherwise -1 */
 int
-ssl_sock_set_generated_cert(SSL_CTX *ssl_ctx, unsigned int serial, struct bind_conf *bind_conf)
+ssl_sock_set_generated_cert(SSL_CTX *ssl_ctx, unsigned int key, struct bind_conf *bind_conf)
 {
 	struct lru64 *lru = NULL;
 
 	if (ssl_ctx_lru_tree) {
-		lru = lru64_get(serial, ssl_ctx_lru_tree, bind_conf->ca_sign_cert, 0);
+		lru = lru64_get(key, ssl_ctx_lru_tree, bind_conf->ca_sign_cert, 0);
 		if 

Protecting against slow HTTP POST queries

[Sylvain Faivre]

Hi,

Is there a timeout setting in HAproxy that can help protect against slow 
HTTP POST queries ?


I'm not talking about "slow loris" type attacks (where the client sleeps 
between request headers) but "slow HTTP POST" (where the client sleeps 
between POST data lines).


Here is an example :

- Test 1 :

root@proxy1>: telnet localhost 85
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
POST /test HTTP/1.1
Host: host.domain.com
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
Content-Type: application/json; charset=utf-8
Content-Length: 1234

test

<>

HTTP/1.1 408 Request Time-out
Date: Wed, 03 Feb 2016 13:03:30 GMT
Content-Length: 223
Content-Type: text/html; charset=iso-8859-1



408 Request Time-out

Request Time-out
Server timeout waiting for the HTTP request from the client.

Connection closed by foreign host.


- Test 2 :

Here we send the POST body very slowly (line by line, wait 10 seconds 
between each line).


root@proxy1>: telnet localhost 85
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
POST /test HTTP/1.1
Host: host.domain.com
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
Content-Type: application/json; charset=utf-8
Content-Length: 1234

test
<>
test
<>
test
<>
test
<>
test
<>
test
<>
test
<>
Connection closed by foreign host.


In each case, HAproxy log shows termination flags "SD--" which means the 
application server closed the connection.


So, the app server timeouts after 30 seconds, but this duration is reset 
each time the client sends data in the POST body.


Is there an option to set a timeout on this part of the request ? It 
should be similar to "timeout http-request" but work against the request 
body, instead of the request headers.


We already have these settings, but none of them seems to act against 
HTTP POST content (I was able to stay connected while sending HTTP POST 
content for 5+ minutes) :


timeout connect 5s
timeout http-request12s
timeout queue   180s
timeout client  180s
timeout server  180s
timeout http-keep-alive 10s
timeout tarpit  30s


Best regards,

Sylvain