目录
  1. 1. 当你访问网站时,会发生什么?
  2. 2. 密码学的武器
  3. 3. 尝试设计个安全的网页访问协议
    1. 3.1. 简单加密
    2. 3.2. 双重加密
    3. 3.3. 数字证书
    4. 3.4. HTTPS协议握手过程
  4. 4. SSL协议简介
  5. 5. 如何获得SSL证书
看完你还不懂HTTPS,那就......再看一遍好了

不知道从什么时候开始,浏览器的地址栏开始出现了绿色的小锁

有绿色小锁的网站,网址会变成https开头,鼠标点击还会提示网站的身份验证信息

没有绿色小说的网站,浏览器直接提示:“您与此网站之间建立的连接不安全”

到底什么是https?怎么实现更加安全的呢?

当你访问网站时,会发生什么?

通俗的理解,我们用来上网的电脑即为客户端

能打开网站,说明网站的服务器将相关信息传给了客户端

而实现这个过程就离不开http协议

没错,这是常见网址的开头http://

http出现在互联网发展之初,当时的主要目标是实现可靠的通信

想象下两个人打电话,为了确保通话质量,你接起电话的第一句话是:

喂?

是的,开始的时候,两个人会互相用喂来确认线路的通畅

结束的时候,又会用拜拜或者再见表示通话的结束

原始的http协议也非常简单,采用了类似电话的四步流程:

  1. 客户端和服务器建立连接

  2. 客户端向服务器提出请求

  3. 服务器接受请求,并根据请求返回相应的文件作为应答

  4. 客户与服务器关闭连接

大家最为熟悉的404页面,就出现在第3步,尽管客户端和服务器可以建立连接,但是服务器并没有找到客户端所需要的页面

可以说,当年的http协议,为了实现可靠通信就已经用尽全力了,哪里还有精力考虑安全呢?

而这带来致命的问题:

HTTP的连接、请求和返回信息均是明文传输

1
2
3
4
5
6
7
8
9
10
11
HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
...
<html>
<head>
<title>An Example Page</title>
</head>
<body>
Hello World, this is a very simple HTML document.
</body>
</html>

如上是服务器给客户端返回的http报文样例,网页标题、内容等等信息全部可以看到

只要有个黑客在网络上侦听,就可以获得客户端向服务器提交的用户名、银行卡号、身份证号等相关信息,以及服务器返回的全部页面信息

这是一件多么可怕的事情呀!

当然,准确的说,访问网站是个非常复杂的过程

如果你想打破砂锅问到底,可以详细参考这篇文章

但更多的技术细节并不会影响上面的结论:

HTTP这东西,就和安全没啥关系!

密码学的武器

网络是本质是一条电子高速公路

只要是公路,就是公开的,无法阻止黑客在路上观察车辆

所以,解决安全问题,只能依托于加密

现在当我们把目光投向和网络同步发展的密码学。

在现代密码学中,主要有两类算法:对称和非对称加密

所谓对称的概念,是针对加密和解密是否使用相同的秘钥

对称加密中,只有1个秘钥k——
发送方使用秘钥k加密内容,接收方也使用秘钥k对内容进行解密

这种加密方式比较符合对密码的直观感知,常见的算法有DES、3DES、RC5,IDEA

优点很多:算法公开、计算量小、加密速度快、加密效率高

缺点也很明显,只有一个密钥k,公开即破功,发送方和接收方如何确保k的安全传递,是个大问题

非对称密码就厉害了,有两个秘钥,分别叫公钥PK和私钥CK——
发送方使用接收方的公钥PK加密内容,接收方使用私钥CK对内容进行解密

常用的非对称密码有RSA、Elgama、ECC(椭圆曲线加密算法)

或许直观上感觉,设计两个密码是脱裤子放屁,仔细一样,其实不然

对接收方来说:自己的公钥PK完全可以公开,任何人都可以用它加密内容,只有自己拥有私钥CK,可以解密,其他人截获信息也无用,这样就实现了安全保密的功能

