同一IP地址和同一端口上的多个SSL域？

#1 楼

有关Apache和SNI的最新信息（包括其他特定于HTTP的RFC），请参阅Apache Wiki。



FYsI：“ TLS升级的魔力为您带来了一个IP上的多个（不同）SSL证书。
它可与更新的Apache服务器（2.2.x）和相当新的浏览器一起使用（不知道版本的顶部）。我的头）。

RFC 2817（在HTTP / 1.1中升级到TLS）具有详细信息，但基本上它适用于很多人（如果不是大多数人）。您可以重现旧的时髦但是，openssl的s_client命令（或任何“足够旧”的浏览器）的行为。

编辑以添加：显然curl可以比opensl更好地向您展示正在发生的事情：


SSLv3

mikeg@flexo% curl -v -v -v -3 https://www.yummyskin.com
* About to connect() to www.yummyskin.com port 443 (#0)
*   Trying 69.164.214.79... connected
* Connected to www.yummyskin.com (69.164.214.79) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: serialNumber=wq8O9mhOSp9fY9JcmaJUrFNWWrANURzJ; C=CA; 
              O=staging.bossystem.org; OU=GT07932874;
              OU=See www.rapidssl.com/resources/cps (c)10;
              OU=Domain Control Validated - RapidSSL(R);
              CN=staging.bossystem.org
*    start date: 2010-02-03 18:53:53 GMT
*    expire date: 2011-02-06 13:21:08 GMT
* SSL: certificate subject name 'staging.bossystem.org'
       does not match target host name 'www.yummyskin.com'
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
curl: (51) SSL: certificate subject name 'staging.bossystem.org'
does not match target host name 'www.yummyskin.com'

TLSv1

mikeg@flexo% curl -v -v -v -1 https://www.yummyskin.com
* About to connect() to www.yummyskin.com port 443 (#0)
*   Trying 69.164.214.79... connected
* Connected to www.yummyskin.com (69.164.214.79) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: C=CA; O=www.yummyskin.com; OU=GT13670640;
              OU=See www.rapidssl.com/resources/cps (c)09;
              OU=Domain Control Validated - RapidSSL(R);
              CN=www.yummyskin.com
*    start date: 2009-04-24 15:48:15 GMT
*    expire date: 2010-04-25 15:48:15 GMT
*    common name: www.yummyskin.com (matched)
*    issuer: C=US; O=Equifax Secure Inc.; CN=Equifax Secure Global eBusiness CA-1
*    SSL certificate verify ok.

#2 楼

是的，但是有一些警告。

这是通过服务器名称指示（传输层安全性的扩展）来完成的。

什么是服务器名称指示？

服务器名称指示（RFC 6066；废弃的RFC 4366，RFC 3546）是传输层安全性的扩展，它允许客户端告知服务器它要访问的主机的名称。

SNI根据规范与TLS 1.0及更高版本兼容，但实现方式可能有所不同（请参见下文）。它不能与SSL一起使用，因此连接必须协商TLS（请参阅RFC 4346附录E）才能使用SNI。这通常是在受支持的软件自动发生的。

为什么需要SNI？

在正常的HTTP连接中，浏览器会向服务器通知其正在尝试使用的服务器的主机名使用Host:标头到达。这允许单个IP地址上的Web服务器为多个主机名提供内容，这通常称为基于名称的虚拟主机。

替代方法是为每个Web主机名分配唯一的IP地址，以被送达。这通常是在Web成立之初就完成的，当时人们普遍知道IP地址将用光并开始采取保护措施，但对于SSL虚拟主机（不使用SNI），仍然以这种方式进行。

因为这种传输主机名的方法要求已经建立连接，所以它不适用于SSL / TLS连接。在建立安全连接时，Web服务器必须已经知道它将为客户端提供哪个主机名，因为Web服务器本身正在建立安全连接。

SNI解决了这个问题通过让客户端在TLS协商中传输主机名来解决问题，以便服务器已经知道应使用哪个虚拟主机来为连接提供服务。然后，服务器可以将证书和配置用于正确的虚拟主机。

为什么不使用不同的IP地址？

HTTP Host:标头被定义为允许由于IPv4地址不足而从一个IP地址为一个以上的Web主机提供服务，这早已被认为是一个问题。如1990年代中期。在共享的Web托管环境中，可以使用单个IP地址为数百个唯一的，不相关的网站提供服务，从而节省地址空间。

然后，共享的托管环境发现IP地址空间的最大使用者是对安全网站具有唯一IP地址的需求，这使SNI成为通向IPv6的权宜之计。如今，有时很难在没有明显依据的情况下获得多达5个IP地址（/ 29），这通常会导致部署延迟。

随着IPv6的出现，不再需要这种地址保护技术，由于单个主机可以分配给它的IPv6地址比今天整个Internet所包含的更多，所以在将来很可能仍会使用该技术为旧版IPv4连接提供服务。

注意事项

某些操作系统/浏览器组合不支持SNI（请参阅下文），因此使用SNI并不适合所有情况。针对此类系统/浏览器组合的站点必须放弃SNI，并继续为每个虚拟主机使用唯一的IP地址。

特别值得注意的是，Windows XP上的Internet Explorer版本均不支持SNI。由于此组合仍占互联网流量的很大一部分（但稳步下降；根据NetMarketShare，2012年12月，占互联网流量的16％），因此SNI不适合针对这些用户群的网站。

支持

许多但不是全部，常用软件包都支持SNI。

（此列表中的遗漏并不一定意味着缺乏支持；这意味着我可以输入多少字，或者我无法快速在搜索中找到信息。如果没有列出您的软件包，请进行搜索（名称加上sni应该显示支持是否存在以及如何设置。）

库支持

大多数软件包都依赖外部库来提供SSL / TLS支持。


GNU TLS
JSSE（Oracle Java）7或更高版本，仅作为客户端

libcurl 7.18.1或更高版本
NSS 3.1.1或更高版本
OpenSSL 0.9.8j或更高版本


OpenSSL 0.9.8f或更高版本，带有配置标志


Qt 4.8或更高版本

服务器支持

最新版本的流行服务器软件均支持SNI。设置说明可用于以下大多数：




Apache 2.2.12或更高版本

Apache Traffic Server 3.2.0或更高版本
切诺基

HAProxy 1.5或更高版本

IIS 8.0或更高版本

LiteSpeed 4.1或更高版本
/>
nginx 0.5.32或更高版本

客户端支持

当前大多数Web浏览器和命令行用户代理均支持SNI。

桌面


Chrome 5或更高版本


Windows XP上的Chrome 6或更高版本


Firefox 2或更高版本
在Windows Vista / Server 2008或更高版本上运行的Internet Explorer 7或更高版本


不管IE版本如何，Windows XP上的Internet Explorer不支持SNI


Konqueror 4.7或更高版本
Opera 8或更高版本（可能要求启用TLS 1.1才能运行）
Windows Vista / Server 2008或更高版本或Mac OS X 10.5上的Safari 3.0。 6或更高版本

移动设备


3.0 Ho上的Android浏览器neycomb或更高版本
iOS 4或更高版本上的iOS Safari
Windows Phone 7或更高版本

命令行


cURL 7.18.1或更高
wget 1.14或更高版本（发行版可能已向后移植了SNI支持的修补程序）

不支持


BlackBerry Browser
Internet Explorer（任何版本） Windows XP

（注意：此答案的某些信息是从Wikipedia获得的。）

#3 楼

问题：

当Web客户端和Web服务器通过HTTPS相互通信时，首先需要进行的是安全握手。

这是一个这种握手的简化示例：



如果这是HTTP而不是HTTPS，则客户端发送的第一件事就是这样的：

GET /index.html HTTP/1.1
Host: example.com

这使得单个IP地址上的多个虚拟主机成为可能，因为服务器确切地知道客户端要访问的域，即example.com。

HTTPS不同。就像我之前说的，握手先于其他。如果您看上面所示的握手的第三步（证书），则服务器需要在握手时向客户端出示证书，但不知道客户端尝试访问哪个域名。服务器唯一的选择是每次都发送相同的证书，即默认证书。

您仍然可以在Web服务器上设置虚拟主机，但是服务器将始终向每个服务器发送相同的证书。客户。如果您尝试在服务器上同时托管example.com和example.org网站，则当客户端请求HTTPS连接时，服务器将始终为example.com发送证书。因此，当客户端通过已建立的HTTPS连接请求example.org时，就会发生这种情况：



此问题实际上将可以通过HTTPS进行服务的域数限制为一个每个IP地址。

解决方案：

解决此问题的最简单方法是让客户端告诉服务器在握手期间要访问哪个域。这样服务器可以提供正确的证书。

这正是SNI或服务器名称指示的作用。

使用SNI，客户端可以发送所需的服务器名称作为第一条消息的一部分进行访问，请参见上方握手图中的“客户端问候”步骤。

一些较旧的Web浏览器不支持SNI。例如，在Windows XP上，没有单个版本的Internet Explorer支持SNI。在使用SNI虚拟主机的服务器上通过HTTPS访问资源时，将显示一个通用证书，这可能会导致浏览器显示警告或错误。



我在这里简化了事情，只是为了解释问题和解决方案背后的原理。如果您想要更多的技术说明，那么维基百科页面或RFC 6066可能是一个很好的起点。您还可以在Wikipedia上找到支持SNI的服务器和浏览器的最新列表

#4 楼

http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

客户端浏览器也必须支持SNI。以下是某些浏览器可以执行以下操作：

* Mozilla Firefox 2.0 or later
* Opera 8.0 or later (with TLS 1.1 enabled)
* Internet Explorer 7.0 or later (on Vista, not XP)
* Google Chrome
* Safari 3.2.1 on Mac OS X 10.5.6 

#5 楼

服务器名称指示（RFC6066）TLS扩展是基于名称的虚拟主机在HTTPS上运行所必需的。

扩展已广泛实现，我尚未遇到任何有关当前软件的问题，但存在一个问题。如果您依赖SNI，则某些客户端（不支持它的客户端）将被路由到默认站点的可能性。