CN110870277A - 将中间盒引入到客户端与服务器之间的安全通信中 - Google Patents

将中间盒引入到客户端与服务器之间的安全通信中 Download PDF

Info

Publication number
CN110870277A
CN110870277A CN201880042761.XA CN201880042761A CN110870277A CN 110870277 A CN110870277 A CN 110870277A CN 201880042761 A CN201880042761 A CN 201880042761A CN 110870277 A CN110870277 A CN 110870277A
Authority
CN
China
Prior art keywords
middlebox
endpoint
transport layer
client
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201880042761.XA
Other languages
English (en)
Other versions
CN110870277B (zh
Inventor
T·卡拉基亚尼斯
C·格坎特西迪斯
D·内勒
R·李
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Technology Licensing LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Technology Licensing LLC filed Critical Microsoft Technology Licensing LLC
Publication of CN110870277A publication Critical patent/CN110870277A/zh
Application granted granted Critical
Publication of CN110870277B publication Critical patent/CN110870277B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0464—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload using hop-by-hop encryption, i.e. wherein an intermediate entity decrypts the information and re-encrypts it before forwarding it
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/76—Proxy, i.e. using intermediary entity to perform cryptographic operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/062—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying encryption of the keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H04L63/205—Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Abstract

一种在第一端点与第二端点之间通过网络进行通信的方法，一个端点是客户端，另一端点是服务器。该方法包括：在第一端点与第二端点之间建立第一安全传输层通道，在第一端点与中间盒之间建立第二安全传输层通道，第一端点要将通过第一安全传输层通道发送的业务的处理委派给该中间盒；第一端点经由相应第二安全传输层通道验证中间盒，并且在上述验证的条件下经由第二安全传输层通道与中间盒共享第一通道的加密密钥；以及引起通过通道发送的业务经由中间盒被路由。该方法从而使得中间盒能够以明文方式处理通过第一通道发送的业务的内容。

Description

将中间盒引入到客户端与服务器之间的安全通信中
背景技术
因特网通信不再必须包括通过转储(dump)分组转发核来交换消息的两个端点。相反，数据经常由中间的中间盒(诸如高速缓存、压缩代理、入侵检测系统或病毒扫描器)处理。例如，美国所有四大移动运营商都使用HTTP代理，并且典型的企业网络具有的中间盒数量与路由器和交换机的数量大致相同。但是，随着在线加密的使用的增加(截至2014年，所有Web流中的几乎一半使用HTTPS)，这些中间盒对业务的内容变为“盲”，因此无法再执行其工作。这促使学术界和工业界考虑这个问题：如何将中间盒集成到安全的通信会话中？
因为TLS(因特网中使用的标准安全通信协议)是专为两方设计的，所以当前的做法是将连接拆分为两个单独的TLS连接：中间盒将服务器模拟为客户端并且打开到服务器的第二连接。但是这样做极大地削弱了安全性，部分原因是客户端无法显式地认证中间盒，也无法确保中间盒正确地认证了服务器。最近，诸如多上下文TLS(mcTLS)等提议已经通过允许端点对彼此以及对中间盒进行显式认证而解决了这一问题。
但是，新兴的中间盒部署模型使情况变得复杂：将中间盒功能外包给第三方(诸如提供中间盒即服务的ISP或第三方云提供者)。这保证了规模经济的成本效益，并且使网络管理员无需配置和管理多个专用盒。但是这也带来了新的挑战：中间盒软件的所有者(中间盒服务提供者)和运行它的硬件的所有者(基础结构提供者)是不同的。如果基础结构不可信，则如拆分TLS和mcTLS等现有协议就无法提供TLS今天为我们提供的标准安全属性，这是因为首先，会话数据和密钥在存储器中可见，其次，端点无法确定基础结构提供者是否实际上运行中间盒提供者预期其运行的代码。
一个已知的想法是使用新的密码技术来保护会话数据不受基础结构提供者的侵害。BlindBox和Embark引入了新技术，这些技术允许中间盒直接处理密码数据。这些工作基于与加密数据相匹配的模式，而不需要对其进行解密。
发明内容
尽管从隐私角度来看很有吸引力，但是这些解决方案仅支持执行模式匹配的中间盒，如入侵检测系统。它们仍然无法访问加密业务的实际(明文)内容。这表示它们在它们能够做的事情方面受到限制。首先，它们是点解决方案，即它们只能在特定任务的特定实例上工作。其次，它们无法执行任何需要了解实际内容的任务。需要对加密内容进行操作也使它们非常慢。此外，现有方法要求两个端点都升级，这是部署的重大障碍。
期望提供一种技术，该技术使得中间盒能够对业务的内容进行操作，但是同时仍然保持安全性。优选地，也期望能够以不必依赖于两个端点被升级的方式来做到这一点，使得即使一个端点被升级以识别新协议并且另一端点是传统端点，该技术仍然起作用。
根据本公开的一个方面，提供了一种在第一端点与第二端点之间通过网络进行通信的方法，第一端点是客户端设备或服务器，并且第二端点是客户端设备和服务器中的另一者。该方法包括在第一端点与第二端点之间建立第一安全传输层通道，该第一安全传输层通道由访问通过第一安全传输层通道发送的业务的内容所需要的第一密码密钥限定。该方法还包括在第一端点与中间盒之间建立第二安全传输层通道，第一端点要将通过第一安全传输层通道发送的业务的处理委派给该中间盒，第二安全传输层通道由访问通过第二安全传输层通道发送的内容所需要的第二密码密钥限定。第一端点经由相应第二安全传输层通道来验证(例如，认证)中间盒，并且在上述验证的条件下经由第二安全传输层通道与中间盒共享第一加密密钥。此外，通过通道发送的业务经由中间盒被路由。从而，该方法使得中间盒能够使用第一密码密钥以明文方式处理通过第一安全传输层通道发送的业务的内容。
因此，通过经由辅助(即，辅)安全通道来验证(例如，认证)其中间盒，第一端点可以在将中间盒引入第一通道(即，主要或主通道)之前确定该中间盒是可信的。第二端点信任第一端点，并且第一端点信任中间盒。此外，由于仅在第一端点及其中间盒之间执行将中间盒引入主要通道所需要的握手，因此第二端点不必要了解中间盒或者以任何方式升级以识别新协议。从第二端点的角度来看，它似乎只是与第一端点通信。
在实施例中，所公开的协议通过在所谓的“包围区”中隔离中间盒执行环境与第三方基础结构，即在第三方的操作系统上运行的任何其他应用不可访问的隔离执行环境，进一步保护会话数据免受第三方基础结构提供者的侵害。在实施例中，第三方的操作系统本身或任何管理程序也不能访问该执行环境。
在其他替代或附加实施例中，所公开的协议提供了多方设置中可能是有利的其他有用的安全属性。例如，在实施例中，所公开的协议保证数据按端点指定的顺序访问中间盒，并且防止攻击者了解在继续转发数据之前中间盒是否修改了数据。
提供本“发明内容”以便以简化的形式介绍一些概念，这些概念将在下面的“具体实施方式”中进一步描述。本“发明内容”既不旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用于限制所要求保护的主题的范围。所要求保护的主题也不限于解决本文中描述的任何或所有缺点的实现。
附图说明
为了帮助理解本公开的实施例并且示出它们如何能够生效，仅以示例的方式参考附图，在附图中：
图1是用于经由一个或多个中间盒在客户端与服务器之间进行通信的通信系统的示意图；
图2a是在客户端与服务器之间建立的通道中包括中间盒的方法的示意图；
图2b是经由中间盒进行通信的另一方法的示意图；
图3是用于在经由多个中间盒进行的通信中保持中间盒顺序的技术的示意图；以及
图4是示出建立安全TLS通道并且将中间盒引入该通道的方法的示意性信令图。
具体实施方式
如上所述，当今的因特网通信通常涉及中间的中间盒，如高速缓存、压缩代理或病毒扫描器。随着加密变得越来越普遍，这些中间盒变为盲，无法提供其安全性、功能性和性能优势。尽管工业界和学术界都做出了努力，但是目前还没有办法将中间盒集成到安全会话中，同时保留中间盒和安全会话的功能。
以下内容提出了一种用于将一个或多个中间盒引入安全通道，例如用于安全的多方通信会话中的协议。该协议为会话(诸如多方通信会话)提供了一组安全属性。在实施例中，即使端点(客户端或服务器)之一仍然是尚未升级以识别该协议的传统端点，该协议也仍然有效。在实施例中，协议使用SGX包围区等来在不可信的硬件上提供安全保证。在实施例中，如果在链中引入了多个中间盒，则协议还保留业务通过每个中间盒的顺序。
该协议有利地解决了两个彼此竞争的需求。一方面，因特网通信不再限于通过转储分组转发核来交换消息的两个端点。相反，数据通常由中间的中间盒(诸如高速缓存、压缩代理、入侵检测系统或病毒扫描器)处理。但是，另一方面，随着在线加密的使用的增加，这些中间盒变为盲，无法再执行其工作。希望能够保留这种加密的安全性，同时允许使用中间盒，包括第三方中间盒的可能性。
例如，考虑将中间盒功能外包给提供中间盒即服务的ISP或第三方云提供者的做法越来越多。这保证了规模经济的成本效益，并且使网络管理员无需配置和管理多个专用盒。但是，该设置也带来了新的挑战：中间盒软件的所有者(中间盒服务提供者)和运行它的硬件的所有者(基础结构提供者)是不同的。如果基础结构不可信，则现有协议无法提供TLS今天为我们提供的标准安全属性，这是因为(i)会话数据和密钥在存储器中可见，并且(ii)端点无法确定基础结构提供者是否实际上运行中间盒提供者预期其运行的代码。
图1示出了根据本公开的实施例的联网计算机系统。该系统包括优选地是诸如通常被称为因特网的广域网的形式的分组交换数据网络101。该系统还包括为用户终端102的形式的多个客户端设备，每个客户端设备由相应用户103使用。每个用户终端102可以采用多种潜在形式中的任何一种，例如，静态用户终端(诸如台式计算机)或移动终端(诸如膝上型计算机、平板计算机、智能电话或可穿戴设备(例如，智能手表或智能眼镜))。每个用户终端102被配置为经由合适的有线或更普遍地是无线接入技术连接到网络101，例如，经由无线局域网(WLAN)的本地无线路由器或接入点；或经由移动蜂窝网络，诸如3GPP网络(例如，3G、LTE、4G或5G网络)；或经由本地有线网络，诸如以太网；或经由有线调制解调器，有线调制解调器经由PSTN或电缆网络连接到网络101。本领域技术人员将熟悉各种其他方式。还应当注意，不同的用户终端不必要采用彼此相同的形式，也不必要经由相同的方式连接到网络101。
系统还包括服务器104，服务器104也连接到网络101。注意，本文中所指的服务器是指可以包括位于一个或多个地理位置的一个或多个物理服务器单元的任何服务器设备。在多个单元(所谓的“云”计算或云存储布置)的情况下，本领域技术人员将熟悉用于分布式存储和分布式计算的合适的技术本身。而且，用于将(多个)服务器单元连接到网络101以及在分布式系统的情况下彼此连接的各种合适的有线或无线方式也是本领域技术人员已知的(例如，上面讨论的那些或其他)。
通过物理上实现的任何手段，服务器104被配置为托管服务软件106。服务软件106采用存储在服务器104的存储装置上并且被布置为在服务器104的处理装置上运行的代码的形式。服务软件106被配置为使得当以这种方式运行时经由网络101向客户端设备102及其用户103提供服务。所提供的服务可以采用多种形式中的任何一种，例如云存储服务、协作工作空间服务、VoIP或视频会议服务等。无论应用是什么，服务软件106还被配置为根据本文中公开的任何方法来执行服务器侧功能。在本文中将操作归因于服务器104的情况下，应当理解，这是指由在服务器104上运行的服务软件106执行的操作的简写。
存储有服务软件106的存储装置(存储器)可以采用在任何一个或多个服务器单元中实现的一个或多个存储器单元上实现的一个或多个存储器单元的形式，采用任何合适的一个或多个存储器介质，例如诸如硬盘驱动器等磁性介质、诸如EEPROM、闪存或固态驱动器(SSD)等电子介质、或甚至光学介质。运行服务软件106的服务器104的处理装置可以包括以任何一个或多个服务器单元实现的一个或多个单核或多核处理单元。这样的处理单元可以包括例如CPU和/或工作加速器处理器，诸如GPU等。各种合适的物理处理器装置本身将是本领域技术人员熟悉的。
每个用户终端102安装有客户端应用105的相应实例。客户端应用105采用存储在相应用户终端102的存储装置上并且被布置为在相应用户终端102的处理装置上运行的软件的形式。客户端应用105被配置为当这样运行时经由网络101和相应用户终端102的任何合适的有线或无线网络接口(例如，被配置为经由任何上述装置进行连接的网络接口)访问服务器104上的服务软件106。客户端应用105还被配置为根据本文中描述的任何方法来执行客户端侧功能。在本文中将操作归因于客户端设备102或仅归因于“客户端”的情况下，应当理解，这是指由在相应客户端设备102上运行的客户端应用105执行的操作的简写。
存储有客户端应用105的每个相应实例的存储装置(存储器)可以采用相应用户终端102的一个或多个存储器单元的形式，采用任何合适的一个或多个存储器介质，例如诸如硬盘驱动器等磁性介质、诸如EEPROM、闪存或固态驱动器(SSD)等电子介质、或诸如CD ROM或DVD驱动器等光学介质。运行客户端应用105的相应实例的相应用户终端102的处理装置可以包括一个或多个单核或多核处理单元。这样的处理单元也可以包括CPU和/或工作加速器处理器，诸如GPU等。各种合适的物理处理器装置本身也将是本领域技术人员熟悉的。
此外，计算机系统包括在一个或多个中间网络设备107上运行的一个或多个中间盒108。中间盒108是客户端或服务器将要对业务执行的某些操作推迟到其(而不仅仅是分组转发)的实体。通常，这将包括一些需要访问业务的内容的操作，即明文(解密)有效负载。这样的中间盒108可以包括例如以下中的任何一个或多个：病毒扫描器、儿童安全过滤器(例如，父母控制过滤器)、入侵检测器、压缩代理、音频和/或视频代码转换器、HTTP代理、应用层负载平衡器和/或高速缓存。
中间盒108可以包括客户端102向其推迟一个或多个操作的一个或多个客户端中间盒108-C、和/或服务器104向其推迟一个或多个操作的一个或多个服务器中间盒108-S。
每个中间盒108采用存储在其相应网络设备107的存储装置中并且被布置为在相应网络设备的处理装置上运行的软件的形式。所使用的存储也可以包括在一个或多个地理位置处的一个或多个物理存储单元，并且可以使用一个或多个存储介质(例如，诸如硬盘驱动器等磁性介质、或者诸如EEPROM、闪存或SSD等电子介质等)。处理装置也可以包括一个或多个单核或多核处理单元，例如，CPU和/或工作加速器处理器等。同样，用于将中间盒设备108连接到网络101的各种合适的有线或无线装置也是本领域技术人员已知的(例如，上面讨论的那些或其他)。同样，各种合适的物理存储装置、处理器和网络接口装置本身将是本领域技术人员熟悉的。中间盒108可以在彼此分离的物理单元中或在同一物理单元中实现。中间盒设备108可以在客户端设备102和服务器104两者外部，或者甚至可以与服务器104在同一物理设备中实现。
无论物理实现采用什么形式，客户端102都被配置为经由一个或多个中间盒108-C、108-S通过网络101与服务器104建立安全传输层通道201。该通道201可以包括由客户端102引入到通道201中的客户端102的一个或多个中间盒；和/或由服务器204引入通道中的服务器104的一个或多个中间盒108。通道的建立由客户端102发起。
优选地，安全传输层通道201采用使用TLS(传输层安全性)协议而建立的TLS通道的形式。以下将在TLS通道方面来描述实施例，但是不排除将使用其他类型的安全传输层协议来实现本文中公开的方法，例如，技术人员可以使用他/她的本领域技术来设计的诸如SSL(安全套接字层)或TLS的将来变体等传统协议。
传输层是OSI模型的在分组层之上的层，例如：在基于IP(因特网协议)的网络(诸如因特网)中位于IP层之上。该通道是“安全的”，因为通过该通道发送的业务的内容被加密(使用本领域技术人员将熟知的已知密码技术本身)。安全传输层通道至少部分由解密通过该通道发送的业务所需要的密码密钥来限定。在将中间盒108引入TLS通道201的情况下，这表示它已经获取相关通道的密钥并且通过该通道发送的业务经由所涉及的中间盒108被路由。
如图2a所示，这是通过在中间盒108与该中间盒所属的端点(客户端102或服务器104)之间建立的辅助安全传输层通道202(优选地还为TLS通道)来实现的。为了便于讨论，所涉及的中间盒108是服务器104的中间盒，即服务器104将要对客户端102与服务器104之间的业务执行的某种操作委派给其的中间盒108-S(尽管，替代地或另外地，可以加上必要的变更地使用相同的过程以使客户端102能够引入客户端102的中间盒108-C)。
根据本文中公开的协议，服务器104经由网络101与其中间盒108-S建立辅助(即，辅)TLS通道202。然后，服务器104使用该通道来验证中间盒。优选地，这至少包括：验证被联系的中间盒108-S是由预期方(例如，预期的第三方)提供的。在实施例中，该验证包括通过第二TLS通道202执行认证以认证提供中间盒的一方是可信方。这可以采用本身在本领域中已知的多种可能的认证技术中的任何一种。此外，在实施例中，经由第二TLS通道202执行的验证可以替代地或另外地包括验证所联系的中间盒108-S提供期望服务。例如，如果服务器需要病毒扫描服务，则服务器104验证所涉及的中间盒108-S包括病毒扫描器，并且它是特定病毒扫描器。在实施例中，这包括验证对包围区进行初始化的二进制文件，这表示特定版本的特定病毒扫描器。
一旦该验证完成，并且在肯定验证的条件下，服务器104然后通过辅助TLS通道202与中间盒108-S共享用于主要(主)TLS通道201的密码安全密钥。
从一开始，服务器104就将其IP地址或域名作为服务器的中间盒108-S的IP地址或域名通告给客户端102，使得当客户端102发送建立主要TLS通道201并且随后通过主要TLS通道201发送业务的消息时，所有这些消息和业务都经由中间盒108-S路由到服务器104，其中中间盒108-S被设置以便将它们转发到服务器104。一种替代方案是在网络101中配置路由协议/或转发机制以将目的地为服务器104的业务转发到中间盒108-S。从服务器104发送回客户端102的消息和业务也经由中间盒108-S被路由。此外，一旦其具有地址和密钥，中间盒108-C就可以访问经由中间盒108-S传递的任何业务的实际(解密的)内容。这使得其能够执行其作为中间盒的功能，例如病毒扫描器或父母过滤器。
因为客户端102信任服务器104(已经经由主TLS通道201进行认证)，并且服务器104信任中间盒108-S，所以实际上可以认为客户端102信任服务器的中间盒108-S——即使客户端102实际上不一定需要知道它经由中间盒108-S进行通信而与其直接与服务器104建立传统TLS通道进行任何不同操作。后一种观点表示，服务器104可以用新协议进行升级，而客户端102在实施例中仍然可以是传统客户端。
如果客户端102不是传统客户端，则可以关于客户端102及其中间盒108-C加上必要的变更地使用相同的过程。也就是说，客户端102建立相应辅助TLS通道(如果两者都使用中间盒，则与服务器104建立的通道不同)，并且使用该通道来验证相应中间盒108-C。然后，它使用该通道共享主要通道的加密密钥。客户端102还将其IP地址或域名作为客户端的中间盒108-C的IP地址或域名通告给服务器104，否则，网络101中的路由协议和/或转发机制被配置为将目的地为客户端102的业务转发到其中间盒108-C。因此，使得经由客户端的中间盒108-C发送的业务对于该中间盒108-C是可访问的(以明文方式)，从而使得其能够代表客户端102执行其中间盒功能。在实施例中，服务器104不需要被升级以识别新的协议，而是可以是传统服务器104。替代地，客户端102和服务器104都可以使用它们自己的中间盒108-C、108-S，在这种情况下，客户端102和服务器104每个经由不同的相应辅助TLS通道202执行协议的单独的实例。
该协议的示例实现在图4中更详细地示出，以在稍后将更详细地讨论。用实线示出的步骤表示主要握手的步骤，由此客户端102与服务器104建立主要安全传输层通道。用虚线示出的步骤表示客户端侧的辅助握手的步骤，由此客户端102与其中间盒108-C建立相应辅助安全通道，经由该辅助通道验证该中间盒108-C，然后经由相应辅助通道与相应中间盒108-C共享用于主要通道201的安全密钥。用虚线示出的步骤表示服务器侧上的辅助握手的步骤，由此服务器104与其中间盒108-S建立相应辅助安全通道，经由该辅助通道验证该中间盒108-S，然后经由相应辅助通道与相应中间盒108-S共享用于主要通道201的安全密钥。
对于客户端侧中间盒108-C，当客户端102发送请求发起主要TLS通道的标准TLS消息时，它在其中包括一种新型TLS扩展，以声明其对中间盒的支持。该消息经由中间盒108-C发送到服务器104。该扩展触发中间盒108-C开始与客户端102握手以建立辅助TLS通道。对于在传统客户端不包括新TLS扩展的情况下的服务器侧中间盒，服务器中间盒108-S自主地向服务器104发送声明自己的新型(非标准)TLS消息，这开始与服务器104握手以建立辅助TLS通道。
一旦建立了主要通道201并且成功地引入了任何所需要的中间盒108，就可以将主要TLS通道201用于程序员期望的任何应用。例如，主要TLS通道201可以用于进行多部分通信会话，包括客户端102(例如，图1中的客户端102a)和一个或多个另外的客户端102b、……、102n，它们均经由服务器104和主要TLS通道201彼此通信。例如，会话可以包括多方VoIP呼叫、视频呼叫或其他媒体会话，诸如远程幻灯片演示、屏幕共享会话或虚拟白板。
如图2b所示，在实施例中，中间盒108(或每个中间盒108)优选地在其相应网络设备108上的安全“包围区”中运行。这是一个安全的虚拟环境，其中中间盒108和它通过安全TLS通道201、202接收的数据与在同一网络设备107的操作系统上运行的其他应用隔离。也就是说，即使在同一物理设备上运行，也没有其他应用可以访问该数据。合适的安全包围区的示例包括SGX(软件防护扩展)、TrustZone(信任区域)、SEV(安全加密虚拟化)等。在诸如SGX等情况下，操作系统本身也像任何管理程序一样无法访问包围区内的数据。
如图3所示，在其他替代或附加实施例中，可以将多个中间盒108的链引入主要TLS通道201中，包括一个或多个客户端102和一个或多个服务器104(使得客户端102和服务器中的一者或两者可以具有相应的多个中间盒108)。在多个客户端侧中间盒108-C的情况下，客户端102与每个建立不同的相应辅助TLS通道，以便根据上述过程将相应中间盒108-C引入主要TLS通道。类似地，在多个服务器侧中间盒108-S的情况下，服务器104与服务器侧中间盒108-S中的每个建立不同的相应辅助TLS通道，同样根据上述过程。
客户端102将消息和业务转发到链中的第一(最近的)客户端侧中间盒108-C，并且该中间盒将它们转发到链中的下一客户端侧中间盒108-C，以此类推。最远的客户端侧中间盒108-C将消息和业务转发到距离服务器104最远的服务器侧中间盒108-S，服务器侧中间盒108-S将它们转发到链中的下一服务器侧中间盒108-S，以此类推，直到服务器侧的直接(最近的)中间盒108-S转发到服务器104。注意，这里的“最近的”和“最远的”是指跃点数，不一定是物理距离。当从服务器104向客户端102发送业务和消息时，该过程以相同的方式但是在相反的方向上进行。
此外，根据本文中公开的特定实施例，当在客户端102与服务器104之间的主要TLS通道201上发送业务时，应用一种技术以确保中间盒顺序。当业务沿着客户端102与其直接(最近的)客户端侧中间盒108-C1之间的直接跃点被路由时，使用第一客户端侧加密密钥K_C-C1对业务进行加密。当业务沿着该客户端侧中间盒108-C1与距离客户端102下一最远的客户端侧中间盒108-C0之间的下一跃点被路由时，使用不同的第二客户端侧加密密钥K_C1-C0对业务进行加密，以此类推。当业务沿着服务器104与其直接(最近的)服务器侧中间盒108-S1之间的直接跃点被路由时，使用第一服务器侧加密密钥K_S1-S对业务进行加密。当业务沿着该服务器侧中间盒108-S1与距离服务器104下一最远的服务器侧中间盒108-S0之间的下一最远跃点被路由时，使用不同的第二客户端侧加密密钥K_S0-S1对业务进行加密，以此类推。注意，这些加密密钥与用于验证中间盒108并且与它们共享主要TLS通道的密钥的辅助TLS通道的加密密钥不同。
在距离客户端102最远的客户端侧中间盒108-C与距离服务器最远的服务器侧中间盒108-S之间，使用主要TLS通道的主要加密密钥K_C-S来交换业务。注意：这里假定客户端侧和服务器侧中间盒108-C、108-S不会彼此混合，例如服务器侧中间盒108-S不能比任何客户端侧中间盒108-C更靠近客户端。实现这一点的方式如下：中间盒108观察来自其他中间盒108的业务，并且如果它们看到来自不同类型的中间盒的业务(例如，客户端侧中间盒108-C看到服务器中间盒业务)，则它们禁用自己。
因此，每个跃点上的业务使用不同的相应的唯一加密密钥来加密。也就是说，在每个跃点处的接收中间盒108使用前一跃点的密钥设置来解密，然后使用新的密钥来重新加密下一直接跃点，使得下一中间盒可以解密。这样可以确保中间盒必须按链中的期望顺序分别处理业务，否则中间盒将无法解密业务的内容。而且，另一好处是，窃听业务的任何恶意第三方甚至都无法确定链中的任何给定中间盒108是否已经修改业务，因为加密形式的业务在沿着路由的任何跃点处无论如何都会看起来不同(对于某些对安全性敏感的应用，以及窃听者无法查看业务的明文内容，还希望窃听者甚至无法确定业务的内容是否已经被修改)。
现在将参考图2a至4更详细地讨论一些其他示例性实现细节。
如前所述，因特网通信不再限于通过转储分组转发核来交换消息的两个端点。相反，数据经常由中间的中间盒(诸如高速缓存、压缩代理、入侵检测系统或病毒扫描器)处理。例如，美国所有四大移动运营商都使用HTTP代理，并且典型的企业网络具有的中间盒数量与路由器和交换机的数量大致相同。随着在线加密的使用的增加(截至2014年，所有Web流中的几乎一半使用HTTPS)，这些中间盒变为盲，并且无法再执行其工作，这促使学术界和工业界考虑以下问题：如何将中间盒集成到安全的通信会话中？
因为TLS(因特网中使用的标准安全通信协议)是专为两方设计的，所以当前的做法是将连接“拆分”为两个单独的TLS连接：中间盒将服务器模拟为客户端并且打开到服务器的第二连接。这样做极大地削弱了安全性，部分原因是客户端无法显式地认证中间盒，也无法确保中间盒正确地认证了服务器。最近，诸如多上下文TLS(mcTLS)等建议已经通过允许端点对彼此以及对中间盒进行显式认证而解决了这一问题。但是，情况通过新兴的中间盒部署模型变得复杂：将中间盒功能外包给提供中间盒即服务的第三方云提供者或ISP。这保证了规模经济的成本效益，并且使网络管理员无需配置和管理多个专用盒。这提出了新的挑战：中间盒软件的所有者(中间盒服务提供者)和运行它的硬件的所有者(基础结构提供者)是不同的。如果基础结构不可信，则如“拆分TLS”和mcTLS等现有协议无法提供TLS今天为我们提供的标准安全属性，这是因为首先，会话数据和密钥在存储器中可见，其次，端点无法确定基础结构提供者是否实际上运行中间盒提供者预期其运行的代码。
现有的想法是使用新的密码技术来保护会话数据不受基础结构提供者的侵害。BlindBox和Embark引入了新颖的密码技术，这些密码技术允许中间盒直接处理加密数据。尽管从隐私角度来看很有吸引力，但BlindBox(到目前为止)在实践中太慢而无法部署，并且这些解决方案仅支持执行模式匹配的中间盒，如入侵检测系统。更糟糕的是，BlindBox和mcTLS要求两个端点都进行升级，这是部署的重大障碍。下文中提出了在本文中称为中间盒TLS(mbTLS)的协议，这是一种用于解决这些缺点的用于安全多方通信的协议。
(i)mbTLS保护来自第三方基础设施提供者的会话数据。mbTLS利用可信的计算技术(例如，Intel SGX[12、29、20])将中间盒执行环境与第三方基础结构隔离。它使用由如SGX等平台通常提供的两个特征：安全执行环境——中间盒应用的代码、堆和堆栈被加密并且在存储器中被完整性保护；以及远程证明——中间盒可以通过加密方式向端点证明执行环境被正确配置。
(ii)mbTLS与传统TLS端点互操作。与mcTLS或BlindBox不同，mbTLS端点可以在与未经修改的TLS端点的会话中安全地包括中间盒。在测试中，发明人使用mbTLS客户端成功地从300多个顶级Alexa站点加载了内容。
(iii)mbTLS提供了多方设置独有的其他有用的安全属性。例如，mbTLS保证了数据按端点指定的顺序访问中间盒，并且mbTLS阻止攻击者了解在继续转发数据之前中间盒是否修改了数据。
实施例使用OpenSSL和Intel SGX SDK来实现mbTLS。与TLS相比，mbTLS没有增加握手延迟，并且mbTLS减少了中间盒上的CPU负载，并且仅增加了服务器上的合理开销。此外，在SGX包围区内部运行不会降低吞吐量。mbTLS是桥接端到端安全性与中间盒不会消失的现实之间的间隙迈出的重要且实际的一步。
如今，大多数网络通信会话都涉及更多方，而不仅仅是客户端和服务器。总的来说，这些其他方属于以下三类之一：
·网络层中间盒(例如，防火墙、NAT、第3层负载平衡器)。这些中间盒逐分组地处理数据，不需要重建或访问应用层数据。
·应用层中间盒(例如，病毒扫描器、IDS、父母过滤器、高速缓存、压缩代理、应用层负载平衡器)。这些中间盒确实需要访问应用层数据。
·应用层代表(例如，CDN)。与在通信时充当客户端与服务器之间的中介的中间盒相反，本文中引入术语“委派”一词是指在会话期间担当服务器角色的中介(尽管在现实世界关系中，它们仍然更自然地被视为中介)。内容交付网络(CDN)是一个很好的示例；客户端与CDN服务器通信，并且不与原始服务器直接交互。
随着安全实践的改善以及向加密无处不在的因特网发展，很明显，目前尚不存在用于安全的多方通信的适当协议，现有文献也没有公开应当提供的属性。
在两方的情况下，众所周知什么安全性属性是理想的，以及如何实现它们——TLS已经成功使用了多年。但是在多方情况下，仍然存在两个关键的未解决问题。首先，对于涉及三方或更多方的会话，应当持有哪些安全属性？其次，加强这些属性的最佳机制是什么？
对于这三类中介中的每一类，这些问题的答案可能有所不同。本公开集中讨论应用层中间盒，在实施例中，集中讨论涉及应用层中间盒的安全多方通信。即使在仅应用层中间盒中，安全需求也可能存在差异。例如，入侵检测系统和压缩代理的行为截然不同，管理员指定的病毒扫描器与选择加入的压缩服务之间的信任关系也不同，这表明可能没有单一的一刀切的解决方案。但是，在实践中可能至少需要两个特定的要求。
一种是在外包中间盒的情况下保护会话数据。在第三方环境中部署中间盒的兴趣日益浓厚。这可以采用至少两种可能的形式之一。首先，可以将网络功能外包给专门操作中间盒的云提供者，从而使网络管理员无需学习操作专用盒，并且利用规模经济来降低成本。其次，在客户端ISP中部署中间盒可以帮助降低延迟或带宽成本(例如，使用客户端ISP中的节点的网络代理连接)。在这两种情况下，网络功能的逻辑所有者和运行它的硬件的操作者是不同的。由于可能不信任中间盒基础结构，因此除了传统的网络攻击者，希望还保护会话数据不受中间盒基础结构的攻击。
另一理想的要求是传统的互操作性。如BlindBox和mcTLS等协议都需要升级两个端点。其他协议要求至少升级客户端，这表示服务器在与传统客户端的会话中不能包括中间盒。但是，实际上，等待因特网中的每个客户端都被升级并不是一种选择；鉴于已经拦截了多达10％的HTTPS连接，这一点尤其正确。因此，希望支持传统端点。
目前，网络管理员或使用“拆分TLS”方法运行本地病毒/恶意软件扫描软件的最终用户有时会将中间盒插入加密连接中。中间盒(或客户端侧软件)终止TLS连接以假装成为服务器，并且打开与预期服务器的第二TLS连接。
中间盒为服务器的域名动态地生成凭证，并且使用自己的CA密钥对其进行签名，该CA密钥已经预先安装在客户端上。最近的一项研究发现，几乎所有使用这种方法的流行的中间盒都降低了连接安全性，并且其中一些引入了严重的漏洞；其中的大多数是由于客户端无法直接认证或与服务器协商密码。最近的行业建议提供了更高的透明度，但是仍不能向客户端保证中间盒不会降低会话安全性。
以下威胁模型描述了由本文中公开的实施例解决的目标场景。
·角色。有六个主要角色。每个标记在本文中标记为“可信”或“不可信”，其中可信表示角色被授权访问会话数据。注意，最后三个角色特定于多方通信，最后一个角色特定于外包的中间盒场景。
·客户端(C)[可信]：用户、其机器以及其运行的软件(例如，web浏览器)。可以假定在机器上运行的任何其他软件是可信的(即，该软件的不当行为不在范围内)。
·服务提供者(S)[可信]：提供在线服务的公司、其服务器及其运行的软件(例如，web服务器)。与客户端一样，出于目前的目的，可以假定在公司自身服务器上运行的其他软件或恶意员工没有进行任何攻击。
·第三方(TP)[不可信]：有权访问网络业务(或这样的业务的日志)的任何其他人，诸如ISP或咖啡店的Wi-Fi截取器(sniper)。
·中间盒服务(MS)[可信]：处理会话数据的中间盒软件。
·中间盒服务提供者(MSP)[可信]：提供中间盒服务的实体以及存储与该服务有关的信息的任何内部服务器。
·中间盒基础结构提供者(MIP)[不可信]：提供运行中间盒软件的硬件的实体，诸如客户ISP或专用的云中间盒服务。可以假定该公司、其雇员、其硬件以及在其机器上运行的任何其他软件均不可信。
对手能力：以下内容假定活跃的全局对手可以观察并且控制系统的任何不可信部分。在网络中，对手可以观察、修改或丢弃任何分组并且注入新分组。在中间盒基础结构上，对手可以完全访问所有硬件(例如，它可以读取和操纵存储器)和软件(例如，它可以执行任意代码，包括特权代码，如恶意OS)。这包括修改或替换由MSP发送以由MIP执行的中间盒代码的能力。但是，假定对手受到了计算限制(即，不能破坏标准的密码原语)并且不能损害可信的计算硬件(例如，启用Intel SGX的CPU)。旁路攻击(例如，基于业务或高速缓存访问模式)、中间盒软件中的可利用漏洞以及拒绝服务不在范围之内。
安全属性：可以通过以下四个属性P1至P4限定与应用层中间盒的“安全”多方通信。
P1：数据保密。P1A：对手必须不能读取会话数据。P1B：通信应当是前向秘密的(长期私钥的泄露不会帮助攻击者访问先前会话的数据)。P1C：与每个跃点都是其自己的独立TLS连接相比，对手从观察密文中不应当了解到更多东西(例如，对手不应当了解在转发数据之前中间盒是否修改了数据)。
P2：数据认证。对手应当不能修改、删除或注入会话数据。这包括重放或重新排序数据。
P3：实体认证。端点必须能够验证它们与“正确的事物”进行通信。这包含两个巧妙地交织的属性。P3A：每个端点都可以验证另一端点是否由预期实体操作并且每个MS是否由预期MSP操作(例如，视频共享服务的服务器)。P3B：每个端点都可以验证另一端点和每个MS是否正在运行预期的软件并且被正确配置(例如，仅启用了强TLS密码套件的Apachev2.4.25)。
P4：路径完整性。端点修复会话的中间盒的有序路径。任何其他实体(包括中间盒)都不可能导致中间盒以不同的顺序处理会话数据(包括跳过中间盒)。
注意，前三个属性是TLS为两方通信提供的相同属性，但是扩展到多方设置；第四路径完整性仅在三个或三个以上各方存在时才会出现(路径顺序会影响安全性，尤其是在中间盒执行过滤和/或清理功能时)。
由于TLS已经提供了很多期望属性，因此一种方法是：在客户端与服务器之间建立常规的TLS会话，然后将会话密钥通过单独的辅助TLS会话传递给中间盒。这在图2a中示出。这提供了很多期望的安全属性：对数据进行加密和完整性保护以防止来自第三方的改变；如果使用了前向安全密码套件，则通信是前向秘密的，并且端点可以使用凭证来验证彼此的身份。
但是，由于上述三个原因，按照上述威胁模型，以这种方式使用TLS是次优选的实施例：(I)由于它是为两方设计的，因此它没有用于提供路径完整性的机制(P4)；(II)在会话中的每个跃点上使用相同的密钥进行加密，从而使对手可以轻松地比较进入和离开中间盒的记录以查看它们是否发生改变(P1C)；以及(III)基础结构提供者可以访问存储器中的会话数据(P1A)，访问存储器中的密钥材料并且使用它来伪造MAC(P2)，并且有可能运行由MSP提供的软件以外的软件(P3B)。
在实施例中，这些问题通过对图2a的方法进行两个进一步的高级改变来解决。这在图2b中示出，其中为每个跃点生成唯一密钥，并且中间盒在安全执行环境中运行。该结果在本文中可以称为中间盒TLS(mbTLS)。首先，修改握手以将唯一的对称密钥分配给会话中的每个跃点。这防止了对手将记录传递到乱序的中间盒，并且使得无法确定中间盒何时在不改变数据的情况下转发数据。其次，如果需要保护基础设施，则可以在安全的执行环境(如Intel SGX包围区)中运行中间盒以保护会话数据和密钥免受不可信MIP的影响。
关于可信计算和SGXL的注释：mbTLS的某些特征采用可信计算技术，如Intel的软件防护扩展(SGX)。具体地，mbTLS使用由SGX提供的两个特征：安全执行环境和远程证明。
在替代实现中，任何提供这些特征的可信计算技术(如Microsoft的虚拟安全模式(VSM)或ARM TrustZone)也可以正常工作。(如ARM TrustZone等其他技术提供类似的功能，但提供的安全保证略有不同。)
安全执行环境：SGX允许应用在被称为包围区的安全环境中运行代码。
包围区是包含程序代码和数据的受保护的存储器区域；在将高速缓存行移动到DRAM之前，它们通过CPU被加密并且被完整性保护。只要CPU在物理上没有受到破坏，即使恶意硬件或特权软件也无法访问或修改包围区存储器。在包围区中运行代码会导致性能下降，因为(a)必须首先对存储器中写入/从存储器读取的高速缓存行进行加密/解密，并且(b)由于OS不可信，包围区线程必须离开包围区才能进行系统调用，如send()和recv()。
远程证明：SGX可以为在包围区中运行的代码提供由CPU签名的特殊消息，称为证明，该消息向远程方证明所涉及的代码确实在真正的Intel CPU上的包围区中运行。该证明包括包围区代码和数据页的初始状态的密码哈希(因此，远程验证器可以看到期望的代码正在运行)、以及由包围区应用提供的自定义数据(将其用于将证明与TLS握手集成在一起)。
下面提供中间盒TLS或mbTLS(一种用于安全多方通信的协议，该协议使端点能够建立包括应用层中间盒的安全通信会话)的示例实现细节。每个端点102、104向会话添加零个或多个中间盒，其可以被称为客户端侧和服务器侧中间盒(在附图中为108-C和108-S)。每个端点都不知道对方的中间盒(或者根本不知道对方具有中间盒)。重要的是，这表示mbTLS端点可以与传统TLS端点互操作。
在高级别，端点进行标准的TLS握手，以建立主要TLS会话，该会话最终将用于数据传输。端点与它们的每个中间盒同时建立辅助TLS会话。端点一旦具有到中间盒的安全通道，其就会向中间盒发送加入主要端到端会话所需要的密钥材料。
在实施例中，当前公开的协议扩展了TLS 1.2握手2以可选地包括远程证明，端点可以在这里使用远程证明来验证这些辅助TLS会话是否在安全执行环境内终止。在实施例中，这是对用作mbTLS握手的构建块的TLS 1.2握手的唯一改变。
在mbTLS握手结束时，会话如图3所示。该示例会话示出了两个客户端侧和两个服务器侧中间盒。每个跃点使用不同的密钥对数据进行加密和MAC保护——客户端为客户端侧跃点生成密钥，服务器为服务器侧跃点生成密钥，并且主要会话密钥桥接两侧。由于每个跃点具有自己的加密/MAC密钥，因此可以防止对手导致记录跳过中间盒或以错误的顺序遍历中间盒，还可以防止窃听者检测中间盒是否修改了记录。除此之外，记录层与标准TLS相同。每个端点都会为其一半的连接生成密钥(例如，客户端生成图中的KC-C1和KC1-C0)。由于主要握手KC-S而建立的会话密钥充当客户端侧与服务器侧中间盒之间的“桥梁”。
在实施例中，根据mbTLS协议的消息收发可以如下工作。还参考图4。mbTLS对主要和辅助握手使用相同的每跃点TCP连接。引入了一种新的TLS记录类型(封装的)以在中间盒及其端点之间包装辅助TLS记录。这些记录包括外部TLS记录头，之后是一个字节的子通道ID和封装的记录。详细信息参考mbTLS消息格式。
关于客户端侧中间盒，mbTLS允许客户端既包括先验已知的中间盒(例如，由用户配置或经由DNS、DHCP或PDP/PDN声明)，又包括在会话建立期间发现的中间盒(在默认路由路径上)。为了向路径上中间盒通知客户端支持mbTLS，主要客户端问候包括新的中间盒支持TLS扩展。当看到扩展时，中间盒将客户端问候向前转发到服务器，并且与客户端开始其自己的辅助握手。在该辅助握手中，中间盒充当服务器的角色。原始的主要客户端问候兼作辅助握手的客户端问候；中间盒直接使用服务器问候3进行响应(这是为了避免额外的往返。)虽然，在所有计算中，客户端和中间盒都使用PRF(客户端随机||中间盒随机)。
可以存在多个客户端侧中间盒。辅助握手消息在封装记录中被发送，每个中间盒具有其自己的子通道ID。中间盒等待，直到它们看到主要的服务器问候，对其进行缓冲，为其自己分配下一可用子通道ID，使用该ID将其自己的辅助服务器问候注入到数据流中，并且最后转发主要服务器问候。这个过程可以确保每个中间盒在协调最少的情况下获取唯一的子通道ID。
关于服务器侧中间盒，它们也可以被预先布置(例如，经由DNS)或被即时发现。但是，发现稍微更多地涉及服务器侧情况。与客户端不同，服务器不使用中间盒支持扩展来声明mbTLS支持，这有两个原因：首先，TLS规范禁止服务器在服务器问候中包括客户端未包括在客户端问候中的扩展；如果客户端也不支持mbTLS，则依赖于服务器的中间盒支持扩展将失败。其次，即使有可能，如果服务器侧中间盒等待声明其存在直到服务器的服务器问候，则中间盒服务器握手也将在主要握手之后完成，从而将整个握手过程延长到两个以上的RTT。
相反，服务器侧中间盒在知道服务器是否支持mbTLS之前用新的中间盒声明消息乐观地声明自己。如果不是，则根据其TLS实现，它将忽略中间盒声明，并且握手将在没有中间盒的情况下继续进行，否则握手将失败。(在任何一种情况下，中间盒都将高速缓存该信息，而不会再次向该服务器声明自己。)如果握手失败，则客户端需要重试。客户端软件可以将其解释为这表示服务器正在运行过期的TLS堆栈并且使用较旧版本的TLS重试，这有潜在的危险。此外，在实践中，预计服务器侧中间盒和服务器通常将在同一管理控制下，在这种情况下，中间盒知道服务器支持mbTLS。与客户端侧中间盒一样，服务器侧中间盒在发送其中间盒声明消息时也为其自己分配未使用的子通道ID。
关于证明，当端点与其中间盒握手时，它们可以选择要求凭证、SGX证明或两者。凭证验证的工作方式与普通TLS握手中的工作方式相同，因此以下仅关注证明。目的是使端点确信只有在包围区中运行的中间盒应用才知道正在建立的TLS会话密钥。这样做的主要思想如下：由于证明包括代码的身份，并且假定代码(应用+mbTLS库)经过检查并且是可信的，则如果代码告诉我们它对于该握手生成了密钥材料并且没有导出它，则我们可以信任它。挑战变为标识“该握手”——端点如何确保对手没有从不同握手中重播旧证明？
这表示，除了代码身份，证明还应当包括某种握手标识符(SGX允许证明包括64字节的任意用户数据)。良好的握手标识符应当(A)在每次握手中都存在(因此不是服务器可以选择不支持的会话ID)，(B)在未来的握手中通常不会重复，并且(C)不能被攻击者强迫重复(因此，不是客户端随机)。良好的候选包括任何基于握手中交换的临时密钥的东西。预备主秘密或从中得到的任何东西都是一个不错的选择，除了只有从端点接收到客户端密钥交换之后中间盒才知道该预备主秘密。如果等待了这么长时间才发送证明，这将延迟整个端到端握手。相反，握手标识符可以仅基于中间盒的密钥材料(一种实现使用中间盒的公共临时Diffie Hellman密钥的哈希)。这些是公开的没关系，因为它们不会正常重复，并且攻击者无法强迫它们。这就要求服务器使用具有临时公钥的密钥交换方法(因为每个握手中的固定公钥都相同)，但是无论如何，使用临时公钥进行前向保密都是标准的最佳实践。
关于密钥分配，在完成与其中间盒的辅助握手之后，每个端点都会为其连接侧的每个跃点生成对称密钥。它将这些密钥分配到加密的中间盒密钥交换记录中的中间盒，该记录与辅助握手消息一样，在数据流的封装记录中被发送。客户端服务器会话密钥(KC-S)充当最后的客户端侧中间盒与第一服务器侧中间盒之间的“桥梁”。
现在，以下将重新介绍每个安全属性P1-P4，从而说明mbTLS为何要解决这些问题。
P1：数据保密。P1A：对手必须不能读取会话数据。解密会话数据需要访问图3所示的对称密钥之一。桥接密钥KC-S是在端到端客户端服务器TLS握手期间中建立的，端点在该握手中彼此验证彼此的凭证。接下来，该密钥和其余会话密钥(例如，KC-C1、KC1-C0等)通过各个辅助TLS连接传输到中间盒；重要的是，这些辅助连接在SGX包围区内终止，这表示MIP无法访问存储器中的辅助会话的密钥，因此只有MS(而非MIP)才能获知主要会话密钥。远程证明向中间盒的端点证明MS确实在安全环境中运行。
P1B：通信应当是转发秘密的。桥接密钥(KC-S)是(标准)主要TLS握手的结果，因此，如果主要握手是前向安全的，则KC-S也是如此。其他会话密钥(例如，KC-C0、KC0-C1等)为每个会话重新生成，并且通过(标准)辅助TLS连接被发送到中间盒。因此，如果这些辅助握手是前向安全的，则非桥接会话密钥也是如此。
P1C：与每个跃点都是其自己的独立TLS连接相比，观察者不应当从观察密文中学到更多东西。由于每个跃点使用其自己的独立加密和MAC密钥，因此在握手之后，每个跃点都像其自己的TLS连接一样有效地操作。
具体地，这阻止了对手了解中间盒是否修改了记录(尽管其仍然可以看到每个记录的大小和时间，包括中间盒是增加还是减小了数据的大小)。
P2：数据认证。对手必须不能修改、删除或注入会话数据。每个记录都带有消息认证码(MAC)，这是使用用于标识数据的会话密钥生成的小标签。如果MAC与数据不匹配，则可以检测到未经授权的改变。由于只有端点和每个MS知道会话密钥(请参阅P1A)，因此只有这些实体才能修改或创建记录。
P3：实体认证。P3A：每个端点都可以验证另一端点是否由预期实体操作并且每个MS是否由预期MSP操作。首先，客户端和服务器可以在主要握手时要求彼此的凭证(尽管通常客户端认证发生在应用层)。
凭证将服务器的公钥绑定到其身份，并且该公钥在主要握手中用于协商共享桥接密钥，因此，在成功握手之后，客户端确保使用该桥接密钥加密的任何数据只能通过预期服务提供者(或它选择添加到会话的中间盒)进行解密。其次，端点还可以要求来自中间盒的凭证。由于与凭证相对应的私钥存储在MIP无法访问的包围区中(并且远程证明证明了是这种情况)，因此端点确信其正在与由预期MSP提供和配置的软件进行通信。
P3B：每个端点都可以验证另一端点和每个MS正在运行预期的软件以及其被正确配置。由于我们的威胁模型假定SP及在其服务器上运行的所有软件都是可信的，并且在P3A中，我们验证了服务器拥有SP的私钥，因此客户端相信该机器正确地配置有预期的应用软件。相同的逻辑适用于中间盒，另外还有一个步骤，即远程证明使端点确信MS在安全执行环境中被安全隔离。
P4：路径完整性。每个端点为其中间盒选择顺序。任何其他实体(包括其他端点或任何中间盒)都不可能导致中间盒以不同顺序处理会话数据。这是因为mbTLS为每个跃点都使用新的密钥。假定对手从图3中的C1-C0链中截取记录，然后尝试将其插入S0-S1链中(从而跳过中间盒C0和S0)。该记录将使用KC1-C0被加密和进行MAC，但是C1希望使用KS1-S0保护数据，因此MAC检查将失败并且该记录将被丢弃。(注意，端点可以在其路径的一部分的任何位置中注入、删除或修改数据，因为它知道其一侧的所有会话密钥。)
在实施例中，示例性mbTLS协议的一些其他安全性属性如下。
端点隔离：端点只能验证自己的中间盒，而不能验证其他端点添加的中间盒。实际上，端点可能甚至不知道另一侧的中间盒。这遵循密钥生成和分配的方式。仅当凭证中的公钥用于密钥交换时，检查凭证或证明才有意义(然后，您相信只有与该公钥相关联的实体才能解密您使用新对称密钥发送的内容)。由于端点不与另一侧的中间盒进行KE，因此即使交换了凭证/证明，它们也无法彼此进行认证。这种限制是合理的；由于端点大概彼此信任，或者它们之间本来不会进行通信，因此自然可以信任另一端点以正确地认证其添加到会话的任何中间盒。
路径灵活性：无法交织客户端侧和服务器侧中间盒。为了支持这一点，端点将需要协调以生成/分配密钥到路径的交织部分。这表示端点需要额外的工作，并且端点还需要了解彼此的(某些)中间盒。这也表示一个端点可以在另一端点的中间盒之后修改/注入业务，如果这些中间盒之一进行某种过滤或清理，则这可能是安全问题。
不可信MSP：即使服务提供者不可信，mbTLS也可以提供保证。在我们的威胁模型中，SP和MSP都是可信的。但是，即使在SP和MSP不可信的更为悲观的威胁模型中，远程证明仍然可以提供P1、P2、P3和P4，因为证明可以标识在安全环境中运行的代码。这依赖于两个大的假定：一，已知该软件“行为良好”(例如，不将会话数据导出到包围区之外)；二，客户端知道该“已知良好”软件的哈希。例如，如果软件是开源的并且已经过公开验证以对会话数据保密，则即使该客户端既不信任操作该服务的公司也不信任运行其的基础结构，该客户端也可以连接到不可信Web代理。
中间盒状态中毒：将mbTLS与保留全局状态的客户端侧中间盒一起使用是不安全的。由于端点知道其连接一侧上的每个跃点的密钥，因此恶意客户端可以在不知道其中间盒的情况下读取和/或修改任何这些跃点上的数据。当中间盒跨多个客户端(如Web高速缓存)共享状态时，这是一个问题。有权访问高速缓存与服务器之间的链接的客户端可以请求页面，丢弃服务器的响应并且注入其自己的响应，从而使其他客户端的高速缓存中毒。一种可能的解决方案是改变握手协议，使得中间盒与其邻居建立密钥，而不是由端点生成和分配会话密钥；这表示各方仅知道与其相邻的(多个)跃点的(多个)密钥。缺点是客户端失去了验证服务器的凭证以及使用该凭证中的公钥建立会话密钥的能力。相反，客户端必须信任其中间盒以认证服务器。这可能是合理的，因为SGX证明应当使客户端确信中间盒正在运行将要这样做的软件，但是实施例未在mbTLS中采用这种方法，因为在可能的情况下，可以优选地依赖于密码，因为依赖于SGX还表示依赖于协议库代码的正确性。
绕过过滤器中间盒：乍一看，端点知道其一侧的所有会话密钥的事实会引发另一种攻击：如果中间盒执行某种过滤功能(例如，由管理员授权的病毒扫描器、父母过滤器或数据泄露检测器)，这表示端点具有在过滤传入数据或随后注入传出数据之前可以访问传入数据的密钥。但是，如果端点能够在过滤器的“另一侧”读取或写入数据(即，超越中间盒物理地从网络中检索分组/将分组注入到网络)，则过滤器一开始就没有用，因此mbTLS不会启用新的攻击。
现在讨论mbTLS的示例性实施例的一些其他特征。
会话恢复：在实施例中，mbTLS完全支持基于ID和基于票证的会话恢复。
每个子握手(主要握手和辅助握手)仅进行标准的缩写握手；唯一的细微差别是，中间盒的会话票证应当包含端到端会话的会话密钥(除了端点中间盒子会话的密钥)。不需要新的证明，因为只有包围区知道解密会话票证所需要的密钥。希望恢复会话的客户端存储服务器和每个客户端侧中间盒的会话ID或票证。如果服务器还使用mbTLS，则它可以高速缓存其中间盒的会话ID/票证，也可以要求客户端对其进行高速缓存并且将其发送到客户端问候中。
TLS 1.3：与TLS 1.2及更早版本相比，这大大改变了TLS握手，将其从两次往返缩短为一次。通过较小的修改，mbTLS的握手可以适应TLS 1.3。有一个警告：当存在客户端侧中间盒时，在与服务器完成相同的飞行(flight)中由服务器发送的数据可能会延迟，在最坏的情况下，可能会延迟一次往返；但是，在大多数情况下，客户端首先发送应用数据；在这些情况下，不存在问题。
mbTLS和SGX：后者对中间盒开发人员构成了限制。由于仅信任CPU，因此默认情况下不允许与外界进行交互(特别是，由于OS不可信，因此不允许系统调用)。Intel的SDK实现了libc的子集，但是开发人员必须通过在包围区内提供自定义实现或者开发明确的包围区接口来使包围区线程离开包围区，执行不可信代码并且将结果返回包围区来添加其余功能。
存在不同方法来平衡两个竞争因素：可信计算库的大小(即，TCB)(包围区中的代码越多，它越可能包含可利用的错误)和包围区接口的大小(在包围区外部的每个调用都为攻击者提供注入恶意输入的机会)。一种极端情况是将整个库OS放置在包围区内，从而导致TCB大而包围区接口小。相反的极端情况是，在包围区中什么也不实现，并且对于每个libc调用行进到外部(小型TCB、大型接口)。也可以采用中间立场。
网络I/O：当包围区线程需要进行系统调用时，有两种高级策略：(1)将参数复制到不受保护的存储器中，退出包围区，执行调用，然后重新进入包围区，并且将结果复制回包围区存储器；或者(2)将请求放置在共享队列中，包围区外部的另一线程执行该调用，经由响应队列将结果传递回包围区。这些分别是同步和异步系统调用。
应当理解，上述实施例仅作为示例进行了描述。
更一般地，根据本文中公开的一个方面，提供了一种在第一端点与第二端点之间通过网络进行通信的方法，第一端点是客户端设备或服务器，并且第二端点是客户端设备和服务器中的另一者；该方法包括：在第一端点与第二端点之间建立第一安全传输层通道，第一安全传输层通道由访问通过第一安全传输层通道发送的业务的内容所需要的第一密码密钥限定；在第一端点与中间盒之间建立第二安全传输层通道，第一端点要将通过第一安全传输层通道发送的业务的处理委派给中间盒，第二安全传输层通道由访问通过第二安全传输层通道发送的内容所需要的第二密码密钥限定；第一端点经由相应第二安全传输层通道验证中间盒，并且在上述验证的条件下经由第二安全传输层通道与中间盒共享第一加密密钥；以及引起通过通道发送的业务经由中间盒被路由；该方法从而使得中间盒能够使用第一密码密钥以明文方式处理通过第一安全传输层通道发送的业务的内容。
在实施例中，第一传输层通道和第二传输层通道中的每个传输层通道可以是TLS通道。
在实施例中，上述验证可以包括确认中间盒是由预期方提供的。
在实施例中，上述验证可以包括认证中间盒是由可信方提供的。
在实施例中，上述确认可以包括确认中间盒提供预期服务。
在实施例中，中间盒可以包括以下至少之一：病毒扫描器、儿童安全过滤器、入侵检测器、压缩代理、音频或视频代码转换器、HTTP代理、应用层负载平衡器和/或高速缓存。
在实施例中，可以通过向第二端点提供中间盒的IP地址或域名作为第一端点的联系地址，或者通过将网络配置为将被寻址到第一端点的业务重定向到中间盒，来引起业务经由中间盒被路由。
在实施例中，该方法可以包括上述客户端和至少一个另外的客户端经由上述第一安全传输层通道与服务器通信作为同一多方通信会话的一部分。
在实施例中，中间盒可以在其上实现中间盒的网络设备的安全包围区内运行。
在实施例中，第一端点可以是客户端，并且第二端点可以是服务器。
在实施例中，第一安全传输层通道的建立可以包括客户端经由中间盒向服务器发送消息，其中该消息可以包括被配置为引起中间盒与客户端开始握手以执行第二安全传输层通道的上述建立的TLS扩展。
在替代实施例中，第一端点可以是服务器，并且第二端点可以是客户端。
在实施例中，该方法可以包括：对于第一端点和第二端点中的每个相应端点，在相应端点与相应中间盒之间建立不同的相应第二安全传输层通道，相应端点要将通过第一安全传输层通道发送的业务的处理委派给相应中间盒，每个第二安全传输层通道由访问通过相应第二安全传输层通道发送的内容所需要的不同的相应第二密码密钥来限定；第一端点和第二端点中的每个端点经由相应第二安全传输层通道来验证端点的相应中间盒，并且在上述验证的条件下经由相应第二安全传输层通道与相应中间盒共享第一加密密钥；以及引起通过通道发送的业务经由第一端点和第二端点两者的中间盒被路由；该方法从而使得两个端点的中间盒能够使用第一密码密钥来处理通过第一通道发送的业务的内容。
在实施例中，多个中间盒的链可以被包括在第一安全传输层通道中，每个中间盒根据上述方法的相应实例使用不同的相应第二安全传输层通道来引入。
在实施例中，上述链可以包括第一端点的多个中间盒，每个中间盒根据上述方法的相应实例使用不同的相应第二安全传输层通道来引入。
在实施例中，其中上述链可以包括第二端点的多个中间盒，每个中间盒根据上述方法的相应实例使用不同的相应第二安全传输层通道来引入。
在实施例中，该方法可以包括通过以下操作来强制中间盒接收业务的顺序：使用不同的相应的每跃点加密密钥来发送业务以加密端点与中间盒之间的每个跃点以及中间盒之间的每个跃点上的业务。
在实施例中，上述网络可以包括因特网。
根据本文中公开的另一方面，提供了一种计算机程序产品，其实施在计算机可读存储装置上并且被配置为当在计算机系统上运行时执行任何前述实施例的方法。
根据本文中公开的另一方面，提供了一种计算机系统，其至少包括被编程为执行任何前述实施例的方法的第一端点。
一旦给出本文中的公开内容，其他变型对于本领域技术人员而言将变得很清楚。本公开的范围不由上述实施例限制，而仅由所附权利要求书限制。

Claims (15)

1.一种在第一端点与第二端点之间通过网络进行通信的方法，所述第一端点是客户端设备或服务器，并且所述第二端点是所述客户端设备和所述服务器中的另一者；所述方法包括：
在所述第一端点与所述第二端点之间建立第一安全传输层通道，所述第一安全传输层通道由访问通过所述第一安全传输层通道发送的业务的内容所需要的第一密码密钥限定；
在所述第一端点与中间盒之间建立第二安全传输层通道，所述第一端点要将通过所述第一安全传输层通道发送的所述业务的处理委派给所述中间盒，所述第二安全传输层通道由访问通过所述第二安全传输层通道发送的内容所需要的第二密码密钥限定；
所述第一端点经由相应的所述第二安全传输层通道验证所述中间盒，并且在所述验证的条件下经由所述第二安全传输层通道与所述中间盒共享第一加密密钥；以及
引起通过所述通道发送的所述业务经由所述中间盒被路由；
所述方法从而使得所述中间盒能够使用所述第一密码密钥以明文方式处理通过所述第一安全传输层通道发送的所述业务的内容。
2.根据权利要求1所述的方法，其中所述第一传输层通道和所述第二传输层通道中的每个传输层通道是TLS通道。
3.根据权利要求1或2所述的方法，其中所述验证包括以下中的一项或多项：
-确认所述中间盒是由预期方提供的，
-认证所述中间盒是由可信方提供的，和/或
-确认所述中间盒提供预期服务。
4.根据前述权利要求中任一项所述的方法，其中所述中间盒包括以下之一：
-病毒扫描器，
-儿童安全过滤器，
-入侵检测器
-压缩代理，
-音频或视频代码转换器，
-HTTP代理，
-应用层负载平衡器，和/或
-高速缓存。
5.根据前述权利要求中任一项所述的方法，包括所述客户端和至少一个另外的客户端经由所述第一安全传输层通道与所述服务器通信作为同一多方通信会话的一部分。
6.根据前述权利要求中任一项所述的方法，其中所述中间盒在网络设备的安全包围区内运行，所述中间盒被实现在所述网络设备上。
7.根据前述权利要求中任一项所述的方法，其中所述第一端点是所述客户端，并且所述第二端点是所述服务器。
8.根据权利要求7所述的方法，其中所述第一安全传输层通道的所述建立包括所述客户端经由所述中间盒向所述服务器发送消息，以及其中所述消息包括TLS扩展，所述TLS扩展被配置为引起所述中间盒开始与所述客户端握手以执行所述第二安全传输层通道的所述建立。
9.根据权利要求1至6中任一项所述的方法，其中所述第一端点是所述服务器，并且所述第二端点是所述客户端。
10.根据前述权利要求中任一项所述的方法，包括：
对于所述第一端点和所述第二端点中的每个相应端点，在所述相应端点与相应中间盒之间建立不同的相应第二安全传输层通道，所述相应端点要将通过所述第一安全传输层通道发送的所述业务的处理委派给所述相应中间盒，每个第二安全传输层通道由访问通过所述相应第二安全传输层通道发送的内容所需要的不同的相应第二密码密钥限定；
所述第一端点和所述第二端点中的每个端点经由所述相应第二安全传输层通道来验证所述端点的相应中间盒，并且在所述验证的条件下经由所述相应第二安全传输层通道与所述相应中间盒共享所述第一加密密钥；以及
引起通过所述通道发送的所述业务经由所述第一端点和所述第二端点两者的所述中间盒被路由；
所述方法从而使得两个端点的所述中间盒能够使用所述第一密码密钥来处理通过所述第一通道发送的所述业务的内容。
11.根据前述权利要求中任一项所述的方法，其中多个中间盒的链被包括在所述第一安全传输层通道中，每个中间盒根据所述方法的相应实例使用不同的相应第二安全传输层通道而被引入。
12.根据权利要求11所述的方法，其中：
所述链包括所述第一端点的多个中间盒，每个中间盒根据权利要求1至9中任一项所述的方法的相应实例使用不同的相应第二安全传输层通道而被引入；和/或
所述链包括所述第二端点的多个中间盒，每个中间盒根据权利要求10所述的方法的相应实例使用不同的相应第二安全传输层通道而被引入。
13.根据权利要求11或12所述的方法，包括通过以下操作强制所述中间盒接收所述业务的顺序：
使用不同的相应的每跃点加密密钥来发送所述业务以加密端点与中间盒之间的每个跃点以及中间盒之间的每个跃点上的所述业务。
14.一种计算机程序产品，体现在计算机可读存储装置上并且被配置为当在计算机系统上运行时执行根据前述权利要求中任一项所述的方法。
15.一种计算机系统，至少包括被编程为执行根据权利要求1至13中任一项所述的方法的所述第一端点。
CN201880042761.XA 2017-06-26 2018-06-04 将中间盒引入到客户端与服务器之间的安全通信中 Active CN110870277B (zh)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
GBGB1710168.4A GB201710168D0 (en) 2017-06-26 2017-06-26 Introducing middleboxes into secure communications between a client and a sever
GB1710168.4 2017-06-26
US15/640,160 US10389524B2 (en) 2017-06-26 2017-06-30 Introducing middleboxes into secure communications between a client and a server
US15/640,160 2017-06-30
PCT/US2018/035771 WO2019005426A1 (en) 2017-06-26 2018-06-04 INTRODUCTION OF INTERMEDIATE BOXES IN SECURE COMMUNICATIONS BETWEEN A CLIENT AND A SERVER

Publications (2)

Publication Number Publication Date
CN110870277A true CN110870277A (zh) 2020-03-06
CN110870277B CN110870277B (zh) 2022-03-29

Family

ID=59523479

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201880042761.XA Active CN110870277B (zh) 2017-06-26 2018-06-04 将中间盒引入到客户端与服务器之间的安全通信中

Country Status (5)

Country Link
US (1) US10389524B2 (zh)
EP (1) EP3646553B1 (zh)
CN (1) CN110870277B (zh)
GB (1) GB201710168D0 (zh)
WO (1) WO2019005426A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112468495A (zh) * 2020-11-26 2021-03-09 上海天旦网络科技发展有限公司 完全前向保密加密系统的降级监控方法、系统及介质
CN116032657A (zh) * 2023-02-15 2023-04-28 北京锐服信科技有限公司 一种流量监控方法、系统和电子设备

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3920465B1 (en) * 2010-10-08 2023-12-06 Brian Lee Moffat Private data sharing system
WO2018213239A1 (en) * 2017-05-15 2018-11-22 Polyport, Inc. Stacked encryption
US10992652B2 (en) 2017-08-25 2021-04-27 Keysight Technologies Singapore (Sales) Pte. Ltd. Methods, systems, and computer readable media for monitoring encrypted network traffic flows
US10903985B2 (en) 2017-08-25 2021-01-26 Keysight Technologies Singapore (Sales) Pte. Ltd. Monitoring encrypted network traffic flows in a virtual environment using dynamic session key acquisition techniques
US10608959B2 (en) * 2017-09-11 2020-03-31 Vmware, Inc. Securely managing and diagnosing network middleboxes
CN109660490A (zh) * 2017-10-10 2019-04-19 优刻得科技股份有限公司 数据处理方法、装置、系统和存储介质
US11245674B2 (en) * 2017-12-14 2022-02-08 Nicira, Inc. Secure communication protocol processing
WO2019199303A1 (en) * 2018-04-11 2019-10-17 Google Llc Mutually distrusting enclaves
US10893030B2 (en) * 2018-08-10 2021-01-12 Keysight Technologies, Inc. Methods, systems, and computer readable media for implementing bandwidth limitations on specific application traffic at a proxy element
EP3888291A4 (en) * 2018-11-28 2022-08-17 Visa International Service Association COLLUSION PREVENTION TECHNIQUES USING SIMULTANEOUS KEY RELEASE
US11050723B1 (en) * 2018-12-29 2021-06-29 Whatsapp Inc. Methods and systems for transmitting anonymized information
WO2020151809A1 (en) * 2019-01-22 2020-07-30 Telefonaktiebolaget Lm Ericsson (Publ) Security for distributed networking
US11658944B2 (en) * 2020-03-13 2023-05-23 Arm Ip Limited Methods and apparatus for encrypted communication
EP4002331A1 (en) * 2020-11-18 2022-05-25 Veriqloud Method and server for delegated quantum computing using a hardware enclave
CN115514584B (zh) * 2022-11-16 2023-01-31 北京锘崴信息科技有限公司 服务器以及金融相关服务器的可信安全认证方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140298415A1 (en) * 2013-03-28 2014-10-02 Research In Motion Limited Method and system for providing connectivity for an ssl/tls server behind a restrictive firewall or nat
CN104580189A (zh) * 2014-12-30 2015-04-29 北京奇虎科技有限公司 一种安全通信系统
CN104821951A (zh) * 2015-05-26 2015-08-05 杭州华三通信技术有限公司 一种安全通信的方法和装置
US20160219018A1 (en) * 2015-01-27 2016-07-28 Dell Software Inc. Dynamic bypass of tls connections matching exclusion list in dpi-ssl in a nat deployment
US9467290B2 (en) * 2001-02-12 2016-10-11 Aventail Llc Method and apparatus for providing secure streaming data transmission facilities using unreliable protocols

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6643701B1 (en) * 1999-11-17 2003-11-04 Sun Microsystems, Inc. Method and apparatus for providing secure communication with a relay in a network
US7386723B2 (en) 2002-11-22 2008-06-10 Intel Corporation Method, apparatus and system for compressing IPSec-protected IP packets
US8613071B2 (en) * 2005-08-10 2013-12-17 Riverbed Technology, Inc. Split termination for secure communication protocols
CN101127595B (zh) 2006-08-15 2011-02-02 华为技术有限公司 一种实现多方通信安全的方法、系统及设备
US8190875B2 (en) * 2007-03-22 2012-05-29 Cisco Technology, Inc. Reducing processing load in proxies for secure communications
US7992200B2 (en) 2007-07-16 2011-08-02 International Business Machines Corporation Secure sharing of transport layer security session keys with trusted enforcement points
US8190879B2 (en) * 2009-12-17 2012-05-29 Cisco Technology, Inc. Graceful conversion of a security to a non-security transparent proxy
US9374344B1 (en) * 2013-03-29 2016-06-21 Secturion Systems, Inc. Secure end-to-end communication system
CN106209734B (zh) * 2015-04-30 2019-07-19 阿里巴巴集团控股有限公司 进程的身份认证方法和装置
ES2828948T3 (es) 2015-07-02 2021-05-28 Telefonica Cibersecurity & Cloud Tech S L U Método, sistema y productos de programa informático para posibilitar de forma segura una funcionalidad en - red a lo largo de sesiones de datos cifradas
US10367891B2 (en) * 2015-09-28 2019-07-30 Citrix Systems, Inc. System and method for improving efficiency of SSL/TLS connections
US10250637B2 (en) * 2016-01-29 2019-04-02 Citrix Systems, Inc. System and method of pre-establishing SSL session connections for faster SSL connection establishment
US10084764B2 (en) * 2016-05-13 2018-09-25 Cisco Technology, Inc. System for a secure encryption proxy in a content centric network

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9467290B2 (en) * 2001-02-12 2016-10-11 Aventail Llc Method and apparatus for providing secure streaming data transmission facilities using unreliable protocols
US20140298415A1 (en) * 2013-03-28 2014-10-02 Research In Motion Limited Method and system for providing connectivity for an ssl/tls server behind a restrictive firewall or nat
CN104580189A (zh) * 2014-12-30 2015-04-29 北京奇虎科技有限公司 一种安全通信系统
US20160219018A1 (en) * 2015-01-27 2016-07-28 Dell Software Inc. Dynamic bypass of tls connections matching exclusion list in dpi-ssl in a nat deployment
CN104821951A (zh) * 2015-05-26 2015-08-05 杭州华三通信技术有限公司 一种安全通信的方法和装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
刘洪伟等: ""身份认证技术的分类及应用研究"", 《江苏理工学院学报》 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112468495A (zh) * 2020-11-26 2021-03-09 上海天旦网络科技发展有限公司 完全前向保密加密系统的降级监控方法、系统及介质
CN112468495B (zh) * 2020-11-26 2022-05-17 上海天旦网络科技发展有限公司 完全前向保密加密系统的降级监控方法、系统及介质
CN116032657A (zh) * 2023-02-15 2023-04-28 北京锐服信科技有限公司 一种流量监控方法、系统和电子设备

Also Published As

Publication number Publication date
CN110870277B (zh) 2022-03-29
EP3646553A1 (en) 2020-05-06
EP3646553B1 (en) 2021-09-22
US20180375644A1 (en) 2018-12-27
GB201710168D0 (en) 2017-08-09
US10389524B2 (en) 2019-08-20
WO2019005426A1 (en) 2019-01-03

Similar Documents

Publication Publication Date Title
CN110870277B (zh) 将中间盒引入到客户端与服务器之间的安全通信中
US11792169B2 (en) Cloud storage using encryption gateway with certificate authority identification
Naylor et al. And then there were more: Secure communication for more than two parties
US9398026B1 (en) Method for authenticated communications incorporating intermediary appliances
US10178181B2 (en) Interposer with security assistant key escrow
US8788805B2 (en) Application-level service access to encrypted data streams
US8418242B2 (en) Method, system, and device for negotiating SA on IPv6 network
Degraaf et al. Improved port knocking with strong authentication
US10721219B2 (en) Method for establishing a secure communication session in a communications system
CN103907330A (zh) 在网络环境中用于重定向的防火墙发现的系统和方法
WO2010104632A2 (en) Offloading cryptographic protection processing
CN111428225A (zh) 数据交互方法、装置、计算机设备及存储介质
JP2023514736A (ja) 安全な通信のための方法及びシステム
CA3066728A1 (en) Cloud storage using encryption gateway with certificate authority identification
US10721061B2 (en) Method for establishing a secure communication session in a communications system
US20090327730A1 (en) Apparatus and method for encrypted communication processing
US10659228B2 (en) Method for establishing a secure communication session in a communications system
US20080267395A1 (en) Apparatus and method for encrypted communication processing
US11689517B2 (en) Method for distributed application segmentation through authorization
KR20140091221A (ko) 웹 보안 프로토콜에 따른 암호화 데이터를 복호화하는 보안 장치 및 그것의 동작 방법
KR20190024581A (ko) 보안을 위한 보안 소켓 계층 복호화 방법
CN110995730B (zh) 数据传输方法、装置、代理服务器和代理服务器集群
US20080059788A1 (en) Secure electronic communications pathway
Rao et al. Pseudo-System Protocol for Information Transfer
CN114268499A (zh) 数据传输方法、装置、系统、设备和存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant