SSL/TLS 原理详解

发布时间: 更新时间: 总字数:9002 阅读时间:18m 作者: IP上海 分享 网址

HTTPS 早在 1994 年由网景公司首次提出,SSL/TLS作为一种互联网安全加密技术,原理较为复杂,本文试图试图介绍其原理。

介绍

  • 常见加密算法
  • TLS(Transport Layer Security) 通过非对称加密算法,用于在不安全的环境中创建可靠的安全连接,保证通信不被泄露和篡改
    • SSL(Secure Socket Layer,安全套接字层) 为 Netscape 所研发,用以保障在 Internet 上数据传输之安全,利用数据加密(Encryption)技术,可确保数据在网络上之传输过程中不会被截取
    • SSL 有 1.0/2.0/3.0 三个版本,SSL 从 3.1 开始改名为 TLS,发展处 TLS1.0/1.1/1.2/1.3 四个版本,常用的是 1.2
  • HTTPs(HTTP over SSL/TLS) 使用数字证书来验证网站的身份,通过 SSL/TLS 加密 HTTP 数据,保证通信的安全
    • HTTPs 协议默认端口未 443,协议前缀为 https://
  • SSL Handshake Protocol 使用 SSL/TLS 协议 的双方通信前,需要协商加密算法和密钥,该过程称为握手,是 SSL/TLS 中成本最高、最耗时的,之后通过对称加密通信
    • TLS1.1/1.2 握手步骤不较复杂,TLS 1.3 做了很大的简化,提高了性能
  • SNI(Server Name Indication) 是对 TLS 协议的扩展,它允许客户端在 ClientHello 时携带请求网站的主机名信息(相当于 HTTP 协议的 Header 中的 Host 字段),此时服务器可以据此选择对应的证书
  • OCSP(Online Certificate Status Protocol) 向权威服务器发送查询请求,验证服务器证书是否因过期、被撤销等原因失效而不被信任
    • OCSP 替代存在缺陷的 CRL(Certificate Revocation List) 协议,通常使用 HTTP 协议通信
  • OCSP Stapling,OpenResty 参考
    • 客户端可以在 SSL 握手阶段发起 OCSP 查询,验证服务器证书是否正常,但增加了 TLS 连接建立的时长
    • OCSP Stapling 由服务器主动获取 OCSP 查询结果,并随证书一起发给客户端,优化了 SSL 握手过程

术语

  • CA证书颂发机构(Certificate Authority) 是指一个中心化的,可信任的证书颁发机构
  • 数字证书(Digital Certificate) 使用 CA 私钥加密(拥有者信息、公钥信息和拥有者公钥)得到的数据,即是数字证书
  • PKI公钥基础设施(Public Key Infrastructure) 用来实现基于公钥密码体制的密钥和证书的产生、管理、存储、分发和撤销等功能

OpenSSL 工具介绍

openssl是一个开源程序的套件、这个套件有三个部分组成:

  1. libcryto 是一个具有通用功能的加密库,里面实现了众多的加密库
  2. libssl 是实现 ssl 机制的,它是用于实现 TLS/SSL 的功能
  3. openssl 是个多功能命令行工具,它可以实现加密解密,甚至还可以当 CA 来用,可以让你创建证书、吊销证书

证书格式介绍

  • .key:私钥文件,如ca.key
  • .crt:数字证书(Digital Certificate)文件,如ca.crt
  • .bundle.crt:最终在 NGINX 上配置的数字证书文件,通常包含两部分,如:<domain>.crtca.crt
  • .chain.crt:证书链文件
  • .srlopenssl ca签名过程中产生的Serial Number存放的文件
  • .csr:证书签名请求(Certificate Signing Request)文件,如all.xiexianbin.cn.csr
  • .crl:证书吊销列表(Certificate Revocation List)
  • .pemPrivacy Enhanced Mail,以 -----BEGIN... 开头,-----END... 结尾,内容是 BASE64 编码,包含私钥的证书
    • 查看证书命令:openssl x509 -text -noout -in xxx.pem
  • .der Distinguished Encoding Rules 二进制格式
    • 查看证书命令:openssl x509 -inform der -text -noout -in xxx.der

非对称加密算法

非对称加密算法需要两个密钥:

  • 公开密钥(publickey)简称公钥
  • 私有密钥(privatekey)简称私钥
  • 公钥与私钥是一对,如果用公钥对数据进行加密,只有用对应的私钥才能解密;私钥仅有一把,但公钥可以是多个
  • 私钥加密的内容,所有公钥都能解开
  • 公钥加密的内容,只有私钥才能解开

