解析HTTPS

时间 2019-11-06 标签解析 https

本文主要是对HTTPS作一个总结，主要讲解HTTPS的实质、HTTPS加密原理、HTTPS的通讯过程等。html

HTTPS是什么

HTTP存在问题

因为HTTP协议过于简单：算法

通讯使用明文（不加密），内容可能会被窃听。
不验证通讯方的身份，所以可能遭遇假装
没法验证报文的完整性，因此有可能已遭篡改。

为了解决诸多问题，HTTPS应运而生。浏览器

HTTPS的实质

HTTP加上加密处理、认证机制、以及完整性保护后的就是HTTPS。安全

须要知道的是，HTTPS并不是是应用层的一种新的协议。只是HTTP通讯接口部分用SSL或TLS协议代替而已。也就是说，所谓的HTTPS，其实就是身披SSL协议外壳的HTTP。服务器

值得一提的是，SSL是独立于HTTP协议的，也就是说其余运行在应用层的协议都可配合SSL协议使用。现今SSL是最为普遍的网络安全技术。网络

SSL和TLS

HTTPS中使用了SSL和TLS这两个协议。session

TLS以SSL3.0为基准，后又制定了TLS1.0、TLS1.1和TLS1.2。当前主流的版本是SSL3.0和TLS1.0。性能

TLS是以SSL为原型开发的协议，有时候会统称该协议为SSL。网站

HTTPS的加密原理

近代的加密算法中加密算法是公开的，而密钥是保密的。经过这种方式来保持加密方法的安全性。ui

加密和解密要用到密钥，若是没有密钥就没有办法对密码解密。换句话来讲，任何人只要持有密钥就可以对密文进行解密。

HTTPS在加密过程当中使用了非对称加密技术和对称加密技术。

对称加密算法

采用单钥密码系统的加密方式，同一个密钥能够同时作信息的加密和解密，这种加密的方法称为对称加密，也称为单密钥加密。

下面会把对称加密算法称为共享密钥加密算法。

假如如今，SSL在通讯过程当中，使用了对称加密算法，也就是说客户端和服务器同时共享一个密钥。

因而，以共享密钥的方式加密，必须将密钥发给对方。这个时候，假如通讯过程被监听，密钥被攻击者获取了，那么这个时候也就失去了加密的意义了。

那么，有没有办法解决这个问题呢？答案是确定的，也就是使用两把密钥。

下面先看使用两把密钥的非对称加密算法。

非对称加密算法

与对称加密算法相反，非对称加密算法须要两个密钥来进行加密和解密，这两个密钥是配对的，分别是公开密钥（公钥）和私有密钥（私钥）。

通常状况下，公钥是能够被公开的，它主要用来加密明文。而相应的，私钥不能被公开，用来解密公钥加密的密文。

值得注意的是：公钥加密后的密文只能经过对应的私钥来解密，而私钥加密的密文却能够经过对应的公钥来解密。

以上，公钥加密私钥解密用来加密，私钥加密公钥解密用来签名。相关用途后面会讲到。

下面会把非对称加密算法称为公开密钥加密算法。

因而如今，假设如今由服务器来生成一对公钥和私钥。

当客户端第一次发请求和服务器协商的时候，服务器就生成了一对公钥和私钥。

紧接着，服务器把公钥发给客户端（明文，不须要作任何加密），客户端接收后，随机生成一个密钥，使用服务器发过来的公钥进行加密。

再接着，客户端把使用公钥加密的密钥发给服务器，服务器接收到了之后，用配对的私钥进行解密，就获得了客户端随机生成的那个密钥。

这个时候，客户端和服务端所持的密钥都是相同的。此时，交换密钥环节就完成了。

因而通讯开始时就可进行上面所述的共享密钥加密方式来进行加密。

同时使用

可能，有小伙伴就会问，为何要大费周章使用非对称加密的方式，而后再获得相同的密钥，进行共享密钥加密的通讯呢？

因为公开密钥加密处理起来比共享密钥加密方式更为复杂，所以在通讯的时候使用公开密钥加密的方式，效率很低。

因而，咱们须要使用非对称加密的方式来保证密钥共享的过程当中密钥的安全性，然后在通讯的过程当中使用对称加密算法，这是最合理的设计方式，在保证安全性的同时又保证了性能。

