《HTTP 权威指南》Part 3 —— 识别、认证与安全

867 阅读29分钟

第三部分提供了一系列的技术和技巧,可用来跟踪身份、进行安全性检查, 控制对内容的访问。

客户端识别与cookie机制

Web 服务器可能会同时与数千个不同的客户端进行对话。这些服务器通常要记录下 它们在与谁交谈,而不会认为所有的请求都来自匿名的客户端。

HTTP首部

  • 承载用户相关信息的HTTP首部 image.png

客户端IP地址

使用客户端 IP 地址来识别用户存在着很多缺点,限制了将其作为用户识别技术的效能。

  • 客户端 IP 地址描述的是所用的机器,而不是用户。如果多个用户共享同一台计算机,就无法对其进行区分了。
  • 很多因特网服务提供商都会在用户登录时为其动态分配 IP 地址。
  • 为了提高安全性,并对稀缺的地址资源进行管理,很多用户都是通过网络地址转换(Network Address Translation,NAT)防火墙来浏览网络内容的。这些 NAT 设备隐藏了防火墙后面那些实际客户端的 IP 地址,将实际的客户端 IP 地址转换成了一个共享的防火墙 IP 地址(和不同的端口号)
  • HTTP 代理和网关通常会打开一些新的、到原始服务器的 TCP 连接。Web 服务器看到的将是代理服务器的 IP 地址,而不是客户端的。有些代理为了绕过这个问题会添加特殊的 Client-IP 或 X-Forwarded-For 扩展首部来保存原始的 IP 地址。但并不是所有的代理都支持这种行为。

用户登录

Web 服务器无需被动地根据用户的 IP 地址来猜测他的身份,它可以要求用户通过用户名和密码进行认证(登录)来显式地询问用户是谁。

为了使 Web 站点的登录更加简便,HTTP 中包含了一种内建机制,可以用 WWWAuthenticate 首部和 Authorization 首部向 Web 站点传送用户的相关信息。

胖URL

有些 Web 站点会为每个用户生成特定版本的 URL 来追踪用户的身份。通常,会对 真正的 URL 进行扩展,在 URL 路径开始或结束的地方添加一些状态信息。用户浏 览站点时,Web 服务器会动态生成一些超链,继续维护 URL 中的状态信息。

改动后包含了用户状态信息的 URL 被称为胖 URL(fat URL)。可以在用户浏览站点时,用胖 URL 对其进行识别。但这种技术存在几个很严重的问题。

  • 丑陋的 URL,浏览器中显示的胖 URL 会给新用户带来困扰。

  • 无法共享 URL,胖 URL 中包含了与特定用户和会话有关的状态信息。如果将这个 URL 发送给其 他人,可能就在无意中将你积累的个人信息都共享出去了。

  • 破坏缓存,为每个 URL 生成用户特有的版本就意味着不再有可供公共访问的 URL 需要缓存了。

  • 额外的服务器负荷,服务器需要重写 HTML 页面使 URL 变胖。

  • 逃逸口,用户跳转到其他站点或者请求一个特定的 URL 时,就很容易在无意中“逃离” 胖 URL 会话。只有当用户严格地追随预先修改过的链接时,胖 URL 才能工作。 如果用户逃离此链接,就会丢失他的进展(可能是一个已经装满了东西的购物 车)信息,得重新开始。

  • 在会话间是非持久的,除非用户收藏了特定的胖 URL,否则用户退出登录时,所有的信息都会丢失。

cookie

cookie 是当前识别用户,实现持久会话的最好方式。

cookie 非常重要,而且它们定义了一些新的 HTTP 首部,所以我们要比前面那些技 术更详细地介绍它们。cookie 的存在也影响了缓存,大多数缓存和浏览器都不允许对任何 cookie 的内容进行缓存。

cookie 类型

可以笼统地将 cookie 分为两类:会话 cookie 和持久 cookie。

  • 会话 cookie:会话 cookie 是一种 临时 cookie,它记录了用户访问站点时的设置和偏好。用户退出浏览器时,会话 cookie 就被删除了。

  • 持久 cookie:持久 cookie 的生存时间更长一些;它们存储在硬盘上,浏览器退出,计算机重启时它们仍然存在。通常会用持久 cookie 维护某个用户会周期性访问的站点的配置文件或登录名

