有次面试，面试官问到这个问题，当时没准备，只是凭记忆里的印象回答了一些，不是很准确，重新查了下资料，记录一下。
首先要明确过程中涉及到的几个关键词：
- 对称加密
- 就是最容易理解的加密方式，双方可以使用同一个秘钥对明文进行加密和解密。
- 非对称加密RSA及其公钥、私钥
- 利用原理为对极大整数做因数分解，当其位数足够多时，目前尚无可靠的破解方法，但加解密速度也比对称加密更慢。
- 公钥：可以给任意人持有，用来对明文a进行加密成b。
- 私钥：只能给所有者持有，不能泄露给任何人（包括3），否则加密就会被破解。用来把b解密成a。
- 数字证书认证机构（CA，Certificate Authority）及其公钥、私钥
- 为域名持有者颁发非对称加密公私钥证书的权威机构。
- 私钥仅数字证书认证机构持有，作用是为域名持有者的公开密码加密生成其RSA中公钥。
- 公钥作用是给客户端用来查询验证收到的服务端公钥证书签名是否为正确的，即验证通信域名公钥证书的有效性。
整个https安全机制如下：
客户端服务端双向认证：
- 由于SSL协议是在TCP和应用层协议(如HTTP)之间的，所以先进行TCP三次握手。
- 客户端发出请求，并告诉服务端它所支持的加密协议版本等，确保后续双方使用的加密协议是前者的子集。
- 服务端收到请求后，基于前述信息发出此次通信的加密协议版本等，并发送自己的公钥证书给客户端。
- 客户端收到公钥证书后，用内置的数字证书认证机构公钥向机构查询验证此公钥证书的有效性。如果不通过，客户端会对用户进行提示，比如该域名不可信等，用户可以选择继续进行下一步或者中止访问，如果通过，则直接进行下一步。
- 客户端随机生成一个会话秘钥（对称加密）client-key，和一对RSA非对称公私钥(client-public-key / client-private-key)，并将会话秘钥(client-key)和RSA公钥(client-public-key)用上述收到的服务端域名公钥(server-public-key)进行加密传给服务端。
- 服务端收到报文后，用自己的私钥(server-private-key)对报文解密，得到客户端会话秘钥(client-key)和客户端RSA公钥(client-public-key)。
- 服务端随机生成服务端会话秘钥(server-key)，并用客户端RSA公钥(client public key)对服务端会话秘钥(server-key)加密，并将加密结果发送给客户端。
- 客户端收到报文后，用自己在步骤4中的RSA私钥(client-private-key)对报文进行解密，得到服务端会话秘钥(server-key)。 截止到此，客户端拥有了服务端会话的秘钥(server-key)，服务端拥有了客户端会话的秘钥(client-key)，均为对称加密秘钥，后续双方通信均基于这两个秘钥，比如客户端把要发送的数据用(client-key)加密，服务端收到后可以用(client-key)解开，反之亦然。
服务端单向认证过程：
- 客户端发出请求，携带一个随机数a和它所支持的加密协议信息。
- 服务端收到请求，基于客户端所支持的加密协议信息，选择二者均可用的加密协议，并生成一个随机数b和自己的公钥证书，发送给客户端。
- 客户端收到公钥证书后，用内置的数字证书认证机构公钥向机构查询验证此公钥证书的有效性，得到服务端域名公钥(server-public-key)。如果不通过，客户端会对用户进行提示，比如该域名不可信等，用户可以选择继续进行下一步或者中止访问，如果通过，则直接进行下一步。
- 客户端再随机生成一个随机数c，并将它用上述收到的服务端域名公钥(server-public-key)进行加密传给服务端。
- 服务端收到报文后，用自己的私钥(server-private-key)对报文解密，得到客户端刚传过来的随机数c，然后利用a/b/c三个随机数共同生成一个会话秘钥(premaster-secret),同时，客户端也是知道这三个数的，也可以得到会话秘钥。
- 基于此会话秘钥，后续二者的全双工数据交流均由此秘钥加密解密。
来说一下上述过程为什么要这么做。
-
为什么http配合对称加密无法保证安全？
- 如果还是老的http协议，没有上述的RSA加密参与，客户端与服务端中任何一层中间代理都可以明文截获传输报文，信息安全等于没有。即使报文使用了对称加密，但第一步握手时双方也需要知晓对称加密秘钥，这同样很容易被截获，导致后续数据依然可以被中间人解密。
-
为什么不能只用RSA，而在最后还是要结合会话秘钥的对称加密来加密数据？
- 如果只用RSA，虽然客户端发送给服务端的数据，中间人由于没有服务端私钥故解不开数据，但是服务端发送给客户端的数据被中间人截获后，中间人是可以得到服务端的公钥的，用公钥就可以解开私钥加密的数据，单向数据安全为零。
-
为什么要使用数字证书？
- 因为如果只传输RSA中的公钥，那么中间人只要伪造自己为原始服务端的客户端同时又是原始客户端的服务端，就可以在中间明文获取原始服务端的公钥，然后把自己的公钥给客户端，这样就欺骗了双方，相当于一个传话筒在中间任意截获甚至篡改通信内容。而使用了数字证书后，客户端会用浏览器（操作系统）中内置的根证书公钥去验证证书的有效性，从中解出服务端公钥信息，如果是中间人伪造的证书，这一步是通不过的，所以会安全一些。
-
抓包工具的原理是怎样的？
- 抓包工具其实就是3中所述的中间人攻击原理，只不过，由于是伪造的证书，所以需要用户提前安装工具的证书并信任，相当于在客户端校验证书有效性时对抓包工具开了绿灯。
-
即使有抓包工具，并且也安装信任了对应证书，为什么在APP端有的应用依然抓取不到https请求的信息？或者说如何在这种情况下，让APP有防止抓包工具抓包的功能？这可以有效保护APP内部接口等信息的泄露。
- 监听应用是否走了代理，如果有，则拒绝一切请求。
- 内部的数字证书校验走完整校验流程。（待补充完善）
参考：rfc
