Closed oacsed closed 7 years ago
@oacsed from working with devices I had learned that most of the time there’s something weird coming from device’s SSL stack. I’d recommend collecting traces with wireshark and analyzing them for validity. If anything, having SNI extension would actually hurt as SslStream (used internally in TlsHandler) does not support SNI.
closing due to lack of activity
Hi,
We're currently trying to connect a physical device to a DotNetty TCP-based server we developed. The connection is achieved through a secured channel (TLS 1.2).
While everything works fine when connecting simulated devices (or even CURL-initiated requests), our physical devices can't connect. We've narrowed down the issue to the absence of the Server Name Indication (SNI) extension within the Client Hello message coming from our devices. From our understanding (see https://tools.ietf.org/html/rfc4366#section-3.1), this particular TLS extension is not mandatory ("clients MAY include an extension"...), so a TCP server should accept both messages with and within this extension.
How could I parameterize my DotNetty server to accept such TCP connections?
For reference, here's the relevant DotNetty server code we're using to reproduce the issue:
Thanks for the help, Regards