在http协议的缺点通信中使用明文，内容有可能被窃听(泄露重要密码) (不验证通信对方的身份，有可能遭遇伪装) )在网站之间要求伪造)的消息的完整性无法证明，有可能被篡改) https是在http协议中加上加密处理、认证机构和完整性保护，http加密认证完整性保护=https
https不是APP应用层的新协议，只是http通信接口部分被ssl/tls协议取代。 http通常直接与tcp通信，但使用ssl时，它会发展为首先与ssl通信，然后与ssl通过tcp通信。
https实际上是指披着ssl协议外壳的http
什么是SSL/TLS？ SSL是“安全套接字层”的缩写，在中文中被称为“安全覆盖层”。 是20世纪90年代中期，网景公司设计的。
你为什么发明了SSL这个协议？ 由于原来在互联网上使用的HTTP协议是明文的，所以存在传输内容被窃取(snipping )或篡改等很多缺点。 发明SSL协议是为了解决这些问题。
到了1999年，SSL被广泛使用，因此成为了网上的事实标准。 ITF在那一年将SSL标准化了。 标准化后的名称改为传输层安全协议(TLS )缩写，中文称之为“传输层安全协议”。
所以，这两者其实是同一协议，只是不同阶段的不同称谓。
SSL协议位于TCP/IP协议和各种APP应用层协议之间，可安全地支持数据通信。 SSL协议分为以下两个级别：
sslrecordprotocol (sslrecordprotocol ) :建立在受信任的传输协议(如TCP )之上，支持高层协议的数据封装、压缩和加密等基本功能。
SSL握手协议(SSL Handshake Protocol )构建在SSL记录协议之上，在实际数据传输开始之前，通信伙伴进行认证、加密算法协商、加密密钥交换等
对称密钥加密和非对称密钥加密对称密钥加密也称为私钥加密，信息的发送方和接收方使用相同的密钥加密和解密数据。 最大的优点是加密/解密速度快，适合加密大数据量，但密钥管理困难。
不对称密钥加密，也称为公钥加密，需要使用一对密钥分别执行加密和解密操作。 一个是公钥，另一个是用户自己秘密存储的私钥，即私有密钥。 信息发送者用公钥加密，信息接收者用私钥解密。
在功能上，不对称加密比对称加密更强大，但加密和解密的速度比对称密钥加密慢得多。
不对称密钥通信过程
SSL/TLS协议的基本原理SSL/TLS协议的基本思路是采用公钥加密法。 这意味着客户端首先向服务器端请求公钥，然后用公钥加密信息。 服务器收到密文后，用自己的私钥解密，这里有两个问题。
)1)、如何防止公钥被篡改？
解决方案：将公钥放入数字证书中，只要证书可信，公钥就可信。
) 2、公钥加密计算量太大，如何减少消耗时间？
解决方案：对于每个会话(session )，在客户端和服务器端生成“会话密钥”(session key )并使用它加密信息。 “会话密钥”是对称加密，因此运算速度非常快，服务器公钥仅用于“会话密钥”本身的加密，从而减少加密运算的消耗时间。
因此，SSL/TLS协议的基本过程如下：
客户端向服务器端请求公钥进行验证。 双方协商生成“对话密钥”。 双方使用“会话密钥”进行加密通信。 具体流程请参考以下板栗
假设客户端称为pgddwl，服务器称为主动航空，则整个握手过程可以在下图中说明
首先，pgddwl提供协议版本号、客户端生成的随机数(客户端随机)以及客户端支持的加密方法。 具体加密方法请参考SSL证书背后的加密算法。
在第2步中，积极的航空公司将审查双方使用的加密方法，并提供数字证书和一个服务器生成的随机数(Server random )。
第3步(3(PGDdwl验证数字证书是否有效，生成新的随机数(Premaster secret )，并使用数字证书的公钥对该随机数进行加密，然后将其发送给积极的航空公司。
在第4步中，积极的航空公司使用自己的私钥获取pgddwl发送来的随机数，即Premaster secret。
步骤5，pgddwl和积极航空公司基于约定的加密方法，使用前面的三个随机数生成用于加密下一整个对话过程的“对话密钥”(session key )。
HTTPS的工作原理1、客户端发起HTTPS请求
用户在浏览器中输入https地址，连接到服务器的443端口。
2、服务端的配置
使用HTTPS协议的服务器必须具有一组可以自己创建或向组织申请的数字证书。 区别在于，您颁发的证书需要客户端验证才能继续访问。
而使用受信任的公司申请的证书则不会弹出提示页面。
3、传送证书
这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。
4、客户端解析证书
这部分工作是由客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。
（1）首先浏览器读取证书中的证书所有者、有效期等信息进行一一校验
（2）浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发
（3）如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。
（4）如果找到，那么浏览器就会从操作系统中取出颁发者CA 的公钥(多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥)，然后对服务器发来的证书里面的签名进行解密
（5）浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比
（6）对比结果一致，则证明服务器发来的证书合法，没有被冒充
（7）此时浏览器就可以读取证书中的公钥，用于后续加密了
5、传送加密信息
这部分传送的是用证书加密后的随机值(私钥)，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
6、服务端解密信息
服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密
7、传输加密后的信息
这部分信息是服务端用私钥加密后的信息，可以在客户端被还原。
8、客户端解密信息
客户端用之前生成的私钥解密服务端传过来的信息，于是获取了解密后的内容，整个过程第三方即使监听到了数据，也束手无策。
原理如下图
配置https最重要的是配置ssl证书，配置SSL证书可以参考SSL证书部署指南
这里我们以自签证书来演示：
sudo openssl genrsa -out server.key 2048
生成自签证书文件sudo openssl req -new -x509 -days 1826 -key server.key -out server.crt
修改apache配置apache2.4
需开启的模块LoadModule ssl_module libexec/apache2/mod_ssl.so
LoadModule socache_shmcb_module libexec/apache2/mod_socache_shmcb.so
sudo vim httpd-ssl.conf
<VirtualHost *:443> DocumentRoot "/var/www/html" ServerName www.domain.com:443 SSLEngine on SSLCertificateFile /usr/local/apache/conf/server.crt #添加证书文件 SSLCertificateKeyFile /usr/local/apache/conf/server.key #添加私钥文件</VirtualHost> 检测配置文件是否有错误sudo apachectl configtest
重启apachesudo apachectl restart
Fiddler/Charles是如何监听HTTPS?第一步，Fiddler截获客户端发送给服务器的HTTPS请求，Fiddler伪装成客户端向服务器发送请求进行握手 。
第二步，服务器发回相应，Fiddler获取到服务器的CA证书， 用根证书（这里的根证书是CA认证中心给自己颁发的证书）公钥进行解密， 验证服务器数据签名， 获取到服务器CA证书公钥。然后Fiddler伪造自己的CA证书（这里的CA证书，也是根证书，只不过是Fiddler伪造的根证书）， 冒充服务器证书传递给客户端浏览器。
第三步，与普通过程中客户端的操作相同，客户端根据返回的数据进行证书校验、生成密码Pre_master、用Fiddler伪造的证书公钥加密，并生成HTTPS通信用的对称密钥enc_key。
第四步，客户端将重要信息传递给服务器， 又被Fiddler截获。Fiddler将截获的密文用自己伪造证书的私钥解开， 获得并计算得到HTTPS通信用的对称密钥enc_key。Fiddler将对称密钥用服务器证书公钥加密传递给服务器。
第五步，与普通过程中服务器端的操作相同，服务器用私钥解开后建立信任，然后再发送加密的握手消息给客户端。
第六步，Fiddler截获服务器发送的密文， 用对称密钥解开， 再用自己伪造证书的私钥加密传给客户端。
第七步，客户端拿到加密信息后，用公钥解开，验证HASH。握手过程正式完成，客户端与服务器端就这样建立了”信任“。
在之后的正常加密通信过程中，Fiddler如何在服务器与客户端之间充当第三者呢？
服务器—>客户端：Fiddler接收到服务器发送的密文， 用对称密钥解开， 获得服务器发送的明文。再次加密， 发送给客户端。
客户端—>服务端：客户端用对称密钥加密，被Fiddler截获后，解密获得明文。再次加密，发送给服务器端。由于Fiddler一直拥有通信用对称密钥enc_key， 所以在整个HTTPS通信过程中信息对其透明。