SNI Reset - complementing DNS spoofing

2018-12-02 14:43:16

       最近修改hosts以应对DNS污染的方式失效了,同样的,一个不受污染的DNS也是毫无用处。而这一切的背后,便是SNI阻断。SNI - Server Name Indication,用于TLS握手时的证书选择,在ClientHello中以明文传输,与明文的HTTP一样,成为了网络安全的阿喀琉斯之踵。TLS1.3中会预期加入ESNI,加密的SNI传输,但目前未广泛部署,因而SNI仍被明文传输。

#尝试以下命令
wget -O /dev/null https://en.wikipedia.org/wiki/Wikipedia:%E9%A6%96%E9%A1%B5 \
--header 'Host: zh.wikipedia.org'
#再尝试以下命令
wget -O /dev/null https://zh.wikipedia.org/wiki/Wikipedia:%E9%A6%96%E9%A1%B5 \
--header 'Host: zh.wikipedia.org'
#注意到唯一的不同之处在于server name,前者可以访问,后者则反之。
#但对于
drill en.wikipedia.org
drill zh.wikipedia.org
#结果均为198.35.26.96

       也即IP层并未被阻断,可见问题在于明文SNI被过滤了。正如多年前对于HTTP明文的关键词阻断一样,TCP流重建再次走上了历史舞台。而不同于HTTP明文过滤时关键词出现位置往往不固定的状况,ClientHello中的SNI字段理所当然地出现在流的前部,乃至仅在连接建立后的第一个数据包中,也给攻击者带来了极大便利。而对此的应对措施,却因为各大服务提供商对于Domain fronting的负面态度而停滞不前,只能寄希望于即将标准化的TLS1.3能带来怎样的可能。