因此，HTTPS采用共享密钥加密和公开密钥加密二者并用的混合加密机制。在交换密钥使用环节使用公开密钥加密方式，以后创建的通讯交换报文阶段则使用共享密钥加密方式。

以上，大概就是使用对称加密和非对称加密的过程。看似过程很完美，其实还存在着一个问题，就是：如何保证服务器传过来的公开密钥的正确性。换句话说，就是保证它不被拦截篡改。

使用证书保证公钥的正确性

假如如今正准备和某台服务器创建公开密钥加密方式下的通讯，如何证实客户端收到的公开密钥就是本来预想的那台服务器发行的公开密钥呢？或许，在公开密钥传输的过程当中，真正的公开密钥可能已经被攻击者替换掉了。

为了解决这个问题，可使用由数字证书机构和其相关颁发的公开密钥证书。

下面阐述一下数字证书认证机构（简称CA）的业务流程：

首先，服务器的运营人员向数字证书机构提出公开密钥的申请。数字证书认证机构在判明提出申请者的身份以后，会对已申请的公开密钥作数字签名，而后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一块儿。
咱们用白话文来翻译一下上面这段话：

首先，CA会向申请者颁发一个证书，这个证书里面的内容有：签发者、证书用途、使用的HASH算法、签名所使用的算法、证书到期的时间等等。
紧接着，把上面所提到的内容，作一次HASH求值，获得一个HASH值。
再接着，用CA的私钥对这个HASH值和所使用的HASH算法加密，这样就完成了数字签名。而用CA的私钥加密后，就生成了相似人体指纹的签名，任何篡改证书的尝试，都会被数字签名发现。
最后，把数字签名，附在数字证书的末尾，传输给服务器。

接下来，服务器会把这份由数字证书认证机构颁发的公钥证书发给客户端。这个时候，客户端可使用数字证书机构的公开密钥对其进行验证。一旦验证成功，客户端便可以肯定这个公开密钥是可信的。
咱们再用白话文来翻译一下：

客户端拿到这个数字证书之后，用CA私钥对应的公钥，能够解密数字证书末尾的数字签名，获得HASH值和所采用的HASH算法。
紧接着，客户端按照解密到的这个HASH算法，对证书的内容求HASH值。若是经过CA公钥解密的HASH和经过计算求得的HASH值相同，那么认证经过，不然失败。
若是认证经过，就能够取得服务器的公开密钥。

那客户端上面的CA公钥是从哪里来的呢？

其实，CA除了给申请者发布证书，它本身自己也有本身的证书。CA自身的数字证书（通常由它本身生成）在咱们操做系统刚安装好的时候，这些CA自身的数字证书就已经被微软（或者其它操做系统的开发机构）安装在操做系统中了。而CA的公钥就包含在其中。这样，CA就能够经过自身的私钥对发布的数字证书进行签名，而在客户端就可以用对应的公钥来对其进行解密。

其具体过程是这样子的（图中简化了数字签名的过程）：

这里其实就用到了非对称加密算法，只不过如今这个加密算法用来签名而不是加密。

使用私钥加密，公钥解密，用于公钥的持有者验证经过私钥加密的内容是否被篡改，可是不用来保证内容是否被他人得到。

而使用公钥加密，私钥解密，则是相反的，它不保证信息被他人截获篡改，可是保证信息没法被中间人得到。

客户端证书

HTTPS中不只可使用服务器证书，还可使用客户端证书。以客户端证书进行客户端认证，它的做用与服务器证书是相同的。

因为客户端获取证书须要用户自行安装客户端证书，同时也面临着费用的问题。

所以，现状是，安全性极高的认证机构可办法客户端证书可是仅用于特殊用途的业务。好比那些可支撑客户端证书支出费用的业务。

例如，银行的网上银行就采用了客户端证书。在登陆网银时不只要求用户确认输入ID和密码，还会要求用户的客户端证书，以确认用户是否从特定的终端访问网银。

HTTPS通讯的过程

如今咱们来理清一下SSL创建的过程：

