HTTPS（理论）

文艺求关注.png

<h5>一 背景知识</h5>

1.基本术语 HTTP|HTTPS|SSL|TLS
2.HTTP和TCP的关系，如长连接和短连接等
3.加密算法的大概知识（对称加密和非对称加密）
4.CA证书的用途

<h5>二 基本术语</h5>

<b>HTTP:</b>是一个专门用来传输web内容的协议。

• 版本历史：
  <b>1）</b>0.9 90年代推出时候为0.9版本
  <b>2）</b>1.0 之后推出了1.0版本 该版本曾被广泛应用过
  <b>3）</b>1.1 这个 1.1 版本是1995年底开始起草的（技术文档是 RFC2068），并在1999年正式发布（技术文档是 RFC2616）
  <b>4）</b>2.0 2015年发布

<b>SSL:</b>是Secure Sockets Layer的缩写，翻译成中文叫做安全套接字层

• 上世界90年代由网景公司设计（该公司还发明了"!!!，js脚本等）
• HTTP协议在传输数据的时候是明文传输的，可能存在数据泄露（被嗅探）和篡改的问题。
• 而SSL协议就是为了解决上述问题而提出的。到了1999年，SSL 因为应用广泛，已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化之后的名称改为 TLS（是“Transport Layer Security”的缩写），中文叫做“传输层安全协议”。所以，SSL和TLS可以视作同一个东西的不同阶段。

<b>HTTPS:</b>即 HTTP + SSL

<h5>三 HTTP和TCP的关系</h5>

<b>1）HTTP协议和TCP协议</b>

• TCP协议是HTTP协议的基石，即HTTP协议需要依靠TCP协议来传输数据。
• HTTP是应用层协议之一。
• TCP是传输层协议之一。
• 有很多应用层的协议（如HTTP|SMTP等）都以TCP协议为基础来进行数据传输。
• 传输层协议主要有TCP和UDP两种，区别在于TCP协议是可靠的。

<b>2）短连接和长连接</b>

• HTTP 对TCP连接的使用，分为两种方式：俗称“短连接”和“长连接”（“长连接”又称“持久连接”，英文为“Keep-Alive”或“Persistent Connection”）

<b>3）HTTP各个版本中TCP的连接方式</b>

• 假设有一个网页，里面包含好多图片，还包含好多【外部的】CSS 文件和 JS 文件。在“短连接”的模式下，浏览器会先发起一个 TCP 连接，拿到该网页的 HTML 源代码（拿到 HTML 之后，这个 TCP 连接就关闭了）。然后，浏览器开始分析这个网页的源码，知道这个页面包含很多外部资源（图片、CSS、JS）。然后针对【每一个】外部资源，再分别发起一个个 TCP 连接，把这些文件获取到本地（同样的，每抓取一个外部资源后，相应的 TCP 就断开）
• 相反，如果是“长连接”的方式，浏览器也会先发起一个 TCP 连接去抓取页面。但是抓取页面之后，该 TCP 连接并不会立即关闭，而是暂时先保持着（所谓的“Keep-Alive”）。然后浏览器分析 HTML 源码之后，发现有很多外部资源，就用刚才那个 TCP 连接去抓取此页面的外部资源。
  HTTP1.0 版本默认使用短连接，也叫作一次性连接。因为那个时候网页简单。
  HTTP1.1 版本中默认使用长连接，因为此时网页已经变得足够复杂，如果继续使用短连接的方式效率太低（因为建立TCP连接需要时间和CPU成本）

<h5>四 加密和解密</h5>

• 加密：给你一个明文，可以通过一定的加密算法得到一串密文的过程。明文————>密文
• 解密：给你一个密文，可以通过对应的解密算法得到初始原文的过程。密文————>明文
• 对称加密：加密和解密使用相同的密钥。"速度快|效率高|存在密钥传输安全的问题"
• 非对称加密：加密和解密使用不同的密钥。拥有一个公钥一个私钥，使用公钥进行加密使用私钥来进行解密。"速度慢|安全性强"
  对称加密和非对称加密的特点也影响到了SSL协议的设计。

<h5>五 HTTPS协议为什么要设计成这样？（WHY）</h5>

<b>1）兼容性问题</b>

• 比如：①已有的web应用应该尽可能无缝的迁移到HTTPS，最好是做到零成本。②浏览器厂家改动应该尽可能的小
  • ①"HTTPS协议还是基于TCP来进行传输"
  • ②"把HTTP协议包裹起来成为一个新的协议"
  • ③好比以前的HTTP协议是塑料水管容易戳破，现在就在以前塑料水管的基础上再包上一层金属管。这样就可以做到，原有的管道能够照常运行，且不再容易被戳破。

