Re: 1.5 latest segfault trying to negate acl
Hi Thank you, I can confirm this fixes the issue for me Thanks, Neil On 9 April 2014 12:35, Willy Tarreau w...@1wt.eu wrote: Hi guys, sorry it took that long to take a look at it. I've just pushed the patch, it's available here : http://git.1wt.eu/web?p=haproxy.git;a=commitdiff_plain;h=6a0b6bd648592e73f42fb8e7341bf984d26ba8dc The bug happens when the sc0_get_gpc0() statement is applied to an explicit table while sc0 is not yet tracked. The implicit table already contained the check for the existence of the tracker, but not the code doing the lookup in an alternate table. Thanks for reporting this! Willy
Re: redirecting based on Accept-Language
On Wed, Apr 09, 2014 at 01:50:28PM -0700, Marc Fournier wrote:
nginx has a module for doing this
(http://wiki.nginx.org/AcceptLanguageModule) that appears to work on a ?first
match? basis:
==
set_from_accept_language $lang en ja pl;
==
so site supports en/ja/pl ? $lang variable set based on the first
Accept-Languages value that matches that list ? if no match, default to the
first one (en) ?
This might be more then could be done in the config file though, if you want
to honor the q= prioritizer, but that is just a method of grouping, from what
I?ve read in RFC2616 ? your examples above, for instance, would translate as:
You *must* honnor q= because q=0 means that you won't accept the
associated value. That's what haproxy does with accept-encoding for
example.
zh-TW,zh;q=0.8,en-US;q=0.6,en;q=0.4,ar
zh-TW;q=1,zh;q=0.8,en-US;q=0.6,en;q=0.4,ar;q=1
which would then sort out to:
zh-TW,ar,zh,en-US,en
Of course, that assumes I?m reading how it works from RFC2616 correctly ?
without any q= value, everything defaults to 1 and is parsed ?in hte order
presented? ? the q= modifier provides a sort order by weighting everything
from ?most desired? to ?least desired? ?
Hrmmm ? a bit messy, but what I could probably do is use nginx in front of
haproxy to set a cookie that I could read in haproxy and redirect accordingly
? which I may need to do anyway, to support https:// ?
And yes, I could use nginx to do the load balancing too, but I?m using
haproxy?s stats interface for load monitoring / alerting ? I?d rather avoid
using nginx if I can, since it just adds one more layer ...
Matching a series of q-values is very easy, the difficulty is in defining
how we'd like the accepted values to be configured in order to apply the
match.
Thierry proposed me something like a sample fetch which would take a
semi-colon delimited list of languages. I don't know if that's something
acceptable, as I still find that it's not obvious to configure, but it
would permit every possible combination. For example you would have :
use_backend en if {
req.fhdr(accept-language),q-preferred(zh-TW;ar;zh;en-US;en) en en-US }
use_backend zh if {
req.fhdr(accept-language),q-preferred(zh-TW;ar;zh;en-US;en) zh zh-TW }
use_backend ar if {
req.fhdr(accept-language),q-preferred(zh-TW;ar;zh;en-US;en) ar }
So that would extract the complete accept-language header, apply the filtering
from the supported list and pick the preferred one, then match it against a set
of strings.
The benefit of applying it as a converter is that it will be usable as
well for accept, accept-charset and accept-encoding.
If that's something you think is acceptable in terms of configuration, I
believe it's really not complicated to do given that we already have the
code to pick a preferred value in a q-list.
Willy
Re: Query regarding extracting ssl hello sni.
Hi,
On Thu, Apr 10, 2014 at 10:33:38AM +0530, Pravin Tatti wrote:
Hi,
The function smp_fetch_ssl_hello_sni() only supports record layer version
and client hello version greater than or equal to 3.1. But as in the
RFC5246 in appendix E says that TLS versions 1.0, 1.1, and 1.2, and SSL
3.0 are very similar and also if we check the last 2 paras as mentioned
below
Earlier versions of the TLS specification were not fully clear on what
the record layer version number (TLSPlaintext.version) should contain when
sending ClientHello (i.e., before it is known which version of the protocol
will be employed). Thus, TLS servers compliant with this specification MUST
accept any value {03,XX} as the record layer version number for
ClientHello.
TLS clients that wish to negotiate with older servers MAY send any value
{03,XX} as the record layer version number. Typical values would be
{03,00}, the lowest version number supported by the client, and the value
of ClientHello.client_version. No single value will guarantee
interoperability with all old servers, but this is a complex topic beyond
the scope of this document.
This indicates that the tls record version might be SSL 3.0 and the client
hello might be TLS version 1.0, 1.1 or 1.2.
Do we need to consider this case while parsing in smp_fetch_ssl_hello_sni()
or is there any other specific reason for it.
I noticed such kind of issue when application is using gnutls instead of
openssl.
ie., the record layer version is SSL 3.0 and client hello is 3.3.
Well, there is no particular reason for being limited to a certain set of
versions, however I think we did it this way because SNI started to be used
long after any client totally stopped supporting SSLv3, so it did not appear
that there was any intersection between SSLv3 and SNI. But if there is, sure,
maybe propose a patch!
Thanks,
Willy
Re: Query regarding extracting ssl hello sni.
I think you still didn't understood the problem. There are two versions in
SSL one is record layer hello version and the client hello version. Any
application that support TLS versions 1.0, 1.1, 1.3 or SSLv3 (client hello
version) may contain SSL 3.0 as the record layer version number and the
once the negotiation is done the record layer version is updated.
The problem is not with SSLv3 alone the problem is with all the TLS
versions 1.0, 1.1, 1.3 or SSLv3 who has the record layer version as SSLv3
for client hello packet.
The problem is the application using gnutls instead of openssl has record
layer hello version set to SSL 3.0 for client hello handshake and the
client hello version to TLSv2 (max TLS version supported by client).
What i suggest is fetching of SNI is still valid even if the record layer
version is 3.0 and the actual client hello version is any of the TLS
versions including SSLv3.
On Thu, Apr 10, 2014 at 2:34 PM, Willy Tarreau w...@1wt.eu wrote:
[image: Boxbe] https://www.boxbe.com/overview Willy Tarreau (w...@1wt.eu)
is not on your Guest
Listhttps://www.boxbe.com/approved-list?tc_serial=16879868868tc_rand=1178275786utm_source=stfutm_medium=emailutm_campaign=ANNO_MWTPutm_content=001token=%2Fwy11T7R1QVKnkycPjMukAJgXwKDuCjUkkpoPo3fnUbD27SXBkGi8peGgEmh%2FReckey=pl7vWF6XC3JfowFZA%2F0CL7u6ZiLZzX%2BJ6UJhky1jiZM%3D|
Approve
senderhttps://www.boxbe.com/anno?tc_serial=16879868868tc_rand=1178275786utm_source=stfutm_medium=emailutm_campaign=ANNO_MWTPutm_content=001token=%2Fwy11T7R1QVKnkycPjMukAJgXwKDuCjUkkpoPo3fnUbD27SXBkGi8peGgEmh%2FReckey=pl7vWF6XC3JfowFZA%2F0CL7u6ZiLZzX%2BJ6UJhky1jiZM%3D|
Approve
domainhttps://www.boxbe.com/anno?tc_serial=16879868868tc_rand=1178275786utm_source=stfutm_medium=emailutm_campaign=ANNO_MWTPutm_content=001domtoken=%2Fwy11T7R1QVKnkycPjMukAJgXwKDuCjUkkpoPo3fnUbD27SXBkGi8peGgEmh%2FReckey=pl7vWF6XC3JfowFZA%2F0CL7u6ZiLZzX%2BJ6UJhky1jiZM%3D
Hi,
On Thu, Apr 10, 2014 at 10:33:38AM +0530, Pravin Tatti wrote:
Hi,
The function smp_fetch_ssl_hello_sni() only supports record layer version
and client hello version greater than or equal to 3.1. But as in the
RFC5246 in appendix E says that TLS versions 1.0, 1.1, and 1.2, and SSL
3.0 are very similar and also if we check the last 2 paras as mentioned
below
Earlier versions of the TLS specification were not fully clear on what
the record layer version number (TLSPlaintext.version) should contain
when
sending ClientHello (i.e., before it is known which version of the
protocol
will be employed). Thus, TLS servers compliant with this specification
MUST
accept any value {03,XX} as the record layer version number for
ClientHello.
TLS clients that wish to negotiate with older servers MAY send any value
{03,XX} as the record layer version number. Typical values would be
{03,00}, the lowest version number supported by the client, and the value
of ClientHello.client_version. No single value will guarantee
interoperability with all old servers, but this is a complex topic beyond
the scope of this document.
This indicates that the tls record version might be SSL 3.0 and the
client
hello might be TLS version 1.0, 1.1 or 1.2.
Do we need to consider this case while parsing in
smp_fetch_ssl_hello_sni()
or is there any other specific reason for it.
I noticed such kind of issue when application is using gnutls instead of
openssl.
ie., the record layer version is SSL 3.0 and client hello is 3.3.
Well, there is no particular reason for being limited to a certain set of
versions, however I think we did it this way because SNI started to be used
long after any client totally stopped supporting SSLv3, so it did not
appear
that there was any intersection between SSLv3 and SNI. But if there is,
sure,
maybe propose a patch!
Thanks,
Willy
Re: Query regarding extracting ssl hello sni.
On Thu, Apr 10, 2014 at 06:30:26PM +0530, Pravin Tatti wrote: I think you still didn't understood the problem. There are two versions in SSL one is record layer hello version and the client hello version. Any application that support TLS versions 1.0, 1.1, 1.3 or SSLv3 (client hello version) may contain SSL 3.0 as the record layer version number and the once the negotiation is done the record layer version is updated. The problem is not with SSLv3 alone the problem is with all the TLS versions 1.0, 1.1, 1.3 or SSLv3 who has the record layer version as SSLv3 for client hello packet. OK thanks for clarifying. The problem is the application using gnutls instead of openssl has record layer hello version set to SSL 3.0 for client hello handshake and the client hello version to TLSv2 (max TLS version supported by client). What i suggest is fetching of SNI is still valid even if the record layer version is 3.0 and the actual client hello version is any of the TLS versions including SSLv3. Fine, could you send a patch to do that then ? Willy
RE: Query regarding extracting ssl hello sni.
Date: Thu, 10 Apr 2014 15:22:43 +0200 From: w...@1wt.eu To: tattiprav...@gmail.com CC: haproxy@formilux.org Subject: Re: Query regarding extracting ssl hello sni. On Thu, Apr 10, 2014 at 06:30:26PM +0530, Pravin Tatti wrote: I think you still didn't understood the problem. There are two versions in SSL one is record layer hello version and the client hello version. Any application that support TLS versions 1.0, 1.1, 1.3 or SSLv3 (client hello version) may contain SSL 3.0 as the record layer version number and the once the negotiation is done the record layer version is updated. The problem is not with SSLv3 alone the problem is with all the TLS versions 1.0, 1.1, 1.3 or SSLv3 who has the record layer version as SSLv3 for client hello packet. OK thanks for clarifying. Basically we just need to relax the record layer check to SSLv3 - and leave the clienthello check as is, right? Does the attached diff do the job for you correctly, Pravin? Regards, Lukas sslv3-record-layer-sni.diff Description: Binary data
AW: AW: Weird timing values in http log
Hi Lukas, I can have a look at it. Meta-Question: Which source has to be taken to make a patch against? Best regards Andreas Mock -Ursprüngliche Nachricht- Von: Lukas Tribus [mailto:luky...@hotmail.com] Gesendet: Dienstag, 8. April 2014 14:53 An: Andreas Mock; Cyril Bonté Cc: Haproxy Betreff: RE: AW: Weird timing values in http log Hi Cyril, thank you very much for the fast answer and the pointer into the documentation. Now I have to think about whether I'm happy with it... ;-) In this case I suggest adding a cross reference to the paragraph citied by me, so that there are configuration circumstances where a high request time does NOT mean a network problem. Could you send a doc patch for that? Regards, Lukas
RE: AW: AW: Weird timing values in http log
Hi, I can have a look at it. Meta-Question: Which source has to be taken to make a patch against? Current git master. Clone the repository with: git clone http://master.formilux.org/git/people/willy/haproxy.git/ README contains some hints howto contribute. Regards, Lukas
haproxy mis-reporting layer 4 checks
I've brought up this bug before (http://marc.info/?l=haproxym=139312718801838), but it seems to not have gotten any attention, so I'm raising it again. There is an issue with haproxy mis-reporting layer 4 checks. There are 2, likely related, issues. 1) When haproxy first starts up, it will report the server as UP 1/3 for however long the check interval is set to. If the interval is 30 seconds, it will say UP 1/3 for 30 seconds. 2) Haproxy is adding the check interval time to the time of the check itself. For example, if I have a check interval of 30 seconds, the statistics output reports a check completion time of 30001ms. Attached is a simple configuration that can be used to demonstrate this issue. Launch haproxy, and then go to http://localhost/haproxy/stats -Patrick global log 127.0.0.1 local0 defaults log global modehttp option httplog timeout connect 5000 timeout client 6 timeout server 17 stats enable stats uri /haproxy/stats frontend f1 bind 0.0.0.0:9000 default_backend b1 backend b1 server s1 localhost:9001 check inter 1 frontend f2 bind 0.0.0.0:9001
RE: Query regarding extracting ssl hello sni.
Hi, Basically we just need to relax the record layer check to SSLv3 - and leave the clienthello check as is, right? Does the attached diff do the job for you correctly, Pravin? I have reproduced the issue with gnutls and can confirm that the patch fixes the problem. The function now requires only SSLv3 or later in the record layer, but still requires at least TLSv1.0 in the client hello. I don't think any SNI capable client announces SSLv2 in the record layer or worse. I will submit the patch formally. Regards, Lukas
[PATCH] BUG/MINOR: acl: req_ssl_sni fails with SSLv3 record version
SNI is a TLS extension and requires at least TLSv1.0 or later, however the version in the record layer may be SSLv3, not necessarily TLSv1.0. GnuTLS for example does this. Relax the record layer version check in smp_fetch_ssl_hello_sni() to allow fetching SNI values from clients indicating SSLv3 in the record layer (maintaining the TLSv1.0+ check in the actual handshake version). This was reported and analyzed by Pravin Tatti. --- src/payload.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/payload.c b/src/payload.c index b806e08..4057f6f 100644 --- a/src/payload.c +++ b/src/payload.c @@ -285,10 +285,10 @@ smp_fetch_ssl_hello_sni(struct proxy *px, struct session *s, void *l7, unsigned if (*data != 0x16) goto not_ssl_hello; - /* Check for TLSv1 or later (SSL version = 3.1) */ + /* Check for SSLv3 or later (SSL version = 3.0) in the record layer*/ if (bleft 3) goto too_short; - if (data[1] 0x03 || data[2] 0x01) + if (data[1] 0x03) goto not_ssl_hello; if (bleft 5) -- 1.7.9.5
Big Data - IBM Users
Hi, Would you be interested in IBM - End Users, Partners, Channel Partners, Resellers and Competitors accounts? Other Big Data users: HP, Oracle, AWS, Cisco, Intel, Microsoft and more. Industry: Public Sectors, Telecoms, Financial Services, Healthcare Pharma, Marketing, PR Media, Retails, Manufacturing and more. Few other categories List: Storage, Web Applications, Big Data and Analytics, Disaster Recovery etc. Titles: *http://www.hdiconference.com/overview/attend/CIO-conference CIOs, http://www.hdiconference.com/overview/attend/CTO-conference CTOs, COO * CVDM Marketing * Senior-level VPs and directors * Decision Makers: IT Managers, Directors, and Business Leaders * Developers and Engineers, System Administrators, and Architects P.S. If you have any other technology user's data requirement apart from those mentioned above, please send your target specifications so that I can get back to you with additional information regarding the counts, quality, samples etc. for your review. Let me know if you need more information. Kind Regards, Nick Thompson Business Development Append | E-mail Hygiene | Fax Append | Phone Append | Mailing Address Append |Custom Lists | Specialty Lists | Pre-packaged Lists | Telemarketing Lists |List Management | E-mail Marketing | Email Campaign--- To unsubscribe please reply to this email with remove in the subject line and you will not receive further emails.
Re: [PATCH] BUG/MINOR: acl: req_ssl_sni fails with SSLv3 record version
On Thu, Apr 10, 2014 at 09:36:22PM +0200, Lukas Tribus wrote: SNI is a TLS extension and requires at least TLSv1.0 or later, however the version in the record layer may be SSLv3, not necessarily TLSv1.0. GnuTLS for example does this. Relax the record layer version check in smp_fetch_ssl_hello_sni() to allow fetching SNI values from clients indicating SSLv3 in the record layer (maintaining the TLSv1.0+ check in the actual handshake version). This was reported and analyzed by Pravin Tatti. Applied, thanks Lukas! willy
Animez votre site avec une vidéo
Your email client cannot read this email. To view it online, please go here: http://semkma01.mlsense.com/display.php?M=739032C=3ed8f04f28b2901c80609735fcc011b6S=7L=8N=3 To stop receiving these emails:http://semkma01.mlsense.com/unsubscribe.php?M=739032C=3ed8f04f28b2901c80609735fcc011b6L=8N=7
Re: Query regarding extracting ssl hello sni.
I would suggest that it will not harm even if you relax the check for client hello too as the old client can using SSL 3.0 is still supported and its according to RFC and also note that the max supported TLS version is 3.3. I would suggest the below mentioned changes. 288c288 /* Check for TLSv1 or later (SSL version = 3.1) */ --- /* Check for SSLv3 or later (SSL version = 3.0) */ 291c291 if (data[1] 0x03 || data[2] 0x01) --- if (data[1] 0x03 || data[2] 0x03) 322c322 if (data[0] 0x03 || data[1] 0x01) /* TLSv1 minimum */ --- if (data[0] 0x03 || data[1] 0x03) /* SSLv3 minimum TLSv1.2 maximum */ On Fri, Apr 11, 2014 at 12:43 AM, Lukas Tribus luky...@hotmail.com wrote: Hi, Basically we just need to relax the record layer check to SSLv3 - and leave the clienthello check as is, right? Does the attached diff do the job for you correctly, Pravin? I have reproduced the issue with gnutls and can confirm that the patch fixes the problem. The function now requires only SSLv3 or later in the record layer, but still requires at least TLSv1.0 in the client hello. I don't think any SNI capable client announces SSLv2 in the record layer or worse. I will submit the patch formally. Regards, Lukas