客户端经过发送Client Hello报文开始SSL通讯。报文中包含客户端支持的SSL的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。
注意：客户端还会附加一个随机数，这里记为A。
服务器可进行SSL通讯时，会以Server Hello报文做为应答。和客户端同样，在报文中包含SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
注意：这里服务器一样会附加一个随机数，发给客户端，这里记为B。
以后服务器发送Certificate报文。报文中包含公开密钥证书。（具体的数字签名请看证书一节）
最后服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束。
SSL第一次握手结束后，客户端会对服务器发过来的证书进行验证，若是验证成功，解密取出证书中的公钥。（具体查看证书一节）
接着，客户端以Client Key Exchange报文做为回应。报文中包含通讯加密中使用的一种被称为Pre-master secret的随机密码串。该报文使用从证书中解密得到的公钥进行加密（其实就是服务器的公钥）。
客户端继续发送Change Cipher Spec报文。用于告知服务端，客户端已经切换到以前协商好的加密套件（Cipher Suite）的状态，准备使用以前协商好的加密套件加密数据并传输了。
客户端发送Finished报文。该报文包含链接至今所有报文的总体校验值（也就是HASH值），用来供服务器校验。
服务器接收到客户端的请求以后，使用私钥解密报文，把Pre-master secret取出来。接着，服务器一样发送Change Cipher Spec报文。
服务器一样发送Finished报文，用来供客户端校验。
服务器和客户端的Finished报文交换完毕以后，SSL链接就算创建完成。固然，通讯会受到SSL的保护。今后处开始进行应用层协议的通讯，即发送HTTP请求。
应用层协议通讯，即发送HTTP响应。
最后由客户端断开链接。断开链接时，发送close_notify报文。上图作了一些省略，这步以后再发送TCP FIN报文来关闭与TCP的通讯。

读到这里，你可能会对上面的一些细节产生不少疑惑，如今咱们一个个来理清楚？

问题一

为何最后客户端和服务端都要发送一个Finish报文？

上面已经说起，Finish报文是对至今所有报文的总体校验值（也就是HASH值）。当客户端把这个值经过获得的公钥进行加密的时候，服务器获得以后对其进行解密，而后再对所有报文进行一个HASH求值。若是这个值跟解密获得的值相等的话，那么说明客户端是可信赖的。
一样的，服务器发送这样的一个总体校验值，用来客户端验证服务器是不是真正要进行通讯的那一个。
综上，这个Finish报文就是用来校验双方的身份的。

问题二

整个过程当中产生的三个随机数有什么用呢？还有，后面进行HTTP通讯的时候，是用哪个密钥进行加密，还有怎么保证报文的完整性。

看下面这张图。

对于客户端：
当其生成了Pre-master secret以后，会结合原来的A、B随机数，用DH算法计算出一个master secret，紧接着根据这个master secret推导出hash secret和session secret。

对于服务端：
当其解密得到了Pre-master secret以后，会结合原来的A、B随机数，用DH算法计算出一个master secret，紧接着根据这个master secret推导出hash secret和session secret。

在客户端和服务端的 master secret是依据三个随机数推导出来的，它是不会在网络上传输的，只有双方知道，不会有第三者知道。同时，客户端推导出来的 session secret和 hash secret与服务端也是彻底同样的。

那么如今双方若是开始使用对称算法加密来进行通信，使用哪一个做为共享的密钥呢？过程是这样子的：

双方使用对称加密算法进行加密，用hash secret对HTTP报文作一次运算生成一个MAC，附在HTTP报文的后面，而后用session-secret加密全部数据（HTTP+MAC），而后发送。

接收方则先用session-secret解密数据，而后获得HTTP+MAC，再用相同的算法计算出本身的MAC，若是两个MAC相等，证实数据没有被篡改。

MAC(Message Authentication Code)称为报文摘要，可以查知报文是否遭到篡改，从而保护报文的完整性。

问题三

为何要使用三个随机数呢？

网友dog250是这么解释的：

