Https详解
一、定义
Hypertext Transfer Protocol Secure（超文本传输安全协议，缩写：HTTPS）是一种网络安全传输协议。 它是在http协议的基础上开发的，实现了加密传输，解决了http协议传输不安全的问题。https协议由网景公司（Netscape）在1994年首次提出的。提到网景，会想到那场惊心动魄的浏览器大战，只可惜网景没有胜出。自古成王败寇，只能感叹商场竞争的残酷。如果当年网景能够存活下来，不知道还会带来多少惊喜。
二、原理
HTTPS在传输数据之前需要客户端与服务端之间进行一次握手，在握手过程中将确立双方加密传输数据的密码信息。握手过程的如下图所示：
三、SSL/TLS简介
https又称为http over TLS/SSL。它的核心是TLS/SSL,所以我们先了解一下。
TLS/SSL协议设计得非常精妙，它的智慧在于，用非对称秘钥加密要交换的key，真正通信的时候，用对称秘钥加密信息。充分利用了非对称加密的安全性和对称加密的高效性。
为什么交换的key，需要非对称秘钥来传输呢？因为，对称秘钥是在本地生成的，但是要生成秘钥，需要key的参与，所以key也需要保密。
TLS/SSL对加密算法进行了综合应用，使用了非对称加密，对称加密以及HASH算法。常见的算法：
非对称加密算法：RSA，DSA/DSS
对称加密算法： AES，RC4，3DES
HASH算法： MD5，SHA1，SHA256
TLS：(Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性。TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任务组）制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本，可以理解为SSL 3.1，它是写入了 RFC 的。
SSL/TLS协议提供的服务主要有：
- 认证用户和服务器，确保数据发送到正确的客户机和服务器；
- 加密数据以防止数据中途被窃取；
- 维护数据的完整性，确保数据在传输过程中不被改变。
TLS对于安全性的改进
- 对于消息认证使用密钥散列法：TLS 使用“消息认证代码的密钥散列法”（HMAC），当记录在开放的网络（如因特网）上传送时，该代码确保记录不会被变更。SSLv3.0还提供键控消息认证，但HMAC比SSLv3.0使用的（消息认证代码）MAC 功能更安全。
- 增强的伪随机功能（PRF）：PRF生成密钥数据。在TLS中，HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了，只要第二种算法未暴露，则数据仍然是安全的。
- 改进的已完成消息验证：TLS和SSLv3.0都对两个端点提供已完成的消息，该消息认证交换的消息没有被变更。然而，TLS将此已完成消息基于PRF和HMAC值之上，这也比SSLv3.0更安全。
- 一致证书处理：与SSLv3.0不同，TLS试图指定必须在TLS之间实现交换的证书类型。
- 特定警报消息：TLS提供更多的特定和附加警报，以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。
四、SSL协议结构：
说明：
SSL协议主要分为两层：SSL记录协议层和SSL握手协议层。
SSL记录协议层
为高层协议提供基本的安全服务。它建立在可靠的传输（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能。
SSL握手协议层
包括SSL握手协议（SSL HandShake Protocol）、SSL密码参数修改协议（SSL Change Cipher Spec Protocol）和SSL告警协议（SSL Alert Protocol）。其中最重要的是SSL握手协议，它建立在SSL记录协议之上，用于在实际的数据传输开始之前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。
五、握手协议
分为两个阶段：
（1）Handshake phase（握手阶段）：
协商加密算法和认证服务器，建立用于加密和MAC（Message Authentication Code，消息认证码）用的密钥。信息认证码 ，是经过特定算法后产生的一小段信息，检查某段消息的完整性 ，以及作身份验证。
（2）Secure data transfer phase（安全的数据传输阶段）：
在已经建立的SSL连接里安全的传输数据。
SSL建立总过程：
我们以访问https://cn.bing.com/网站为例，用WireShark抓包：
ClientHello
握手第一步是客户端向服务端发送 Client Hello 消息，这个消息里包含了一个客户端生成的随机数 Random1、客户端支持的加密套件（Support Ciphers）和 SSL Version 等信息。
这个随机数一方面需要在客户端保存，另一方面需要传送给服务端，客户端的随机数需要跟服务端产生的随机数结合起来产生Master Secret 。
ServerHello
收到客户端问候之后服务器必须发送服务器问候信息，服务器会检查指定诸如TLS版本和算法的客户端问候的条件，如果服务器接受并支持所有条件，它将发送其证书以及其他详细信息，否则，服务器将发送握手失败消息。
跟客户端一样，服务端也需要产生一个随机数发送给客户端。客户端和服务端都需要使用这两个随机数来产生Master Secret。
Server Key Exchange（可选）
根据之前在ClientHello消息中包含的CipherSuite信息，决定了密钥交换方式（例如RSA或者DH）。
在服务端向客户端发送的证书中没有提供足够的信息（证书公钥）的时候，还可以向客户端发送一个 Server Key Exchange，它包含完成密钥交换所需的一系列参数。
Certificate Request（可选）——可以是单向的身份认证，也可以双向认证
这一步是可选的，如果在对安全性要求高的常见可能用到。服务器用来验证客户端。服务器端发出Certificate Request消息，要求客户端发他自己的证书过来进行验证。该消息中包含服务器端支持的证书类型（RSA、DSA、ECDSA等）和服务器端所信任的所有证书发行机构的CA列表，客户端会用这些信息来筛选证书。
Server Hello Done
客户端：
Client Key exchange
客户端按照不同的密钥交换算法，(例如：RSA, Diffie-Hellman)产生一个48个字节的Key，这个key 就叫做premaster key，发送给服务器，服务端收到pre-master算出main master。而客户端当然也能自己通过pre-master算出main master。如此以来双方就算出了对称密钥。
ChangeCipherSpec
ChangeCipherSpec是一个独立的协议，体现在数据包中就是一个字节的数据，用于告知服务端，客户端已经切换到之前协商好的加密套件（Cipher Suite）的状态，准备使用之前协商好的加密套件加密数据并传输了。
服务端：
服务端在接收到客户端传过来的 PreMaster 加密数据之后，使用私钥对这段加密数据进行解密，并对数据进行验证，也会使用跟客户端同样的方式生成 Session Secret，一切准备好之后，会给客户端发送一个 ChangeCipherSpec，告知客户端已经切换到协商过的加密套件状态，准备使用加密套件和 Session Secret加密数据了。
六、几个secret
Secret Keys
上面的分析和讲解主要是为了突出握手的过程，所以PreMaster secret，Master secret，session secret都是一代而过，但是对于Https，SSL/TLS深入的理解和掌握，这些Secret Keys是非常重要的部分。所以，准备把这些Secret Keys抽出来单独分析和讲解。
我们先来看看这些Secret Keys的生成过程以及作用流程图：
PreMaster secret
PreMaster Secret是在客户端使用RSA或者Diffie-Hellman等加密算法生成的。它将用来跟服务端和客户端在Hello阶段产生的随机数结合在一起生成 Master Secret。在客户端使用服务端的公钥对PreMaster Secret进行加密之后传送给服务端，服务端将使用私钥进行解密得到PreMaster secret。也就是说服务端和客户端都有一份相同的PreMaster secret和随机数。
PreMaster secret前两个字节是TLS的版本号，这是一个比较重要的用来核对握手数据的版本号，因为在Client Hello阶段，客户端会发送一份加密套件列表和当前支持的SSL/TLS的版本号给服务端，而且是使用明文传送的，如果握手的数据包被破解之后，攻击者很有可能串改数据包，选择一个安全性较低的加密套件和版本给服务端，从而对数据进行破解。所以，服务端需要对密文中解密出来对的PreMaster版本号跟之前Client Hello阶段的版本号进行对比，如果版本号变低，则说明被串改，则立即停止发送任何消息。
七、数字证书和 CA 机构
协议中，服务器返回证书，客户端需要身份认证，而且还要用证书里的公钥加密，所以有必要把证书详细了解下。
在说校验数字证书是否可信的过程前，我们先来看看数字证书是什么，一个数字证书通常包含了：
- 公钥；
- 持有者信息；
- 证书认证机构（CA）的信息；
- CA 对这份文件的数字签名及使用的算法；
- 证书有效期；
- 还有一些其他额外信息；
那数字证书的作用，是用来认证公钥持有者的身份，以防止第三方进行冒充。说简单些，证书就是用来告诉客户端，该服务端是否是合法的，因为只有证书合法，才代表服务端身份是可信的。
证书如下图：
我们用证书来认证公钥持有者的身份（服务端的身份），那证书又是怎么来的？又该怎么认证证书呢？
证书指纹：29b4ede71f1c1b12996c9b1e2775ac012515771f，相当于身份证。这个证书指纹就是解密后的Hash值。证书的格式遵循X.509 标准。X.509 是由国际电信联盟制定的数字证书标准。这个标准规定了证书应该有哪些信息。
X.500和X.509是X.500系列标准中最核心的两个协议。
X.500是用来管理用户名，且提供搜索，确保用户的唯一性。
X.509是一个鉴别框架。用户可用常规加密算法（如 DES）为 信息加密，然后再用接收者的公共密钥对 DES 迚行加密并将之附于信息之上， 这样接收者可用对应的私钥打开 DES 密锁，并对信息解密。
为了让服务端的公钥被大家信任，服务端的证书都是由 CA （Certificate Authority，证书认证机构）签名的，CA 就是网络世界里的公安局、公证中心，具有极高的可信度，所以由它来给各个公钥签名，信任的一方签发的证书，那必然证书也是被信任的。
之所以要签名，是因为签名的作用可以避免中间人在获取证书时对证书内容的篡改。
数字证书签发和验证流程
如下图图所示，为数字证书签发和验证流程：
CA 签发证书的过程，如上图左边部分：
首先 CA 会把持有者的公钥、用途、颁发者、有效时间等信息打成一个包，然后对这些信息进行 Hash 计算，得到一个 Hash 值；
然后 CA 会使用自己的私钥将该 Hash 值加密，生成 Certificate Signature，也就是 CA 对证书做了签名；
最后将 Certificate Signature 添加在文件证书上，形成数字证书；
客户端校验服务端的数字证书的过程，如上图右边部分：
首先客户端会使用同样的 Hash 算法获取该证书的 Hash 值 H1；
通常浏览器和操作系统中集成了 CA 的公钥信息，浏览器收到证书后可以使用 CA 的公钥解密 Certificate Signature 内容，得到一个 Hash 值 H2 ；
最后比较 H1 和 H2，如果值相同，则为可信赖的证书，否则则认为证书不可信。
小结：https的目的是网络安全，它仅仅保证了传输过程中的安全。https是大势所趋，大多数有名的网站都会提供https服务。这只是网络安全里的冰山一角。