SNI field contains an IP address instead of a valid hostname

cohosh commented 2 years ago

Your environment.

Version: v2.0.8
Browser: varies

What did you do?

We've been investigating a possible attempt to block Snowflake by fingerprinting the DTLS connections between clients and Snowflake proxies in Russia: https://ntc.party/t/ooni-reports-of-tor-blocking-in-certain-isps-since-2021-12-01/1477/18

One of the identified differences between the DTLS handshake messages created by Snowflake's use of pion/dtls and a WebRTC connection between two browsers is that pion/dtls will include the SNI extension in the client hello and it is populated with the IP address of the remote peer.

See https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40014 for an overview of differences and examples.

This seems to be a bug. Looking at the behaviour of SNI in crypto/tls, there is the following note:

// hostnameInSNI converts name into an appropriate hostname for SNI.
// Literal IP addresses and absolute FQDNs are not permitted as SNI values.
// See RFC 6066, Section 3.

Proposed change

I think ideally, the SNI extension would not be sent if there is no hostname. I saw in https://github.com/pion/dtls/issues/345 that this library wants to follow the behaviour of crypto/tls and it was asked whether they will send blank SNI extensions. Looking more at crypto/tls, it does appear that the server name extension is only included if the name is not empty: https://cs.opensource.google/go/go/+/master:src/crypto/tls/handshake_messages.go;l=124

Sean-Der commented 2 years ago

Thanks for bringing this up!

Matching crypto/tls is always an auto approval from me :)

Do you have time to make this PR, or would it be helpful if I did the code?

cohosh commented 2 years ago

Working on it now :) Thanks for the quick reply!

pion / dtls