X.509

X.509是国际电信联盟针对PKI制定的标准RFCs

一个X.509 v3版本的数字证书包含的结构如下:

  • Version - 必须是 v3
  • Serial Number - 每个证书都有唯一的序列号
  • Algorithm ID - 算法 ID,与底下的证书签名算法必须一致
  • Issuer - 发行者
  • Validity - 指明有效期
  • Subject - 拥有者的相关信息,如 C=CN, ST=Henan, L=Zhengzhou, ... CN=*.xiexianbin.cn
  • Subject public key info
  • Issuer Unique Identifier (optional)
  • Subject Unique Identifier (optional)
  • Extensions (optional) - 拓展,尤其是 Subject Alternative Name 的拓展非常关键
    • Subject Key Identifier (optional)
    • Authority Key Identifier (optional)
    • Subject Alternative Name: 重要
      • 通配证书(Wildcard Certificates)指的是像*.xiexianbin.cn一类的证书
    • Basic Constraints (optional)
  • 证书签名算法(Certificate Signature Algorithm)如:SHA-256
  • 证书签名(Certificate Signature)

HTTPs 交互过程

  • 浏览器向服务器发送请求证书请求
  • 服务器响应证书给浏览器
  • 浏览器获取证书后,根据签发机构,从本地的信任 CA 中找到对应的签发者,验证证书是否有效,证书和域名是否匹配等
    • 有效
      • 浏览器生成 会话密钥(对称加密实现,效率高)
      • 浏览器使用服务器的公钥加密 会话密钥,并将加密后的 会话密钥 发送给服务器
      • 服务器端接收加密的 会话密钥,并使用私有解码
      • 服务的告诉浏览器 会话密钥 已接收(若失败,返回错误)
      • 此后,浏览器使用 会话密钥 加密和解密数据,与服务器进行通信,服务器也是用对应的 会话密钥 对接收的数据进行加密和解密
    • 无效:提示 SSL 证书不被信任

SSL/TLS 概览

握手的过程

  • Clienthello:发送客户端的功能和首选项给服务器,在连接建立后,当希望重协商、或者响应服务器的重协商请求时会发送
    • version:客户端支持的最佳协议版本
    • Random:共 32 字节,28 字节随机数,4 字节额外信息,受客户端时钟影响(为了避免浏览器指纹采集,现在一般会对 4 字节时钟做扭曲)
    • Session ID:32 字节随机数,用于和服务器重建会话,为空表示新建会话
    • cipher suit:客户端支持的所有密码套件,按优先级排列
    • Compression:客户端支持的压缩算法,默认无压缩
    • Extensions:由任意数量的扩展组成,携带额外数据
  • ServerHello:
    • 选择客户端提供的参数反馈客户端
    • 服务器无需支持客户端支持的最佳版本,如果服务器不支持客户端版本,可以提供其他版本以期待客户端可以接受
  • Certificate:
    • 用于携带服务器 X.509 证书链
    • 主证书必须第一个发送,中间证书按照正确的顺序跟在主证书之后
    • 服务器必须保证发送的证书和选择的算法套件一致
    • Certificate 消息时可选的
  • ServerKeyExchange: 携带密钥交换的额外数据,取决于加密套件
  • ServerHelloDone:服务器已将所有预计的握手消息发送完毕
  • ClientkeyExchange:携带客户端为密钥交换提供的信息
  • ChangeCipherSpec:发送端已取得用以连接参数的足够的信息
  • Finish:握手完成,消息内容加密,双方可以交换验证,整个握手完整性所需的数据
    • 算法:verrify_data = PRF(master_secret , finished_label,hash(handshake_message))

整体结构

SSL 是一个介于 HTTP 协议与 TCP 之间的一个可选层,其位置大致如下:

SSL 协议位于 TCP/IP 协议与各种应用层协议之间,为数据通讯提供安全支持。SSL 协议可分为两层:SSL记录协议(SSL Record Protocol):它建立在可靠的传输协议(如 TCP)之上,为高层协议提供数据封装、压缩、加密等基本功能的支持。 SSL 握手协议(SSL Handshake Protocol):它建立在 SSL 记录协议之上,用于在实际的数据传输开始前,通讯双方进行身份认证、协商加密算法、交换加密密钥等。

TLS(Transport Layer Security,传输层安全协议) 用于两个应用程序之间提供保密性和数据完整性。

