openssl客户端编程:一个不起眼的函数导致的SSL会话失败问题

虚幻大学 xuhss 126℃ 0评论

? 优质资源分享 ?

学习路线指引(点击解锁) 知识定位 人群定位
? Python实战微信订餐小程序 ? 进阶级 本课程是python flask+微信小程序的完美结合,从项目搭建到腾讯云部署上线,打造一个全栈订餐系统。
?Python量化交易实战? 入门级 手把手带你打造一个易扩展、更安全、效率更高的量化交易系统

我们目前大部分使用的openssl库还是基于TLS1.2协议的1.0.2版本系列,如果要支持更高的TLS1.3协议,就必须使用openssl的1.1.1版本或3.0版本。升级openssl库有可能会导致SSL会话失败,我在升级 wincurl 时,意外的收获了一个函数。这个函数非常的不起眼,但具有的现实意义却很大。
大部分情况下如果你不调用该函数,并不影响SSL会话和通信,但有时会被某些服务器拒绝。一旦被拒绝,查找具体的原因将变得非常痛苦。这个函数的意义好比HTTP协议中HOST字段,它和NGINX反向代理的Server name有异曲同工之妙。了解这个函数的意义,可能会让你今后在配置nginx反向代理时少走一些弯路。
这个函数是 SSL_set_tlsext_host_name,在介绍这个函数之前,我们先快速看看TLS协议和openssl的发展。

虽然TLS1.3的标准自2018年就已发布,但目前国内几乎所有网站并没有增加对TLS 1.3的支持,大部分主流网站使用的还是基于TLS1.2的版本。目前国内使用TLS1.3的好像只有知乎,其它诸如:新浪、网易、搜狐、腾讯、华为、京东、百度....都还是采用TLS1.2的标准。

网站是否支持TLS1.3其实并不重要,重要的是浏览器是否支持TLS1.3协议。好在目前市场上所有主流浏览器都已升级到了TLS1.3。因此对于用户而言,不管是支持TLS1.3的网站还是支持TLS1.2的网站,访问起来都不是问题,或者说对终端用户而言这种访问是无感的。

为何TLS3.0已经出现5年了,各大网络平台还是首选TLS1.2呢?估计还是出于对兼容和稳定的考虑。如果贸然升级到1.3导致大量客户端无法访问从而丢失用户,是任何平台所无法承受的。此外,支持TLS1.3的openssl版本也在不断完善中,在其未达到稳定前,最好还是使用稳定的1.2版本。这大概就是目前几乎所有平台类网站还在使用TLS1.2的原因。

此外,即使有的网站采用TLS1.3协议,也会继续提供对1.2的访问支持(向下兼容并保留所有TLS1.2的加密套件),除非该网站的运维人员强行使用TLS1.3的加密套件。但如果这样做的话就会导致大量仍然使用1.2标准的客户端程序无法继续访问该网站,这也意味着该运维人员离下岗再就业不远了。

这也是为什么我们即使不升级老版本的openssl库,也依然可以访问TLS1.3网站的原因。

上面说的TLS1.2,1.3指的是TLS的协议,实现上述协议的是openssl库。 其中支持TLS1.3的openssl库目前有两个版本系列:一个是1.1.1系列,一个是3.0系列。其中1.1.1更像是一个过渡版本,openssl团队承诺会支撑该版本到2023年9月11日,也就是明年911事件22周年之际(确实是一个值得纪念的日子)将停止更新1.1.1版本。这就意味着大家还没开始普及使用1.1.1,它就已经结束了。

这个其实也不重要,因为3.0才是最终openssl的终极版本,直接跳过了2.0,从而体现了openssl的跨越式发展。 3.0版本是openssl团队主推版本,也是一个长期维护的版本,该版本会维护到2026年9月7日。

虽然主流web浏览器都已支持TLS1.3,但浏览器只是客户端的一种,其它大部分客户端使用的还是openssl 1.0.2系列版本,甚至是1.0.1系列版本,也就是我们经常看到的libeay32.dllssleay32.dll 库,这些版本是不支持TLS1.3协议的。比如工具类的postman、curl,以及应用类QQ、Foxmail、微信以及各种下载客户端程序,使用的可能还是老的openssl库。openssl库在1.1.1及以上版本已经将库的导出名称改为libcryptolibssl,不过这只是前缀名,如果是1.1.1系列,则后缀为-1.1.dll,如果是3.0系列,则后缀为-3.dll,我们通过openssl的库名就能判断出该应用程序是否支持TLS1.3。

