Https加密

发表于

http与https

https 全称Hyper Text Transfer Protocol Secure， 相比http多了secure，https到底比http安全在哪里呢？
http （Hyper Text Transfer Protocol）超文本传输协议，是一个基于请求与响应模式的、无状态的、应用层协议，位于TCP／IP协议上层。http协议用户客户端与浏览器端之前的信息传递与交互。
http所封装的信息是明文的，这就意为着可以通过抓包工具获取内容信息，这是很不安全的，所以就需要https，它在http的基础上添加了SSL(安全套接字层)层来保证传输数据的安全问题。
TCP/IP四层协议从下往上包括数据链路层，IP（网络层），TCP（传输层），HTTP（应用层），https在http的基础上添加了TLS，SSL（安全层），位于TCP与http层之间。

http工作流程

http的大体流程是客户端向服务器端发送请求，服务器回送响应。(http协议是一个无状态的协议，同一个客户端的这次请求和上次请求是没有对应关系)一次HTTP操作称为一个事务，其工作过程可分为四步：

  1. 首先客户端与服务器需要建立连接。
  2. 建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是MIME信息包括请求修饰符、客户端信息等。
  3. 服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个状态码，服务器信息、实体信息等。
  4. 客户端接收服务器所返回的信息通过浏览器显示在用户的显示屏上，然后客户端与服务器断开连接。

这样一个流程看似没有问题，但是http所封装的信息是明文的，信息有可能被别人获取，这就需要https。

https工作流程

https的工作流程和http的流程大题一致。但是https对传输的数据有加密和解密的操作。总结起来就是：客户端将数据通过密钥加密生成密文，客户端向服务器端发送密文。服务器端收到密文之后，用密钥解密得到原始数据。但是这里有一个问题，密钥如何传输？密钥如果在传输的过程中被中间人截获了，那么传输的数据还是会轻易的被人获取。
那其实还有一种办法，就是客户端通过公钥加密数据，发送到服务器之后通过私钥解密，公钥是可以公开的，私钥不公开，一个公钥对应一个私钥，二者不能互相计算出，而且用私钥加密的数据，只有对应的公钥才能解密，用公钥加密的数据， 只有对应的私钥才能解密。但是这样又出现了一个问题，这种加密方式比之前慢多了。

对称加密+非对称加密

  1. 对称加密 : 采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密.
  2. 非对称加密 : 非对称加密也叫公开密钥加密,它使用了两个密钥,一个为公钥,一个为私钥,当一个用作于加密的时候,另一个则用作解密.这两个密钥就算被其他人知道了其中一个也不能凭借它计算出另一个密钥,所以可以公开其中一个密钥(也就是公钥),不公开的密钥为私钥.

可以看出对称加密比较简便，但是一旦被人获取了密钥，数据就随之公开。非对称加密相对繁琐，却不会因为密钥被获取而泄露数据。
回到最初的问题，如果解决的了对称加密中的密钥传输问题，后续就可以使用对称加密来传输数据了。那么，何不结合对称加密和非对称加密？先使用非对称加密传输对称加密使用的密钥，这样就保证密钥不会泄露，之后客户端和服务器端使用对称加密的密钥传输数据，由于密钥没有泄露，中间人即使获取了密文，也没办法解密。既解决了密钥的传递问题， 又解决了非对称加密速度慢的问题。

怎么证明你是你

但是，这样又引发了一些问题：

  • 客户端怎么确保获取的公钥就是服务器发送过来的密钥呢？

如果中间人获取了服务器发送的公钥，将自己的公钥发送给客户端，客户端就会用这个公钥加密数据，中间人获取后就可以用自己私钥解密！！必须要确保是服务器的公钥发送到客户端！！
问题回到公钥的发送，公钥虽然可以公开，但是可能会被别有用心的人利用。怎样确保公钥安全无误地传输到客户端呢？
解决方法依是通过一个权威的CA(Certificate Authority)证书中心,它来负责颁发证书,这个证书包含:

  1. 证书的发布机构.
  2. 证书的有效期
  3. 公钥
  4. 证书所有人
  5. 数字签名

将公钥和个人信息用一个Hash算法生成一个消息摘要，这个Hash算法是不可逆的，只要输入数据有一点点变化，那生成的消息摘要就会有巨变，这样就可以防止别人修改原始内容，再将消息摘要通过CA的私钥加密,最终形成数字签名。数字签名用户验证数据的完整性。
当客户端接收到证书时,只需要用同样的Hash算法再次生成一个消息摘要,然后用CA的公钥对证书进行解密,之后再对比两个消息摘要就能知道数据有没有被篡改过了。
但是又出现了一个问题：CA的公钥要从哪里来呢？？又会到公钥的传输的问题。陷入鸡生蛋，蛋生鸡的无限循环中。
这就要从CA说起了。
网上的公众用户通过验证CA的签字从而信任CA，任何人都可以得到CA的证书含公钥，用以验证后续它所签发的证书。如果用户想得到一份属于自己的证书，他应先向CA提出申请。在CA 判明申请者的身份后，便为他分配一个公钥，并且CA将该公钥与申请者的身份信息绑在一起，并为之签字后，便形成证书发给申请者。CA证书的信用体系就像一棵树的结构,上层节点是信用高的CA同时它也会对底层的CA做信用证书,操作系统中已经内置了一些根证书,所以相当于你已经自动信任了它们(需要注意误安装一些非法或不安全的证书)。
这就是说，当客户端使用CA证书的时候，就已经默认信任CA了。
这样通过CA证书验证，客户端就可以确保获得服务器的公钥，再使用公钥进行非对称加密传输对称加密所需的密钥，最后用这个密钥加密和解密。

总结

  1. 客户端与服务器连接，客户端向服务器发送请求。
  2. 服务器向客户端发送CA证书。
  3. 客户端读取证书中的所有人,有效期等信息并进行校验。
  4. 客户端查找操作系统中内置的已经信任的根证书,并对服务器发来的证书进行验证。
  5. 验证成功之后，客户端会从操作系统中取出CA的公钥,然后对服务器发来的证书中的数字签名进行解密。
  6. 客户端使用相同的Hash算法计算出消息摘要,然后对数字签名中的消息摘要进行校对。
  7. 校对成功，则证明证书安全。客户端获取非对称加密的公钥，生成后续对称加密所需的密钥，利用非对称加密的公钥对该密钥加密生成密文，传输给服务器端。
  8. 服务器获取密文，利用非对称加密的私钥解密，获取后续对称加密所需的密钥。
  9. 服务器和客户端使用密钥进行对称加密传输。

总结起来就是，通过一系列的操作保证密钥不被获取，然后用密钥进行对称加密传输数据。