浅谈HTTPS SNI

什么是SNI？

SNI全称是 Server Name Indication，它是TLS协议的一个扩展，在TLS握手时用来标记客户端的关键信息。https通常使用SNI标记请求域名或主机名，web server能根据SNI快速识别出请求地址，进而实现CDN、WAF、HTTP代理等一些重要特性（SNI是TLS协议扩展，非http服务的TCP+TLS也可以使用SNI完成一些特定功能）。

SNI的作用

曾经，在无SNI或基础库不支持SNI的年代，假如我们要开发一个web代理，这个代理是CDN或WAF系统的一个基础功能。

每个用户系统都接入到web代理系统，由于不支持SNI，为了使代理系统能够区分多用户

一、每个用户分配唯一的IP；

二、多用户共享IP，使用端口区分，例如，http://ip:port/index；

三、多用户共享一个IP，为每个用户分配唯一的子域名(或主机名)，使用DNS别名(cname)到子域名，web代理根据Http头部Host携带的主机名标记来识别请求。

方案一，公网IP有限，根本不实用；

方案二，用户体验差，且通http客户端所在网关只开放了80/443端口，导致web无法访问；

方案三，能很好地完成一些http代理能力，这也是目前常用的http代理方案，但却难以实现一些基于https的新特性。

通常CDN或WAF系统并不是简单的http代理

● 能够解析https，且每个用户使用的自有证书(用户把证书上传到代理系统)

● 需要对每个https请求的内容进行安全检查

● 压缩、缓存、回源等其它功能

要实现上述功能，web代理在收到http请求时首先要知道使用哪个证书来跟客户端进行握手，只有握手成功才能从TLS解密出http内容，这是问题的根本。

因为https是通过TCP+TLS传输的，web代理收到的http内容经过加密的数据，无法确定TCP连接是谁发过来的，web代理拥有众多用户的证书，但究竟拿哪一个证书进行TLS握手？如果每个证书都尝试一遍？这样效率也太低了！但我们发现，尽管TLS传输内容是加密的，但在建立会话的握手阶段，它的报文头是明文(Hello报文)，如果客户端能在TLS握手报文里放置标记自已身份的ID那问题就会变得十分简单。

为了解决类似上述的场景，TLS扩展实现了

Web应用通常使用SNI携带域名或主机名，除了上述的证书加载，还可以实现其它功能，例如，在无法得到用户的SSL证书情况下，网关只需扫描TLS和SNI就可以实现域名安全检查、域备是否备案等。另外，物联网也可以利用SNI标记设备ID，实现TLS的双向认证。

SNI支持情况

 目前绝对大多数浏览器、http服务器以及其所依赖的加密库都支持SNI，下面的SNI支持情况来源于互联网，仅供参考：

● Chrome 5及以上版本、Chrome 6及以上版本（Windows XP）

●  Firefox 2及以上版本

●  IE 7及以上版本（运行在Windows Vista

/Server12008及以上版本版本系统中，在XP系统中任何版本的IE浏览器都不支持SNI）

●  Konqueror 4.7 及以上版本

●  Opera 8 及以上版本

● Safari 3.0 on Windows Vista/Server 2008 及以上版本, or Mac OS X 10.5.6 及以上版本

● Android Browser on 3.0 Honeycomb 及以上版本

● iOS Safari on iOS 4 及以上版本

● Windows Phone 7 及以上版本

● Apache 2.2.12 及以上版本

● Apache Traffic Server 3.2.0 及以上版本

● Cherokee

● HAProxy 1.5 及以上版本

● IIS 8.0 及以上版本

● lighttpd 1.4.24 及以上版本

● LiteSpeed 4.1 及以上版本

● nginx 0.5.32 及以上版本

● cURL 7.18.1 及以上版本

● wget 1.14 及以上版本

● GNU TLS

● JSSE (Oracle Java) 7 及以上版本, 仅作为客户端

● libcurl 7.18.1 及以上版本

● NSS 3.1.1 及以上版本

● OpenSSL 0.9.8j 及以上版本

● OpenSSL 0.9.8f 及以上版本，需配置flag

● Qt 4.8 及以上版本