注:1.请直接看六。2.一切从Http设计角度考虑。
1.用户浏览器发送域名向DNS服务发送一个域名,请求其ip地址。
2.DNS找到ip并返回给用户浏览器。
3.用户浏览器向服务端浏览器发送请求。(地址、端口号、请求、参数等等)
4.服务端向用户浏览器返回响应。
http不面向链接,无状态(但我们可以用session+cookie来实现状态)。
Http 协议无法加密数据。
IP+TCP+SSL/TLS+HTTP。SSL会对内容加密,防止用户篡改。
对称加密算法:一把key即加密又解密。
非对称加密算法:一对配套的公钥私钥。用公钥对数据进行加密,只有用对应的私钥才能解密;用私钥对数据进行加密,那么只有用对应的公钥才能解密。
(从设计角度出发,每一个小段并不是最终状态!)
既然接收方要解密,就需要得到一把公钥(如果用对称算法则....凉了么这不是....)
但我们发送请求有时需要通过“中间人”(用来协商密钥)。遇到一个“不靠谱”的中间人就可能会生这种事:
①client向中间人:请求获取公钥(s.public)
②中间人向server:请求获取公钥(s.public)
③server向中间人:返回公钥(s.public)
④如果此时中间人进行篡改,中间人向client:返回自己的公钥(m.public,假公钥)
⑤此时,client发送消息,用假公钥(m.public)进行加密,并返回给中间人。
⑥中间人可以用私钥(m.private)进行解密,篡改信息,再用真公钥(s.public)向client发出篡改后的信息。
所以,我们需要让中间人安分下来!
第三方机构,它有一个(t.pub)(t.pri)。那么故事就会是这样:
①client向中间人:请求获取公钥(s.pub)
②中间人向server:请求获取公钥(s.pub)
③server向第三方机构:发出公钥(s.pub)
④在第三方判明申请者的身份后,便为server分配一个公钥,并且 CA 将该公钥与申请者的身份信息绑在一起,并为之签字后,便形成证书发给server。(证书包括了s.pub,颁发机构,等等的信息。SHA-256算法就是在这)
⑤server向中间人:返回数据证书
⑥中间人向client:返回数据证书 (他对证书无能为力。即便也能通过正规渠道从CA获得一个公钥,但是由于CA进行了身份绑定,client可以判断出来!)
⑦client向中间人发送消息...这时中间人已经没有威胁了!
可以去找第三方问。对于每一个clinet,受信任的CA都被浏览器内置证书,向用户提供其公钥c.pub。
①当客户端向服务端发送请求三次握手-random
②三次握手之后会得到服务器端发送CA证书[]-random
③客户端对证书进行验证(比如:证书编号、对证书所有路径层级校验、对请求域名做校验、有效期校验....)
④客户端生成随机对称密钥,通过s.pub加密-random
⑤客户端发送给服务端由s.pub加密的对称密钥
⑥服务器端客户端基于会话密钥(生成三个随机数[三个random由s.pub加密]进行验证,这就是对称加密)进行通信 。
用非对称加密生成数字证书,然后用对称加密进行传输。
过程中生成随机数,知道开始会话才最终确定密钥。