什么是https

也称作HTTP over TLS

什么是SSL/TLS

1994年，NetScape公司设计了SSL协议（Secure Sockets Layer）的1.0版，但是未发布。
1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞。
1996年，SSL 3.0版问世，得到大规模应用。
1999年，互联网标准化组织ISOC接替NetScape公司，发布了SSL的升级版TLS 1.0版。
2006年和2008年，TLS进行了两次升级，分别为TLS 1.1版和TLS 1.2版。最新的变动是2011年TLS 1.2的修订版。
TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。

为什么要有https

在说HTTPS之前先说说什么是HTTP，HTTP就是我们平时浏览网页时候使用的一种协议。HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全。为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。

https保证安全的原理

Client端和Server端如果用非对称加密的算法进行通信肯定是绝对安全的，因为私钥和密钥没有第三方知道。但是这样的问题是性能低下。但是如果用对称加密，很容易泄露密钥，安全性得不到保证。那么https是如何做的呢？
大概原理就是使用非对称加密来交换一个密钥来进行对称加密。这个过程被称为SSL/TSL的四次握手，具体过程如下：

Client端向Server端的443端口发出请求，带上随机数client_random和支持的加密方式列表
Server端返回随机数server_random ，选择的加密方式和服务器证书链
Client端验证这个证书是否合法，如果非法则提示用户是否“继续接受这个不可信的网站”，如果合法则使用证书中的公钥加密premaster secret发送给服务端
Server端使用私钥解密premaster secret，然后通过client_random，server_random 和premaster secret 生成master secret，用于对称加密后续通信内容。
Sever端用master secret加密最终需要返回的网站内容
Client端也用相同的方式生成这个master secret解密收到的消息

master_secret = PRF(pre_master_secret, “master secret”, ClientHello.random + ServerHello.random)[0..47];

随机数为什么要三个？
这是由于SSL/TLS设计，就假设服务器不相信所有的客户端都能够提供完全随机数，假如某个客户端提供的随机数不随机的话，就大大增加了“对话密钥”被破解的风险，所以由三组随机数组成最后的随机数，保证了随机数的随机性，以此来保证每次生成的“对话密钥”安全性。

那么问题来了

证书的安全性，Client端是如何验证证书合法性的，这个证书第三方无论如何都伪造不了吗？
对称加密密钥的安全性，生成的master secret密钥第三方为什么拿不到？

要解答这两个问题，首先得弄清楚什么是证书。

为什么证书是安全的？

什么是证书

数字证书就是互联网通讯中标志通讯各方身份信息的一串数字，提供了一种在Internet上验证通信实体身份的方式，数字证书不是数字身份证，而是身份认证机构盖在数字身份证上的一个章或印（或者说加在数字身份证上的一个签名）。它是由权威机构——CA机构，又称为证书授权（Certificate Authority）中心发行的，人们可以在网上用它来识别对方的身份。
数字证书的格式普遍采用的是X.509V3国际标准，一个标准的X.509数字证书包含以下一些内容：

证书的版本信息；
证书的序列号，每个证书都有一个唯一的证书序列号；
证书所使用的签名算法；
证书的发行机构名称，命名规则一般采用X.500格式；
证书的有效期，通用的证书一般采用UTC时间格式，它的计时范围为1950-2049；
证书所有人的名称，命名规则一般采用X.500格式；
证书所有人的公开密钥；
证书发行者对证书的签名。

证书里的公钥的作用？
证书里的签名的作用？
数字证书的签发机构CA，在接收到申请者的资料后进行核对并确定信息的真实有效，然后就会制作一份符合X.509标准的文件。证书中的证书内容包含的持有者信息和公钥等都是由申请者提供的，而数字签名则是CA机构对证书内容进行hash加密后得到的，而这个数字签名就是我们验证证书是否是有可信CA签发的数据。

证书的产生

证书的类型

实际上，我们使用的证书分很多种类型，SSL证书只是其中的一种。证书的格式是由X.509标准定义。SSL证书负责传输公钥，是一种PKI（Public Key Infrastructure，公钥基础结构）证书。
我们常见的证书根据用途不同大致有以下几种：
1、SSL证书，用于加密HTTP协议，也就是HTTPS。
2、代码签名证书，用于签名二进制文件，比如Windows内核驱动，Firefox插件，Java代码签名等等。
3、客户端证书，用于加密邮件。
4、双因素证书，网银专业版使用的USB Key里面用的就是这种类型的证书。
这些证书都是由受认证的证书颁发机构——我们称之为CA（Certificate Authority）机构来颁发，针对企业与个人的不同，可申请的证书的类型也不同，价格也不同。CA机构颁发的证书都是受信任的证书，对于SSL证书来说，如果访问的网站与证书绑定的网站一致就可以通过浏览器的验证而不会提示错误。

证书的安全问题

如果让证书安全，那么就需要让客户端拿到的证书是真正想要的证书，即不能让证书被冒充或者被篡改。
那么如何保证这一点呢？

如果证书自己有一个id
证书的这个id无法被伪造
客户端知道自己想要的证书id是多少

如果做到了这三点就能保证证书的安全性了。上面说提到的id就是证书的数字签名。那么什么是数字签名？

数字签名（digital signature）

数字签名是证书的防伪标签，是将待签名内容通过哈希和私钥加密处理后生成的。目前使用最广泛的 SHA-RSA 数字签名的制作和验证过程如下：