会话 cookie 和持久 cookie 之间唯一的区别就是它们的过期时间。

cookie 是如何工作的

用户首次访问 Web 站点时,Web 服务器对用户一无所知。Web 服务器希望这个用户会再次回来,所以想给这个用户“拍上”一个独有的 cookie,这样以后它就可以识别出这个用户了。cookie 中包含了一个由名字 = 值(name=value) 这样的信息构成的任意列表,并通过 Set-Cookie 或 Set-Cookie2 HTTP 响应(扩展)首部将其贴到用户身上去。

cookie罐:客户端的状态

cookie 的基本思想就是让浏览器积累一组服务器特有的信息,每次访问服务器时都将这些信息提供给它。因为浏览器要负责存储 cookie 信息,所以此系统被称为客户端侧状态(client-side state)。这个 cookie 规范的正式名称为 HTTP 状态管理机制 (HTTP state management mechanism)。

不同站点使用不同的cookie

浏览器内部的 cookie 罐中可以有成百上千个 cookie,但浏览器不会将每个 cookie 都发送给所有的站点。实际上,它们通常只向每个站点发送 2 ~ 3 个 cookie。原因 如下:

  • 对所有这些 cookie 字节进行传输会严重降低性能。浏览器实际传输的 cookie 字节数要比实际的内容字节数多!
  • cookie 中包含的是服务器特有的名值对,所以对大部分站点来说,大多数 cookie 都只是无法识别的无用数据。
  • 将所有的 cookie 发送给所有站点会引发潜在的隐私问题,那些你并不信任的站点也会获得你只想发给其他站点的信息。

很多 Web 站点都会与第三方厂商达成协议,由其来管理广告。这些广告被做得像 Web 站点的一个组成部分,而且它们确实发送了持久 cookie。用户访问另一个由同 一广告公司提供服务的站点时,(由于域是匹配的)浏览器就会再次回送早先设置的持久 cookie。营销公司可以将此技术与 Referer 首部结合,暗地里构建一个用户档案和浏览习惯的详尽数据集。现代的浏览器都允许用户对隐私特性进行设置,以限制第三方 cookie 的使用。

  1. cookie的域属性,产生 cookie 的服务器可以向 Set-Cookie 响应首部添加一个 Domain 属性来控制 哪些站点可以看到那个 cookie。如:
Set-cookie: user="mary17"; domain="airtravelbargains.com"
  1. cookie路径属性,cookie 规范甚至允许用户将 cookie 与部分 Web 站点关联起来。可以通过 Path 属性来实现这一功能,在这个属性列出的 URL 路径前缀下所有 cookie 都是有效的。如:
Set-cookie: pref=compact; domain="airtravelbargains.com"; path=/autos/

cookie成分

现在使用的 cookie 规范有两个不同的版本:

  • cookies 版本 0(有时被称为 Netscape cookies)
  • cookies 版本 1(RFC 2965)。

cookies 版本 1 是对 cookies 版本 0 的扩展,应用不如后者广泛。

cookie与会话跟踪

image.png

基本认证机制

认证

认证就是要给出一些身份证明。

HTTP的质询/响应认证框架

HTTP 提供了一个原生的质询 / 响应(challenge/response)框架,简化了对用户的认 证过程。HTTP 的认证模型如图中所示

image.png

认证协议与首部

HTTP 通过一组可定制的控制首部,为不同的认证协议提供了一个可扩展框架。

HTTP 定义了两个官方的认证协议:基本认证和摘要认证。

image.png

image.png

安全域

Web 服务器会将受保护的文档组织成一个安全域(security realm)。每个安全域都可以有不同的授权用户集。

  • Web 服务器上的安全域 image.png

基本认证

基本认证是最流行的 HTTP 认证协议。几乎每个主要的客户端和服务器都实现了基本认证机制。基本认证最初是在 HTTP/1.0 规范中提出的,但此后被移到了 RFC 2617 中,它详细介绍了 HTTP 的认证机制。

基本认证实例

