HTTPS

文章目录

- HTTPS
- 加密方式
- - 对称加密
  - 非对称加密
- [数据摘要数据指纹](#数据摘要数据指纹)
- HTTPS的工作过程
- - 方案---只使用对称加密
  - [方案2 只使用非对称加密](#方案2 只使用非对称加密)
  - [方案3 双方都使用非对称加密](#方案3 双方都使用非对称加密)
  - [方案4 非对称加密+对称加密](#方案4 非对称加密+对称加密)
- 引入证书

如果你上了一些不好的网站，黑客可能在你的机器上开放某些端口，把你的cookie信息就给盗走了，之后他拿着你的账号密码就去登录了

问题

1。个人cookie文件被盗窃，由别人冒充我的身份

2。个人私有信息被泄露

用户客户端的防范能力在黑客眼里 = 0，所以把私密信息放在客户端cookie里是不合理的。

先解决第二个问题

今天浏览器访问，服务器做认证，如果认证成功就在服务端生成session文件，而且会有唯一的session ID,这个文件以这个ID命名。

然后服务器就会给客户端响应，响应里挟带set-cookie: session id,

浏览器中的cookie文件就会保存这个session id，此后每次请求都挟带这个ID，如果存在于服务端就服务，不存在就重定向到网站首页重新登录。

可是服务器里存在大量的用户的session文件，怎么把这么多的seeion文件管理起来？

先描述在组织

当代企业主流的会把session放到redis托管起来

这种session+cookie的解决方案和只用cookie有什么区别？

很显然黑客依然可以获取这个session id的cookie，然后拿着这个id，我不就是你吗，依然可以冒充你。

最大的好处是你的私人信息不会被泄露了。因为你的信息都是由服务端来维护了。

那服务器维护，那服务器不会被攻击？

企业不是吃闲饭的，有攻防。zfb你试试。

顶级攻防甚至会开放某些钓鱼端口然后你去扫吧，人家和运营商关系也不差，反向追踪。

那cookie信息被盗取的问题能解决吗？

服务器做的很好，再怎么防，也防不住客户端把信息让别人盗走，所以防不住。

客户端点了某些链接，邮件，钓鱼软件一点就把自己的个人信息打包拿走了。

那他还是能冒充我，登录我的账号了啊

那怎么办？

session id 是服务器端统一管理分配的。

他能分配给你，他也随时能回收。

比如黑客和你不是同一个地区的，此时服务器甄别到你账号有异常，人家把session信息设置为暂停状态，并让用户重新登录，如果登录失败了立马把这个session删掉，这个sesion就不奏效了。

虽然无法彻底解决黑客冒充身份，但是可以对session id进行各种保活了，取消了修改了暂行了，来达到控制客户端的目的。

我们目前的所有Http请求全都是明文的。

post表单传参如果传递的用户名密码，都能被抓包抓到，他是非常不安全的。

现在我们访问网站都是https

侧重点放在https放在保证数据安全

如何让一个请求和一个响应能够安全的进行数据交互

我们HTTP在应用层把数据通过系统调用socket套接字贯穿OS，把数据发送到网络中交给服务端。

OS没有义务给你把数据加密，他只负责数据传送

这之间如果有人收到了这个报文，HTTP都是明文的他就能拿到这个数据放到他自己的应用层去了，所以这样断然是不行的。

所以就在应用层又加了一层软件层：ssl加密解密层，加密之后只有通信双方的应用层能读取到真实报文，别人拿到了也是加密的。

所以走左边不加密的贯穿协议栈是http，走右边加了软件层的是https

明文变密文相互转化

明文加了很多中间数据变成密文

这些辅助数据称为密钥

例如一心给慈禧写的信，全是唠家常，但是慈禧用另一张带洞的纸一比就有真正的密文了。

目前用户的所有数据请求都是要经过运营商，再由运营商转发给服务器。

运营商此时就成为了中间人，对用户的明文做篡改，更改了用户的下载行为

这种篡改称之为中间人攻击。

所以一定要给信息做加密了。

我们的机器一定是处于某个局域网之中的，你的明文信息要先交给路由器，再发送到外网。

所以路由器也能看到你的明文报文。

或者某些钓鱼WIFI，你手机给PC开热点。

这都有可能成为中间人。

加密方式

对称加密

加密和解密都同用一个密钥

特点：速度快

非对称加密

加密和解密用的是不同的两组数据

明文用A加密得到密文用B解密

用B解密也可以用A来解密

其中一个密钥直接公开，因为有特殊场景。

把公开的密钥叫做公钥，把自己保留的密钥叫做私钥。

特点：运行速度非常慢

用私钥加密，谁拥有公钥都可以解密

用公钥加密之后只有拥有私钥的人才可以解密

数据摘要数据指纹

把原始文章利用某种摘要算法比如MD5生产固定长度的，非常低概率发生冲突的固定长度的字符串，具有唯一性

如果你更改了原始文章任意一个小地方，都会导致字符串不一致

对比两个字符串是否相等，就能知道文章是否被修改过。

这个字符串称为数据指纹

两个场景

1。session id具有唯一性，我们用用户名的唯一性和密码生成数据摘要也具有唯一

2。网盘秒传

对电影二进制数据行程数据摘要，然后把指纹入库，存到数据库里，具有唯一性。

下一次请求时使用同样的数据摘要，先把摘要上传，直接去库里面搜索，看有没有匹配的，有就在你的目录里建立软连接，指向已经有的电影文件。

HTTPS的工作过程

1.我们自己逐步的设计---套安全方案

方案---只使用对称加密

对称加密双方都异或同一个数字

7^5 =2加密 2 ^5=7解密

客户端和服务器约定好用同一个秘钥，到底靠不靠谱？

不靠谱

因为服务器的客户端非常多，比如浏览器需要内置密钥，你能拿到密钥的话，任何人也能拿到密钥。

如果服务器要把密钥换一下，可是客户端已经有很多了，你怎么保证别人跟着你换。

那有人说了我们CS可以在数据发送之前，我可以先向服务器请求这个秘钥，然后服务器把秘钥发回来，此时双方都有密钥了，不就能正常通信了。

但你这密钥发送，请求和响应，密钥本身要不要加密，那不加密黑客不也能获得这个秘钥吗。

那我对响应的这个秘钥加密，那到对端对端怎么解密呢？

所以只使用对称加密方案不合理

无论密钥是由C还是S提供，两个只能有一个人形成，要把用一个秘钥交给对方，你就必须经过网络，那经过网络的密钥本身要不要加密？

所以黑客照样也能拿到密钥信息。

方案2 只使用非对称加密

非对称加密有公钥P 私钥P'

服务器永远是被动接受客户端请求的，所以客户端请求来了，客户端响应把我的公钥是P交给了浏览器。

从此往后客户端再给服务器发数据，要把数据经过P加密，形成密文信息，世界上只有服务器有私钥，这个加密的数据只有服务器能解密。

所以即便是黑客无法获取私钥，但他能拿到公钥但没有任何价值。黑客难道数据也没办法。

此时保证了客户端到服务器端本身数据传送的安全性（暂时）。

http有请求就有响应，服务器给响应就是response+P' 因为客户端只有公钥，所以服务器只能对数据用私钥来加密，那客户端就得到了响应，这里有个严重问题，用私钥加密可以用公钥解密，客户端能获取公钥，黑客也能获取公钥。

所以只采用非对称加密来直接进行数据传输，你能做到客户端到服务器暂时的数据安全，但从服务器到客户端数据安全你保证不了，因为公钥是公开的，黑客拿到了公钥也就能对response进行解密得到明文数据。

所以只使用非对称加密也不行

当我们有了这种方案，立马想到服务器有公钥私钥，那客户端也可以有公钥私钥啊，这样双方把公钥一交换不就可以了吗

方案3 双方都使用非对称加密

客户端，服务器都由公钥私钥

C,C' S S'

客户端请求就把公钥C交给了S

服务器响应也可以把自己的公钥S交给客户端

双方把私钥不暴露

从此往后双方数据请求时，客户端使用服务器的公钥进行加密，服务器响应时使用客户端的公钥加密，因为只有持有对应私钥的人才能对数据解密，所以就能保证两个方向的数据安全性。

俩问题

1。运行速度慢

2。依旧有安全问题

方案4 非对称加密+对称加密

首先服务器要有公钥S和私钥S'

然后客户端发起http请求的时候，服务器对http进行响应，服务端就把自己的公钥S就给了客户端，所以客户端拿到了公钥S。

客户端自己形成一个对称密钥：C

然后客户端把C这个对称密钥和服务器端发来的公钥进行加密形成密文数据，然后再把对应的密文数据推送给服务器，服务器收到了加密后的对称私钥结合自身的私钥解密得到对称密钥C（

因为非对称加密公钥加密私钥解密，即便中间人难道了公钥也没法破解拿到对称私钥）

此时对称私钥就被双方安全拿到了

从此往后双方进行正常的请求响应采用对称的加密和解密。

此时既能保证通信双方的数据安全，又能保证前期只是交换密钥的过程中使用非对称，这样也能保证后续正常通信的效率问题。

非对称加密扮演的角色是支持客户端和服务器进行对称密钥的交换的！

这种方案4 已经接近了正常https通信前密钥握手的真实答案，但是他还是有问题。

由于中间的⽹络设备没有私钥,即使截获了数据,也⽆法还原出内部的原⽂,也就⽆法获取到对称密钥(真的吗？)

非对称加密

最典型的特点在于密钥可以公开，私钥保留只有拥有私钥的人独立解密。

非对称加密应用场景，进行对称密钥的交换协商。

但实际情况还是不行。

方案2 方案3 方案4 前期都是用了非对称加密，2，3，4都有一个问题。

前提性问题

刚刚所有的中间人都很傻，从第四个请求才进来，万一从第一个请求中间人就已经在了呢？

针对2，3，4方案自己想一个中间人攻击的方案来攻破它。

客户端，服务器，中间人

服务器有自己的公钥S和私钥S'

基于方案4来攻击，如果4有问题，2，3，也有问题

CS通信前，中间人也有自己的准备，他准备了自己的公钥M和私钥M'

客户端向服务器发起请求，服务器给他响应，把公钥S返回给客户端，此时中间人最开始第一个请求的时候已经来了，客户端以为自己请求的是服务器，实际上他的报文要先到中间人，此时客户端请求中间人，中间人把这个请求放给了服务器，服务器就给中间人响应了公钥S然后由中间人转给客户端，中间人收取到报文时，最开始双方交换时整个报文没有加密，所以中间人拿到了响应，中间人做一件事情，