https

https

详谈HTTPS SSL/TLS协议原理

科技创新森马 发表了文章 • 0 个评论 • 41 次浏览 • 2021-04-28 16:53 • 来自相关话题

协议安全和加密越来越引起人们的重视和关注,今天就跟大家分享一点协议加密方面的知识。要说清楚 HTTPS 协议的实现原理,至少需要如下几个背景知识。大致了解几个基本术语(HTTPS、SSL、TLS)的含义大致了解 HTTP 和 TCP 的关系(尤其是 “短连接”... ...查看全部

协议安全和加密越来越引起人们的重视和关注,今天就跟大家分享一点协议加密方面的知识。要说清楚 HTTPS 协议的实现原理,至少需要如下几个背景知识。

  1. 大致了解几个基本术语(HTTPS、SSL、TLS)的含义

  2. 大致了解 HTTP 和 TCP 的关系(尤其是 “短连接”VS“长连接”)

  3. 大致了解加密算法的概念(尤其是 “对称加密与非对称加密” 的区别)

  4. 大致了解 CA 证书的用途考虑到很多技术菜鸟可能不了解上述背景,俺先用最简短的文字描述一下。如果你自认为不是菜鸟,请略过本章节,直接去看 “HTTPS 协议的需求”。

一、先澄清几个术语——HTTPS、SSL、TLS。

1. “HTTP” 是干嘛用滴?

首先,HTTP 是一个网络协议,是专门用来帮你传输 Web 内容滴。关于这个协议,就算你不了解,至少也听说过吧?比如你访问俺的博客的主页,浏览器地址栏会出现如下的网址http://www.xxx.com/

俺加了粗体的部分就是指 HTTP 协议。大部分网站都是通过 HTTP 协议来传输 Web 页面、以及 Web 页面上包含的各种东东(图片、CSS 样式、JS 脚本)。

2. “SSL/TLS” 是干嘛用滴?

SSL 是洋文 “Secure Sockets Layer” 的缩写,中文叫做 “安全套接层”。它是在上世纪 90 年代中期,由网景公司设计的。(顺便插一句,网景公司不光发明了 SSL,还发明了很多 Web 的基础设施——比如“CSS 样式表” 和“JS 脚本”) 为啥要发明 SSL 这个协议捏?因为原先互联网上使用的 HTTP 协议是明文的,存在很多缺点——比如传输内容会被偷窥(嗅探)和篡改。发明 SSL 协议,就是为了解决这些问题。

到了 1999 年,SSL 因为应用广泛,已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化之后的名称改为 TLS(是 “Transport Layer Security” 的缩写),中文叫做“传输层安全协议”。

很多相关的文章都把这两者并列称呼(SSL/TLS),因为这两者可以视作同一个东西的不同阶段。

3. “HTTPS” 是啥意思?

解释完 HTTP 和 SSL/TLS,现在就可以来解释 HTTPS 啦。咱们通常所说的 HTTPS 协议,说白了就是 “HTTP 协议” 和“SSL/TLS 协议”的组合。你可以把 HTTPS 大致理解为——“HTTP over SSL”或“HTTP over TLS”(反正 SSL 和 TLS 差不多)。

二、再来说说 HTTP 协议的特点

作为背景知识介绍,还需要再稍微谈一下 HTTP 协议本身的特点。HTTP 本身有很多特点,考虑到篇幅有限,俺只谈那些和 HTTPS 相关的特点。

1. HTTP 的版本和历史

如今咱们用的 HTTP 协议,版本号是 1.1(也就是 HTTP 1.1)。这个 1.1 版本是 1995 年底开始起草的(技术文档是 RFC2068),并在 1999 年正式发布(技术文档是 RFC2616)。

在 1.1 之前,还有曾经出现过两个版本 “0.9 和 1.0”,其中的 HTTP 0.9 没有被广泛使用,而 HTTP 1.0 被广泛使用过。另外,2015年IETF 就要发布 HTTP 2.0 的标准了。

2. HTTP 和 TCP 之间的关系

简单地说,TCP 协议是 HTTP 协议的基石——HTTP 协议需要依靠 TCP 协议来传输数据。在网络分层模型中,TCP 被称为 “传输层协议”,而 HTTP 被称为 “应用层协议”。

有很多常见的应用层协议是以 TCP 为基础的,比如 “FTP、SMTP、POP、IMAP” 等。

TCP 被称为 “面向连接” 的传输层协议。关于它的具体细节,俺就不展开了(否则篇幅又失控了)。你只需知道:传输层主要有两个协议,分别是 TCP 和 UDP。TCP 比 UDP 更可靠。你可以把 TCP 协议想象成某个水管,发送端这头进水,接收端那头就出水。并且 TCP 协议能够确保,先发送的数据先到达(与之相反,UDP 不保证这点)。

3. HTTP 协议如何使用 TCP 连接?

HTTP 对 TCP 连接的使用,分为两种方式:俗称 “短连接” 和“长连接”(“长连接”又称 “持久连接”,洋文叫做“Keep-Alive” 或“Persistent Connection”) 假设有一个网页,里面包含好多图片,还包含好多外部的CSS 文件和 JS 文件。在 “短连接” 的模式下,浏览器会先发起一个 TCP 连接,拿到该网页的 HTML 源代码(拿到 HTML 之后,这个 TCP 连接就关闭了)。然后,浏览器开始分析这个网页的源码,知道这个页面包含很多外部资源(图片、CSS、JS)。

然后针对每一个外部资源,再分别发起一个个 TCP 连接,把这些文件获取到本地(同样的,每抓取一个外部资源后,相应的 TCP 就断开) 相反,如果是 “长连接” 的方式,浏览器也会先发起一个 TCP 连接去抓取页面。但是抓取页面之后,该 TCP 连接并不会立即关闭,而是暂时先保持着(所谓的“Keep-Alive”)。然后浏览器分析 HTML 源码之后,发现有很多外部资源,就用刚才那个 TCP 连接去抓取此页面的外部资源。

在 HTTP 1.0 版本,默认使用的是 “短连接”(那时候是 Web 诞生初期,网页相对简单,“短连接” 的问题不大);到了 1995 年底开始制定 HTTP 1.1 草案的时候,网页已经开始变得复杂(网页内的图片、脚本越来越多了)。这时候再用短连接的方式,效率太低下了(因为建立 TCP 连接是有 “时间成本” 和“CPU 成本”滴)。

所以,在 HTTP 1.1 中,默认采用的是 “Keep-Alive” 的方式。关于 “Keep-Alive” 的更多介绍,可以参见维基百科词条。

三、谈谈 “对称加密” 和“非对称加密”的概念

1. 啥是 “加密” 和“解密”?

通俗而言,你可以把 “加密” 和“解密”理解为某种互逆的数学运算。就好比 “加法和减法” 互为逆运算、“乘法和除法”互为逆运算。

“加密”的过程,就是把 “明文” 变成 “密文” 的过程;反之,“解密”的过程,就是把 “密文” 变为“明文”。在这两个过程中,都需要一个关键的东东——叫做“密钥”——来参与数学运算。

2. 啥是 “对称加密”?

所谓的 “对称加密技术”,意思就是说:“加密” 和“解密”使用相同的密钥。这个比较好理解。就好比你用 7zip 或 WinRAR 创建一个带密码(口令)的加密压缩包。当你下次要把这个压缩文件解开的时候,你需要输入同样的密码。在这个例子中,密码 / 口令就如同刚才说的“密钥”。

3. 啥是 “非对称加密”?

所谓的 “非对称加密技术”,意思就是说:“加密” 和“解密”使用不同的密钥。这玩意儿比较难理解,也比较难想到。当年 “非对称加密” 的发明,还被誉为 “密码学” 历史上的一次革命。

由于篇幅有限,对 “非对称加密” 这个话题,俺就不展开了。有空的话,再单独写一篇扫盲。

4. 各自有啥优缺点?

看完刚才的定义,很显然:(从功能角度而言)“非对称加密”能干的事情比 “对称加密” 要多。这是 “非对称加密” 的优点。但是 “非对称加密” 的实现,通常需要涉及到 “复杂数学问题”。所以,“非对称加密” 的性能通常要差很多(相对于 “对称加密” 而言)。这两者的优缺点,也影响到了 SSL 协议的设计。

四、HTTPS 协议的需求是啥?

花了好多口水,终于把背景知识说完了。下面正式进入正题。先来说说当初设计 HTTPS 是为了满足哪些需求?

很多介绍 HTTPS 的文章一上来就给你讲实现细节。个人觉得:这是不好的做法。早在 2009 年开博的时候,发过一篇<学习技术的三部曲:WHAT、HOW、WHY>,其中谈到 “WHY 型问题” 的重要性。一上来就给你讲协议细节,你充其量只能知道 WHAT 和 HOW,无法理解 WHY。

俺在前一个章节讲了“背景知识”,在这个章节讲了“需求”,这就有助于你理解:当初为什么要设计成这样?——这就是 WHY 型的问题。

兼容性

因为是先有 HTTP 再有 HTTPS。所以,HTTPS 的设计者肯定要考虑到对原有 HTTP 的兼容性。这里所说的兼容性包括很多方面。比如已有的 Web 应用要尽可能无缝地迁移到 HTTPS;比如对浏览器厂商而言,改动要尽可能小;基于 “兼容性” 方面的考虑,很容易得出如下几个结论:

  1. HTTPS 还是要基于 TCP 来传输(如果改为 UDP 作传输层,无论是 Web 服务端还是浏览器客户端,都要大改,动静太大了)。

  2. 单独使用一个新的协议,把 HTTP 协议包裹起来 (所谓的 “HTTP over SSL”,实际上是在原有的 HTTP 数据外面加了一层 SSL 的封装。HTTP 协议原有的 GET、POST 之类的机制,基本上原封不动)。打个比方: 如果原来的 HTTP 是塑料水管,容易被戳破;那么如今新设计的 HTTPS 就像是在原有的塑料水管之外,再包一层金属水管。一来,原有的塑料水管照样运行;二来,用金属加固了之后,不容易被戳破。

可扩展性

前面说了,HTTPS 相当于是 “HTTP over SSL”。如果 SSL 这个协议在 “可扩展性” 方面的设计足够牛逼,那么它除了能跟 HTTP 搭配,还能够跟其它的应用层协议搭配。岂不美哉?

现在看来,当初设计 SSL 的人确实比较牛。如今的 SSL/TLS 可以跟很多常用的应用层协议(比如: FTP、SMTP、POP、Telnet)搭配,来强化这些应用层协议的安全性。

接着刚才打的比方: 如果把 SSL/TLS 视作一根用来加固的金属管,它不仅可以用来加固输水的管道,还可以用来加固输煤气的管道。

保密性

HTTPS 需要做到足够好的保密性。说到保密性,首先要能够对抗嗅探(行话叫 Sniffer)。所谓的 “嗅探”,通俗而言就是监视你的网络传输流量。如果你使用明文的 HTTP 上网,那么监视者通过嗅探,就知道你在访问哪些网站的哪些页面。

嗅探是最低级的攻击手法。除了嗅探,HTTPS 还需要能对抗其它一些稍微高级的攻击手法——比如 “重放攻击”。

完整性

除了 “保密性”,还有一个同样重要的目标是“确保完整性”。关于“完整性” 这个概念,在之前的博文<扫盲文件完整性校验——关于散列值和数字签名>中大致提过。健忘的同学再去温习一下。在发明 HTTPS 之前,由于 HTTP 是明文的,不但容易被嗅探,还容易被篡改。

举个例子: 比如咱们天朝的网络运营商都比较流氓,经常有网友抱怨说访问某网站(本来是没有广告的),竟然会跳出很多广告。为啥会这样捏?因为你的网络流量需要经过 ISP 的线路才能到达公网。如果你使用的是明文的 HTTP,ISP 很容易就可以在你访问的页面中植入广告。所以,当初设计 HTTPS 的时候,还有一个需求是 “确保 HTTP 协议的内容不被篡改”。

真实性

在谈到 HTTPS 的需求时,“真实性”经常被忽略。其实 “真实性” 的重要程度不亚于前面的 “保密性” 和“完整性”。

举个例子: 你因为使用网银,需要访问该网银的 Web 站点。那么,你如何确保你访问的网站确实是你想访问的网站?(这话有点绕口令) 有些天真的同学会说:通过看网址里面的域名来确保。

为啥说这样的同学是 “天真的”?因为 DNS 系统本身是不可靠的(尤其是在设计 SSL 的那个年代,连DNSSEC 都还没发明)。由于DNS 的不可靠(存在“域名欺骗” 和“域名劫持”),你看到的网址里面的域名未必是真实滴!所以,HTTPS 协议必须有某种机制来确保 “真实性” 的需求。

性能

再来说最后一个需求——性能。引入 HTTPS 之后,不能导致性能变得太差。否则的话,谁还愿意用?为了确保性能,SSL的设计者至少要考虑如下几点:

  1. 如何选择加密算法(“对称”or“非对称”)?

  2. 如何兼顾 HTTP 采用的 “短连接”TCP 方式?SSL 是在1995 年之前开始设计的,那时候的 HTTP 版本还是 1.0,默认使用的是 “短连接” 的 TCP 方式——默认不启用 Keep-Alive)。


