2

It seems that, when configuring HAProxy for hostname routing on HTTPS connections, it is crucial to include a tcp-request inspect-delay directive to "give HAProxy a chance to look into the connection". Is there a way to get NGINX to to the same, or should I start packing it up and move my whole server to HAProxy?

(For reference, this question comes from my previous misunderstanding expressed here)

EDIT

Michael, in the comments:

he seems to want to "sniff" SNI from the client's handshake attempt without actually terminating the TLS connection, in order to make a lower-layer connection-proxying decision and blindly carry the payload to a subsequent machine for termination of the TLS, because for some reason he doesn't want the TLS certs and keys on the proxy, or for the proxy to do the TLS at all -- just sniff the SNI and make an inward TCP connection using a rule derived from its content.

The rationale is that I need the certificates and keys within the backend applications (some require this for one reason or another), so I have to provide these to them. Having to set them up in the proxy too essentially doubles the maintenance work, and the chance for error. If I could do without maintaining access to the certificates for the proxy, it would make my architecture much easier, and lessen the chances for mistakes.

9
  • 1
    What's your problem, and what are you trying to achieve?
    – Tim
    May 22, 2016 at 19:35
  • 2
    @Tim based on the other question, he seems to want to "sniff" SNI from the client's handshake attempt without actually terminating the TLS connection, in order to make a lower-layer connection-proxying decision and blindly carry the payload to a subsequent machine for termination of the TLS, because for some reason he doesn't want the TLS certs and keys on the proxy, or for the proxy to do the TLS at all -- just sniff the SNI and make an inward TCP connection using a rule derived from its content. The rationale isn't as clear to me as is the desired outcome. May 22, 2016 at 23:42
  • Thanks Michael, that's exactly what I want to achieve. The rationale is that I need the certificates and keys within the backend applications (some require this for one reason or another), so I have to provide these to them. Having to set them up in the proxy too essentially doubles the maintenance work, and the chance for error. If I could do without maintaining access to the certificates for the proxy, it would make my architecture much easier, and lessen the chances for mistakes.
    – Morpheu5
    May 23, 2016 at 9:24
  • 2
    Hello! I got into this question looking for other stuff and I think I have something of your interest. If you still interested :-P. At the bottom of: nginx.org/en/docs/stream/ngx_stream_ssl_module.html you have a variable $ssl_server_name that "returns the server name requested through SNI"
    – lgg
    Jul 5, 2016 at 21:59
  • @Morpheu5 did you end up reaching a solution for this? I have a similar use case
    – Chris
    Feb 21, 2017 at 12:15

1 Answer 1

5

The ngx_stream_ssl_preread_module module is available as of Nginx 1.11.5 and seems to do just this.

It allows access to the SNI server name found in the client's ClientHello message via the $ssl_preread_server_name variable.

This information can be used to route a TCP ("stream") connection to a backend. The documentation for the module provides an example of how to do that.

1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .