客户端访问https网站

一般有两种方式实现，一是信任所有的证书，也就是跳过证书合法性校验这一步骤，对于这种做法肯定是有风险的；二是校验证书，证书合法才能访问。

第一种方式 :信任所有证书

解决证书不被系统承认的方法，就是跳过系统校验。要跳过系统校验，就不能再使用系统标准的SSLSocketFactory了，需要自定义一个。然后为了在这个自定义的SSLSocketFactory里跳过校验，还需要自定义一个X509TrustManager（Android采用的是X509验证），建立我们的验证规则，在其中忽略所有校验，即TrustAll。

    // okhttp不验证绕过自己证书,使用android内置证书，直接通过所有的https连接
    // 获取这个SSLSocketFactory
    public static SSLSocketFactory getSSLSocketFactory() {
        try {
            SSLContext sslContext = SSLContext.getInstance("SSL");
            sslContext.init(null, getTrustManager(), new SecureRandom());
            return sslContext.getSocketFactory();
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }

使用这样的极端方式，虽然使用了HTTPS，实现了客户端和服务器端的通信内容得到了加密，嗅探程序无法得到传输的内容，但引生出来一种弊端,无法抵挡“中间人攻击”。例如，在内网配置一个DNS，把目标服务器域名解析到本地的一个地址，然后在这个地址上使用一个中间服务器作为代理，它使用一个假的证书与客户端通讯，然后再由这个代理服务器作为客户端连接到实际的服务器，用真的证书与服务器通讯。这样所有的通讯内容都会经过这个代理，而客户端不会感知，这是由于客户端不校验服务器公钥证书导致的，如charles抓包。

第二种方式:检验证书

image.png

为了防止上面方案可能导致的“中间人攻击”，我们可以下载服务器端公钥证书，然后将公钥证书编译到Android应用中一般在assets文件夹保存，由应用在交互过程中去验证证书的合法性。

    //使用内置证书
    public static SSLSocketFactory getSSLSocketFactory_Certificate(Context context) {
        try {
            //获取X.509格式的内置证书
            CertificateFactory certificateFactory = CertificateFactory.getInstance("X.509");
            KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());
            keyStore.load(null);
            Collection<? extends Certificate> cers = certificateFactory.generateCertificates(context.getAssets().open("CACertificate.cer"));
            int index = 0;
            for (Certificate certificate : cers) {
                String certificateAlias = Integer.toString(index++);
                keyStore.setCertificateEntry(certificateAlias, certificate);
            }
            //用这个KeyStore去引导生成的TrustManager来提供验证
            final TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
            trustManagerFactory.init(keyStore);
            //用TrustManager生成SSLContext
            SSLContext sslContext = SSLContext.getInstance("TLS");
            sslContext.init(null, trustManagerFactory.getTrustManagers(), new SecureRandom());
            //SSLContext返回SSLSocketFactory
            return sslContext.getSocketFactory();
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }

这样一来虽然抓包工具是无法拦截到我们的数据了，但作为我们平时使用能非常直接看到接口返回数据的工具不能用了，对我们也造成了不便。现在我们想用Charles，如何防止中间人攻击同时又只能被Charles抓到呢？

我们一起再来看一下Charles的原理。

为何Https依然会被截取？
目前的一些抓包工具，fiddler、charles使用了叫做man-in-the-middle（中间人）机制：

具体简述起来就是对客户端设置Charles的代理，作为客户端的代理，由Charles连接到实际服务器。

第一步， charles向服务器发送请求进行握手， 获取到服务器的CA证书， 用根证书公钥进行解密， 验证服务器数据签名，获取到服务器CA证书公钥。
第二步， charles伪造自己的CA证书， 冒充服务器证书传递给客户端浏览器，客户端做跟charles一样的事。
第三步， 客户端浏览器生成https通信用的对称密钥，用charles伪造的证书公钥加密后传递给服务器， 被charles截获。
第四步， charles将截获的密文用自己伪造证书的私钥解开，获得https通信用的对称密钥。
第五步， charles将对称密钥用服务器证书公钥加密传递给服务器， 服务器用私钥解开后建立信任，握手完成， 用对称密钥加密消息， 开始通信。
第六步， charles接收到服务器发送的密文， 用对称密钥解开，获得服务器发送的明文。再次加密， 发送给客户端浏览器。
第七步， 客户端向服务器发送消息， 用对称密钥加密， 被charles截获后，解密获得明文。

由于charles一直拥有通信用对称密钥， 所以在整个https通信过程中信息对其透明。也就是说charles向服务器冒充是客户端，向客户端又谎称自己是服务器。
也就是说开启Charles抓包以后，我们的客户端实际上是和Charles建立了连接，服务器的CA证书已经被Charles拦截，取而代之是由Charles伪造的CA证书，冒充了服务器的证书传递给了客户端。

所以我们让Charles的CA证书也成为我们证书信任链中的一个

从 http://charlesproxy.com/getssl 下载Charles的CA证书，后缀名为.pem的文件，用记事本打开，将提取出来的证书拷贝到自己服务器证书的下面

image.png