HTTPS与httpdns一起用的业务场景解决方案

HTTPS与httpdns一起用的业务场景解决方案

1 背景说明

发送HTTPS请求首先要进行SSL/TLS握手，握手过程大致如下：

客户端发起握手请求，携带随机数、支持算法列表等参数。
服务端收到请求，选择合适的算法，下发公钥证书和随机数。
客户端对服务端证书进行校验，并发送随机数信息，该信息使用公钥加密。
服务端通过私钥获取随机数信息。
双方根据以上交互的信息生成session ticket，用作该连接后续数据传输的加密密钥。
上述过程中，和HTTPDNS有关的是第3步，客户端需要验证服务端下发的证书，验证过程有以下两个要点：

客户端用本地保存的根证书解开证书链，确认服务端下发的证书是由可信任的机构颁发的。
客户端需要检查证书的domain域和扩展域，看是否包含本次请求的host。
如果上述两点都校验通过，就证明当前的服务端是可信任的，否则就是不可信任，应当中断当前连接。

当客户端使用HTTPDNS解析域名时，请求URL中的host会被替换成HTTPDNS解析出来的IP，所以在证书验证的第2步，会出现domain不匹配的情况，导致SSL/TLS握手不成功。

2 解决方案

针对“domain不匹配”问题，可以采用如下方案解决：hook证书校验过程中第2步，将IP直接替换成原来的域名，再执行证书验证。

下面分别列出Android和iOS平台的示例代码。

2.1 Android示例

此示例针对HttpURLConnection接口。

try {
    String url = "https://140.205.160.59/?sprefer=sypc00";
    HttpsURLConnection connection = (HttpsURLConnection) new URL(url).openConnection();
    connection.setRequestProperty("Host", "m.taobao.com");
    connection.setHostnameVerifier(new HostnameVerifier() {
/*
 * 关于这个接口的说明，官方有文档描述：
 * This is an extended verification option that implementers can provide.
 * It is to be used during a handshake if the URL's hostname does not match the
 * peer's identification hostname.
 *
 * 使用HTTPDNS后URL里设置的hostname不是远程的主机名(如:m.taobao.com)，与证书颁发的域不匹配，
 * Android HttpsURLConnection提供了回调接口让用户来处理这种定制化场景。
 * 在确认HTTPDNS返回的源站IP与Session携带的IP信息一致后，您可以在回调方法中将待验证域名替换为原来的真实域名进行验证。
 *
 */
    @Override
    public boolean verify(String hostname, SSLSession session) {
        return HttpsURLConnection.getDefaultHostnameVerifier().verify("m.taobao.com", session);
        return false;
    }
    });
    connection.connect();
} catch (Exception e) {
    e.printStackTrace();
} finally {
}

2.2 iOS示例

此示例针对NSURLSession/NSURLConnection接口。

- (BOOL)evaluateServerTrust:(SecTrustRef)serverTrust
                  forDomain:(NSString *)domain
{
    /*
     * 创建证书校验策略
     */
    NSMutableArray *policies = [NSMutableArray array];
    if (domain) {
        [policies addObject:(__bridge_transfer id)SecPolicyCreateSSL(true, (__bridge CFStringRef)domain)];
    } else {
        [policies addObject:(__bridge_transfer id)SecPolicyCreateBasicX509()];
    }
    /*
     * 绑定校验策略到服务端的证书上
     */
    SecTrustSetPolicies(serverTrust, (__bridge CFArrayRef)policies);
    /*
     * 评估当前serverTrust是否可信任，
     * 官方建议在result = kSecTrustResultUnspecified 或 kSecTrustResultProceed
     * 的情况下serverTrust可以被验证通过，https://developer.apple.com/library/ios/technotes/tn2232/_index.html
     * 关于SecTrustResultType的详细信息请参考SecTrust.h
     */
    SecTrustResultType result;
    SecTrustEvaluate(serverTrust, &result);
    return (result == kSecTrustResultUnspecified || result == kSecTrustResultProceed);
}
/*
 * NSURLConnection
 */
- (void)connection:(NSURLConnection *)connection
willSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge
{
    if (!challenge) {
        return;
    }
    /*
     * URL里面的host在使用HTTPDNS的情况下被设置成了IP，此处从HTTP Header中获取真实域名
     */
    NSString* host = [[self.request allHTTPHeaderFields] objectForKey:@"host"];
    if (!host) {
        host = self.request.URL.host;
    }
    /*
     * 判断challenge的身份验证方法是否是NSURLAuthenticationMethodServerTrust（HTTPS模式下会进行该身份验证流程），
     * 在没有配置身份验证方法的情况下进行默认的网络请求流程。
     */
    if ([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust])
    {
        if ([self evaluateServerTrust:challenge.protectionSpace.serverTrust forDomain:host]) {
            /*
             * 验证完以后，需要构造一个NSURLCredential发送给发起方
             */
            NSURLCredential *credential = [NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust];
            [[challenge sender] useCredential:credential forAuthenticationChallenge:challenge];
        } else {
            /*
             * 验证失败，进入默认处理流程
             */
            [[challenge sender] continueWithoutCredentialForAuthenticationChallenge:challenge];
        }
    } else {
        /*
         * 对于其他验证方法直接进行处理流程
         */
        [[challenge sender] continueWithoutCredentialForAuthenticationChallenge:challenge];
    }
}


/*
 * NSURLSession
 */
