HTTPS 认证
HTTPS 认证
HTTPS 认证介绍
HTTPS基础知识：HTTPS (Secure Hypertext Transfer Protocol)安全超文本传输协议，是一个安全通信通道，它基于HTTP开发用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换，简单来说它是HTTP的安全版,是使用TLS/SSL加密的HTTP协议。 HTTP协议采用明文传输信息，存在信息窃听、信息篡改和信息劫持的风险，而协议TLS/SSL具有身份验证、信息加密和完整性校验的功能，可以避免此类问题发生。HTTPS是在HTTP上建立SSL加密层，并对传输数据进行加密，是HTTP协议的安全版。HTTPS主要作用是：
- 对数据进行加密，并建立一个信息安全通道，来保证传输过程中的数据安全;
- 对网站服务器进行真实身份认证。
TLS/SSL全称安全传输层协议Transport Layer Security, 是介于TCP和HTTP之间的一层安全协议，不影响原有的TCP协议和HTTP协议，所以使用HTTPS基本上不需要对HTTP页面进行太多的改造。
单向认证双向认证
单向认证指的是只有一个对象校验对端的证书合法性。
通常都是client来校验服务器的合法性。那么client需要一个ca.crt,服务器需要server.crt,server.key
双向认证指的是相互校验，服务器需要校验每个client,client也需要校验服务器。
server 需要 server.key 、server.crt 、ca.crt
client 需要 client.key 、client.crt 、ca.crt
CA 的证书 ca.crt 和 SSL Server的证书 server.crt 是什么关系呢？
- SSL Server 自己生成一个 私钥/公钥对。server.key/server.pub // 私钥加密，公钥解密！
- server.pub 生成一个请求文件 server.req. 请求文件中包含有 server 的一些信息，如域名/申请者/公钥等。
- server 将请求文件 server.req 递交给 CA，CA验明正身后，将用 ca.key和请求文件加密生成 server.crt
- 由于 ca.key 和 ca.crt 是一对, 于是 ca.crt 可以解密 server.crt.
在实际应用中：**如果 SSL Client 想要校验 SSL server.那么 SSL server 必须要将他的证书 server.crt 传给 client.然后 client 用 ca.crt 去校验 server.crt 的合法性。**如果是一个钓鱼网站，那么CA是不会给他颁发合法server.crt证书的，这样client 用ca.crt去校验，就会失败。比如浏览器作为一个 client,你想访问合法的淘宝网站https://www.taobao.com, 结果不慎访问到 https://wwww.jiataobao.com ,那么浏览器将会检验到这个假淘宝钓鱼网站的非法性，提醒用户不要继续访问！这样就可以保证了client的所有https访问都是安全的。
单向认证
Https在建立Socket连接之前，需要进行握手，具体过程如下：
- 客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。
- 服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书
- 客户端使用服务端返回的信息验证服务器的合法性，包括：
- 证书是否过期
- 发型服务器证书的CA是否可靠
- 返回的公钥是否能正确解开返回证书中的数字签名
- 服务器证书上的域名是否和服务器的实际域名相匹配
验证通过后，将继续进行通信，否则，终止通信
- 客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择
- 服务器端在客户端提供的加密方案中选择加密程度最高的加密方式。
- 服务器将选择好的加密方案通过明文方式返回给客户端
- 客户端接收到服务端返回的加密方式后，使用该加密方式生成产生随机码，用作通信过程中对称加密的密钥，使用服务端返回的公钥进行加密，将加密后的随机码发送至服务器
- 服务器收到客户端返回的加密信息后，使用自己的私钥进行解密，获取对称加密密钥。
在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全。
双向认证
双向认证和单向认证原理基本差不多，只是除了客户端需要认证服务端以外，增加了服务端对客户端的认证，具体过程如下：
- 客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。
- 服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书
- 客户端使用服务端返回的信息验证服务器的合法性，包括：
- 证书是否过期
- 发型服务器证书的CA是否可靠
- 返回的公钥是否能正确解开返回证书中的数字签名
- 服务器证书上的域名是否和服务器的实际域名相匹配
验证通过后，将继续进行通信，否则，终止通信
- 服务端要求客户端发送客户端的证书，客户端会将自己的证书发送至服务端
- 验证客户端的证书，通过验证后，会获得客户端的公钥
- 客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择
- 服务器端在客户端提供的加密方案中选择加密程度最高的加密方式
- 将加密方案通过使用之前获取到的公钥进行加密，返回给客户端
- 客户端收到服务端返回的加密方案密文后，使用自己的私钥进行解密，获取具体加密方式，而后，产生该加密方式的随机码，用作加密过程中的密钥，使用之前从服务端证书中获取到的公钥进行加密后，发送给服务端
- 服务端收到客户端发送的消息后，使用自己的私钥进行解密，获取对称加密的密钥，在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全。
相关问题
- 客户端是如何校验公钥证书合法性的?
- Https到底怎么来防止中间人攻击的（Man-in-the-middle attack，缩写：MITM）?
- 客户端如果没有内置公钥可以使用HTTPS么？
首先，我们需要了解 HTTPS 握手时使用的加密算法：对称加密算法和非对称加密算法。
了解了这俩种加密方式，再来看客户端如何校验公钥证书合法性，如果出现了中间人攻击，中间替换了公钥证书，客户端是如何校验的？既然是合法性的问题，服务器和客户端俩个当事人谁说了都不算，由数字证书认证机构（CA,Certificate Authority）和其相关机构颁发的公开密钥证书说了算。
证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文，同时包含一个签名；签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA 的私钥对信息摘要进行加密，密文即签名；
客户端在对服务器 say hello 之后，服务器将公开密钥证书发送给客户端，注意这个证书里面包含了公钥+各种信息+签名（私钥对各种信息加密后生成签名），客户端收到公开密钥证书后，相当于收到了一个包裹里面有公钥+各种信息+签名，怎么样使用这三个数据来校验尼，很简单，公钥加密，私钥解，私钥加密公钥也可以解，只要利用公钥对签名进行解密，然后最和各种信息做比较就可以校验出证书的合法性。
证书
私钥：私钥就是一个算法名称加上密码串，自己保存，从不给任何人看
公钥：公钥也是一个算法名称加上密码串，一般不会单独给别人，而是嵌在证书里面一起给别人
CA：专门用自己的私钥给别人进行签名的单位或者机构
申请（签名）文件：在公钥的基础上加上一些申请人的属性信息，比如我是谁，来自哪里，名字叫什么，证书适用于什么场景等的信息，然后带上进行的签名，发给CA（私下安全的方式发送），带上自己签名的目的是为了防止别人篡改文件。
证书文件：证书由公钥加上描述信息，然后经过私钥签名之后得到，一般都是一个人的私钥给另一个人的公钥签名，如果是自己的私钥给自己的公钥签名，就叫自签名。
签名过程：CA收到申请文件后，会走核实流程，确保申请人确实是证书中描述的申请人，防止别人冒充申请者申请证书，核实通过后，会用CA的私钥对申请文件进行签名，签名后的证书包含申请者的基本信息，CA的基本信息，证书的使用年限，申请人的公钥，签名用到的摘要算法，CA的签名。
证书找谁签名合适
别人认不认你的证书要看上面签的是谁的名，所以签名一定要找权威的人来签，否则别人不认，哪谁是权威的人呢？那就是CA，哪些CA是受人相信的呢？那就要看软件的配置，配置相信谁就相信谁，比如浏览器里面默认配置的那些，只要是那些CA签名的证书，浏览器都会相信，而你自己写的程序，可以由你自己指定信任的CA。
信任一个CA就是说你相信你手上拿到的CA的证书是正确的，这是安全的前提，CA的证书是怎么到你手里的，这个不属于规范的范畴，不管你是U盘拷贝的，还是怎么弄来得，反正你得确保拿到的CA证书没问题，比如浏览器、操作系统等，安装好了之后里面就内置了很多信任的CA的证书。
那么CA的证书又是谁签的名呢？一般CA都是分级的，CA的证书都是由上一级的CA来签名，而最上一级CA的证书是自签名证书。
证书如何验证
下面以浏览器为例，说明证书的验证过程：
- 在TLS握手的过程中，浏览器得到了网站的证书
- 打开证书，查看是哪个CA签名的这个证书
- 在自己信任的CA库中，找相应CA的证书，
- 用CA证书里面的公钥解密网站证书上的签名，取出网站证书的校验码（指纹），然后用同样的算法（比如sha256）算出出网站证书的校验码，如果校验码和签名中的校验码对的上，说明这个证书是合法的，且没被人篡改过
- 读出里面的CN，对于网站的证书，里面一般包含的是域名
- 检查里面的域名和自己访问网站的域名对不对的上，对的上的话，就说明这个证书确实是颁发给这个网站的
- 到此为止检查通过
如果浏览器发现证书有问题，一般是证书里面的签名者不是浏览器认为值得信任的CA，浏览器就会给出警告页面，这时候需要谨慎，有可能证书被掉包了。如访问12306网站，由于12306的证书是自己签的名，并且浏览器不认为12306是受信的CA，所以就会给警告，但是一旦你把12306的根证书安装到了你的浏览器中，那么下次就不会警告了，因为你配置了浏览器让它相信12306是一个受信的CA。
中间人攻击
第一种：客户端say hello 后，被代理服务器拦截，然后他再向我们真正的服务器发相同的say hello，这时候服务器不知道你是谁，给了代理服务器公开密钥证书，然后代理服务器再把证书转发给客户端，客户端校验没毛病，然后用公钥加密的随机字符串发给代码服务器，这个时候代理服务器懵逼了，因为他没有私钥，解密不到随机字符串到底是什么，好吧，他虽然看不懂，但是还是把这一坨东西原封不动的给了服务器，服务器一看，没毛病，再把加密信息给代理服务器，代理服务器，因为不知道刚才的随机字符串是什么，而这个时候客户端和服务器已经不再使用公钥加密，而是使用了共享密钥加密，而关键的关键就是密钥就是刚才的随机字符串。代理服务器再次懵逼，就看数据来来回回，可是他看不懂，这样的中间人，只能算蠢萌的中转人，这也就是使用了HTTPS之后，packetCapture截取到的数据都是乱码的原因。
第二种：客户端say hello 后，被代理服务器拦截，代理服务器也有CA颁发的证书，他把自己的合法证书发给客户端，客户端用证书里面的公钥解密签名之后，得到了各种信息，一看信息都对上了，没毛病信任。然后代理服务器宰相真正的服务器say hello，服务器下发真正的证书，代理服务器假装自己是客户端，信任了证书，然后校验通过，发用真正公钥加密后的随机数给服务器，服务器当然能解开，也就是代理服务器作为客户端和真正的服务器建立了合法的通信。再看客户端在校验了代理服务器自己的证书后也建立了合法的通信，这个时候，代理服务器作为中间人，因为他有自己的私钥和真正的公钥，可以欺上瞒下，俩边的信息都从它这里过了一次，信息被他偷窥到。攻击成功。
怎么防御？
客户端内置真正的公钥，当代理服务器把它自己的证书传过来的时候，客户端用内置的公钥去解密证书中的签名，因为不是真正的私钥加密的所以解密失败，校验也就失败，连接中断。这也就是客户端信任所有的证书的风险—被中间人攻击。
客户端如果没有内置公钥可以使用HTTPS么？
解析到这里，想必大家也知道第三个问题的答案 ：客户端如果没有内置公钥可以使用HTTPS么？当然可以，只是不安全，会被MITM。
握手不成功常见问题
配置好了之后还是连不上，一般会是下面几种问题：
- 版本不一致，有一方的版本太低，另一方为了安全不同意跟它通信
- 无法就cipher suite达成一致，有一方支持的加密算法太弱，安全程度不够
- 证书有问题，没法通过验证
- 服务器端需要验证客户端的证书，而客户端没有配置
参考链接
HTTP和HTTPS协议，看一篇就够了
想不通HTTPS如何校验证书合法性来看
SSL/TLS 双向认证(一) – SSL/TLS工作原理
SSL/TLS及证书概述