下图是一个详细的基本认证实例。

  • 在图 a 中,用户请求了私人家庭相片 /family/jeff.jpg。
  • 在图 b 中,服务器回送一条 401 Authorization Required,对私人家庭相片 进行密码质询,同时回送的还有 WWW-Authenticate 首部。这个首部请求对 Family 域进行基本认证。
  • 在图 c 中, 浏 览 器 收 到 了 401 质 询, 弹 出 对 话 框, 询 问 Family 域 的 用 户名和密码。用户输入用户名和密码时,浏览器会用一个冒号将其连接起 来,编码成“经过扰码的”Base-64 表示形式,然后将其放在 Authorization 首部中回送。
  • 在图 d 中,服务器对用户名和密码进行解码,验证它们的正确性,然后用一 条 HTTP 200 OK 报文返回所请求的报文。

image.png

注意,基本认证协议并没有使用表所示的 Authentication-Info 首部。

Base-64 用户名/密码编码

HTTP 基本认证将(由冒号分隔的)用户名和密码打包在一起,并用 Base-64 编码 方式对其进行编码。

代理认证

中间的代理服务器也可以实现认证功能。有些组织会在用户访问服务器、LAN 或无 线网络之前,用代理服务器对其进行认证。可以在代理服务器上对访问策略进行集中管理,因此,通过代理服务器提供对某组织内部资源的统一访问控制是一种很便捷的方式。这个过程的第一步就是通过代理认证(proxy authentication)来识别身份。

  • 列出了 Web 服务器和代理在认证中使用的状态码和首部的差异。

image.png

基本认证的安全缺陷

基本认证简单便捷,但并不安全。只能用它来防止非恶意用户无意间进行的访问, 或将其与 SSL 这样的加密技术配合使用。

基本认证存在下列安全缺陷:

  • 基本认证会通过网络发送用户名和密码,这些用户名和密码都是以一种很容易解码的形式表示的。
  • 即使密码是以更难解码的方式加密的,第三方用户仍然可以捕获被修改过的用户名和密码,并将修改过的用户名和密码一次一次地重放给原始服务器,以获得对服务器的访问权。
  • 即使将基本认证用于一些不太重要的应用程序,比如公司内部网络的访问控制或个性化内容的访问,一些不良习惯也会让它变得很危险。很多用户由于受不了大量密码保护的服务,会在这些服务间使用相同的用户名和密码。比如说,某个狡猾的恶徒会从免费的因特网邮件网站捕获明文形式的用户名和密码,然后会发现用同样的用户名和密码还可以访问重要的在线银行网站!
  • 基本认证没有提供任何针对代理和作为中间人的中间节点的防护措施,它们没有修改认证首部,但却修改了报文的其余部分,这样就严重地改变了事务的本质。
  • 假冒服务器很容易骗过基本认证。如果在用户实际连接到一台恶意服务器或网关的时候,能够让用户相信他连接的是一个受基本认证保护的合法主机,攻击者就可以请求用户输入密码,将其存储起来以备未来使用,然后捏造一条错误信息传送给用户。

摘要认证

基本认证便捷灵活,但极不安全。用户名和密码都是以明文形式传送的,也没有采取任何措施防止对报文的篡改。安全使用基本认证的唯一方式就是将其与 SSL 配合使用。

摘要认证的改进

摘要认证是另一种 HTTP 认证协议,它试图修复基本认证协议的严重缺陷。具体来说,摘要认证进行了如下改进。

  • 永远不会以明文方式在网络上发送密码。
  • 可以防止恶意用户捕获并重放认证的握手过程。
  • 可以有选择地防止对报文内容的篡改。
  • 防范其他几种常见的攻击方式。

用摘要保护密码

摘要认证遵循的箴言是“绝不通过网络发送密码”。客户端不会发送密码,而是会发 送一个“指纹”或密码的“摘要”,这是密码的不可逆扰码

单向摘要

摘要是“对信息主体的浓缩”。摘要是一种单向函数,主要用于将无限的输入值转换为有限的浓缩输出值。常见的摘要函数 MD5,会将任意长度的字节序列转换为一个 128 位的摘要。

用随机数防止重放攻击

但是,仅仅隐藏密码并不能避免危险,因为即便不知道密码,别有用心的人也可以截获摘要,并一遍遍地重放给服务器。摘要和密码一样好用。