TLS 1.0 是 IETF(Internet Engineering Task Force,Internet 工程任务组)制定的一种新的协议,它建立在 SSL 3.0 协议规范之上,是 SSL 3.0 的后续版本,可以理解为 SSL 3.1,它是写入了 RFC 的。该协议由两层组成: TLS 记录协议(TLS Record)和 TLS 握手协议(TLS Handshake)。较低的层为 TLS 记录协议,位于某个可靠的传输协议(例如 TCP)上面。

SSL/TLS 协议提供的服务主要有:

  • 认证用户和服务器,确保数据发送到正确的客户机和服务器;

  • 加密数据以防止数据中途被窃取;

  • 维护数据的完整性,确保数据在传输过程中不被改变。

TLS 与 SSL 的差异

  • 版本号:TLS 记录格式与 SSL 记录格式相同,但版本号的值不同,TLS 的版本 1.0 使用的版本号为 SSLv3.1。

  • 报文鉴别码:SSLv3.0 和 TLS 的 MAC 算法及 MAC 计算的范围不同。TLS 使用了 RFC-2104 定义的 HMAC 算法。SSLv3.0 使用了相似的算法,两者差别在于 SSLv3.0 中,填充字节与密钥之间采用的是连接运算,而 HMAC 算法采用的是异或运算。但是两者的安全程度是相同的。

  • 伪随机函数:TLS 使用了称为 PRF 的伪随机函数来将密钥扩展成数据块,是更安全的方式。

  • 报警代码:TLS 支持几乎所有的 SSLv3.0 报警代码,而且 TLS 还补充定义了很多报警代码,如解密失败(decryption_failed)、记录溢出(record_overflow)、未知 CA(unknown_ca)、拒绝访问(access_denied)等。

  • 密文族和客户证书:SSLv3.0 和 TLS 存在少量差别,即 TLS 不支持 Fortezza 密钥交换、加密算法和客户证书。

  • certificate_verify 和 finished 消息:SSLv3.0 和 TLS 在用 certificate_verify 和 finished 消息计算 MD5 和 SHA-1 散列码时,计算的输入有少许差别,但安全性相当。

  • 加密计算:TLS 与 SSLv3.0 在计算主密值(master secret)时采用的方式不同。

  • 填充:用户数据加密之前需要增加的填充字节。在 SSL 中,填充后的数据长度要达到密文块长度的最小整数倍。而在 TLS 中,填充后的数据长度可以是密文块长度的任意整数倍(但填充的最大长度为 255 字节),这种方式可以防止基于对报文长度进行分析的攻击。

TLS 的主要增强内容

TLS 的主要目标是使 SSL 更安全,并使协议的规范更精确和完善。TLS 在 SSL v3.0 的基础上,提供了以下增强内容:

  • 更安全的 MAC 算法
  • 更严密的警报
  • “灰色区域”规范的更明确的定义

TLS 对于安全性的改进

  • 对于消息认证使用密钥散列法:TLS 使用“消息认证代码的密钥散列法”(HMAC),当记录在开放的网络(如因特网)上传送时,该代码确保记录不会被变更。SSLv3.0 还提供键控消息认证,但 HMAC 比 SSLv3.0 使用的(消息认证代码)MAC 功能更安全。
  • 增强的伪随机功能(PRF):PRF 生成密钥数据。在 TLS 中,HMAC 定义 PRF。PRF 使用两种散列算法保证其安全性。如果任一算法暴露了,只要第二种算法未暴露,则数据仍然是安全的。
  • 改进的已完成消息验证:TLS 和 SSLv3.0 都对两个端点提供已完成的消息,该消息认证交换的消息没有被变更。然而,TLS 将此已完成消息基于 PRF 和 HMAC 值之上,这也比 SSLv3.0 更安全。
  • 一致证书处理:与 SSLv3.0 不同,TLS 试图指定必须在 TLS 之间实现交换的证书类型。
  • 特定警报消息:TLS 提供更多的特定和附加警报,以指示任一会话端点检测到的问题。TLS 还对何时应该发送某些警报进行记录。

密钥协商过程——TLS 握手

SSL 协议分为两部分:Handshake Protocol 和 Record Protocol。其中 Handshake Protocol 用来协商密钥,协议的大部分内容就是通信双方如何利用它来安全的协商出一份密钥。 Record Protocol 则定义了传输的格式。

由于非对称加密的速度比较慢,所以它一般用于密钥交换,双方通过公钥算法协商出一份密钥,然后通过对称加密来通信,当然,为了保证数据的完整性,在加密前要先经过 HMAC 的处理。

