http 和 https
HTTP: 超文本传输协议 (英文: HyperText Transfer Protocol, 缩写: HTTP) 是一种用于分布式, 协作式和超媒体信息系统的应用层协议. HTTP 是万维网的数据通信的基础. 设计 HTTP 最初的目的是为了提供一种发布和接收 html 页面的方法. 通过 HTTP 或者 HTTPS 协议请求的资源由统一资源标识符 (Uniform Resource Identifiers,URI) 来标识.
简单来说, HTTP 是一种超文本传输协议, 它是无状态的, 简单快速的, 基于 TCP 的可靠传输协议.
HTTP 特点:
无状态: 协议对客户端没有状态存储, 对事物处理没有 "记忆" 能力, 比如访问一个网站需要反复进行登录操作.
无连接: HTTP/1.1 之前, 由于无状态特点, 每次请求需要通过 TCP 三次握手四次挥手, 和服务器重新建立连接. 比如某个客户机在短时间多次请求同一个资源, 服务器并不能区别是否已经响应过用户的请求, 所以每次需要重新响应请求, 需要耗费不必要的时间和流量.
基于请求和响应: 基本的特性, 由客户端发起请求, 服务端响应.
简单快速, 灵活.
通信使用明文, 请求和响应不会对通信方进行确认, 无法保护数据的完整性.
在 HTTP/2 出现之后, HTTP 的传输效率得到了巨大提升, 这归功于其多路复用技术. 然而, HTTP 协议这么好, 那怎么又冒出来了一个 HTTPS 呢?
主要是因为 HTTP 是明文传输的, 这就造成了很大的安全隐患. 在网络传输过程中, 只要数据包被人劫持, 那你就相当于赤身全裸的暴露在他人面前, 毫无半点隐私可言. 想象一下, 如果你连了一个不可信的 Wi-Fi, 正好有使用了某个支付软件进行了支付操作, 那么你的密码可能就到别人手里去了, 后果可想而知.
随着互联网的发展和普及, 网络安全问题越发引入注意, HTTPS 便应运而生.
HTTPS: 超文本传输安全协议 (英语: Hypertext Transfer Protocol Secure, 缩写: HTTPS, 常称为 HTTP over TLS,HTTP over SSL 或 HTTP Secure) 是一种通过计算机网络进行安全通信的传输协议. HTTPS 经由 HTTP 进行通信, 但利用 SSL/TLS 来加密数据包. HTTPS 开发的主要目的, 是提供对网站服务器的身份认证, 保护交换数据的隐私与完整性. 这个协议由网景公司 (Netscape) 在 1994 年首次提出, 随后扩展到互联网上.
简单来说, HTTPS 是身披 SSL 外壳的 HTTP, 它本质上还是 HTTP 协议, 使用 HTTPS 可以保护所有类型网站上的网页真实性, 保护账户和保持用户通信, 身份和网络浏览的私密性.
背景
从风险的角度来说, HTTPS 解决了 HTTP 的三个问题, 如下:
HTTP 三大风险:
窃听风险: 第三方可以获知通信内容.
篡改风险: 第三方可以修改通信内容.
冒充风险: 第三方可以冒充他人身份参与通信.
HTTPS 解决方案:
内容加密: 所有信息都是加密传播, 第三方无法窃听.
验证身份: 具有校验机制, 一旦被篡改, 通信双方会立刻发现.
保护数据完整性: 配备身份证书, 防止身份被冒充.
实现
上面讲了这么多, 大家应该对 HTTPS 有了一点了解了吧. 但是对于其本质, 以及如何保护数据安全的原理应该还是糊里糊涂的吧. 别急, 我们这就来了解一下神奇的 HTTPS 如何保障数据安全.
[注: HTTPS 并非绝对的安全, 但是它能很大程度上保护数据安全, 因为要破解 HTTPS 安全机制从而获取或者篡改数据需要花费大量的人力物力, 这对于那些居心不良的人来说是很不愿意做的事情]
由于 HTTPS 涉及到了一些术语, 在这里我先解释一下, 到时候方便理解.
对称加密: 即通信双方通过相同的密钥进行信息的加解密. 加解密速度快, 但是安全性较差, 如果其中一方泄露了密钥, 那加密过程就会被人破解.
非对称加密: 相比对称加密, 非对称加密算法需要两个密钥: 公开密钥 (publickey) 和私有密钥(privatekey). 公开密钥与私有密钥是一对, 如果用公开密钥对数据进行加密, 只有用对应的私有密钥才能解密; 如果用私有密钥对数据进行加密, 那么只有用对应的公开密钥才能解密. 因为加密和解密使用的是两个不同的密钥, 所以这种算法叫作非对称加密算法. 两把密钥分别由发送双发各自保管, 加解密过程需两把密钥共同完成. 安全性更高, 但同时计算量也比对称加密要大很多.
混合加密: 结合非对称加密和对称加密技术. 客户端使用对称加密生成密钥对传输数据进行加密, 然后使用非对称加密的公钥再对对称加密的密钥进行加密, 所以网络上传输的数据是被对称加密的密钥加密后的内容和用非对称加密的公钥加密后的对称加密的密钥, 因此即使被黑客截取, 由于没有非对称加密的私钥, 无法获取到加密明文的对称加密的密钥, 便无法获取到明文数据. [ps: 这里好绕呀╮(╯﹏╰)╭]
CA: 证书颁发机构 (Certificate Authority) 即颁发数字证书的机构. 是负责发放和管理数字证书的权威机构, 并作为电子商务交易中受信任的第三方, 承担公钥体系中公钥的合法性检验的责任. CA 中心为每个使用公开密匙的用户发放一个数字证书, 数字证书的作用是证明证书中列出的用户合法拥有证书中列出的公开密钥. CA 机构的数字签名使得攻击者不能伪造和篡改证书.
数字签名: CA 会对服务端的公钥和服务端信息用一个 Hash 算法生成一个消息摘要, 然后 CA 再用它的私钥对消息摘要加密, 形成签名, 这就是数字签名.[注: 使用 Hash 算法有个极好的特性, 只要输入数据有一点点变化, 那生成的消息摘要就会有巨变, 这样就可以防止别人修改原始内容]
数字证书: CA 将服务端的信息以及服务端的数字签名合并, 形成一个全新的东西, 叫做 "数字证书". 当服务端把它的证书发给其他人之后, 别人就用同样的 Hash 算法, 再次生成消息摘要, 然后用 CA 的公钥对数字签名解密, 得到 CA 创建的消息摘要, 两者一比, 就知道有没有人篡改了.[注: 在操作系统 / 浏览器中会内置一些顶层的 CA 的证书]
基础术语解释完毕之后, 我们来看看使用 HTTPS 的时候, 一些校验流程, 如下图:
客户端向服务端发送请求 https://xxx.com, 然后连接到服务端的 443 端口.
服务端传送证书给客户端 , 这个证书里面包含了很多信息, 如证书所有者的信息, 证书的颁发机构, 过期时间, 服务端的公钥, 第三方证书认证机构 (CA) 的签名, 服务端的域名信息等内容.
客户端解析证书 .
这部分工作是由客户端的 TLS 来完成的, 首先会验证公钥是否有效, 比如颁发机构, 过期时间等等, 如果发现异常, 则会弹出一个警告框, 提示证书存在问题. 如果证书没有问题, 那么就生成一个随即值 (对称加密的密钥), 然后用服务端的公钥(public key) 对该随机值进行加密.
传送加密信息给服务端 , 这部分传送的是用服务端的公钥加密后的密钥(上述所说的随机值), 目的就是让服务端得到这个密钥.
服务端用自己的私钥解密, 得到了客户端传过来的密钥, 之后开始使用对称密钥来加密解密数据, 就不用再使用公钥和私钥校验了.
整个流程大致如上面所说的. 另外有几个点再说一下.
1. 为什么要使用服务端的公钥来加密对称加密的密钥?
其实上面有说过, 服务端的公钥和私钥是一对的, 用公钥加密的内容必须使用私钥才能解密, 用私钥加密的内容必须使用公钥来解密. 公钥谁都能知道, 但是只有服务器知道私钥. 使用服务端的公钥来加密对称加密的密钥, 也就是说必须要使用服务器的私钥来解密, 而黑客等中间人他们是不可能知道服务端的私钥是什么的, 所以他们便无法解密得到用于加密数据的密钥, 自然而然没办法篡改数据的传输.
2. 如何保障证书安全传输? 如何保障服务器给客户端下发的公钥是真正的公钥?
这里面涉及到了证书的校验原理, 上面在解释术语的时候就有说到过校验过程, 这里贴一张图片出来看看, 会更加直观, 如图:
当服务端把它的证书发给其他人之后, 别人也对证书的信息内容用 CA 使用的 Hash 算法进行处理, 再次生成消息摘要, 然后用 CA 的公钥对数字签名解密, 得到 CA 创建的消息摘要, 两者一比, 就知道有没有人篡改了.
另外, 即便中间人虽然有权威机构的公钥, 能够解析证书内容并篡改, 但是篡改完成之后中间人需要将证书重新加密, 但是中间人没有权威机构的私钥, 无法加密, 强行加密只会导致客户端无法解密, 如果中间人强行乱修改证书, 就会导致证书内容和证书签名不匹配, 我们就能知道证书是不是被篡改了.
弊端
当然, 从其他角度来说, HTTPS 也具有其弊端, 毕竟没有什么东西是绝对完美的.
1. 网络耗时增加
使用 HTTP 的时候, 只需要完成 TCP 三次握手建立 TCP 连接就能够直接发送 HTTP 请求获取应用层数据, 此外在整个访问过程中也没有需要消耗计算资源的地方.
而 HTTPS 的访问过程, 相比 HTTP 要复杂很多.
对于用户来说, 一般发起的是 HTTP 请求. 举个例子, 比如说访问百度首页, 绝大部分用户不会手动输入 https://www.baidu.com 来访问 HTTPS, 对吧. 好, 那我们看看这里面有哪些地方会增加耗时的地方.
由于用户没有使用 HTTPS 请求, 服务端只能返回 302 强制浏览器跳转到 HTTPS, 这个时候就需要多话费一些时间, 而且浏览器处理 302 跳转也需要耗时.
通过 302 跳转到 HTTPS 服务器之后, 由于端口和服务器不同, 需要重新完成三次握手, 建立 TCP 连接. 这里也增加了耗时.
浏览器校验证书, 验证证书有效性, 服务器信息等过程也需要时间处理.
当然, 增加耗时的地方不止上面所列的三点, 比如说浏览器有可能更 CA 域名解析, 握手等情况. 但是, 我们能从上面这个粗糙的例子中知道, HTTPS 相对于 HTTP 的确会增加不少的网络耗时情况.
2. 计算耗时增加
浏览器校验证书, 数据加密等等以及服务器获取对称密匙, 解密数据等都需要耗费时间. 当数据量多的时候, 这对服务器 CPU 的计算能力也提出来很高的要求.
3. 价格昂贵
SSL 证书需要购买申请, 功能越强大的证书费用越高.[注: 这个是导致 HTTPS 普及率低的很重要原因, 因为对于个人来说实在是太贵了. 但是目前网上也有一些可以申请免费 SSL 证书的机构, 但是限制比较多.]
前景
这些年谷歌一直力推 HTTPS 协议, 对 Chrome 的用户界面做出了一些改变. 2017 年 1 月发布的 Chrome 56 浏览器开始把收集密码或信用卡数据的 HTTP 页面标记为 "不安全". 若用户使用 2017 年 10 月推出的 Chrome 62, 带有输入数据的 HTTP 页面和所有以无痕模式浏览的 HTTP 页面都会被标记为 "不安全". 到了 2018 年 7 月, Chrome 浏览器的地址栏将把所有 HTTP 标示为不安全网站.
除去谷歌, 其他一些互联网公司也进行了自己的 HTTPS 实现, 比如当前国内炒的很火热的微信小程序也要求必须使用 HTTPS 协议; 新一代 HTTP/2 协议的支持必须以 HTTPS 为基础; 苹果公司要求 App Store 当中的所有应用必须使用 HTTPS 传输等等.
总而言之, HTTPS 和传统的 HTTP 主要的差异遭遇安全性方面, HTTPS 上的站点数据, 在互联网上传播具有动态的加密特性, 所以安全性较高, 而 HTTP 则没有这个功能, 在如今网络安全日益突出的大环境下, HTTPS 必然成为趋势.
来源: https://www.cnblogs.com/slly/p/10529135.html