升级到TLS1.3可以从openssl的官网https://openssl.org)下载1.1.1或3.0版本的源码进行编译。编译完毕后,我们只要替换openssl库,并重新配置并编译你的客户端程序即可。
使用openssl库编写客户端程序的一般流程如下:先创建套接字,并连接到服务器,然后创建ssl,并绑定套接字,通过调动SSL_connect函数进行握手操作,成功后使用SSL_readSSL_write进行业务通信。
代码通常如下:

    // 创建套接字,并连接到服务器
    SOCKET s = socket(AF_INET, SOCK_STREAM, 0);
    struct hostent* hst = ::gethostbyname(pszServer);
    if(NULL == hst)
        return FALSE;
    unsigned long addr;
    struct sockaddr\_in sockAddr;
    memcpy(&addr, hst->h_addr, hst->h_length);
    sockAddr.sin_family = AF_INET;
    sockAddr.sin_port = htons(nPort);
    sockAddr.sin_addr.S_un.S_addr = addr; 
    // 连接到服务器
    if(SOCKET_ERROR != ::connect(s, (struct sockaddr *)&sockAddr, sizeof(struct sockaddr_in)))
        return FALSE;

    // Openssl库初始化
    OpenSSL_add_ssl_algorithms();
    SSL_load_error_strings(); 
    SSLeay_add_ssl_algorithms();
    ERR_load_BIO_strings();
    ctx = SSL_CTX_new(SSLv23_client_method());

    // 创建ssl上下文,并绑定套接字
    SSL* ssl = SSL_new (m_ctx);
    SSL_set_fd(m_ssl, s);
    // 开始ssl握手
    int iRet = SSL_connect(m_ssl);
    if(1 != iRet)
        return FALSE;

    // 下面使用SSL\_read或SSL\_write进行通信

上述代码中SSL_connect函数是最重要的,它内部实现了SSL的握手过程,openssl在内部采用状态机的方式实现了整个握手,代码还是相当的晦涩。几乎所有的SSL通信失败都是在握手阶段产生的,比如加密套件不匹配,服务器证书没有可靠的签名等。

openssl中有个s_client命令集合,该命令用于实现客户端的通信,它的实现在s_client.c文件中,在这个庞大代码中有一个不起眼的函数调用,这个函数是SSL_set_tlsext_host_name。该函数的作用是在客户端在发送ClientHello消息时,将所访问的主机(服务器)名称写入到server name的扩展字段中。

   if (!noservername && (servername != NULL || dane_tlsa_domain == NULL)) {
        if (servername == NULL) {
            if(host == NULL || is_dNS_name(host)) 
                servername = (host == NULL) ? "localhost" : host;
        }
        if (servername != NULL && !SSL_set_tlsext_host_name(con, servername)) {
            BIO_printf(bio_err, "Unable to set TLS servername extension.\n");
            ERR_print_errors(bio_err);
            goto end;
        }
    }

调用该函数后会在ClientHello的扩展字段中增加一个Server Name字段。如下图所示:

e8ca735a698d494926ffc6e078d264e2 - openssl客户端编程:一个不起眼的函数导致的SSL会话失败问题

我们在客户端编程时,通常不会调用该函数,因为会觉得该字段可有可无,既然已经连接到Host服务器上,为何还要将Host的名称告诉给服务器呢?如果我们不调用SSL_set_tlsext_host_name 函数,难道SSL会话会失败么?实际上即使不调用该函数,也是可以握手成功的,并不影响TLS的正常通信。

但如果服务器强制校验该字段时,就会导致握手失败,这就好比HTTP协议中请求的HOST字段一样。那么为什么有的服务器要强制校验该字段呢?如果一台服务器绑定不同的DSN名称(也就是一个IP地址绑定多个域名),这个扩展字段的意义就出来了,服务器会根据不同的域名提供不同的证书。

举个例子,假设BAT都破产了,他们穷到共用一台服务器的地步,也就是一个IP地址绑定了百度、阿里和腾讯三个公司域名,并且这三家公司都给域名申请了数字证书,此时扩展字段的HOST的作用就体现出来了,openssl服务器端会跟据不同的host名称决定返回哪家公司的数字证书。这也是Ngnix反向代理的原理,根据不同域名进行不同访问地址映射。

写到这里,本文也即将结束,也许我们调用了SSL_set_tlsext_host_name函数也无法知道它的最终目的是什么,这也是我写这篇文章的原因之一吧。

转载请注明:xuhss » openssl客户端编程:一个不起眼的函数导致的SSL会话失败问题

喜欢 (0)

您必须 登录 才能发表评论!