数字签名的签发。首先是使用哈希函数对待签名内容进行安全哈希，生成数字摘要，然后使用CA自己的私钥对数字摘要进行加密。
数字签名的校验。使用CA的公钥解密签名，然后使用相同的签名函数对待签名证书内容进行签名并和服务端数字签名里的签名内容进行比较，如果相同就认为校验成功。

签发：待签名内容 -> 哈希 -> 数字摘要 -> CA私钥加密 -> 数字签名
校验：

数字签名 -> CA公钥解密 -> 数字摘要1
待签名内容 -> 哈希 -> 数字摘要2
比较「数字摘要1」和「数字摘要2」是否相等

这里有几点需要说明：

数字签名签发和校验使用的密钥对是 CA 自己的公私密钥，跟证书申请者提交的公钥没有关系。
数字签名的签发过程跟公钥加密的过程刚好相反，即是用私钥加密，公钥解密。
现在大的 CA 都会有证书链，证书链的好处一是安全，保持根 CA 的私钥离线使用。第二个好处是方便部署和撤销，即如果证书出现问题，只需要撤销相应级别的证书，根证书依然安全。
根 CA 证书都是自签名，即用自己的公钥和私钥完成了签名的制作和验证。而证书链上的证书签名都是使用上一级证书的密钥对完成签名和验证的。

那么问题又来了。
CA的私钥和公钥是安全的吗？可以被冒充吗？

CA的安全性

从根CA开始到直接给客户发放证书的各层次CA，都有其自身的密钥对。CA中心的密钥对一般由硬件加密服务器在机器内直接产生，并存储于加密硬件内，或以一定的加密形式存放于密钥数据库内。加密备份于IC卡或其他存储介质中，并以高等级的物理安全措施保护起来。密钥的销毁要以安全的密钥冲写标准，彻底清除原有的密钥痕迹。需要强调的是，根CA密钥的安全性至关重要，它的泄露意味着整个公钥信任体系的崩溃，所以CA的密钥保护必须按照最高安全级的保护方式来进行设置和管理。

CA的私钥是自己靠上述方法保管的，不对外公开。
CA的公钥是厂商跟浏览器和操作系统合作，把公钥默认装到浏览器或者操作系统环境里。比如firefox 就自己维护了一个可信任的 CA 列表，而chrome 和 IE 使用的是操作系统的 CA 列表。

证书验证失败的原因

1、SSL证书不是由受信任的CA机构颁发的(注意这种情况并不一定说明有SSL劫持发生)
2、证书过期
3、访问的网站域名与证书绑定的域名不一致

至此，可以知道证书在一定程度上是非常安全的，客户端只要收到的证书是合法的，就能很大程度上保证整个会话是安全的。

客户端具体是如何验证SSL证书的

为了抵御这种中间人攻击，SSL证书需要由可信的SSL证书颁发机构颁发，形成一个证书链（比如Gmail的证书链为：最底层为网域 mail.google.com，上一层为Thawte SGC CA证书颁发机构，最顶层为很有名的VeriSign证书颁发机构）。那么，浏览器除了需要验证域和有效期外，还要检查证书链中的上级证书公钥是否有效，上级的上级证书公钥是否有效，直至根证书公钥为止。这样就可以有效避免中间人攻击了，因为根证书公钥都是预装在操作系统中的，黑客如果不是暴力破解，无法得到根证书的私钥。如果黑客自己生成一个私钥，浏览器验证根证书公钥的时候发现无法通过操作系统中预装的公钥加密数据后使用这个私钥进行解密，从而判定这个公钥是无效的。这个方案也是现在https通讯通常的方案。

那么，这个现在所有的浏览器正在使用的https通讯方案就无懈可击了吗？答案仍是否定的。我们可以看到，在后一个方案中，https的安全性需要在证书颁发机构公信力的强有力保障前提下才能发挥作用。如果证书颁发机构在没有验证黑客为mail.google.com的持游者的情况下，给黑客颁发了网域为mail.google.com的证书，那么黑客的中间人攻击又可以顺利实施然而，不验证域名持有者就颁发证书的情况在国外几乎不会发生，但是在国内就不一定了。针对破解目标，国内证书颁发机构WoSign（在此只是举例国内比较有名的证书颁发机构WoSign，并不代表WoSign今后一定会这么做）很有可能为了上级要求颁发了证书给非域名持有者的黑客，从而使得破解目标的Gmail密码被黑客截取。

涉及到的算法

非对称加密算法：RSA，DSA/DSS
对称加密算法：AES，RC4，3DES
HASH算法：MD5，SHA1，SHA256

总结

整个过程是递进的，一步一步了解https安全的原理。

https如何保证安全又高效？
https使用非对称加密算法来交换对称加密的密钥，最后使用对称加密算法来进行通信。
如何保证非对称加密时的安全性？
服务端发送证书来传递非对称加密的公钥。保证了公钥和私钥的保密性。
客户端怎么知道证书是不是真的？
客户端根据CA证书的公钥校验证书的数字签名来保证其合法性。
客户端的CA证书不会被伪造或泄露吗？
CA证书是默认预装到浏览器和操作系统中的，所以CA证书的公钥是安全的。

Reference

http://op.baidu.com/2015/04/https-s01a01/
https://cipherstuff.wordpress.com/
http://oncenote.com/2014/10/21/Security-1-HTTPS/
http://www.williamlong.info/archives/2058.html
http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html