共计 8816 个字符，预计需要花费 23 分钟才能阅读完成。
一、背景
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 开始。
public CloseableHttpClient build() {
// 省略局部代码
HttpClientConnectionManager connManagerCopy = this.connManager;
// 如果指定了连接池管理器则应用指定的，否则新建一个默认的
if (connManagerCopy == null) {
LayeredConnectionSocketFactory sslSocketFactoryCopy = this.sslSocketFactory;
if (sslSocketFactoryCopy == null) {
// 如果开启了应用环境变量，https 版本与明码控件从环境变量中读取
final String[] supportedProtocols = systemProperties ? split(System.getProperty("https.protocols")) : null;
final String[] supportedCipherSuites = systemProperties ? split(System.getProperty("https.cipherSuites")) : null;
// 如果没有指定，应用默认的域名验证器，会依据 ssl 会话中服务端返回的证书来验证与域名是否匹配
HostnameVerifier hostnameVerifierCopy = this.hostnameVerifier;
if (hostnameVerifierCopy == null) {hostnameVerifierCopy = new DefaultHostnameVerifier(publicSuffixMatcherCopy);
}
// 如果制订了 SslContext 则生成定制的 SSL 连贯工厂，否则应用默认的连贯工厂
if (sslContext != null) {
sslSocketFactoryCopy = new SSLConnectionSocketFactory(sslContext, supportedProtocols, supportedCipherSuites, hostnameVerifierCopy);
} else {if (systemProperties) {
sslSocketFactoryCopy = new SSLConnectionSocketFactory((SSLSocketFactory) SSLSocketFactory.getDefault(),
supportedProtocols, supportedCipherSuites, hostnameVerifierCopy);
} else {
sslSocketFactoryCopy = new SSLConnectionSocketFactory(SSLContexts.createDefault(),
hostnameVerifierCopy);
}
}
}
// 将 Ssl 连贯工厂注册到连接池管理器中，当须要产生 Https 连贯的时候，会依据下面的 SSL 连贯工厂生产 SSL 连贯
@SuppressWarnings("resource")
final PoolingHttpClientConnectionManager poolingmgr = new PoolingHttpClientConnectionManager(RegistryBuilder.<ConnectionSocketFactory>create()
.register("http", PlainConnectionSocketFactory.getSocketFactory())
.register("https", sslSocketFactoryCopy)
.build(),
null,
null,
dnsResolver,
connTimeToLive,
connTimeToLiveTimeUnit != null ? connTimeToLiveTimeUnit : TimeUnit.MILLISECONDS);
// 省略局部代码
}
}
下面的代码将一个 Ssl 连贯工厂 SSLConnectionSocketFactory 创立，并注册到了连接池管理器中，供之后生产 Ssl 连贯应用。连接池的问题参考：http://www.cnblogs.com/kingsz…
这里在配置 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/kingsz…。
在从连接池中取得一个连贯后，如果这个连贯不处于 establish 状态，就须要先建设连贯。
DefaultHttpClientConnectionOperator 局部的代码为：
public void connect(
final ManagedHttpClientConnection conn,
final HttpHost host,
final InetSocketAddress localAddress,
final int connectTimeout,
final SocketConfig socketConfig,
final HttpContext context) throws IOException {
// 之前在 HttpClientBuilder 中 register 了 http 与 https 不同的连接池实现，这里 lookup 取得 Https 的实现，即 SSLConnectionSocketFactory
final Lookup<ConnectionSocketFactory> registry = getSocketFactoryRegistry(context);
final ConnectionSocketFactory sf = registry.lookup(host.getSchemeName());
if (sf == null) {throw new UnsupportedSchemeException(host.getSchemeName() +
"protocol is not supported");
}
// 如果是 ip 模式的地址能够间接应用，否则应用 dns 解析器解析失去域名对应的 ip
final InetAddress[] addresses = host.getAddress() != null ?
new InetAddress[] { host.getAddress() } : this.dnsResolver.resolve(host.getHostName());
final int port = this.schemePortResolver.resolve(host);
// 一个域名可能对应多个 Ip, 依照程序尝试连贯
for (int i = 0; i < addresses.length; i++) {final InetAddress address = addresses[i];
final boolean last = i == addresses.length - 1;
// 这里只是生成一个 socket，还并没有连贯
Socket sock = sf.createSocket(context);
// 设置一些 tcp 层的参数
sock.setSoTimeout(socketConfig.getSoTimeout());
sock.setReuseAddress(socketConfig.isSoReuseAddress());
sock.setTcpNoDelay(socketConfig.isTcpNoDelay());
sock.setKeepAlive(socketConfig.isSoKeepAlive());
if (socketConfig.getRcvBufSize() > 0) {sock.setReceiveBufferSize(socketConfig.getRcvBufSize());
}
if (socketConfig.getSndBufSize() > 0) {sock.setSendBufferSize(socketConfig.getSndBufSize());
}
final int linger = socketConfig.getSoLinger();
if (linger >= 0) {sock.setSoLinger(true, linger);
}
conn.bind(sock);
final InetSocketAddress remoteAddress = new InetSocketAddress(address, port);
if (this.log.isDebugEnabled()) {this.log.debug("Connecting to" + remoteAddress);
}
try {
// 通过 SSLConnectionSocketFactory 建设连贯并绑定到 conn 上
sock = sf.connectSocket(connectTimeout, sock, host, remoteAddress, localAddress, context);
conn.bind(sock);
if (this.log.isDebugEnabled()) {this.log.debug("Connection established" + conn);
}
return;
}
// 省略一些代码
}
}
在下面的代码中，咱们看到了是建设 SSL 连贯之前的筹备工作，这是通用流程，一般 HTTP 连贯也一样。SSL 连贯的非凡流程体现在哪里呢？
SSLConnectionSocketFactory 局部源码如下：
@Override
public Socket connectSocket(
final int connectTimeout,
final Socket socket,
final HttpHost host,
final InetSocketAddress remoteAddress,
final InetSocketAddress localAddress,
final HttpContext context) throws IOException {Args.notNull(host, "HTTP host");
Args.notNull(remoteAddress, "Remote address");
final Socket sock = socket != null ? socket : createSocket(context);
if (localAddress != null) {sock.bind(localAddress);
}
try {if (connectTimeout > 0 && sock.getSoTimeout() == 0) {sock.setSoTimeout(connectTimeout);
}
if (this.log.isDebugEnabled()) {this.log.debug("Connecting socket to" + remoteAddress + "with timeout" + connectTimeout);
}
// 建设连贯
sock.connect(remoteAddress, connectTimeout);
} catch (final IOException ex) {
try {sock.close();
} catch (final IOException ignore) { }
throw ex;
}
// 如果以后是 SslSocket 则进行 SSL 握手与域名校验
if (sock instanceof SSLSocket) {final SSLSocket sslsock = (SSLSocket) sock;
this.log.debug("Starting handshake");
sslsock.startHandshake();
verifyHostname(sslsock, host.getHostName());
return sock;
} else {
// 如果不是 SslSocket 则将其包装为 SslSocket
return createLayeredSocket(sock, host.getHostName(), remoteAddress.getPort(), context);
}
}
@Override
public Socket createLayeredSocket(
final Socket socket,
final String target,
final int port,
final HttpContext context) throws IOException {
// 将一般 socket 包装为 SslSocket,socketfactory 是依据 HttpClientBuilder 中的 SSLContext 生成的，其中蕴含密钥信息
final SSLSocket sslsock = (SSLSocket) this.socketfactory.createSocket(
socket,
target,
port,
true);
// 如果制订了 SSL 层协定版本与加密算法，则应用指定的，否则应用默认的
if (supportedProtocols != null) {sslsock.setEnabledProtocols(supportedProtocols);
} else {
// If supported protocols are not explicitly set, remove all SSL protocol versions
final String[] allProtocols = sslsock.getEnabledProtocols();
final List<String> enabledProtocols = new ArrayList<String>(allProtocols.length);
for (final String protocol: allProtocols) {if (!protocol.startsWith("SSL")) {enabledProtocols.add(protocol);
}
}
if (!enabledProtocols.isEmpty()) {sslsock.setEnabledProtocols(enabledProtocols.toArray(new String[enabledProtocols.size()]));
}
}
if (supportedCipherSuites != null) {sslsock.setEnabledCipherSuites(supportedCipherSuites);
}
if (this.log.isDebugEnabled()) {this.log.debug("Enabled protocols:" + Arrays.asList(sslsock.getEnabledProtocols()));
this.log.debug("Enabled cipher suites:" + Arrays.asList(sslsock.getEnabledCipherSuites()));
}
prepareSocket(sslsock);
this.log.debug("Starting handshake");
//Ssl 连贯握手
sslsock.startHandshake();
// 握手胜利后校验返回的证书与域名是否统一
verifyHostname(sslsock, target);
return sslsock;
}
能够看到，对于一个 SSL 通信而言。首先是建设一般 socket 连贯，而后进行 ssl 握手，之后验证证书与域名一致性。之后的操作就是通过 SSLSocketImpl 进行通信，协定细节在 SSLSocketImpl 类中体现，但这部分代码 jdk 并没有开源，感兴趣的能够下载相应的 openJdk 源码持续剖析。
五、本文总结
- https 协定是 http 的平安版本，做到了传输层数据的平安，但对服务器 cpu 有额定耗费
- https 协定在协商密钥的时候应用非对称加密，密钥协商完结后应用对称加密
- 有些场景下，即便通过了 https 进行了加解密，业务零碎也会对报文进行二次加密与签名
- HttpClient 在 build 的时候，连接池管理器注册了两个 SslSocketFactory，用来匹配 http 或者 https 字符串
- https 对应的 socket 建设准则是先建设，后验证域名与证书一致性
- ssl 层 加解密由 jdk 本身实现，不须要 httpClient 进行额定操作