为防止此类重放攻击的发生,服务器可以向客户端发送一个称为随机数(nonce)的特殊令牌,这个数会经常发生变化(可能是每毫秒,或者是每次认证都变化)。客户端在计算摘要之前要先将这个随机数令牌附加到密码上去。

摘要认证的握手机制

HTTP 摘要认证协议是一种升级版的认证方式,所用首部与基本认证类似。

  • 基本认证与摘要认证的语法对比

image.png

image.png

摘要的计算

摘要认证的核心就是对公共信息、保密信息和有时限的随机值这个组合的单向摘要。

摘要算法的输入数据

摘要是根据以下三个组件计算出来的。

  • 由单向散列函数 H(d) 和摘要 KD(s,d) 组成的一对函数,其中 s 表示密码,d 表示 数据。
  • 一个包含了安全信息的数据块,包括密码,称为 A1。
  • 一个包含了请求报文中非保密属性的数据块,称为 A2。 H 和 KD 处理两块数据 A1 和 A2,产生摘要。

算法H(d)和KD(s,d)

摘要认证支持对各种摘要算法的选择。RFC 2617 建议的两种算法为 MD5 和 MD5- sess(“sess”表示会话),如果没有指定其他算法,默认算法为 MD5。

安全HTTP

前面讨论了一些有助于识别和认证用户的 HTTP 特性。在友好环境中,这些技术都能够很好地工作,但在充满各种利益驱动和恶意对手的环境中,它们并不足以保护那些重要的事务处理。

保护HTTP的安全

前面的章节讨论了一些提供认证(基本认证和摘要认证)和报文完整性检查(摘要 qop="auth-int")的轻量级方法。对很多网络事务来说,这些方法都是很好用的, 但对大规模的购物、银行事务,或者对访问机密数据来说,并不足够强大。这些更为重要的事务需要将 HTTP 和数字加密技术结合起来使用,才能确保安全。

HTTP 的安全版本要高效、可移植且易于管理,不但能够适应不断变化的情况而且还应该能满足社会和政府的各项要求。我们需要一种能够提供下列功能的 HTTP 安全技术。

  • 服务器认证(客户端知道它们是在与真正的而不是伪造的服务器通话)。
  • 客户端认证(服务器知道它们是在与真正的而不是伪造的客户端通话)。
  • 完整性(客户端和服务器的数据不会被修改)。
  • 加密(客户端和服务器的对话是私密的,无需担心被窃听)。
  • 效率(一个运行的足够快的算法,以便低端的客户端和服务器使用)。
  • 普适性(基本上所有的客户端和服务器都支持这些协议)。
  • 管理的可扩展性(在任何地方的任何人都可以立即进行安全通信)。
  • 适应性(能够支持当前最知名的安全方法)。
  • 在社会上的可行性(满足社会的政治文化需要)。

HTTPS

HTTPS 是最流行的 HTTP 安全形式。它是由网景公司首创的,所有主要的浏览器和服务器都支持此协议。

使用 HTTPS 时,所有的 HTTP 请求和响应数据在发送到网络之前,都要进行加密。 HTTPS 在 HTTP 下面提供了一个传输级的密码安全层(参见下图)——可以使用 SSL,也可以使用其后继者——传输层安全(Transport Layer Security,TLS)。由于 SSL 和 TLS 非常类似,所以在本书中我们不太严格地用术语 SSL 来表示 SSL 和 TLS。

image.png

大部分困难的编码及解码工作都是在 SSL 库中完成的,所以 Web 客户端和服务器在使用安全 HTTP 时无需过多地修改其协议处理逻辑。在大多数情况下,只需要用SSL 的输入 / 输出调用取代 TCP 的调用,再增加其他几个调用来配置和管理安全信 息就行了。

数字加密

先介绍一些 SSL 和 HTTPS 用到的加密编码技术的背景知识。

  • 密码:对文本进行编码,使偷窥者无法识别的算法。
  • 密钥:改变密码行为的数字化参数。
  • 对称密钥加密系统:编 / 解码使用相同密钥的算法。
  • 不对称密钥加密系统:编 / 解码使用不同密钥的算法。
  • 公开密钥加密系统:一种能够使数百万计算机便捷地发送机密报文的系统。
  • 数字签名:用来验证报文未被伪造或篡改的校验和。
  • 数字证书:由一个可信的组织验证和签发的识别信息。

