前言
这篇文章实话说我有点虚, 因为平时都不怎么研究这一块的, 然后涉及到的知识点超多, 我只能到处看看资料总结一下相关信息, 所以在此我只想说句:
本文章内容只代表个人立场, 有错必改!
原本打算一次性总结, 后来越扯越多超过字数限制了, 就干脆做成 http 系列文章了, 不定时更新原有内容(发现哪里出错的话), 不定时新增系列文章, 请见谅!
Http 协议系列 ----OSI 参考模型, 协议原理构成, 三次握手, 四次挥手, 连接管理
Http 协议系列 -- 字符编码, cookie, 缓存, 疑难杂症
PS: 好多人反映看不懂繁体字, 鉴于这些理论性东西不仅枯燥而且复杂, 我就都转简体吧.
什么是 HTTPS 协议?(来自百度百科)
HTTPS(Hyper Text Transfer Protocol over Secure Socket Layer), 是以安全为目标的 HTTP 通道, 简单讲是 HTTP 的安全版. HTTPS 的安全基础是 SSL, 它是一个 URI scheme(抽象标识符体系), 句法类同 http: 体系. 用于安全的 HTTP 数据传输. https:URL 表明它使用了 HTTP, 但 HTTPS 存在不同于 HTTP 的默认端口及一个加密 / 身份验证层(在 HTTP 与 TCP 之间). 这个系统提供了身份验证与加密通讯方法. 现在它被广泛用于万维网上安全敏感的通讯, 例如交易支付方面. 主要作用:
建立一个信息安全通道, 来保证数据传输的安全
确认网站的真实性, 凡是使用了 https 的网站, 都可以通过点击浏览器地址栏的锁头标志来查看网站认证之后的真实信息, 也可以通过 CA 机构颁发的安全签章来查询
HTTP 和 HTTPS 的区别
HTTP 协议以明文方式发送内容, 不提供任何方式的数据加密, 因此 HTTP 协议不适合传输一些敏感信息, 比如信用卡号, 密码等.
HTTPS 在 HTTP 的基础上加入了 SSL 协议, SSL 依靠证书来验证服务器的身份, 并为浏览器和服务器之间的通信加密.
https 协议需要到 CA 申请证书, 一般免费证书很少, 需要交费;
https 协议可以通过 CA 机构颁发的安全签章或点击浏览器地址栏的锁头标志来查看网站认证之后的真实信息;
http 是超文本传输协议, 信息是明文传输, https 则是具有安全性的 ssl 加密传输协议;
http 和 https 使用的是完全不同的连接方式, 用的端口也不一样, 前者是 80, 后者是 443;
http 的连接很简单, 是无状态的; HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输, 身份认证的网络协议, 比 http 协议安全;
- (懒, 直接百度图片的拿来用的..)
- (更多内容请自行查阅, 本节到此为止了.)
- SSL(Secure Sockets Layer) && TLS(Transport Layer Security)
SSL 是一种在传输层对网络连接进行加密为网络通信提供安全及数据完整性的安全协议, TLS 是 SSL 的升级版.
SSL 协议位于 TCP/IP 协议与各种应用层协议之间, 为数据通讯提供安全支持. SSL 协议可分为两层:
SSL 记录协议 (SSL Record Protocol): 它建立在可靠的传输协议(如 TCP) 之上, 为高层协议提供数据封装, 压缩, 加密等基本功能的支持.
SSL 握手协议(SSL Handshake Protocol): 它建立在 SSL 记录协议之上, 用于在实际的数据传输开始前, 通讯双方进行身份认证, 协商加密算法, 交换加密密钥等.
SSL 协议提供的服务主要有:
1)认证用户和服务器, 确保数据发送到正确的客户机和服务器
2)加密数据以防止数据中途被窃取
3)维护数据的完整性, 确保数据在传输过程中不被改变.
SSL 协议的工作流程:
服务器认证阶段:
1)客户端向服务器发送一个开始请求以便开始一个新的会话连接;
2)服务器根据客户端的请求确定是否需要生成新的主密钥, 如需要则服务器在响应客户端请求时将包含生成主密钥所需的信息;
3)客户端根据收到的服务器响应信息, 产生一个主密钥, 并用服务器的公开密钥加密后传给服务器;
4)服务器取回该主密钥, 并返回给客户端一个用主密钥认证的信息, 以此让客户端认证服务器.
用户认证阶段
在此之前, 服务器已经通过了客户端认证, 这一阶段主要完成对客户端的认证. 经认证的服务器发送一个请求给客户端, 客户端则返回 (数字) 签名后的请求和其公开密钥, 从而向服务器提供认证.
从 SSL 协议所提供的服务及其工作流程可以看出, SSL 协议运行的基础是商家对消费者信息保密的承诺, 这就有利于商家而不利于消费者. 在电子商务初级阶段, 由于运作电子商务的企业大多是信誉较高的大公司, 因此这问题还没有充分暴露出来. 但随著电子商务的发展, 各中小型公司也参与进来, 这样在电子支付过程中的单一认证问题就越来越突出. 虽然在 SSL3.0 中通过数字签名和数字证书可实现浏览器和 web 服务器双方的身份验证, 但是 SSL 协议仍存在一些问题, 比如, 只能提供交易中客户与服务器间的双方认证, 在涉及多方的电子交易中, SSL 协议并不能协调各方间的安全传输和信任关系. 在这种情况下, Visa 和 MasterCard 两大信用卡公组织制定了 SET 协议, 为网上信用卡支付提供了全球性的标准.
(更详细内容请看大神阮一峰的 SSL/TLS 协议运行机制的概述 http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html , 下文也会讲解握手内容)
握手过程
专业版
1, 客户端向服务器传送 SSL 协议的版本号, 加密算法的种类, 产生的随机数, 以及其他服务器和客户端之间通讯所需要的各种信息.
2, 服务器向客户端传送 SSL 协议的版本号, 加密算法的种类, 随机数以及其他相关信息, 同时服务器还将向客户端传送自己的证书.
3, 客户端利用服务器传过来的信息验证服务器的合法性, 服务器的合法性包括: 证书是否过期, 发行服务器证书的 CA 是否可靠, 发行者证书的公钥能否正确解开服务器证书的 "发行者的数字签名", 服务器证书上的域名是否和服务器的实际域名相匹配. 如果合法性验证没有通过, 通讯将断开; 如果合法性验证通过, 将继续进行第四步.
4, 客户端随机产生一个用于后面通讯的 "对称密码", 然后用服务器的公钥 (服务器的公钥从步骤二中的服务器的证书中获得) 对其加密, 然后将加密后的 "Master-Key" 传给服务器.
5, 如果服务器要求客户端的身份认证(在握手过程中为可选), 客户端可以建立一个随机数然后对其进行数字签名, 将这个含有签名的随机数和客户端自己的证书以及加密过的 "Master-Key" 一起传给服务器.
6, 如果服务器要求客户的身份认证, 服务器必须检验客户端证书和签名随机数的合法性, 具体的合法性验证过程包括: 客户的证书使用日期是否有效, 为客户提供证书的 CA 是否可靠, 发行 CA 的公钥能否正确解开客户证书的发行 CA 的数字签名, 检查客户的证书是否在证书废止列表 (CRL) 中. 检验如果没有通过, 通讯立刻中断; 如果验证通过, 服务器将用自己的私钥解开加密的 "Master-Key", 然后执行一系列步骤来产生主通讯密码(客户端也将通过同样的方法产生相同的主通讯密码).
7, 服务器和客户端用相同的主密码即 "通话密码", 一个对称密钥用于 SSL 协议的安全数据通讯的加解密通讯. 同时在 SSL 通讯过程中还要完成数据通讯的完整性, 防止数据通讯中的任何变化.
8, 客户端向服务器端发出信息, 指明后面的数据通讯将使用的步骤 7 中的主密码为对称密钥, 同时通知服务器客户端的握手过程结束.
9, 服务器向客户端发出信息, 指明后面的数据通讯将使用的步骤 7 中的主密码为对称密钥, 同时通知客户端服务器端的握手过程结束.
10, SSL 的握手部分结束, SSL 安全通道的数据通讯开始, 客户和服务器开始使用相同的对称密钥进行数据通讯, 同时进行通讯完整性的检验.
我知道专业术语加上繁体字好多人看不懂, 我翻译成白话文给你们看:
浓缩版
1, 客户端向服务器传送
1) SSL 协议版本;
2) 加密算法种类;
3) 随机数 A(用于生成对话密钥);
4) 以及其他相关信息;
2, 服务器返回给客户端
1) 确定 SSL 协议版本;
2) 确定加密算法;
3) 随机数 B(用于生成对话密钥);
4) 以及其他相关信息;
5) 服务器证书;
6) 要求客户端身份认证(可选);
3, 客户端利用这些信息验证服务器的各种合法性
1) 通过继续;
2) 否则断开通讯;
4, 客户端生成一个随机数 C(用于生成对话密钥), 从服务器的证书中获得的公匙;
1) 公匙加密 pre-master key 传给服务器;
2) 如果要求客户端身份认证, 生成一个随机数 D(用于验证客户提供证书的 CA 是否可靠)进行数字签名连同公匙加密的随机数 C 和客户端证书一起传给服务器;
6, 如果服务器要求认证客户端身份, 服务器会检验客户端证书和签名随机数 C 的合法性.
1) 通过, 服务器用自己的私匙解开得到随机数 C;
2) 否则断开通讯;
7, 服务器和客户端拥有随机数 A, 随机数 B, 随机数 C 和确定的加密算法, 会生成相同的会话密钥, 会话密钥用于 SSL 协议的安全数据通讯的加解密通讯. 同时在 SSL 通讯过程中还要完成数据通讯的完整性, 防止数据通讯中的任何变化;
8, 服务器和客户端
1) 确认会话密钥;
2) 通知握手结束;
9, SSL 握手结束, 开始通讯;
(还没太懂也懒, 直接百度图片的拿来用的..)
极致简洁版:
1, 客户端发送随机数 A, 支持的加密方法, 及其他相关信息等;
2, 服务端发送随机数 B, 和服务器证书(可以拿到公匙), 并确认加密方法;
3, 客户端发送用公钥加密的随机数 C;
4, 服务器用私钥解密得到随机数 C;
5, 服务器和客户端用加密方法计算生成对称加密的会话密钥传输数据;
- (还没太懂也懒, 直接百度图片的拿来用的..)
- (更多内容请自行查阅, 本节到此为止了.)
加密算法:
HTTPS 常见的算法简单讲解:
1, 对称加密
加密 (encryption) 与解密 (decryption) 用的是同样的密钥(secret key)
优点: 快速, 简单
缺点: 密钥的管理与分配风险大
例如: DES,AES-GCM,ChaCha20-Poly1305 等
2, 非对称加密
加密使用的密钥和解密使用的密钥是不相同的, 分别称为: 公钥, 私钥, 公钥和算法都是公开的, 私钥是保密的. 非对称加密算法性能较低, 但是安全性超强, 由于其加密特性, 非对称加密算法能加密的数据长度也是有限的.
优点: 安全
缺点: 效率慢
例如: RSA,DSA,ECDSA, DH,ECDHE
常见的方式是将对称加密的密钥使用非对称加密的公钥进行加密, 然后发送出去, 接收方使用私钥进行解密得到对称加密的密钥, 然后双方可以使用对称加密来进行沟通.
3, 哈希算法
哈希算法并不是一个特定的算法而是一类算法的统称. 哈希算法也叫散列算法, 任意数据通过一个函数转换成长度固定的数据串(通常用 16 进制的字符串表示), 函数与数据串之间形成一一映射的关系.
优点:
1, 占用空间小, 一般固定长度结果就能代替原数据去做些验证比较;
2, 数据差敏感, 即使差别小也得到不同结果;
3, 逆推难度大, 跟算法有关;
4, 碰撞几率小, 跟算法有关;
缺点:
2, 即使一些无关紧要微小的改变也会得到不同结果;
3, 逆推可能;
4, 碰撞可能;
例如: MD5,SHA-1,SHA-2,SHA-256 等
4, 数字签名
数字签名技术是将摘要信息用发送者的私钥加密, 与原文一起传送给接收者. 接收者只有用发送者的公钥才能解密被加密的摘要信息, 然后用 HASH 函数对收到的原文产生一个摘要信息, 与解密的摘要信息对比. 如果相同, 则说明收到的信息是完整的, 在传输过程中没有被修改, 否则说明信息被修改过, 因此数字签名能够验证信息的完整性.
数字签名是个加密的过程, 数字签名验证是个解密的过程
优点:
1, 必须依赖于被签名消息的比特模式, 这有利于根据数字特性做出更复杂的甄别模式, 从而达到更优秀的加 / 解密效果;
2, 通过利用密码学的技术, 使用时相对于签名者来说信息具有唯一性, 以防伪造和否认;
3, 在算法上是可验证的, 因此数字签名更加严谨和科学;
4, 更加精确地满足了签名的不可模仿性;
缺点: 信息网络系统的管理机制和技术漏洞是数字签名技术应用的最大威胁和挑战
(更多内容请自行查阅, 本节到此为止了.)
HTTPS 的缺点
CA 申请证书费用高, 部署更新很麻烦;
频繁地做加密和解密操作认证等一系列操作, 消耗资源多, 等待时间长;
HTTPS 优化
CDN 接入
1) CDN 节点通过和业务服务器维持长连接, 会话复用和链路质量优化等可控方法, 极大减少 HTTPS 带来的延时
会话缓存
1) 基于会话缓存建立的 HTTPS 连接不需要服务器使用私钥解密获取信息, 可以省去 CPU 的消耗
简化握手
1) 服务器生成并返回 Session ID 给客户端, 当握手时携带上 Session ID, 服务端后会从自己的内存查找, 如果找到便意味著客户端之前已经发生过完全握手, 然后可以直接进行简化握手
2) 当握手时携带上 Session Ticket, 服务器会对它进行解密, 如果解密成功了就意味著它是值得信任的, 从而可以进行简化握手, 直接传输应用层数据.
硬件加速
远程解密
1) 将最消耗 CPU 资源的解密计算任务转移到其它服务器, 如此则可以充分发挥服务器的接入能力, 充分利用带宽与网卡资源.
2) 远程解密服务器可以选择 CPU 负载较低的机器充当, 实现机器资源复用, 也可以是专门优化的高计算性能的服务器.
SPDY/HTTP2
1) 利用 TLS/SSL 带来的优势, 通过修改协议的方法来提升 HTTPS 的性能, 提高下载速度等
(更多内容请自行查阅, 本节到此为止了.)
来源: http://www.qdfuns.com/article/40831/3ffb59e3d1dfc7ed44e521c2a57aeec7.html