本文介绍 HTTPS 如何做到安全，所有相关名词解释均来自 维基百科，后续引用就不在每次赘述了。
HTTP 的 URL 是由 “http://” 起始与默认使用 端口 80，而 HTTPS 的 URL 则是由 “https://” 起始与默认使用 端口 443。
HTTP 不是安全的，而且攻击者可以通过
嗅探 和
中间人攻击
等手段，获取网站帐户和敏感信息等。
HTTPS 的设计可以防止前述攻击，在正确配置时是安全的。
那么 HTTPS 为什么安全呢，密码学保证？证书又是什么？
引自 Wiki：
超文本传输安全协议（英语：HyperText Transfer Protocol Secure，缩写：HTTPS； 常称为HTTP over TLS、HTTP over SSL或HTTP Secure）是一种通过计算机网络进行安全通信的传输协议。 HTTPS经由HTTP进行通信，但利用SSL/TLS来加密数据包。 HTTPS开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。 这个协议由网景公司（Netscape）在1994年首次提出，随后扩展到互联网上。
HTTP HTTPS
+------------+ +-----------+
| | | HTTP |
| HTTP | | |
| | +-----------+
+------------+ |SSL or TLS |
| | | |
| TCP | +-----------+
| | | TCP |
+------------+ | |
| | +-----------+
| IP | | IP |
| | | |
+------------+ +-----------+
展开
如果任何人使用公钥加密明文，得到的密文可以透过不安全的途径（如网络）发送，只有对应的私钥持有者才可以解密得到明文； 其他人即使从网络上窃取到密文及加密公钥，也无法（在数以年计的合理时间内）解密得出明文。 典型例子是在网络银行或购物网站上，因为客户需要输入敏感消息，浏览器连接时使用网站服务器提供的公钥加密并上传数据， 可保证只有信任的网站服务器才能解密得知消息，不必担心敏感个人信息因为在网络上传送而被窃取。
展开
对称密钥算法（英语：Symmetric-key algorithm）又称为对称加密、私钥加密、共享密钥加密，是密码学中的一类加密算法。 这类算法在加密和解密时使用相同的密钥，或是使用两个可以简单地相互推算的密钥。 事实上，这组密钥成为在两个或多个成员间的共同秘密，以便维持专属的通信联系。 与公开密钥加密相比，要求双方获取相同的密钥是对称密钥加密的主要缺点之一。
常见的对称加密算法有 DES、3DES、AES、Blowfish、IDEA、RC5、RC6。
对称加密的速度比公钥加密快很多，在很多场合都需要对称加密。
展开
公开密钥密码学（英语：Public-key cryptography，也称非对称式密码学）是密码学的一种算法， 它需要两个密钥，一个是公开密钥，另一个是私有密钥；一个用作加密，另一个则用作解密。 使用其中一个密钥把明文加密后所得的密文，只能用相对应的另一个密钥才能解密得到原本的明文； 甚至连最初用来加密的密钥也不能用作解密。由于加密和解密需要两个不同的密钥，故被称为非对称加密； 不同于加密和解密都使用同一个密钥的对称加密。 虽然两个密钥在数学上相关，但如果知道了其中一个，并不能凭此计算出另外一个； 因此其中一个可以公开，称为公钥，任意向外发布； 不公开的密钥为私钥，必须由用户自行严格秘密保管，绝不透过任何途径向任何人提供，也不会透露给被信任的要通信的另一方。
基于公开密钥加密的特性，它还提供数字签名的功能，使电子文件可以得到如同在纸本文件上亲笔签署的效果。
公开密钥基础建设透过信任数字证书认证机构的根证书、及其使用公开密钥加密作数字签名核发的公开密钥认证，形成信任链架构， 已在TLS实现并在万维网的HTTP以HTTPS、在电子邮件的SMTP以STARTTLS引入。
另一方面，信任网络则采用去中心化的概念，取代了依赖数字证书认证机构的公钥基础设施， 因为每一张电子证书在信任链中最终只由一个根证书授权信任，信任网络的公钥则可以累积多个用户的信任。 PGP就是其中一个例子。
展开
在现实世界上可作比拟的例子是，一个传统保管箱，开门和关门都是使用同一条钥匙，这是对称加密；
而一个公开的邮箱，投递口是任何人都可以寄信进去的，这可视为公钥；而只有信箱主人拥有钥匙可以打开信箱，这就视为私钥。
数字证书认证机构 （英语：Certificate Authority，缩写为CA），也称为电子商务认证中心、电子商务认证授权机构， 是负责发放和管理数字证书的权威机构，并作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。
展开
证书实际是由证书签证机关（CA）签发的对用户的公钥的认证。
证书的内容包括：电子签证机关的信息、公钥用户信息、公钥、权威机构的签字和有效期等等。 当前，证书的格式和验证方法普遍遵循 X.509 国际标准。
-
加密：ca认证将文字转换成不能直接阅读的形式（即密文）的过程称为加密。
-
解密：将密文转换成能够直接阅读的文字（即明文）的过程称为解密。
如打算在电子文档上实现签名的目的，可使用数字签名。RSA公钥体制可实现对数字信息的数字签名，方法如下：
信息发送者用其私钥对从所传报文中提取出的特征数据（或称数字指纹）进行RSA算法操作，以保证发信人无法抵赖曾发过该信息（即不可抵赖性），同时也确保信息报文在传递过程中未被篡改（即完整性）。当信息接收者收到报文后，就可以用发送者的公钥对数字签名进行验证。
在数字签名中有重要作用的数字指纹是通过一类特殊的散列函数（HASH函数）生成的。对这些HASH函数的特殊要求是：
- 接受的输入报文数据没有长度限制；
- 对任何输入报文数据生成固定长度的摘要（数字指纹）输出；
- 从报文能方便地算出摘要；
- 难以对指定的摘要生成一个报文，而由该报文可以算出该指定的摘要；
- 两个不同的报文难以生成具有相同的摘要。
用一个证书来证明另一个证书是可信的，例如 C 机构公章和 A 机构公章在同一张介绍信上，注明公章 C 信任公章 A，A 也是可信的。
简单说，信任关系是可以传递的，只要你信任头一个证书，后续的证书都是可以信任的。
C 信任 A，A 信任 A1，A1 信任 A2，A、A1、A2 都是可信任的。
展开
在密码学和计算机安全领域，根证书 （root certificate）是属于根证书颁发机构（CA）的公钥证书，是在公开密钥基础建设中，信任链的起点。
在证书的信任链中，A1 可以由 A 证明可信任，A 由 C 证明可信任，C 由谁证明可信任呢？ C 不需要证明自己是可信任的，因为它是权威机构，这就是根证书（处于树结构的顶端）。
由于根证书在信任链中的重要角色，一旦证书机构的私钥外泄，将可能导致整个信任链被摧毁，影响广及众多客户， 所以认证机构会使用各种方法保护根证书，例如硬件安全模块。
防止 浏览器 与 服务端 数据传输时被 中间人攻击，
若暂不理解 HTTPS 为什么需要 证书机制，请先看下文 HTTPS 过程详解。
服务端和浏览器之间要实现安全的密钥交换该如何实现？
如果单纯使用对象加密算法，服务端与浏览器必须要交换密钥，密钥直接用明文传输很容易被窃取，无法保证密钥的安全性。
-
服务端 基于非对称加密算法随机生成一堆密钥对 x,y，目前算很安全，只有服务端知道
-
服务端把 x 留在本地，把 y 用明文传输到 浏览器（y可能被窃取）
-
浏览器拿到 y 后，先随机生成第三个对称加密的密钥 z，然后用 y 加密 z 得到最新的 f （本质上就是用非对称加密 保证 对称加密的安全性），将 f 发送到 服务端（因为 x, y 是成对的， 只用 x 才能解密 y 加密的结果，所以 y 泄露也无法解密 k）
-
服务端 拿到 f 之后，用 x 解密得到 z，至此 浏览器 和 服务端 都有对称加密的密钥 z，可以进行通信加密。
思考一下，方案二 是否 安全 和 完美？
实际上，方案二可以在一定程度上防止 嗅探，但无法防范 网络数据修改（中间人攻击）。 在 服务端 和 浏览器 交换密钥的过程中，中间人接收网站发送的 密钥 y 保存下来，改用自己生成的密钥； 伪造成 服务端 与 浏览器 交互，同时使用密钥 y 伪造成 浏览器 与 服务端交互。
方案二 不安全的根源是缺乏可靠的身份认证，浏览器 无法鉴别自己受到的密钥是不是来自 真正的 服务端。
因此需要引入 CA证书机制（身份认证），基于 CA证书 进行密钥交换（具体 CA机制可查看介绍 CA相关文章）。
此时得到方案三。
-
服务端 首先花钱从 权威CA 机构购买一个数字证书，证书通常包含一个私钥和一个公钥证书文件
-
浏览器 访问 服务端 时将公钥证书文件发送给 浏览器
-
浏览器 验证收到的证书（权威机构担保真假，主流 浏览器 和 操作系统 都会内置权威 CA机构 的根证书）
-
如果证书科学，就随机生成一个对称加密密钥 k，使用公钥加密 k，得到密钥 c
-
将密钥 c 发送给 服务端，服务端 根据私钥解密出 密钥 k，至此密钥交换完成。
这就是 HTTPS 加密传输的过程。
-
了解 HTTPS 机制，你需要了解
-
对称加密与非对称加密
-
CA 证书机制
-
-
本质上就是，在第一次交换密钥时，用 非对称加密 保证 对称加密 的安全性。
-
在交换密钥时，使用 非对称加密 算法；之后交互过程，使用 对称加密 算法。