HTTPS虐我千百遍,我却待她如初恋!

本篇将讨论 HTTPS 的加解密原理,很多人都知道 RSA,以为 HTTPS=RSA,使用 RSA 加解密数据,实际上这是不对的。

HTTPS 是使用 RSA 进行身份验证和交换密钥,然后再使用交换的密钥进行加解密数据。

身份验证是使用 RSA 的非对称加密,而数据传输是双方使用相同的密钥进行的对称加密。那么,什么是对称加密和非对称加密?

对称加密和非对称加密

假设隔壁小王想要约小红出来,但是他不想让小明知道,于是他想用对称加密给小红传了个小纸条。如下图所示:

他想发送的数据是”Meet at 5:00 PM”(5 点见面,如果是中文的话可以使用 UTF-8 编码),加密方式是直接在 ASCII 表进行左移或右移。

他的密钥是 3,表示在 ASCII 表往后移 3 位,就会变成”Phhw#dw#8=33#SP”,这样一般人如果截获了不知道是什么意思的。

但是我们可以想一下,如果既然他可以截获你的数据,自然也可以截获你的密钥,进而进行解密。如下图所示:

所以小王打算用非对称加密,非对称加密的特点是双方都有自己的公钥和私钥对,其中公钥发给对方,密钥不交换自己保管不泄漏。如下图所示:

其中小红的公钥为:

public_key = (N, e) = (3233, 17)

她把公钥发给了小明,她自己的私钥为:

private_key = (N, e) = (3233, 2753)

这里注意公钥和私钥都是两个数,N 通常是一个大整数,e 表示一个幂指数。现在小王想给小红发消息,于是他用小红的公钥进行加密,怎么加密呢?

他要发送的第一个字母为 t=“M”,“M”的 ASCII 编码为 77,77 的加密过程如下计算:

T = 77 ^ e  % N = 77 ^ 17 % 3233 = 3123

把 77 做 e 次幂然后模以 N,便得到了 T=3123,然后把这个数发给小红(其他字母按同样方式处理)。

小红收到 T 之后便用她的私钥进行解密,计算如下:

t = T ^ e % N = 3123 ^ 2753 % 3233 = 77

计算方法是一样的,这样便把 T 还原成了 t,只要公私钥配对,便可通过一些数学公式证明上面的推算是成立的。这个就是 RSA 的加解密原理,如果无法知道私钥便无法进行正确解密。反过来,使用私钥进行加密,公钥进行解密也是可行的。那么 HTTPS 是怎么利用 RSA 进行加解密的呢,我们从 HTTPS 连接建立过程说起。

HTTPS 连接建立过程

HTTPS 主要有以下作用:

  • 验证服务方身份,如我访问 google.com 的时候连的确实就是谷歌服务器
  • 防止数据被劫持,例如有些运营商会给 http 的页面插入广告
  • 防止敏感数据被窃取篡改等

正如 openssl 的注释所说,这是防止中间人攻击的唯一方法:

