一、背景
HTTP是一个传输内容有可读性的公开协议，客户端与服务器端的数据完全通过明文传输。在这个背景之下，整个依赖于Http协议的互联网数据都是透明的，这带来了很大的数据安全隐患。想要解决这个问题有两个思路：
C/S端各自负责，即客户端与服务端使用协商好的加密内容在Http上通信
C/S端不负责加解密，加解密交给通信协议本身解决
第一种在现实中的应用范围其实比想象中的要广泛一些。双方线下交换密钥，客户端在发送的数据采用的已经是密文了，这个密文通过透明的Http协议在互联网上传输。服务端在接收到请求后，按照约定的方式解密获得明文。这种内容就算被劫持了也不要紧，因为第三方不知道他们的加解密方法。然而这种做法太特殊了，客户端与服务端都需要关心这个加解密特殊逻辑。
第二种C/S端可以不关心上面的特殊逻辑，他们认为发送与接收的都是明文，因为加解密这一部分已经被协议本身处理掉了。
从结果上看这两种方案似乎没有什么区别，但是从软件工程师的角度看区别非常巨大。因为第一种需要业务系统自己开发响 应的加解密功能，并且线下要交互密钥，第二种没有开发量。
HTTPS是当前最流行的HTTP的安全形式，由NetScape公司首创。在HTTPS中，URL都是以https://开头，而不是http://。使用了HTTPS时，所有的HTTP的请求与响应在发送到网络上之前都进行了加密，这是通过在SSL层实现的。
二、加密方法
通过SSL层对明文数据进行加密，然后放到互联网上传输，这解决了HTTP协议原本的数据安全性问题。一般来说，对数据加密的方法分为对称加密与非对称加密。
2.1 对称加密
对称加密是指加密与解密使用同样的密钥，常见的算法有DES与AES等，算法时间与密钥长度相关。
对称密钥最大的缺点是需要维护大量的对称密钥，并且需要线下交换。加入一个网络中有n个实体，则需要n(n-1)个密钥。
2.2 非对称加密
非对称加密是指基于公私钥(public/private key)的加密方法，常见算法有RSA，一般而言加密速度慢于对称加密。
对称加密比非对称加密多了一个步骤，即要获得服务端公钥，而不是各自维护的密钥。
整个加密算法建立在一定的数论基础上运算，达到的效果是，加密结果不可逆。即只有通过私钥(private key)才能解密得到经由公钥(public key)加密的密文。
在这种算法下，整个网络中的密钥数量大大降低，每个人只需要维护一对公司钥即可。即n个实体的网络中，密钥个数是2n。
其缺点是运行速度慢。
2.3 混合加密
周星驰电影《食神》中有一个场景，黑社会火并，争论撒尿虾与牛丸的底盘划分问题。食神说：“真是麻烦，掺在一起做成撒尿牛丸那，笨蛋！”
对称加密的优点是速度快，缺点是需要交换密钥。非对称加密的优点是不需要交互密钥，缺点是速度慢。干脆掺在一起用好了。
混合加密正是HTTPS协议使用的加密方式。先通过非对称加密交换对称密钥，后通过对称密钥进行数据传输。
由于数据传输的量远远大于建立连接初期交换密钥时使用非对称加密的数据量，所以非对称加密带来的性能影响基本可以忽略，同时又提高了效率。
三、HTTPS握手
可以看到，在原HTTP协议的基础上，HTTPS加入了安全层处理：
客户端与服务端交换证书并验证身份，现实中服务端很少验证客户端的证书
协商加密协议的版本与算法，这里可能出现版本不匹配导致失败
协商对称密钥，这个过程使用非对称加密进行
将HTTP发送的明文使用3中的密钥，2中的加密算法加密得到密文
TCP层正常传输，对HTTPS无感知
四、HttpClient对HTTPS协议的支持
4.1 获得SSL连接工厂以及域名校验器
作为一名软件工程师，我们关心的是“HTTPS协议”在代码上是怎么实现的呢？探索HttpClient源码的奥秘，一切都要从HttpClientBuilder开始。
上面的代码将一个Ssl连接工厂SSLConnectionSocketFactory创建，并注册到了连接池管理器中，供之后生产Ssl连接使用。连接池的问题参考：http://www.cnblogs.com/kingszelda/p/8988505.html
这里在配置SSLConnectionSocketFactory时用到了几个关键的组件，域名验证器HostnameVerifier以及上下文SSLContext。
其中HostnameVerifier用来验证服务端证书与域名是否匹配，有多种实现，DefaultHostnameVerifier采用的是默认的校验规则，替代了之前版本中的BrowserCompatHostnameVerifier与StrictHostnameVerifier。NoopHostnameVerifier替代了AllowAllHostnameVerifier，采用的是不验证域名的策略。
注意，这里有一些区别，BrowserCompatHostnameVerifier可以匹配多级子域名，"*.foo.com"可以匹配"a.b.foo.com"。StrictHostnameVerifier不能匹配多级子域名，只能到"a.foo.com"。
而4.4之后的HttpClient使用了新的DefaultHostnameVerifier替换了上面的两种策略，只保留了一种严格策略及StrictHostnameVerifier。因为严格策略是IE6与JDK本身的策略，非严格策略是curl与firefox的策略。即默认的HttpClient实现是不支持多级子域名匹配策略的。
SSLContext存放的是和密钥有关的关键信息，这部分与业务直接相关，非常重要，这个放在后面单独分析。
4.2 如何获得SSL连接
如何从连接池中获得一个连接，这个过程之前的文章中有分析过，这里不做分析，参考连接：http://www.cnblogs.com/kingszelda/p/8988505.html。
在从连接池中获得一个连接后，如果这个连接不处于establish状态，就需要先建立连接。
DefaultHttpClientConnectionOperator部分的代码为：
在上面的代码中，我们看到了是建立SSL连接之前的准备工作，这是通用流程，普通HTTP连接也一样。SSL连接的特殊流程体现在哪里呢？
SSLConnectionSocketFactory部分源码如下：
可以看到，对于一个SSL通信而言。首先是建立普通socket连接，然后进行ssl握手，之后验证证书与域名一致性。之后的操作就是通过SSLSocketImpl进行通信，协议细节在SSLSocketImpl类中体现，但这部分代码jdk并没有开源，感兴趣的可以下载相应的openJdk源码继续分析。
五、本文总结
https协议是http的安全版本，做到了传输层数据的安全，但对服务器cpu有额外消耗
https协议在协商密钥的时候使用非对称加密，密钥协商结束后使用对称加密
有些场景下，即使通过了https进行了加解密，业务系统也会对报文进行二次加密与签名
HttpClient在build的时候，连接池管理器注册了两个SslSocketFactory，用来匹配http或者https字符串
https对应的socket建立原则是先建立，后验证域名与证书一致性
ssl层 加解密由jdk自身完成，不需要httpClient进行额外操作
网友评论