HTTPS

 

密钥:可以将它认为是谍战人员所携带的密码本,根据这个密钥(密码本)将一串密文(通常是数字)进行相关的解密工作,同理也可以将需要加密的信息根据这个密钥(密码本)进行相应的加密操作.

 

网络时代,整个网络中最频繁,最重要的操作就是网络中各终端之间的通信,在传输层本身并不会做出任何的加密,如何保证通信之间数据传输的安全性,成为了计算机网络时代最重要的安全课题.提起对网络传输数据的加密,必须要先说安全套接字层(Secure Socket Layer,SSL).SSL协议工作于传输层与应用层之间,为应用提供数据的加密传输.而HTTPS的全称是HTTP over SSL,简单的理解就是在之前的HTTP传输上增加了SSL协议的加密能力.

DES加密算法是一种对称加密算法.

如果通过DES算法对数据进行加密,即一个主站与用户之间可以使用相同的密钥对传输内容进行解密.是否可以认为这样就完全没有风险了呢?肯定不是这样的,因为密钥几乎没有什么保密性可言,如果与每一个用户之间都约定一个独立的密钥,如何把密钥传输给对方,又是一个安全难题.在互联网上,IP报文好比官道上的押运的粮草,黄金,物资的载体,很容易被别人给盯上,密钥本身如果被盗,那么再复杂的密钥也是摆设.自然的想法就是在密钥之上再加密钥,这就是递归的穷举问题了.

这就引出了下面一种我们要介绍的算法:RSA算法(非对称加密算法).

首先科普一下什么是质数:

1、只有1和它本身两个约数的数,叫质数。(如:2÷1=2,2÷2=1,所以2的约数只有1和它本身2这两个约数,2就是质数。)

2、除了1和它本身两个约数外,还有其它约数的数,叫合数。(如:4÷1=4,4÷2=2,4÷4=1,很显然,4的约数除了1和它本身4这两个约数以外,还有约数2,所以4是合数。)

3、1既不是质数也不是合数。因为它的约数有且只有1这一个约数。

 

判断一个数是质数,还是合数,可以根据它约数的个数来确定:只有两个约数的数,是质数;有三个或三个以上的约数的数是合数;有且只有一个约数的数既不是质数也不是合数。

这种算法可以使报文即使被截取之后,黑客依然无计可施.RSA算法(非对称加密)把密码革命性地分成公钥和私钥,由于两个密钥并不相同,所以称为非对称加密,任何人都可以知道,包括黑客.RSA的安全性是基于大质数分解的困难性,在非对称的加密中公钥和私钥是一对大质数函数.计算两个大质数的乘积是简单的,但是这个过程的逆运算(将这个乘积分解为两个质数)是非常困难的.在RSA的算法中,从一个公钥和密文中解密出明文的难度等同于分解两个大质数的难度.因此在实际的传输中,可以把公钥发给对方.一方发送信息时,使用另一方的公钥进行加密生成密文.收到密文的一方再用私钥进行解密,这样一来,传输就相对安全了.

但是非对称加密并不是完美的,它有一个很明显的缺点就是加密和解密耗时长,只适合对少量数据进行处理.

回到前面讲的例子中:我们如果担心对称加密中的密钥安全问题,那么将密钥的传输使用非对称加密就完美地解决了这个问题.实际上,HTTPS也正是通过这样的一种方式来建立安全的SSL连接的.按照上面的逻辑,

用户A和用户B进行非对称加密传输的过程如下:

1.	A告诉B,使用RSA算法进行加密.B说,好的
2.	A和B分别根据RSA算法生成一对密钥,互相发送公钥.
3.	A使用B的公钥给B加密报文信息
4.	B收到信息,并使用自己的密钥进行解密
5.	B使用同样的方式给A发送信息,A使用相同方式进行解密.

 

这个过程中看起来是无懈可击,但是在TCP/IP里,端到端的通信,路途遥远,夜长梦多.在2中,如果A的送信使者中途被强盗给拦下,在严刑拷打之后,强盗知道使者是去送公钥的,虽然没有办法破解A的加密信息,但是可以把这个使者关起来扣留,自己去生成一对密钥,然后冒充A的使者到B家,把自己的公钥给B.B相信了,然后,把银行卡密码,存款金额统统告诉了中间的强盗.

说了这么多,其实就是一句话我们在解决了加密危机之后又产生了信任危机,

解决信任危机的方法:就是如果有一个具有公信力的组织来证明身份,这个问题就得到了解决.CA(Certificate Authority)就是颁发HTTPS证书的组织.HTTPS是当前网站的主流文本传输协议,在基于HTTPS进行连接时,就需要数字证书.如下图所示可以看到协议版本,签名方案,签发的组织是GlobalSign,以及这个证书的有效期是到2018年10月31日.