我们以 MDN(https://developer.mozilla.org)的网站为例,然后用 wireshark 抓包,观察 HTTPS 连接建立的过程。

如下图所示:

首先是 TCP 三次握手,然后客户端(浏览器)发起一个 HTTPS 连接建立请求,客户端先发一个 Client Hello 的包,然后服务端响应一个 Server Hello。接着再给客户端发送它的证书,然后双方经过密钥交换,最后使用交换的密钥加行加解密数据。

在 Client Hello 里面客户端会告知服务端自己当前的一些信息,如下图所示:

包括客户端要使用的 TLS 版本,支持的加密套装,要访问的域名,给服务端生成的一个随机数(Nonce)等。需要提前告知服务器想要访问的域名以便服务器发送相应的域名的证书过来,因为此时还没有发生 HTTP 请求。

服务端在 Server Hello 里面会做一些响应:

服务端选中的加密套装叫 TLSECDHERSAWITHAES128GCM_SHA256,这一串的意思是:

  • 密钥交换使用 ECDHE
  • 证书签名算法 RSA
  • 数据加密使用 AES 128 GCM
  • 签名校验使用 SHA256

接着服务给客户端发来了 4 个证书:

第一个证书的公用名(common name)就是我们当前访问的域名 developer.mozilla.org。如果公用名是 *.mozilla.org 的话那么这个证书便能给 mozilla.org 的所有二级子域名使用。

第二个证书是第一个证书的签发机构(CA)的证书,它是 Amazon,也就是说 Amazon 会用它的私钥给 developer.mozilla.org 进行签名。依此类推,第三个证书会给第二个证书签名,第四个证书会给第三个证书签名,并且我们可以看到第四个证书是一个根(Root)证书。

一个证书里面会有什么东西呢,我们可以展开第一个证书看一下,如下图所示:

证书包含三部分内容:

  • tbsCertificate(to be signed certificate)待签名证书内容
  • 证书签名算法
  • CA 给的签名

也就是说 CA 会用它的私钥对 tbsCertificate 进行签名,并放在签名部分。为什么证书要签名呢?签名是为了验证身份。

身份验证

我们先来看一下 tbsCertificate 里面有什么内容,如下图所示:

它里面包括了证书的公钥、证书的适用公用名、证书的有效期还有它的签发者等信息。

Amazon 的证书也具备上述结构,我们可以把 Amazon 证书的公钥拷出来,如下图所示:

中间有一些填充的数字,用灰色字表示。可以看到N通常是一个很大的整数(二进制 2048 位),而 e 通常为 65537。

然后我们用这个 CA 的公钥对 mozilla.org 的证书签名进行解密,方法和上面的类似:

取解密后的数字 decrypted 的十六进制的末 64 位,即为二进制 256 位的 SHA 哈希签名。

接下来我们手动计算一下 tbsCertificate 的 SHA256 哈希值,方法是在 wireshark 里面把 tbsCertificate 导出一个原始二进制文件:

然后再使用 openssl 计算它的哈希值,如下所示:

liyinchengs-MBP:https liyincheng$ openssl dgst -sha256 ~/tbsCertificate.binSHA256(/Users/liyincheng/tbsCertificate.bin)= 5e300091593a10b944051512d39114d56909dc9a504e55cfa2e2984a883a827d

我们发现手动计算的哈希值和加密后的证书里的哈希值一致!说明只有知道了 Amazon 私钥的人才能正确地对 mozilla.org 的证书签名,因为公私钥是唯一匹配的。
因此我们验证了第一个证书 mozilla.org 确实是由第二个证书 Amazon 签发的,使用同样的方式,我们可以验证 Amazon 是由第三个签发的,第三个是由第四个根证书签发。

并且第四个证书是根证书,它是内置于操作系统的(通过 Mac 的 keychain 工具可以查看):

假如 Hacker 通过 DNS 欺骗之类的方式把你访问的域名指向了他的机器,然后他再伪造一个证书。

但是由于根证书都是内置于操作系统的,所以它改不了签名的公钥,并且它没有正确的私钥,只能用自己的私钥,由于公私钥不配对,很难保证加解密后的信息一致。

或者直接把浏览器拿到的证书搬到他自己的服务器?这样再给浏览器发的证书便是一模一样,但是由于他不知道证书的私钥,所以无法进行后续的操作,因此这样是没有意义的。

这个就是 HTTPS 能够验证身份的原理。另外一个例子是 SSH,需要手动验证签名是否正确。

例如通过打电话或者发邮件等方式告知服务器的签名,与自己算的证书的签名是否一致,如果一致说明证书没有被篡改过(如证书的公钥没有被改为 Hacker 的公钥):

上面展示的便是自己手动计算的值,拿这个值和之前的值进行比较是否相等便可知发过来的证书是否被修改过。

那么,为什么不直接使用 RSA 的密钥对进行加密数据?因为 RSA 的密钥对数值太大,不太合适频繁地加解密数据,所以需要更小的密钥。

另一个原因是服务端没有浏览器或者客户端的密钥,无法向浏览器发送加密的数据(不能用自己的私钥加密,因为公钥是公开的)。所以需要进行密钥交换。

密钥交换

密钥交换的方式有两种:RSA 和 ECDHE,RSA 的方式比较简单,浏览器生成一把密钥,然后使用证书 RSA 的公钥进行加密发给服务端,服务再使用它的密钥进行解密得到密钥,这样就能够共享密钥了。

它的缺点是攻击者虽然在发送的过程中无法破解,但是如果它保存了所有加密的数据,等到证书到期没有被维护之类的原因导致私钥泄露,那么它就可以使用这把私钥去解密之前传送过的所有数据。

而使用 ECDHE 是一种更安全的密钥交换算法。如下图所示,双方通过 ECDHE 进行密钥交换:

ECDHE 的全称是 Elliptic Curve Diffie–Hellman key Exchange 椭圆曲线迪非-赫尔曼密钥交换,它是对迪非-赫尔曼密钥交换算法的改进。

这个算法的思想如下图所示:

为了得到共享秘钥 K,甲用它的私钥计算一个数 g^a,发送给乙,乙的私钥为 b,乙便得到 K= g^a^b,同时发送 g^b 给甲,甲也得到了 K=g^b^a。这个应该比较好理解,而引入椭圆曲线加密能够提高破解难度。

椭圆曲线加密

现在的证书的签名算法有两种:RSA 和新起的 EC。如下图所示,google.com 便是使用的 ECC 证书:

我们上面讨论的便是 RSA,破解 RSA 的难点在于无法对公钥的 N 进行质数分解。如果你能对证书的 N 拆成两个质数相乘,便可推算出证书的私钥,但是在当前的计算能力下是不可能的。而 ECC 的破解难点在于找到指定点的系数。

如下图所示,有一条椭圆曲线方程:

y ^ 3 = x ^ 2 + ax + b:

给定一个起点 G(x,y),现在要计算点 P=2G 的坐标,其过程是在 G 点上做一条线与曲线相切于 -2G,做 -2G 相对于 x 轴的反射便得到 2G 点。

为了计算 3G 的坐标,如下图所示:

连接 2G 与 G 与曲线相郊于 -3G,再做反射得到 3G,同理计算 4G 便是连接 G 与 3G 再做反射。如果最后一个点和起点的连线垂直于 x 轴,说明所有的点已用完。

EC 的难点在于给定起点 G 和点 K:

K = kG

想要得到 K(K 足够大)是一件很困难的事情。这个 K 便是私钥,而 K=kG 便是公钥。ECC 是怎么加解密数据的呢?假设要加密的数据为 m,把这个点当作x坐标得到在曲线上的一个点 M,取定一个随机数 r,计算点 C1=rG,C2=M+rK。

把这两个点便是加密后的数据,发给对方,对方收到后使用私钥 K 进行解密,过程如下:

M = C2 - rK = C2 - rkG = C2 - rkG = C2 - kC1

通过上面的计算便能还原得到 M,而不知道私钥 K 的人是无法解密的。更多细节可见 Medium 的这篇文章《ECC elliptic curve encryption》。这样我们便理解了 ECC 的原理,那么怎么利用 ECC 进行密钥交换呢?

ECC 密钥交换

原理很简单,如下图所示:

之前交换的是两个幂次方的数,现在变成交换两个曲线上的点。

而曲线方程是规定好的,例如 Curve X25519 使用的曲线方程为:

y^2 = x^3 + 486662x^2 + x

在密钥交换里面会指定所使用的曲线方程,如下图所示:

mozilla.org 所使用的曲线方程为 secp256r1,这个也是比较流行的一个,它的参数比 Curve X25519 大很多。
密钥交换也使用了证书的私钥进行签名,保证交换的密钥不会被人篡改,只是这里的私钥是 mozilla 自己的私钥。也就是说从连接建立到现在都是明文传输的。接下来双方发送 Change Cipher Spec 的包通知,接下来的包都按照之前约定好的方式进行加密。至此整个安全连接建立完毕。

HTTPS 证书的应用

那么是谁在做 HTTPS 加密呢?服务端通常是 Nginx、Apache 这些反向代理服务器做的,而具体的业务服务器不需要处理,客户端通常是浏览器等做的加解密,Chrome 是使用 boringSSL 这个库,fork 自 openssl。

我们通过 let’s encrypt 可以申请免费的 TLS 证书,每 3 个月需要手动续。

证书分为 3 种:DV、OV、EV,DV 适用于个人,OV 和 EV 需要身份审核,EV 最高端。

EV 证书会在浏览器的地址栏显示证书的企业名称:

但是新版的 Chrome 似乎把这个去掉了,所以我们打开 medium 的控制台可以看到一个提示:

As part of an experiment, Chrome temporarily shows only the lock icon in the address bar. Your SSL certificate with Extended Validation is still valid.

另外我们可以用 openssl 生成一个自签名证书,执行以下命令:

openssl req -x509 -nodes -sha256 -days 365 -newkey rsa:2048 -keyout test.com.key -out test.com.crt

便会得到两个文件,test.com.crt 是证书,test.com.key 是证书的私钥,如下图所示:

然后把这两个文件给 Nginx 使用便能使用 HTTPS 访问,如下代码所示:

    server {
        listen       443;
        server_name  test.com;
        ssl on;
        ssl_certificate    test.com.crt;
        ssl_certificate_key    test.com.key;
     }

可以把这个证书添加到系统证书里面,这样浏览器等便能信任,或者直接使用 mkcert 工具一步到位。

客户端证书

还有一种证书叫客户端证书,同样需要向 CA 机构申请一个客户端证书,和服务端 TLS 证书不一样的地方是,服务端证书通常是和域名绑定的,而客户端证书可以给本地的任意可执行文件进行签名。

签名验证算法和上文讨论的 TLS 证书一致。为什么可执行文件需要签名呢,因为如果不签名的话,系统会拦截安装或者运行,如 Mac 双击一个未签名的 dmg 包的提示:

直接不让你运行了,而 Windows 也有类似的提示,Windows 是会给一个警告:

而当我们运行一个已签名的 exe 文件将会是正常的提示,如 Chrome 的提示:

综上本文主要讨论了对称加密和非对称加密的原理,并介绍了如何利用 RSA 对证书签名的检验以验证连接服务器的身份,怎么利用 ECC 进行数据加密和密钥交换,介绍了下怎么生成和使用 HTTPS 证书,并介绍了下客户端证书。

相信看完本篇,会对 HTTPS 的加解密有一个较为全面的了解。

来源:http://suo.im/5lYNlh

Image placeholder
l135033303
未设置
  48人点赞

没有讨论,发表一下自己的看法吧

推荐文章
甜过初恋!浙大博士用200个西瓜130页论文,教你用机器学习科学挑瓜

大数据文摘出品作者:易琬玉刚刚送走了最热七月,转眼就迎来了最热八月。2019年是人类有气象纪录以来最热的几个年份之一,虽然这个夏天还没结束,但气象学家们已经有十足把握做出这个判断。为了应付热,人们想出

如何使网站支持https访问?nginx配置https证书

购买SSL证书要想使用https访问你的网址,首先得拥有颁发的SSL证书。我这里申请的是阿里云免费的,有效期为一年,过期后再重新申请。申请SSL证书购买后,可在阿里云的搜索框输入证书关键字进入到控制台

记录一次 LNMP 环境搭建到 Https 配置

之前一直习惯使用LAMP环境,更多的使用Apache去作为自己的服务器。今天折腾了一下LNMP,以及升级https,因为没什么含金量,仅作为我的一个记录笔记吧。 1.搭建了LNMP环境``` sudo

SpringBoot2.0 支持 https 访问

买了dapideng.com,自然要上https。 其实在之前的博客中,也早有提及配置证书的事儿,只不过这次变成了springboot,它内置了tomcat容器,和把项目打包放在tomcat下面不太一

https无法加载css js资源怎么办?

https无法加载cssjs资源怎么办?在https的网站中引用http路径的js或css会导致不起作用,其形如:解决办法:将http:去掉,改为浏览器默认是不允许在HTTPS里面引用HTTP资源的,

使用Certbot开启HTTPS访问(最新)

知乎地址友情链接 v-easy-components-基于Vue2.x的组件命令库 逸宿-一款预定民宿的webapp(毕设) 在线网易云API-基于NeteaseCloudMusicApi在线A

03.4. Go 的 http 包详解

前面小节介绍了Go怎么样实现了Web工作模式的一个流程,这一小节,我们将详细地解剖一下http包,看它到底是怎样实现整个过程的。 Go的http有两个核心功能:Conn、ServeMux Conn的g

ThinkPHP6 核心分析(一):Http 类的实例化

从入口文件出发 当访问一个ThinkPHP搭建的站点,框架最先是从入口文件开始的,然后才是应用初始化、路由解析、控制器调用和响应输出等操作。入口文件主要代码如下: //引入自动加载器,实现类的自动加载

Go 如何基于 IP 限制 HTTP 访问频率

如果你运行HTTP服务,并且希望限制HTTP的访问频率,那么你可以借助一些比较稳定的工具,例如:github.com/didip/tollbooth。不过如果你构建的应用比较简单,也可以自己来实现。

PHP 实现 HTTP 表单请求服务器

在今天的这一篇博文中,我们将继续深化这一知识,同时我们会用到HTTP协议的相关知识,借助PHP实现表单上传服务器,作为一个后台开发者,我们必须对这一块知识,有深入的理解,今天要讲的内容有些地方可能不

访问 laradock 服务器内部 http 服务器

在laradock中创建了一个http服务器之后,在workspace容器中,通curl127.0.0.1:9588,可以返回helloworld。但是在本地,通过浏览器访问127.0.0.1:958

基于Tcp协议与基于Http协议的RPC简介笔记

前言:之前对于RPC方面的学习多限于对RMI原理的学习,直到今天在看陈康贤前辈的《大型分布式网站架构-设计与实践》这本书的时候,才发现原来RPC可以基于TCP协议也可以基于HTTP协议(这里所说的TC

在 [slim] 中伪造 Request 来进行你的 HTTP 测试吧

代码需要做HTTP测试,Laravel中有自带这方面的功能。现在使用slim就得自己动手丰衣足食。 网上找了许多例子,关于这方便的比较少。然后就想到了查看Laravel的源码 看了一下,发现其实是自己

HTTP协议

什么是HTTP协议 http协议的工作过程 #url、域名 ![](https://cdn2.lmonkey.com/uploads/2019-12-19-06-33-535194) 常用协议

个人学习系列 - httpd的简单应用

想学习一下前端的代码,自然而然就希望能部署并观察一下自己写的烂代码了。所以,就研究一下httpd这个工具了。httpd的使用docker中的httpd的获取查询httpd的镜像并下载 查询httpd

TPC-C解析系列03_TPC-C基准测试之SQL优化

TPC-C是一个非常严苛的基准测试模型,考验的是一个完备的关系数据库系统全链路的能力。这也是为什么在TPC-C的榜单前列,出现的永远只是大家熟知的那几家在业界有着几十年积累、从关系数据库理论开始发展就

TPC-C解析系列05_TPC-C基准测试之存储优化

TPC-C规范要求被测数据库的性能(tpmC)与数据量成正比。TPC-C的基本数据单元是仓库(warehouse),每个仓库的数据量通常在70MB左右(与具体实现有关)。TPC-C规定每个仓库所获得的

TPC-C解析系列01_TPC-C benchmark测试介绍

作者:阳振坤2019.10导语:自从蚂蚁金服自研数据库OceanBase获得TPC-C测试第一名后,引起了行业内外大量关注,我们衷心的感谢大家对OceanBase的支持与厚爱,也虚心听取外界的意见和建

TPC-C解析系列02_OceanBase如何做TPC-C测试

导语:蚂蚁金服自研数据库OceanBase登顶TPC-C引起业内广泛关注,为了更清楚的展示其中的技术细节,我们特意邀请OceanBase核心研发人员对本次测试进行技术解读,共包括五篇:1)TPC-C基

TPC-C解析系列04_TPC-C基准测试之数据库事务引擎的挑战

OceanBase这次TPC-C测试与榜单上Oracle和DB2等其他数据库在硬件使用上有非常大的不同,OceanBase的数据库服务器使用的是204+3台型号是ecs.i2.16xlarge阿里云E

Python可视化 | Seaborn5分钟入门(二)——barplot&countplot&pointplot

微信公众号:「Python读财」如有问题或建议,请公众号留言Seaborn是基于matplotlib的Python可视化库。它提供了一个高级界面来绘制有吸引力的统计图形。Seaborn其实是在matp

基于JS的高性能Flutter动态化框架MXFlutter

导语:18年10月份,手机QQ看点团队尝试使用Flutter,做为iOS开发,一接触到Flutter就马上感受到,Flutter虽然强大,但不能像RN一样动态化是阻碍我们使用她的唯一障碍了。看Goog

innerHTML与jquery里的html()区别?

innerHTML与jquery里的html()区别?●html()可以设置tbody、tr这些只读标签,而innerHTML在低版本IE下不行;jQuery的html()做了些容错处理,原生的Dom

使用html-webpack-plugin对HTML文件进行预处理

一、前言先整理一波之前和webpack相关的文章: 使用Webpack对CSS文件进行后处理 基于Webpack的CSSSprites实现方案 Stylus系列——webpack-spritesmit