SSL/TLS
HTTP协议传输数据是明文传输,任意的人抓包就能看到传输的数据,这显然不安全。1994年,Netscape公司用加密协议增加了HTTP,开始在HTTP的基础上加入SSL(Secure Socket Layer)。称为"HTTP over SSL"或者"HTTP Secure",也就是我们现在熟知的HTTPS。
TLS(Transport Layer Security,传输层安全协议)是IETF制定的一种新的协议,TLS1.0是建立在SSL3.0协议规范之上,是SSL3.0协议的后续版本,可以理解为SSL3.1。
TLS加密方式
SSL/TLS分为对称加密和非对称加密两种方式。
对称加密是指加密和解密都用同一份密钥(只有一个KEY),常见的有:AES-128,AES-192,AES-256。
非对称加密对应于一对密钥,称为私钥和公钥,用私钥加密后需要用公钥解密,用公钥加密后需要用私钥解密,常见的有:RSA、DSA/DSS。
对称加密的优点是运算速度快,缺点是互联网环境下无法将密钥安全的传送给对方。非对称加密的优点是可以安全的将公钥传递给对方,但是运算速度慢。
https先采用非对称加密传输协商对称加密的密钥,然后用对称加密通信。
HTTPS加解密过程
HTTPS的非对称和对称加解密过程:
- 客户端浏览器发起连接。
- WEB服务器将公钥发给客户端。
- 客户端生成一个session key,并且将session key用公钥加密后发送给服务器。
- 服务器用私钥将session key解密出来。
- 客户端和服务器用session key做对称加密通信。
整个流程可以这样抽象,但是实际上session key的生成是需要多次协商的结果(文章后面会讲到),我们暂且这样简单的理解。整个流程会有一个问题,第2步中WEB服务器发给客户端的公钥,万一被中间人修改了呢,换句话说,客户端怎么验证公钥的正确性呢?那就需要SSL证书。
HTTPS握手
客户端通过发送Client Hello消息给服务器初始化Session连接,Client Hello 消息包含以下字段:
SSL/TLS 版本号。version 2 表示的是SSL 2.0,version 3 表示的是SSL 3.0,version 3.1表示的是TLS 1.0。
随机数Random_C。一共32个字节。前面4个字节是当前时间戳,后面28个字节是一个随机数。后面协商对称加密的Session Key会用到。
Session ID。如果是之前已经存在的连接重连,那么Session ID会是一串数字,否则是None。
Cipher Suite。支持的加密组件列表。例如TLS_RSA_WITH_DES_CBC_SHA, TLS 是TLS协议版本,TLS表示TLS1.0,RSA是密钥交换算法,DES_CBC是加密算法,SHA是摘要算法。
压缩算法。表示建议选用的是哪种压缩算法。
Server Hello. 服务器收到客户端的Client Hello 消息会响应一个Server Hello 消息,包括以下字段:
SSL/TLS 版本,客户端和服务器都支持的SSL/TLS最高版本。
随机数Random_S,一共32个字节,前面4个字节是当前时间戳,后面28个字节是一个随机数。后面协商对称加密的Session Key会用到。
Session ID,这里会有三种情况。1.产生一个新的Session ID,表示没有找到之前的Session ID或者之前没有这个Session ID。2. 返回客户端带上的之前的Session ID。(断链重连)3.Null,服务器没有办法产生新的Session ID。
Cipher Suite,服务器从刚才Client Hello消息的Cipher Suite加密列表中选中的加密组件。
压缩算法,表示选中的是哪种压缩算法。
client Hello 示例:
ClientVersion 3,1 ClientRandom[32] SessionID: None (new session) Suggested Cipher Suites: TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA Suggested Compression Algorithm: NONE
server hello 示例:
Version 3,1 ServerRandom[32] SessionID: bd608869f0c629767ea7e3ebf7a63bdcffb0ef58b1b941e6b0c044acb6820a77 Use Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA Compression Algorithm: NONE
服务器发完Sever Hello 后还会发送下面几条消息:
Server Certificate.服务器发给客户端的证书,包含公钥。客户端后面会用该密钥加密premaster secret。客户端也会校验证书的合法性,比如证书包含的域名是否就是客户端正在访问的域名。
Server Key Exchange.[可选]当服务器的证书不包含公钥时,客户端会用它来加密后面的Client Key Exchange消息。
Client Certificate Request.[可选]用于服务器需要验证客户端身份的情况,例如银行系统通常用U盾来证明客户端的身份。
Server Hello Done.表示Server已经发送消息完毕并且在登陆客户端回复。
客户端紧接着响应给服务器的消息:
Client Certificate.[可选]客户端证书,包括客户端的公钥。响应上面的Client Certificate Request。
Client Key Exchange.该消息包括premaster secret,TLS的版本号,再次带上版本号是因为之前的版本号是明文传输的,攻击者可能会恶意修改为较低的版本号,从而降低连接的安全系数方便发起攻击。该消息字段会用公钥加密。现在一共有Random_C,Random_S, premaster secret三个随机数,客户端和服务器端会用相同的算法,用这三个随机数作为参数,从而计算得到另外的一个随机数,即后面对称加密的密钥Session Key。
Certificate Verify.[可选]该消息只针对有Client Certificate的情况。会计算出该消息字段的HASH,然后用客户端的私钥加密该HASH作为签名。服务器端会使用Client Certificate消息中得到的客户端公钥解密并验证这条消息的合法性。
Change Cipher Suite.该消息通知服务器接下来的Client Finish消息将会用刚才协商的密钥Session Key来加密。
Client Finished.该消息会列举客户端上面用到的所有加密字段,并且算出他们的HASH值,然后用Session Key加密。
服务器在握手阶段最后回应给客户端的消息:
Change Cipher Suite Message.该消息通知客户端接下来的消息会用Session Key来加密。
Sever Finished Message. 对整个协商阶段用到的字段算一个HASH,然后用Session Key加密。
SSL证书
在握手过程中,网站会向浏览器发送SSL证书,SSL证书和我们日常用的身份证类似,是一个支持HTTPS网站的身份证明,SSL证书里面包含了网站的域名,证书有效期,证书的颁发机构以及用于加密传输密码的公钥等信息,由于公钥加密的密码只能被在申请证书时生成的私钥解密,因此浏览器在生成密码之前需要先核对当前访问的域名与证书上绑定的域名是否一致,同时还要对证书的颁发机构进行验证,如果验证失败浏览器会给出证书错误的提示。
如上图所示,公钥内容的后面是会跟上一个数字签名,该数字签名是将公钥内容的HASH用私钥加密后的密文。客户端拿到公钥后,会用相同的HASH算法重新算一遍,得到一个HASH值hash1。然后用公钥解密数字签名得到HASH值hash2,如果hash1等于hash2就证明这个公钥是没有被中间人修改的。即使中间人修改了公钥的内容,他也没有私钥可以重新生成数字签名,用户拿到修改后的公钥一算发现HASH不对就会报错。
证书安全
对HTTPS最常见的攻击手段就是SSL证书欺骗或者叫SSL劫持,是一种典型的中间人攻击。不过SSL劫持并非只是用于攻击目的,在一些特殊情况下利用SSL劫持我们可以更顺畅的访问网络,我会在后文提到。
以攻击为目的的SSL劫持如果不注意浏览器安全提示的话,很容易就中招。当网络中有中间人发起SSL劫持攻击时,攻击者需要伪造一个SSL证书发给浏览器,这个时候由于伪造的SSL证书不受信任,浏览器会给出提示。
证书验证
完整性验证
使用RAS公钥加密来验证证书上的签名是否合法,如果签名无效,则可认定证书被修改,直接报错。有效性验证
CA在颁发证书时,都为每个证书设定了有效期。包括开始时间与结束时间。系统当前时间不在证书起止时间的话,都认为证书是无效的。吊销状态验证
当用户需要吊销证书了,那么这里就多了一个证书吊销状态的检测。用户将需要吊销的证书通知到CA服务商,CA服务商通知浏览器该证书的撤销状态。-
发行者验证
HTTPS数字证书的使用分两个角色
证书发行方issuer,有签名密钥的私钥
证书申请方subject,使用证书公钥进行身份验证的用户
浏览器检查证书的发行者字段与证书路径中上级证书的Suject字段相同。
为了增加安全性,大多数PKI实现还验证发型方的密钥、签名跟当前证书的密钥相同。 但对于信任链来说,根证书自己签发的,也就是说它们的issuer和subject是一样的。
同时,这些CA根证书都是被操作系统、浏览器等直接打入系统的。
域名规范验证
中间CA提供了对域名证书的管理以及颁发颁发的颗粒度度控制。证书的生效范围会限于固定域名、域名范围(包括子域)或者固定IP。策略约束验证
法律策略相关检测。
吊销状态验证
-
Certificate Revocation Lists (CRL)
CA会定期更新发布撤销证书列表,CRL分布在公共可用的存储库中,浏览器可以在验证证书时获取并查阅CA的最新CRL。
该方法的一个缺陷是撤销的时间粒度限于CRL发布期。只有在计划更新所有当前发布的CRL之后,才会通知浏览器撤销。
各家签名CA厂商的策略不一样,有的是几小时,有的是几天,甚至几周。
CA证书厂商的CRL数量不一,大部分是30-50个,而GoDaddy有300多个CRL的地址,同时有近30W个证书是吊销状态的,文件大小平均达到了1M。
在浏览器去校验证书合法性时,还要去下载一个1M的文件后,再去校验。校验通过后才去连想要访问的网站服务器,这相当浪费时间、效率。
同时,很多浏览器所处网络是有网络访问限制的,可能在一个局域网,比如我们村,或者物理距离非常远,存在严重的网络延迟问题。
Onlie Certificate Status Protocol(OCSP)
为了解决单个文件大,延迟性高等问题,迎来了新的解决方案Onlie Certificate Status Protocol(以下简称OCSP)。
在RFC2560X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP的描述中,浏览器从在线OCSP服务器(也称为OCSP Response Server)请求证书的撤销状态,OCSP Server予以响应。这种方法避免CRL更新延迟问题。同样的,X.509 v3证书的OCSP信息也是存储在拓展信息中。
浏览器在获得Web服务器的公钥证书后,开始验证公钥的合法性,这里会向该公钥的扩展信息中提供的OCSP Server地址发送OCSP Response,获得响应后,确认证书有效,再继续跟Web服务器通信。
OCSP优点:相对于CRL方式,证书吊销后,CA Server可以立刻将吊销信息发送给浏览器,生效时间快。响应包内容短,不像CRL的响应包,都将近1M以上。
OCSP缺点:
浏览器的每次HTTPS请求创建,都需要连接CA OCSP Server进行验证,有的浏览器所在IP与CA OCSP Server的网络并不是通畅的。而且,OCSP的验证有网络IO,花费了很长的时间,严重影响了浏览器访问服务器的用户体验。
在浏览器发送服务器HTTPS证书序号到CA OCSP Server时,也将暴露了用户的隐私,将用户访问的网址透漏给了CA OCSP Server。
- OCSP stapling
OCSP Stapling的方案是解决了CRL、OCSP的缺点,将通过OCSP Server获取证书吊销状况的过程交给Web 服务器来做,Web 服务器不光可以直接查询OCSP信息,规避网络访问限制、OCSP服务器离用户的物理距离较远等问题,还可以将查询响应缓存起来,给其他浏览器使用。由于OCSP的响应也是具备CA RSA私钥签名的,所以不用担心伪造问题。
解决了访问慢的问题
解决了用户隐私泄露的问题
参考资料
《你不在意的HTTPS证书吊销机制》(https://zhuanlan.zhihu.com/p/75475419)
《HTTPS与SSL证书概要》(https://zhuanlan.zhihu.com/p/75475419)