Re: Problems with SNI + TLS passthrough

[Ben Whaley]

Thanks, Lukas, this makes sense. I misunderstood that because SNI is not
part of the HTTP session, perhaps it could still be adjusted with TCP mode.

Ultimately I need to do two-way SSL between the client and the service, and
for that I need both of the HAPs in my configuration to do passthrough. So
I’ll have to find a way to route properly without relying on SNI.

Really appreciate your input.

- Ben

On Fri, Jul 8, 2016 at 2:28 PM, Lukas Tribus  wrote:

> Hi Ben,
>
>
>
> Am 08.07.2016 um 18:51 schrieb Ben Whaley:
>
>> Greetings,
>>
>> I have a scenario like this:
>>
>> Client <=> HAP1 <=> HAP2 <=> Java service
>>
>> Both HAPs in this config use TCP mode for TLS passthrough with SNI for
>> routing decisions, as described in this helpful post:
>> http://blog.haproxy.com/2012/04/13/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension/
>>
>
> That's not what you configured though.
>
>
>
>
>> The issue I’m encountering is between HAP1 and HAP2 in the backend
>> configuration of HAP1. Specifically, I have the backend configuration on
>> HAP1 like this:
>>
>> backend mybackend
>>mode tcp
>>server myserver myhost.example.com:443 
>> ssl verify none sni str(myhost.example.com )
>>
>
> When you use TLS passthrough, you DO NOT configure the ssl keyword, and
> you DO NOT configure anything related to SSL, like sni. The reason is that
> TLS passthrough by definition does not modify the TCP payload, it just
> transparently relays TCP from the frontend to the backend. You can still
> take routing decisions based on SNI though (like the blog post you
> mentioned does), but you do not intercept SSL.
>
> In fact, you don't need to build haproxy with SSL support for this
> configuration, because SNI matching doesn't need openssl support.
>
>
>
> When I try an “openssl s_client” command to check the SSL connection, the
>> result is “SSL23_GET_SERVER_HELLO:unknown protocol”. Via packet traces on
>> HAP2 I can see that the correct SNI is set (myhost.example.com <
>> http://myhost.example.com> appears), but the SSL handshake fails
>> inexplicably.
>>
>
> Of course, because your configuration basically boils down to encrypting
> the already encrypted SSL traffic once again with SSL. That doesn't make
> any sense.
>
>
>
>
>> If I remove “ssl verify none” from the HAP1 configuration, I can see in
>> the packet traces that SNI is not being set by HAProxy, even though the
>> “sni str()” is still in the config.
>>
>
> Correct. You can only set SNI if you are terminating SSL. You cannot SNI
> on arbitrary TCP sessions.
>
>
>
> Furthermore, if I then add “-servername myhost.example.com <
>> http://myhost.example.com>” to the s_client command to explicitly set
>> the SNI value, the handshake completes successfully. But this doesn’t work
>> as a solution because the name that the client knows is different than the
>> internal name of the service. (e.g. the client knows “
>> somehost.example.com ” but internally that
>> service is addressed as “myhost.example.com ”)
>>
>
> So your real use case is that your client sends a SNI value (XY) and you
> need to rewrite that SNI value to something else before it hits the
> backend. You cannot use TLS passthrough for this then.
>
> You'll have to terminate SSL on the frontend and work from there
> (installing certificates on the haproxy frontend).
>
>
>
>
>> Is there a problem with using “ssl” and “sni str()” together in a config?
>> Why does HAP set the SNI value if “ssl” is in the config, but does NOT set
>> the SNI value if ssl is not in the config?
>>
>
> SNI is an SSL parameter relevant only if SSL is actually used. If you only
> pass SSL through the proxy configured transparently (no terminating SSL),
> then you cannot set any SNI values.
>
>
>
> Regards,
>
> Lukas
>
>

Re: Problems with SNI + TLS passthrough

[Lukas Tribus]

Hi Ben,



Am 08.07.2016 um 18:51 schrieb Ben Whaley:

Greetings,

I have a scenario like this:

Client <=> HAP1 <=> HAP2 <=> Java service

Both HAPs in this config use TCP mode for TLS passthrough with SNI for 
routing decisions, as described in this helpful post: 
http://blog.haproxy.com/2012/04/13/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension/


That's not what you configured though.





The issue I’m encountering is between HAP1 and HAP2 in the backend 
configuration of HAP1. Specifically, I have the backend configuration 
on HAP1 like this:


backend mybackend
   mode tcp
   server myserver myhost.example.com:443 
 ssl verify none sni 
str(myhost.example.com )


When you use TLS passthrough, you DO NOT configure the ssl keyword, and 
you DO NOT configure anything related to SSL, like sni. The reason is 
that TLS passthrough by definition does not modify the TCP payload, it 
just transparently relays TCP from the frontend to the backend. You can 
still take routing decisions based on SNI though (like the blog post you 
mentioned does), but you do not intercept SSL.


In fact, you don't need to build haproxy with SSL support for this 
configuration, because SNI matching doesn't need openssl support.




When I try an “openssl s_client” command to check the SSL connection, 
the result is “SSL23_GET_SERVER_HELLO:unknown protocol”. Via packet 
traces on HAP2 I can see that the correct SNI is set 
(myhost.example.com  appears), but the SSL 
handshake fails inexplicably.


Of course, because your configuration basically boils down to encrypting 
the already encrypted SSL traffic once again with SSL. That doesn't make 
any sense.






If I remove “ssl verify none” from the HAP1 configuration, I can see 
in the packet traces that SNI is not being set by HAProxy, even though 
the “sni str()” is still in the config.


Correct. You can only set SNI if you are terminating SSL. You cannot SNI 
on arbitrary TCP sessions.




Furthermore, if I then add “-servername myhost.example.com 
” to the s_client command to explicitly set 
the SNI value, the handshake completes successfully. But this doesn’t 
work as a solution because the name that the client knows is different 
than the internal name of the service. (e.g. the client knows 
“somehost.example.com ” but internally 
that service is addressed as “myhost.example.com 
”)


So your real use case is that your client sends a SNI value (XY) and you 
need to rewrite that SNI value to something else before it hits the 
backend. You cannot use TLS passthrough for this then.


You'll have to terminate SSL on the frontend and work from there 
(installing certificates on the haproxy frontend).






Is there a problem with using “ssl” and “sni str()” together in a 
config? Why does HAP set the SNI value if “ssl” is in the config, but 
does NOT set the SNI value if ssl is not in the config?


SNI is an SSL parameter relevant only if SSL is actually used. If you 
only pass SSL through the proxy configured transparently (no terminating 
SSL), then you cannot set any SNI values.




Regards,

Lukas

Problems with SNI + TLS passthrough

[Ben Whaley]

Greetings,

I have a scenario like this:

Client <=> HAP1 <=> HAP2 <=> Java service

Both HAPs in this config use TCP mode for TLS passthrough with SNI for
routing decisions, as described in this helpful post:
http://blog.haproxy.com/2012/04/13/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension/

The issue I’m encountering is between HAP1 and HAP2 in the backend
configuration of HAP1. Specifically, I have the backend configuration on
HAP1 like this:

backend mybackend
   mode tcp
   server myserver myhost.example.com:443 ssl verify none sni str(
myhost.example.com)

When I try an “openssl s_client” command to check the SSL connection, the
result is “SSL23_GET_SERVER_HELLO:unknown protocol”. Via packet traces on
HAP2 I can see that the correct SNI is set (myhost.example.com appears),
but the SSL handshake fails inexplicably.

If I remove “ssl verify none” from the HAP1 configuration, I can see in the
packet traces that SNI is not being set by HAProxy, even though the “sni
str()” is still in the config. Furthermore, if I then add “-servername
myhost.example.com” to the s_client command to explicitly set the SNI
value, the handshake completes successfully. But this doesn’t work as a
solution because the name that the client knows is different than the
internal name of the service. (e.g. the client knows “somehost.example.com”
but internally that service is addressed as “myhost.example.com”)

Is there a problem with using “ssl” and “sni str()” together in a config?
Why does HAP set the SNI value if “ssl” is in the config, but does NOT set
the SNI value if ssl is not in the config?

Thanks in advance for any help & insights.

- Ben

[no subject]

[june]

DearPurchasemanager,   =p;  
4WST64ledfilamentbulbwiththefollowingfeatures:=   =p; 
1)ImportedEpistarCOB,8*38mmfilament   =p; 
2)luminousefficiency:70-120lm/w   =p; 3)differentshapefilamentoption
   =p; 4)fillwithnoblegasandreduceluminousdecay   =p; 
5)Linearconstantcurrentdimming   =p; 6)CRI80  
B.RGDSJunewww.sunriseleds.com