第七章 确保Web安全的HTTPS
7.1 HTTP的缺点
7.2 HTTP+加密+认证+完整性保护 = HTTPS心得:
网络安全的简单内容,可以了解到HTTPS是什么,这个通信机制可以有效的防止什么问题。
HTTP的三个问题:传输的内容被窃听,服务器无法确定,客户端无法确定。
通常,HTTP 直接和 TCP 通信。当使用 SSL时,则演变成HTTP先和 SSL通信,再由 SSL和 TCP 通信了。采用 SSL后,HTTP 就拥有了 HTTPS 的加密、证书和完整性保护这些功能。SSL是独立于 HTTP 的协议,所以不光是 HTTP 协议,其他运行在应用层的 SMTP 和 Telnet 等协议均可配合 SSL协议使用。
HTTPS如何进行加密呢? 比如两把密钥加密机制、混合加密机制
那HTTPS加密造成的一些不足是什么呢?HTTPS响应比HTTP慢
7.1 HTTP的缺点
HTTP主要的不足有如下:
- 通信使用明文(不加密),内容可能会被窃听。
- 不验证通信方的身份,因此有可能遭遇伪装
- 无法证明报文的完整性,所以有可能已遭篡改
- …
**7.1.1 通信使用明文可能被窃听 **
由于HTTP本身不具有加密的功能,所以无法做到对通信整体(使用HTTP协议通信的请求和响应的内容)进行加密。即,HTTP报文使用明文(指未经过加密的报文)方式发送。
-
TCP/IP可能被监听
如果要问为什么通信时不加密是一个缺点 ,那就是可能被窃听(即使是被加密的信息也可能被窃听)。如果通信经过加密,就有可能让人无法破解报文信息的含义,但加密处理后的报文信息本身还是会被看到的。窃听相同段上的通信并非难事。只需要收集在互联网上流动的数据包(帧)就行了。对于收集来的数据包的解析工作,可交给那些抓包(Packet Capture)或嗅探器(Sniffer)工具。 -
通信的加密
HTTP通过和SSL(安全套接层)或TLS(安全层传输协议)的组合使用,加密HTTP的通信内容。用SSL建立安全通信线路之后,可以在这条线路上进行HTTP通信。和SSL组合的HTTP就成为HTTPS(HTTP Secure,超文本传输安全协议)或HTTP over SSL。
-
内容的加密
直接对参与通信的内容本身加密的方式。由于HTTP协议里没有加密机制,那就把HTTP报文里所含的内容进行加密处理即可。由于该方式不同于 SSL或 TLS 将整个通信线路加密
处理,所以内容仍有被篡改的风险。
7.1.2 不验证通信方的身份可能遭遇伪装
HTTP 协议中的请求和响应不会对通信方进行确认。也就是说存在“服务器是否就是发送请求中 URI 真正指定的主机,返回的响应是否真的返回到实际提出请求的客户端”等类似问题。 -
任何人都可能发起请求
在HTTP协议通信时,由于不存在确定通信方的处理步骤,任何人都可以发起请求。另外,服务器收到请求不论对方身份都会返回响应。因此存在一下隐患:
无法确定请求发送至目标Web服务器是否按照真实意图返回响应的服务器,可能是已伪装的Web服务器。
无法确定响应返回到的客户端是否按照真实的意图接受响应的那个客户端,可能是已伪装的客户端。
无法确定正在通信的对方是否具有访问权限。
即使是无意义的请求也会被接受,无法阻止海量请求下的DoS(Denial of Service,拒绝服务攻击)。
无法判断请求是来自何方,出自谁手。
- 查明对手的证书
虽然使用HTTP协议无法确定通信方,但是使用SSL可以。SSL不仅提供加密处理,而且使用被称为证书的手段确认通信方。
证书由值得信任的第三方机构颁发,用以证明服务器和客户端是存在的。(伪造证书从技术儿说很难) 通过使用证书,以证明通信方就是意料中的服务器。这对使用者个人来讲,也减少了个人信息泄露的危险性。另外,客户端持有证书即可完成个人身份的确认,也可用于对Web 网站的认证环节。
7.1.3 无法证明报文完整性,可能已遭到篡改
所谓完整性就是信息的准确度。若无法证明完整性,通常以为无法判断信息是否准确
-
接收到内容可能有误‘
由于HTTP协议无法证明通信的报文完整性,因此,在请求或响应送出之后直到对方接受之前的时间,请求遭到篡改也无法获悉。像这样,请求或响应在传输途中,遭攻击者拦截并篡改内容的攻击称为中间人攻击(Man-in-the-Middle attack,MITM)。
-
如何防止篡改
虽然有使用 HTTP 协议确定报文完整性的方法,但事实上并不便捷、可靠。其中常用的是 MD5 和 SHA-1 等散列值校验的方法,以及用来确认文件的数字签名方法。
提供文件下载服务的 Web 网站也会提供相应的以 PGP(Pretty Good Privacy,完美隐私)创建的数字签名及 MD5 算法生成的散列值。PGP 是用来证明创建文件的数字签名,MD5 是由单向函数生成的散列值。不论使用哪一种方法,都需要操纵客户端的用户本人亲自检查验证下载的文件是否就是原来服务器上的文件。浏览器无法自动帮用户检查。
为了有效防止这些弊端,有必要使用 HTTPS。SSL提供认证和加密处理及摘要功能。
7.2 HTTP+ 加密 + 认证 + 完整性保护=HTTPS
7.2.1 HTTP 加上加密处理和认证以及完整性保护后即是HTTPS
使用HTTPS进行通信的时候,使用https://。另外,当浏览器访问 HTTPS 通信有效的 Web 网站时,浏览器的地址栏内会出现一个带锁的标记。对 HTTPS 的显示方式会因浏览器的不同而有所改变。
7.2.2 HTTPS的通信过程
通常,HTTP 直接和 TCP 通信。当使用 SSL时,则演变成HTTP先和 SSL通信,再由 SSL和 TCP 通信了。采用 SSL后,HTTP 就拥有了 HTTPS 的加密、证书和完整性保护这些功能。SSL是独立于 HTTP 的协议,所以不光是 HTTP 协议,其他运行在应用层的 SMTP 和 Telnet 等协议均可配合 SSL协议使用。
7.2.3 相互交换密钥的公开加密技术
SSL采用一种叫做公开密钥加密(Public-key cryptography)的加密处理方式。近代的加密方法中加密算法是公开的,而密钥却是保密的。通过这种方式得以保持加密方法的安全性。如果密钥被攻击者获得,那加密也就失去了意义。
- 共享密钥加密的困境
加密和解密用用一个密钥的方式称为共享密钥加密(Common key crypto system),也被称为对称密钥加密。
以共享密钥方式加密时必须将密钥也发给对方。可究竟怎样才能安全地转交?
- 使用两把密钥的公开加密
公开的加密使用非对称密钥,一把是私有密钥,另一把是公开密钥。私有密钥不让其他人直到,公开密钥可以随意发布,任何人可获得。
使用公开密钥加密方式,发送密文的一方使用对方的公开密钥进行加密处理,对方收到被加密的信息后,再使用自己的私有密钥进行解密。利用这种方式,不需要发送用来解密的私有密钥,也不必担心密钥被攻击者窃听而盗走。
另外,要想根据密文和公开密钥,恢复到信息原文是异常困难的,因为解密过程就是在对离散对数进行求值,这并非轻而易举就能办到。退一步讲,如果能对一个非常大的整数做到快速地因式分解,那么密码破解还是存在希望的。但就目前的技术来看是不太现实的。
- HTTPS采用混合加密机制
HTTPS采用共享密钥加密和公开密钥加密两者并用的混合加密机制。若密钥可以实现安全交换,有可能会考虑仅使用公开密钥来通信。但是公开密钥加密和共享密钥加密相比,器处理速度要慢。
所以应充分利用两者各自道德优势,将多种方法组合起来用于通信。在交换密钥环节使用公开密钥加密方式,之后的建立通信交换报文阶段则使用共享密钥加密方式。
**7.2.4 证明公开密钥正确性的证书 **
正准备和某台服务器建立公开密钥加密方式下的通信时,如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥。或许在公开密钥传输途中,真正的公开密钥已经被攻击者替换掉了?
公开密钥加密的方式存在一些问题,无法证明公开密钥本身就是货真价实的公开密钥。使用由数字证书认证机构(Certificate Authority)和其他机关颁发的公开密钥证书。
数字证书认证机构处于客户端和服务器双方都可信赖的第三方机构的立场上。
- 服务器的运营人员向数字证书认证机构提出公开密钥的申请。数字证书认证机构在判明提出申请者的身份之后,会对已申请的公开密钥做数字签名,然后分配这个已签名的公开密钥,并将该公开密钥放入公钥证书后绑定在一起。
- 服务器将这份由数字证书认证机构颁发的公钥证书发送给客户端,以进行公开密钥加密的方式通信。公钥证书也可以叫做数字证书或直接称为证书。
- 客户端接到证书认证机构的公开密钥,对证书的数字签名进行认证,一旦验证通过,客户端可以认证两件事:一是认证服务器的公开密钥是正是有效的数字证书认证机构;二是服务器的公开密钥是值得信赖的。
和证书相关知识: - 可证明服务器后的组织真实性的EV SSL证书
证书的一个作用是用来证明作为通信一方的服务器是否规范,另外一个作用是可确认对方服务器背后运营的企业是否真实存在。拥有该特性的证书就是 EV SSL证书(Extended Validation SSL Certificate)。
EV SSL证书是基于国际标准的认证指导方针颁发的证书。其严格规定了对运营组织是否真实的确认方针,因此,通过认证的Web 网站能够获得更高的认可度。 - 用以确认客户端的客户端证书
HTTPS 中还可以使用客户端证书。以客户端证书进行客户端认证,证明服务器正在通信的对方始终是预料之内的客户端,其作用跟服务器证书如出一辙。
但是仍有的问题:客户端证书只是证明客户端的计算机可靠,但是机器的使用者不一定是真实用户。 - 认证机构信誉第一
SSL机制中介入认证机构之所以可行,是因为建立在其信用绝对可靠这一大前提下的。然而,2011 年 7 月,荷兰的一家名叫DigiNotar 的认证机构曾遭黑客不法入侵,颁布了 google.com 和twitter.com 等网站的伪造证书事件。这一事件从根本上撼动了SSL的可信度。
虽然存在可将证书无效化的证书吊销列表(Certificate Revocation List,CRL)机制,以及从客户端删除根证书颁发机构(Root Certificate Authority,RCA)的对策,但是距离生效还需要一段时间,而在这段时间内,到底会有多少用户的利益蒙受损失就不得而知了。 - 由自认证机构办法的证书称为自签名证书
独立构建的认证机构叫做自认证机构,由自认证机构颁发的“无用”证书也被戏称为自签名证书。由自认证机构颁发的服务器证书之所以不起作用,是因为它无法消除伪装的可能性。
7.2.5 HTTPS的安全通信机制
- 客户端通过发送 Client Hello 报文开始 SSL通信。报文中包含客户端支持的 SSL的指定版本、加密组件(Cipher Suite)列表(所使用的加密算法及密钥长度等)。
- 服务器可进行 SSL通信时,会以 Server Hello 报文作为应答。和客户端一样,在报文中包含 SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
- 之后服务器发送 Certificate 报文。报文中包含公开密钥证书。
- 最后服务器发送 Server Hello Done 报文通知客户端,最初阶段的 SSL握手协商部分结束。
- SSL第一次握手结束之后,客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。
- 接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器,在此报文之后的通信会采用 Pre-master secret 密钥加密。
- 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功,要以服务器是否能够正确解密该报文作为判定标准。
- 服务器同样发送Change Cipher Spec报文。
- 服务器发送Finished报文
- 服务器和客户端的 Finished 报文交换完毕之后,SSL连接就算建立完成。当然,通信会受到 SSL的保护。从此处开始进行应用层协议的通信,即发送 HTTP 请求。
- 应用层协议通信,即发送HTTP响应
- 最后由客户端断开连接。断开连接时,发送 close_notify 报文。
- 之后再发送 TCP FIN 报文来关闭与 TCP的通信。
应用层发送数据时会附加一种叫做 MAC(Message Authentication Code)的报文摘要。MAC 能够查知报文是否遭到篡改,从而保护报文的完整性。
CBC 模式(Cipher Block Chaining)又名密码分组链接模式。在此模式下,将前一个明文块加密处理后和下一个明文块做 XOR 运算,使之重叠,然后再对运算结果做加密处理。对第一个明文块做加密时,要么使用前一段密文的最后一块,要么利用外部生成的初始向量(initial vector,IV)。
7.2.6 HTTPS的慢?为什么不一直用HTTPS呢?HTTPS 那么安全可靠,那为何所有的 Web 网站不一直使用HTTPS ?
其中一个原因是,因为与纯文本通信相比,加密通信会消耗更多的CPU 及内存资源。如果每次通信都加密,会消耗相当多的资源,平摊到一台计算机上时,能够处理的请求数量必定也会随之减少。如果是非敏感信息则使用 HTTP 通信,只有在包含个人信息等敏感数据时,才利用 HTTPS 加密通信。特别是每当那些访问量较多的 Web 网站在进行加密处理时,它们所承担着的负载不容小觑。在进行加密处理时,并非对所有内容都进行加密处理,而是仅在那些需要信息隐藏时才会加密,以节约资源。
另一个原因是节约购买证书的开销。
HTTPS的慢一种是通信慢,除去和TCP连接、发送HTTP请求并响应请求,还需要和SSL进行通信。
SSL的慢分两种,第一种是通信慢,另一种是由于 SSL必须进行加密处理。在服务器和客户端都需要进行加密和解密的运算处理,比起 HTTP会更多地消耗服务器和客户端的硬件资源,负载增强,导致的处理速度变慢。 所以HTTPS通常比HTTP会慢2到100倍。
针对速度变慢这一问题,并没有根本性的解决方案,我们会使用SSL加速器这种(专用服务器)硬件来改善该问题。该硬件为SSL通信专用硬件,相对软件来讲,能够提高数倍 SSL的计算速度。仅在 SSL处理时发挥 SSL加速器的功效,以分担负载。