密码编制的机制与技巧

密码学是对报文进行编 / 解码的机制与技巧。人们用加密的方式来发送秘密信息已经有数千年了。但密码学所能做的还不仅仅是加密报文以防止好事者的读取,我们还可以用它来防止对报文的篡改,甚至还可以用密码学来证明某条报文或某个事务确实出自你手,就像支票上的手写签名或信封上的压纹封蜡一样。

密码

密码学基于一种名为密码(cipher)的秘密代码。密码是一套编码方案——一种特殊的报文编码方式和一种稍后使用的相应解码方式的结合体。加密之前的原始报文通常被称为明文(plaintext 或 cleartext)。使用了密码之后的编码报文通常被称作密文(ciphertext)。

image.png

密码机

随着技术的进步,人们开始制造一些机器,这些机器可以用复杂得多的密码来快速、精确地对报文进行编解码。这些密码机不仅能做一些简单的旋转,它们还可以替换字符、改变字符顺序,将报文切片切块,使代码的破解更加困难。

使用了密钥的密码

编码算法和编码机都可能会落入敌人的手中,所以大部分机器上都有一些号盘,可以将其设置为大量不同的值以改变密码的工作方式。即使机器被盗,没有正确的号盘设置(密钥值),解码器也无法工作。

这些密码参数被称为密钥(key)。要在密码机中输入正确的密钥,解密过程才能正确进行。密码密钥会让一个密码机看起来好像是多个虚拟密码机一样,每个密码机都有不同的密钥值,因此其行为都会有所不同。

image.png

数字密码

与金属钥匙或机械设备中的号盘设置相比,数字密钥只是一些数字。这些数字密钥 值是编 / 解码算法的输入。编码算法就是一些函数,这些函数会读取一块数据,并 根据算法和密钥值对其进行编 / 解码。

image.png

对称密钥加密技术

很多数字加密算法都被称为对 称密钥(symmetric-key)加密技术,这是因为它们在编码时使用的密钥值和解码时 一样(e=d)。我们就将其统称为密钥 k。

image.png

密钥长度与枚举攻击

好的加密算法会迫使攻击者试遍每一个可能的密钥,才能破解代码。用暴力去尝试 所有的密钥值称为枚举攻击(enumeration attack)。

  • 较长的密钥要花费更多的精力去破解

image.png

建立共享密钥

对称密钥加密技术的缺点之一就是发送者和接收者在互相对话之前,一定要有一个共享的保密密钥。

每对通信实体都需要自己的私有密钥。如果有 N 个节点, 每个节点都要和其他所有 N-1 个节点进行安全对话,总共大概会有 N2 个保密密钥: 这将是一个管理噩梦。

公开密钥加密技术

公开密钥加密技术没有为每对主机使用单独的加密 / 解密密钥,而是使用了两个非对称密钥:一个用来对主机报文编码,另一个用来对主机报文解码。编码密钥是众所周知的(这也是公开密钥加密这个名字的由来),但只有主机才知道私有的解密密钥。这样,每个人都能找到某个特定主机的公开密钥,密钥的建立变得更加简单。但解码密钥是保密的,因此只有接收端才能对发送给它的报文进行解码。

image.png

通过公开密钥加密技术,全球所有的计算机用户就都可以使用安全协议了。制定标准化的公开密钥技术包是非常重要的,因此,大规模的公开密钥架构(Public-Key Infrastructure,PKI)标准创建工作已经开展十多年了。

混合加密系统和会话密钥

任何人只要知道了其公开密钥,就可以向一台公共服务器发送安全报文,所以非对称的公开密钥加密系统是很好用的。两个节点无须为了进行安全的通信而先交换私有密钥。

但公开密钥加密算法的计算可能会很慢。实际上它混合使用了对称和非对称策略。 比如,比较常见的做法是在两节点间通过便捷的公开密钥加密技术建立起安全通信,然后再用那条安全的通道产生并发送临时的随机对称密钥,通过更快的对称加密技术对其余的数据进行加密。

