HTTPS协议
HTTP天生"明文"的特点,整个传输过程中完全透明,任何人都能够在链路中截取、修改或者伪造请求/响应报文,数据不具有可信性,因此就诞生了HTTPS协议。使用HTTPS协议时所有HTTP请求和响应在发送到网络之前,都需要进行加密。
HTTPS协议等于HTTP协议加上SSL/TLS协议
SSL/TLS协议
SSL(Secure Socket Layer,安全套接字层):1994年为Netscape所研发,SSL协议位于TCP/IP协议与各种应用层协议之间,为数据通讯提供安全支持。
TLS(Transport Layer Security,传输层安全):其前身是SSL,它最初的几个版本(SSL 1.0、SSL 2.0、SSL 3.0)由网景公司开发,1999年从3.1开始被IETF标准化并改名,发展至今已经有TLS 1.0、TLS 1.1、TLS 1.2三个版本。SSL3.0和TLS1.0由于存在安全漏洞,已经很少被使用到。TLS 1.3改动会比较大,目前还在草案阶段,目前使用最广泛的是TLS 1.1、TLS 1.2。
摘要算法
摘要算法能够把任意长度的数据"压缩"成固定长度、而且独一无二的"摘要"字符串,就好像是给这段数据生成了一个数字"指纹"。任意微小的数据差异,都可以生成完全不同的摘要。所以可以通过把明文信息的摘要和明文一起加密进行传输,数据传输到对方之后再进行解密,重新对数据进行摘要,再比对就能发现数据有没有被篡改。这样就保证了数据的完整性
加密算法
对称加密
编、解码使用相同密钥的算法
客户端提前发送约定好的密钥给服务器,但是为了让服务器知道密钥内容,就必须明文传输,此时如果被黑客劫持,之后发送的密文都可以被黑客劫持的密钥破解
因此我们就需要非对称密钥
非对称加密
非对称加密就是生成一个公钥和一个密钥,通过他们得到对称密钥,因此来进行后面的密文传输
公钥
可以明文传输约定,公钥只能对密文进行加密,但是无法破解密文,因此无论谁拿到公钥都无法破解密文
密钥
密钥由分服务器自己保存,不被其他人知道,客户端使用公钥来对对称密钥进行加密,传输给服务器,服务器通过私钥进行解密,获得对称密钥。此时客户端就可以使用这个对称密钥进行后续的传输工作。
但是由于非对称加密比较慢,对称加密比较快。因此一般使用非对称加密来进行对称密钥的加密传输。而用对称加密来进行后续的传输工作。
但是同样也会有风险
中间人攻击
如果黑客自己也生成一套公钥和密钥来欺骗客户端和服务器
伪装成客户端:获取服务器的公钥A,黑客获取到客户端发送的对称密钥,通过服务器提供的公钥A加密给服务器发送内容,服务器接受后得到对称密钥,之后的发送密文内容就会以这个对称密钥来进行加密。
伪装成服务器:发送自己生成公钥B给客户端,客户端就会以公钥B加密发送对称密钥给黑客,因为与公钥B配套的密钥B也是由黑客自己生成的,所以就可以破解客户端发送的对称密钥
这样,黑客就能得到客户端和服务器之间通信的对称密钥,并且服务器从而破解接下来的传输内容。
证书
服务器(网站)在成立的时候,需要去一些专门的认证机构(第三方机构)申请证书。服务器需要提供一些资质。当申请通过之后,机构就会给你颁发证书。其中,证书中也就包含了公钥。
服务器会把自己的公钥注册到CA(第三方证书机构),然后CA拿自己的私钥对服务器的公钥进行处理并颁发数字证书。
通过这个方法来防止有人伪装成服务器给客户端发送消息
此时客户端申请公钥的时候,此时就不应该只是请求要一个公钥了,而是请求要一个证书。
当客户端拿到证书之后,就可以进行校验。验证证书是不是假的或者被篡改的。如果客户端发现证书是无效的,浏览器就会直接弹框警告
hash2:浏览器利用数字证书的原始信息计算出信息摘要
hash1:用CA的公钥解密数字证书的数字签名,解密的数据就是信息摘要
怎么获取CA的公钥
部署https服务器的时候,除了要部署当前域名的数字证书,还需要部署CA机构的数字证书,CA机构的数字证书包含了CA公钥以及机构的一些信息。
在建立https连接时,服务器会将当前域名的数字证书、给当前域名签名的CA机构的数字证书一同发送给浏览器,因此浏览器就获取到CA公钥。
客户端(浏览器)拿到证书时,就会对证书的内容验证:
- 判定证书的有效期是否过期;
- 判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构);
- 验证证书是否被篡改:
系统中拿到该证书发布机构的公钥, 对签名解密, 得到一个 hash 值(称为数据摘要/签名), 设为 hash2; 然后计算整个证书的 hash 值, 设为 hash1
虽然公钥是可以获取的,但因为黑客无法获取证书的密钥(保存在CA机构中),因此无法伪装成服务器且无法对签名篡改后重新加密(防止中间人攻击,黑客就无法伪装成服务器,浏览器不会信任黑客提供的假密钥,因此黑客拿到证书信息和公钥,也无法破解后续浏览器发送的密文的内容)
浏览器对比 hash1 和 hash2 是否相等,如果相等, 则说明证书是没有被篡改过的
本地数字证书是浏览器保存的一种缓存,用于加速对已知证书的验证。当用户再次访问同一网站时,浏览器可以通过本地存储的证书快速验证其有效性,而无需重新从CA获取证书。
知道上面的加密相关的细节之后,我们来数理一遍HTTPS连接的全过程
HTTPS连接全过程
1、首先呢,客户端先向服务端发送加密通信(https)请求,这次请求中包括:
- SSL/TSL版本号
- 加密套件,也就是客户端支持的加密算法列表
- 产生一个随机数,我们叫他为第1随机数
- 有一个Client Hello字符串
2、服务器收到请求后,向客户端发出响应:
- 确认SSL/TSL版本号,如果客户端不支持,那么就关闭通信
- 确认的加密算法列表
- 生成一个随机数,我们叫第2随机数
3、服务器再向客户端发送数字证书。(上文中有写数字证书的验证)服务器会把自己的公钥注册到CA(第三方证书机构),然后CA拿自己的私钥对服务器的公钥进行处理并颁发数字证书。
4、服务器将公钥发送给客户端
5、服务器发送Hello Done,表示发送完毕
6、客户端收到服务端一系列响应后,确认数字证书和公钥,没有问题后向服务端发送:
- 生成一个随机数,我们叫第3随机数或者预主密钥,此预主密钥会通过公钥进行加密
- 客户端握手结束通知,表示客户端的握手结束
7、服务端收到客户端数据后,使用私钥对加密后的预主密钥进行解密,没有其他人知道预主密钥,因为它加密了,除非服务器私钥泄漏。然后服务端通过第一、二、预主密钥计算出会话密钥。客户端也计算出了会话密钥。
8、服务端向客户端发送:
- 加密通信算法改变通知,以后通过会话密钥通信
- 服务端握手结束
到此为止,SSL/TSL握手结束,在此之后都会通过会话密钥来进行加密和解密,也就是对称加密。
本文结合了csdn上的相关文章汇总出来的HTTPS传输教程,部分图片直接搬运上来了,希望对读者有帮助!
(仅做技术交流分享)