SSL 缺省只进行 server 端的认证,客户端的认证是可选的。以下是其流程图(摘自 TLS 协议)。

客户端发出请求(ClientHello)

由于客户端(如浏览器)对一些加解密算法的支持程度不一样,但是在 TLS 协议传输过程中必须使用同一套加解密算法才能保证数据能够正常的加解密。在 TLS 握手阶段,客户端首先要告知服务端,自己支持哪些加密算法,所以客户端需要将本地支持的加密套件(Cipher Suite)的列表传送给服务端。除此之外,客户端还要产生一个随机数,这个随机数一方面需要在客户端保存,另一方面需要传送给服务端,客户端的随机数需要跟服务端产生的随机数结合起来产生后面要讲到的 Master Secret 。

综上,在这一步,客户端主要向服务器提供以下信息:

  • 支持的协议版本,比如 TLS 1.0 版
  • 一个客户端生成的随机数,稍后用于生成”对话密钥”
  • 支持的加密方法,比如 RSA 公钥加密
  • 支持的压缩方法

服务器回应(SeverHello)

上图中,从 Server Hello 到 Server Done,有些服务端的实现是每条单独发送,有服务端实现是合并到一起发送。Sever Hello 和 Server Done 都是只有头没有内容的数据。

服务端在接收到客户端的 Client Hello 之后,服务端需要将自己的证书发送给客户端。这个证书是对于服务端的一种认证。例如,客户端收到了一个来自于称自己是www.alipay.com的数据,但是如何证明对方是合法的alipay支付宝呢?这就是证书的作用,支付宝的证书可以证明它是alipay,而不是财付通。证书是需要申请,并由专门的数字证书认证机构(CA)通过非常严格的审核之后颁发的电子证书。颁发证书的同时会产生一个私钥和公钥。私钥由服务端自己保存,不可泄漏。公钥则是附带在证书的信息中,可以公开的。证书本身也附带一个证书电子签名,这个签名用来验证证书的完整性和真实性,可以防止证书被串改。另外,证书还有个有效期。

在服务端向客户端发送的证书中没有提供足够的信息(证书公钥)的时候,还可以向客户端发送一个 Server Key Exchange,

此外,对于非常重要的保密数据,服务端还需要对客户端进行验证,以保证数据传送给了安全的合法的客户端。服务端可以向客户端发出 Cerficate Request 消息,要求客户端发送证书对客户端的合法性进行验证。比如,金融机构往往只允许认证客户连入自己的网络,就会向正式客户提供 USB 密钥,里面就包含了一张客户端证书。

跟客户端一样,服务端也需要产生一个随机数发送给客户端。客户端和服务端都需要使用这两个随机数来产生 Master Secret。

最后服务端会发送一个 Server Hello Done 消息给客户端,表示 Server Hello 消息结束了。

综上,在这一步,服务器的回应包含以下内容:

  • 确认使用的加密通信协议版本,比如 TLS 1.0 版本。如果浏览器与服务器支持的版本不一致,服务器关闭加密通信

  • 一个服务器生成的随机数,稍后用于生成”对话密钥”

  • 确认使用的加密方法,比如 RSA 公钥加密

  • 服务器证书

客户端回应(Certificate Verify)

Client Key Exchange

如果服务端需要对客户端进行验证,在客户端收到服务端的 Server Hello 消息之后,首先需要向服务端发送客户端的证书,让服务端来验证客户端的合法性。

Certificate Verify

接着,客户端需要对服务端的证书进行检查,如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期,就会向访问者显示一个警告,由其选择是否还要继续通信。如果证书没有问题,客户端就会从服务器证书中取出服务器的公钥。然后,向服务器发送下面三项信息:

  • 一个随机数。该随机数用服务器公钥加密,防止被窃听

  • 编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送

  • 客户端握手结束通知,表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的 hash 值,用来供服务器校验

上面第一项的随机数,是整个握手阶段出现的第三个随机数,它是客户端使用一些加密算法(例如:RSA, Diffie-Hellman)产生一个 48 个字节的 Key,这个 Key 叫 PreMaster Secret,很多材料上也被称作 PreMaster Key。

ChangeCipherSpec

ChangeCipherSpec 是一个独立的协议,体现在数据包中就是一个字节的数据,用于告知服务端,客户端已经切换到之前协商好的加密套件(Cipher Suite)的状态,准备使用之前协商好的加密套件加密数据并传输了。

