学计算机的那个

不是我觉到、悟到，你给不了我，给了也拿不住;只有我觉到、悟到，才有可能做到，能做到的才是我的.

0%

HTTPS协议

发表于 更新于 分类于

HTTP 主要有这些不足，例举如下

  1. 通信使用明文(不加密)，内容可能会被窃听
  2. 不验证通信方的身份，因此有可能遭遇伪装
  3. 无法证明报文的完整性，所以有可能已遭篡改

通讯加密

HTTP 协议中没有加密机制，但可以通过和 SSL(Secure Socket Layer，安全套接层)或 TLS(Transport Layer Security，安全层传输协议)的组合使用， 加密 HTTP 的通信内容。用 SSL 建立安全通信线路之后，就可以在这条线路上进行HTTP 通信了。与 SSL 组合使用的 HTTP 被称为 HTTPS(HTTP Secure，超文本传输安全协议)或 HTTP over SSL

验证通信方身份

使用证书，以证明通信方就是意料中的服务器。另外，客户端持有证书即可完成个人身份的确认，也可用于对 Web 网站的认证环节

加密方式

对称加密

对称加密：指的就是加、解密使用的同是一串密钥，所以被称做对称加密。对称加密只有一个密钥作为私钥。
常见的对称加密算法：DES，AES等。

优缺点：加解密的效率要高得多、加密速度快。但是缺陷在于对于密钥的管理和分发上比较困难，不是非常安全，密钥管理负担很重。

非对称加密

非对称加密：指的是加、解密使用不同的密钥，一把作为公开的公钥，另一把作为私钥。公钥加密的信息，只有私钥才能解密。反之，私钥加密的信息，只有公钥才能解密。

见的非对称加密算法：RSA

优缺点：

安全性更高，公钥是公开的，密钥是自己保存的，不需要将私钥给别人。缺点：加密和解密花费时间长、速度慢，只适合对少量数据进行加密。

举例：假设A要发送一封Email给B，他不想让任何其他人在传输中看到Email的内容，做法就是使用B的公钥对Email加密，只有B的私钥能够解密（B的私钥唯一性保证信件不会泄露）。
某天出意外了，有黑客冒充A给B发送Email，并且也用B的公钥加密，导致B无法区分这封邮件是否来自A。怎么办？此时A可以用自己的私钥加密，那么B收到邮件后如果用A的公钥可以解密邮件，那么证明这封信肯定来自于A

公钥的作用：对内容本身加密，保证不被其他人看到。
私钥的作用：证明内容的来源

数字签名

上面发邮件的例子，A用自己的私钥对Email加密发送，这存在下面问题
对文件本身加密可能是个耗时过程，比如这封Email足够大，那么私钥加密整个文件以及拿到文件后的解密无疑是巨大的开销。

数字签名可以解决这个问题：
1.A先对这封Email执行哈希运算得到hash值简称“摘要”，取名h1
2.然后用自己私钥对摘要加密，生成的东西叫“数字签名”
3.把数字签名加在Email正文后面，一起发送给B
4.B收到邮件后用A的公钥对数字签名解密，成功则代表Email确实来自A，失败说明有人冒充
5.B对邮件正文执行哈希运算得到hash值，取名h2
6.B 会对比第4步数字签名的hash值h1和自己运算得到的h2，一致则说明邮件未被篡改。

数字签名的作用就是验证数据来源以及数据完整性！解密过程则称为数字签名验证

数字签名流程有两个问题：

  1. 如果中间人同时篡改了Email正文和数字签名，那B收到邮件无法察觉啊。
    答案：数字签名的生成需要对方私钥，所以数字签名很难被伪造。万一私钥泄漏了呢，不好意思，你私钥都能弄丢了那这篇文章当我白写。（私钥绝对保密不参与传输）

  2. 公钥是公开的并且可以自行导入到电脑，如果有人比如C偷偷在B的电脑用自己公钥替换了A的公钥，然后用自己的私钥给B发送Email，这时B收到邮件其实是被C冒充的但是他无法察觉。
    答案：确实存在这种情况！解决办法就是数字证书，一环套一环请接着看。

数字证书

数字证书如何生成？

  1. 首先A去找”证书中心”（certificate authority，简称CA），为公钥做认证。证书中心用自己的私钥，对A的公钥和一些相关信息一起加密，生成”数字证书”（Digital Certificate）
  1. A在邮件正文下方除了数字签名，另外加上这张数字证书
  1. B收到Email后用CA的公钥解密这份数字证书，拿到A的公钥，然后验证数字签名，后面流程就和图1的流程一样了，不再赘述。

问题：

  1. 假设数字证书被伪造了呢？
    传输中数字证书有可能被篡改。因此数字证书也是经过数字签名的，上文说道数字签名的作用就是验证数据来源以及数据完整性！B收到邮件后可以先验证这份数字证书的可靠性，通过后再验证数字签名。

  2. 要是有1万个人要给B发邮件，难道B要保存1万份不同的CA公钥吗？
    不需要，CA认证中心给可以给B一份“根证书”，里面存储CA公钥来验证所有CA分中心颁发的数字证书。

  3. 证书验证的过程依赖于证书信任链。

所谓证书信任链，即一个证书要依靠上一级证书来证明自己是可信的，最顶层的证书被称为根证书，拥有根证书的机构被称为根 CA。

以 Github 为例，在浏览器中我们可以看到它的证书信任链如下：

1
2
DigiCert High Assurance EV Root CA -> DigiCert SHA2 
Extended Validation Server CA -> Github.com

