第七章：确保WEB安全的HTTPS
引言
- 在HTTP请求中可能存在信息窃听身份伪装等问题
- 使用HTTPS通信机制可以有效防止这些问题
HTTP的缺点
缺点
- 内容使用明文（不加密），可能会被窃听
- 不验证通信双方的身份，可能会遭遇伪装
- 无法验证报文完整性，所以可能已经篡改
通信使用明文可能会被窃听
- 由于HTTP本身不具备加密功能，所以HTTP报文以明文形式进行发送
- 由于TCP/IP协议本身的工作机制，导致报文可能会被通信线路上的任何一个环节被窃听
- 加密处理防止被窃听
- 通信的加密：HTTP 协议中没有加密机制，但可以通过和 SSL（Secure Socket Layer，安全套接层）或TLS（Transport Layer Security，安全层传输协议）的组合使用，加密 HTTP 的通信内容。
- 用SSL建立安全通信线路之后，就可以在这条HTTP通信线路上通信了，与SSL组合的HTTP被称之为HTTPS或者HTTP over SSL
- 内容的加密：将HTTP报文的内容进行加密，但是要求服务器端和客户端具有相同的加密和解密机制，由于没有像不同于SSL和TLS将整个通信线路加密，所以仍然有被篡改的风险
不验证通信方的身份就可能遭遇伪装
- HTTP请求和响应不会对通信方进行确认
- 任何人都可以发起请求
- 在HTTP协议中，不存在确认通信方的处理步骤不管对方是谁都会返回一个响应（但也仅限于发送端的 IP 地址和端口号没有被 Web 服务器设定限制访问的前提下）
- 无法确定请求发送至目标的 Web 服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的 Web 服务器
- 无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端
- 无法确定正在通信的对方是否具备访问权限。因为某些Web 服务器上保存着重要的信息，只想发给特定用户通信的权限
- 即使是无意义的请求也会照单全收，无法阻止海量请求的Dos攻击（Denial of Service，拒绝服务攻击）
- 查明对方的证书
- 使用SSL证书机制可以确认对方身份
- 证书由值得信赖的第三方机构颁发， 用于确认通信双方真实存在
HTTP学习笔记（7）—— 确保WEB安全的HTTPS
无法验证报文完整性，可能已经被篡改
- 所谓完整性是指信息的准确度。若无法证明其完整性，通常也就意味着无法判断信息是否准确
- 接收到的内容可能有误
- 由于 HTTP 协议无法证明通信的报文完整性，因此，在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉。
HTTP学习笔记（7）—— 确保WEB安全的HTTPS - 如何防止篡改
- 常用的是 MD5 和 SHA-1 等散列值校验的方法，以及用来确认文件的数字签名方法来确认报文完整性
- 可惜的是，用这些方法也依然无法百分百保证确认结果正确
- 为了有效防止这些弊端，有必要使用 HTTPS。SSL提供认证和加密处理及摘要功能
HTTP+ 加密 + 认证 + 完整性保护=HTTPS
HTTP 加上加密处理和认证以及完整性保护后即是HTTPS
HTTPS 是身披 SSL 外壳的 HTTP
- HTTPS并非是一种新的通信协议，只是HTTP通信接口部分用SSL和TLS协议代替
- 通常HTTP是直接和TCP通信，采用HTTPS之后，先和SSL通信，然后SSL和TCP通信
- SSL是独立于 HTTP 的协议，运行在应用层的SMTP和Telent等协议均可配合SSL协议使用
- SSL是世界上应用最广泛的 网络安全技术
相互交换秘钥的公开秘钥加密技术
- 加密和解密都会用到密钥。没有密钥就无法对密码解密，反过来说，任何人只要持有密钥就能解密了。如果密钥被攻击者获得，那加密也就失去了意义
- 共享秘钥加密的困境
- 加密和解密同用一个密钥的方式称为共享密钥加密（Common keycrypto system），也被叫做对称密钥加密。
HTTP学习笔记（7）—— 确保WEB安全的HTTPS
- 共享秘加密时，也会将秘钥发送给对方，可究竟怎样才能实现安全地转交
- 使用两把秘钥的公开秘钥加密
非对称加密方式很好的解决了共享秘钥加密的困难
该方式使用对方的公钥进行加密，然后对方使用自己的私钥进行解密
- HTTPS采用共享加密机制
- HTTPS采用共享秘钥加密和公开秘钥加密两者并用的混合秘钥加密
- 如果秘钥能够实现安全交换，那么可能会考虑仅使用公开秘钥加密
- 共享秘钥加密处理的速度回更快
- 所以在交换秘钥环节使用公开秘钥加密，建立通信之后就可以使用共享秘钥加密
HTTP学习笔记（7）—— 确保WEB安全的HTTPS
证明公开秘钥准确性的证书
- 公开秘钥无法证明公开秘钥本身就是货真价实的公开秘钥
- 为了解决上述问题，可以使用由数字证书认证机构（CA，CertificateAuthority）和其相关机关颁发的公开密钥证书
- 首先，服务器的运营人员向数字证书认证机构提出公开密钥的申请。数字证书认证机构在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起
- 此处认证机关的公开密钥必须安全地转交给客户端。使用通信方式时，如何安全转交是一件很困难的事，因此，多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥
可证明组织真实性的 EV SSL 证书
- 证书的一个作用是用来证明作为通信一方的服务器是否规范，另外一个作用是可确认对方服务器背后运营的企业是否真实存在。拥有该特性的证书就是 EV SSL证书（Extended Validation SSLCertificate）。
- 持有 EV SSL证书的 Web 网站的浏览器地址栏处的背景色是绿色的，从视觉上就能一眼辨别出
用于确认客户端的客户端证书
- 想获取证书时，用户得自行安装客户端证书。但由于客户端证书是要付费购买的，且每张证书对应到每位用户也就意味着需支付和用户数对等的费用。另外，要让知识层次不同的用户们自行安装证书，这件事本身也充满了各种挑战
- 客户端证书存在的另一个问题点是，客户端证书毕竟只能用来证明客户端实际存在，而不能用来证明用户本人的真实有效性。也就是说，只要获得了安装有客户端证书的计算机的使用权限，也就意味着同时拥有了客户端证书的使用权限。
认证机构信誉第一
- 因为伪造证书上有正规认证机构的数字签名，所以浏览器会判定该证书是正当的。当伪造的证书被用做服务器伪装之时，用户根本无法察觉到
- 虽然存在可将证书无效化的证书吊销列表（Certificate RevocationList，CRL）机制，以及从客户端删除根证书颁发机构（RootCertificate Authority，RCA）的对策，但是距离生效还需要一段时间，而在这段时间内，到底会有多少用户的利益蒙受损失就不得而知了。
由自认证机构颁发的证书称为自签名证书
- 如果使用 OpenSSL这套开源程序，每个人都可以构建一套属于自己的认证机构，从而自己给自己颁发服务器证书。但该服务器证书在互联网上不可作为证书使用，似乎没什么帮助
HTTPS的安全通信机制
- ＨＴＴＰＳ的通信步骤
- 客户端发送Client Hello报文开始的SSL通信，报文中包含客户端支持的 SSL的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）
- 服务器可进行SSL通信时会以Server Hello作为应答，。和客户端一样，在报文中包含 SSL版本以及加密件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
- 之后服务器发送 Certificate 报文。报文中包含公开密钥证书
- 最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL握手协商部分结束
- SSL第一次握手结束之后，客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-mastersecret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。
- 接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret 密钥加密
- 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准
- 服务器同样发送 Change Cipher Spec 报文
- 服务器同样发送 Finished 报文。
- 服务器和客户端的 Finished 报文交换完毕之后，SSL连接就算建立完成。当然，通信会受到 SSL的保护。从此处开始进行应用层协议的通信，即发送 HTTP 请求
- 最后由客户端断开连接。断开连接时，发送 close_notify 报文。上图做了一些省略，这步之后再发送 TCP FIN 报文来关闭与 TCP的通信。
- 在以上流程中，应用层发送数据时会附加一种叫做 MAC（MessageAuthentication Code）的报文摘要。MAC 能够查知报文是否遭到篡改，从而保护报文的完整性
- HTTPS要比HTTPS慢2-100倍
- 一般非敏感信息会使用HTTP通信，设计资金，个人信息等才会使用HTTPS进行通信
- 而且并非所有内容都进行加密，只是在涉及到概要隐藏的资源时才应该加密