search

hackfengJam / hackfun.github.io

2 stars 0 forks source link

HTTPS 如何做到安全 #4

Open hackfengJam opened 5 years ago

hackfengJam commented 5 years ago

HTTPS 如何做到安全

前言

本文介绍 HTTPS 如何做到安全，所有相关名词解释均来自 维基百科，后续引用就不在每次赘述了。

目录

1. 背景

2. 什么是HTTPS

3. 对称加密与非对称加密

4. CA 证书机制

5. HTTPS 过程详解

6. 总结

1. 背景

HTTP 的 URL 是由 “http://” 起始与默认使用 端口 80，而 HTTPS 的 URL 则是由 “https://” 起始与默认使用 端口 443。

HTTP 不是安全的，而且攻击者可以通过 嗅探 和 中间人攻击 等手段，获取网站帐户和敏感信息等。
HTTPS 的设计可以防止前述攻击，在正确配置时是安全的。

那么 HTTPS 为什么安全呢，密码学保证？证书又是什么？

2. 什么是HTTPS

2.1 HTTPS 简介

引自 Wiki：

超文本传输安全协议（英语：HyperText Transfer Protocol Secure，缩写：HTTPS； 常称为HTTP over TLS、HTTP over SSL或HTTP Secure）是一种通过计算机网络进行安全通信的传输协议。 HTTPS经由HTTP进行通信，但利用SSL/TLS来加密数据包。 HTTPS开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。 这个协议由网景公司（Netscape）在1994年首次提出，随后扩展到互联网上。

2.2 HTTP 和 HTTPS

    HTTP               HTTPS

+------------+      +-----------+
|            |      |   HTTP    |
|    HTTP    |      |           |
|            |      +-----------+
+------------+      |SSL or TLS |
|            |      |           |
|    TCP     |      +-----------+
|            |      |    TCP    |
+------------+      |           |
|            |      +-----------+
|     IP     |      |    IP     |
|            |      |           |
+------------+      +-----------+

3. 对称加密与非对称加密

3.1 加密解密

展开 如果任何人使用公钥加密明文，得到的密文可以透过不安全的途径（如网络）发送，只有对应的私钥持有者才可以解密得到明文； 其他人即使从网络上窃取到密文及加密公钥，也无法（在数以年计的合理时间内）解密得出明文。 典型例子是在网络银行或购物网站上，因为客户需要输入敏感消息，浏览器连接时使用网站服务器提供的公钥加密并上传数据， 可保证只有信任的网站服务器才能解密得知消息，不必担心敏感个人信息因为在网络上传送而被窃取。

3.2 对称密钥加密

