HTTPS单向认证与双向认证

HTTPS单向认证与双向认证

HTTPS

Https就是HTTP+SSL/TSL的简称。
SSL(Secure Socket Layer 安全套接层)是TCP/IP协议中基于HTTP之下TCP之上的一个可选协议层。
起初HTTP在传输数据时使用的是明文，传输过程中并不安全。网景（Netscap）公司推出了SSL解决了这一安全隐患，因此越来越多的人也开始使用HTTPS。在SSL更新到3.0时， 互联网工程任务组（IETF）对SSL3.0进行了标准化，并添加了少数机制，并将其更名为TLS1.0(Transport Layer Security 安全传输层协议)，可以说TLS就是SSL的新版本3.1。TLS与SSL两者所使用的算法是不同的TLS增加了许多新的报警代码，比如解密失败(decryption_failed)、记录溢出(record_overflow)、未知CA(unknown_ca)、拒绝访问(access_denied)等，但同时也支持SSL协议上所有的报警代码。由于这些区别的存在，我们可认为TLS是SSL的不兼容增强版。即TLS和SSL不能共用，在认证证书时TLS指定必须与TLS之间交换证书， SSL必须与SSL之间交换证书。

CA证书

CA是Certificate Authority（证书授权）的简称,是由认证机构服务者签发，是数字签名的技术基础保障，也是网上实体身份的证明，能够证明某一实体的身份及其公钥的合法性，证明该实体与公钥二者之间的匹配关系。
CA证书一般由证书认证机构（CA）签发，过程：
1、申请者自己通过非对称加密算法（RSA） 生成对应的公钥和私钥，然后把需要的申请信息（国家，域名等）连同公钥（就是RSA生成的公钥）发送给 证书认证机构（CA）
2、证书认证机构（CA）确认无误后通过消息摘要算法（MD5，SHA) 加密申请的CA证书中的信息，加密完的就叫信息摘要，然后把信息摘要用CA的私钥（申请的RSA私钥） 进行加密，加密完的数据就是签名。

单向认证

1、客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。
2、服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书（包含了公钥和数字签名）。
3、客户端使用服务端返回的信息验证服务器的合法性，包括：

  • 证书是否过期（这个可能就是平常访问浏览器有红色的提示的原因）
  • 发行服务器证书的CA是否可靠（这个可能就是平常访问浏览器有红色的提示的原因）
  • 返回的公钥是否能正确解开返回证书中的数字签名
  • 服务器证书上的域名是否和服务器的实际域名相匹配
  • 验证通过后，将继续进行通信，否则，终止通信

4、客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择。
5、服务器端在客户端提供的加密方案中选择加密程度最高的加密方式。
6、服务器将选择好的加密方案通过明文方式返回给客户端。
7、客户端接收到服务端返回的加密方式后，使用该加密方式生成产生随机码，这个随机码则用作通信过程中对称加密的密钥，使用服务端返回的公钥进行加密，将加密后的随机码发送至服务端。
8、服务器收到客户端返回的加密信息后，使用CA的私钥进行解密，获取对称加密密钥。 在接下来的会话中，服务器和客户端将会使用该对称加密密钥进行对称加密，保证通信过程中信息的安全。
个人理解：单向认证在认证方面，只有客户端对服务端的证书进行了验证，验证了这个SSL证书是否是可信的，而服务端并没有对客户端的相关信息进行验证，这就导致了下面抓包工具在https中进行抓包！

双向认证

1、客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。
2、服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书（包含了公钥和数字签名）
3、客户端使用服务端返回的信息验证服务器的合法性，验证通过后，将继续进行通信，否则，终止通信，其中包括：

  • 证书是否过期
  • 发行服务器证书的CA是否可靠
  • 返回的公钥是否能正确解开返回证书中的数字签名
  • 服务器证书上的域名是否和服务器的实际域名相匹配

4、服务端要求客户端发送客户端的证书（这个证书指的就是内置存储在当前APP中通信需要用的证书），客户端会将自己内置的证书发送至服务端（在APP中一般都是类似client.p12的文件等等的）
5、服务端验证客户端的证书，通过验证后，会获得客户端的公钥
6、客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择
7、服务器端在客户端提供的加密方案中选择加密程度最高的加密方式
8、服务端将加密方案通过使用之前客户端提供给服务端的公钥进行加密，返回给客户端
9、客户端收到服务端返回的加密方案密文后，使用自己内置证书的私钥进行解密，获取具体加密方式，而后，产生该加密方式的随机码，用作加密过程中的密钥，使用之前从服务端证书中获取到的公钥进行加密后，发送给服务端
10、服务端收到客户端发送的消息后，使用自己的私钥进行解密，获取对称加密的密钥，在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全。
ps：双向认证的客户端证书一般都可以是如openssl生成的自签名证书，包括 client.crt 和 client.key，这两部分内容可以集成在 p12 证书中, p12 证书可以设置打开密码。

个人理解证书验证的过程：
先理解下信任传递比如A信任C，B也信任C，那么AB就可以通过C也建立信任关系，CA是值得信任的因此CA颁发的证书值得信任，这个是证书验证的前提。

服务器会去CA申请一个数字证书，提交一些信息（RSA公钥，证书拥有者身份信息，数字证书认证机构（发行者）信息，发行者对这份文件的数字签名及使用的算法，证书的有效期），CA需要去核实这些信息，CA核实后会签发一个用CA私钥加密的数字证书给服务器，同时提供一个CA的公钥用于解密。

客户端收到服务端发送来的CA私钥加密的证书这个过程是如何保持不被第三方破解转发的呢？
证书是CA的私钥进行加密的，CA的私钥我们认为是安全可信的，因此就算第三方截取到消息可以进行解密（使用CA的公钥），但是无法串改信息后加密（因为第三方没有CA的私钥），这就保证了客户端收到的信息一定是服务端发来的，然后对服务的发来的证书进行验证