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.

  • 1
    What's your problem, and what are you trying to achieve? – Tim May 22 '16 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. – Michael - sqlbot May 22 '16 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 '16 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 '16 at 21:59
  • @Morpheu5 did you end up reaching a solution for this? I have a similar use case – Chris Feb 21 '17 at 12:15
4

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.