Hi Julien,
> Still, I would like to take a look at the patch and get it fixed properly.
Your patch works for me if I only apply the one-line change at
"version = (data[9] << 16) + data[10];"
Can you confirm that this works for you as well and resubmit it
for inclusion?
Thanks,
Lukas
On Fri, Oct 09, 2015 at 05:05:12AM -0400, Julien Vehent wrote:
> On 2015-10-08 18:24, Lukas Tribus wrote:
> >Are you sure your TLSv1.2 client is actually sending
> >jve.linuxwall.info as SNI value? I suggest to remove the
> >SNI if statement while testing the TLS ACL.
>
> Argh... I can't count
>> jve.linuxwall.info as SNI value? I suggest to remove the
>> SNI if statement while testing the TLS ACL.
>
> Argh... I can't count the number of times forgetting -servername in
> openssl s_client got me looking for a bug. This one included.
>
> "acl tls12 req.payload(9,2) -m bin 0303" works as
On 2015-10-10 02:02, Willy Tarreau wrote:
On Fri, Oct 09, 2015 at 05:05:12AM -0400, Julien Vehent wrote:
On 2015-10-08 18:24, Lukas Tribus wrote:
>Are you sure your TLSv1.2 client is actually sending
>jve.linuxwall.info as SNI value? I suggest to remove the
>SNI if statement while testing the
On 2015-10-08 18:24, Lukas Tribus wrote:
Are you sure your TLSv1.2 client is actually sending
jve.linuxwall.info as SNI value? I suggest to remove the
SNI if statement while testing the TLS ACL.
Argh... I can't count the number of times forgetting -servername in
openssl s_client got me looking
On Fri, Oct 09, 2015 at 12:24:11AM +0200, Lukas Tribus wrote:
> > frontend https-in
> > bind 0.0.0.0:443
> > mode tcp
> > tcp-request inspect-delay 5s
> > tcp-request content accept if { req_ssl_hello_type 1 }
> >
> > acl sni_jve req.ssl_sni -i jve.linuxwall.info
> > acl tls12 req.payload(9,2) -m
On 2015-10-05 17:03, Lukas Tribus wrote:
I would argue that HAProxy is doing the wrong thing here: the
req_ssl_ver variable
should return the handshake version, not the record layer version.
Agreed.
We really should ignore the record layer and use the client hello
version instead
> Attached is a patch that should work but doesn't. (bare with me, I'm in
> unknown codebase territory here).
>
> I also tried to match directly using req.payload, and I can't get the
> ACL to match:
> acl tls12 req.payload(9,2) -m bin 0303
"req.payload(9,2) -m bin 0303" is imho correct, this
On 2015-10-08 11:28, Lukas Tribus wrote:
Attached is a patch that should work but doesn't. (bare with me, I'm
in
unknown codebase territory here).
I also tried to match directly using req.payload, and I can't get the
ACL to match:
acl tls12 req.payload(9,2) -m bin 0303
"req.payload(9,2) -m
On 2015-10-08 12:05, Julien Vehent wrote:
acl tls12 req.payload(9,2) -m bin 0301
Oops... typo while copy/pasting my conf. The right config is below:
frontend https-in
bind 0.0.0.0:443
mode tcp
tcp-request inspect-delay 5s
tcp-request content accept if {
> frontend https-in
> bind 0.0.0.0:443
> mode tcp
> tcp-request inspect-delay 5s
> tcp-request content accept if { req_ssl_hello_type 1 }
>
> acl sni_jve req.ssl_sni -i jve.linuxwall.info
> acl tls12 req.payload(9,2) -m bin 0303
> acl sslv3 req_ssl_ver 3.0
>
> use_backend jve_https if sni_jve
Hi Julien,
>> Maybe you can also try with "curl --tlsv1.2" which should use a 3.3
>> version.
>
> That's a very interesting details. Indeed curl sets the HELLO version to
> 0x0303
> whereas OpenSSL uses 0x0301. Interestingly, both Firefox and Chrome also
> use 0x0301
> in the version of the
Hi,
Le 04/10/2015 17:16, Julien Vehent a écrit :
Hi everyone,
I'm working on a configuration that routes to a different backend based
on the TLS version, using:
acl modern_tls req_ssl_ver 3.3
However, it appears that the acl never returns true. I'm testing with:
$ openssl s_client
On 2015-10-04 13:19, Cyril Bonté wrote:
Hi,
Le 04/10/2015 17:16, Julien Vehent a écrit :
Hi everyone,
I'm working on a configuration that routes to a different backend
based
on the TLS version, using:
acl modern_tls req_ssl_ver 3.3
However, it appears that the acl never returns true.
14 matches
Mail list logo
