HTTPS(全称:Hypertext Transfer Protocol Secure,超文本传输安全协议),是以安全为目标的HTTP通道,简单讲是HTTP的安全版。
为什么需要https
使用https的原因其实很简单,就是因为http的不安全
当我们往服务器发送比较隐私的数据(比如说你的银行卡,身份证)时,如果使用http进行通信。那么安全性将得不到保障。
首先数据在传输的过程中,数据可能被中间人抓包拿到,那么数据就会被中间人窃取。
其次数据被中间人拿到后,中间人可能对数据进行修改或者替换,然后发往服务器。
最后服务器收到数据后,也无法确定数据有没有被修改或替换,当然,如果服务器也无法判断数据就真的是来源于客户端。
总结下来,http存在三个弊端:
无法保证消息的保密性
无法保证消息的完整性和准确性
无法保证消息来源的可靠性
https就是为了解决上述问题应运而生的。
基本概念
https采用了一些加解密,数字证书,数字签名的技术来实现。
对称加密与非对称加密
为了保证消息的保密性,就需要用到加密和解密。加解密算法目前主流的分为对称加密和非对称加密。
1.对称加密(共享密匙加密):客户端和服务器公用一个密匙用来对消息加解密,这种方式称为对称加密。客户端和服务器约定好一个加密的密匙。客户端在发消息前用该密匙对消息加密,发送给服务器后,服务器再用该密匙进行解密拿到消息。
对称加密的优点:
对称加密解决了http中消息保密性的问题
对称加密的缺点:
对称加密虽然保证了消息保密性,但是因为客户端和服务器共享一个密匙,这样就使得密匙特别容易泄露。
因为密匙泄露风险较高,所以很难保证消息来源的可靠性、消息的完整性和准确性。
2.非对称加密(公有密匙加密):既然对称加密中,密匙那么容易泄露,那么可以采用一种非对称加密的方式来解决。
采用非对称加密时,客户端和服务端均拥有一个公有密匙和一个私有密匙。公有密匙可以对外暴露,而私有密匙只有自己可见。
使用公有密匙加密的消息,只有对应的私有密匙才能解开。反过来,使用私有密匙加密的消息,只有公有密匙才能解开。这样客户端在发送消息前,先用服务器的公匙对消息进行加密,服务器收到后再用自己的私匙进行解密
非对称加密的缺点:
非对称加密时需要使用到接收方的公匙对消息进行加密,但是公匙不是保密的,任何人都可以拿到,中间人也可以。那么中间人可以做两件事,第一件是中间人可以在客户端与服务器交换公匙的时候,将客户端的公匙替换成自己的。这样服务器拿到的公匙将不是客户端的,而是服务器的。服务器也无法判断公匙来源的正确性。第二件是中间人可以不替换公匙,但是他可以截获客户端发来的消息,然后篡改,然后用服务器的公匙加密再发往服务器,服务器将收到错误的消息。
非对称加密的性能相对对称加密来说会慢上几倍甚至几百倍,比较消耗系统资源。正是因为如此,https将两种加密结合了起来。
数字证书与数字签名
为了解决非对称加密中公匙来源的不安全性。我们可以使用数字证书和数字签名来解决。
1.数字证书的申请
在现实中,有一些专门的权威机构用来颁发数字证书,我们称这些机构为认证中心(CA Certificate Authority)。
服务器可以向这些CA来申请数字证书。
申请的过程大致是:
自己本地先生成一对密匙,然后拿着自己的公匙以及其他信息(比如说企业名称啊什么的)去CA申请数字证书。
CA在拿到这些信息后,会选择一种单向Hash算法(比如说常见的MD5)对这些信息进行加密,加密之后的东西我们称之为摘要。
单向Hash算法有一种特点就是单向不可逆的,只要原始内容有一点变化,加密后的数据都将会是千差万别(当然也有很小的可能性会重复,有兴趣的小伙伴鸽巢原理了解一下),这样就防止了信息被篡改。
生成摘要后还不算完,CA还会用自己的私匙对摘要进行加密,摘要加密后的数据我们称之为数字签名。
最后,CA将会把我们的申请信息(包含服务器的公匙)和数字签名整合在一起,由此而生成数字证书。然后CA将数字证书传递给我们。
https原理:
https没有采用单一的技术去实现,而是根据他们的特点,充分的将这些技术整合进去,以达到性能与安全最大化。这套整合的技术我们称之为SSL(Secure Scoket Layer 安全套接层)。所以https并非是一项新的协议,它只是在http上披了一层加密的外壳。
https的建立
这里把https建立到断开分为6个阶段,12过程。下面将对12个过程一 一做解释
1.客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件(Cipher Suite)列表(所使用的加密算法及密匙长度等)。
2.服务器可进行SSL通信时,会以Server Hello报文作为应答。和客户端一样,在报文中包含SSL版本以及加密组件。服务器的加密组件内容时从接收到的客户端加密组件内筛选出来的。
3.服务器发送证书报文。报文中包含公开密匙证书。
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的通信。
总结:https虽然提供了消息安全传输的通道,但是每次消息的加解密十分耗时,消息系统资源。在一些对安全性比较高的场景下,比如银行系统,购物系统中我们必须要使用https进行通信,其他一些对安全性要求不高的场景,我们其实没必要使用https。使用https需要使用到数字证书,但是一般权威机构颁发的数字证书都是收费的,价格也是不菲的,所以对于一些个人网站特别是学生来讲,如果对安全性要求不高,没必要使用https。