透视HTTPS建造固若金汤的城堡

科技创新木土走召 发表了文章 • 0 个评论 • 42 次浏览 • 2021-03-17 12:00 • 来自相关话题

为什么有 HTTPS?因为 HTTP 不安全! 现在的互联网已经不再是 “田园时代”,“黑暗森林” 已经到来。上网的记录会被轻易截获,网站是否真实也无法验证,黑客可以伪装成银行网站,盗取真实姓名、密码、银行卡等敏感信息,威胁人身安全和财产安全。上网的... ...查看全部

为什么有 HTTPS?因为 HTTP 不安全! 现在的互联网已经不再是 “田园时代”,“黑暗森林” 已经到来。上网的记录会被轻易截获,网站是否真实也无法验证,黑客可以伪装成银行网站,盗取真实姓名、密码、银行卡等敏感信息,威胁人身安全和财产安全。

上网的时候必须步步为营、处处小心,否则就会被不知道埋伏在哪里的黑客所“猎杀”。

HTTPS 如何实现安全通信?如何构建出固若金汤的网络城堡?主要涉及的知识点如下:

  • 了解什么是 HTTPS

  • 什么样的才是安全的通信

  • 对称加密与非对称加密、摘要算法、数字签名、完整性校验到底是什么

  • 迁移 HTTPS 的必要性

什么是安全

做事要稳,老司机【码哥字节】开车要安全!不管是戴杜蕾斯还是安全气囊,“安全至关重要”!

在通信过程中,具备以下特性则认为安全:机密性、完整性、不可否认、身份认证

机密性

数据必须保密,只能有信任的人读取,其他人是不可见的秘密。诸葛亮的密报总不能让司马懿知道呀,不然还玩个蛋。通俗的说:就是不能让不相关的人看到不该看的东西。

完整性

也叫作一致性,也就是数据在传输过程中没有被非法篡改,内容不能多也不能少,一五一十的保持原状。

打个比方,原本张无忌说:“赵敏,么么哒。”,传信的飞鸽被周芷若抓到了,截取了消息,改成了 “赵敏,去死吧!”。这么子搞,倚天屠龙记可能就会被改写了。

不可否认

也就做不可抵赖,不能否认已经发生过的事情。所谓 “君子一言,驷马难追”。“老懒” 这种事情不能发生。

