图解http协议－https协议（五）-CSDN博客

本文链接：https://blog.csdn.net/cotexarm7/article/details/81027395

第7章确保web安全的https协议

7.1 http的缺点

1.通信使用明文，不加密，内容可能会被窃听

2.不验证通信方的身份，因此有可能遭遇伪装

3.无法证明报文的完整性，有可能被篡改。

总结：通信双方的身份是假的、内容是假的、通信双方和内容是真的但是被第三方拿到了

7.1.1 内容被盗

解决办法：通信加密和内容加密

http协议和ssl协议结合，ssl对通信加密，防止内容被窃听

7.1.2 身份是假的

无法确定请求发送至目标的 Web 服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的 Web 服务器。

无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端。

无法确定正在通信的对方是否具备访问权限。因为某些 Web 服务器上保存着重要的信息,只想发给特定用户通信的权限。无法判定请求是来自何方、出自谁手。

即使是无意义的请求也会照单全收。无法阻止海量请求下的 DoS 攻击(Denial of Service,拒绝服务攻击)。

解决办法：ssl不仅可以对通信加密，还提供了证书，用于确定发送方和接收方

证书由值得信任的第三方机构颁发,用以证明服务器和客户端是实际存在的。另外,伪造证书从技术角度来说是异常困难的一件事。所以只要能够确认通信方(服务器或客户端)持有的证书,即可判断通信方的真实意图。

通过使用证书,以证明通信方就是意料中的服务器。这对使用者个人来讲,也减少了个人信息泄露的危险性。另外,客户端持有证书即可完成个人身份的确认,也可用于对 Web 网站的认证环节。

7.1.3 内容被篡改

如何防止内容被篡改

提供文件下载服务的 Web 网站也会提供相应的以 PGP(Pretty Good Privacy,完美隐私)创建的数字签名及 MD5 算法生成的散列值。PGP 是用来证明创建文件的数字签名,MD5 是由单向函数生成的散列值。不论使用哪一种方法,都需要操纵客户端的用户本人亲自检查验证下载的文件是否就是原来服务器上的文件。浏览器无法自动帮用户检查。

7.2 HTTP + 加密＋认证＋完整性保护＝HTTPS

7.2.2 HTTPS是身披SSL外壳的HTTP

HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用 SSL(Secure Socket Layer)和TLS(Transport Layer Security)协议代替而已。

http协议是http直接和tcp协议通信，而https是http协议先和ssl协议通信，再由ssl和tcp协议通信。

SSL 是独立于 HTTP 的协议,所以不光是 HTTP 协议,其他运行在应用层的 SMTP 和 Telnet 等协议均可配合 SSL 协议使用。可以说 SSL 是当今世界上应用最为广泛的网络安全技术。

7.2.3 相互交换密钥的公开密钥加密技术

在对ssl讲解之前，先了解下ssl使用的公开密钥加密技术。近代加密方法都是公开加密算法，但是密钥是保密的。但是，如果别人知道了密钥，那么还是不安全的。

加密和解密都使用同一种密钥的加密方式叫对称加密，也叫共享密钥加密。

以共享密钥方式加密时必须将密钥也发给对方。可究竟怎样才能安全地转交?在互联网上转发密钥时,如果通信被监听那么密钥就可会落入攻击者之手,同时也就失去了加密的意义。另外还得设法安全地保管接收到的密钥。

使用2把密钥的公开密钥加密

使用一对非对称的密钥，一般公开密钥，一把私有密钥，私有密钥不能让任何人知道，公开密钥可以随意传输，任何人都可以获得。

过程为：密文发送方使用对方（接收方）的公开密钥加密，然后接收方使用私有密钥解密。这样就不用担心密钥被盗取。

要根据公开密钥和密文进行解密是十分困难的，相当于对离散对数进行求值，很难办到。

https采用混合加密机制

在交换密钥环节使用公开密钥加密方式，然后利用获得的密钥进行共享密钥加密方式，因为只要能确保共享密钥没有被盗取，那么共享密钥加密方式就是安全的。

证明公开密钥正确性的证书

遗憾的是,公开密钥加密方式还是存在一些问题的。那就是无法证明公开密钥本身就是货真价实的公开密钥。比如,正准备和某台服务器建立公开密钥加密方式下的通信时,如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥。或许在公开密钥传输途中,真正的公开密钥已经被攻击者替换掉了。

为了解决上述问题,可以使用由数字证书认证机构(CA,Certificate Authority)和其相关机关颁发的公开密钥证书。

数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。威瑞信(VeriSign)就是其中一家非常有名的数字证书认证机构。我们来介绍一下数字证书认证机构的业务流程。首先,服务器的运营人员向数字证书认证机构提出公开密钥的申请。数字证书认证机构在判明提出申请者的身份之后,会对已申请的公开密钥做数字签名,然后分配这个已签名的公开密钥,并将该公开密钥放入公钥证书后绑定在一起。

服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端,以进行公开密钥加密方式通信。公钥证书也可叫做数字证书或直接称为证书。

接到证书的客户端可使用数字证书认证机构的公开密钥,对那张证书上的数字签名进行验证,一旦验证通过,客户端便可明确两件事:一,认证服务器的公开密钥的是真实有效的数字证书认证机构。二,服务器的公开密钥是值得信赖的。

