HTTPS协议是如何运作的

HTTPS只是标准的HTTP协议,只是多了SSL/TLS的加密优势。
除非出现可怕的错误(并且它可以),否则它会阻止攻击者查看或修改您浏览网页的请求; 它可以确保您的密码,通信和信用卡详细信息在计算机与您要将此数据发送到的服务器之间保持安全。

1.什么是HTTPS以及它的作用是什么?

HTTPS采用众所周知且理解的HTTP协议,并简单地在其上层叠SSL / TLS(以下简称为“SSL”)加密层。服务器和客户端仍然使用完全相同的HTTP,但通过安全的SSL连接来加密和解密其请求和响应。SSL层有两个主要目的:

  • 验证您是否正在直接与您认为正在与之通话的服务器通话
  • 确保只有服务器可以读取您发送的内容,并且只有您可以读取它发回的内容

真正非常聪明的部分是,任何人都可以拦截您与服务器交换的每一条消息,包括您同意使用密钥和加密策略的消息,但仍然无法从数据中读取任何实际信息。

2.如何建立SSL连接

通过握手建立客户端和服务器之间的SSL连接,其目标是:

  • 满足客户端正在与正确的服务器通信(反之亦然)
  • 对于各方已同意“密码套件”,其中包括他们将用于交换数据的加密算法
  • 对于各方已就此算法的任何必要密钥达成一致

建立连接后,双方可以使用约定的算法和密钥安全地相互发送消息。我们将把握手分为3个主要阶段 - Hello,Certificate Exchange和Key Exchange。

  1. Hello - 握手开始于客户端发送ClientHello消息。这包含服务器通过SSL连接到客户端所需的所有信息,包括各种密码套件和它支持的最大SSL版本。服务器使用ServerHello进行响应,ServerHello包含客户端所需的类似信息,包括基于客户端关于将使用哪个密码套件和SSL版本的首选项的决策。
  2. 证书交换 - 现在已建立联系,服务器必须向客户证明其身份。这是通过其SSL证书实现的,该证书与护照非常相似。SSL证书包含各种数据,包括所有者的名称,附加的属性(例如域),证书的公钥,数字签名以及有关证书有效日期的信息。客户端检查它是隐式信任证书,还是由其也隐含信任的多个证书颁发机构(CA)之一验证和信任。很快就会有更多这方面的内容。请注意,还允许服务器要求证书来证明客户端的身份,但这通常只发生在非常敏感的应用程序中。
  3. 密钥交换 - 客户端和服务器交换的实际消息数据的加密将使用对称算法完成,其确切性质已经在Hello阶段达成一致。与需要公钥/私钥对的非对称算法相比,对称算法使用单个密钥进行加密和解密。双方都需要就这个单一的对称密钥达成一致,这个密钥是使用非对称加密和服务器的公钥/私钥安全完成的。

客户端生成用于主对称算法的随机密钥。它使用在Hello阶段同意的算法和服务器的公钥(在其SSL证书上找到)对其进行加密。它将此加密密钥发送到服务器,使用服务器的私钥对其进行解密,并完成握手的有趣部分。双方都非常高兴他们正在与合适的人交谈,并秘密地同意一个密钥来对称地加密他们将要互相发送的数据。现在可以通过形成明文消息然后加密并发送它来发送HTTP请求和响应。另一方是唯一知道如何解密此消息的人,因此M​​an In The Middle Attackers无法读取或修改他们可能拦截的任何请求。

3.证书

3.1信任

在最基本的层面上,SSL证书只是一个文本文件,任何拥有文本编辑器的人都可以创建一个。实际上,您可以轻松创建一个声明您是Google Inc.并且您控制域gmail.com的证书。如果这是整个故事,那么SSL将是一个笑话; 身份验证基本上是客户要求服务器“你是谷歌吗?”,服务器回复“呃,是的,当然,这是一张纸,上面写着'我是谷歌'”,客户说“好的,这里是我所有的数据。“防止这场闹剧的神奇之处在于数字签名,它允许一方确认另一方的纸张确实是合法的。

您有两个明智的理由可以信任证书:

  • 如果它位于您默认的信任的证书列表中
  • 如果它能够证明上述列表中的一个证书的控制器信任它

第一个标准很容易检查。您的浏览器具有预安装的证书颁发机构(CA)证书列表,您可以查看,添加和删除这些证书。这些证书由一组(理论上和通常在实践中)极其安全,可靠和值得信赖的组织(如Symantec,Comodo和GoDaddy)控制。如果服务器提供该列表中的证书,那么您知道可以信任它们。

第二个标准要困难得多。服务器很容易说“呃,我的名字是微软,你信任Symantec,他们完全信任我。”一个有点聪明的客户可能会去问​​Symantec“我有一个微软在这里说你信任他们,这是真的吗?“但即使Symantec说”是的,我们知道他们,微软是合法的“,你仍然不知道声称是微软的服务器实际上是微软还是其他更糟糕的东西。这就是数字签名的用武之地。

3.2数字签名

如前所述,SSL证书具有关联的公钥/私钥对。公钥作为证书的一部分进行分发,并且私钥保持令人难以置信的安全保护。这对非对称密钥用于SSL握手,以便为双方交换进一步密钥以对称地加密和解密数据。客户端使用服务器的公钥加密对称密钥并将其安全地发送到服务器,服务器使用其私钥对其进行解密。任何人都可以使用公钥加密,但只有服务器可以使用私钥解密。