展开 [对称密钥算法](https://zh.wikipedia.org/wiki/%E5%B0%8D%E7%A8%B1%E5%AF%86%E9%91%B0%E5%8A%A0%E5%AF%86)（英语：Symmetric-key algorithm）又称为对称加密、私钥加密、共享密钥加密，是密码学中的一类加密算法。 这类算法在加密和解密时使用相同的密钥，或是使用两个可以简单地相互推算的密钥。 事实上，这组密钥成为在两个或多个成员间的共同秘密，以便维持专属的通信联系。 与公开密钥加密相比，要求双方获取相同的密钥是对称密钥加密的主要缺点之一。 常见的对称加密算法有 DES、3DES、AES、Blowfish、IDEA、RC5、RC6。 对称加密的速度比公钥加密快很多，在很多场合都需要对称加密。

3.3 公开密钥密码学

展开 [公开密钥密码学](https://zh.wikipedia.org/wiki/%E5%85%AC%E5%BC%80%E5%AF%86%E9%92%A5%E5%8A%A0%E5%AF%86)（英语：Public-key cryptography，也称非对称式密码学）是密码学的一种算法， 它需要两个密钥，一个是公开密钥，另一个是私有密钥；一个用作加密，另一个则用作解密。 使用其中一个密钥把明文加密后所得的密文，只能用相对应的另一个密钥才能解密得到原本的明文； 甚至连最初用来加密的密钥也不能用作解密。由于加密和解密需要两个不同的密钥，故被称为非对称加密； 不同于加密和解密都使用同一个密钥的对称加密。 虽然两个密钥在数学上相关，但如果知道了其中一个，并不能凭此计算出另外一个； 因此其中一个可以公开，称为公钥，任意向外发布； 不公开的密钥为私钥，必须由用户自行严格秘密保管，绝不透过任何途径向任何人提供，也不会透露给被信任的要通信的另一方。 基于公开密钥加密的特性，它还提供数字签名的功能，使电子文件可以得到如同在纸本文件上亲笔签署的效果。 公开密钥基础建设透过信任数字证书认证机构的根证书、及其使用公开密钥加密作数字签名核发的公开密钥认证，形成信任链架构， 已在TLS实现并在万维网的HTTP以HTTPS、在电子邮件的SMTP以STARTTLS引入。 另一方面，信任网络则采用去中心化的概念，取代了依赖数字证书认证机构的公钥基础设施， 因为每一张电子证书在信任链中最终只由一个根证书授权信任，信任网络的公钥则可以累积多个用户的信任。 PGP就是其中一个例子。

3.4 对称加密与非对称加密

展开 在现实世界上可作比拟的例子是，一个传统保管箱，开门和关门都是使用同一条钥匙，这是对称加密； 而一个公开的邮箱，投递口是任何人都可以寄信进去的，这可视为公钥；而只有信箱主人拥有钥匙可以打开信箱，这就视为私钥。

4. CA 证书机制

4.1 CA

数字证书认证机构（英语：Certificate Authority，缩写为CA），也称为电子商务认证中心、电子商务认证授权机构， 是负责发放和管理数字证书的权威机构，并作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。

4.2 CA 证书

展开 证书实际是由证书签证机关（CA）签发的对用户的公钥的认证。 证书的内容包括：电子签证机关的信息、公钥用户信息、公钥、权威机构的签字和有效期等等。 当前，证书的格式和验证方法普遍遵循 [X.509](https://zh.wikipedia.org/wiki/X.509) 国际标准。 　　 - 加密：ca认证将文字转换成不能直接阅读的形式（即密文）的过程称为加密。 - 解密：将密文转换成能够直接阅读的文字（即明文）的过程称为解密。 如打算在电子文档上实现签名的目的，可使用数字签名。RSA公钥体制可实现对数字信息的数字签名，方法如下： 信息发送者用其私钥对从所传报文中提取出的特征数据（或称数字指纹）进行RSA算法操作，以保证发信人无法抵赖曾发过该信息（即不可抵赖性），同时也确保信息报文在传递过程中未被篡改（即完整性）。当信息接收者收到报文后，就可以用发送者的公钥对数字签名进行验证。 在数字签名中有重要作用的数字指纹是通过一类特殊的散列函数（HASH函数）生成的。对这些HASH函数的特殊要求是： 1. 接受的输入报文数据没有长度限制； 2. 对任何输入报文数据生成固定长度的摘要（数字指纹）输出； 3. 从报文能方便地算出摘要； 4. 难以对指定的摘要生成一个报文，而由该报文可以算出该指定的摘要； 5. 两个不同的报文难以生成具有相同的摘要。

4.3 证书间信任关系

用一个证书来证明另一个证书是可信的，例如 C 机构公章和 A 机构公章在同一张介绍信上，注明公章 C 信任公章 A，A 也是可信的。

4.4 证书信任链

简单说，信任关系是可以传递的，只要你信任头一个证书，后续的证书都是可以信任的。

C 信任 A，A 信任 A1，A1 信任 A2，A、A1、A2 都是可信任的。

4.5 根证书

展开 在密码学和计算机安全领域，[根证书](https://zh.wikipedia.org/wiki/%E6%A0%B9%E8%AF%81%E4%B9%A6)（root certificate）是属于根证书颁发机构（CA）的公钥证书，是在公开密钥基础建设中，[信任链](https://zh.wikipedia.org/wiki/%E4%BF%A1%E4%BB%BB%E9%8F%88)的起点。 在证书的信任链中，A1 可以由 A 证明可信任，A 由 C 证明可信任，C 由谁证明可信任呢？ C 不需要证明自己是可信任的，因为它是权威机构，这就是根证书（处于树结构的顶端）。 由于根证书在信任链中的重要角色，一旦证书机构的私钥外泄，将可能导致整个信任链被摧毁，影响广及众多客户， 所以认证机构会使用各种方法保护根证书，例如[硬件安全模块](https://zh.wikipedia.org/wiki/%E7%A1%AC%E4%BB%B6%E5%AE%89%E5%85%A8%E6%A8%A1%E5%9D%97)。

4.6 证书在 HTTPS 中作用

防止 浏览器 与 服务端 数据传输时被 中间人攻击，

若暂不理解 HTTPS 为什么需要 证书机制，请先看下文 HTTPS 过程详解。

5. HTTPS 过程详解

服务端和浏览器之间要实现安全的密钥交换该如何实现？

5.1 方案一：使用对称加密算法

如果单纯使用对象加密算法，服务端与浏览器必须要交换密钥，密钥直接用明文传输很容易被窃取，无法保证密钥的安全性。

5.2 方案二：使用非对称加密算法

  1. 服务端 基于非对称加密算法随机生成一堆密钥对 x,y，目前算很安全，只有服务端知道

  2. 服务端把 x 留在本地，把 y 用明文传输到 浏览器（y可能被窃取）

  3. 浏览器拿到 y 后，先随机生成第三个对称加密的密钥 z，然后用 y 加密 z 得到最新的 f （本质上就是用非对称加密 保证 对称加密的安全性），将 f 发送到 服务端（因为 x, y 是成对的， 只用 x 才能解密 y 加密的结果，所以 y 泄露也无法解密 k）

  4. 服务端 拿到 f 之后，用 x 解密得到 z，至此 浏览器 和 服务端 都有对称加密的密钥 z，可以进行通信加密。

5.3 思考，是否有方案三呢？

思考一下，方案二 是否 安全 和 完美？

实际上，方案二可以在一定程度上防止 嗅探，但无法防范 网络数据修改（中间人攻击）。 在 服务端 和 浏览器 交换密钥的过程中，中间人接收网站发送的 密钥 y 保存下来，改用自己生成的密钥； 伪造成 服务端 与 浏览器 交互，同时使用密钥 y 伪造成 浏览器 与 服务端交互。

方案二 不安全的根源是缺乏可靠的身份认证，浏览器 无法鉴别自己受到的密钥是不是来自 真正的 服务端。

因此需要引入 CA证书机制（身份认证），基于 CA证书 进行密钥交换（具体 CA机制可查看介绍 CA相关文章）。

此时得到方案三。

5.4 方案三

  1. 服务端 首先花钱从 权威CA 机构购买一个数字证书，证书通常包含一个私钥和一个公钥证书文件

  2. 浏览器 访问 服务端 时将公钥证书文件发送给 浏览器

  3. 浏览器 验证收到的证书（权威机构担保真假，主流 浏览器 和 操作系统 都会内置权威 CA机构 的根证书）

  4. 如果证书科学，就随机生成一个对称加密密钥 k，使用公钥加密 k，得到密钥 c

  5. 将密钥 c 发送给 服务端，服务端 根据私钥解密出 密钥 k，至此密钥交换完成。

这就是 HTTPS 加密传输的过程。

6. 总结

感谢

hackfengJam commented 5 years ago

Toc 好像不管用 - -|||，原文地址：在这里