访问一个HTTPS的网站的大体流程如下:

1.	浏览器向服务器发送请求,请求中包含浏览器支持的协议,并附带一个随机数.
2.	服务器收到请求后,选择某种对称加密算法,把数字证书签名公钥,身份信息发送给浏览器,同时也附带一个随机数.
3.	浏览器收到以后,验证证书的真实性,用服务器的公钥发送握手信息给服务端.
4.	服务器解密后,使用之前的随机数计算出一个对称加密的密钥,以此作为加密信息并发送.
5.	后续所有的信息发送都是以对称加密方式进行的.

 

我们注意到证书的信息中出现了传输层安全协议(Transport Layer Security,TLS)的概念,TLS和SSL的区别:TLS可以理解为SSL协议3.0版本的升级,所以TLS的1.0版本也被标识为SSL 3.1版本.但是对于大的协议栈来说,SSL和TLS并没有太大的区别,因此在Wireshark里,分层依然用的是安全套接字层(SSL)标识.

 

整个HTTPS的传输过程中,主要分为两部分:首先是HTTPS的握手,然后是数据的传输.

前者是建立一个HTTPS的通道,并确定连接使用的加密套件及数据传输使用的密钥;后者主要是使用密钥对数据加密并传输.

 

首先看HTTPS是如何进行握手的:下图是一个完整的SSL数据流和简单流程.

第一步:客户端发送一个Client Hello协议的请求:在Client Hello中最重要的信息是Cipher Suites字段,
这里客户端会告诉服务端自己支持哪些加密的套件.比如在这次SSL连接中,客户端支持的加密套件协议如下图所示.

 

Cipher Suites

第二,服务端在收到客户端发来的Client Hello的请求后,会返回一系列的协议数据,并以一个没有数据内容的Server Hello Done作为结束.这些协议数据有的是单独发送,有的则是合并发送,这里分别解释下几个比较重要的协议.如下图所示:SSL协议.

 

SSL协议

1.	Server Hello协议 主要告诉客户端后序协议中要使用的TLS协议版本,
这个版本主要和客户端与服务端支持的最高版本有关.
比如本次确认后序的TLS协议版本是TLSv1.2,并为本次连接分配一个会话ID(Session ID).
此外,还会确认后续采用的加密套件(Cliper Suite),这里确认使用的加密套件为TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
该加密套件的基本含义是:使用非对称协议加密(RSA)进行对称协议加密(AES)密钥的加密,
并使用对称加密协议AES:进行信息的加密.
2.	Certificate协议  主要传输服务端的证书内容
3.	Server Key Exchange 如果在Certificate协议中未给出客户端足够的信息,
则会在Server Key Exchange进行补充,
如下图所示:比如再本次连接中Certificate未给出证书的公钥(Public Key),
这个公钥的信息就会通过Server Key Exchange发送给客户端.

 

Server Key Exchange

4.	Certificate Request 这个协议是一个可选项,
当服务端需要对客户端进行证书验证的时候,才会向客户端发送一个证书请求(Certificate Request).
5.	最后以Server Hello Done作为结束信息,告诉客户端整个Server Hello过程结束.

第三,客户端在收到服务端的握手信息后,根据服务端的请求,也会发送一系列的协议.

1.	Certificate 它是可选项.因为上面提到了服务端发送了Certificate Request
需要对客户端进行证书验证,所以客户端要发送自己的证书信息.
2.	Client Key Exchange 它与上文中Server Key Exchange类似,
是对客户端Certificate信息的补充,
在本次请求中同样是补充了客户端证书的公钥信息,如下图所示:

Client Key Exchange

3.	Certification Verity 对服务端发送的证书信息进行确认
4.	Change Cipher Spec 该协议不同于其他握手协议(Handshake Protocol),
而是作为一个独立协议告知服务端,客户端已经接收之前服务端确认的加密套件,
并会在后续通信中使用该加密套件进行加密.
5.	Encrypted Handshake Message 用于客户端给服务端加密套件加密一段Finish的数据,
用以验证这条建立起来的加密通道的正确性.

第四,服务端在接收客户端的确认信息及验证信息后,会对客户端发送的数据进行确认,这里也分为几个协议进行回复

1.	Change Cipher Spec 通过使用私钥对客户端发送的数据进行解密,
并告知后续将使用协商好的加密套件进行加密传输数据
2.	Encrypted Handshake Message 与客户端的操作相同,
发送一段Finish的加密数据验证加密通道的正确性.

 

最后,如果客户端和服务端都确认加解密无误后,各自按照之前约定的Session Secret对Application Data进行加密传输.

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值