从上到下即 Root CA -> 二级 CA -> 网站。

  1. 如何验证根证书可靠性？
    无法验证。根证书是自验证证书，CA机构是获得社会绝对认可和有绝对权威的第三方机构，这一点保证了根证书的绝对可靠。

HTTP+ 加密 + 认证 + 完整性保护 = HTTPS

HTTPS 并非是应用层的一种新协议。只是HTTP通信接口部分用 SSL(Secure Socket Layer)和 TLS(Transport Layer Security)协议代 替而已。

HTTP 直接和 TCP 通信。当使用 SSL 时，则演变成先和 SSL 通 信，再由 SSL 和 TCP通信了。简言之，所谓 HTTPS，其实就是身披 SSL 协议这层外壳的 HTTP

SSL 是独立于 HTTP 的协议,是 当今世界上应用最为广泛的网络安全技术

HTTPS连接过程

HTTPS 连接的建立流程是怎样的?

会话秘钥 = random S + random C + 预主秘钥

  • TLS 四次握手
  1. 第一步，客户端向服务器发起请求，请求种包括使用的协议版本号，生成的一个随机数C、以及客户端支持的加密方法。
  2. 第二部，服务端收到请求后，确认双方使用的加密方法、并给出服务器的证书、以及一个服务器生成的随机数S
  3. 第三部，客户端确认服务器证书有效后，生成一个新的随机数（预主密钥），并使用数字证书中的公钥，加密这个随机数，然后发给服务器。并且还会提供一个前面所有内容的hash的值，用来供服务器检验。
  4. 服务器使用自己的私钥，来解密客户端发送过来的随机数。并提供前面所有内容的hash值来供客户端检验。这个时候双方都有了三个随机数，按照之前约定的加密方法，使用这三个随机数生成对话密钥，以后的对话过程都使用这个密钥来加密信息。

  • 为什么一定要用三个随机数，来生成“会话密钥”？
    客户端和服务端都需要生成随机数，以此来保证每次生成的密钥都不相同，使用三个随机数，是因为SSL的协议默认不信任每个主机都能产生完全随机的数。三个伪随机数就很接近于随机了，因此可以使用这种方法来保持生成密钥的随机性和安全性。

  • SSL连接断开后如何恢复？
    一共有两种方法来恢复断开的SSL连接，一种是session ID，一种是session ticket。

  1. 使用session ID
    每一次的会话都有一个编号，当对话中断后，下一次重新连接时，只要客户端给出这个编号，服务器如果有这个编号，那么双方就可以继续使用以前的密钥，而不用重新生成一把。
    缺点：session ID只能够存在一台服务器上，如果我们的请求通过负载均衡被转移到其他的服务器上，那么就无法恢复对话。
  2. 使用session ticket
    session ticket是服务器在上一次对话中发送给客户的，这个ticket是加密的，只有服务器能解密，里面包含了本次会话的信息，比如对话密钥和加密算法等。这样不管我们的请求是否转移到其他的服务器上，当服务器将ticket解密以后，就能够获取上次对话的信息，就不用生成新的对话密钥。

HTTPS都使用了哪些加密手段?

在交换密钥环节（连接建立过程中）使用公开密钥加密方式（非对称加密），之后的建立通信交换报文阶段（通信过程中）则使用共享密钥加密方式（对称加密）。

如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥？

使用由数字证书认证机构(CA，Certificate Authority)和其相关机关颁发的公开密钥证书。

数字证书认证机构在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书 后绑定在一起。

服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端，以进行公开密钥加密方式通信。公钥证书也可叫做数字证书或直接称为证书。

接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确两件事: 一，认证服务器的公开密钥的是真实有效的数字证书认证机构。二， 服务器的公开密钥是值得信赖的。

认证机关的公开密钥必须安全地转交给客户端。使用通信方式 时，如何安全转交是一件很困难的事，因此，多数浏览器开发商发布 版本时，会事先在内部植入常用认证机关的公开密钥

证书的一个作用是用来证明作为通信一方的服务器是否规范，另 外一个作用是可确认对方服务器背后运营的企业是否真实存在

SSL剥离

SSL 剥离即阻止用户使用 HTTPS 访问网站。由于并不是所有网站都只支持 HTTPS，大部分网站会同时支持 HTTP 和 HTTPS 两种协议。用户在访问网站时，也可能会在地址栏中输入 http:// 的地址，第一次的访问完全是明文的，这就给了攻击者可乘之机。通过攻击 DNS 响应，攻击者可以将自己变成中间人。

DNS 作为基于 UDP 的协议是相当不安全的，为了保证 DNS 的安全可以使用 DNS over TCP 等机制

解决：HSTS（HTTP Strict Transport Security）用于强制浏览器使用 HTTPS 访问网站的一种机制

伪造证书攻击

即使在全程使用 HTTPS 的情况下，我们仍然有可能被监听

假设我们想访问 www.google.com，但我们的 DNS 服务器被攻击了，指向的 IP 地址并非 Google 的服务器，而是攻击者的 IP。当攻击者的服务器也有合法的证书的时候，我们的浏览器就会认为对方是 Google 服务器，从而信任对方。这样，攻击者便可以监听我们和谷歌之前的所有通信了

击者有两步需要操作，第一步是需要攻击 DNS 服务器。第二步是攻击者自己的证书需要被用户信任，这一步对于用户来说是很难控制的，需要证书颁发机构能够控制自己不滥发证书

解决：HPKP（Public Key Pinning Extension for HTTP）在 HSTS 上更进一步，HPKP 直接在返回头中存储服务器的公钥指纹信息，一旦发现指纹和实际接受到的公钥有差异，浏览器就可以认为正在被攻击

参考

1.通俗理解数字签名，数字证书和https