标签归档:数字证书

HTTPS和SNI

问题:有两个站点架在同一台服务器上,并且强制HTTPS访问,地址分别为https://sub.domain.com和https://admin.sub.domain.com,HTTPS证书签名的域名分别为*.domain.com和*.sub.domain.com,使用HttpClient(4.1.1版本)去调用一个接口:

1
2
3
4
5
6
7
public class TestGet {
  public static void main(String args[]) throws Exception {
    HttpGet httpGet = new HttpGet("https://sub.domain.com/api/nodes");
    HttpClient httpClient = new DefaultHttpClient();
    httpClient.execute(httpGet);
  }
}

返回 javax.net.ssl.SSLException异常:

Exception in thread "main" javax.net.ssl.SSLException: hostname in certificate didn't match:  != <*.sub.domain.com> OR <*.sub.domain.com>
    at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:231)
    at org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(BrowserCompatHostnameVerifier.java:54)
    at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:152)
    at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:133)
    at org.apache.http.conn.ssl.SSLSocketFactory.verifyHostname(SSLSocketFactory.java:559)
    at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:534)
    ……

问题分析:从异常信息来看,显然是SSL连接握手阶段出现证书不匹配的问题,客户端请求的是sub.domain.com域名,服务器返回了*.sub.domain.com的证书。但是浏览器访问又正常,这是为何?

解决方法:故事要从IPv4的设计开始说起,设计者认为32位够用了,后续的上层协议设计者也纷纷假设一个IP提供一个服务的前提,比如HTTP/1.0、SSL等,一个大坑就这样被埋下。从90年代中期开始,互联网发展太快,人们开始意识到IP资源越来越稀缺,于是着手设计IPv6,但是从IPv4到IPv6需要一个很长的过渡期,远远大于IPv4地址耗尽的时间。于是一些IP复用的方案出现了,CIDR和NAT技术能在一定程度上缓和IPv4资源稀缺的问题,互联网协议也适时进行了升级,比如HTTP,在HTTP/1.1版本中加入Host头,这个头部在虚拟主机(Virtual Host)中非常重要,它支持不同站点架在一个IP上,客户端通过Host头告知服务器需要访问的站点。但是Host头无法解决HTTPS场景中客户端与虚拟主机(多站点共享同一个IP)之间加密连接的建立,因为HTTPS依赖的SSL/TLS协议并没有同步跟进,SSL握手阶段客户端向服务器端发送的信息中未包含Host,所以服务器端也就没法返回正确的HTTPS证书了。这样的背景下,解决HTTPS虚拟主机的方法主要有:

1. 绑定不同的端口。为不同的虚拟主机绑定不同的HTTPS端口(默认端口443)。缺点显而易见,每次访问都需要显式指定端口号。
2. 绑定不同的IP。前面说过,IPv4资源越来越稀缺,而且这种方法也违背了虚拟主机的初衷。
3. 购买泛域名SSL证书(Wildcard Certificate)。
4. 购买多域名SSL证书(Multi Domain Certificate)。

这些方法都只是绕过限制,要根本解决问题还是得修改SSL/TLS协议,所以SNI(Server Name Indication)就适时被提了出来,它扩展了TLS协议(SSL 3.0不支持,在TLS 1.0以后支持,RFC4366RFC6606),在客户端请求的CLIENTHELLO阶段加入Host信息,告知服务器端要与哪个主机建立加密连接。
SNI

图片来源

实际上,SNI需要通信双方(服务端、客户端)都支持,根据Wiki上的总结,目前一些常见浏览器、服务器软件、类库的支持情况如下:

浏览器:

IE 7+
Mozilla Firefox 2.0+
Opera 8.0+
Google Chrome 5.0.342.1+
Safari 3.0+

注:这里的支持度还跟操作系统相关,比如Windows XP上所有IE均不支持,Chrome在不同操作系统下开始支持的版本也不同。

服务器软件:

Apache 2.2.12+
Nginx(依赖支持sni的openssl库)
Apache Traffic Server 3.2.0+
HAProxy 1.5+

类库:

