http、https和数字证书的相关知识

http协议

http协议全称超文本传输协议，是一个基于请求与响应，无状态的，应用层的协议，常基于TCP/IP协议传输数据，互联网上应用最为广泛的一种网络协议，所有的WWW文件都必须遵守这个标准。设计HTTP的初衷是为了提供一种发布和接收HTML页面的方法。

• 无状态：协议对客户端没有状态存储，对事物处理没有“记忆”能力，比如访问一个网站需要反复进行登录操作
• 无连接：HTTP/1.1之前，由于无状态特点，每次请求需要通过TCP三次握手四次挥手，和服务器重新建立连接。比如某个客户机在短时间多次请求同一个资源，服务器并不能区别是否已经响应过用户的请求，所以每次需要重新响应请求，需要耗费不必要的时间和流量。
• 基于请求和响应：基本的特性，由客户端发起请求，服务端响应
• 简单快速、灵活
• 通信使用明文、请求和响应不会对通信方进行确认、无法保护数据的完整性

http通信带来的问题

由于是明文传输，那么传输过程中带来的信任问题就由此而来，如果有人劫持了网络请求，就可以知道你传输的内容了，这样浏览器和客户端之间的所有数据都可以被获取，这样就无秘密可言，所以需要对信息加密，防止被获取，加密算法：

• 对称加密
  一把钥匙，可以用来加密，也可以用来解密，所以是一把密钥。
• 非对称加密
  两把密钥，一个是公钥、一个是私钥，公钥给别人，私钥不能提供出去，只能自己知道。公钥加密的内容只能私钥解开，私钥加密的内容只能公钥解开。

虽然采取加密算法，但依旧有问题，如果有一个中间人，获取了客户端发给服务端的公钥，然后替换成自己的公钥，再把自己的公钥发给服务端，并且把服务端的公钥换成另一个自己的公钥，发给客户端，这样自己做中间人，可以对双方的传输内容做加密解密，依旧可以拦截、篡改内容。这些问题 说到底还是怎么验证一个服务端的连接是否合法的。这就需要CA数字签名+数字证书。

CA机构：证书颁发机构

两个机器之间通信，公钥是公开的，那么公钥和机器怎么对应上？你说A机器的公钥是X，但是也可能让人给改了，改成了别人的公钥Y，需要一个国际认证机构来管理和认证，他们来认证公钥与网站的映射关系。这就是CA机构，它就像是第三方，把所有数据进行封装。它会给一个网站颁发一个证书，这里面包含了网站的域名信息、公钥等，它会对证书生成数字签名，并把证书和数字签名一起封装发给服务端，并且操作系统、浏览器本身会预装一些它们信任的根证书，如果其中会有CA机构的根证书，这样就可以拿到它对应的可信公钥了。这个公钥对应的密钥非常重要，由CA机构保管，其中如果有泄漏，则会导致大量的网站信任问题。

数字签名

我们把证书内容生成一份“签名”，比对证书内容和签名是否一致就能察觉是否被篡改。这种技术就叫数字签名，数字签名的制作过程：

• 1、CA拥有非对称加密的私钥和公钥。
• 2、CA对证书明文信息进行hash。
• 3、对hash后的值用私钥加密，得到数字签名。

这里的hash其实是MD5、SHA256这样的算法。明文和数字签名共同组成了数字证书，这样一份数字证书就可以颁发给网站了。那浏览器拿到服务器传来的数字证书后，如何验证它是不是真的？（有没有被篡改、掉包）
浏览器验证过程：

• 拿到证书，得到明文T，数字签名S。
• 用CA机构的公钥对S解密（由于是浏览器信任的机构，所以浏览器保有它的公钥），得到S’。
  用证书里说明的hash算法对明文T进行hash得到T’。
• 比较S’是否等于T’，等于则表明证书可信。

这里回到刚刚提到的问题：为什么制作数字签名时需要hash一次？
我们是不会觉得以上过程中hash有点多余，把hash过程去掉也能保证证书没有被篡改。因为我们可以对明文加密。说到底还是性能问题，非对称加密效率较差，加密的内容越多越耗时，证书信息一般较长，比较耗时。而hash后得到的是固定长度的信息（比如用md5算法hash后可以得到固定的128位的值），这样加密解密就会快很多。也有安全上的考虑，具体可以去参考其他博客。

谈谈证书被篡改

篡改之后，hash之后的值跟数字签名就对不上了。

谈谈证书被掉包

如果证书被掉包，换成其他的伪造证书，则拿ca机构的公钥，解不开数字签名。

SSL

在网站通过SSL来与用户建立安全的通信中，对称加密算法和非对称加密算法起到了很大作用。客户端和服务器的握手阶段使用的是非对称加密算法，传输数据节点使用的是对称算法，这主要是因为对称算法效率比非对称要高。

