TLS error IP vs. host name.

[ams-tschoening]

I use some Linux/Enigma 2-based TV-receiver which provides shellinabox as part of some web interface to configure and use the receiver. Recently I discovered that shellinabox is properly accessible using the IP of the receiver, but not it's host name, neither a short one like with https://vusolo4k:4200 nor a full DNS name like https://vusolo4k.fritz.box:4200. Other users of my receiver have the same problem, only IPs are working.

Trying to access using the host name results in TLS errors during the handshake already, according Wireshark it's directly after the client hello of my browser. The actual error the browser presents heavily depends on the browser itself of course, but one example is ERR_SSL_VERSION_OR_CIPHER_MISMATCH. This problem has nothing to do with untrusted certificates, the browser warns about those only in case of a successful connection, which only happens using the IP.

For web servers I would have a look at different configurations regarding things like SNI etc., but the docs say that shellinabox doesn't use any configuration files and I can't find anything suitable on the receiver as well. Additionally, the host name resolves to the one and only working IP as well.

So, do you have any idea why host name and IP are handled differently? Thanks!

[ams-tschoening]

The issue is found, the receiver only provides certificate.pem, which is not used in case of accessing the device using the host name and a SNI capable browser. After creating a symlink of that file to certificate-vusolo4k.pem accessing the device using the host name works as well.

The docs say the following:

If no SNI handshake took place, it falls back on using the certificate in the certificate.pem file.

That read to me like even with SNI, certificate.pem is used as fallback, which doesn't seem to be the case at least in the version of shellinabox of my device. Is this intended behaviour? Wouldn't it make sense to use certificate.pem as fallback always? Of course my device could easily provide that symlink, but that might make shellinabox itself a bit more compatible.

I'll leave the issue open for discussion of the fallback-approach, so if you think otherwise, please leave a note and close yourself. Thanks!