美国、香港服务器

 

HTTPS安全超文本传输协议，它是一个安全通信通道，它基于HTTP开发，用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换，简单来说它是HTTP的安全版。

 

https相比与http多了安全支持最关键的步骤就是建立server和client的SSL安全连接通道。

 

客户端对https的支持方案：

 

这里主要描述流程和逻辑，以及这样做的目的。我们可以看到整个过程分为四个阶段：

 

1，client建立TCP连接后，发送一个标志请求，双方交换一些与加密相关的信息。这个过程主要是为了协商加密算法。

 

2，server会紧接着将自己的证书发送给client，来完成client对server身份的认证。这里的证书可以理解为一种网络身份证，即由一些有资质的CA机构（如VeriSign）经过核实后颁发的证明文件，因此如果想让server支持https是需要花钱买数字证书的，同时windows等操作系统也已经提供了一套API来完成对证书合法性的检查（类似于去公安部分查证某人的身份）。

 

对于这一步，浏览器的标准做法是维护一个CA机构的列表（该列表用户可以干预），当验证证书时，如果是列表中的机构（或经其授权的机构，证书链）颁发的就为可信任证书。然后还会验证证书有效期、证书标明的域名和目前访问的域名是否一致、证书中的公钥能否解开证书数字签名等。对于其他应用客户端，由于已经明确知道server证书的域名等信息，因此可以将认证逻辑做的更加严格。如果客户端发现server认证失败，就断开连接。这样，就可以防止有人伪造server来骗取客户端连接和https请求，从而将https解密盗用接口。

 

需要明确的一个概念是，SSL的认证和加密之间没有必然联系，也就是说如果client不做认证，后续依然可以继续标准的SSL加密，和server进行https通信。可以这样理解，SSL将身份认证步骤独立出来，如果双方继续连接和握手过程，那么可以继续协商数据加密算法，完成后续的通信。此时对于通信双方来说，这次的数据通道和数据本身都是安全的，不会别第三者截取和解密。但是如果和你打电话的人不是你要的，虽然你说的是暗语，对方也能听懂，因为电话一开始你们俩就从一系列标准暗语里协商了一个来用，暗语只是用来防止第三者窃听。

 

3，如果server要求，client需要发送自己的证书，server完成对client端身份的认证。目的与第2步类似，但是一般很多server并不要求对client身份进行认证。

 

4，协商最终加密算法。client用服务器证书中的公钥加密一个随机串密码（pre-mastersecret），并将一个由之前协商算法计算而来的握手消息用pre-mastersecret加密，将这些一并发给server；server收到后，用对应的私钥解密pre-mastersecret，由于密钥只有server知道，因此其他人无法得到pre-mastersecret。server使用pre-mastersecret解密握手消息，并验证是否符合之前的协商规则。server和client通过相同的算法生成一个mastersecret，此后server和client之间用mastersecret作为初始密钥进行对称加解密通信。可以看出，双方先通过非对称加密方式生成对称加密所用的密钥，然后用该密钥进行对称加密通信。关于对称加密/非对称加密/公钥/密钥等概念，请自行google。

 

需要说明的是，上面四个阶段是从逻辑上区分的，实际SSL协商时client和server之间的数据交互可能有所穿插和合并。通过以上建立起的SSL，保证了通信双方、通道和数据的安全性，后续的通信过程也足够安全。

 

三、客户端实现https方式

 

实际上很多浏览器、邮箱等已经是支持https的客户端了。如果我们在开发过程中有客户端对https的支持需求，可以按照标准的https/ssl协议来实现，但是难度还是相当大的。幸好已经有开源的应用那就是libcurl 和 openssl。openssl封装了ssl标准，而libcurl也提供了对openssl的支持。从目前的实际情况看，主流浏览器都预埋了对ssl证书的支持，支持https访问，同时能给访客以更高层级的安全保障。