就像尹志平亲密接触了小龙女,事后一直隐瞒否认,装作不知道,这是万万不可的。所以最终就嗝屁了。

身份验证

也就是确认对方的真实身份,“证明你是真的是你”,保证消息发送到可信的人,而不是非法之徒。

比如令狐冲写了一份情书给任盈盈:“盈盈,冲哥哥爱你哟”,但是岳不群看到快递小哥,冒充是令狐冲,截取了情书后回复:“傻逼,白日做梦”。令狐冲不知道这是岳不群的回复,以为是任盈盈的,笑傲江湖又要重写了……

所以同时具备了机密性、完整性、身份认证、不可否认四个特性,通信双方的安全才有保证,才是真正的安全。

什么是 HTTPS

到这里,终于轮到 HTTPS 上台了,也就是它为 HTTP 增加了刚刚说的四大安全特性。

HTTPS 其实是一个“非常简单”的协议,规定了新的协议名“https”,默认端口号 443,至于其他的什么请求 – 应答模式、报文结构、请求方法、URI、头字段、连接管理等等都完全沿用 HTTP,没有任何新的东西。唯一的差别就是端口号不同、去掉明文传输。

微信图片_20210311113558.png

那 HTTPS 凭啥就变得安全了呢?

就是因为他在 TCP/IP 与 HTTP 之间加上了 SSL/TLS ,从原来的 HTTP over TCP/IP 变成了HTTP over SSL/TLS,让 HTTP 运行在 安全的 SSL/TLS 协议上,安全开车。http与https

所以重点就是去掌握 SSL/TLS 到底是什么玩意成就了安全。

SSL/TLS

SSL 即安全套接层(Secure Sockets Layer),在 OSI 模型中处于第 5 层(会话层),由网景公司于 1994 年发明,有 v2 和 v3 两个版本,而 v1 因为有严重的缺陷从未公开过。

SSL 发展到 v3 时已经证明了它自身是一个非常好的安全通信协议,于是互联网工程组 IETF 在 1999 年把它改名为 TLS(传输层安全,Transport Layer Security),正式标准化,版本号从 1.0 重新算起,所以 TLS1.0 实际上就是 SSLv3.1。

TLS 由记录协议、握手协议、警告协议、变更密码规范协议、扩展协议等几个子协议组成,综合使用了对称加密、非对称加密、身份认证等许多密码学前沿技术。

浏览器与服务器在使用 TLS 建立连接的时候实际上就是选了一组加密算法实现安全通信,这些算法组合叫做 “密码套件(cipher suite)”。

套件命名很有规律,比如“ECDHE-RSA-AES256-GCM-SHA384”。按照 密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法”组成的.

所以这个套件的意思就是:使用 ECDHE 算法进行密钥交换,使用 RSA 签名和身份验证,握手后使用 AES 对称加密,密钥长度 256 位,分组模式 GCM,消息认证和随机数生成使用摘要算法 SHA384。

对称加密与非对称加密

前面提到四个实现安全的必要条件,先说 机密性,也就是消息只能给想给的人看到并且看得懂。

实现机密性的手段就是 加密(encrypt),也就是将原本明文消息使用加密算法转换成别人看不懂的密文,只有掌握特有的 密钥 的人才能解密出原始内容。就好像是诸葛亮将发给关二爷密报的内容通过一种转换算法转成其他的内容,司马懿看不懂。关二爷持有解密该内容的关键钥匙。

钥匙也就是 密钥(key),未加密的消息叫做 明文 (plain text/clear text),加密后的内容叫做 密文(cipher text),通过密钥解密出原文的过程叫做 解密(decrypt),而加解密的整个过程就是 加密算法。

由于 HTTPS、TLS 都运行在计算机上,所以“密钥”就是一长串的数字,但约定俗成的度量单位是“位”(bit),而不是“字节”(byte)。比如,说密钥长度是 128,就是 16 字节的二进制串,密钥长度 1024,就是 128 字节的二进制串。

加密算法通常有两大类:对称加密和非对称加密。

对称加密

加密和解密使用的密钥都是同一个,是 “对称的”。双方只要保证不会有泄露其他人知道这个密钥,通信就具有机密性。

对称加密算法常见的有 RC4、DES、3DES、AES、ChaCha20 等,但前三种算法都被认为是不安全的,通常都禁止使用,目前常用的只有 AES 和 ChaCha20。

AES 的意思是“高级加密标准”(Advanced Encryption Standard),密钥长度可以是 128、192 或 256。它是 DES 算法的替代者,安全强度很高,性能也很好,而且有的硬件还会做特殊优化,所以非常流行,是应用最广泛的对称加密算法。

加密分组模式

对称算法还有一个 “分组模式”的概念,目的是通过算法用固定长度的密钥加密任意长度的明文。

最新的分组模式被称为 AEAD(Authenticated Encryption with Associated Data),在加密的同时增加了认证的功能,常用的是 GCM、CCM 和 Poly1305。

非对称加密

有对称加密,为何还搞出一个非对称加密呢?

对称加密确实解决了机密性,只有相关的人才能读取出信息。但是最大的问题是:如何安全的把密钥传递对方,专业术语 “密钥交换”。

这个很容易理解,对称加密的密钥在飞鸽传书过程中被打鸟的敌军捕获窃取,那么就能随意加解密收发作战密报数据了,诸葛亮的密报没有机密可言。

所以非对称加密诞生了。

由两个密钥组成,分别是 公钥(public key) 和 “私钥(private key)”,两个密钥是不一样的,这也就是不对称的由来,公钥可以任何人使用,私钥则自己保密。

这里需要注意的是:公钥和私钥都可以用来加密解密,公钥加密的密文只能用私钥解密,反之亦然。

服务端保存私钥,在互联网上分发公钥,当访问服务器网站的时候使用授予的公钥加密明文即可,服务端则使用对应的私钥来解密。敌军没有私钥也就无法破解密文了。非对称加密

TLS 中常见的加密算法有 DH、RSA、ECC、DSA 等。其中的 RSA 最常用,它的安全性基于“整数分解”的数学难题,使用两个超大素数的乘积作为生成密钥的材料,想要从公钥推算出私钥是非常困难的。

ECC(Elliptic Curve Cryptography)是非对称加密里的“后起之秀”,它基于“椭圆曲线离散对数”的数学难题,使用特定的曲线方程和基点生成公钥和私钥,子算法 ECDHE 用于密钥交换,ECDSA 用于数字签名。

比起 RSA,ECC 在安全强度和性能上都有明显的优势。160 位的 ECC 相当于 1024 位的 RSA,而 224 位的 ECC 则相当于 2048 位的 RSA。因为密钥短,所以相应的计算量、消耗的内存和带宽也就少,加密解密的性能就上去了,对于现在的移动互联网非常有吸引力。

现在我们为了机密性从对称加密到非对称加密,而非对称加密还解决了密钥交换不安全的问题。那么是否可以直接使用非对称加密来实现机密性呢?

答案是否定的!

因为非对称加密运算速度比较慢。所以需要两者结合,混合模式实现机密性问题,同时又有很好的性能。

加密流程如下所示:

  1. 先创建一个随机数的对称加密密钥,会话密钥(session key);

  2. 使用会话密钥加密需要传输的明文消息,因为对称加密性能较好,接着再使用非对称加密的公钥对会话密钥加密,因为会话密钥很短,通常只有 16 字节或 32 字节,所以加密也不会太慢。这里主要就是解决了非对称加密的性能问题,同时实现了会话密钥的机密交换。

  3. 另一方接收到密文后使用非对称加密的私钥解密出上一步加密的 会话密钥,接着使用会话密钥解密出加密的消息明文。

混合加密

总结一下就是使用非对称加密算法来加密会话密钥,使用对称加密算法来加密消息明文,接收方则使用非对称加密算法的私钥解密出会话密钥,再利用会话密钥解密消息密文。