对发送方来说:先行将内容用自己的私钥CK加密,任何人都可以用公钥PK解密,因为只有发送方拥有私钥CK,可以正确解密就代表内容一定来源于发送方,这就实现了类似数字签名的效果

非对称加密这么好,是不是没有缺点了呢?

非也?速度慢——比起对称加密算法,要慢数千倍

粗略的换算一下,用DES算法1s就可以完成的加密工作,RSA要执行1个小时

因此,现代密码学上,通常用非对称加密传递对称加密的密钥,实现了安全和效率的兼顾

尝试设计个安全的网页访问协议

既然有了加密的武器,我们就开始吧!

简单加密

最朴素的想法,自然是加密客户端和服务器之间的所有消息交互

我们就先使用最简单的对称加密算法,扩展http协议如下:

  1. 客户端和服务器建立连接

  2. 客户端使用密钥k加密请求,提交服务器

  3. 服务器使用密钥k解密,将请求的文件使用密钥k加密后返回客户端

  4. 客户端与服务器关闭连接

emmm,看起来是个完美的解决方案

客户端和服务器之间均为安全传输,有了现代密码学的基石,只要不知道密钥k,在有效时间无法破解

可是,问题就出在这个密钥k上——

服务器也不知道密钥k!

更重要的是,服务器也不能对所有的客户端都使用一个密钥k

所以当客户端的数量几何级增长,这么多不同密钥k,服务器无从得知

双重加密

既然问题出在密钥k上,我们就来解决一下

刚才已经提到了非对称算法,可以在一个密钥公开的场景下实现加密

因为非对称算法的加密效率较低,我们可以用它来加密传输对称算法密钥k,后续的传输由对称算法接管

那么我们应用如下:

  1. 客户端发起与服务器的连接,获取服务器的公钥PK

  2. 客户端生成对称密钥k,并使用服务器的公钥PK加密后告知服务器

  3. 服务器使用私钥CK解密后获得密钥k,反馈客户端

  4. 客户端使用密钥k加密请求,提交服务器

  5. 服务器使用密钥k解密,将请求的文件使用密钥k加密后返回客户端

  6. 客户端与服务器关闭连接

感谢非对称加密算法,事情看起来得到了有效解决!

毕竟,核心的密钥k在服务器公钥的加密保护下,只有服务器可以解开。

可是,你高兴的太早了!

互联网上的黑客可不是善茬,中间人攻击了解一下—

黑客伪装成服务器,给客户端返回虚假的公钥PK’,就可以让客户端傻傻的交出关键的密钥k

然后再伪装成客户端,获取服务器的公钥PK,将关键密钥k加密提交服务器,就可以继续后面的连接

在通信过程中,客户端和服务器之间的所有交互,全部被黑客尽收眼底

还是密钥k出了问题吗?

不对,问题应该出现在客户端不该轻信中间人返回的公钥PK’

数字证书

既然中间人返回的公钥不一定可信

索性让客户端提前存储所有网站的公钥好了

理想很丰满,现实很骨感

2019年全国网站519万个,谁的公钥可信呢?

再说了,网站随时会有新设,本地的浏览器或者操作系统也得频繁升级获取公钥吗?

这时候,我们就需要引入可信的第三方CA机构了——

我们认为有些机构是可信的,机构的数量是一定的,有数据表明,2017年全中国也就37家

于是在浏览器里内置机构的根证书,就可以实现了

网站向第三方CA机构申请数字证书,客户端可以借助内置的根证书验证网站的身份,再也不会随便轻易阿猫阿狗的返回公钥了——

  1. 客户端发起与服务器的连接,获取服务器数字证书(内含公钥PK)

  2. 客户端使用本地的根证书验证服务器返回的数字证书,验证服务器身份

  3. 客户端生成对称密钥k,并使用服务器的公钥PK加密后告知服务器

  4. 服务器使用私钥CK解密后获得密钥k,反馈客户端

  5. 客户端使用密钥k加密请求,提交服务器

  6. 服务器使用密钥k解密,将请求的文件使用密钥k加密后返回客户端

  7. 客户端与服务器关闭连接

