Re: RSA and ECC not working as expected

[Lukas Tribus]

Hello,

On Tue, 4 Dec 2018 at 20:10, Mildis  wrote:
> Thanks Lukas.
> I knew I saw something like that in the docs since 1.6 but an official blog 
> note had priority on my mind :)
> Maybe amending the post could help others wandering around the web for a 
> solution ...

Agreed, Nenad amended the article this morning.


Lukas

Re: RSA and ECC not working as expected

[Mildis]

> Le 3 déc. 2018 à 23:05, Lukas Tribus  a écrit :
> 
> Hello Mildis,
> 
> 
> On Mon, 3 Dec 2018 at 22:19, Mildis  wrote:
>> 
>> Hi,
>> 
>> I'm using 1.8.14 and I tried to follow 
>> https://www.haproxy.com/blog/serving-ecc-and-rsa-certificates-on-same-ip-with-haproxy/
>>  but all I'm getting in the log is
> 
> I'd recommend to ignore this blog post. Haproxy can do ECC/RSA cert
> switching itself since some time now and I have some doubts about
> req.ssl_ec_ext still actually correctly matching ECC support with
> todays browsers and TLS stacks.
> 
> Read the docs about the crt keyword:
> https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#5.1-crt
> 
> The gist of it is that:
> "crt example.pem" loads "example.pem.ecdsa" as ECC and
> "example.pem.rsa" as RSA certificate, and selects the correct one
> based on client support (by actually using the correct openssl
> features, not payload matching in TCP mode). This makes it easy to
> implement ECC/RSA switching without a dedicated TCP based
> frontend/backend.
> 
Thanks Lukas.
I knew I saw something like that in the docs since 1.6 but an official blog 
note had priority on my mind :)
Maybe amending the post could help others wandering around the web for a 
solution ...

Re: RSA and ECC not working as expected

[Lukas Tribus]

Hello Mildis,


On Mon, 3 Dec 2018 at 22:19, Mildis  wrote:
>
> Hi,
>
> I'm using 1.8.14 and I tried to follow 
> https://www.haproxy.com/blog/serving-ecc-and-rsa-certificates-on-same-ip-with-haproxy/
>  but all I'm getting in the log is

I'd recommend to ignore this blog post. Haproxy can do ECC/RSA cert
switching itself since some time now and I have some doubts about
req.ssl_ec_ext still actually correctly matching ECC support with
todays browsers and TLS stacks.

Read the docs about the crt keyword:
https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#5.1-crt

The gist of it is that:
"crt example.pem" loads "example.pem.ecdsa" as ECC and
"example.pem.rsa" as RSA certificate, and selects the correct one
based on client support (by actually using the correct openssl
features, not payload matching in TCP mode). This makes it easy to
implement ECC/RSA switching without a dedicated TCP based
frontend/backend.



> Why is SC the only answer ?
> Am I missing something ?

If I'd have to take a guess I would say you probably downgrade haproxy
privileges to a non-root user, which is missing the privileges to
access the unix socket that was bound by root. Use the user keyword on
the unix socket bind statement to use a specific user for the unix
socket:

https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#5.1-user


chroot may also be an issue, if you are using it.


Regards,
Lukas

RSA and ECC not working as expected

[Mildis]

Hi,

I'm using 1.8.14 and I tried to follow 
https://www.haproxy.com/blog/serving-ecc-and-rsa-certificates-on-same-ip-with-haproxy/
 

 but all I'm getting in the log is 

ssl-relay ssl-rsa/rsa 1/-1/0 0 SC 1/1/0/0/3 0/0

Currently I do not have an ECC cert so I'm doing tests with an RSA only backend

The relevant configuration is 

frontend ssl-relay
mode tcp
bind ${HAPROXY_VRRP}:443
bind ${HAPROXY_IPV4}:443
bind ${HAPROXY_IPV6}:443
default_backend ssl-rsa

backend ssl-rsa
mode tcp
server rsa unix@/var/run/haproxy/haproxy_ssl_rsa.sock send-proxy-v2

listen all-ssl
mode http
bind unix@/var/run/haproxy/haproxy_ssl_rsa.sock accept-proxy ssl crt 
company.crt 

#capture request  header Host len 50
#capture response header Location len 50
#capture request header User-Agent len 50

http-request set-header X-Forwarded-Proto https
http-request set-header X-Forwarded-Port 443
http-request set-header X-Forwarded-Host %[ssl_fc_sni]


http-response set-header Strict-Transport-Security max-age=31536000;\ 
includeSubDomains

acl secured_cookie res.hdr(Set-Cookie),lower -m sub secure
rspirep ^(Set-Cookie:.*) \1;\ Secure unless secured_cookie


The all-ssl section is where all the routing logic take place based on 
hdr(host) and path_beg combinations to use a specific backend.

Why is SC the only answer ?
Am I missing something ?

Thanks,
Mildis