这样混合加密就解决了对称加密算法的密钥交换问题,而且安全和性能兼顾,完美地实现了机密性。

后面还有完整性、身份认证、不可否认等特性没有实现,所以现在的通信还不是绝对安全。

摘要算法与完整性

摘要算法的主要目的就是实现完整性,通过常见的散列函数、哈希函数实现。

我们可以简单理解成这事一种特殊的压缩算法,将任意长度的明文数据处理成固定长度、又是独一无二的“摘要”字符串,就是该数据的指纹。

同时摘要算法是单向加密算法,没有密钥,加密后的数据也无法解密,也就是不能从“摘要”推导出明文。

比如我们听过或者用过的 MD5(Message-Digest 5)、SHA-1(Secure Hash Algorithm 1),它们就是最常用的两个摘要算法,能够生成 16 字节和 20 字节长度的数字摘要。

完整性实现

有了摘要算法生成的数字摘要,那么我们只需要在明文数据附上对应的摘要,就能保证数据的完整性。

但是由于摘要算法不具有机密性,不能明文传输,否则黑客可以修改消息后把摘要也一起改了,网站还是鉴别不出完整性。

所以完整性还是要建立在机密性上,我们结合之前提到的混合加密使用 ”会话密钥“ 加密明文消息 + 摘要,这样的话黑客也就无法得到明文,无法做修改了。这里有个专业术语叫“哈希消息认证码(HMAC)”。哈希消息认证码(HMAC)

比如诸葛亮使用上面提到的混合加密过程给关二爷发消息:“明天攻城” + “SHA-2 摘要”,关二爷收到后使用密钥将解密出来的会话密钥解密出明文消息,同时对明文消息使用解密出来的摘要算法进行摘要计算,接着比对两份“摘要”字符串是否一致,如果一致就说明消息完整可信,没有被敌军修改过。

消息被修改是很危险的,要以史为鉴,比如赵高与李斯伪造遗诏,直接把扶苏给送西天了,这太可怕了。

总结下就是通过摘要比对防止篡改,同时利用混合加密实现密文与摘要的安全传输。

数字签名和 CA

到这里已经很安全了,但是还是有漏洞,就是通信的两头。黑客可以伪装成网站来窃取信息。而反过来,他也可以伪装成你,向网站发送支付、转账等消息,网站没有办法确认你的身份,钱可能就这么被偷走了。

现在如何实现身份认证呢?

现实生活中,解决身份认证的手段是签名和印章,只要在纸上写下签名或者盖个章,就能够证明这份文件确实是由本人而不是其他人发出的。

非对称加密依然可以解决此问题,只不过跟之前反过来用,使用私钥再加上摘要算法,就能够实现“数字签名”,同时实现“身份认证”和“不可否认”。

就是把公钥私钥的用法反过来,之前是公钥加密、私钥解密,现在是私钥加密、公钥解密。但又因为非对称加密效率太低,所以私钥只加密原文的摘要,这样运算量就小的多,而且得到的数字签名也很小,方便保管和传输。

重点就是使用非对称加密的“私钥”加密原文的摘要,对方则使用非对称加密的公钥解密出摘要,再比对解密出的原文通过摘要算法计算摘要与解密出的摘要比对是否一致。这样就能像签署文件一样证明消息确实是你发送的。签名验签

只要你和网站互相交换公钥,就可以用“签名”和“验签”来确认消息的真实性,因为私钥保密,黑客不能伪造签名,就能够保证通信双方的身份。

CA

到这里似乎已经大功告成,可惜还不是。

综合使用对称加密、非对称加密和摘要算法,我们已经实现了安全的四大特性,是不是已经完美了呢?

不是的,这里还有一个“公钥的信任”问题。因为谁都可以发布公钥,我们还缺少防止黑客伪造公钥的手段,也就是说,怎么来判断这个公钥就是你或者张三丰的公钥呢?

这个“第三方”就是我们常说的CA(Certificate Authority,证书认证机构)。它就像网络世界里的公安局、教育部、公证中心,具有极高的可信度,由它来给各个公钥签名,用自身的信誉来保证公钥无法伪造,是可信的。

CA 对公钥的签名认证也是有格式的,不是简单地把公钥绑定在持有者身份上就完事了,还要包含序列号、用途、颁发者、有效时间等等,把这些打成一个包再签名,完整地证明公钥关联的各种信息,形成“数字证书”(Certificate)。

OpenSSL

它是一个著名的开源密码学程序库和工具包,几乎支持所有公开的加密算法和协议,已经成为了事实上的标准,许多应用软件都会使用它作为底层库来实现 TLS 功能,包括常用的 Web 服务器 Apache、Nginx 等。

由于 OpenSSL 是开源的,所以它还有一些代码分支,比如 Google 的 BoringSSL、OpenBSD 的 LibreSSL,这些分支在 OpenSSL 的基础上删除了一些老旧代码,也增加了一些新特性,虽然背后有“大金主”,但离取代 OpenSSL 还差得很远。

总结下就是:OpenSSL 是著名的开源密码学工具包,是 SSL/TLS 的具体实现。

迁移 HTTPS 必要性

如果你做移动应用开发的话,那么就一定知道,Apple、Android、某信等开发平台在 2017 年就相继发出通知,要求所有的应用必须使用 HTTPS 连接,禁止不安全的 HTTP。

在台式机上,主流的浏览器 Chrome、Firefox 等也早就开始“强推”HTTPS,把 HTTP 站点打上“不安全”的标签,给用户以“心理压力”。

Google 等搜索巨头还利用自身的“话语权”优势,降低 HTTP 站点的排名,而给 HTTPS 更大的权重,力图让网民只访问到 HTTPS 网站。

这些手段都逐渐“挤压”了纯明文 HTTP 的生存空间,“迁移到 HTTPS”已经不是“要不要做”的问题,而是“要怎么做”的问题了。HTTPS 的大潮无法阻挡,如果还是死守着 HTTP,那么无疑会被冲刷到互联网的角落里。

顾虑

阻碍 HTTPS 实施的因素还有一些这样、那样的顾虑,我总结出了三个比较流行的观点:“慢、贵、难”。

而“慢”则是惯性思维,拿以前的数据来评估 HTTPS 的性能,认为 HTTPS 会增加服务器的成本,增加客户端的时延,影响用户体验。

其实现在服务器和客户端的运算能力都已经有了很大的提升,性能方面完全没有担心的必要,而且还可以应用很多的优化解决方案

所谓“贵”,主要是指证书申请和维护的成本太高,网站难以承担。

这也属于惯性思维,在早几年的确是个问题,向 CA 申请证书的过程不仅麻烦,而且价格昂贵,每年要交几千甚至几万元。

但现在就不一样了,为了推广 HTTPS,很多云服务厂商都提供了一键申请、价格低廉的证书,而且还出现了专门颁发免费证书的 CA,其中最著名的就是“Let’s Encrypt”。

所谓的“难”,是指 HTTPS 涉及的知识点太多、太复杂,有一定的技术门槛,不能很快上手。

总结

从什么是安全我们延展出 HTTPS,解释了什么是 HTTPS,以及与 HTTP 的区别。HTTPS 主要就是通过 SSL/TLS 实现安全,而安全我们又接触了什么是对称加密与非对称加密,非对称加密性能较弱,所以我们使用非对称加密来加密对称加密的“会话密钥”,利用会话密钥加密明文解决了性能问题。

通过混合加密实现了机密性,利用摘要算法实现了完整性,通过数字签名使用非对称加密的“私钥”加密原文的摘要,对方则使用非对称加密的公钥解密出摘要,再比对解密出的原文通过摘要算法计算摘要与解密出的摘要比对是否一致实现了身份认证与不可否认。

转载于公众号“码个蛋”

