网络安全篇，面对复杂多变的网络环境，我们需要掌握哪些关于网络安全的相关知识，聊一聊与网络安全相关的：HTTPS、SSL、TLS 等。
网络安全专题
- 网络安全的基石
《网络安全 — HTTPS》
《网络安全的基石（上）— 加密》
《网络安全的基石（下）— 完整性与身份认证》
《公钥信任问题 — 数字证书与 CA》
《信任始于握手 — TLS 连接过程详解》
- HTTPS 的优化
《TLS 1.3 特性解析》
《如何优化 HTTPS 连接》- 待完善
问题描述
今天我们来聊一聊，最近在项目开发过程中，遇到的关于网络安全相关的异常。客户端网络框架请求报错如下：
javax.net.ssl.SSLException: hostname in certificate didn`t match:
!= <*.b0.upaiyun.com> OR <*.b0.upaiyun.com>
出现该报错，基本可以确定服务器返回的证书中不包含当前请求域名的证书。为什么会出现该问题呢？服务器为什么没有返回对应请求域名的证书呢？
其实该问题是由于 Web 服务器配置了多个主机域名，即同一个 IP 服务上被多个域名共享，该怎么理解它呢？下面我们通过 nginx 的配置来了解下：
server {
listen 443;
server_name www.example.com;
ssl on;
ssl_certificate www.example.com.crt;
}
server {
listen 443;
server_name www.example.org;
ssl on;
ssl_certificate www.example.org.crt;
}
可以看到在同一个 IP 服务（HTTPS）上配置了多个域名，那这有什么影响吗？
“此时服务器必须要知道客户端所请求的域名，这是因为一个 IP 服务部署了多个 HTTPS 域名后，每个域名会独立对应一张证书，如果服务器不知道客户端请求的域名（客户端未支持），此时只能返回缺省的域名证书，如上就是 www.example.com 对应的证书。这就可能会导致客户端无法正常访问服务的情况”
上面的操作实际是开启了 nginx 对 TLS SNI 的支持（默认是关闭的）
那如何解决该问题呢？
我们知道在 HTTP 协议中，请求的主机信息是在 HTTP 的请求头中，但是使用 HTTPS 时，由于 TLS 握手发生在服务器看到任何 HTTP 协议数据之前，因此服务器无法使用 HTTP 请求头中的信息来确定要呈现的证书，所以 TLS 引入了一个扩展协议 SNI，目的是让服务器在 TLS 握手阶段就能知道客户端所请求的域名，从而返回客户端所需要的域名证书。
SNI ？
SNI（服务器名称指示）属于 TLS（传输层安全） 安全协议的扩展，客户端通过该协议在握手开始阶段指明其尝试连接的主机名。
这样基于 SNI 的虚拟主机允许同一个 IP 地址服务器托管多个 DNS 主机名，即同一个 IP:Port 上显示多张证书，从而允许多个安全网站（HTTPS）由同一个 IP 地址提供服务，而无需使用同一张证书。
SNI 定义在 RFC 4366，属于对 SSL/TLS 协议的改善，在 SSLv3/TLSv1 中被启用；这样在客户端发起 TLS 握手请求时就提交请求的 Host 信息，使服务器在 TLS 握手阶段就能够知道客户端所请求的域名。
SNI 早在 2004 年就已经被提出，目前在主流的浏览器、服务器及测试工具都能够提供支持。
出现背景
随着 IPv4 地址的短缺，为了让多个域名复用同一个 IP 地址，HTTP 服务引入了虚拟主机的概念。即服务器可以根据客户端不同的 Host 请求，将请求分配给不同的域名处理。一个 IP 地址对应多个域名。
但是在一个被多个域名所共享的 IP 服务（HTTPS）上，由于在握手建立之前服务器无法知道客户端请求的是哪个 Host，此时就出现了无法将请求交给特定的虚拟主机。所以就出现了上面的问题，服务端返回了缺省证书，但是该证书所对应域名并非客户端请求的 Host。
SNI 的出现对客户端和服务器来说，使得单个 IP 地址的服务器可以为一组域名提供服务，而对于每个域名都有其唯一的证书。
实现
我们已经知道 SNI 是为了解决一台服务器使用多个域名和证书的 TLS 扩展，它的实现是在客户端建立 TLS 连接时的 ClientHello 消息中，下面我们通过 Wireshark 抓包看下。
通过扩展协议包含要访问的站点域名（Hostname），这样服务器会根据这个域名返回一个合适的证书。
SNI 兼容
回到文章开头，此时我们再来看该问题是不是就很容易理解了？
由于使用了不支持 SNI 的客户端访问开启 SNI 服务器时，在 TLS 握手阶段服务器不知道客户端请求的是哪个域名，服务器只能返回一个内置的缺省证书。注意，如果运气好，SNI 的第一个配置正好是客户端所请求的域名证书，否则此时域名校验失败。
SNI 的兼容性，这里主要说下移动端的支持
- 移动端浏览器支持
- Mobile Safari for iOS 4.0
- Android 3.0（Honeycomb）and later
- Windows Phone 7
- Android 网络库支持
HttpURLConnection 在 Android 2.3 之后就已经支持了 SNI，从 Android 4.4 开始 HttpURLConnection 的底层实现采用的是 OkHttp。
Android 在 6.0 之前内嵌了 Apache HttpClient，此时不支持，6.0 以后被官方从 SDK 中移除，新引入的依赖库在 6.0 之后可以支持。
目前较为主流的 Android 网络库是 OkHttp，不过从它的 issues中可以看到是在 2014 年才开始支持 SNI 的。
原生的 WebView 在 Android 3.0 之后开始支持 SNI。
- iOS 网络库支持
- NSURLConnection/NSURLSession 并没有提供接口进行SNI字段的配置。
扩展阅读
- Transport Layer Security（TLS）Extensions - RFC-4366
- Server Name Indication RFC-4366
- SNI 兼容性导致 HTTPS 访问异常
- HTTPS 之 SNI 介绍