数字签名

除了加 / 解密报文之外,还可以用加密系统对报文进行签名(sign),以说明是谁编写的报文,同时证明报文未被篡改过。这种技术被称为数字签名(digital signing)

签名是加了密的校验和

数字签名是附加在报文上的特殊加密校验码。使用数字签名有以下两个好处。

  • 签名可以证明是作者编写了这条报文。只有作者才会有最机密的私有密钥,因此,只有作者才能计算出这些校验和。校验和就像来自作者的个人“签名”一样。

  • 签名可以防止报文被篡改。如果有恶意攻击者在报文传输过程中对其进行了修改, 校验和就不再匹配了。由于校验和只有作者保密的私有密钥才能产生,所以攻击者无法为篡改了的报文伪造出正确的校验码。

数字签名通常是用非对称公开密钥技术产生的。因为只有所有者才知道其私有密钥, 所以可以将作者的私有密钥当作一种“指纹”使用。

下图显示了一个例子,说明了节点 A 是如何向节点 B 发送一条报文,并对其进行签名的。

  • 节点 A 将变长报文提取为定长的摘要。
  • 节点 A 对摘要应用了一个“签名”函数,这个函数会将用户的私有密钥作为参数。 因为只有用户才知道私有密钥,所以正确的签名函数会说明签名者就是其所有者。在图中,由于解码函数 D 中包含了用户的私有密钥,所以我们将其作为签名函数使用。
  • 一旦计算出签名,节点 A 就将其附加在报文的末尾,并将报文和签名都发送给 B。
  • 在接收端,如果节点 B 需要确定报文确实是节点 A 写的,而且没有被篡改过, 节点 B 就可以对签名进行检查。节点 B 接收经私有密钥扰码的签名,并应用了使用公开密钥的反函数。如果拆包后的摘要与节点 B 自己的摘要版本不匹配,要 么就是报文在传输过程中被篡改了,要么就是发送端没有节点 A 的私有密钥(也就是说它不是节点 A)。 image.png

数字证书

本节将介绍因特网上的“ID 卡”——数字证书。

证书的主要内容

数字证书中还包含一组信息,所有这些信息都是由一个官方的“证书颁发机构”以数字方式签发的。

  • 典型的数字签名格式 image.png 而且,数字证书通常还包括对象的公开密钥,以及对象和所用签名算法的描述性信息。任何人都可以创建一个数字证书,但并不是所有人都能够获得受人尊敬的签发权,从而为证书信息担保,并用其私有密钥签发证书。

X.509 v3证书

不幸的是,数字证书没有单一的全球标准。就像不是所有印刷版 ID 卡都在同样的位 置包含了同样的信息一样,数字证书也有很多略有不同的形式。不过好消息就是现在使用的大多数证书都以一种标准格式——X.509 v3,来存储它们的信息

用证书对服务器进行认证

通过 HTTPS 建立了一个安全 Web 事务之后,现代的浏览器都会自动获取所连接服 务器的数字证书。如果服务器没有证书,安全连接就会失败。服务器证书中包含很多字段,其中包括:

  • Web 站点的名称和主机名;
  • Web 站点的公开密钥;
  • 签名颁发机构的名称;
  • 来自签名颁发机构的签名。

验证签名是真的

image.png

HTTPS——细节介绍

HTTPS 是最常见的 HTTP 安全版本。它得到了很广泛的应用,所有主要的商业浏览 器和服务器上都提供 HTTPS。HTTPS 将 HTTP 协议与一组强大的对称、非对称和 基于证书的加密技术结合在一起,使得 HTTPS 不仅很安全,而且很灵活,很容易在处于无序状态的、分散的全球互联网上进行管理

HTTPS概述

HTTPS 就是在安全的传输层上发送的 HTTP。它在将 HTTP 报文发送给 TCP 之前,先将其发送给了一个安全层,对其进行加密。参见图(b)

image.png

HTTPS方案