在 ChangecipherSpec 传输完毕之后,客户端会使用之前协商好的加密套件和 Session Secret 加密一段 Finish 的数据传送给服务端,此数据是为了在正式传输应用数据之前对刚刚握手建立起来的加解密通道进行验证。

服务器的最后回应(Server Finish)

服务端在接收到客户端传过来的 PreMaster 加密数据之后,使用私钥对这段加密数据进行解密,并对数据进行验证,也会使用跟客户端同样的方式生成 Session Secret,一切准备好之后,会给客户端发送一个 ChangeCipherSpec,告知客户端已经切换到协商过的加密套件状态,准备使用加密套件和 Session Secret 加密数据了。之后,服务端也会使用 Session Secret 加密一段 Finish 消息发送给客户端,以验证之前通过握手建立起来的加解密通道是否成功。

根据之前的握手信息,如果客户端和服务端都能对 Finish 信息进行正常加解密且消息正确的被验证,则说明握手通道已经建立成功,接下来,双方可以使用上面产生的 Session Secret 对数据进行加密传输了。

几个 secret

Secret Keys

上面的分析和讲解主要是为了突出握手的过程,所以 PreMaster secret,Master secret,session secret 都是一代而过,但是对于 Https,SSL/TLS 深入的理解和掌握,这些 Secret Keys 是非常重要的部分。所以,准备把这些 Secret Keys 抽出来单独分析和讲解。

我们先来看看这些 Secret Keys 的生成过程以及作用流程图:

PreMaster secret

PreMaster Secret 是在客户端使用 RSA 或者 Diffie-Hellman 等加密算法生成的。它将用来跟服务端和客户端在 Hello 阶段产生的随机数结合在一起生成 Master Secret。在客户端使用服务端的公钥对 PreMaster Secret 进行加密之后传送给服务端,服务端将使用私钥进行解密得到 PreMaster secret。也就是说服务端和客户端都有一份相同的 PreMaster secret 和随机数。

PreMaster secret 前两个字节是 TLS 的版本号,这是一个比较重要的用来核对握手数据的版本号,因为在 Client Hello 阶段,客户端会发送一份加密套件列表和当前支持的 SSL/TLS 的版本号给服务端,而且是使用明文传送的,如果握手的数据包被破解之后,攻击者很有可能串改数据包,选择一个安全性较低的加密套件和版本给服务端,从而对数据进行破解。所以,服务端需要对密文中解密出来对的 PreMaster 版本号跟之前 Client Hello 阶段的版本号进行对比,如果版本号变低,则说明被串改,则立即停止发送任何消息。

关于 PreMaster Secret(Key)的计算请参考 Https SSL/TLS PreMaster/Master Secret(Key)计算。

Master secret

上面已经提到,由于服务端和客户端都有一份相同的 PreMaster secret 和随机数,这个随机数将作为后面产生 Master secret 的种子,结合 PreMaster secret,客户端和服务端将计算出同样的 Master secret。

Master secret 是有系列的 hash 值组成的,它将作为数据加解密相关的 secret 的 Key Material 的一部分。Key Material 最终解析出来的数据如下:

其中,write MAC key,就是 session secret 或者说是 session key。Client write MAC key 是客户端发数据的 session secret,Server write MAC secret 是服务端发送数据的 session key。MAC(Message Authentication Code),是一个数字签名,用来验证数据的完整性,可以检测到数据是否被串改。

关于 Session Secret(Key)的计算请参考 Https SSL/TLS Session Secret(Key)计算。

应用数据传输

在所有的握手阶段都完成之后,就可以开始传送应用数据了。应用数据在传输之前,首先要附加上 MAC secret,然后再对这个数据包使用 write encryption key 进行加密。在服务端收到密文之后,使用 Client write encryption key 进行解密,客户端收到服务端的数据之后使用 Server write encryption key 进行解密,然后使用各自的 write MAC key 对数据的完整性包括是否被串改进行验证。

总结

SSL 客户端(也是 TCP 的客户端)在 TCP 链接建立之后,发出一个 ClientHello 来发起握手,这个消息里面包含了自己可实现的算法列表和其它一些需要的消息,SSL 的服务器端会回应一个 ServerHello,这里面确定了这次通信所需要的算法,然后发过去自己的证书(里面包含了身份和自己的公钥)。Client 在收到这个消息后会生成一个秘密消息,用 SSL 服务器的公钥加密后传过去,SSL 服务器端用自己的私钥解密后,会话密钥协商成功,双方可以用同一份会话密钥来通信了。

附:密钥协商的形象化比喻

