闲聊HTTPS

相关文章:

闲聊HTTP
闲聊HTTP/2.0
闲聊HTTPS
HTTP缓存机制的Etag、Last-Modified、If-None-Match和If-Modified-Since、Expires和Cache-Control笔记
转载的深度好文:一个 TCP 连接上面能发多少个 HTTP 请求

转载文章:全面了解HTTP和HTTPS(开发人员必备)

目录

HTTPS:

前言:

加密和哈希(encryption and hashing):

证书的原理以及所提供的安全性:

TLS加密连接流程:

关于SSL的书上介绍:

网站的资源它们也通过 HTTPS 呈现吗?


HTTPS:

前言:

你有没有想过,在咖啡厅或类似的公共场合,使用免费 Wi-Fi 多么的傻?你信任店主没有做出什么狡猾的事,并且相信当前正在使用Wi-Fi 热点的人不是坏人?他们不仅能监听你的网络操作,你毕竟是通过无线电波进行广播,而且他们能够篡改你所接收的数据,这是一个无害的更改。但是如果你想通过公共 Wi-Fi,查看你的银行账户呢?想想有很多人都能够读取或更改你的数据,我们肯定不希望发生这种事。

HTTPS 可以保护你和你的用户免遭恶意咖啡店主及访问者的攻击,作为网络开发者 HTTPS 甚至更重要,因为所有现代浏览器 API仅支持通过 HTTPS 加密的网站要充分利用网络的强大功能,网页使用了 HTTPS可以让用户在这些公共场合对你的网页放心。

如何判断网站是否使用了 HTTPS?网站是否正确使用了 HTTPS?以及如何在你自己的网站上使用 HTTPS?

我们知道 HTTP 很容易读懂,甚至普通人都能读懂,这很让人头疼。你几乎可以在控制台上实时查看发送的请求,并且依然理解所发生的情况。如果有人能够以某种方式偷听开放的 HTTP 连接,偷听者将能够阅读所有的请求和响应并提取所需的所有数据。那么偷听连接有多容易呢?Wi-Fi 使偷听过程更加容易,因为你直接通过无线电波广播连接,因此偷听者只需偷听即可,如果有特殊的监听软件,偷听起来更简单,加密 Wi-Fi 有所帮助,但是你无法控制咖啡厅的 Wi-Fi 设置。以前的加密方法很容易破解,因此 HTTPS 推出了加密功能,它将使浏览器加密请求,只有你要连接的服务器能够解密这些请求,咖啡厅的店主或恶意偷听者都无法阅读你的数据流。
但是如果你以为你连接到了正确的服务器而实际上没有呢?在中间人攻击(简称 MITM)中,攻击者在你和要连接的服务器之间扮演着中间人的角色,发生这种情况时,浏览器将以加密的方式连接到他们的服务器,而不是你尝试连接的服务器。攻击者将解密你的数据,阅读你的所有私密信息,重新加密这些信息 然后将信息传达给你想连接的服务器,反之亦然。你和服务器都不知道中间有个攻击者,为了解决这个问题,除了加密功能之外,HTTPS 还推出了验证功能,服务器需要标识自己的身份,只有真正的服务器才能标识自己。因此你能够确定你与之通信的服务器是正确的服务器。

当我们提到 HTTPS 时,实际上说的是两个不同的概念,HTTP 和 TLS(之前称为 SSL)。TLS 是传输层安全协议的简称,TLS 并非只针对 HTTP,它可以用于任何协议,例如,FTPS 它由 FTP 和 TLS 构成,用于安全地传输文件,TLS 对通信进行特殊加密,使得目标接收者之外的任何人都无法读取数据。在现实中,我们根本无法破解 TLS 加密。为了确保通信的服务器是你要通信的服务器,TLS 会用到信任链这一功能。服务器通过证书来标识自己的身份,该证书中包含关于服务器本身以及加密密钥指纹的元数据。这些证书由证书授权机构颁发,证书授权机构有很多,当证书由此类授权机构签名了,那么如果你要使用的密钥与该指纹匹配,你就会知道与之通信的服务器是正确的服务器。实际上,你可以在浏览器中查找证书授权机构列表,甚至可以添加你自己的授权机构,你在这里看到的大多数是能够从对方那购买证书的公司,它们需要支付费用,因为它们不仅会验证你的服务器,而且会验证你作为该服务器的所有者的身份,因为并非所有开发者都能够或想要支付证书费用以便向用户提供基本的安全性,因此 Let's Encrypt 应运而生,它可以免费提供证书。

