读《图解HTTP》记录
上一篇 读书笔记_图解HTTP(三) Web服务器以及http首部
HTTPS
在Http协议中有可能存在信息被窃听或身份伪装等安全问题。使用Https通信机制可以有效地防止这些问题。
1、Http的缺点
- 通信使用明文(不加密),内容可能会被窃听
- 不验证通信方的身份，因此有可能遭遇伪装
- 无法证明报文的完整性，所以可能已遭篡改
这些问题在其他未加密的协议中也会存在。除此之外，Http本身还有很多缺点。而且，还有像某些特定的Web服务器和特定的Web浏览器在实际应用中存在不足，另外，Java和PHP等编程语言开发的Web应用也可能存在安全漏洞。
1、通信使用明文可能会被窃听
由于Http本身不具备加密的功能，所以也无法做到对通信整体（使用Http协议通信的请求和响应的内容）进行加密。即，Http报文使用明文(未经过加密的报文)方式发送。
- TCP/IP 可能会被窃听的网络
因为TCP/IP协议族的工作机制，通信内容在所有的通信线路上都有可能会遭到窥视。互联网，是由能连通到全世界的网络组成。无论在世界哪个角落的服务器在和客户端通信时，在此通信线路上的某些网络设备、光纤、计算机等都不可能是个人的私有物，所以不排除某个环节中会遭到恶意窥视行为。
即使已经经过加密处理的通信，也会被窥视到通信内容，这点和未加密的通信是相同的。只是经过加密之后，就有可能会让人无法破解报文的含义，但是加密后的报文本身还是会被看到。
-
加密处理防止被窃听
1、通信的加密
Http协议中没有加密机制，但可以通过和SSL(Secure Socket Layer,安全套接层)或TLS(Transport Layer Security,安全层传输协议)的组合使用，加密Http的通信内容。
使用SSL建立安全通信线路之后，就可以在这条线路上进行Http通信了。与SSL组合使用Http被称为HTTPS(HTTP Secure,超文本传输安全协议)或HTTP over SSL。
通信的加密
2、内容的加密
内容的加密是将参与通信的内容本身加密。由于HTTP协议中没有加密机制，那么就对HTTP协议传输的内容本身加密。即把HTTP报文里所包含的内容进行加密处理。在这种情况下，需要客户端对HTTP报文进行加密处理后再发送请求。但是这种方式不同于SSL或TLS将整个通信线路加密处理，所以内容仍然可能被篡改。
2、不验证通信方身份就可能遭遇伪装
HTTP协议中的请求和响应不会对通信方进行确认。也就是说存在“服务器是否就是发送请求中URI真正指定的主机，返回的响应是否真的返回到实际提出问题的客户端”等类似的问题。客户端不能确认请求的服务器是不是真的目标服务器；服务器收到的请求是不是真的目标范围内的客户端。
- 任何人都能发起请求
在HTTP协议通信时，由于不存在确认通信方的处理步骤，任何人都可以发起请求。另外，服务器只要接收到请求，不管对方是谁否会返回一个响应。所以会存在各种隐患。
1、不能确定请求的是不是目标服务器（无法确认请求发送至目标的Web服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的Web服务器）。
2、不知道发起请求的是不是目标客户端（无法确定响应返回到的客户端是否是按真是意图街道的那个客户端。可能是已伪装的客户端）。
3、无法确认正在通信的对方是否具备访问权限。（某些数据只想给特殊的用户）
4、即使是无意义的请求也会照单全收。无法阻止海量请求下的DOS攻击(Denial of Service,拒绝服务攻击)。
- 查明对手的证书
Http协议无法确认通信方，但如果使用SSL则可以。SSL不仅提供加密处理，而且还使用了一种被称为证书的手段，可用于确认方。
证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。在技术角度来说，伪造证书非常困难。所以只要能确认通信方(服务器或客户端)持有证书，即可判断通信方的真实意图。
通过使用证书，以证明通信方是意料中的服务器。这对使用者个人来说，减少了个人信息泄漏的危险性。
客户端持有证书即可完成个人身份的确认，也可用于对Web网站的认证环节。
3、无法证明报文完整性，可能已遭篡改
所谓完整性是指信息的准确度。若无法证明完整性，通常也就意味着无法判断信息是否准确。
- 接收到的内容可能有误
由于HTTP协议无法证明通信的报文的完整性，因此，在请求或响应送出之后直到对方接收到之前的这断时间内，即使请求或响应的内容遭到篡改，也没办法知道。
换句话说，没有人格办法确认，发出的请求/响应和接收到的请求/响应是相同的。内容在传输途中可能已经被篡改为其他内容。
像在请求或响应的传输中，早攻击者拦截并篡改内容的攻击被称为中间人攻击(Man-in-the-Middle attack,MITM)。
- 防止篡改
虽然有使用Http协议确定报文完整性的方法，但事实上并不便捷、可靠。其中常用的是MD5和SHA-1等离散列值校验的方法，以及用来确认文件的数字签名方法。
提供文件下载服务的Web网站也会提供相应的以PGP(Pretty Good Privacy，完美隐私)创建的数字签名及MD5算法生成的散列值。PGP是用来证明创建文件的数字签名，MD5是由单向函数生成的散列值。不论使用哪种方法，都需要操纵客户端的用户本人亲自检查验证下载的文件是否就是原来服务器上的文件。浏览器无法自动帮用户检查。
可是，用这些方法也依然无法百分百保证确认结果正确。因为PGP和MD5本山被改写的话，用户就没办法意识到了。
为了有效防止这些弊端，有必要使用HTTPS。SSL提供认证和加密处理及摘要功能。仅靠HTTP确保完整性是非常困难的，因此通过和其他协议组合使用来实现这个目标。
2、HTTP+加密+认证+完整性保护=HTTPS
为了解决上述问题，需要在HTTP上加入加密处理和认证等机制。我们吧添加了加密以及认证机制的HTTP称为HTTPS(HTTP Secure)。
2.1、HTTPS是身披SSL外壳的HTTP
HTTPS并非是应用层的一种新协议。只是HTTP通信接口部分用SSL和TLS协议代替而已。
通常，HTTP直接和TCP通信。当使用SSL时，则演变成先和SSL通信，再由SSL和TCP通信。
在采用SSL后，HTTP就拥有了HTTPS的加密、证书和完整性保护这些功能。SSL是独立于HTTP的协议，所以不光是HTTP协议，其他运行在应用层的SMTP和Telnet等协议均可配合SSL协议使用。可以说SSL是当今世界上应用最为广泛的网络安全技术。
2.2、互换密钥的公开密钥加密技术
SSL采用一种叫做公开密钥加密的加密技术。近代的而机密方法中加密算法是公开的，而密钥是保密的。通过这种方式得以保持加密方法的安全性。
加密和解密都会用到密钥。没有密钥就无法对密码解密。就是说，任何人只要持有密钥就能解密。如果攻击者获得了密钥，那加密就没有意义了。
2.2.1 共享密钥加密的困境
加密和解密使用同一个密钥的方式称为共享密钥加密(Common key cryto system)，也被称为对称密钥加密。
以共享密钥方式加密时必须将密钥也发给对方。但是在互联网上转发密钥，如果通信被监听密钥就可能会落入攻击者的手中，同时就失去了加密的意义。另外还得设法安全的保管接收到的密钥。
2.2.2 使用两把密钥的公开密钥加密
公开密钥加密方式很好的解决了共享密钥加密的困难。
公开密钥加密使用一对非对称的密钥。一把叫做私有密钥(private key) 另一把叫做公开密钥(public key)。私有密钥不能让其他任何人知道，公开密钥可以随意发布，任何人都可以获得。
使用公开密钥加密方式，发送秘闻的一方使用对方的公开密钥加密，对方收到加密信息后，再使用自己的私有密钥解密。这样就不需要发送用来解密的私有密钥，也不必担心密钥被攻击者监听而盗走。
另外，要想根据密文和公开密钥恢复到信息原文异常困难。就目前技术来看是不太现实的。
2.2.3 HTTPS采用混合加密机制
HTTPS采用共享加密和公开密钥加密两者并用的混合加密机制。若密钥能实现安全交换，那么就有可能会考虑仅使用公开密钥加密来通信。但是公开密钥加密比共享密钥加密处理速度要慢。
所以应该充分利用两者自己的优势，将多种加密方法组合起来用于通信。在交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段使用共享密钥加密方式。
2.3、证明公开密钥正确性的证书
公开密钥加密方式还是存在一些问题的。那就是无法证明公开密钥本身就是货真价实的公开密钥。比如，正准备和某台服务器建立公开密钥加密方式下的通信时，如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥。或许在公开密钥传输中，真正的公开密钥已经被攻击者替换掉了。
为了解决上述问题，可以使用由数字证书认证机构和相关机关办法的公开密钥证书。
数字证书认证机构处于客户端与服务器双方都可醒来的第三方机构的立场上。其业务流程如下。
- 首先，服务器的运营人员向数字证书认证机构提出公开密钥的申请；
- 数字证书认证机构在判断提出申请的身份之后，会对已申请的公开密钥做数字签名；
- 然后分配这个已经签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。
这时，服务器会将这份由数字证书认证机构办法的公钥证书发送给客户端，以进行公开密钥加密方式通信。公钥证书也可以叫做数字证书或者直接称为证书。
接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名验证，一旦验证通过了，客户端就可以明确两件事；
- 认证服务器的公开密钥的是真实有效的数字证书认证机构；
- 服务器的公开密钥是值得信赖的
此处认真机关的公开密钥必须安全的转交给客户端。使用通信方式时，如何安全转交是一件很困难的事，因此，多数浏览器开发商发布版本时，会事先在内部植入常用认真机关的公开密钥。
2.3.1可证明组织真实性的EV SSL证书
证书的作用是用来证明作为通信以放的服务器是否规范，另一个作用是可确认对方服务器背后运营的企业是否真是存在。拥有该特性的证书就是EV SSL证书(Extended Validation SSL Certificate).
EV SSL证书是基于国际标准的认证指导方针办法的证书。其严格规定了对运营组织是否真是的确认方针，因此，通过认证的Web网站能够获得更高的认可度。
拥有EV SSL证书的Web网站的浏览器地址栏的背景色是绿色的，一眼就能看出来。而且在地址栏的左侧显示了SSL证书中记录的组织名称以及颁发证书的认证机构的名称。
上述机制的原意图是为了防止用户被钓鱼攻击，但是就效果上来讲，还得打一个问号。
2.3.2 用以确认客户端的客户端证书
Https中还可以使用客户端证书。一客户端证书进行客户端认证，证明服务器正在通信的对方始终是预料之内的客户端，其作用更服务器证书一样。
但客户端证书仍存在几处问题。其中一个就是证书的获取及发布。
想获取证书时，用户得自行安装客户端证书。但由于客户端证书要付费，且每张证书对应到每位用户也就意味着需支付和用户数对等的费用。另外，要让知识层次不同的用户自行安装证书，这件事也不太现实。
现状是，安全性极高的认证机构可办法客户端证书但仅用于特殊用途的业务。比如那些可支撑客户端证书支出费用的业务。例如，银行的晚上银行就采用了客户端证书。在登录网银时，不仅要求用户确认ID和密码，还会要求用户的客户端证书，以确认用户是否从特定的终端访问网银。
客户端证书存在的另一个问题是，客户端证书毕竟只是用来证明客户端实际存在，而不能用来证明用户本人的真实有效性。也就是说，只要获得了安装客户端证书的计算机的使用权限，也就意味着同时拥有了客户端证书的使用权限。
2.3.3 认证机构信誉第一
SSL机制中介入认证机构之所以可行，是因为建立在其信用绝对可靠这一大前提下。然而，2011年7月，荷兰一家认证机构曾遭黑客不法入侵，颁布了google.com和teitter.com等网站的伪造证书事件。这一事件从根本上撼动了SSL的可信度。
因为伪造证书上有正规认证机构的数字签名，所以浏览器会判断该证书是正当的。但伪造的证书被用作服务器伪装时，用户根本无法察觉到。
虽然存在可将证书无效化的证书吊销列表机制，以及从客户端删除根证书颁发机构的对策，但距离生效还需要一段时间，而这段时间内，到底有多少用户的利益蒙受损失就不知道了。
2.3.4由自认证机构办法的证书称为自签名证书
如果使用OpenSSL这套开源程序，每个人都可以建立一套属于自己的认证机构，从而自己给自己办法服务器证书。但该服务器证书在互联网上不可做为证书使用，似乎没什么帮助。
独立构建的认证机构叫做自认证机构，由自认证机构办法的“无用”证书也被称为自签名证书。
浏览器访问该服务器时，会显示“无法确认链接安全性”或“该网站的安全证书存在问题”等警告消息。
由自认证机构办法的服务器证书之所以不起作用，是因为它无法消除伪装的可能性。自认证机构能产生的作用顶多就是自己对外宣称“我是xx”的这种态度。即使采用自签名证书，通过SSL加密之后，可能偶尔还会看到通信处在安全状态的提示，可那也是有问题的。因为就算加密通信，也不能排除正在和已经伪装过的假服务器保持通信。
值得信赖的第三方机构介入认证，才能让已植入在浏览器内的认证机构颁布的公开密钥发挥作用，并借此证明服务器的真实性。
中级认证机构的证书可能会变成自认证证书
多数浏览器内预先已植入备受新浪的认证机构的证书，但也有一小部分浏览器会植入中级认证机构的证书。
对于中级认证机构办法的服务器证书，某些浏览器会议正规的证书来对待，有可能的浏览器会当作自签名证书。
2.3、HTTPS的安全通信机制
先来观察一下https的通信步骤
- 1、客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件(Cipher Suite) 列表(所使用的加密算法以及密钥长度等)。
- 2、服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含了SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
- 3、之后服务器发送Certificate报文。报文中包含公开密钥证书。
- 4、最后服务器发送Server Hello Done 报文通知客户端，最初阶段的SSL握手协商部分结束。
- 5、SSL第一次握手结束之后，客户端以Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文已用步骤3里边公开密钥进行加密。
- 6、接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用Pre-master secret密钥加密。
- 7、客户端发送Finished报文。该报文包含连接至今全部保温的整体校验值。这次握手协商能否成功，要以服务器是否能够正确解密该报文作为判定标准。
- 8、服务器同样发送 Change Cipher Spec 报文。
- 9、服务器同样发送Finished报文。
- 10、服务器和客户端的Finished报文。
- 11、应用层协议通信，即发送HTTP响应。
- 12、最后由客户端断开连接。断开连接时，发送close_notify 报文。上图做了一些省略，这步之后再发送TCP FIN报文来关闭TCP的通信。
在以上流程中，引用陈发送数据时会附带一种叫做MAC(Message Authentication Code)的报文摘要。MAC能够查知报文是否遭遇篡改，从而保护报文的完整性。
下面是对整个流程的图解。图中说明了从仅使用服务器端的公开密钥证书(服务器证书)建立HTTPS通信的整个过程。
CAC模式(Cipher Block Chaining)又名密码分组链接模式。再次模式下，将前一个明文块加密处理后和下一个明文块做XOR算法，使之重叠，然后在对运算结果做加密处理。对第一个明文块加密时，要么使用前一段秘闻的最后一块，要么利用外部生成的初始向量。
2.3.1、SSL和TLS
HTTP使用SSL(Secure Socket Layer) 和TLS(Transport Layer Security) 这两个协议。
SSL技术最初是有浏览器开发商网景通信公司率先倡导的，开发锅SSL3.0之前的版本。目前主导权已经转移到了IETF(Internet Engineering Task Force,Internet 工程任务组)的手中。
IETF 以SSL3.0为基准，后又制定了TLS1.0、TLS1.1和TLS1.2。TLS是以SSL为原型开发的协议，有时会统一成该协议为SSL。当前主流的版本是SSL3.0和TLS1.0。
由于SSL1.0协议在设计之初被发现出了问题，就没有实际投入使用。SSL2.0也被发现存在问题，所以很多浏览器直接废除了该版本协议。
2.3.2、SSL速度慢吗？
HTTPS也存在一些问题，那就是当使用SSL时，它的处理速度会变慢。
SSL的慢分两种。一种是指通信慢。另一种是指由于更大消耗CPU以及内存等资源，导致处理速度变慢。
和HTTP相比，网络负载可能会变慢2~100倍。除去和TCP链接、发送HTTP请求和响应以外，还必须进行SSL通信，因此基本上处理通信量不可避免会增加。
另一点是SSL必须进行加密处理。在服务器和客户端都需要进行加密和解密运算。因此从结果上来讲，比起HTTP会更多的消耗服务器和客户端的硬件资源，导致负载增强。
针对速度变慢这一问题，并没有根本性的解决方案，我们会使用SSL加速器这种硬件来改善问题。该应该为SSL通信专用硬件，相对软件来讲，能够提高数倍SSL的计算速度。仅在SSL处理时发汇SSL处理器的功效，以分担负载。
2.3.3、为什么不一直使用HTTPS
既然HTTPS那么安全可靠，为啥不是所有的Web网站都一直使用HTTPS？
一个原因是，与纯文本通信相比，加密通信会消耗更多的CPU以及内存资源。如果每次通信都加密，会消耗相当多的资源，平摊到一台计算机上时，能够处理的请求数量必定也会随之减少。
因此，如果是非敏感信息则使用http通信，只有在包含个人信息等敏感数据时，才利用HTTPS加密通信。
特别是每当那些访问量较多的Web网站在进行加密处理时，他们所能承担着的负载不容小觑。在进行加密处理时，并非对所有内容都进行加密处理，而是仅在那些需要信息隐藏时才会加密，以节约资源。
另一个原因就是想要节约购买证书的开销。
要进行HTTPS通信，证书是必不可少的。而使用的证书必须向认证机构买。证书的价格不便宜。那些购买证书并不合算的服务以及一些个人网站，可能只会采用HTTP的通信方式。