详谈HTTPS SSL/TLS协议原理

科技创新森马 发表了文章 • 0 个评论 • 41 次浏览 • 2021-04-28 16:53 • 来自相关话题

协议安全和加密越来越引起人们的重视和关注,今天就跟大家分享一点协议加密方面的知识。要说清楚 HTTPS 协议的实现原理,至少需要如下几个背景知识。大致了解几个基本术语(HTTPS、SSL、TLS)的含义大致了解 HTTP 和 TCP 的关系(尤其是 “短连接”... ...查看全部

协议安全和加密越来越引起人们的重视和关注,今天就跟大家分享一点协议加密方面的知识。要说清楚 HTTPS 协议的实现原理,至少需要如下几个背景知识。

  1. 大致了解几个基本术语(HTTPS、SSL、TLS)的含义

  2. 大致了解 HTTP 和 TCP 的关系(尤其是 “短连接”VS“长连接”)

  3. 大致了解加密算法的概念(尤其是 “对称加密与非对称加密” 的区别)

  4. 大致了解 CA 证书的用途考虑到很多技术菜鸟可能不了解上述背景,俺先用最简短的文字描述一下。如果你自认为不是菜鸟,请略过本章节,直接去看 “HTTPS 协议的需求”。

一、先澄清几个术语——HTTPS、SSL、TLS。

1. “HTTP” 是干嘛用滴?

首先,HTTP 是一个网络协议,是专门用来帮你传输 Web 内容滴。关于这个协议,就算你不了解,至少也听说过吧?比如你访问俺的博客的主页,浏览器地址栏会出现如下的网址http://www.xxx.com/

俺加了粗体的部分就是指 HTTP 协议。大部分网站都是通过 HTTP 协议来传输 Web 页面、以及 Web 页面上包含的各种东东(图片、CSS 样式、JS 脚本)。

2. “SSL/TLS” 是干嘛用滴?

SSL 是洋文 “Secure Sockets Layer” 的缩写,中文叫做 “安全套接层”。它是在上世纪 90 年代中期,由网景公司设计的。(顺便插一句,网景公司不光发明了 SSL,还发明了很多 Web 的基础设施——比如“CSS 样式表” 和“JS 脚本”) 为啥要发明 SSL 这个协议捏?因为原先互联网上使用的 HTTP 协议是明文的,存在很多缺点——比如传输内容会被偷窥(嗅探)和篡改。发明 SSL 协议,就是为了解决这些问题。

到了 1999 年,SSL 因为应用广泛,已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化之后的名称改为 TLS(是 “Transport Layer Security” 的缩写),中文叫做“传输层安全协议”。

很多相关的文章都把这两者并列称呼(SSL/TLS),因为这两者可以视作同一个东西的不同阶段。

3. “HTTPS” 是啥意思?

解释完 HTTP 和 SSL/TLS,现在就可以来解释 HTTPS 啦。咱们通常所说的 HTTPS 协议,说白了就是 “HTTP 协议” 和“SSL/TLS 协议”的组合。你可以把 HTTPS 大致理解为——“HTTP over SSL”或“HTTP over TLS”(反正 SSL 和 TLS 差不多)。

二、再来说说 HTTP 协议的特点

作为背景知识介绍,还需要再稍微谈一下 HTTP 协议本身的特点。HTTP 本身有很多特点,考虑到篇幅有限,俺只谈那些和 HTTPS 相关的特点。

1. HTTP 的版本和历史

如今咱们用的 HTTP 协议,版本号是 1.1(也就是 HTTP 1.1)。这个 1.1 版本是 1995 年底开始起草的(技术文档是 RFC2068),并在 1999 年正式发布(技术文档是 RFC2616)。

在 1.1 之前,还有曾经出现过两个版本 “0.9 和 1.0”,其中的 HTTP 0.9 没有被广泛使用,而 HTTP 1.0 被广泛使用过。另外,2015年IETF 就要发布 HTTP 2.0 的标准了。

2. HTTP 和 TCP 之间的关系

简单地说,TCP 协议是 HTTP 协议的基石——HTTP 协议需要依靠 TCP 协议来传输数据。在网络分层模型中,TCP 被称为 “传输层协议”,而 HTTP 被称为 “应用层协议”。

有很多常见的应用层协议是以 TCP 为基础的,比如 “FTP、SMTP、POP、IMAP” 等。

TCP 被称为 “面向连接” 的传输层协议。关于它的具体细节,俺就不展开了(否则篇幅又失控了)。你只需知道:传输层主要有两个协议,分别是 TCP 和 UDP。TCP 比 UDP 更可靠。你可以把 TCP 协议想象成某个水管,发送端这头进水,接收端那头就出水。并且 TCP 协议能够确保,先发送的数据先到达(与之相反,UDP 不保证这点)。

3. HTTP 协议如何使用 TCP 连接?

HTTP 对 TCP 连接的使用,分为两种方式:俗称 “短连接” 和“长连接”(“长连接”又称 “持久连接”,洋文叫做“Keep-Alive” 或“Persistent Connection”) 假设有一个网页,里面包含好多图片,还包含好多外部的CSS 文件和 JS 文件。在 “短连接” 的模式下,浏览器会先发起一个 TCP 连接,拿到该网页的 HTML 源代码(拿到 HTML 之后,这个 TCP 连接就关闭了)。然后,浏览器开始分析这个网页的源码,知道这个页面包含很多外部资源(图片、CSS、JS)。

然后针对每一个外部资源,再分别发起一个个 TCP 连接,把这些文件获取到本地(同样的,每抓取一个外部资源后,相应的 TCP 就断开) 相反,如果是 “长连接” 的方式,浏览器也会先发起一个 TCP 连接去抓取页面。但是抓取页面之后,该 TCP 连接并不会立即关闭,而是暂时先保持着(所谓的“Keep-Alive”)。然后浏览器分析 HTML 源码之后,发现有很多外部资源,就用刚才那个 TCP 连接去抓取此页面的外部资源。

在 HTTP 1.0 版本,默认使用的是 “短连接”(那时候是 Web 诞生初期,网页相对简单,“短连接” 的问题不大);到了 1995 年底开始制定 HTTP 1.1 草案的时候,网页已经开始变得复杂(网页内的图片、脚本越来越多了)。这时候再用短连接的方式,效率太低下了(因为建立 TCP 连接是有 “时间成本” 和“CPU 成本”滴)。

所以,在 HTTP 1.1 中,默认采用的是 “Keep-Alive” 的方式。关于 “Keep-Alive” 的更多介绍,可以参见维基百科词条。

三、谈谈 “对称加密” 和“非对称加密”的概念

1. 啥是 “加密” 和“解密”?

通俗而言,你可以把 “加密” 和“解密”理解为某种互逆的数学运算。就好比 “加法和减法” 互为逆运算、“乘法和除法”互为逆运算。

“加密”的过程,就是把 “明文” 变成 “密文” 的过程;反之,“解密”的过程,就是把 “密文” 变为“明文”。在这两个过程中,都需要一个关键的东东——叫做“密钥”——来参与数学运算。

2. 啥是 “对称加密”?

所谓的 “对称加密技术”,意思就是说:“加密” 和“解密”使用相同的密钥。这个比较好理解。就好比你用 7zip 或 WinRAR 创建一个带密码(口令)的加密压缩包。当你下次要把这个压缩文件解开的时候,你需要输入同样的密码。在这个例子中,密码 / 口令就如同刚才说的“密钥”。

3. 啥是 “非对称加密”?

所谓的 “非对称加密技术”,意思就是说:“加密” 和“解密”使用不同的密钥。这玩意儿比较难理解,也比较难想到。当年 “非对称加密” 的发明,还被誉为 “密码学” 历史上的一次革命。

由于篇幅有限,对 “非对称加密” 这个话题,俺就不展开了。有空的话,再单独写一篇扫盲。

4. 各自有啥优缺点?

看完刚才的定义,很显然:(从功能角度而言)“非对称加密”能干的事情比 “对称加密” 要多。这是 “非对称加密” 的优点。但是 “非对称加密” 的实现,通常需要涉及到 “复杂数学问题”。所以,“非对称加密” 的性能通常要差很多(相对于 “对称加密” 而言)。这两者的优缺点,也影响到了 SSL 协议的设计。

四、HTTPS 协议的需求是啥?

花了好多口水,终于把背景知识说完了。下面正式进入正题。先来说说当初设计 HTTPS 是为了满足哪些需求?

很多介绍 HTTPS 的文章一上来就给你讲实现细节。个人觉得:这是不好的做法。早在 2009 年开博的时候,发过一篇<学习技术的三部曲:WHAT、HOW、WHY>,其中谈到 “WHY 型问题” 的重要性。一上来就给你讲协议细节,你充其量只能知道 WHAT 和 HOW,无法理解 WHY。

俺在前一个章节讲了“背景知识”,在这个章节讲了“需求”,这就有助于你理解:当初为什么要设计成这样?——这就是 WHY 型的问题。

兼容性

因为是先有 HTTP 再有 HTTPS。所以,HTTPS 的设计者肯定要考虑到对原有 HTTP 的兼容性。这里所说的兼容性包括很多方面。比如已有的 Web 应用要尽可能无缝地迁移到 HTTPS;比如对浏览器厂商而言,改动要尽可能小;基于 “兼容性” 方面的考虑,很容易得出如下几个结论:

  1. HTTPS 还是要基于 TCP 来传输(如果改为 UDP 作传输层,无论是 Web 服务端还是浏览器客户端,都要大改,动静太大了)。

  2. 单独使用一个新的协议,把 HTTP 协议包裹起来 (所谓的 “HTTP over SSL”,实际上是在原有的 HTTP 数据外面加了一层 SSL 的封装。HTTP 协议原有的 GET、POST 之类的机制,基本上原封不动)。打个比方: 如果原来的 HTTP 是塑料水管,容易被戳破;那么如今新设计的 HTTPS 就像是在原有的塑料水管之外,再包一层金属水管。一来,原有的塑料水管照样运行;二来,用金属加固了之后,不容易被戳破。

可扩展性

前面说了,HTTPS 相当于是 “HTTP over SSL”。如果 SSL 这个协议在 “可扩展性” 方面的设计足够牛逼,那么它除了能跟 HTTP 搭配,还能够跟其它的应用层协议搭配。岂不美哉?

现在看来,当初设计 SSL 的人确实比较牛。如今的 SSL/TLS 可以跟很多常用的应用层协议(比如: FTP、SMTP、POP、Telnet)搭配,来强化这些应用层协议的安全性。

接着刚才打的比方: 如果把 SSL/TLS 视作一根用来加固的金属管,它不仅可以用来加固输水的管道,还可以用来加固输煤气的管道。

保密性

HTTPS 需要做到足够好的保密性。说到保密性,首先要能够对抗嗅探(行话叫 Sniffer)。所谓的 “嗅探”,通俗而言就是监视你的网络传输流量。如果你使用明文的 HTTP 上网,那么监视者通过嗅探,就知道你在访问哪些网站的哪些页面。

嗅探是最低级的攻击手法。除了嗅探,HTTPS 还需要能对抗其它一些稍微高级的攻击手法——比如 “重放攻击”。

完整性

除了 “保密性”,还有一个同样重要的目标是“确保完整性”。关于“完整性” 这个概念,在之前的博文<扫盲文件完整性校验——关于散列值和数字签名>中大致提过。健忘的同学再去温习一下。在发明 HTTPS 之前,由于 HTTP 是明文的,不但容易被嗅探,还容易被篡改。

举个例子: 比如咱们天朝的网络运营商都比较流氓,经常有网友抱怨说访问某网站(本来是没有广告的),竟然会跳出很多广告。为啥会这样捏?因为你的网络流量需要经过 ISP 的线路才能到达公网。如果你使用的是明文的 HTTP,ISP 很容易就可以在你访问的页面中植入广告。所以,当初设计 HTTPS 的时候,还有一个需求是 “确保 HTTP 协议的内容不被篡改”。

真实性

在谈到 HTTPS 的需求时,“真实性”经常被忽略。其实 “真实性” 的重要程度不亚于前面的 “保密性” 和“完整性”。

举个例子: 你因为使用网银,需要访问该网银的 Web 站点。那么,你如何确保你访问的网站确实是你想访问的网站?(这话有点绕口令) 有些天真的同学会说:通过看网址里面的域名来确保。

为啥说这样的同学是 “天真的”?因为 DNS 系统本身是不可靠的(尤其是在设计 SSL 的那个年代,连DNSSEC 都还没发明)。由于DNS 的不可靠(存在“域名欺骗” 和“域名劫持”),你看到的网址里面的域名未必是真实滴!所以,HTTPS 协议必须有某种机制来确保 “真实性” 的需求。

性能

再来说最后一个需求——性能。引入 HTTPS 之后,不能导致性能变得太差。否则的话,谁还愿意用?为了确保性能,SSL的设计者至少要考虑如下几点:

  1. 如何选择加密算法(“对称”or“非对称”)?

  2. 如何兼顾 HTTP 采用的 “短连接”TCP 方式?SSL 是在1995 年之前开始设计的,那时候的 HTTP 版本还是 1.0,默认使用的是 “短连接” 的 TCP 方式——默认不启用 Keep-Alive)。


