以下是证书校验逻辑

结论：非对称加密的主要目的保证session key（会话密钥） 的安全性。当获取到session key之后使用对称加密节省开销。

疑惑： 服务器返回的公钥是如何与URL验证是否匹配的？

ssl需要2个证书，分别是服务器和客户端，服务器中放在服务器空间中，客户端如果是手机，在设置中的 加密与凭证 中可查看。如果手机或浏览器中没有对应的证书，导致url和公钥不匹配。出现警号信息。所以针对中间人抓包https，手机中需要安装证书。

证书颁发流程：

1，从域名或主机提供商处购买，填写相关信息后会生成一个证书，这个证书上传到服务器即可。

服务器端证书校验和客户端证书校验

即便是本地安装了证书，charles或fiddler等工具也不一定能抓到包，原因之一：

1，服务器端证书校验。服务器校验客户端的证书。即https请求时，客户端将证书携带传给服务器端。服务器端通过后返回数据。由于charles证书不满足服务器端要求，所以这种情况下，能抓到request包，但response包因为证书错误所有无返回。相关nodejs代码：

const httpsAgent = new https.Agent({
  rejectUnauthorized: false, // (NOTE: this will disable client verification)
  cert: fs.readFileSync("./usercert.pem"),
  key: fs.readFileSync("./key.pem"),
  passphrase: "YYY"
})

axios.get(url, { httpsAgent })

// or

const instance = axios.create({ httpsAgent })

2，客户端校验服务器证书。https请求时会先拿服务器公钥（证书），如果服务器传过来的证书与apk代码中或文件中的不相符，则证明存在三方窃听的可能性，导致请求不会发出。

为什么此段代码能使抓包工具抓不到吗？以下代码为去掉代理，frida添加以下代码后使apk恢复至普通模式，即可正常抓包，比如酷我畅听app的包就是这样抓到的。

Java.perform(function() {
    try {
        var URL = Java.use("java.net.URL");
        URL.openConnection.overload('java.net.Proxy').implementation = function(arg1){
            return this.openConnection();//this指向URL实例
        }
    } catch(e) {
        console.log("" + e);
    }

    /*try {
        var Builder = Java.use("okhttp3.OkHttpClient$Builder");
        var mybuilder = Builder.$new();
        Builder.proxy.overload('java.net.Proxy').implementation = function(arg1){
            return mybuilder;
        }
    } catch(e) {
        console.log("" + e);
    }*/
});

问题：

session key 如何加密以节省开销？

先用RSA非对称加密，拿到sessionKey，花销大。再用sessionKey做为密钥，数据传输时使用对称加密，如aes,des。花销小。

服务器端证书校验和客户端证书校验区别？

服务器端 证书校验 ，指的是服务器校验客户端的证书，用charles或者fiddler的证书，并不是app里面的证书， 服务器校验的是charles的证书，一匹配发现不是app的证书，就返回网络失败，所以我们要将app中内置的证书导入到Charles中去。 特征是 挂上vpn，打开charles抓包可以看到没网络，但是可以抓到包，怀疑是服务器校验客户端证书了。解决办法是逆向后找到证书文件和密码。详细办法参与如下：

https://blog.csdn.net/qq409732112/article/details/120061517

客户端证书校验，指的是客户端校验服务端的证书，客户端发起请求，服务端将公钥返回，客户端检查服务器公钥网址，到期时间等是否匹配，匹配则进行下一步，这就是 客户端 证书校验过程。web传输不存在服务器证书校验。只有安卓和苹果才存在。因为服务器是1对多的关系。

服务器证书购买需要提供哪些信息？证书包含了哪些信息？

点击确定后下一定就是文件验证。

通过zgnet.com购买的证书，包含了证书颁发的机构，证书开始时间和到期时间，域名，

如何通过抓包找到session key 以破解https，找到原文传输。

关于SSL:
一般情况下的网络协议应用中，数据在机器中经过简单的由上到下的几次包装，就进入网络，如果这些包被截获的话，那么可以很容易的根据网络协议得到里面的数据.由网络监听工具可以很容易的做到这一点。

SSL就是为了加密这些数据而产生的协议，可以这么理解，它是位与应用层和 TCP/IP之间的一层，数据经过它流出的时候被加密，再往TCP/IP送，而数据从TCP/IP流入之后先进入它这一层被解密，同时它也能够验证网络连接两端的身份（根据我们之前学习的不对称加密算法只是可知）。

SSL协议包含2个子协议，一个是包协议，一个是握手协议。包协议位于握手协议更下一层，我们暂时对包协议的内容没有兴趣。SSL握手过程说简单点就是：通信双方通过不对称加密算法来协商好一个对称加密算法以及使用的key，然后用这个算法加密以后所有的数据完成应用层协议的数据交换。

SSL通信流程：
握手一般都是由client发起的，SSL也不例外。
1、client送给server它自己本身使用的ssl的version(ssl一共有三个version)，加密算法的一些配置，和一些随机产生的数据，以及其他在SSL协议中需要用到的信息。
2、server送给client它自己的SSL的version，加密算法的配置，随机产生的数据，还会用自己的私有密钥加密SERVER-HELLO信息。Server还同时把自己的证书文件给送过去。同时有个可选的项目，就是server可以要求需要客户的certificate。
3、client就用server送过来的certificate来验证server的身份。如果server身份验证没通过，本次通信结束。通过证书验证之后，得到server的公共密钥，解开server送来的被其用私有密钥加密过的SERVER-HELLO信息，看看对头与否。如果不对，说明对方只有该server的公共密钥而没有私有密钥，必是假的。通信告吹。
4、client使用到目前为止所有产生了的随机数据(sharedsecret)，client产生本次握手中的premastersecret(这个步骤是有可能有server的参与的，由他们使用的加密算法决定)，并且把这个用server的公共密钥加密，送回给server.如果server要求需要验证client,那么client也需要自己把自己的证书送过去，同时送一些自己签过名的数据过去。
RSA就是我们上一章说过的一种不对称加密算法。首先server把自己的RSA公共密钥送给client，client于是用这个key加密一个随机产生的值(这个随机产生的值就是sharedsecret)，再把结果送给server.
5、Server验证完client的身份之后，然后用自己的私有密钥解密得到premastersecret然后双方利用这个premastersecret来共同协商，得到mastersecret.
6、双方用master一起产生真正的sessionkey,着就是他们在剩下的过程中的对称加密的key了。这个key还可以用来验证数据完整性。双方再交换结束信息。握手结束。

回过头来我们看openssl，openssl就是实现ssl的一个软件，下面我就讨论刚才的命令，生成一个私有密钥：
openssl genrsa -des3 -out server.key 1024
genras表示生成RSA私有密钥文件，-des3表示用DES3加密该文件，1024是我们的key的长度。一般用512就可以了，784可用于商业行为了，1024可以用于军事用途了。生成server.key的时候会要你输入一个密码，这个密钥用来保护你的server.key文件，这样即使人家偷走你的server.key文件，也打不开，拿不到你的私有密钥。