此处认证机关的公开密钥必须安全地转交给客户端。使用通信方式时,如何安全转交是一件很困难的事,因此,多数浏览器开发商发布版本时,会事先在内部植入常用认证机关的公开密钥。

可证明组织真实性的EV SSL证书

EV SSL证书一个作用是可以用来证明通信一方的服务器是否规范，另一作用是可确定对方背后服务器背后运营的企业是否真实存在。持有 EV SSL 证书的 Web 网站的浏览器地址栏处的背景色是绿色的,从视觉上就能一眼辨别出。而且在地址栏的左侧显示了 SSL 证书中记录的组织名称以及颁发证书的认证机构的名称。
用以确认客户端的客户端证书

除了服务器端证书，还有客户端证书，以客户端证书进行客户端认证,证明服务器正在通信的对方始终是预料之内的客户端,其作用跟服务器证书如出一辙。

客户端证书的问题：

1.想获取证书时,用户得自行安装客户端证书。但由于客户端证书是要付费购买的,且每张证书对应到每位用户也就意味着需支付和用户数对等的费用。另外,要让知识层次不同的用户们自行安装证书,这件事本身也充满了各种挑战。

现状是,安全性极高的认证机构可颁发客户端证书但仅用于特殊用途的业务。比如那些可支撑客户端证书支出费用的业务。例如,银行的网上银行就采用了客户端证书。在登录网银时不仅要求用户确认输入 ID 和密码,还会要求用户的客户端证书,以确认用户是否从特定的终端访问网银。

客户端证书存在的另一个问题点是,客户端证书毕竟只能用来证明客户端实际存在,而不能用来证明用户本人的真实有效性。也就是说,只要获得了安装有客户端证书的计算机的使用权限,也就意味着同时拥有了客户端证书的使用权限

认证机构信誉第一

SSL 机制中介入认证机构之所以可行,是因为建立在其信用绝对可靠这一大前提下的。然而,2011 年 7月,荷兰的一家名叫 DigiNotar 的认证机构曾遭黑客不法入侵,颁布了 google.com 和 twitter.com 等网站的伪造证书事件。这一事件从根本上撼动了 SSL 的可信度。因为伪造证书上有正规认证机构的数字签名,所以浏览器会判定该证书是正当的。当伪造的证书被用做服务器伪装之时,用户根本无法察觉到。虽然存在可将证书无效化的证书吊销列表(Certificate Revocation List,CRL)机制,以及从客户端删除根证书颁发机构(Root Certificate Authority,RCA)的对策,但是距离生效还需要一段时间,而在这段时间内,到底会有多少用户的利益蒙受损失就不得而知了。

7.2.5 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 报文交换完毕之后,SSL 连接就算建立完成。当然,通信会受到 SSL的保护。从此处开始进行应用层协议的通信,即发送 HTTP 请求。

步骤 11: 应用层协议通信,即发送 HTTP 响应。

步骤 12: 最后由客户端断开连接。断开连接时,发送 close_notify 报文。上图做了一些省略,这步之后再发送 TCP FIN 报文来关闭与 TCP 的通信。

在以上流程中,应用层发送数据时会附加一种叫做 MAC(Message Authentication Code)的报文摘要。MAC 能够查知报文是否遭到篡改,从而保护报文的完整性。

ssl和tls

http使用ssl和tls协议，ssl的缺点是速度慢。

ssl的慢分为2种，1是通信慢，2是是指由于大量消耗 CPU 及内存等资源,导致处理速度变慢。

和使用 HTTP 相比,网络负载可能会变慢 2 到 100 倍。除去和 TCP 连接、发送 HTTP 请求 • 响应以外,还必须进行 SSL 通信,因此整体上处理通信量不可避免会增加。另一点是 SSL 必须进行加密处理。在服务器和客户端都需要进行加密和解密的运算处理。因此从结果上讲,比起 HTTP 会更多地消耗服务器和客户端的硬件资源,导致负载增强。针对速度变慢这一问题,并没有根本性的解决方案,我们会使用 SSL 加速器这种(专用服务器)硬件来改善该问题。该硬件为 SSL 通信专用硬件,相对软件来讲,能够提高数倍 SSL 的计算速度。仅在 SSL处理时发挥 SSL 加速器的功效,以分担负载。

为什么不一直用https

既然 HTTPS 那么安全可靠,那为何所有的 Web 网站不一直使用 HTTPS ?其中一个原因是,因为与纯文本通信相比,加密通信会消耗更多的 CPU 及内存资源。如果每次通信都加密,会消耗相当多的资源,平摊到一台计算机上时,能够处理的请求数量必定也会随之减少。因此,如果是非敏感信息则使用 HTTP 通信,只有在包含个人信息等敏感数据时,才利用 HTTPS 加密通信。特别是每当那些访问量较多的 Web 网站在进行加密处理时,它们所承担着的负载不容小觑。在进行加密处理时,并非对所有内容都进行加密处理,而是仅在那些需要信息隐藏时才会加密,以节约资源。除此之外,想要节约购买证书的开销也是原因之一。