透视HTTPS建造固若金汤的城堡

科技创新木土走召 发表了文章 • 0 个评论 • 42 次浏览 • 2021-03-17 12:00 • 来自相关话题

为什么有 HTTPS?因为 HTTP 不安全! 现在的互联网已经不再是 “田园时代”,“黑暗森林” 已经到来。上网的记录会被轻易截获,网站是否真实也无法验证,黑客可以伪装成银行网站,盗取真实姓名、密码、银行卡等敏感信息,威胁人身安全和财产安全。上网的... ...查看全部

为什么有 HTTPS?因为 HTTP 不安全! 现在的互联网已经不再是 “田园时代”,“黑暗森林” 已经到来。上网的记录会被轻易截获,网站是否真实也无法验证,黑客可以伪装成银行网站,盗取真实姓名、密码、银行卡等敏感信息,威胁人身安全和财产安全。

上网的时候必须步步为营、处处小心,否则就会被不知道埋伏在哪里的黑客所“猎杀”。

HTTPS 如何实现安全通信?如何构建出固若金汤的网络城堡?主要涉及的知识点如下:

  • 了解什么是 HTTPS

  • 什么样的才是安全的通信

  • 对称加密与非对称加密、摘要算法、数字签名、完整性校验到底是什么

  • 迁移 HTTPS 的必要性

什么是安全

做事要稳,老司机【码哥字节】开车要安全!不管是戴杜蕾斯还是安全气囊,“安全至关重要”!

在通信过程中,具备以下特性则认为安全:机密性、完整性、不可否认、身份认证

机密性

数据必须保密,只能有信任的人读取,其他人是不可见的秘密。诸葛亮的密报总不能让司马懿知道呀,不然还玩个蛋。通俗的说:就是不能让不相关的人看到不该看的东西。

完整性

也叫作一致性,也就是数据在传输过程中没有被非法篡改,内容不能多也不能少,一五一十的保持原状。

打个比方,原本张无忌说:“赵敏,么么哒。”,传信的飞鸽被周芷若抓到了,截取了消息,改成了 “赵敏,去死吧!”。这么子搞,倚天屠龙记可能就会被改写了。

不可否认

也就做不可抵赖,不能否认已经发生过的事情。所谓 “君子一言,驷马难追”。“老懒” 这种事情不能发生。

