Http与Https的区别

简单的讲,Http协议的客户端和服务端通信采用的是明文(post请求也只是将数据放在header中,但依然是明文传输。而Hppts协议的客户端和服务端间通信采用的秘文传输（对称加密和非对称加密相结合）

HTTPS是如何保障安全的

HTTPS其实就是secure http的意思,也就是HTTP的安全升级版。稍微了解网络基础的同学都知道，HTTP是应用层协议，位于HTTP协议之下是传输协议TCP。TCP负责传输，HTTP则定义了数据如何进行包装。

传输加密的流程:原先是应用层将数据直接给到TCP进行传输，现在改成应用层将数据给到TLS/SSL，将数据加密后，再给到TCP进行传输。

tls-ssl-_tcp-ip_protocol.png

握手认证:
客户端发起一次请求后,服务端返回数字证书,客户端接受到后,生成一个对称密钥,再用服务器下发证书中的公钥对其加密并发送,服务端接受到客户端发送的加密后的对称密钥后用自己的私钥解密,获得对称密钥。到此服务端和客户端都拥有了可以用来加密数据的对称密钥，并且可以保证该密钥没有泄漏。
传输阶段
客户端和服务端用上面得到的对称密钥将数据加密后正常传输。

关于对称加密和非对称加密就不在此赘述了,详见[http://blog.csdn.net/bluishglc/article/details/7585965]

由上面的Https握手过称可以知道,Https的安全性很大程度上取决于服务器下发的公钥,所以先了解下证书:
在正式介绍证书的格式前，必须先科普下数字签名和摘要，然后再对证书进行非深入的介绍。
为什么呢？因为数字签名、摘要是证书防伪非常关键的武器。

简单的来说，“摘要”就是对传输的内容，通过hash算法计算出一段固定长度的串（是不是联想到了文章摘要）。然后，在通过CA的私钥对这段摘要进行加密，加密后得到的结果就是“数字签名”。（这里提到CA的私钥，后面再进行介绍）

明文 --> hash运算 --> 摘要 --> 私钥加密 --> 数字签名

结合上面内容，我们知道，这段数字签名只有CA的公钥才能够解密。
接下来，我们再来看看神秘的“证书”究竟包含了什么内容，然后就大致猜到是如何对非法证书进行预防的了。
数字签名、摘要进一步了解可参考这篇文章。

先无耻的贴上一大段内容，证书格式来自这篇不错的文章《OpenSSL 与 SSL 数字证书概念贴》
内容非常多，这里我们需要关注的有几个点：

此外，有一点需要补充下，就是：
CA本身有自己的证书，江湖人称“根证书”。这个“根证书”是用来证明CA的身份的，本质是一份普通的数字证书。
浏览器通常会内置大多数主流权威CA的根证书。
如何辨别非法证书
上面提到，XX证书包含了如下内容：

证书包含了颁发证书的机构的名字 -- CA
证书内容本身的数字签名（用CA私钥加密）
证书持有者的公钥
证书签名用到的hash算法
浏览器内置的CA的根证书包含了如下关键内容：

好了，接下来针对之前提到的两种非法证书的场景，讲解下怎么识别

完全伪造的证书
这种情况比较简单，对证书进行检查：
证书颁发的机构是伪造的：浏览器不认识，直接认为是危险证书
证书颁发的机构是确实存在的，于是根据CA名，找到对应内置的CA根证书、CA的公钥。
用CA的公钥，对伪造的证书的摘要进行解密，发现解不了。认为是危险证书
篡改过的证书
假设代理通过某种途径，拿到XX的证书，然后将证书的公钥偷偷修改成自己的，然后喜滋滋的认为用户要上钩了。然而太单纯了：
1.检查证书，根据CA名，找到对应的CA根证书，以及CA的公钥。
2.用CA的公钥，对证书的数字签名进行解密，得到对应的证书摘要AA
3.根据证书签名使用的hash算法，计算出当前证书的摘要BB
4.对比AA跟BB，发现不一致--> 判定是危险证书

https的主要缺点就是性能问题。造成https性能低于http的原因有两个：

对数据进行加解密决定了它比http慢。
另外一个重要原因的是https禁用了缓存。相关测试数据表明使用HTTPS协议传输数据的工作效率只有使用HTTP协议传输的十分之一。因此对于一个网站来说，只有那对那些安全要求极高的的数据才会选择使用https进行传输。

本文主要来自https://segmentfault.com/a/1190000004523659, 自己做了些修改