1、《HTTP专题》对于https的理解

对于HTTP,大家都很熟悉了，使用也相当广泛。但是同很多未加密协议一样，HTTP也存在着安全性的问题。

比如：

1、明文消息，很容易被窃听

2、不验证通信方身份，很容易遭遇伪装

3、无法证明报文的完整性，内容容易被篡改

这时候HTTPS就需要加上必要的加密处理和认证机制了。我们将这个加了加密认证机制的HTTP叫做HTTPS(HTTP Secure)。

HTTPS并非是一种新的协议，只是HTTP通信接口部分改成SSL和TLS协议代替而已。同城HTTP跟TCP通信，当使用SSL时，先变成SSL通信，再由SSL和TCP通信。其实就是身披SSL的HTTP

类似的不光是HTTP协议，其他运行在应用层上的协议都可以配上一层SSL,比如SMTP,Telnet等协议，都可以配合SSL来提高安全性。

单纯的http很好理解，这里不再做介绍。

https就是在http之上加上一层安全机制。这层安全我们需要依赖于密码学以及相关的认证机制。

所以接下来我们来了解下https是如何做数据的加密以及认证的。

在密码学中，加密的算法都是公开的。所以我们加密并不依赖于算法的保密性，而是依赖于密钥的保密。换言之，只要获得密钥，就可以解密。这时候在保密通信中密钥的传输就尤为关键。

如果想要通信安全，那么需要使用密钥加密通信。但是如何保证密钥安全？就是如何保证密钥安全的送达对方？在互联网环境中，如果密钥在转发时被窃听，截取甚至篡改，那么我们后面的加密将失去意义。

这就陷入一个循环了，密钥的发送会有安全的风险。但是我不发送就无法加密会话。而如果我能安全发送密钥，那么我应该也能安全发送数据。。。

为了解决这样一个问题，后面有人提出了使用非对称加密。

对称加密就是加密和解密都是使用相同的一个密钥。也就是加密和解密的过程只用一个密钥。

非对称加密分公钥和私钥。发送方使用共钥加密数据，接收方使用私钥解密数据。也就是说保密方会生成对应的公钥和私钥，之后公钥就发出去了。保密的数据使用公钥进行加密，接收方会使用私钥对加密数据进行解密。

利用非对称加密方式，就可以绕过前面的问题。我们将公钥发出去，而私钥是自己保留。最坏的情况是会话被截取，但是也无法被解密。但是这里还是有一个问题，如何保证公钥就是货真价实公钥，公钥被恶意篡改了怎么办？

1、如果公钥在送达对方的时候就已经被篡改了，那么很有可能就是遭受到了中间人攻击，有人冒名顶替了我方跟对面通话。

2、如果公钥在送达对方之后被截取，攻击者即使无法解密出会话内容，也能轻易做到冒名顶替对方跟我方通信。

为了解决这个问题，人们使用了数字证书认证机构（CA,Certificate Authority）和其相关机关颁发的公开密钥证书。

数字证书认证机构是通信双方都认可的第三方机构。这个机构就像是公证处一样，经过公证处认可的公钥，那就是可以信任的。基于这种理念，前面的问题就可以解决了。客户端不是不确定我们服务器的公钥是否被篡改么？找公证处问问就行了。实际上我们的做法是服务器的运营人员会向认证机构提供身份信息，并提出公钥证书的申请。一般的公钥和私钥都是自己生成好的，然后认证机构会用自己的私钥对你的公钥进行数字签名，签名之后就能得到一个数字证书，这个证书包含了公钥信息。用认证机构的私钥对公钥进行签名的意义在于，认证机构是可信任的，认证机构的公钥被预置于浏览器端已经接受到浏览器的信任。所以服务器的公钥证书如果能在客户端被受信任的公钥解密，那么说明这个证书本身也就是值得信赖的。

我们知道，在打开浏览器的安全选项的时候，有一个证书的列表，这就是浏览器厂商帮我们预置的证书，这些证书就是这个浏览器信任的。（这里多嘴一句，后面我们对https数据进行窃听，就需要生成第三方的证书并让浏览器信任。比如，我们用burp进行窃听，就需要生成一个证书。这个证书需要让浏览器信任）

在真正通信的时候，服务器端将这个带有认证机构认证的公钥证书发出来。客户端接到证书后可以用认证机构的公钥对数字证书进行解密。如果解密成功，那么这个证书就是经过认证的。

这里还有一个小问题要注意，我们向认证机构申请公钥证书的时候，还要提供自己的身份信息，还有服务器的ip，域名等信息。这些信息也会被添加到公钥证书中。这样做的好处就为了防止证书的欺骗。

因为服务器端发出去的公钥证书，如果能被客户端正常解密，其实只能说明这个公钥证书来源没问题，确实是通过认证的。但是如果出现中间人攻击，攻击者也同样用认证后的证书发送给客户端，那么客户端毋庸置疑也可以解密证书拿到里面的公钥。这时候客户端这边对证书的校验工作就显得尤为重要了。解密后的公钥会包含原来证书申请者的信息，所以客户端在校验证书的时候还需要校验证书的信息与我们要访问的对象信息是否符合。比如：证书是否已经过期，证书的域名，ip等是否就是我们当前访问的ip等。一般浏览器或客户端校验证书时，都会先检查证书是否是“受信任的根证书颁发机构”颁发，再检查SSL证书中的证书吊销列表，再检查检查此SSL证书是否过期，再检查SSL证书的网站的域名是否与当前访问域名一致。如果使用一个合法签发的证书实际上可以通过大部分校验。

只有经过这一系列的校验，才能明确这个证书确实是经过公证的我们正在访问的服务器端发过来的证书。

前面我们说了这么多证书和认证的内容，这些在我们的https协议上都有具体的应用。现在回到我们的https协议上来看看，这套认证机制是如何应用的。

上面的一张图展示了一个https 的握手包括密钥协商大致整个过程。

这里我们注意到，https 中混合使用了对称加密和非对称加密两种，其实完全是可以从头到尾使用非对称加密的。但是有人从加密解密算法小效率上提出来了，如果一直使用非对称加密，会造成通信效率的底下，尤其是不适合像客户端和服务器之间这种高频的通信过程中，所以使用非对称加密，只是为了保证我们密钥的交换过程是安全的，一旦挖完成密钥的交换，后续的就是使用对称加密算法进行加密了。

 

当然，我们前面说了这么多，其实都是单方向认证的，不知道大家注意了没有。就是全部的内容，其实都是在做客户端对服务器的验证。即如何保证服务器是真正的服务器，而我们服务器并没有对客户端进行校验。也就是服务器端不管谁来请求，都是没问题的，所以后续，还会有双向验证的问题。当然过程也是和单项差不多的，无非是服务器端要验证客户端证书的合法性问题（具体的这里先不做介绍）

 

证书的出现，一方面为了解决数据的安全问题。另一方面，证书的申请需要提供真实的身份信息，因此也可以用来判定服务器背后的运营企业是否真实存在。

下面再介绍下证书的类型：

1、首先是EV SSL 证书，持有EV SSL证书的web网站在浏览器的地址栏会有绿色的显示安全的提示，可以很容易分辨出来

2、由自认证机构颁发的证书。这种也叫自签名证书，因为openssl是开源的， 每个人都可以构建一套属于自己的证书，当然这种证书肯定是没通过第三方认证的，不过好处就是不用钱，也一样可以起到加密的作用，所以也会有很多人使用这种自签名证书。当然这种自签名证书安全性不高，因为它无法消除被证书欺骗的风险，也就是说攻击者可以伪造证书并完成中间人攻击。