@lizlalala
2016-10-20T08:28:30.000000Z
字数 2322
阅读 1200
http
为什么请求头中要指定uri
因现实生活中,有可能一个服务器上部署着多个服务,(虚拟服务器存在)域名不同,那么光有IP是没有用的都会定位到这个服务器,因此需要有指定的uri来唯一识别
客户端 代理服务器 源服务器
每次经过代理服务器,都需要写入 via 首部信息到头请求头或者响应头。
chapter6 是http首部字段的一些说明,包括通用首部、请求首部、响应首部、实体首部以及一些没有放到http1.1的rfc里面但很常用的首部字段,包括cookie的一些字段及属性,如set-cookie的secure,httpOnly属性,cookie字段。还有其他的如DNT(do not trace,拒绝个人信息被搜集),p3p(保护用户隐私)的等等。具体可以查看书上的介绍,这部分不再赘述。
本章是基于http的以下三个缺点展开的:
为什么不加密?因为加密了其实也可能被窃听,只是可能不会被破解而已。
如何防止被窃听——加密
ssl:
secure socket layer 安全套接字
tls:
transport layer security 传输层安全协议
如何确认通信方的身份——证书
不确认通信方的身份,可能会带来若干隐患:
如何保证通信内容不被篡改——摘要
现实生活中,请求或者响应在传输过程中是可能被攻击者拦截后进行篡改的,这种就是中间人攻击。通常避免的方法有MD5和SHA-1等hash值校验的方法、数字签名(文件的数字签名可以用PGP来生成)。
但这些方法都需要客户端的用户去亲自检查验证是否自己下载的文件就是服务器上的文件。
而且一旦MD5,PGP这些被篡改的话,用户其实也无法发现。
综上,HTTPS可以解决以上三种问题,SSL提供了认证+加密处理+摘要的功能。它可以总结为
HTTPS = HTTP+ 加密+ 认证 +完整性保护
使用ssl时,就从通常的http与tcp通信变成http->ssl->tcp->ip..
【注】ssl是独立于http的协议的,其他运行在应用层的SMTP,Telnet等协议都可以与ssl配合使用。
https采取了共享秘钥加密+公开秘钥加密的混合加密方式
补充知识:
加密分两种,对称/非对称,ssl采取的是非对称即公开秘钥加密
对称密钥(共享密钥),即加密解密都用同一个秘钥,缺点在于秘钥必须发送给对方,而传送时有可能就被窃听甚至获取到。
公开秘钥使用非对称密钥,公钥加密,私钥解密,公钥可以被任意共享。具体来说是,A发送给B,就用B的公钥加密,B收到后用自己的私钥解密
优点在于安全性得到了极大的保障:
- 同时获取公钥私钥很困难
- 即使获得了破解也困难(大素数分解)
实际中,由于公开秘钥加密很慢,因此https采取了两种方式混合使用的方式,用公开密钥加密的方法去交换接下来在共享秘钥加密方式中的密钥,然后在确保密钥安全的前提下用共享秘钥的方式通信。
问题又来了...当你用公开秘钥加密的方法传输时,你怎么知道这个被你传的就是真正的公开秘钥。
但是光有不行,因为不能证明公钥本身就是真正的公钥,有可能这个公钥已经被攻击者替换。
因此,就需要证书来验证。
3.证书
流程:
服务器运营人员向 数字证书认证机构申请,机构用自己的私钥对申请的公开秘钥做数字签名,然后把这个公开密钥A放入公钥证书。然后服务器把证书给客户端。客户端要验证这个公钥证书是否是正确的,就直接把证书(公钥A+机构私钥组成的数字签名)连同浏览器内置好的认证机构的公钥B,去验证数字签名,以确定公钥A的真实性。
一旦验证这个公开密钥A是真实的,就可以继续用原来的 方式(公开密钥加密方式去交换对称密钥,然后共享秘钥方式加解密)....好绕口=。=
其实就相当于在原来的基础上多了一步验证公开密钥的真实性。而这个秘钥的真实性的验证是借助可信证书机构的公私密钥来解决的。
正确的流程是:
服务器:
服务器每次传送,都需要发:
//服务器sendData = 信息+ signature +数字证书。
//signature = md5(信息)+ 服务器私钥加密
//数字证书 = 服务器公钥 + 机构私钥 加密后结果
客户端
客户端拿到以后,用浏览器的机构公钥解密,得到服务器公钥,然后去解谜收到的东西,得到的就是 md5以后的 信息 A。然后将信件本身md5后生成B 。AB进行判断是否相等。就可以看信件是否篡改了。
在这个过程中,先用机构公钥解密验证 身份,再用服务器公钥揭秘再比对实现 篡改验证。
同第七章的证书(服务器认证)不一样的是,这一章是针对客户端的认证,主要包括以下几种,以后几章都用思维导图来总结啦。