与HTTP相比，HTTPS具有更多的安全支持。关键的一步是在服务器和客户端之间建立SSL安全连接通道。在网上找一个很好的数字来描述这个步骤。
HTTPS的客户端支持方案：
它主要描述了过程和逻辑，以及这样做的目的。我们可以看到，整个过程分为四个阶段：
一客户端建立TCP连接后，发送一个标志请求，双方交换一些与加密相关的信息。这个过程主要是协商加密算法。
二然后，服务器将自己的证书发送给客户端，以完成客户端对服务器标识的身份验证。这里的证书可以理解为一种网络身份证，即一些有资质的CA机构（如VeriSign）验证后颁发的证书。因此，如果希望服务器支持HTTPS，则需要为数字证书付费。同时，windows等操作系统还提供了一套API来完成对证书有效性的检查（类似于去公安部门核实某人的身体份额）。
对于此步骤，浏览器的标准做法是维护Ca机构列表（用户可以干预）。当证书被验证时，可信证书由列表中的机构（或其授权机构，证书链）颁发。然后验证证书的有效性，证书所指示的域名是否与当前访问的域名一致，证书中的公钥是否可以解锁证书的数字签名。对于其他应用程序客户端，由于服务器证书的域名和其他信息已经被清楚地知道，因此可以使身份验证逻辑更加严格。如果客户端发现服务器身份验证失败，它将断开连接。这样可以防止伪造服务器欺骗客户端连接和HTTPS请求，从而解密HTTPS并窃取接口。
一个清晰的概念是SSL认证和加密之间没有必然的联系。也就是说，如果客户端不进行身份验证，它仍然可以继续与服务器进行标准的SSL加密和HTTPS通信。可以理解，SSL将分离身份验证步骤。如果双方继续联系握手，可以继续协商数据加密算法，完成后续通信。此时，对于通信双方来说，数据通道和数据本身是安全的，没有第三方会截获和解密它们。但如果你打电话的人不是你想要的人，即使你是在秘密交谈，对方也能理解，因为在通话开始时，你俩协商了一系列标准的秘密用语中的一个来使用。密语仅用于防止第三方***。
三如果服务器需要，客户端需要发送自己的证书，服务器完成对客户端身份的验证。其目的类似于步骤2，但通常许多服务器不需要验证客户端身份。
四协商终的加密算法。客户端使用服务器证书中的公钥对pre-mastersecret进行加密，并使用pre-mastersecret对先前协商算法计算出的握手消息进行加密，并将其发送到服务器。服务器接收到消息后，将使用相应的私钥解密预主密钥。因为密钥只有服务器知道，所以其他人无法获取主密钥。服务器使用pre-mastersecret解密握手消息，并验证是否满足先前的协商规则。服务器和客户端通过相同的算法生成主密钥，主密钥作为服务器和客户端之间对称加密解密通信的初始密钥。可见，双方首先通过非对称加密生成对称加密密钥，然后利用密钥进行对称加密通信。关于对称加密/非对称加密/公钥/密钥的概念，请自行谷歌搜索。
应当指出，上述四个阶段在逻辑上是有区别的。在实际的SSL协商中，客户机和服务器之间的数据交互可以交叉合并。通过以上建立的SSL，保证了通信双方信道和数据的安全，并且后续的通信过程也足够安全。
事实上，许多浏览器邮箱等已经是支持HTTPS的客户端。如果我们在开发过程中有对HTTPS的客户端支持需求，我们可以按照标准的HTTPS/SSL协议来实现，但这是相当困难的。幸运的是，已经有了开源应用程序：libcurl和OpenSSL。OpenSSL封装了SSL标准，libcurl还提供了对OpenSSL的支持。从目前的实际情况来看，主流浏览器都嵌入了对SSL证书的支持，支持HTTPS访问，可以给访问者更高的安全级别。
