网络协议之: 加密传输中的 NPN 和 ALPN
网络协议之:加密传输中的 NPN 和 ALPN 文章目录
简介 SSL/TLS 协议 NPN 和 ALPN 总结简介自从 HTTP 从 1.1 升级到了 2，一切都变得不同了。虽然 HTTP2 没有强制说必须使用加密协议进行传输，但是业界的标准包括各大流行的浏览器都只支持 HTTPS 情况下的 HTTP2 协议。
那么怎么在 HTTPS 之中加入 HTTP2 协议的支持呢？今天本文将会跟大家聊一下 SSL/TLS 协议的扩展 NPN 和 ALPN。
SSL/TLS 协议 SSL(Secure Socket Layer)安全套接层，是 1994 年由 Netscape 公司设计的一套协议，并与 1995 年发布了 3.0 版本。
TLS(Transport Layer Security)传输层安全是 IETF 在 SSL3.0 基础上设计的协议，实际上相当于 SSL 的后续版本。
SSL/TLS 是一种密码通信框架，他是世界上使用最广泛的密码通信方法。
TLS 主要分为两层，底层的是 TLS 记录协议，主要负责使用对称密码对消息进行加密。
上层的是 TLS 握手协议，主要分为握手协议，密码规格变更协议和应用数据协议 4 个部分。
其中最重要的就是握手协议，通过客户端和服务器端的交互，和共享一些必要信息，从而生成共享密钥和交互证书。
接下来我们一步步的介绍每一步的含义：
client hello 客户端向服务器端发送一个 client hello 的消息，包含下面内容：
可用版本号当前时间客户端随机数会话 ID 可用的密码套件清单可用的压缩方式清单我们之前提到了 TLS 其实是一套加密框架，其中的有些组件其实是可以替换的，这里可用版本号，可用的密码套件清单，可用的压缩方式清单就是向服务器询问对方支持哪些服务。
客户端随机数是一个由客户端生成的随机数，用来生成对称密钥。
server hello 服务器端收到 client hello 消息后，会向客户端返回一个 server hello 消息，包含如下内容：
使用的版本号当前时间服务器随机数会话 ID 使用的密码套件使用的压缩方式使用的版本号，使用的密码套件，使用的压缩方式是对步骤 1 的回答。
服务器随机数是一个由服务器端生成的随机数，用来生成对称密钥。
可选步骤:certificate 服务器端发送自己的证书清单，因为证书可能是层级结构的，所以处理服务器自己的证书之外，还需要发送为服务器签名的证书。客户端将会对服务器端的证书进行验证。如果是以匿名的方式通信则不需要证书。
可选步骤:ServerKeyExchange
如果第三步的证书信息不足，则可以发送 ServerKeyExchange 用来构建加密通道。
ServerKeyExchange 的内容可能包含两种形式：
如果选择的是 RSA 协议，那么传递的就是 RSA 构建公钥密码的参数（E，N）。我们回想一下 RSA 中构建公钥的公式：密文=明文^E\ mod\ N 密文=明文 Emod N， 只要知道了 E 和 N，那么就知道了 RSA 的公钥，这里传递的就是 E，N 两个数字。具体内容可以参考 RSA 算法详解如果选择的是 Diff-Hellman 密钥交换协议，那么传递的就是密钥交换的参数，具体内容可以参考更加安全的密钥生成方法 Diffie-Hellman 可选步骤:CertificateRequest 如果是在一个受限访问的环境，比如 fabric 中，服务器端也需要向客户端索要证书。如果并不需要客户端认证，则不需要此步骤。
server hello done 服务器端发送 server hello done 的消息告诉客户端自己的消息结束了。
可选步骤:Certificate
对步骤 5 的回应，客户端发送客户端证书给服务器
ClientKeyExchange
还是分两种情况：
如果是公钥或者 RSA 模式情况下，客户端将根据客户端生成的随机数和服务器端生成的随机数，生成预备主密码，通过该公钥进行加密，返送给服务器端。如果使用的是 Diff-Hellman 密钥交换协议，则客户端会发送自己这一方要生成 Diff-Hellman 密钥而需要公开的值。具体内容可以参考更加安全的密钥生成方法 Diffie-Hellman，这样服务器端可以根据这个公开值计算出预备主密码。可选步骤:CertificateVerify 客户端向服务器端证明自己是客户端证书的持有者。
ChangeCipherSpec(准备切换密码)
ChangeCipherSpec 是密码规格变更协议的消息，表示后面的消息将会以前面协商过的密钥进行加密。
finished(握手协议结束)
客户端告诉服务器端握手协议结束了。
ChangeCipherSpec(准备切换密码)
服务器端告诉客户端自己要切换密码了。
finished(握手协议结束)
服务器端告诉客户端，握手协议结束了。
切换到应用数据协议
这之后服务器和客户端就是以加密的方式进行沟通了。
NPN 和 ALPN 上面我们介绍 SSL/TLS 协议的时候，最后一步是切换到应用数据协议，那么客户端是怎么和服务器端讨论协商具体使用哪种应用数据协议呢？是使用 HTTP1.1？还是 HTTP2？还是 SPDY 呢？
这里就要用到 TLS 扩展协议了。而 NPN(Next Protocol Negotiation) 和 ALPN (Application Layer Protocol Negotiation) 就是两个 TLS 的扩展协议。
他们主要用在 TLS 中，用来协商客户端和服务器端到底应该使用什么应用数据协议进行沟通。
其中 NPN 是 SPDY 使用的扩展，而 ALPN 是 HTTP2 使用的扩展。
他们两个有什么区别呢？
相较于 NPN 来说，ALPN 在 client hello 消息中已经列出了客户端支持的应用层协议，服务器端只需要从中选择出它支持的协议即可。比 NPN 少了一个交互的步骤，所以 ALPN 是推荐的协议。
下面是具体的交互流程图：
交互的例子下面以 ALPN 为例，讲解下具体的交互流程，首先是客户端发送”Client Hello“消息：
可以看到在 client hello 消息中的 Extension 字段中，使用了 ALPN，并且列出了可以选择使用的两种 ALPN Protocol：h2 和 http/1.1。
对应的“server hello” 消息会选择出具体使用的 ALPN protocol 如下：
如上所示，服务器端选择了 h2， 最终当客户端和服务器端 TLS 握手结束之后，会选择使用 HTTP2 作为后续的应用层数据协议。
总结 NPN 和 ALPN 都是 TLS 的扩展，相较而言，ALPN 更加好用。
本文已收录于 http://www.flydean.com/08-ssl-tls-npn-alpn/
最通俗的解读，最深刻的干货，最简洁的教程，众多你不知道的小技巧等你来发现！
欢迎关注我的公众号:「程序那些事」,懂技术，更懂你！
版权声明: 本文为 InfoQ 作者【程序那些事】的原创文章。
原文链接:【http://xie.infoq.cn/article/a0352e3343ca818d20d859026】。文章转载请联系作者。
关注公众号：程序那些事，更多精彩等着你！ 2020.06.07 加入
最通俗的解读，最深刻的干货，最简洁的教程，众多你不知道的小技巧，尽在公众号：程序那些事！
评论