<b>2）可扩展性</b>

• SSL/TLS 可以跟很多常用的应用层协议（比如：FTP、SMTP、POP、Telnet）搭配，来强化这些应用层协议的安全性
• 如果把SSL看成是一层金属管，那么他不仅能够对输水管道进行加固，而且也能对输电管道，输煤气管道进行加固。

<b>3）保密性</b>

• 说白了以前是透明的塑料管道，随便花点功夫就能够知道传输的内容，而现在能够做到足够好的保密性。

<b>4）完整性</b>

• 能够确保HTTP协议的内容不被修改。
• 因为你的网络流量需要经过 ISP 的线路才能到达公网。如果你使用的是明文的 HTTP，ISP 很容易就可以在你访问的页面中植入广告

<b> 5）真实性</b>
HTTPS 协议必须有某种机制来确保“真实性”的需求。
如何确定我们访问的网站是真实的，关于这一点仅仅根据域名来判断是不靠谱的。因为我们的DNS系统本身就是不可靠的（域名欺骗和域名劫持），所以我们看到的网址里面的域名未必是真实的。

<b> 6）性能</b>

• 使用HTTPS的时候性能不能太差，因此在设计的时候需要考虑两个问题：
  ① 加密和解密采用什么样的方式来进行：对称加密还是非对称加密？
  ② 采用什么样的连接方式：短连接还是长连接

<h5>六 设计HTTPS协议的难点</h5>

个人认为最难的地方在于对传输数据进行加密和解密这一块，也就是密钥交换。
如果客户端和服务器端需要进行HTTPS通信，那么首先需要协商双方应该采用什么样的加密算法，确定了加密算法之后还需要传输加密和解密中可能涉及到的密钥，而此时尚处于握手阶段，所有的数据传输都还是明文的，那么应该如何安全的传输密钥成为最大的问题。

<h5>七 解决密钥安全传输的问题</h5>

<b>1）单独使用对称加密来传输</b>

• 完全使用对称加密来传输不具备可行性，因为如果要使用对称加密，那么浏览器和客户端之间势必需要先交换对称加密的密钥。
• 如果这个密钥直接用明文来传输，则很有可能会被攻击者偷窥到。

<b>2）使用非对称加密来传输 效率太低</b>
<b>3）使用非对称加密+对称加密：</b>

• 存在中间人攻击隐患（需要具备篡改通信数据的能力）[伪造公钥][MITM]

<b>4）正是因为"缺乏身份认证机制"，所以我们需要考虑身份认证的问题。</b>

<h5>八 身份认证的几种方式</h5>

1) 基于某些私密共享的信息 |前提——通信双方认识彼此熟悉
2）基于双方都信任的公证人 |如果通信双方都不认识彼此，那么就只能采用该模式（如C2C）
   那么，谁来充当这个公证人呢？"CA"华丽登场

如何解决SSL的身份认证问题：使用CA
CA数字证书在技术实现上依赖于非对称加密技术

<h5>维基百科中对HTTPS的定义</h5>

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

扩充知识：
网景（英语：Netscape）是一个自1994年开始的品牌。"1994年4月4"日它最初成立的名字是'马赛克通信公司'。该公司有一款名称为"网景导航者"的浏览器，因此"网景"也是是网景通信公司（Netscape Communications Corporation）的常用简称。网景通信公司曾经是一家美国的电脑服务公司，以其生产的同名网页浏览器而闻名。1998年11月，网景被美国在线（AOL）收购，2003年7月网景被解散，网景大部分的程序员被解雇，2008年3月1日美国在线宣布停止对网景浏览器的技术支持。

网景公司（Netscape）在1994年推出首版网页浏览器，网景导航者时，推出HTTPS协议，以SSL进行加密，这是SSL的起源。IETF将SSL进行标准化，1999年公布了第一版TLS标准文件

IETF:互联网工程任务小组（英语：Internet Engineering Task Force，缩写为 IETF）负责互联网标准的开发和推动.

该网站提供免费的安全证书：https://letsencrypt.org

SSL协议握手的过程：
通过握手，客户端和服务器协商各种参数用于创建安全连接：

• ① 当客户端连接到支持TLS协议的服务器要求创建安全连接并列出了受支持的密码组合（加密密码算法和加密哈希函数），握手开始。

• ② 服务器从该列表中决定加密和散列函数，并通知客户端。

• ③ 服务器发回其数字证书，此证书通常包含服务器的名称、受信任的证书颁发机构（CA）和服务器的公钥。