加密和哈希(encryption and hashing):

TLS 有两个重要的密码构建组件,分别为加密和哈希(encryption and hashing)。
加密分为对称加密和非对称加密(公钥加密)。
对称加密:加密一些数据并将加密的数据提供给其他人,接收者需要使用相同的密钥来解密收到的数据,否则无法查看数据。

非对称加密(公钥加密):浏览器能够利用加密算法,使用一个密钥进行加密并使用另一个密钥进行解密。通常,加密消息的密钥已经公开,任何想要发送消息的人都可以使用该密钥加密,任何其他人都无法使用同一密钥解密消息,只有拥有解密密钥的你能够解密消息。通过后台的数学算法,两个密钥都可以用来加密和解密,用一个密钥加密后,只能用另一个密钥解密。因此可以说有一个任何人都可以访问的公钥,以及一个只有所有者可以访问的私钥,私钥需要安全地存储。

哈希:是将数据转换为原始数据的简短表示的过程。原始数据的小小改动将在哈希中有巨大的变化,如果两个文档的哈希值一样,那么它们非常有可能是同一文档。对于哈希函数,我们需要知道的是,一般无法颠倒转换流程,表示数据一旦转换为哈希则无法再恢复成原始数据,一般无法找到生成完全一样的哈希值的另一个文档。

Hash算法特别的地方在于它是一种单向算法用户可以通过Hash算法对目标信息生成一段特定长度的唯一的Hash值,却不能通过这个Hash值重新获得目标信息。因此Hash算法常用在不可还原的密码存储、信息完整性校验等。

常见的Hash算法:MD2、MD4、MD5、HAVAL、SHA、SHA-1、HMAC、HMAC-MD5、HMAC-SHA1。
这几种算法只生成一串不可逆的密文,经常用其效验数据传输过程中是否经过修改,因为相同的生成算法对于同一明文只会生成唯一的密文,若相同算法生成的密文不同,则证明传输数据进行过了修改。通常在数据传说过程前,使用MD5和SHA1算法均需要发送和接收数据双方在数据传送之前就知道密匙生成算法,而HMAC与之不同的是需要生成一个密匙,发送方用此密匙对数据进行摘要处理(生成密文),接收方再利用此密匙对接收到的数据进行摘要处理,再判断生成的密文是否相同。

最常见的哈希函数是 SHA,它有多个版本,例如SHA-256或SHA-512,后面的数字表示哈希的输出有多大(单位是位),无论文档多大,当你使用SHA-256时,输出将始终为 256 位。
 

证书的原理以及所提供的安全性:

现在来讨论下签名,之前提到了证书授权机构,它们的任务是对证书签名,是什么意思呢?为何有人需要签名的证书?

当我们提到有人签名了文档,我们指的是证书授权机构已经审查并验证该文档中的内容,目的是证明该实体已查看甚至创建该文档,就像在文件上签名,证明你已经看过该文件的法律证据,服务器也可以通过电子签名来证明。服务器对文档签名并使用它们的私钥加密文档,然后返回签名的文档,只有私钥的持有者能够解密文档。
文档可能会很庞大,例如DVD影像,使用非对称密码加密和解密需要很长的时间,因此只加密文档的哈希而不是整个文档本身,生成了摘要。如果你想检测签名是否有效,可以解密签名并自己对文档进行哈希转换(生成摘要),看看这两个值(摘要)是否匹配,这样我们就知道所接收的文档与服务器发送是否完全一样。如果文档在传输中被更改了,则哈希与服务器作为签名提供的值(摘要)不匹配,这叫做无效签名

