简单聊聊Https的来龙去脉
- [Http 通信具有哪些风险](#Http 通信具有哪些风险)
- [Https = Http + SSL/TLS](#Https = Http + SSL/TLS)
- [对称加密 和 非对称加密](#对称加密 和 非对称加密)
- 数字证书
- Https工作流程
- 一定需要Https吗?
Http 通信具有哪些风险
- 使用明文通信,通信内容可能会被监听
- 不验证通信双方身份,因此可能会遭遇伪装
- 无法验证报文完整性,可能会遭到中间人攻击,从而篡改请求和响应报文中的内容
Https = Http + SSL/TLS
Http 协议直接和TCP进行通信,而 Https 在 Http 和 Tcp 之间加了一层 SSL 实现加密传输 :
SSL ( Secure Socket Layer ) 安全套接层 是一种密码通信框架,于1995年发布了3.0版本,而TLS(Transport Layer Security)传输层安全是在SSL 3.0基础上设计的协议,对SSL的安全性进行增强,相当于SSL的后续版本。
SSL是一个独立的协议,不只有Http可以使用,其他应用层协议如果需要加密支持都可以使用,比如FTP,SMTP等都可以使用SSL来加密。
对称加密 和 非对称加密
常用的加密算法分为两类:
- 对称加密
- 非对称加密
对称加密: 加密和解密使用同一把秘钥,服务器和客户端在通信初始阶段需要协商秘钥,该阶段存在窃听导致秘钥泄露的风险。
非对称加密: 客户端和服务端均拥有一个公钥,服务端单独拥有一个私钥,公钥可以对外暴露,而私钥只有自己可见;使用公钥加密的信息,只有对应的私钥才能破解,反过来,使用私钥加密的消息,只有公钥才能解开。
非对称加密可能存在公钥被拦截,然后被替换为中间人公钥的场景:
或者中间人不替换公钥,但是通过拦截客户端发送的消息,然后篡改,使用服务器公钥加密后再发送,此时服务器将收到错误的消息
非对称加密另一个缺点就是会比对称加密慢上很多。
数字证书
为了解决非对称加密过程中公钥传递的不安全性,人们想到了使用数字证书加上数字签名来解决这个问题。
数字证书的申请
在现实生活中,有一些专门的权威机构用来颁发证书,我们称之为认证中心 CA ,我们的服务器可以向这些CA来申请数字证书,申请流程大致如下:
- 服务器自己本地先生成一对秘钥,然后拿着自己的公钥以及其他信息(企业名称等)去CA申请数字证书。
- CA拿到这些信息后,会选择一种单向Hash算法(比如MD5)对这些信息进行加密,加密后的东西我们称之为摘要
- 单向Hash算法有一种特点就是不可逆,只要原始内容有一点变化,加密后的结果都是不一样的(当然也存在很小的概率会发生重复 -- 鸽巢原理),这样可以防止信息被篡改。
- 比如用于检验IP报文是否完整的校验和,文件上传与下载对于的文件校验和,原理都是一样的
- 生成摘要后,CA还会用自己的私钥对摘要进行加密,摘要加密后的结果我们称之为数字签名
- 最后,CA 会将我们申请的信息(包含服务器公钥)和数字签名整合在一起,由此生成数字证书
- 然后CA把数字证书返回给服务器
数字证书怎么起作用
服务器在获取到数字证书后,服务器会将数字证书发送给客户端,客户端需要用CA的公钥解密数字证书并检验数字证书的合法性,所以,首要问题是如何拿到CA的公钥 ?
我们的电脑和浏览器已经内置了一部分权威机构的根证书,这些根证书包含了CA的公钥:
之所以是根证书,是因为现实生活中,认证中心也是分层级的,类似一个树状结构,虽然计算机中内置的是最顶级机构的根证书,但是根证书的公钥在子级也是适用的。
- 客户端用CA的公钥解密数字证书中的数字签名,如果解密成功说明证书来源于合法认证机构,解密成功后,客户端就可以拿到摘要。
- 然后,客户端按照和CA一样的Hash算法将申请信息(公钥,服务器域名,. . . ) 生成一份摘要,并和解密出来的那份做对比,如果相同说明内容完整,没有被篡改。
- 最后,客户端安全的从数字证书拿到服务器的公钥
- 随后就可以使用公钥和服务器进行安全的非对称加密通信了
Https工作流程
Https = Http + SSL/TLS , 说白了,无非就是在http上披了一层加密的外壳,Https的整个通信流程如下图所示:
- 客户端通过发送Client Hello报文开始通信,报文中包含客户端支持的SSL的指定版本,加密组件(Cipher Suite)列表(所使用的加密算法及密钥长度等)
- 服务器可进行SSL通信时,会以Server Hello报文作为回答,和客户端一样,在报文中包含SSL版本以及加密组件,服务器加密组件内容是从接收到的客户端加密组件内容筛选出来的
- 服务器发送证书报文,报文中包含公开秘钥证书
- 最后,服务器发送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连接就算建立完成了
- 从此处开始进行应用层协议的通信,即发送Http请求,此时的通信过程会受到SSL的保护
- 最后,由客户端端口连接,断开连接时,发送close_notify报文
- 这步之后,再发送TCP FIN报文来关闭与TCP的通信
另外,在以上流程图中,应用层发送数据时会附加一种叫做MAC(Message Authentication Code)的报文摘要。MAC能够查知报文是否遭到篡改,从而保证报文的完整性。
经过上面的介绍,我们可以看出https先是利用数字证书保证服务器端的公匙可以安全无误的到达客户端。然后再用非对称加密安全的传递共享密匙,最后用共享密匙安全的交换数据。
一定需要Https吗?
Https那么的安全,是不是我们在什么场景下都要去使用https进行通信呢?答案是否定的。
- https虽然提供了消息安全传输的通道,但是每次消息的加解密十分耗时,消息系统资源。所以,除非在一些对安全性比较高的场景下,比如银行系统,购物系统中我们必须要使用https进行通信,其他一些对安全性要求不高的场景,我们其实没必要使用https。
- 使用https需要使用到数字证书,但是一般权威机构颁发的数字证书都是收费的,而且价格也是不菲的,所以对于一些个人网站特别是学生来讲,如果对安全性要求不高,也没必要使用https。