"No server name in ClientHello" errors

[extrawurst]

I am seeing regular errors like this in my environment even though i am only using ACME for SSL and that works perfectly fine.

rpxy-1         | 2024-10-22T03:37:24.816615Z ERROR No server name in ClientHello
rpxy-1         | 2024-10-22T03:37:24.817029Z ERROR No server name in ClientHello
rpxy-1         | 2024-10-22T03:37:24.818541Z ERROR Failed to build TLS acceptor: peer is incompatible: SignatureAlgorithmsExtensionRequired
rpxy-1         | 2024-10-22T03:37:24.818814Z ERROR Failed to build TLS acceptor: received corrupt message of type MissingData("ClientHelloPayload")
rpxy-1         | 2024-10-22T03:37:24.818886Z ERROR No server name in ClientHello
rpxy-1         | 2024-10-22T03:37:24.871406Z ERROR Failed to build TLS acceptor: peer is incompatible: SignatureAlgorithmsExtensionRequired
rpxy-1         | 2024-10-22T03:37:24.879289Z ERROR Failed to build TLS acceptor: received corrupt message of type InvalidContentType

Any ideas what this is caused by, why it errors even though everything seems to work or how to prevent these errors?

[Gamerboy59]

I'm not seeing this on my instance but to me this looks like somebody is trying to connect with broken protocol support (on client side). Is it within Docker or standalone?

[extrawurst]

this is inside docker. there is no request logged before or after that could be related to that 🤔

[junkurihara]

Hi, as @Gamerboy59 mentioned, it seems that a client sent a TLS ClientHello message which is unacceptable to rpxy.

Technically, it is NOT malicious nor invalid. The ServerNameIndication (SNI) is an extension of TLS ClientHello message. It is currently supported by most of TLS clients and servers, and usually used by default for TLS connection based on domain names. So, the use of SNI is a de-facto standard.

But SNI is not enforced to be used, and very legacy clients do not support SNI (maybe ones early 2000s). Also, if a TLS connection is initiated not with a domain name but with an IP address, ClientHello does not contain SNI.

Here recall that certificates are issued to Common Names, i.e., domain names. Also recall that a certificate is presented in the response (ServerHello) to the given ClientHello. So, the SNI is actually mandatory since the server must chose the certificate matched to the requested service, i.e., the domain name.

In rpxy, We designed rpxy by considering the above principle. Specifically, TLS ClientHello with no SNI is rejected since it cannot be routed to any backend app.

[extrawurst]

@junkurihara thanks for the explanation. I had no idea ClientHello is part of the TLS standard and handshake. would be great if it could log out a bit more info about the request that in effect will be rejected then because of this error

[xkr47]

While I think the principle is solid especially given rpxy's effortless multi-domain support, I also feel a bit like "it could be supported". @extrawurst do you have any options to make requests so that they include SNI?

I'm just thinking, if the server has just one certificate installed, maybe requests without SNI could be allowed?

[Gamerboy59]

@xkr47 Do you think of something like a wildcard certificate which replies to all requests (even ip only requests where tls is technically impossible with the currently implementes mechanism)? It might be possible but that's not how tls works and is implemented anywhere so it would require huge customization effort. Updating the client to support a recent (and even ten year old) version of tls protocol would be more helpful.

[xkr47]

@Gamerboy59 Yeah I know, it does not make much sense from a browser perspective. Have just been working with enough old non-browser clients to know upgrading old existing code can be a pain. But yeah, I kindof agree that it is better that rpxy has this security-first approach, it gives most users a much better experience and comfort.