TLS加密连接流程:

为了简单起见,忽略一些复杂的细节,但是不会对概念有影响。
第一步,让服务器向你发送证书,证书中包含服务器的公钥以及其他一些信息,例如证书的目标网域以及证书授权机构的签名。第二步,客户端检查网域是否正确,并检查授权机构的签名是否有效。正如之前讨论的,所有浏览器都在本地具有证书授权机构列表,包括它们的公钥,因此不用检查签名是否有效

第三步,客户端生成一个对称加密随机密钥,并一直使用下去,浏览器使用服务器的公钥对随机密钥进行加密并发送出去。

这样做有两个好处:

1.与非对称加密相比,对称加密速度快了很多并且更加高效,能够更好地扩展到大型数据。

2.但是更重要的是,只有真的服务器拥有私钥并且能够解密出随机密钥,才能接着继续通信,这样就可以验证服务器的身份

如果所有这些步骤都成功了,最后的连接建立成功。HTTP 协议能够接管任务,此时,你将在浏览器的网址栏中获得绿色挂锁符号。

在上个场景中只有两个地方可以出错,要么是证书授权机构在证书上的签名无效,要么是服务器在切换到对称加密后无法通信。在现实中,出错的地方有很多,证书有一个截止期限,因此可能会过期。证书规定了哈希集合和支持的对称加密函数。这几年事实证明,某些加密函数比较薄弱,有时候证书有效但是服务器的其他设置无效。
https://badssl.com/上可以查看TLS 连接有问题时浏览器的行为,badssl.com 具有自己的有效证书,但是也具有故意无效的证书和无效的设置,因此我们能够了解在不同情形下浏览器的行为我们来看看 sha1-2016,绿色锁不见了,浏览器显示如下:


点击此连接后可以看到被使用的证书的具体详情,请使用 badssl.com 网站,判断哪些设置导致 Chrome 拒绝访问网站。
过期证书会发生这种情况吗?(会)

另一个主机的证书呢?(会)

混合内容会导致拒绝访问网站吗?(不会)

我们来试试,每个链接的背景色差不多就表明了会发生的情况。红色表示不可行,绿色表示可行,灰色表示结果可疑。
过期证书或主机错误的证书都拒绝访问

混合内容信任链不完整和 SHA256都允许用户访问,但是并非都会出现绿色锁

以下可行:

关于SSL的书上介绍:

网站的资源它们也通过 HTTPS 呈现吗?

不一定,但是建议通过HTTPS呈现,失去绿色锁的快速方式是通过普通的 HTTP 呈现资源,发生这种情况时,网站就会进入混合内容状态,当你打开一个本应通过 HTTPS 呈现,但是其中包含来自非 TLS 加密来源的资源(例如图片 iframe 样式表或脚本)的网站时就会出现混合内容。如下图:


一个常见错误是从非TLS CDN获取 jQuery,通过非安全渠道传输的资源类型不同导致的后果可能有所不同,可能会失去绿色挂锁,但是依然可以运行,资源可能被屏蔽或使网页崩溃甚至可能会出现红色挂锁,不同浏览器的行为不尽相同,因此你肯定需要避免这种情况。检查网站是否有混合内容,实际上 Google 建议通过 HTTPS呈现所有资源,这样才能够避免混合内容警告,你的网站和其中的资源才会安全地传输。

大部分托管服务和 CDN 现在都支持 TLS,越来越多的浏览器API仅支持 HTTPS 网站,你应该为了你的用户和你的网站始终使用 HTTPS。

===============Talk is cheap, show me the code================

发布了209 篇原创文章 · 获赞 344 · 访问量 89万+

猜你喜欢

转载自blog.csdn.net/qq_34115899/article/details/86249037