OpenSSL: 0.9.8f(compiled in with config option '--enable-tlsext'), 0.9.8j+
libcurl / cURL 7.18.1+
Python 3.2
Qt 4.8
Oracle Java 7 JSSE
Apache HttpComponents 4.3.2
wget 1.14
Android 4.2 (Jellybean MR1)
Go (client and server)

Java是在JDK1.7里才支持SNI的,因此要在Java应用里使用,前提就是将OpenJDK或者Oracle JDK升到1.7,如果同时使用HttpClient进行HTTP接口调用,那么还必须将HttpClient版本升到4.3.2及以后,这个JIRA单描述了如何支持SNI(代码设计层面)的前因后果。

回到开头的异常问题,可以通过以下步骤修复:

1. 升级JDK至少到1.7。
2. 升级HttpClient至少到4.3.2。
3. 更新少量代码如下:

1
2
3
4
5
6
7
8
public class TestGet {
  public static void main(String args[]) throws Exception {
    HttpGet httpGet = new HttpGet("https://sub.domain.com/api/nodes");
    //HttpClient httpClient = new DefaultHttpClient();
    CloseableHttpClient httpClient = HttpClients.createDefault();
    httpClient.execute(httpGet);
  }
}

--EOF--

SSH和Puppet的身份认证机制

互联网上最成熟的身份验证方式就是非对称加密和数字证书技术,它是互联网安全的基石,以此为基础的SSH和SSL/TLS也是不可信网络下进行安全通信的标准协议,可以有效避免通信数据被窃听、篡改和伪造。

这里简单总结下SSH远程登录和Puppet是如何进行通信双方的身份识别。

1. SSH远程登录

SSH的一个主要应用就是安全可靠地登录远程机器,所有数据经过加密传输。客户端和远程主机(服务端)在通信之前需要握手,进行身份验证。首先,服务端任性地向客户端发送自己的公钥PubKey,客户端没得选择,只能线下确认PubKey是否准确,然后接受。如果不进行确认就接受公钥,容易发生中间人攻击,严重的话会导致密码泄露。有了服务端公钥PubKey之后,客户端就要向对方表明自己的身份了,SSH提供了两种方式:第一种是密码登陆,客户端用PubKey加密密码后发送给服务端,服务端用私钥解密后进行身份验证;第二种是密钥登陆,客户端公钥事先存储在服务端,当用户选择密钥登陆时,服务端向客户端发送一个随机数,客户端用用户私钥对随机数加密后发回服务端,服务端将数据解密后得到的随机数如果与之前的一样,表示身份验证通过。密钥登陆能避免中间人攻击。

2. Puppet

Puppet是一个C/S架构的配置管理和部署工具。采用SSL证书对客户端和服务端之间的通信进行身份认证和数据加密传输。Puppet自己提供本地CA,用于签发客户端和服务端的证书,通常情况下,服务端进程会兼任本地CA的职责。当服务端初始化时,首先创建一对本地CA的公私钥,用于签发证书,然后为服务端创建一对公私钥和一张数字证书,这张证书包含了服务端的公钥和公钥签名(用CA私钥签),最后将这张证书分发到所有的客户端;当客户端初始化时,它生成一对公私钥,并且把公钥发送到本地CA(服务端),申请为这个公钥签发一张证书。本地CA(服务端)可以根据不同策略对客户端的申请请求进行确认,这样服务端就有了一张客户端的数字证书。此时,客户端持有了自己的私钥和服务端数字证书,服务端持有了自己的私钥和客户端数字证书,之后的通信就是SSL协议的内容了,双方首先通过本地CA的公钥认证对方数字证书和公钥的合法性,确认双方身份,然后通过非对称加密算法进行随机数的加密传送,推导出双方的会话密钥,最后通过这个会话密钥进行传输内容的对称加解密。

References:
[1]. 『Secure Shell』.
[2]. 『SSH原理与运用(一):远程登录』.
[3]. 『数字签名是什么?』.
[4]. 『SSL』.
[5]. 『SSL/TLS协议运行机制的概述』.
[6]. 『What's the difference between SSH and SSL/TLS?』.
[7]. 『Puppet Labs: Certificates and Security』.

--EOF--