HTTPS的安全原理及工作流程

HTTPS的安全原理及工作流程

1 为什么建议使用HTTPS协议进行通信

1.1、HTTP存在的安全问题?

1.2、HTTPS解决了什么?

1.3 HTTPS是什么?

1.4 HTTPS与HTTP的小结

2.HTTPS的安全原理

2.1 原理简述:

2.2 解决内容可能被窃听的问题——加密

2.2.1 对称加密

2.2.2 非对称加密

2.2.3 对称加密+非对称加密

2.3 解决报文可能遭篡改问题——数字签名

2.3.1 数字签名的两种功效

2.3.2 数字签名如何生成?

2.3.3 校验数字签名流程?

2.4 解决通信方身份可能被伪装的问题——数字证书

3.HTTPS的工作流程

 

1 为什么建议使用HTTPS协议进行通信

1.1、HTTP存在的安全问题?

HTTP由于是明文传输,所以安全上存在以下三种风险:

(1)窃听风险:通信使用明文,内容可能被窃听;

(2)冒充风险:不验证通信方的身份,因此有可能遭遇冒充;

(3)篡改风险:无法证明报文的完整性,所以有可能遭到篡改。

1.2、HTTPS解决了什么?

HTTPS在HTTP与TCP层之间加入了SSL/TSL协议,可以很好的解决了上述的风险:

(1)信息加密:所有信息都是加密传播,第三方无法窃听;内容经过对称加密,每个连接生成一个唯一的加密密钥;

(2)身份认证:,配备了身份认证,第三方无法伪造服务端(客户端)的身份;

(3)数据完整性校验:内容传输经过完整性校验,一旦报文被篡改,通信双方会立刻发现。

1.3 HTTPS是什么?

HTTPS就是在原HTTP的基础上加上一层用于数据加密、解密、校验、身份认证的安全层SSL/TSL,用于解决HTTP存在的安全隐患。如下两图所示:

在采用SSL后,HTTP就拥有了HTTPS的加密、证书和完整性保护这些功能。也就是说HTTP加上加密处理和认证以及完整性保护后即是HTTPS。

1.4 HTTPS与HTTP的小结

(1)HTTPS是加密传输协议,HTTP是明文传输协议;

(2)HTTPS协议需要向CA(证书权威机构)申请数字证书;

(3)HTTPS比HTTP更加安全,对搜索引擎更友好,利于SEO(搜索引擎优化)。例如:为保护用户隐私安全,谷歌优先索引HTTPS网页;

(4)HTTPS标准端口443,HTTP标准端口80;

(5)HTTPS在浏览器显示安全锁,HTTP没有显示。

HTTPS并非是应用层的一种新协议,只是HTTP通信接口部分用SSL和TLS协议代替而已,说白了,HTTPS是身披SSL/TSL外壳的HTTP。

2.HTTPS的安全原理

2.1 原理简述:

HTTPS协议的主要功能基本都依赖于TLS/SSL协议,TLS/SSL的功能实现主要依赖于三类基本算法:散列函数、对称加密和非对称加密。其利用非对称加密实现身份认证和密钥协商,对称加密算法采用协商的密钥对数据加密,基于散列函数验证信息的完整性。如下图所示:

2.2 解决内容可能被窃听的问题——加密

2.2.1 对称加密

这种方式加密和解密同用一个密钥。加密和解密都会用到密钥,没有密钥就无法对密码进行解密,反过来说,任何人只要持有密钥就能解密了 。

以对称加密方式加密时必须将密钥也发给对方。可究竟怎样才能安全地转交?在互联网上转发密钥时,如果通信被监听那么密钥就可会落人攻击者之手,同时也就失去了加密的意义。另外还得设法安全地保管接收到的密钥。

2.2.2 非对称加密

公开密钥加密使用一对非对称的密钥。一把叫做私有密钥,即私钥;另一把叫做公开密钥,即公钥。顾名思义,私有密钥不能让其他任何人知道,而公开密钥则可以随意发布,任何人都可以获得。

