HTTPS

如果你上了一些不好的网站，黑客可能在你的机器上开放某些端口，把你的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

侧重点放在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然后由中间人转给客户端，中间人收取到报文时，最开始双方交换时整个报文没有加密，所以中间人拿到了响应，中间人做一件事情，

他把服务器的公钥S自己保存起来，然后中间人把自己的公钥M放到响应报文中，然后把对应的响应报文伪造的带了自己的公钥M响应交给客户端

此时客户端就以为公钥M就是服务器的公钥M，这个公钥M没有自证性，合法不合法客户端不知道，他就以为是服务器的公钥，中间人也是透明的，所以客户端形成自己的对称密钥，使用M进行加密，就形成了对应密文，接着把加密后的密文交给服务器，可是要先转给中间人。

中间人拿到了密文数据XXXX，客户端用的是中间人的公钥加密了，中间人就用自己的私密M’解密了，中间人就拿到了对称密钥X，紧接着对秘钥X进一步用曾经截获的服务器公钥S再加密形成密文YYYY，此时中间人把密文推送给服务器。

客户端服务器双方不清楚对应的数据是被篡改过的，所以服务端就收到了YYYY

服务器以为自己收到的密文数据是没有被人篡改过的，他也认为这个密文数据是客户端用公钥S进行加密的，确实中间人就用S加密的，只不过这个密文被我窥探到了。
此时服务就用私钥S’进行解密，他也成功得到了X对称密钥。

至此客户端，服务器很高兴，双方得到了对称密钥
中间人最高兴，因为我也拿到了对称密钥X
接下来我们要使用对称密钥进行数据交换了，数据交换时客户端发了报文，服务器得到报文，中间人说你们俩所有的报文加密用的X我也知道，你们的报文我也拿到了，所以我也可以对你的报文进行解密。
解密完成之后了不起我在用X加密在推送给服务器

所以CS双方通信时所有数据中间人都能拿到。
更有甚者 中间人篡改客户端某些请求，服务器也是甄别不出来的

所以后续使用X进行对称解密，一切都在中间人的掌握之中了。
所以这种中间人攻击方案称做MITM攻击

断定方案4肯定不行了，那方案3更别说了，方案2 都有类似的问题

所以如何解决问题呢？
要解决问题你得知道问题的本质是什么？
整个过程中问题的本质是什么呢？
客户端无法验证服务器发来的公钥是否是合法的！！！
客户端根本没法确认中间人把公钥替换为公钥M了，如果公钥本身是合法的，我客户端能知道，也就能甄别非法公钥了，所以也就不会形成对称密钥，也就没有后面一堆动作了。

如何保证公钥的合法性？？？
中间人想篡改也篡改不了
才能基于方案4在调优

引入证书

角色
CA机构
服务端在使⽤HTTPS前，需要向CA机构申领⼀份数字证书，数字证书⾥含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书⾥获取公钥就⾏了，证书就如⾝份证，证明服务端公钥的权威性

申请证书的一般流程

1.申请者 申请证书
要准备
生成公钥与私钥对，就是服务器端自己的公钥和私钥
确认申请信息：域名、申请者、公钥
生产请求文件.csr
不含有私钥信息
2.交给CA审核
3.签发证书
3.1 安装到服务器
4.客户端发起请求后客户端返回证书
5.客户端就去验证证书
6.密钥协商

签名 的信息
最重要的是包含了 公钥

就是服务器的公钥S
那私钥在哪呢？在服务器申请证书时，把公钥提交给CA了，私钥谁也不能给，服务器自己保护好。

换言之客户端请求服务器时，客户端会先得到证书，而证书本来就包含服务器的公钥，所以此时客户端如果相信公钥，前提他得相信证书是合法的，我就相信公钥。

你怎么证明你的证书
1、是权威机构+没有被篡改过的呢？

证书中包含了签名
证书是否合法条件：1。机构权威+没有被篡改
两个陌生的概念
1、签名
2、把个人信息打包生产请求文件.csr
在线生成方案

那我怎么没看到公钥呢？

公钥是几你不用关心了，你只需要知道有个私钥，还有个CSR,对应公钥人家已经形成了。
然后拿着CSR文件就可以向CA机构提交了。

签名

签名 = 数据生成数据摘要 的散列值（固定大小）再用私钥加密的散列值

把数据和签名结合后，对单独数据进行散列形成数据摘要
在把单独签名用公钥解密后得到的数据摘要
把这两个数据摘要对比，如果一致，则数字签名有效

在CA内部如何形成证书呢？？
数据值得就是用户提交上来的数据，我网站的建设者提交，接下来的视角是CA内部
，CA采用公开函数散列算法，形成数据摘要，然后用CA机构自己的公钥和私钥–和我们历史讲的CS通信时服务端的公钥和私钥毫无关系！
所以CA用自己的私钥CA’来加密形成了签名，然后把客户端提交的数据和签名形成了证书了。

方案5 非对称加密+对称加密+证书认证

客户端请求，服务器响应给客户端证书，证书中携带了公钥，然后客户端就生成对称密钥，用公钥加密形成密文，客户端再把密文交给服务器端，服务器端拿到密文再用私钥解密拿到对称密钥，之后就用对称密钥进行通信了，整个过程和方案4没有任何区别

客户端拿到证书需要先做认证
把证书的数据用公开的MD5算法形成数据摘要
把签名用内置在浏览器中CA的公钥进行解密得到数据摘要
如果两个摘要一致，则证书中的公钥可信
后续进行对称加密通信

签名是用CA的公钥进行解密，客户端只认CA的公钥，也就意味着只有CA能够进行证书的签发，因为只有CA自己具有私钥！

应对中间人攻击场景
1。明文修改
改改公钥，不改签名，客户端认证摘要信息不一致。
2。签名修改+明文修改
中间人没资格进行证书的全新形成！我只认CA机构的。
中间人要保持透明状态。
3。签名修改
也解不了密，摆着告诉别人我是中间人。

那中间人胆子大跑去CA机构把什么域名公钥上层申请一个真的证书给你呢？
黑客申请真证书，提交真信息！
世界上不存在两个一模一样的域名，你的域名信息必须要改变，因为别人已经申请了。
那黑客申请真证书，本身不就是一个合法网站吗？
有些假网站会这么做。

假网站也是一种中间人，你先请求给了假网站然后假网站替你去请求真网站
这种是防不住了，只有交给专业人员处理
黑客会用真信息，只不过不用他自己的信息不就行了。

无论引入CA机构还是非对称加密对密钥交换实际上最本质的问题就是如何保证公钥的合法性？
证书，引入CA官方第三方机构解决信赖问题。

如何看待Https

Https真的安全吗？
可以有效防止中间人的攻击，可是没有密不透风的墙，这个世界上有黑就有白。
https 用的ssl安全协议一直在升级

他能不能防止客户端本身就是黑客？
而且中间人空间对象是客户端，我们不排除有些人想攻击服务器。
如果客户端本身自己就是攻击软件，把浏览器的CA也保留一份，往后攻击软件也有自己的对称密钥，往后用这个对称密钥和服务器加密解密，攻击软件就能分析服务器发来的响应。