"无论是客户端仍是服务器，都须要随机数，这样生成的密钥才不会每次都同样。因为SSL协议中证书是静态的，所以十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
对于RSA密钥交换算法来讲， pre-master secret自己就是一个随机数，再加上hello消息中的随机，三个随机数经过一个密钥导出器最终导出一个对称密钥。
pre-master secret的存在在于SSL协议不信任每一个主机都能产生彻底随机的随机数，若是随机数不随机，那么 pre-master secret就有可能被猜出来，那么仅适用 pre-master secret做为密钥就不合适了，所以必须引入新的随机因素，那么客户端和服务器加上 pre-master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能彻底不随机，但是是三个伪随机就十分接近随机了，每增长一个自由度，随机性增长的可不是一。"

注：咱们在计算机所使用的随机数都是伪随机，而不是物理上所说的真正随机。

另外，黑客可能拦截了这样的一个加密的报文，他不对报文进行修改，而是不停的向报文的接受者发送重复的报文，以扰乱通讯的创建。因而，就能够加这么一个随机数。只要任何一个通讯方，接收到的报文中的随机数出现重复的状况，就能够知道有中间者对通讯的过程进行了扰乱，能够当即中断通讯。

问题四

若是黑客拦截了服务器把证书发送给客户端，并对证书进行恶意修改，会出现什么状况？

第一种状况，假如黑客只是单纯的修改数字证书中的内容，那么因为数字签名的存在，客户端会很容易的判断出报文是否被篡改。

第二种状况，黑客不只修改了数字证书的内容，而且把数字签名替换掉了，因为黑客不可能知道CA的私钥，因而在客户端用CA的公钥进行解密的时候，解密以后得不到正确的信息，也很容易判断出报文是否被修改。

第三种状况，黑客恶意的从相同的第三方CA申请了一个数字证书。因为这个CA是真实存在的，因此客户端是能够用CA的公钥进行解密，获得了黑客提供的数字证书中的公钥。可是，因为数字证书在申请的时候，会绑定一个域名，当客户端好比说浏览器，检测到这个数字证书中的域名和咱们如今网页访问的域名不一致，便会发出警告，此时咱们也能得知数字证书被替换了。发出的警告以下：

必定要用HTTPS吗

当HTTP披上SSL外壳以后，因为加入了诸多验证的机制，虽然安全性大大提升了，可是它的处理速度会变慢。慢的缘由分如下两种：

服务器在与客户端协商次数增多，也就是说总体上处理通讯量会不可避免的增长。
SSL进行加密处理，在服务端和客户端都须要进行加密和解密的运算处理。结果会消耗更多的硬件资源，致使负载增长。

可见，使用HTTPS会消耗更多的资源。若是每次通讯都加密，那么平摊到一台计算机上，可以处理的请求数量也一定会减小。

同时，使用HTTPS须要向CA购买证书，因而开销也成为考虑是否使用HTTPS的缘由之一。

因此，大部分的Web网站都采起了一个折中的方法。对于一些须要隐藏、私密的信息进行加密，而普通的信息不进行加密处理，以节省资源。

fiddler拦截HTTPS请求的原理

不少时候咱们能够经过fiddler来进行抓HTTP包，可是当遇到链接采用的是HTTPS的时候，过程可能就不那么愉快了。但实际上实现拦截也十分简单。

fiddler拦截HTTPS请求最核心的地方在于真正的客户端须要安装fiddler的证书。这样子的话，fiddler可以伪造出CA证书，达到欺骗客户端，拿到须要的信息并推算出以后双方正常通讯的对称加密密钥。

最后

这学期恰好有《信息安全》这门课程，那就简明的介绍一下公钥密码密码体系RSA算法原理是什么。

它是这样子工做的：

选取两个大素数p和q，相乘获得n。
p-1和q-1相乘，获得f(n)。
随机选取一个e与f(n)互质，而后获得公钥(e, n)。
私钥的求法为ed = 1 mod f(n)。 [这是一个等价关系而不是一个表达式！也就是ed模fn(n)的结果是1，这是求模运算的逆运算，能够用欧几里德展转相除法求得]
最后获得的私钥为(d, n)。

整个RSA公钥密码算法的难度其实在于分解这一个大数 n， pq=n正向运算很容易，逆向运算很困难，随着这个数愈来愈大，想要逆向分解须要不少年的时间。

参考书籍：《图解HTTP》
参考连接：
https://www.zhihu.com/questio...
http://www.cnblogs.com/Jeffre...