Bye, bye
We are sorry that you decided to opt-out. We confirm that this email account haproxy@formilux.org has un-subscribed.
Re: patch proposal: ssl_c_cert
Hi Willy,
On Fri, May 09, Willy Tarreau wrote:
This patch should be compatible with apache/mod_ssl
(RequestHeader set SSL_CLIENT_CERT %{SSL_CLIENT_CERT}s)
(newlines in the pem cert are replaced with space chars).
I'm wondering whether there is a risk that this same cert could be used
encoded differently. Eg, currently we have it in PEM and replace new lines
with spaces, but would it make sense sometimes for example to hash it and
just pass a hash or whatever ?
I don't know about hashes, but googling shows that there seems to
be quite few slightly different formats (some examples below).
My question comes from the fact that we have sample converters and that
in my opinion, the conversion to the PEM format is very simple (eg:
add -BEGIN CERTIFICATE-\n, encode in base64 then END).
Similarly we could have the PEM converter chose the delimiting character
to be used. And BTW we already have the base64 converter, but I don't
think it would provide any value here.
So basically the output format could be built using this string :
ssl_c_cert,pem(CERTIFICATE)
With :
- ssl_c_cert outputting raw binary
- pem(type) being the PEM encoder (prepend the BEGIN and append
the END line, encode in base64 each block of 48 bytes, and emit
a spacexs)
This sounds reasonable. With this approach it should be fairly
easy to support other SSL_CLIENT_CERT header formats:
- just plain base64: ssl_c_cert,base64
- base64(pem): ssl_c_cert,pem(CERTIFICATE,\n),base64
(https://devcentral.f5.com/questions/irule-to-pass-client-ssl-cert-to-the-application-server-pool-member)
- pem encoded with newlines removed (pound compiled w/--enable-cert1l):
ssl_c_cert,pem(CERTIFICATE) ?
- nginx seems to be changing how they output the cert
(http://forum.nginx.org/read.php?29,249804,249848):
ssl_c_cert,pem(CERTIFICATE,\r\n\t)
An optional t argument to the pem encoder would emit tabs instead
of spaces to be compatible with pound/nginx.
Apache adds space(' ') after -END CERTIFICATE- line, but
I think nginx/pound compat. output should not add anything after
-END CERTIFICATE- ?
So should the pem converter take third argument: end marker?
- so apache compat: ssl_c_cert,pem(CERTIFICATE, , )
- nginx/pound: ssl_c_cert,pem(CERTIFICATE, \r\n\t)
I might have some time next week or so to try to do this.
Can you give some pointers (for example which functions I could use
to look for examples) ?
I assume that ssl_c_cert would fetch function (similar to my earlier
patch, but returning the cert in raw binary) and pem would be converter
(like sample_conv_bin2base64) ?
-Jarno
(pound / nginx use different formatting for the cert:
X-SSL-certificate: -BEGIN CERTIFICATE-
\t...
\t-END CERTIFICATE-).
The code to replace newlines with spaces is not optimized. If there's a
guarantee that openssl PEM_write_bio_X509 will always format the pem
cert in same way(
-BEGIN CERTIFICATE-
MIIEoTCCA4mgAwIBAgIQIHCGEzfaVEFkF5d4JxstDTANBgkqhkiG9w0BAQUFADA2
r8q5R89n4IPaS0DaE4I+/W15CPs/AUlkUh6vy2v+PY+WRlie6g==
-END CERTIFICATE-) -- are the base64 encoded lines always 64chars
(except the last line) ?
We really cannot rely on this I think, it sounds quite dangerous. Also,
the cost of translating new lines into spaces is low compared to computing
the cert output!
-- the loop could be optimized to start from pos 27 (end of BEGIN line)
and jump 65 chars until end of last line.
Well, at least the with pem converter described above you would get this
for free :-)
Is this something that could be included in haproxy ?
Sure, I'm just trying to figure what would be the best way to do it so
that we don't have to modify it in 6 months :-)
Re: [PATCH] Add a configurable support of standardized DH parameters = 1024 bits, disabled by default
Hi,
On 05/05/2014 12:06 PM, Sander Klein wrote:
I've added a 2048bit dhparam to my most used certificates and I don't
see a big jump in resource usage.
This was not a big scientific test, I just added the DH params in my
production and looked if the haproxy process started eating more CPU. As
far as I can tell CPU usage went up just a couple percent. Not a very
big deal.
So, to me using 2048bit doesn't seem like a problem. And. I can
always switch to nbproc 1 ;-)
Thank you Sander for taking the time to do this test! I am still not
sure it is a good idea to move a default of 2048 bits though.
Here is a new version of the previous patch that should not require
OpenSSL 0.9.8a to build, but instead includes the needed primes from
rfc2409 and rfc3526 if OpenSSL does not provide them. I have to admit I
don't have access to an host with an old enough OpenSSL to test it
correctly. It still defaults to use 1024 bits DHE parameters in order
not to break anything.
Willy, do you have any thoughts about this patch or any other way to
simplify the use of stronger DHE parameters in haproxy 1.5? I know it
can already be done by generating static DH parameters, but I am afraid
most administrators may find it too complicated and therefore not dare
to test it.
Best regards,
--
Rémi Gacogne
Aqua Ray
SAS au capital de 105.720 Euros
RCS Créteil 447 997 099
www.aquaray.fr
14, rue Jules Vanzuppe
94854 IVRY-SUR-SEINE CEDEX (France)
Tel : (+33) (0)1 84 04 04 05
Fax : (+33) (0)1 77 65 60 42
From b616a26f62e7a7eacd30d1ab1ff5a04539146539 Mon Sep 17 00:00:00 2001
From: Remi Gacogne rgacogne[at]aquaray[dot]fr
Date: Mon, 12 May 2014 18:07:15 +0200
Subject: [PATCH] Add the option to use standardized DH parameters = 1024 bits
When no static DH parameters are specified, this patch makes haproxy
use standardized (rfc 2409 / rfc 3526) DH parameters with prime lenghts
of 1024, 2048, 4096 or 8192 bits for DHE key exchange. The size of the
temporary/ephemeral DH key is computed as the minimum of the RSA/DSA server
key size and the value of a new option named tune.ssl.max-dh-param-size.
---
doc/configuration.txt | 11 ++
include/common/defaults.h | 5 +
include/types/global.h| 1 +
src/cfgparse.c| 8 ++
src/haproxy.c | 1 +
src/ssl_sock.c| 348 +-
6 files changed, 336 insertions(+), 38 deletions(-)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index 6da8b3e..7406dea 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -497,6 +497,7 @@ The following keywords are supported in the global section :
- tune.ssl.lifetime
- tune.ssl.force-private-cache
- tune.ssl.maxrecord
+ - tune.ssl.max-dh-param-size
- tune.zlib.memlevel
- tune.zlib.windowsize
@@ -1017,6 +1018,16 @@ tune.ssl.maxrecord number
best value. Haproxy will automatically switch to this setting after an idle
stream has been detected (see tune.idletimer above).
+tune.ssl.max-dh-param-size number
+ Sets the maximum size of the Diffie-Hellman parameters used for generating
+ the ephemeral/temporary Diffie-Hellman key in case of DHE key exchange. The
+ final size will try to match the size of the server's RSA (or DSA) key (e.g,
+ a 2048 bits temporary DH key for a 2048 bits RSA key), but will not exceed
+ this maximum value. Default value if 1024. Higher values will increase the
+ CPU load, and values greater than 1024 bits are not supported by Java 7 and
+ earlier clients. This value is not used if static Diffie-Hellman parameters
+ are supplied via the certificate file.
+
tune.zlib.memlevel number
Sets the memLevel parameter in zlib initialization for each session. It
defines how much memory should be allocated for the internal compression
diff --git a/include/common/defaults.h b/include/common/defaults.h
index f765e90..944f3aa 100644
--- a/include/common/defaults.h
+++ b/include/common/defaults.h
@@ -214,4 +214,9 @@
#define SSLCACHESIZE 2
#endif
+/* ssl max dh param size */
+#ifndef SSL_MAX_DH_PARAM
+#define SSL_MAX_DH_PARAM 1024
+#endif
+
#endif /* _COMMON_DEFAULTS_H */
diff --git a/include/types/global.h b/include/types/global.h
index c945f53..8470640 100644
--- a/include/types/global.h
+++ b/include/types/global.h
@@ -132,6 +132,7 @@ struct global {
int sslprivatecache; /* Force to use a private session cache even if nbproc 1 */
unsigned int ssllifetime; /* SSL session lifetime in seconds */
unsigned int ssl_max_record; /* SSL max record size */
+ unsigned int ssl_max_dh_param; /* SSL maximum DH parameter size */
#endif
#ifdef USE_ZLIB
int zlibmemlevel;/* zlib memlevel */
diff --git a/src/cfgparse.c b/src/cfgparse.c
index decdcfd..d2e0191 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -633,6 +633,14 @@ int cfg_parse_global(const char *file, int linenum, char **args, int kwm)
}
global.tune.ssl_max_record = atol(args[1]);
}
+ else if (!strcmp(args[0],
Medical Skills and Training Blog
Hi, My name is Paula Fiske and I run Paramedic to RN a site dedicated to medical education and resources. I created a list of 100 resources for paramedics. My list includes sites on advanced cardiac life support, airway management, burn management, fracture spinal injury management, triage, routine treatment other topics. You can see the list at http://www.paramedictorn.org/essential-skills-guide.html If you do not mind taking a look at my article and if you are interested posting a link on your sites page of http://www.hallandalebeachfl.gov/quicklinks.aspx or any page on your site that you deem relevant to my content? Thank you very much and please let me know if there is anything I can do to have my page be an addition on yours. Paula Fiske PO Box 1531 Houston, TX 77219 To be removed from my mailing list please click here: eduoptout.com
Re: Help with dynamic backend selection
- Original Message - From: Willy Tarreau w...@1wt.eu To: Rajat Chopra rcho...@redhat.com Cc: haproxy haproxy@formilux.org Sent: Saturday, May 10, 2014 12:01:14 AM Subject: Re: Help with dynamic backend selection On Sat, May 10, 2014 at 07:58:25AM +0200, Willy Tarreau wrote: May I ask about the ETA on this? It's too early for me to know, I need to go down deep into the ebtrees first to see if longest match is compatible with strings storage-wise, then I need to study how patterns are built as trees to see how to do that as well. Possibly it's just one or two days of work once I understand everything. OK in the end it was extremely easy :-) Thierry has done an amazing job at making the pattern management very modular, because I just changed the index and lookup to try in a tree first with a different algorithm and that works fine! So we don't care about the compatibility between regular string match and beginning. So that's pushed into git now if you want to give it a try. Thanks a lot Willy. It works as intended. I am trying to spin a real large case and check the performance. Will report. Thanks again. Rajat