- (void)URLSession:(NSURLSession *)session task:(NSURLSessionTask *)task
didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge
 completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential * __nullable credential))completionHandler
{
    if (!challenge) {
        return;
    }
    NSURLSessionAuthChallengeDisposition disposition = NSURLSessionAuthChallengePerformDefaultHandling;
    NSURLCredential *credential = nil;
    /*
     * 获取原始域名信息。
     */
    NSString* host = [[self.request allHTTPHeaderFields] objectForKey:@"host"];
    if (!host) {
        host = self.request.URL.host;
    }
    if ([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) {
        if ([self evaluateServerTrust:challenge.protectionSpace.serverTrust forDomain:host]) {
            disposition = NSURLSessionAuthChallengeUseCredential;
            credential = [NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust];
        } else {
            disposition = NSURLSessionAuthChallengePerformDefaultHandling;
        }
    } else {
        disposition = NSURLSessionAuthChallengePerformDefaultHandling;
    }
    // 对于其他的challenges直接使用默认的验证方案
    completionHandler(disposition,credential);
}

另一篇相关的文章

最近谈论 HTTPS 的文章很多，其原因之一是运营商作恶底线越来越低，动不动就插播广告， 前两天小米还联合几家公司发文 关于抵制流量劫持等违法行为的联合声明 痛斥某些运营商。 另一方面也是苹果 ATS 政策的大力推动，逼迫大家在 APP 中全部使用 HTTPS 通信。 上 HTTPS 的好处很多：保护用户的数据不外泄，避免中间人篡改数据， 对企业信息进行鉴权。

关于 HTTPS 如何购买证书，如何部署，网上的教程已经太多了，实践起来没有太大的难处。 我们在部署 HTTPS 的时候，遇到了一些新问题，首当其冲的就是 HTTPS 部分网络不可访问的问题：

尽管使用了 HTTPS 技术，部分邪恶的运营商，仍然使用 DNS 污染技术，让域名指向的他们自己服务器 而这些服务器并没有部署 SSL 服务（就算部署了，也会触发 SSL 证书 Common name 不一致报警）， 导致 443 端口直接被拒绝。

这个问题不解决，强行上 HTTPS 的话，会导致一部分用户出现无法访问网站 一旦用户不爽了，轻则对产品不信任，重则直接导致用户流失。

运营商为了赚广告钱、省网间结算是不择手段的。 他们普遍使用的劫持手段是通过 ISP提供的 DNS 伪造域名。 那有没有什么方法可以解决 DNS 劫持呢？ 业界有一套解决这类场景的方案，即 HTTPDNS。

HTTPDNS 的原理很简单，将 DNS 这种容易被劫持的协议，转为使用 HTTP 协议请求 Domain <-> IP 映射。 获得正确 IP 之后，Client 自己组装 HTTP 协议，从而避免 ISP 篡改数据。

有两篇文章很清晰的讲解了 HTTPDNS 的细节：

• 【鹅厂网事】全局精确流量调度新思路-HttpDNS服务详解
  • 腾讯这篇文章时间点是 2014 年，说明这个方案上线更早，也较为成熟
• DNS-over-HTTPS  |  Public DNS  |  Google Developers
  • 该方案更为先进，使用 HTTP 替换为 HTTPS，减少一个隐患点

点击 https://dns.google.com/resolve?name=www.duitang.com / http://119.29.29.29/d?dn=www.duitang.com 感受一下 DNS-over-HTTPS / HTTPDNS。

单 IP 多域名支持

这个方案看似完美，但是在实际生产中，会遇到一个问题。

Android / iOS 在操作系统级别对 HTTPS 通信是提供了封装。 APP 无法在发起连接时候，也没有权限直接操作 socket。 所以尽管 APP 拿到了域名对应的 IP，却没有办法让这个 IP 在 HTTPS 里生效。

解决的思路很暴力：彻底放弃域名系统，完全使用基于 IP 系统的通讯。

原本请求 https://www.duitang.com 的 request， 调整为请求 https://221.228.82.181。

OK，做到这一步，我们就可以跟运营商劫持说拜拜了。

不，还没结束。

完全搞定运营商之后，这 IP 方案给我们自己带来一个困扰： Nginx 服务器无法通过 Host 来识别不同域名下面的请求了！！！ 在由于使用一个独立 IP，会导致所有域名请求混在一起，无法分别。 大公司可以 dedicated IP，小公司就玩不起了。

为了解决同一个 IP 下面多个域名的问题，我们引入了一个URL参数： __domain。 当请求 IP 域名时候，必须带着这个参数，服务器会将请求域名解析出来，再分发到对应的域名。

实现这个逻辑的 Nginx 核心代码：

set $query_domain $arg___domain;
if ($query_domain !~ '(www|a|b)\.example\.com') {
    rewrite ^ http://www.example.com/404/ redirect;
}
set $my_host $query_domain;
location / {
    proxy_set_header Host $my_host;
    proxy_set_header X-REAL-IP $remote_addr;
    proxy_pass http://127.0.0.1;
}

最后一个注意事项是，记得调整 Nginx 配置的 remote_addr，否则都变成了 127.0.0.1， 也许会导致其他一些策略失效。

完美收工，效果如下：https://221.228.82.181/?__domain=www.duitang.com。

恭喜你，已经掌握核心科技了，再也不怕运营商瞎折腾了，从此走上了业务蓬勃发展的金光大道……☀️

--- end ---