数字签名则相反。证书可以由另一个机构“签名”,由此权威机构有效地记录为“我们已经验证该证书的控制器确实拥有证书上列出的所有权(域名)”。在这种情况下,认证机构使用其私钥加密证书的内容,并且该密文作为其数字签名附加到证书。任何人都可以使用认证机构的公钥解密此签名,并验证它是否会产生预期的解密值。但只有认证机构可以使用私钥加密内容,因此只有认证机构才能实际创建有效的签名。

因此,如果服务器声称拥有由Symantec(或其他一些CA)签名的Microsoft.com证书,您的浏览器不会仅从字面上相信他们。如果它是合法的,Symantec将使用他们的私钥来生成服务器的SSL证书的数字签名,因此您的浏览器使用可以使用他们(Symantec)的公钥来检查此签名是否有效。Symantec将采取措施确保他们签署的组织确实拥有Microsoft.com,因此,鉴于您的客户信任Symantec,可以肯定你确实正在和Microsoft.com通信。

3.3自签名

请注意,所有根CA证书都是“自签名”,这意味着使用证书自己的私钥生成数字签名。根CA的证书没有任何本质上的特殊之处 - 您可以生成自己的自签名证书,并根据需要使用它来签署其他证书。但由于您的随机证书未在任何浏览器中作为CA预先加载到任何浏览器中,因此没有人会信任您签署自己的证书或其他证书。你实际上是在说“呃,是的,我完全是微软,这是我自己发布和签署的官方身份证明”,所有正常运行的浏览器都会发出一个非常可怕的错误信息,以回应你狡猾的凭据。

3.4你信任什么?

有趣的是,您的客户端在技术上并未尝试验证它是否应该信任发送证书的一方,而是它是否应该信任证书中包含的公钥。SSL证书是完全公开的,因此任何攻击者都可以获取Microsoft的证书,拦截客户对Microsoft.com的请求并向其提供合法证书。客户端会接受这一点并愉快地开始握手。但是,当客户端加密将用于实际数据加密的密钥时,它将使用此真实证书中的真实Microsoft公钥进行加密。由于攻击者没有Microsoft的私钥来解密它,因此它们现在被卡住了。即使握手完成,他们仍然无法解密密钥,因此无法解密客户端发送给他们的任何数据。

4.有趣的事实

4.1咖啡店可以通过网络监控我的HTTPS流量吗?

不会。公钥加密技术的神奇之处在于,攻击者可以监视客户端与服务器之间交换的每个字节数据,并且除了大致交换的数据之外,仍然不知道您在说什么。
但是,在不安全的Wi-Fi网络上,您的正常HTTP流量仍然非常脆弱,而且脆弱的网站可能会成为许多解决方案的牺牲品,这些解决方案以某种方式诱使您通过纯HTTP或完全错误的位置发送HTTPS流量。例如,即使登录表单通过HTTPS提交用户名/密码组合,如果表单本身通过HTTP不安全地加载,攻击者也可以在表单到达您的计算机的过程中截获该表单的HTML,并对其进行修改,以将登录详细信息发送到其自己的端点。

4.2我的公司可以通过网络监控我的HTTPS流量吗?

如果您还使用贵公司控制的机器,那么是的。请记住,每个信任链的根源都是一个隐式信任的CA,并且这些权限的列表存储在您的浏览器中。您的公司可以使用他们对您计算机的访问权限将自己的自签名证书添加到此CA列表中。然后,他们可以拦截您的所有HTTPS请求,提供声称代表相应网站的证书,由他们的假CA签名,因此您的浏览器毫无疑问会信任。由于您将使用其狡猾的证书的公钥加密所有HTTPS请求,因此他们可以使用相应的私钥来解密和检查(甚至修改)您的请求,然后将其发送到其预定位置。他们可能没有。但他们可以。

5.结论

HTTPS不是不可破解的,并且SSL协议必须不断发展,因为新的攻击被发现并被压制。但它仍然是一种令人印象深刻的传输秘密数据的方式,而无需关心谁看到你的消息。当然,这里没有提到许多实现细节,例如握手消息的确切格式和顺序,在不必重新协商密钥和密码套件的情况下获取最近会话的缩略握手,以及每个阶段可用的众多不同加密选项。要记住的关键是,虽然HTTPS保证数据安全到目的地,但它绝不会保护您(作为用户或开发人员)免受XSS或数据库泄漏等其他事情。很高兴有它在保护着我们的数据,但要保持警惕。正如Will Smith所说,“Walk in shadow, move in silence, guard against extra-terrestrial violence. 走进阴影,默默地行动,防范外星暴力”。

原文 https://robertheaton.com/2014/03/27/how-does-https-actually-work/

其他参考

数字证书的基础知识
HTTPS科普扫盲帖
和安全有关的那些事
OpenSSL 与 SSL 数字证书概念贴
基于OpenSSL自建CA和颁发SSL证书
聊聊HTTPS和SSL/TLS协议
SSL/TLS协议运行机制的概述
图解SSL/TLS协议
大型网站的 HTTPS 实践
SSL/TLS原理详解
扒一扒HTTPS网站的内幕
白话解释 OSI模型,TLS/SSL 及 HTTPS
OpenSSL HeartBleed漏洞原理漫画图解

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 218,525评论 6 507
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,203评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,862评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,728评论 1 294
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,743评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,590评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,330评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,244评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,693评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,885评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,001评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,723评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,343评论 3 330
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,919评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,042评论 1 270
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,191评论 3 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,955评论 2 355

推荐阅读更多精彩内容