使用公开密钥加密方式,发送密文的一方使用对方的公开密钥进行加密处理,对方收到被加密的信息后,再使用自己的私有密钥进行解密。利用这种方式,不需要发送用来解密的私有密钥,也不必担心密钥被攻击者窃听而盗走。

该过程图示如下:

非对称加密的特点是信息传输一对多,服务器只需要维持一个私钥就能够和多个客户端进行加密通信。

这种方式有以下缺点:

(1)密钥是公开的,所以针对私钥加密的信息,黑客截获后可以使用公钥进行解密,获取其中的内容;

(2)公钥并不包含服务器的信息,使用非对称加密算法无法确保服务器身份的合法性,存在中间人攻击的风险,服务器发送给客户端的公钥可能在传送过程中被中间人解惑并篡改;

(3)使用非对称加密在数据加密解密过程中需要消耗一定时间,降低了数据传输效率。

2.2.3 对称加密+非对称加密

使用对称密钥的好处是解密的效率比较快,使用非对称密钥的好处是可以使得传输的内容不能被破解,因为就算你拦截到了数据,但是没有对应的私钥,也是不能破解内容的。就比如说你抢到了一个保险柜,但是没有保险柜的钥匙也不能打开保险柜。那我们就将对称加密与非对称加密结合起来,充分利用两者各自的优势,在交换密钥环节使用非对称加密方式,之后的建立通信交换报文阶段则使用对称加密方式。

具体做法是:发送密文的一方使用对方的公钥进行加密处理“对称的密钥”,然后对方用自己的私钥解密拿到“对称的密钥”,这样可以确保交换的密钥是安全的前提下,使用对称加密方式进行通信。所以,HTTPS采用对称加密和非对称加密两者并用的混合加密机制。

2.3 解决报文可能遭篡改问题——数字签名

网络传输过程中需要经过很多中间节点,虽然数据无法被解密,但可能被篡改,那如何校验数据的完整性呢?----校验数字签名

2.3.1 数字签名的两种功效

(1)能确定消息确实是由发送方签名并发出来的,因为别人假冒不了发送方的签名;

(2)数字签名能确定消息的完整性,证明数据是否未被篡改过。

2.3.2 数字签名如何生成?

将一段文本先用Hash函数生成消息摘要,然后用发送者的私钥加密生成数字签名,与原文文一起传送给接收者。接下来就是接收者校验数字签名的流程了。

2.3.3 校验数字签名流程?

接收者只有用发送者的公钥才能解密被加密的摘要信息,然后用HASH函数对收到的原文产生一个摘要信息,与上一步得到的摘要信息对比。如果相同,则说明收到的信息是完整的,在传输过程中没有被修改,否则说明信息被修改过,因此数字签名能够验证信息的完整性。

假设消息传递在Kobe,James两人之间发生。James将消息连同数字签名一起发送给Kobe,Kobe接收到消息后,通过校验数字签名,就可以验证接收到的消息就是James发送的。当然,这个过程的前提是Kobe知道James的公钥。问题的关键的是,和消息本身一样,公钥不能在不安全的网络中直接发送给Kobe,或者说拿到的公钥如何证明是James的。

此时就需要引入了证书颁发机构(Certificate Authority,简称CA),CA数量并不多,Kobe客户端内置了所有受信任CA的证书。CA对James的公钥(和其他信息)数字签名后生成证书。

2.4 解决通信方身份可能被伪装的问题——数字证书

数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。

数字证书认证机构的业务流程为:

(1)服务器的运营人员向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证;

(2)CA通过线上、线下等多种手段验证申请者提供信息的真实性,如组织是否存在、企业是否合法,是否拥有域名的所有权等;

(3)如信息审核通过,CA会向申请者签发认证文件-证书。证书包含以下信息:申请者公钥、申请者的组织信息和个人信息、签发机构 CA的信息、有效时间、证书序列号等信息的明文,同时包含一个签名。 其中签名的产生算法:首先,使用散列函数计算公开的明文信息的信息摘要,然后,采用 CA的私钥对信息摘要进行加密,密文即签名;

(4)客户端 Client 向服务器 Server 发出请求时,Server 返回证书文件;