而这,就已经是HTTPS协议的简化版本了

还有什么地方可以进一步加强安全的呢?

客户端生成对称密钥k,似乎过于随意

受技术能力所限,计算机所谓的随机生成,其实都是伪随机,有规律可寻

HTTPS协议握手过程

既然一方的随机数存在伪随机风险,那么可以将客户端和服务器的随机数组合起来生成密钥k

到这一步,我们就可以把HTTPS的握手过程设计出来了——

1.客户端向服务器发送随机数、自己支持的加密算法

2.服务器返回随机数、选择的加密算法、自己的数字证书

3.客户端验证服务器的数字证书,验证成功后用两个随机数和服务器选择的加密算法,生成密钥k,通知服务器握手完成

4.服务器也使用两个随机数和服务器选择的加密算法,生成密钥k,返回客户端握手完成

5.后续服务器和客户端将使用密钥k实现加密通信

SSL协议简介

上述的HTTPS握手协议,其实是基于SSL协议实现的

SSL(Secure Sockets Layer 安全套接层)和继任者传输层安全(Transport Layer Security,TLS)是为网络通信提供安全及数据完整性的一种安全协议

TLS与SSL在传输层与应用层之间对网络连接进行加密

SSL协议提供的安全通道有以下三个特性:

  • 机密性:SSL协议使用密钥加密通信数据

  • 可靠性:服务器和客户都会被认证,客户的认证是可选的

  • 完整性:SSL协议会对传送的数据进行完整性检查

这些特性都是依靠SSL协议的不同子协议实现的——

  • SSL握手协议层:用于SSL管理信息的交换,允许应用协议传送数据之间相互验证,协商加密算法和生成密钥等
    • SSL握手协议
    • SSL密码参数修改协议
    • 应用数据协议
    • SSL告警协议
  • SSL记录协议层:为高层协议提供基本的安全服务

SSL不光和HTTP结合,获得HTTPS安全的网页传输协议,还可以为FTP协议服务,实现安全的文件传输FTPS

更多SSL协议的介绍参见SSL协议

如何获得SSL证书

前面已经提到,支持https的网站,都需要找可信的第三方申请数字证书,也就是通俗所称的SSL证书

SSL证书分为三类:

  1. DV SSL证书:域名验证型SSL证书,验证了域名所有权信息即可颁发,安全等级较低

  2. OV SSL证书:机构验证型的SSL证书,验证企业身份信息后颁发

  3. EV SSL证书:扩展验证型的SSL证书,目前安全等级最高的证书,在验证审核当中也是最为严格

在百度网页的SSL证书中,就明确了企业级的使用者

对于个人用户来说,检验域名的所有权信息,即可获得入门级的DV SSL证书

天下没有免费的午餐,证书的颁发机构也不是做慈善的

在腾讯云的SSL证书购买页面上,Symantec公司提供的企业型的单域名证书,都需要4250元一年

对个人用户来说,最优解肯定是选择免费版了——

TrustAsia公司提供的DV证书,可以免费使用一年,一年之后就得看还有没有优惠活动,可以通过腾讯云链接购买

宝塔面板提供了Let’s Encrypt证书,免费3个月,给力的是到期后可以自动续期,完全不用个人操心,直接配置即可

申请的证书有什么内容呢?

我们解压一个TrustAsia公司提供的DV证书

csr文件即是TrustAsia公司给我们的证书

使用的时候,主要是需要数字证书公钥PK私钥CK,根据服务器软件的不同,提供在不同的文件夹里

对Nginx来说:

第1个文件:需要返回给客户端的数字证书(包含公钥PK)

第2个文件:即是私钥CK(千万要保密!)

文章作者: 西门吹风
文章链接: http://blog.fight365.cn/2019/12/11/看完你还不懂HTTPS,那就......再看一遍好了/
版权声明: 本博客所有文字除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 我的足迹 | 铁匠铺
本博客所有图片除特别声明外,均引用网络链接,如侵犯您的权益,请留言声明,我们将在第一时间删除

评论