现在,安全 HTTP 是可选的。请求一个客户端(比如 Web 浏览器)对某 Web 资源执行某事务时,它会去检查 URL 的方案。

  • 如果 URL 的方案为 http,客户端就会打开一条到服务器端口 80(默认情况下) 的连接,并向其发送老的 HTTP 命令(参见图 14-14a)。

  • 如果 URL 的方案为 https,客户端就会打开一条到服务器端口 443(默认情况下) 的连接,然后与服务器“握手”,以二进制格式与服务器交换一些 SSL 安全参数, 附上加密的 HTTP 命令(参见图 14-14b)。

SSL 是个二进制协议,与 HTTP 完全不同,其流量是承载在另一个端口上的(SSL 通常是由端口 443 承载的)。如果 SSL 和 HTTP 流量都从端口 80 到达,大部分 Web 服务器会将二进制 SSL 流量理解为错误的 HTTP 并关闭连接。

建立安全传输

由于 SSL 安全层的存在,HTTPS 中这个过程会略微复杂一些。在 HTTPS 中,客户 端首先打开一条到 Web 服务器端口 443(安全 HTTP 的默认端口)的连接。一旦建 立了 TCP 连接,客户端和服务器就会初始化 SSL 层,对加密参数进行沟通,并交 换密钥。握手完成之后,SSL 初始化就完成了,客户端就可以将请求报文发送给安全层了。在将这些报文发送给 TCP 之前,要先对其进行加密。下图对此过程 进行了说明。

image.png

SSL握手

在发送已加密的 HTTP 报文之前,客户端和服务器要进行一次 SSL 握手,在这个握 手过程中,它们要完成以下工作:

  • 交换协议版本号;
  • 选择一个两端都了解的密码;
  • 对两端的身份进行认证;
  • 生成临时的会话密钥,以便加密信道。

(简化版)SSL 握手 image.png

服务器证书

SSL 支持双向认证,将服务器证书承载回客户端,再将客户端的证书回送给服务器。 而现在,浏览时并不经常使用客户端证书。大部分用户甚至都没有自己的客户端证书。服务器可以要求使用客户端证书,但实际中很少出现这种情况。

服务器证书是一个显示了组织的名称、地址、服务器 DNS 域名以及其他信息的 X.509 v3 派生证书(参见下图)

  • HTTPS 证书是带有站点信息的 X.509 证书

image.png

站点证书的有效性

SSL 自身不要求用户检查 Web 服务器证书,但大部分现代浏览器都会对证书进行简单的完整性检查,并为用户提供进行进一步彻查的手段。网景公司提出的一种 Web 服务器证书有效性算法是大部分浏览器有效性验证技术的基础。验证步骤如下所述:

  • 日期检测
  • 签名颁发者可信度检测
  • 签名检测
  • 站点身份检测

虚拟主机与证书

对虚拟主机(一台服务器上有多个主机名)站点上安全流量的处理有时是很棘手的。 有些流行的 Web 服务器程序只支持一个证书。如果用户请求的是虚拟主机名,与证书名称并不严格匹配,浏览器就会显示警告框。

HTTPS客户端实例

SSL 是个复杂的二进制协议。幸运的是,借助一些商业或开源的库,编写 SSL 客户端和服务器并不十分困难。

OpenSSL

OpenSSL 是 SSL 和 TLS 最常见的开源实现。OpenSSL 项目由一些志愿者合作开发, 目标是开发一个强壮的、具有完备功能的商业级工具集,以实现 SSL 和 TLS 协议以 及一个全功能的通用加密库。

通过代理以隧道形式传输安全流量

客户端通常会用 Web 代理服务器代表它们来访问 Web 服务器。比如,很多公司都会在公司网络和公共因特网的安全边界上放置一个代理。代理是防火墙路由器唯一允许进行 HTTP 流量交换的设备,它可能会进行病毒检测或其他的内容控制工作。

但只要客户端开始用服务器的公开密钥对发往服务器的数据进行加密,代理就再也不能读取 HTTP 首部了!代理不能读取 HTTP 首部,就无法知道应该将请求转向何处了。

为了使 HTTPS 与代理配合工作。一种常用的技术就是 HTTPS SSL 隧道协议。使用 HTTPS 隧道协议,客户端首先要告知代理,它想要连接的安全主机和端口。这是在开始加密之前,以明文形式告知的,所以代理可以理解这条信息。