You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: