剖析 HTTPS 的设计思路

HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer ，安全的超文本传输协议），是以安全为目标的HTTP通道。即HTTP下加入SSL层，HTTPS的安全基础是SSL，所以加密的详细内容就须要SSL。这个系统的最初研发由 Netscape 进行。

现在，HTTPS 已经渐渐成为主流，不少大型网站都已经全站 HTTPS 化。那么有了 HTTP 后为何还须要有 HTTPS 呢？——为了解决 HTTP 的不足。

HTTP 的不足之处

• 通讯内容使用明文——内容可能被窃听
• 不验证通讯方的身份——可能遭遇假装
• 没法验证报文的完整性——报文有可能已遭篡改

如今来看看通常的明文通讯都存在什么问题。

使用明文传输内容存在的问题

在理想的信息流动状况下，信息可以安全达到目的地且未受到任何攻击。

咱们平时生活中所说的“攻击”，更多地有”主动“的意义。可是这里的攻击，囊括了主动和被动两层意义。根据 ITU-T 的 X.800 推荐标准（OSI 安全框架），攻击分为如下几类：

• 被动攻击
  • 窃听：一个非受权方介入系统的攻击，获取了传输的信息，破坏保密性。
  • 流量攻击：监听流量来判断通讯的性质。
• 主动攻击
  • 假装/冒充：个实体伪装成另一个实体。
  • 伪造/篡改：将伪造的客体插入系统中，破坏真实性。
  • 重放：获取有效数据段以重播的方式获取对方信任。
  • DoS / DDoS：致使合法用户不可以访问正常网络服务的行为都算是拒绝服务攻击。

通常的明文网络访问，没法防止上面所述的攻击方式。经过应用密码学的知识，通常能够阻止上面多数的攻击。（可是密码学对流量攻击、重放和 (D)DoS 还作不了太多。防止重放攻击还须要在更高的应用层作一些处理。）

下面，咱们用密码学来解决它能够解决的风险：

1. 窃听风险：黑客能够获知通讯内容。 —— 保证数据的隐私性
2. 篡改风险：黑客能够修改通讯内容。 —— 保证数据的完整性
3. 冒充风险：黑客能够冒充他人身份参与通讯。 —— 保证身份正确。

解决窃听风险：加密

一、对称加密 。有流式、分组两种，加密和解密都是使用的同一个密钥。 例如：DES、AES 等

二、非对称加密 。加密使用的密钥和解密使用的密钥是不相同的，分别称为：公钥、私钥，公钥和算法都是公开的，私钥是保密的。非对称加密算法性能低，可是安全性超强，因为其加密特性，非对称加密算法能加密的数据长度也是有限的。 例如：RSA、DSA。

非对称加密是最安全的。可是在频繁大量的网络数据传输过程当中，非对称加密算法的性能限制会成为整个系统的瓶颈。若是须要长时间且频繁地传输信息，全程使用非对称加密是万万不能够的。

Client->Server:  I want to talk with you.
Server->Client:  It's my public key.
Client->Server:  Message encoded by public key.
Note: The hacker knows nothing.
Note: Server knows this messgae.
复制代码

只要算法和密钥选择得当，使用对称加密算法能够获得一样安全的加密效果。可是使用对称加密密钥也有它本身的问题：通讯双方如何商定出密钥。通讯双方共享同一个对称密钥，若是双方已经知道这一密钥，以后的信息使用这一密钥进行加密彻底没有问题。 可是，不一样的客户端、服务器数量庞大，因此双方都须要维护大量的密钥，维护成本很高，密钥极易泄露。所以，对称密钥必须动态生成。但问题就在于，密钥如何安全的分享出去。密钥钥若是泄漏，加密就失去了意义。

咱们能够将对称加密和非对称加密联合起来来解决这个问题。

对于没有见过面的双方，第一次请求通讯的时候，S 先发出本身的公钥，C 记下 S 的公钥。以后 S 和 C 协商得出一个对称密钥。由于是通讯非对称加密后的，监听者仅凭他们之间的通讯内容是难以破译出它们协商出的对称密钥的。以后，S、C 使用对称密钥进行正式的通讯，监听者不知道他们的密钥，因此也没法破译他们之间的通讯内容。

看起来很完美。

如何防止中间人：认证

考虑下面的状况：中间人代理了 S、C 之间的全部流量。

C -> H: 请求公钥
H -> S: 请求公钥
S -> H: 返回真实公钥
Note: 伪造密钥对
H -> C: 返回伪造的公钥
Note: 用伪造公钥加密明文
C -> H: 密文
Note: 解密获得明文
Note: 用真实公钥加密明文
H -> S: 密文
Note: 用私钥解密得明文
Note: 无感知
Note: 无感知
复制代码

中间人经过伪造公钥私钥对，假装成 S，同时 C、S 双方对此毫无感知。其实即便不伪造密钥对，只要中间人监听到了公钥，就足以把 S 发给 C 的消息给解密出来。这里的问题是：如何确认 ”S“ 是真实的而不是中间人 ”H“，如何保证公钥的准确 。

为了保证公钥的真实性，引入了认证这一手段。

数字签名

数字签名基于公钥私钥体制，将一段文本经过哈希（hash）和私钥加密处理后生成数字签名。接收者用发送者的公共密钥对签名解密，并将之与收到的信息“指纹”进行比较，以肯定其真实性。只要签名者的私钥不被泄漏，数字签名就是可信的。