在握手阶段，客户端、服务器之间会协商才去的加密方式，客户端也会提供对称密钥，用于双方加密、解密数据。对称加密虽然性能好但有密钥泄漏的风险，非对称加密（2组公钥+2私钥双向传输）安全但性能低下，因此考虑用非对称加密来传输对称加密所需的密钥，然后进行对称加密，但是为了防止非对称过程产生的中间人攻击，需要对服务器公钥和服务器身份进行配对的数字认证，然后引入了CA数字签名+数字证书验证的方式！这是我梳理的整体逻辑流程。

https

对http进行了封装，http超文本传输协议，明文协议，于是容易被获取重要信息。变采用了基于ssl加密的https协议，用与客户端、服务器的数据传输。因为http是明文传输，所以有数据泄漏的安全问题，由此提出来了https协议，具有一下特点：

• 内容加密：采用混合加密技术，中间者无法直接查看明文内容
  加密一般都对称加密和非对称加密，非对称加密算法比较消耗时间，所以一般都用非堆成加密算法对对称加密算法的公钥加密，保证不别窃取，利用对称加密算法的公钥对传输内容加密，由此来提高性能。
• 验证身份：通过证书认证客户端访问的是自己的服务器
  这里验证身份主要是在内容加密一节中存在一个问题，实际的网络环境都有很多代理服务器，如果有人伪装称代理服务器，给你发了一个非堆成加密的公钥，这样客户端就把对称公钥给发给了代理服务器，这样客户端的内容都会被代理服务器所解析出来。所以怎么验证一个服务器的身份呢？
• 保护数据完整性：防止传输的内容被中间人冒充或者篡改

数字证书内容包括了：

• 加密后服务器的公钥
• 权威机构的信息
• 服务器域名
• 还有经过CA私钥签名之后的证书内容
  先通过Hash函数计算得到证书数字摘要，然后用权威机构私钥加密数字摘要得到数字签名
• 签名计算方法
• 证书对应的域名

https过程

比如你如何确信这个网站是一个好网站？好网站就会有一个“好网站证书”，也就是certification，这个证书是由CA（certificate authority）颁布的，

• 客户端每次链接，网站都先去找CA拿一份证书，然后把这个证书一起发给客户，来证明自己的清白。也许你会问，万一是一个坏网站自己伪造的证书呢？
• 然后客户端、服务端就要决定用什么方式加密。加密的方式有很多种，比如各种AES啦什么的。客户端告诉服务器，我的浏览器支持哪些加密方式，然后服务器选择其中一种，于是你们之间的数据就被加密了，这就是confidentiality。
• 那怎么保证你的数据不被修改呢？这就要说到hash，hash算法可以把一个长长的数据变短，一般情况下，不同的长数据变成的短数据，是不一样的。哪怕长数据里面只变化了一点点，短数据也会差别很大（专业术语叫avalanche effect）。传输数据的时候，把这个短数据一并传了，对方就可以知道整个数据包是否被修改。当然这需要双方都提前知道一些并没有被传输的秘密。常用的hash有md5和SHA256等。

客户端在使用HTTPS方式与Web服务器通信时的步骤

• （1）客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。
• （2）Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。
• （3）客户端的浏览器与Web服务器开始协商SSL/TLS连接的安全等级，也就是信息加密的等级。
  这里其实需要做验证，验证证书，验证比较繁琐，首先验证证书机构，证书机构都是预先嵌入到我们的浏览器系统中的。这个验证通过后，验证证书内容，从浏览器中找到CA机构的根公钥，用这个公钥去解析证书的签名得到一个hash值H1，上面提到过，这个签名是证书发布之前CA机构用自己的根私钥加密而成的，所以这里只能由根证书的根公钥去解密。然后用证书的指纹算法对证书的内容再进行hash计算得到另一个hash值H2，如果此时H1和H2是相等的，就代表证书没有被修改过。在证书没有被修改过的基础上，再检查证书上的使用者的URL（比如csdn.net）和我们请求的URL是否相等，如果相等，那么就可以证明当前浏览器连接的网址也是正确的，而不是一些钓鱼网之类的。
• （4）客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。公钥就在证书里。
• （5）Web服务器利用自己的私钥解密出会话密钥。
• （6）Web服务器利用会话密钥加密与客户端之间的通信。

如果有一个钓鱼网站伪装证书，我们来看下能不能成功，CA机构在颁发证书之前会用自己的私钥对其加密，所以浏览器上的根公钥才可以解密，钓鱼网站的证书因为不是私钥加密，所以根据无法解密，也就得不到假的证书中的信息，不过好像这个公钥是对证书的签名进行加密，然后再通过签名方法对证书内容计算得到新签名，对比两个签名是否一样来证明证书内容是不是被篡改了

这里要注意：

• 客户端会话公钥是对传输内容加密的。
• 服务端的公钥、密钥是用来对客户端会话公钥做加密、解密的，保证会话公钥传输的时候不会被别人盗取。
  

参考博客