就像尹志平亲密接触了小龙女,事后一直隐瞒否认,装作不知道,这是万万不可的。所以最终就嗝屁了。

身份验证

也就是确认对方的真实身份,“证明你是真的是你”,保证消息发送到可信的人,而不是非法之徒。

比如令狐冲写了一份情书给任盈盈:“盈盈,冲哥哥爱你哟”,但是岳不群看到快递小哥,冒充是令狐冲,截取了情书后回复:“傻逼,白日做梦”。令狐冲不知道这是岳不群的回复,以为是任盈盈的,笑傲江湖又要重写了……

所以同时具备了机密性、完整性、身份认证、不可否认四个特性,通信双方的安全才有保证,才是真正的安全。

什么是 HTTPS

到这里,终于轮到 HTTPS 上台了,也就是它为 HTTP 增加了刚刚说的四大安全特性。

HTTPS 其实是一个“非常简单”的协议,规定了新的协议名“https”,默认端口号 443,至于其他的什么请求 – 应答模式、报文结构、请求方法、URI、头字段、连接管理等等都完全沿用 HTTP,没有任何新的东西。唯一的差别就是端口号不同、去掉明文传输。

微信图片_20210311113558.png

那 HTTPS 凭啥就变得安全了呢?

就是因为他在 TCP/IP 与 HTTP 之间加上了 SSL/TLS ,从原来的 HTTP over TCP/IP 变成了HTTP over SSL/TLS,让 HTTP 运行在 安全的 SSL/TLS 协议上,安全开车。http与https

所以重点就是去掌握 SSL/TLS 到底是什么玩意成就了安全。

SSL/TLS

SSL 即安全套接层(Secure Sockets Layer),在 OSI 模型中处于第 5 层(会话层),由网景公司于 1994 年发明,有 v2 和 v3 两个版本,而 v1 因为有严重的缺陷从未公开过。

SSL 发展到 v3 时已经证明了它自身是一个非常好的安全通信协议,于是互联网工程组 IETF 在 1999 年把它改名为 TLS(传输层安全,Transport Layer Security),正式标准化,版本号从 1.0 重新算起,所以 TLS1.0 实际上就是 SSLv3.1。

TLS 由记录协议、握手协议、警告协议、变更密码规范协议、扩展协议等几个子协议组成,综合使用了对称加密、非对称加密、身份认证等许多密码学前沿技术。

浏览器与服务器在使用 TLS 建立连接的时候实际上就是选了一组加密算法实现安全通信,这些算法组合叫做 “密码套件(cipher suite)”。

套件命名很有规律,比如“ECDHE-RSA-AES256-GCM-SHA384”。按照 密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法”组成的.

所以这个套件的意思就是:使用 ECDHE 算法进行密钥交换,使用 RSA 签名和身份验证,握手后使用 AES 对称加密,密钥长度 256 位,分组模式 GCM,消息认证和随机数生成使用摘要算法 SHA384。

对称加密与非对称加密

前面提到四个实现安全的必要条件,先说 机密性,也就是消息只能给想给的人看到并且看得懂。

实现机密性的手段就是 加密(encrypt),也就是将原本明文消息使用加密算法转换成别人看不懂的密文,只有掌握特有的 密钥 的人才能解密出原始内容。就好像是诸葛亮将发给关二爷密报的内容通过一种转换算法转成其他的内容,司马懿看不懂。关二爷持有解密该内容的关键钥匙。

钥匙也就是 密钥(key),未加密的消息叫做 明文 (plain text/clear text),加密后的内容叫做 密文(cipher text),通过密钥解密出原文的过程叫做 解密(decrypt),而加解密的整个过程就是 加密算法。

由于 HTTPS、TLS 都运行在计算机上,所以“密钥”就是一长串的数字,但约定俗成的度量单位是“位”(bit),而不是“字节”(byte)。比如,说密钥长度是 128,就是 16 字节的二进制串,密钥长度 1024,就是 128 字节的二进制串。

加密算法通常有两大类:对称加密和非对称加密。

对称加密

加密和解密使用的密钥都是同一个,是 “对称的”。双方只要保证不会有泄露其他人知道这个密钥,通信就具有机密性。

对称加密算法常见的有 RC4、DES、3DES、AES、ChaCha20 等,但前三种算法都被认为是不安全的,通常都禁止使用,目前常用的只有 AES 和 ChaCha20。

AES 的意思是“高级加密标准”(Advanced Encryption Standard),密钥长度可以是 128、192 或 256。它是 DES 算法的替代者,安全强度很高,性能也很好,而且有的硬件还会做特殊优化,所以非常流行,是应用最广泛的对称加密算法。

加密分组模式

对称算法还有一个 “分组模式”的概念,目的是通过算法用固定长度的密钥加密任意长度的明文。

最新的分组模式被称为 AEAD(Authenticated Encryption with Associated Data),在加密的同时增加了认证的功能,常用的是 GCM、CCM 和 Poly1305。

非对称加密

有对称加密,为何还搞出一个非对称加密呢?

对称加密确实解决了机密性,只有相关的人才能读取出信息。但是最大的问题是:如何安全的把密钥传递对方,专业术语 “密钥交换”。

这个很容易理解,对称加密的密钥在飞鸽传书过程中被打鸟的敌军捕获窃取,那么就能随意加解密收发作战密报数据了,诸葛亮的密报没有机密可言。

所以非对称加密诞生了。

由两个密钥组成,分别是 公钥(public key) 和 “私钥(private key)”,两个密钥是不一样的,这也就是不对称的由来,公钥可以任何人使用,私钥则自己保密。

这里需要注意的是:公钥和私钥都可以用来加密解密,公钥加密的密文只能用私钥解密,反之亦然。

服务端保存私钥,在互联网上分发公钥,当访问服务器网站的时候使用授予的公钥加密明文即可,服务端则使用对应的私钥来解密。敌军没有私钥也就无法破解密文了。非对称加密

TLS 中常见的加密算法有 DH、RSA、ECC、DSA 等。其中的 RSA 最常用,它的安全性基于“整数分解”的数学难题,使用两个超大素数的乘积作为生成密钥的材料,想要从公钥推算出私钥是非常困难的。

ECC(Elliptic Curve Cryptography)是非对称加密里的“后起之秀”,它基于“椭圆曲线离散对数”的数学难题,使用特定的曲线方程和基点生成公钥和私钥,子算法 ECDHE 用于密钥交换,ECDSA 用于数字签名。

比起 RSA,ECC 在安全强度和性能上都有明显的优势。160 位的 ECC 相当于 1024 位的 RSA,而 224 位的 ECC 则相当于 2048 位的 RSA。因为密钥短,所以相应的计算量、消耗的内存和带宽也就少,加密解密的性能就上去了,对于现在的移动互联网非常有吸引力。

现在我们为了机密性从对称加密到非对称加密,而非对称加密还解决了密钥交换不安全的问题。那么是否可以直接使用非对称加密来实现机密性呢?

答案是否定的!

因为非对称加密运算速度比较慢。所以需要两者结合,混合模式实现机密性问题,同时又有很好的性能。

加密流程如下所示:

  1. 先创建一个随机数的对称加密密钥,会话密钥(session key);

  2. 使用会话密钥加密需要传输的明文消息,因为对称加密性能较好,接着再使用非对称加密的公钥对会话密钥加密,因为会话密钥很短,通常只有 16 字节或 32 字节,所以加密也不会太慢。这里主要就是解决了非对称加密的性能问题,同时实现了会话密钥的机密交换。

  3. 另一方接收到密文后使用非对称加密的私钥解密出上一步加密的 会话密钥,接着使用会话密钥解密出加密的消息明文。

混合加密

总结一下就是使用非对称加密算法来加密会话密钥,使用对称加密算法来加密消息明文,接收方则使用非对称加密算法的私钥解密出会话密钥,再利用会话密钥解密消息密文。