如果上面的说明不够清晰,这里我们用个形象的比喻,我们假设 A 与 B 通信,A 是 SSL 客户端,B 是 SSL 服务器端,加密后的消息放在方括号[]里,以突出明文消息的区别。双方的处理动作的说明用圆括号()括起。

A:我想和你安全的通话,我这里的对称加密算法有 DES,RC5,密钥交换算法有 RSA 和 DH,摘要算法有 MD5 和 SHA。

B:我们用 DES-RSA-SHA 这对组合好了。 这是我的证书,里面有我的名字和公钥,你拿去验证一下我的身份(把证书发给 A)。 目前没有别的可说的了。

A:(查看证书上 B 的名字是否无误,并通过手头早已有的 CA 的证书验证了 B 的证书的真实性,如果其中一项有误,发出警告并断开连接,这一步保证了 B 的公钥的真实性) (产生一份秘密消息,这份秘密消息处理后将用作加密密钥,加密初始化向量(IV)和 hmac 的密钥。将这份秘密消息-协议中称为 per_master_secret-用 B 的公钥加密,封装成称作 ClientKeyExchange 的消息。由于用了 B 的公钥,保证了第三方无法窃听) 我生成了一份秘密消息,并用你的公钥加密了,给你(把 ClientKeyExchange 发给 B) 注意,下面我就要用加密的办法给你发消息了! (将秘密消息进行处理,生成加密密钥,加密初始化向量和 hmac 的密钥)

[我说完了]

B:(用自己的私钥将 ClientKeyExchange 中的秘密消息解密出来,然后将秘密消息进行处理,生成加密密钥,加密初始化向量和 hmac 的密钥,这时双方已经安全的协商出一套加密办法了) 注意,我也要开始用加密的办法给你发消息了!

[我说完了]

A: [我的秘密是…]

B: [其它人不会听到的…]

SSL 安全性

SecurityPortal 在 2000 年底有一份文章《The End of SSL and SSH?》激起了很多的讨论, 目前也有一些成熟的工具如 dsniff(http://www.monkey.org/~dugsong/dsniff/)可以通过man in the middle 攻击来截获 https 的消息。

从上面的原理可知,SSL 的结构是严谨的,问题一般出现在实际不严谨的应用中。常见的攻击就是 middle in the middle 攻击,它是指在 A 和 B 通信的同时,有第三方 C 处于信道的中间,可以完全听到 A 与 B 通信的消息,并可拦截,替换和添加这些消息。

SSL 可以允许多种密钥交换算法,而有些算法,如 DH,没有证书的概念,这样 A 便无法验证 B 的公钥和身份的真实性,从而 C 可以轻易的冒充,用自己的密钥与双方通信,从而窃听到别人谈话的内容。 而为了防止 middle in the middle 攻击,应该采用有证书的密钥交换算法。 有了证书以后,如果 C 用自己的证书替换掉原有的证书之后,A 的浏览器会弹出一个警告框进行警告,但又有多少人会注意这个警告呢? 由于美国密码出口的限制,IE,netscape 等浏览器所支持的加密强度是很弱的,如果只采用浏览器自带的加密功能的话,理论上存在被破解可能。

代理

下面探讨一下 SSL 的代理是怎样工作的 当在浏览器里设置了 https 的代理,而且里输入了https://www.example.com之后,浏览器会与proxy建立tcp链接,然后向其发出这么一段消息:

CONNECT server.example.com:443 HTTP/1.1
Host: server.example.com:443

然后 proxy 会向 webserver 端建立 tcp 连接,之后,这个代理便完全成了个内容转发装置。浏览器与 web server 会建立一个安全通道,因此这个安全通道是端到端的,尽管所有的信息流过了 proxy,但其内容 proxy 是无法解密和改动的(当然要由证书的支持,否则这个地方便是个 man in the middle 攻击的好场所,见上面的安全部分)。

CA 证书以及如何使用 OpenSSL 自签署,见文章 OpenSSL 自签署证书。

相关变量

  • SSL_CERT_FILE is the environment variable which identifies where to locate the SSL certificate file. If set this overrides the system default(参考 golang 的实现)
  • SSL_CERT_DIR 同上,参考

参考

  1. Keyless SSL The Nitty Gritty Technical Details
  2. Transport Layer Security (TLS)
  3. 传输层安全协议
  4. Survival guides - TLS/SSL and SSL (X.509) Certificates
Home Archives Categories Tags Statistics
本文总阅读量 次 本站总访问量 次 本站总访客数