ngx_stream_core_module Add $preread_server_name from http header.HOST

[Ivan]

HTTP/2 Coalescing
Due to the way HTTP/2 clients reuse connections, there can be problems with SNI routing if there is an overlap of server name among the names (Common Name and Subject Alternate Name) in TLS certificate of origin servers.

​https://miro.medium.com/max/3840/1*Fk8pDKD0O760WuDqM4ysyA.png

In the above example, since the TLS certificate used by origin server 10.0.3.2 has wildcard name *.example.com, Web Browser can make a TLS connection with server name b.example.com and use the same connection for HTTP/2 requests to a.example.com. This can cause undefined behavior in web sites and applications.

See: ​https://levelup.gitconnected.com/multiplex-tls-traffic-with-sni-routing-ece1e4e43e56

Many people use a script, but it is difficult to connect it. Difficult compilation required for ARM platform.

Please add a variable $preread_server_name from http headers.

var server_name = '-';

/

• Read the server name from the HTTP stream. *
• @param s
• Stream. */

function read_server_name(s) {

s.on('upload', function (data, flags) {

if (data.length

flags.last) {

s.done();

}

If we can find the Host header.
var n = data.indexOf('\r\nHost: ');
if (n != -1) {

Determine the start of the Host header value and of the next header.
var start_host = n + 8;
var next_header = data.indexOf('\r\n', start_host);

Extract the Host header value.
server_name = data.substr(start_host, next_header - start_host);

Remove the port if given.
var port_start = server_name.indexOf(':');
if (port_start != -1) {

server_name = server_name.substr(0, port_start);

}

}

});

}

function get_server_name(s) {

return server_name;

}

export default {read_server_name, get_server_name}

[Maxim Dounin]

In no particular order:

• There is a response code 421 which can be used to reject request which cannot be handled by a particular server, see ​RFC 7540. If you are using HTTP/2 and SNI-based routing, it is a good idea to configure your backend servers to respond with 421 for requests to names they don't know how to handle.

• Using HTTP header Host is wrong, since the request authority can be provided in a request line instead, see ​RFC 7230.

• Using request headers for connection routing is wrong, since these headers only apply to a particular request, not the whole connection. There can be multiple requests in a connection, and it is not guaranteed that all these requests will be to the same server name. While this might not be common in HTTPS requests from browsers, this certainly can easily happen in case of HTTP and/or in non-browser requests. That is, routing based on the first request headers requires very same precautions as HTTP/2 with SNI-based routing: your backends have to be able to properly handle other names.

Overall, if you are able to decrypt SSL traffic on the nginx host, it is much better idea to use the HTTP module to handle and route requests. Obviously, if you are not able to decrypt SSL traffic, SNI-based routing is the only available approach.

[maxim]

Ticket retargeted after milestone closed

[Maxim Dounin]

Closing this for reasons explained in comment:1.