这样混合加密就解决了对称加密算法的密钥交换问题,而且安全和性能兼顾,完美地实现了机密性。

后面还有完整性、身份认证、不可否认等特性没有实现,所以现在的通信还不是绝对安全。

摘要算法与完整性

摘要算法的主要目的就是实现完整性,通过常见的散列函数、哈希函数实现。

我们可以简单理解成这事一种特殊的压缩算法,将任意长度的明文数据处理成固定长度、又是独一无二的“摘要”字符串,就是该数据的指纹。

同时摘要算法是单向加密算法,没有密钥,加密后的数据也无法解密,也就是不能从“摘要”推导出明文。

比如我们听过或者用过的 MD5(Message-Digest 5)、SHA-1(Secure Hash Algorithm 1),它们就是最常用的两个摘要算法,能够生成 16 字节和 20 字节长度的数字摘要。

完整性实现

有了摘要算法生成的数字摘要,那么我们只需要在明文数据附上对应的摘要,就能保证数据的完整性。

但是由于摘要算法不具有机密性,不能明文传输,否则黑客可以修改消息后把摘要也一起改了,网站还是鉴别不出完整性。

所以完整性还是要建立在机密性上,我们结合之前提到的混合加密使用 ”会话密钥“ 加密明文消息 + 摘要,这样的话黑客也就无法得到明文,无法做修改了。这里有个专业术语叫“哈希消息认证码(HMAC)”。哈希消息认证码(HMAC)

比如诸葛亮使用上面提到的混合加密过程给关二爷发消息:“明天攻城” + “SHA-2 摘要”,关二爷收到后使用密钥将解密出来的会话密钥解密出明文消息,同时对明文消息使用解密出来的摘要算法进行摘要计算,接着比对两份“摘要”字符串是否一致,如果一致就说明消息完整可信,没有被敌军修改过。

消息被修改是很危险的,要以史为鉴,比如赵高与李斯伪造遗诏,直接把扶苏给送西天了,这太可怕了。

总结下就是通过摘要比对防止篡改,同时利用混合加密实现密文与摘要的安全传输。

数字签名和 CA

到这里已经很安全了,但是还是有漏洞,就是通信的两头。黑客可以伪装成网站来窃取信息。而反过来,他也可以伪装成你,向网站发送支付、转账等消息,网站没有办法确认你的身份,钱可能就这么被偷走了。

现在如何实现身份认证呢?

现实生活中,解决身份认证的手段是签名和印章,只要在纸上写下签名或者盖个章,就能够证明这份文件确实是由本人而不是其他人发出的。

非对称加密依然可以解决此问题,只不过跟之前反过来用,使用私钥再加上摘要算法,就能够实现“数字签名”,同时实现“身份认证”和“不可否认”。

就是把公钥私钥的用法反过来,之前是公钥加密、私钥解密,现在是私钥加密、公钥解密。但又因为非对称加密效率太低,所以私钥只加密原文的摘要,这样运算量就小的多,而且得到的数字签名也很小,方便保管和传输。

重点就是使用非对称加密的“私钥”加密原文的摘要,对方则使用非对称加密的公钥解密出摘要,再比对解密出的原文通过摘要算法计算摘要与解密出的摘要比对是否一致。这样就能像签署文件一样证明消息确实是你发送的。签名验签

只要你和网站互相交换公钥,就可以用“签名”和“验签”来确认消息的真实性,因为私钥保密,黑客不能伪造签名,就能够保证通信双方的身份。

CA

到这里似乎已经大功告成,可惜还不是。

综合使用对称加密、非对称加密和摘要算法,我们已经实现了安全的四大特性,是不是已经完美了呢?

不是的,这里还有一个“公钥的信任”问题。因为谁都可以发布公钥,我们还缺少防止黑客伪造公钥的手段,也就是说,怎么来判断这个公钥就是你或者张三丰的公钥呢?

这个“第三方”就是我们常说的CA(Certificate Authority,证书认证机构)。它就像网络世界里的公安局、教育部、公证中心,具有极高的可信度,由它来给各个公钥签名,用自身的信誉来保证公钥无法伪造,是可信的。

CA 对公钥的签名认证也是有格式的,不是简单地把公钥绑定在持有者身份上就完事了,还要包含序列号、用途、颁发者、有效时间等等,把这些打成一个包再签名,完整地证明公钥关联的各种信息,形成“数字证书”(Certificate)。

OpenSSL

它是一个著名的开源密码学程序库和工具包,几乎支持所有公开的加密算法和协议,已经成为了事实上的标准,许多应用软件都会使用它作为底层库来实现 TLS 功能,包括常用的 Web 服务器 Apache、Nginx 等。

由于 OpenSSL 是开源的,所以它还有一些代码分支,比如 Google 的 BoringSSL、OpenBSD 的 LibreSSL,这些分支在 OpenSSL 的基础上删除了一些老旧代码,也增加了一些新特性,虽然背后有“大金主”,但离取代 OpenSSL 还差得很远。

总结下就是:OpenSSL 是著名的开源密码学工具包,是 SSL/TLS 的具体实现。

迁移 HTTPS 必要性

如果你做移动应用开发的话,那么就一定知道,Apple、Android、某信等开发平台在 2017 年就相继发出通知,要求所有的应用必须使用 HTTPS 连接,禁止不安全的 HTTP。

在台式机上,主流的浏览器 Chrome、Firefox 等也早就开始“强推”HTTPS,把 HTTP 站点打上“不安全”的标签,给用户以“心理压力”。

Google 等搜索巨头还利用自身的“话语权”优势,降低 HTTP 站点的排名,而给 HTTPS 更大的权重,力图让网民只访问到 HTTPS 网站。

这些手段都逐渐“挤压”了纯明文 HTTP 的生存空间,“迁移到 HTTPS”已经不是“要不要做”的问题,而是“要怎么做”的问题了。HTTPS 的大潮无法阻挡,如果还是死守着 HTTP,那么无疑会被冲刷到互联网的角落里。

顾虑

阻碍 HTTPS 实施的因素还有一些这样、那样的顾虑,我总结出了三个比较流行的观点:“慢、贵、难”。

而“慢”则是惯性思维,拿以前的数据来评估 HTTPS 的性能,认为 HTTPS 会增加服务器的成本,增加客户端的时延,影响用户体验。

其实现在服务器和客户端的运算能力都已经有了很大的提升,性能方面完全没有担心的必要,而且还可以应用很多的优化解决方案

所谓“贵”,主要是指证书申请和维护的成本太高,网站难以承担。

这也属于惯性思维,在早几年的确是个问题,向 CA 申请证书的过程不仅麻烦,而且价格昂贵,每年要交几千甚至几万元。

但现在就不一样了,为了推广 HTTPS,很多云服务厂商都提供了一键申请、价格低廉的证书,而且还出现了专门颁发免费证书的 CA,其中最著名的就是“Let’s Encrypt”。

所谓的“难”,是指 HTTPS 涉及的知识点太多、太复杂,有一定的技术门槛,不能很快上手。

总结

从什么是安全我们延展出 HTTPS,解释了什么是 HTTPS,以及与 HTTP 的区别。HTTPS 主要就是通过 SSL/TLS 实现安全,而安全我们又接触了什么是对称加密与非对称加密,非对称加密性能较弱,所以我们使用非对称加密来加密对称加密的“会话密钥”,利用会话密钥加密明文解决了性能问题。

通过混合加密实现了机密性,利用摘要算法实现了完整性,通过数字签名使用非对称加密的“私钥”加密原文的摘要,对方则使用非对称加密的公钥解密出摘要,再比对解密出的原文通过摘要算法计算摘要与解密出的摘要比对是否一致实现了身份认证与不可否认。

转载于公众号“码个蛋”