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

我们目前大部分使用的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.dll和ssleay32.dll 库，这些版本是不支持TLS1.3协议的。比如工具类的postman、curl，以及应用类QQ、Foxmail、微信以及各种下载客户端程序，使用的可能还是老的openssl库。openssl库在1.1.1及以上版本已经将库的导出名称改为libcrypto和libssl，不过这只是前缀名，如果是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_read和SSL_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进行通信
	

     

      
1.
      
2.
      
3.
      
4.
      
5.
      
6.
      
7.
      
8.
      
9.
      
10.
      
11.
      
12.
      
13.
      
14.
      
15.
      
16.
      
17.
      
18.
      
19.
      
20.
      
21.
      
22.
      
23.
      
24.
      
25.
      
26.
      
27.
      
28.
      
29.
      
30.
      
31.
      
32.
     

上述代码中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;
        }
    }


     

      
1.
      
2.
      
3.
      
4.
      
5.
      
6.
      
7.
      
8.
      
9.
      
10.
      
11.
      
12.
     

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

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

但如果服务器强制校验该字段时，就会导致握手失败，这就好比HTTP协议中请求的HOST字段一样。那么为什么有的服务器要强制校验该字段呢？如果一台服务器绑定不同的DSN名称（也就是一个IP地址绑定多个域名），这个扩展字段的意义就出来了，服务器会根据不同的域名提供不同的证书。
 
举个例子，假设BAT都破产了，他们穷到共用一台服务器的地步，也就是一个IP地址绑定了百度、阿里和腾讯三个公司域名，并且这三家公司都给域名申请了数字证书，此时扩展字段的HOST的作用就体现出来了，openssl服务器端会跟据不同的host名称决定返回哪家公司的数字证书。这也是Ngnix反向代理的原理，根据不同域名进行不同访问地址映射。

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