vesvault/snif

SNIF ~ e2e TLS trust for IoT

snif's Issues

Hide a plaintext SNI in snifd/srv.c

snifd/srv.c, the listener for connections from the server processes on the end IoT devices,
relays the TLS traffic for the matched socket without any modifications, including the client TLS hello with a plaintext SNI record.
However, the server process on the end IoT device generally doesn't need a legible SNI.
Would like to explore the possibility of hiding or disguising the SNI hostname in snifd/cln.c connection
without breaking the end-to-end TLS stream.

Certificate expired

The certificate of snif.host expired on Sept 29.

Support for ESNI / ECH in snifd/cln.c

snifd/cln.c, the receiver of the client TLS connections, works fine with a plaintext SNI in the TLS hello request.
Would like to explore the possibility of supporting ESNI or encrypted TLS hello (ECH).
The SNIF relay host should keep the private key, available to snifd relay, and publish the DNS RR with the public key for the wildcard SNIF subdomains.
The end IoT device that connects to snifd/srv.c shouldn't need a legible SNI record, so it should be ok to pass the encrypted SNI as is (although the device won't have the private key to decrypt it), or to correctly discard it.