• ④ 客户端确认其颁发的证书的有效性。

• ⑤ 为了生成会话密钥用于安全连接，客户端使用服务器的公钥加密随机生成的密钥，并将其发送到服务器，只有服务器才能使用自己的私钥解密。

• ⑥ 利用随机数，双方生成用于加密和解密的对称密钥。

  以上就是TLS协议的握手，握手完毕后的连接是安全的，直到连接（被）关闭。如果上述任何一个步骤失败，TLS握手过程就会失败，并且断开所有的连接。
  

TLS 1.2在 RFC 5246 中定义，于2008年8月发表。它基于更早的TLS 1.1规范。

• 主要区别包括：
  • ① 可使用密码组合选项指定伪随机函数使用SHA-256替换MD5-SHA-1组合。
  • ② 可使用密码组合选项指定在完成消息的哈希认证中使用SHA-256替换MD5-SHA-1算法，但完成消息中哈希值的长度仍然被截断为96位。
  • ③ 在握手期间MD5-SHA-1组合的数字签名被替换为使用单一Hash方法，默认为SHA-1。
  • ④ 增强服务器和客户端指定Hash和签名算法的能力。
  • ⑤ 扩大经过身份验证的加密密码，主要用于GCM和CCM模式的AES加密的支
  • ⑥ 添加TLS扩展定义和AES密码组合。
  • ⑦ 所有TLS版本在2011年3月发布的RFC 6176中删除了对SSL的兼容，这样TLS会话将永远无法协商使用SSL 2.0以避免安全问题。

//HTTPS协议中关于SSL/TLS层握手过程的说明

<b>阶段一：协商加密方式等参数</b>

• 客户端

  • ① 我想要和你[服务端]进行安全的通话，我这里的支持的对称加密算法有DES|AES|RC5,密钥交换算法有RSA和DH,消息摘要算法有MD5和SHA1|SHA256
  • ② [我说完了]

• 服务端

  • ① 我们使用AES-RSA-SHA256的组合方式吧。
    -② 服务器端证书发送给客户端，并说[这是我的证书，里面有我的信息和公钥，你拿去验证一下我的身份吧]。
    -③ [我说完了]
    "——————该阶段双方已经协商好了加密[AES]_会话密钥交换[RSA]消息校验[SHA256]的一套方法。

<b>阶段二：验证证书的有效性并交换会话密钥</b>

• 客户端

  • ① 检查证书上面的信息，并通过已有的CA证书验证服务器端证书的真实性，如果有误则发出警告并断开连接。
  • ② 客户端从接收到的证书中提取出公钥
  • ③ 生成随机数作为会话密钥，即session key,该密钥将被在建立安全通道后用作对称加密的密钥。
  • ④ 使用提取出来的公钥加密之前生成的会话密钥，封装成一个ClientKeyExchange消息[其实就是使用公钥对会话密钥进行加密之后的密文]。
  • ⑤ 以后我就要使用session key对消息进行加密来和你进行通信了！
  • ⑥ [我说完了]

• 服务端

  • ① 使用自己的私钥对收到ClientKeyExchange消息进行解密，得到会话密钥，即session key。
    "【注】该消息由客户端使用服务器端发送给其的公钥进行加密，所以服务器端可以使用私钥来解密。</br>
  • ② 使用会话密钥加密初始化向量
  • ③ 加密HMAC的密钥
  • ④ 以后我也要使用session key对消息进行加密来和你进行通信了！
  • ⑤ [我说完了]
    "——————该阶段完成会话密钥session key的安全交换。

<b>阶段三：使用会话密钥加密消息，所有的消息在安全的信道中传输</b>

• 客户端

  • ① 要发送给服务端的消息是CMsg:我的小秘密是....
  • ② 使用会话秘钥对CMsg进行对称加密得到密文CMsg1:xxxxxooooooo
  • ③ 把CMsg1发送给服务器端

• 服务端

  • ① 接收到客户端发送来的消息CMsg1:xxxxxooooooo

  • ② 使用本地的私钥对收到的消息Msg1进行解密，得到原文为CMsg:我的小秘密是....

  • ③ 对客户端的消息进行响应，要发送给客户端的消息为SMsg:其它人不会听到的，我也有个小秘密...

  • ④ 使用会话密钥对SMsg进行对称加密得到密文SMsg1:oooooxxxxxxx

  • ⑤ 把SMsg1发送给客户端

    "——————该阶段在传输之前使用会话密钥对所有的消息进行对称加密处理。
    

关注一下又不会怀孕.png