(5)客户端 Client 读取证书中的相关的明文信息,采用相同的散列函数计算得到信息摘要,然后,利用对应 CA的公钥解密签名数据,对比证书的信息摘要,如果一致,则可以确认证书的合法性,即服务器的公开密钥是值得信赖的。

(6)客户端还会验证证书相关的域名信息、有效时间等信息; 客户端会内置信任CA的证书信息(包含公钥),如果CA不被信任,则找不到对应 CA的证书,证书也会被判定非法。

3.HTTPS的工作流程

HTTPS的工作流程如下图所示:

(1)客户端Client发起一个HTTPS(比如https://juejin.im/user/5a9a9cdcf265da238b7d771c)的请求,根据RFC2818的规定,Client知道需要连接Server的443(默认)端口。

客户端提供:

  • 1.协议版本(如TSL1.0)
  • 2.随机数1(用于生成对话密钥)
  • 3.支持的加密方法(如RSA公钥加密)
  • 4.支持的压缩方法

(2)服务器Server把事先配置好的公钥证书(public key certificate)返回给客户端。

采用HTTPS协议的服务器必须要有一套数字证书,可以是自己制作或者CA证书。区别就是自己颁发的证书需要客户端验证通过,才可以继续访问,而使用CA证书则不会弹出提示页面。这套证书其实就是一对公钥和私钥。公钥给别人加密使用,私钥给自己解密使用。服务器回应内容:

  • 1.确认使用的加密通信协议版本(TSL1.0)
  • 2.随机数2(用于生成对话密钥)
  • 3.确认加密方法(RSA)
  • 4.服务器证书(包含非对称加密的公钥)
  • 5.(可选)要求客户端提供证书的请求

(3)Client验证公钥证书:比如是否在有效期内,证书的用途是不是匹配Client请求的站点,是不是在CRL吊销列表里面,它的上一级证书是否有效,这是一个递归的过程,直到验证到根证书(操作系统内置的Root证书或者Client内置的Root证书)。如果验证通过则继续,不通过则显示警告信息。证书的解析工作由客户端自己执行。如果证书没有问题,那么就生成一个随即值,然后用证书对该随机值进行加密。

(4)Client使用伪随机数生成器生成加密所使用的对称密钥,然后用证书的公钥加密这个对称密钥,发给Server。这部分传送的是用证书加密后的随机值,目的就是让服务端得到这个随机值,以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。发送内容为:

  • 1.随机数3(pre-master key,此随机数用服务器公钥加密,防止被窃听)
  • 2.编码改变通知(表示随后的信息都将用双方商定的方法和密钥发送)
  • 3.客户端握手结束通知

(5-1)Server使用自己的私钥(private key)解密这个消息,得到对称密钥。至此,Client和Server双方都持有了相同的对称密钥。

服务端用私钥解密后,得到了客户端传过来的随机值(私钥),然后把内容通过该值进行对称加密。所谓对称加密就是,将信息和私钥通过某种算法混合在一起,这样除非知道私钥,不然无法获取内容,而正好客户端和服务端都知道这个私钥,所以只要加密算法够彪悍,私钥够复杂,数据就够安全。

(5-2)生成会话秘钥。双方同时有了三个随机数,接着就用事先商定的加密方法,各自生成同一把“会话密钥”,服务器端用自己的私钥(非对称加密的)获取第三个随机数,会计算生成本次所用的会话密钥(对称加密的密钥)。

(6)传输加密后的信息:这部分信息是服务端用私钥加密后的信息,可以在客户端被还原。

(7)客户端解密信息:客户端用之前生成的私钥解密服务段传过来的信息,于是获取了解密后的内容。

(8)当Client再次发起HTTPS的请求,使用对称密钥加密请求的“明文内容B”,然后Server使用对称密钥解密密文,得到“明文内容B”。

 

 

 

声明:本文部分内容整理来源于网络,仅做个人学习使用!侵删~

本文部分内容参考链接:

https://www.jianshu.com/p/aa3f6e47f327

https://juejin.im/post/6844904130402582542

https://blog.nowcoder.net/n/aae672c111664b029b49d88dd22af492

 

 

 

 

 

 

 

 

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页