+---------------------+
| A digital signature |            +---------+              +--------+
|(not to be confused  |----Hash--->| 消息摘要 |---私钥加密--->| 数字签名 |
|with a digital       |            +---------+              +--------+
+---------------------+
复制代码

数字证书

数字证书，是由一个官方的证书颁发机构（CA）签发的一组数据。这种证书很难伪造，用于使用者的身份证实。

数字证书包含如下内容：

• 对象名称（人、服务器、组织、公司等）
• 对象的公开密钥
• 其它扩展信息
• = = = = = = = = = = = = = = = = = = = = =
• 附上证书颁发机构的数字签名

使用证书，正常的通讯流程是这样子的：

1. S 会把本身的数字证书下发给 C

2. C 经过证书中“证书颁发机构的数字签名”来验证证书的来源和完整性。

   具体作法是使用 CA 的公钥解密并对比。

3. 一旦证书被认证经过，C 就从证书中取出 “对象的公开密钥”，以后就用这个公钥来加密数据。

CA 的私钥仅它本身知道，所以黑客没法伪造 CA 的签名，也不能获得合法的证书。只要证书认证经过，它的公钥就是可信的。

到这里，这整个过程才算是无懈可击的。

HTTPS 具体是怎么作的

HTTPS 的通讯过程和上面描述的基本一致。

-> 客户端向服务端发送请求
-> 服务端返回数字证书
-> 客户端用本身的CA[主流的CA机构证书通常都内置在各个主流浏览器中]公钥去解密证书,若是证书有问题会提示风险
-> 若是证书没问题客户端会生成一个对称加密的随机秘钥而后再和刚刚解密的服务器端的公钥对数据进行加密,而后发送给服务器端
-> 服务器端收到之后会用本身的私钥对客户端发来的对称秘钥进行解密
-> 以后双方就拿着这个对称加密秘钥来进行正常的通讯`
复制代码

整个过程当中，HTTPS 证书使用的是 X.509 证书标准。

X.509 是密码学里公钥证书的格式标准。 X.509 证书己应用在包括TLS/SSL 在内的众多网络协议里。

X.509 是由国际电信联盟（ITU-T）制定的数字证书标准。为了提供公用网络用户目录信息服务， ITU 于 1988 年制定了 X.500 系列标准。其中 X.500 和 X.509 是安全认证系统的核心， X.500 定义了一种区别命名规则，以命名树来确保用户名称的惟一性； X.509 则为 X.500 用户名称提供了通讯实体鉴别机制，并规定了实体鉴别过程当中普遍适用的证书语法和数据接口， X.509 称之为证书。

HTTPS协议使用的是 SSL 证书，它听从了 X.509 标准。

• 证书格式版本号
• 证书序列号
• 过时时间
• 证书办法机构
• 证书使用的签名算法
• 过时时间
• 对象名称（人、服务器、组织、公司等）
• 对象的公开密钥
• 其它扩展信息
• = = = = = = = = = = = = = = = = = = = = =
• 附上证书颁发机构的数字签名

在浏览器中，查看证书内容很是容易。

X.509 证书的信任链

到如今，还有一个问题没有被解决。使用证书认证的前提是 C 知道 S 的公钥，但是S 的公钥不能在不安全的网络中直接发送给 C。

此时就引入了证书颁发机构（Certificate Authority，简称CA），世界上CA数量并很少。C 预先拥有全部受信任CA的证书。若是 S 想要一个证书，它先向 CA 申请，CA 使用它本身的私钥对 S 的证书进行签名。接下来，C 和 S 要相互通讯的时候，S 将它的证书发给 C。 C 拥有全部 CA 的可信公钥，因此 C 能够验证证书的真实性。

如此一来，C 信任 CA，CA信任 S 使得 C 信任 S，信任链（Chain Of Trust）就是这样造成的。

事实上，客户端 C 内置的是 CA的根证书(Root Certificate)，HTTPS协议中服务器会发送证书链（Certificate Chain）给客户端。

如上图，“Wikipedia”的证书的证书链以下。这里，C 必定是信任 根证书 Root CA 的，因而 C 最终信任 "Wikimedia Foundation, Inc" 。这里有一个细节，根证书是由根证书本身来签名和颁发的。

证书	证书颁发者
GlobalSign Root CA（根证书）	GlobalSign Root CA（自签名）
GlobalSign Organization Validation CA - SHA256 - G2	GlobalSign Root CA
"Wikimedia Foundation, Inc."	GlobalSign Organization Validation CA

最终，C 只要内置世界上仅有的几个根证书就能够自行校验全部的 HTTPS 证书了。S 的证书必须通过某一个 CA 的签名。可是如今的操做系统和浏览器也容许用户自行添加本身的根证书。例如 12306.cn 曾经要求用户自行下载安装指定的根证书。

从下图能够看到，根证书 “GlobalSign Root CA” 早已经内置到系统内部了。

结语

使用密码学理论，客户端和服务器之间实现了信息的保密传输。密码学中对称加密、非对称加密和哈希函数在整个通讯创建的过程当中都发挥了做用，而且都缺一不可。密码学的理论知识已经成为安全通讯的理论基础。

如今 HTTPS 已经被普遍运用到各大网站中，它已经成为咱们平常中用到的技术，而咱们对此并无太大的感知。密码学提供了不少已经被咱们视为理所固然的工具，咱们使用的大多数安全通讯工具都仰仗于它。