HTTP是不安全的，只需要设定相应的DNS，做一个中间人攻击，再将修改后的数据返回，就可以达到篡改数据的目的(加入未经许可的广告)。
当我们切换HTTPS时候，运营商的这些小九九就施展不开了，服务端认证不通过，浏览器不会展示相应的页面数据；运营商实施搞的这一套东东也就不能在用户不知情的情况下搞起来了，解决办法是去除相应的受污染的DNS。
安全需求
- 加密（客户端和服务器的对话是私密的，无须担心被窃听）
- 服务端认证（客户端知道它们是在与真正的而不是伪造的服务器通信）
- 客户端认证（服务器知道它们是在与真正的而不是伪造的客户端通信）
- 完整性（客户端和服务器的数据不会被修改）
- 效率（一个运行足够快的算法，一遍低端的客户端和服务器使用）
- 普适性（基本上所有的客户端和服务器都支持这些协议）
- 管理的可扩展性（在任何地方的任何人都可以立即进行安全通信）
- 适应性（能够支持当前最知名的安全方法）
- 在社会上的可行性（满足社会的政治文化需要），要有公众受信能力
在这里最重要的是前边几条
- 数据加密 传输内容进行混淆
- 身份验证 通信双方验证对方的身份真实性
- 数据完整性保护 检测传输的内容是否被篡改或伪造
HTTPS简介
HTTPS(全称：Hypertext Transfer Protocol Secure 超文本传输安全协议)，是以安全为目标的HTTP通道，简单讲是HTTP的安全版。
HTTP+加密+认证+完整性保护 = HTTPS
- HTTP： 直接通过明文在浏览器和服务器之间传递信息。
- HTTPS： 采用 对称加密 和 非对称加密 结合的方式来保护浏览器和服务端之间的通信安全。
对称加密算法加密数据+非对称加密算法交换密钥+数字证书验证身份=安全
共享密钥加密也称对称密钥加密。采用的是使用相同密钥对报文进行加密解密。
缺点：无法避免被网络监听泄漏密钥的问题。同时对于众多客户端的服务器来说还需要分配和管理密钥，对于客户端来说也需要管理密钥，增加设计和实现的复杂度，同时也降低了通信的效率。
非对称加密，公钥加密只能通过对应的私钥解密，私钥加密只能通过对应的公钥解密。
缺点：公开密钥加密(非对称加密)安全性高，伴随着加密方式复杂，处理速度慢的问题。如果我们的通信都是用公开密钥的方式加密，那么通信效率会很低。
采用非对称加密因为安全性 采用对称加密是因为他加解密速度快
在交换密钥对环节使用公开密钥加密方式（防止被监听泄漏密钥）加密共享的密钥，在随后的通信过程中使用共享密钥的方式使用共享的密钥进行加解密。
认证方式实现
数字证书
数字签名是附加在报文上的特殊加密校验码，可以证明是作者编写了这条报文，前提是作者才会有私钥，才能算出这些校验码。如果传输的报文被篡改，则校验码不会匹配，因为校验码只有作者保存的私钥才能产生，所以前面可以保证报文的完整性。
数字证书认证机构（Certificate Authority CA）是客户端和服务器双方都可信赖的第三方机构。
服务器的运营人员向数字证书认证机构提出证书认证申请，数字证书认证机构在判明申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书（也叫数字证书或证书）后绑定在一起。服务器将这份有数字认证机构颁发的公钥证书发总给客户端，以进行公开密钥加密方式通信。
数据完整性
数字签名是只有信息发送者才能产生的别人无法伪造的一段文本，这段文本是对信息发送者发送信息真实性的一个有效证明，具有不可抵赖性。
报文的发送方从报文文本生成一个128位的散列值（或称为报文摘要活哈希值），发送方使用自己的私钥对这个摘要值进行加密来形成发送方的数字签名。然后这个数字签名将作为报文的附件一起发送给报文的接收方。报文的接收方首先从接收到的原始报文中计算出128位的散列值，再用发送方的公钥来对报文附加的数字签名进行解密。如果两次得到的结果是一致的那么接收方可以确认该数字签名是发送方的，同时确认信息是真实的 。
HTTPS其实是有两部分组成：HTTP + SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。
- 传统的HTTP协议通信：传统的HTTP报文是直接将报文信息传输到TCP然后TCP再通过TCP套接字发送给目的主机上。
- HTTPS协议通信：HTTPS是HTTP报文直接将报文传输给SSL套接字进行加密，SSL加密后将加密的报文发送给TCP套接字，然后TCP套接字再将加密后的报文发送给目的主机，目的主机通过TCP套接字获取加密后的报文给SSL套接字，SSL解密后交给对应进程。
SSL
SSL工作在OSI七层模型中的表示层，TCP/IP 四层模型的应用层。
SSL 基于TCP，SSL不是简单地单个协议，而是两层协议；SSL记录协议（SSL Record Protocol）为多种高层协议（SSL握手协议，SSL修改密码参数协议，SSL报警协议）提供基本的安全服务。
HTTP是为Web客户端/服务器交互提供传输服务的，它可以在SSL的顶层运行；SSL记录协议为SSL链接提供两种服务，1. 机密性：握手协议定义了一个共享密钥，用于SSL载荷的对称加密。 2. 消息完整性：握手协议还定义了一个共享密钥，它用来产生一个消息认证码（Message Authentication Code，MAC）。
HTTPS加密、解密和验证过程
SSL记录协议操作
- 分段 将每个上层消息分解成不大于2^14（16384）位，然后有选择的进行压缩
- 添加MAC 在压缩数据的基础上计算MAC
- 加密 消息加上MAC用对称加密方法加密
- 添加SSL记录头 内容类型（8位），主版本（8位），副版本（8位），压缩长度（16位）
SSL握手过程 - 第一阶段 建立安全能力 包括协议版本 会话Id 密码构件 压缩方法和初始随机数
- 第二阶段 服务器发送证书 密钥交换数据和证书请求，最后发送请求-相应阶段的结束信号
- 第三阶段 如果有证书请求客户端发送此证书 之后客户端发送密钥交换数据 也可以发送证书验证消息
- 第四阶段 变更密码构件和结束握手协议
SSL协议两个重要概念，SSL会话，SSL连接；SSL连接是点到点的连接，而且每个连接都是瞬态的，每一个链接都与一个会话关联。SSL会话是一个客户端和一个服务器之间的一种关联，会话由握手协议（Handshake Protocol）创建，所有会话都定义了一组密码安全参数，这些安全参数可以在多个连接之间共享，会话可以用来避免每一个链接需要进行的代价高昂的新的安全参数协商过程。
HTTPS加密请求(一次握手)过程
- 客户端发起握手请求，以明文传输请求信息，包含版本信息，加密-套件候选列表，压缩算法候选列表，随机数，扩展字段等信息(这个没什么好说的，就是用户在浏览器里输入一个HTTPS网址，然后连接到服务端的443端口。)
- 服务端的配置, 采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面。这套证书其实就是一对公钥和私钥。如果对公钥不太理解，可以想象成一把钥匙和一个锁头，只是世界上只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。
- 服务端返回协商的信息结果，包括选择使用的协议版本 version，选择的加密套件 cipher suite，选择的压缩算法 compression method、随机数 random_S 以及证书。(这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。)
- 客户端验证证书的合法性，包括可信性，是否吊销，过期时间和域名。(这部分工作是由客户端的SSL/TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警示框，提示证书存在的问题。如果证书没有问题，那么就生成一个随机值。然后用证书（也就是公钥）对这个随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。)
- 客户端使用公匙对对称密匙加密，发送给服务端。(这部分传送的是用证书加密后的随机值，目的是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。)
- 服务器用私钥解密，拿到对称加密的密匙。(服务端用私钥解密后，得到了客户端传过来的随机值，然后把内容通过该随机值进行对称加密，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。)
- 传输加密后的信息，这部分信息就是服务端用私钥加密后的信息，可以在客户端用随机值解密还原。
- 客户端解密信息，客户端用之前生产的私钥解密服务端传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。
客户端和服务端之间的加密机制
?
