HTTPS请求充实的制作方法

背景

本申请总体上涉及使用加密协议的安全的基于网络的通信。

相关技术的简要描述

分布式计算机系统在现有技术中是众所周知的。一个这样的分布式计算机系统是由服务提供商操作和管理的“内容传递网络”(cdn)或“覆盖网络”。服务提供商通常代表使用服务提供商的共享基础设施的第三方(客户)提供内容传递服务。这种类型的分布式系统通常是指通过一个网络或多个网络连同被设计为促进各种服务的软件、系统、协议和技术(诸如内容传递、web应用加速或外包原产地基础设施的其他支持)链接的自主计算机的集合。cdn服务提供商通常通过数字属性(例如网站)提供服务传递，这些数字属性(如网站)在客户门户中提供，然后部署到网络。数字属性通常绑定到允许服务提供商考虑流量并向其客户收费的一个或多个边缘配置。

传输层安全(tls)及其前身安全套接字层(ssl)是提供internet通信安全性的加密协议。它们使用用于身份验证和密钥交换的非对称加密技术、用于机密性的对称加密、以及消息完整性的消息认证码。tls/ssl在会话层初始化，然后在表示层工作。具体地，首先会话层具有使用建立密码设置的非对称密码和关于该会话的共享密钥进行的握手。此后，表示层使用对称密码和该会话密钥对通信的其余部分进行加密。在这两个模型中，tls和ssl代表底层传输层工作，其段承载加密数据。tls是在rfc5246和rfc6176中定义的ietf标准跟踪协议。

http请求充实(enrichment)是internet服务提供商(isp)将客户端智能传递给http服务器的有用和低开销技术。通常可以借助能够识别http请求、向它们插入文本并在客户端和服务器之间正确偏移tcp流的序列号的深度包检测(dpi)框来实现。但是，对于https请求，此功能不能存在，因为中间框无法将任何东西插入ssl流。

作为额外的背景，许多移动网络运营商使用透明代理和在线转码或转换设备来在高流量时段内例如基于其网络中的实时状况控制流量。这些方法对运营商非常有用，但由于ssl流的增长，它们变得越来越不相关。

简述

描述了https请求充实的方法。在一个实施例中，该方法使用特殊形式的充实记录，并且利用处理充实记录的tcp和ssl/tls之间的软件层以及ssl/tls层和应用层可以使用的该层的应用编程接口(api)。本文的技术还提供了充实能力的发现和用于充实的安全通信的密钥协商。

上述已经概述了所公开主题的一些更相关的特征。这些特征应被解释为仅仅是说明性的。通过以不同的方式应用所公开的主题或通过修改将要描述的主题可以获得许多其它有益的结果。

附图简述

为了对本主题及其优点的更彻底理解，现在参考结合附图进行的下面的描述，其中：

图1示出可以实践本公开的技术的覆盖网络，例如内容递送网络(cdn)；

图2示出覆盖网络的边缘服务器的架构；

图3示出用于ssl/tls记录的标准记录格式；

图4示出在客户端和服务器之间的传统的ssl记录交换；

图5示出用于本公开的请求充实技术的代表性实现；

图6示出可以由图5中的充实层来实现的各种功能；

图7示出在一个实施例中如何将ssl请求充实度合并到消息流中；

图8示出在另一个实施例中如何将ssl请求充实度合并到消息流中；

图9示出用于实现充实层功能的优选软件分层方法；

图10示出根据本公开的在移动网络环境中如何使用ssl充实；

图11示出如何可以在移动网络环境中使用服务发现协议来讨论服务api以及协商加密密钥；以及

图12示出使用ssl记录封装协议插入充实的替代方法。

详细描述

图1示出了已知的分布式计算机系统，(如下所述)该已知的分布式计算机系统通过本文的技术进行扩展，以提供具有以广播观众的规模将在线hd视频传递到最流行的运行时环境和在固定线路和移动环境中的最新的设备的能力的单个基于http的平台。

在已知的系统中，如图1所示，分布式计算机系统100被配置为cdn，并且假设具有在互联网周围分布的一组机器102a-n。通常，大多数机器是位于互联网边缘附近(即位于终端用户接入网络或相邻的终端用户接入网络)的服务器。网络操作指挥中心(nocc)104管理在系统中的各种机器的操作。诸如网站106的第三方站点将内容(例如，html、嵌入页面对象、流媒体、软件下载等)的传递卸载到分布式计算机系统100，特别是卸载到“边缘”服务器。通常，内容提供商通过将给定的内容提供商域或子域进行别名(例如，通过dnscname)来将其内容传递卸载到由服务提供商的权威域名服务管理的域。期望内容的终端用户被引导到分布式计算机系统以更可靠和高效地获得该内容。尽管未详细示出，但是分布式计算机系统还可以包括其他基础设施，诸如分布式数据收集系统108，其收集来自边缘服务器的使用情况和其他数据，集合跨越一个区域或一组区域的该数据并将该数据传到其他后端系统110、112、114和116，以便于监视、记录、警报、计费、管理和其他操作和管理功能。分布式网络代理118监视网络以及服务器负载，并向dns查询处理机构115提供网络、流量和负载数据，dns查询处理机构115有权针对由cdn管理的内容域。分布式数据传输机构120可以用于向边缘服务器分发控制信息(例如，用于管理内容、促进负载平衡等的元数据)。

如图2所示，给定机器200包括运行支持一个或多个应用程序206a-n的操作系统内核(例如，linux或变体)204的商用硬件(例如，intelpentium处理器)202。为了促进内容传递服务，例如，给定的机器通常运行一组应用程序，例如，http代理207(有时称为“全局主机”或“ghost”进程)、名称服务器208、本地监视过程210、分布式数据收集过程212等。对于流媒体，如由所支持的媒体格式要求的，该机器通常包括一个或多个媒体服务器，例如，windowsmediaserver(wms)或flash服务器。

cdn边缘服务器被配置为优选地使用分发到使用配置系统的边缘服务器的配置文件来提供一个或多个扩展内容传递特征，优选地基于特定域的、特定客户。给定的配置文件优选地是基于xml的，并且包括一组促进一个或多个高级内容处理特征的内容处理规则和指令。配置文件可以经由数据传输机构传递到cdn边缘服务器。美国专利第7,111,057号示出了用于传递和管理边缘服务器内容控制信息的有用的基础设施，并且这个和其他边缘服务器控制信息可以由cdn服务提供商本身提供，或者(经由外部网等)由操作原始服务器的内容提供者客户提供。

cdn可以包括存储子系统，例如，在美国专利第7,472,178号中描述的存储子系统，该专利的公开内容通过引用并入本文。

cdn可以操作服务器缓存层级以提供客户内容的中间缓存；在美国专利第7,376,716号中描述了一个这样的缓存层级子系统，该专利的公开内容通过引用并入本文。

cdn可以以在美国公布第20040093419号中描述的方式在客户端浏览器、边缘服务器和客户源服务器之间提供安全的内容传递。如本文所述，安全的内容传递一方面在客户端和边缘服务器过程之间执行基于ssl的链接以及另一方面在边缘服务器过程和源服务器过程之间执行基于ssl的链接。这使得ssl保护的网页和/或其组件能够经由边缘服务器传递。

作为覆盖层，cdn资源可用于促进在企业数据中心(可能是私有管理)和第三方软件即服务(saas)提供商之间的广域网(wan)加速服务。

在典型的操作中，内容提供者识别其期望由cdn服务的内容提供商域或子域。cdn服务提供商(例如，通过规范名称或cname)将内容提供者域与边缘网络(cdn)主机名相关联，并且cdn提供商然后将该边缘网络主机名提供给内容提供者。当在内容提供商的域名服务器处收到对内容提供商域或子域的dns查询时，这些服务器通过返回边缘网络主机名来进行响应。边缘网络主机名指向cdn，然后通过cdn名称服务解析该边缘网络主机名。为此，cdn名称服务返回一个或多个ip地址。然后，请求的客户端浏览器向与ip地址相关联的边缘服务器进行内容请求(例如，经由http或https)。请求包括含原始内容提供商域或子域的主机头。在接收到具有主机头的请求时，边缘服务器检查其配置文件以确定所请求的内容域或子域是否实际上正由cdn处理。如果是这样，边缘服务器如其配置中所指定的应用其关于该域或子域的内容处理规则和指令。这些内容处理规则和指令可能位于基于xml的“元数据”配置文件中。

作为额外的背景，在现有技术中已知的是提供所谓的http请求充实。下文提供了这种技术的细节。首先，考虑通过连接客户端和服务器的网络进行的http(非ssl)请求/响应的流程。从理论上讲，这样的流程可能被中间的诸如透明代理、网关、七层交换机等的网元拦截。网元可以选择向http请求中自主地插入额外的报头以将关于请求的附加辅助信息传送到服务器。这是http请求充实的过程。此外，服务器可以将关于响应的附加辅助信息添加到一些报头中，然后中间的网元在将其发送给客户端之前可以从响应报头中读取和提取。这种http请求充实作为许多商业上可用的网元中的简单特征可用。例如，juniper网络移动网络网关包括充实来自具有设备的msisdn号码的移动设备的每个http请求使得服务器可以识别用户的特征。

http是一种基于文本的协议，且其不会通过诸如校验和等的机制来尝试保留请求/响应报头的真实性。http报头充实在这个(非基于https的)环境中起作用，因为网元能够看到在线上的数据流中的请求和响应结构，并且还因为信息的插入/提取不会破坏任何安全机制。

https请求充实

https是使用加密进行通信的协议。ssl/tls是基本技术。加密技术使得中间人的观察者不可能知道加密密钥。在这种环境中，中间的网元不能破译加密的通信，它们也不能将任何数据插入加密流。因此，中间的网元无法以类似于http的方式充实https请求。

例如在服务器和客户端-服务器流程中间的网元之间传输通信充实信息的一种替代方案是使用“带外”方法。在这种方法中，网元可以在单独的连接上向网页服务器发送关于正在进行的https连接的充实信息。作为一个具体的例子，如果ip地址ip1处的移动设备连接到ip地址ip2处的服务器，则可以通过从网元到服务器的单独的https请求来实现上述示例的充实，该单独的https请求向ip2处的服务器发送一对<ip1，一些数据>。然后可能需要服务器将充实信息应用于正确的客户端请求，例如通过针对所接收的所有充实检查客户端的ip/端口。虽然这种方法适用于某些网络环境，但是在网络实体和服务器之间的网络地址转换(nat)设备存在的情况下，此类型的解决方案无法运行。在这种场景下，客户端的ip地址可能被网络实体视为ip1(前nat地址)，且被服务器视为ip3(后nat地址)。为了在nat存在的情况下成功地充实请求，网络实体或服务器必须具有在同一客户端的两个ip地址之间进行实时转换的方法。当网元在移动元素内部并且服务器位于公共互联网上时，几乎总是遇到nat问题。特别地，移动网关使用的nat机制通常没有用于转换(在本例中为)的实时api，这使得https请求的充实变得困难。

本公开的主题涉及这个问题，如现在描述的。

该技术为https请求提供ssl充实机制。

这种方法使得网元(在中间)可将充实注入到ssl连接中，并将其引出。这个网元有时在这里被称为“中间框”。在分层软件架构的环境中，此解决方案优选地由在ssl连接的两个端点处在ssl层下和tcp套接字层之上运行的库来实现。然而，这种实现并不旨在限制。

如将会看到的，这种方法具有几个有吸引力的特性。特别是因为将充实注入到ssl连接的数据流中，所以该方法不受nat问题的影响。以这种方式将充实注入数据流也比带外充实方法更有效。因为在优选实施例中，库优选地在ssl层之下，所以该实现不需要对ssl层(例如，openssl包)的任何改变。相反，实际上，就ssl协议而言，该库是一个中间人(mitm)实体。在协议栈中的这个位置，充实层与中间的其他实体(如wifi设备、防火墙，交换机、路由器、dpi框等)具有相同的有利的点。充实层与任何这些实体一样，既不能访问ssl连接的会话密钥，也不影响用于协商它们的机制。它对会话密钥的无知阻止了该层破译加密通信的内容和/或将正确加密数据写入代表任一端点的连接。此外，该层对于其在连接的端点或中间的网元中的操作不需要ssl证书。凭借上述特性，这种方法很容易被证明没有引入安全风险。

下文中进一步详细说明充实方法。

作为背景，为了与服务器建立ssl连接，客户端首先与服务器建立tcp连接；它然后继续进行ssl握手，其中发送和接收诸如客户端-问候(hello)、服务器-问候、证书等各种类型的消息。在握手结束时，建立会话(主)密钥，且加密的有效载荷开始在两个方向通过ssl连接。消息以及加密的有效载荷以ssl/tls记录的形式进行组织。记录格式被标准化，并且由图3中的记录300示出。该记录格式包括内容类型(或类型)字段、主要版本字段、次要版本字段、压缩长度字段、明文和消息地址码(mac)字段。明文和mac字段可以被加密。众所周知，在客户端402和服务器404之间的记录400的交换通常如图4所示进行。

对本公开的方案中进行工作的充实数据的内容和格式没有严格的要求。在非常基本的层面上，该方案只要求注入的数据不会改变ssl记录的原始内容，并且两个端点必须能够区分原始记录和注入的充实数据。为了简单地进行设计，优选地，将充实数据插入两个ssl/tls记录之间的连接(在任一方向上)，而不是直接插入任何原始记录的主体。此外，优选地，充实数据被表示为ssl/tls记录。因此，充实数据有时称为充实记录。

为了充实数据的识别，优选地，为充实记录的<类型、主要版本、次要版本>选择的值不一定是连接的合法值，例如，每个记录的第一个字节指定记录类型。对于sslv3，只有20-24范围内的值才是记录类型的有效值。根据本文的方法，可以要求(并因此使用)任何未使用的数字用于充实记录的类型。在一个示例性实施例(非限制性)中，-1被用作充实记录的类型。由于充实记录是标准ssl/tls协议的非法记录，因此如果ssl库在连接上看到该记录，则ssl连接将被终止。也就是说，由于充实库优选在ssl层之下运行，所以库的责任是不要在其之上将充实记录传递到ssl层。

在代表性的实施例中，如图5所示，服务器侧的软件层通常包括(从下至上)tcp500、tcp套接字层502、本公开的充实层504、ssl层506(例如openssl)和应用层508。图6示出充实层504提供给应用层508以发送/检索充实的各种功能600。图6中所示的功能是代表性的，并且可以组合各种操作。就应用层而言，简单地调用图6所示的一个或多个功能，以便从ssl连接中获取充实，通过该连接发送它们等。

下文提供根据该方法的代表性充实层504的另外的细节。

众所周知，ssl层506使用tcp套接字层502进行网络通信。具体来说，ssl层506使用具有套接字的标准系统调用，例如open()、close()、read()、write()、listen()和accept())。根据本公开，充实层504优选地通过使用系统调用封装机制来拦截在ssl库506和套接字层502之间的调用。特别地，系统调用优选地由充实层504封装，使得当ssl层506进行这些系统调用之一时，会调用充实层的相应(封装器)功能。除了执行其他操作之外，封装器功能还可以然后唤起原始系统调用。

因此，例如，当ssl层调用read()从网络接收数据时，将会调用充实层的读取封装器。这个函数又唤起原始系统调用read()函数来从网络接收数据。然后检查数据的ssl记录结构，并将其中发现的任何充实记录都取出；来自这些记录的充实数据优选地存储在用于到来的充实的存储表中，对应于它们被读取的套接字。然后将剩余的数据作为read()调用的一部分传递到ssl层。

当应用程序调用图6的其他api功能时，如获取ssl充实计数(getsslenrichmentcount())、读取ssl充实大小(readsslenrichmentsize())、读取ssl充实(readsslenrichment())等，充实层使用为每个套接字存储这些充实的表来响应调用。

当应用层调用写入ssl充实功能(writesslenrichment())时，优选地将结果存储到另一个存储每个套接字的输出充实的表中。当ssl层在套接字上进行write()调用时，将会调用充实层的写入封装器。这个函数又唤起原始系统调用write()函数来向网络发送数据。在任何ssl记录的边界写入套接字之后，从给定套接字的表中的传出充实数据构建一个充实帧，并将其写入套接字。

优选地，用于系统调用accept()和close()的封装器执行管家任务。

下文描述位于中间的网元(最好是移动网元)的作用，特别是如何使用ssl充实来充实ssl请求。在这个例子中，充实是用于终端用户设备的实时带宽向导。这只是一个代表性的例子，并不是为了限制使用这种方案可以实现的充实类型。在该示例场景中，并且参考图7，中间的网元700用作在客户端702和服务器704之间的透明tcp代理。移动网络的管理员可以配置网络路由，以便将发往服务器侦听端口(443)的所有用户的数据包发送到tcp代理。通常，代理700终止tcp连接，尽管这不是必需的。在逻辑上，如上所述，代理不是ssl端点；而是，它是ssl连接的中间人。它识别服务器ip地址，并单独连接到ssl端口上的服务器ip地址。因此，代理700充当该对连接之间的两个方向上的数据的转发器。此代理还链接充实库以用于请求充实操作。为此，在连接对寿命期间的任何时间点，代理可以调用writesslenrichment()api函数来将其客户端带宽向导的知识插入到与服务器704的ssl连接中。这在图7中示出，其显示了上述场景下的ssl记录流。在该示例中，充实记录705紧接在来自客户端702的第一ssl记录(即客户机-问候记录)之后。如果具有这样的通信的需求，则也可以在相反方向(即从服务器804向中间的网元800)发送充实805，然后再发送到客户端802。图8说明了这个选项。

当然，在ssl连接的路径中可具有多个网元，其每个可插入、提取或读取并转发充实。

由于充实记录的记录类型不一定是合法的ssl/tls记录类型，所以不应由任何发送者发送充实记录，除非确信接收者和中间的所有网元都可以无误地处理它们。发现路径和目的地是否“能够充实”优选地需要单独的方法。实现此功能的一种简单方法是通过设备配置。网元可以简单地采取接受充实作为其配置的服务器的列表。在单管理员环境中，这种类型的方法是有效的。然而，当多个管理域涉及通信时，则一个更自动的发现机制是有根据的。在这种场景下可以使用以下发现协议。

特别地，网元优选地观察通过其到所有与客户端形成连接的服务器ip地址的流量。网元然后发起与它们中的每一个的发现连接。作为发现连接的一部分，网元发起ssl握手，并在握手完成之前将充实记录插入其中。该充实记录识别发送者，并且它要求接收实体(或多个实体)识别自身。当目的地服务器或中间的网元不具有充实层时，其ssl层会看到充实记录，这导致其终止错误的连接。因此，网元知道服务器或到其的路径尚未准备好进行充实。当路径上的每个网元和目标服务器都能够处理充实记录时，然后通过将识别自身的充实记录添加到朝向发送者的ssl连接中来进行响应。如果与服务器的ssl握手成功完成，则网元可以断定到服务器和服务器本身的路径是能够充实的。网元还可以从接收自连接的充实中检索路径上的每个实体的识别。当发现过程根据需要完成时，网元可以将充实注入客户端到此服务器的ssl连接，如上所述。

上述方法能够在到目的地的路径中发现可充实的网元的存在，即使目的服务器本身不能够充实。

对于充实数据没有严格的加密要求。然而，在使用公共互联网的系统中，应实施充实数据的安全性。对于公共互联网上的服务器，接收到的充实数据通常不能信任，除非其来源是可信赖的，并且保证在数据发送后路径上的任何网络实体未篡改服务器。优选地，在这种情况下，充实数据应该用仅对两个端点已知的密钥来进行加密。

设备配置是为设备想要发送充实信息的任何网元和服务器提供公共密钥的简单方法。可选地，对于跨越多个管理域的系统，可以使用用于运行时的密钥协商的以下设计。假设服务器提供网元可以用来协商密钥的可公开访问的安全url。可为此目的扩展发现连接。除了要求服务器或网元识别自身之外，发现连接中的充实记录则也用于请求服务器揭示其密钥协商机制(即上述url)的细节。在接收到充实记录中的查询后，服务器返回在相同连接上发送给网元的充实记录中的url。在接收到安全url之后，网络实体向url提供单独的请求，提供其自己的识别(例如，客户端证书)。服务器然后验证身份。如果服务器想要接受来自网络实体的充实，那么它返回作为响应的一部分的密钥到实体。网元现在可以为到服务器的任何连接创建加密的和/或签名的充实。可以按照相同的程序，随时间根据需要再协商多次密钥。如上一节所述，即使服务器本身不能够充实，该方法也可以发现到目的服务器的路径中的能够充实的网元。在这种场景下，上述可以用于不涉及服务器的通信网元对的密钥的协商。

图9进一步示出了本公开的优选软件分层方法，并且特别地，中间框900中的充实层906如何与在ssl通信的每端处的层相互操作。在本实施例中，客户端902是连接到边缘服务器http代理904的移动设备(ue)。

图10示出了移动网络中ssl充实的各种应用。在该实施例中，各种网络服务被链接并且可以彼此交互。在该表示性的但非限制性的操作场景中，期望从边缘服务器1000向请求的移动设备(用户设备(ue))1002传递超顶(ott)自适应比特率流。中间框1004位于无线电接入网元(例如，enodeb应用程序)1006和边缘服务器1000之间。上述ssl充实是在所识别的服务中提供双向通信信道的方式。例如，这里网络向边缘服务器传输各种无线电条件(例如，推荐的bw限制)，且边缘服务器向网络通知所选择的流带宽。边缘服务器还通知中间框和enodeb应用程序它们应该在epc中和无线电上使用什么tcp优化设置。边缘服务器向ue的os平台通知流带宽。当然，这些只是表示性的https请求充实。

上述示例描述了本公开的技术如何提供无线电感知的ssl充实。无线电状态信息被收集，然后使用ssl充实作为ssl连接的一部分被发送到覆盖网络。通过获取该信息，覆盖网络可以适应和优化用于cdn中移动传递的内容，从而提供更好的移动用户体验、更高的网络利用率和更低的网络拥塞。

因此，本公开的技术提供了通过将充实记录注入ssl连接来提供充实数据，以及通过移除充实记录并将原始记录流发送到ssl层来检索充实数据。

实现所描述的功能的中间框的特定功能并不旨在是限制性的。通常，如上所述，充实随着数据包通过设备转发而被添加(例如，吞吐量信息)。

图11示出了如何可将服务发现协议1100(例如，在该示例中在边缘服务器1102中操作)并且如上所述用于发现具有能够充实的设备和其他服务api以及协商加密密钥。

可以看出，上述的充实技术依赖于ssl记录类型和版本号以在一方面原始的ssl记录(由连接的端点编写)和另一方面充实记录(由中间实体插入)之间进行区分。区分的这种具体方法并不旨在为限制性的。

对ssl的本文中的引用不应被视为限制性的，因为该方法也适用于传输层安全(tls)连接。因此，为了本文的目的，ssl和tls是可互换的。

因此，且如图5所示，介绍了tcp和ssl或tls之间的新层(即，图5中的充实层504)。凭借协议栈中的这个位置，充实层能够将任何方向上的ssl/tls连接上流动的数据识别为一系列结构化ssl/tls记录。在一个实施例中，为了传达数据的目的，新类型的ssl/tls记录(本文中有时也称为aux记录)然后被提供并优选地存在于在网络服务和其他服务器(例如，http服务器)之间的层处。如上所述，优选地，网络服务和服务器以aux记录的形式直接将其数据插入到ssl/tls连接中，并且检索它们。

图5中的充实层可以被实现为用户级库，例如在编译时与应用链接的用户级库。因此，优选地，本文中的方法以应用层机制进行操作，然而这不是限制。如上所述，优选地，充实层提供用于应用程序的api，以便通过机制发送或检索辅助数据。

优选地，aux记录不被插入到连接中，除非发送者确定它们不会在其预期目的地或任何中间网元处造成错误。另外，插入数据的实体必须知道目的地预期它到达的格式。

本领域技术人员将理解，本文描述的机制提供了用于端到端加密流量但是不以任何方式干扰加密的带内数据通信。优选地，该机制允许ssl/tls连接的任一端点或介入的中间框将辅助数据插入/检索/删除到连接的tcp流中。

作为选项，可以通过使通信实体以明文、签名明文或用辅助密钥加密的方式交换数据来保护在aux记录中交换的数据本身。

优选地，并且因为在表示性的实施例中，aux记录基本上是无效的ssl/tls记录，所以它们不被允许到达在tls连接的任一端点处的tls层。为了支持任一端点处的aux记录，如先前示出和描述的，优选地，在这种端点处的应用具有夹在tcp和ssl/tls层之间的记录处理层(例如，图5中的充实层504)。优选地，充实层负责处理aux记录，并保持它们达到tls层。

下文提供了有关可通过机制实现的表示性的发现和协商协议的另外的细节。为了描述的目的，协议的步骤在客户端向互联网上的服务器(s)发出https请求且数据流通过中间的网元(ne)的环境的上下文中呈现。该协议描述了ne应该做什么以启动与s的元数据通信。如下所示，充实层支持被称为“tls-aux”。

发现协议

1.如果s想向ne发送元数据和/或从ne接收元数据，那么它应该公开发布tls-aux支持，例如通过其ssl证书中的两个自定义选项。

·tls-aux-support选项可能具有send、receive或sendrecefe的值，指示服务器是否仅对发送元数据、仅接收元数据或两者感兴趣。

·选项tls-aux-negotiationurl可以包含url，其中任何感兴趣的ne可以协商用于(如果适用)aux记录的有效载荷的元数据和加密密钥的格式。

2.如果ne具有观察流量的能力，那么它可以从证书或握手的sni部分中发现服务于从ne到客户端下游的tls流量的所有服务器ip以及由它们托管的域名。此外，ne可以识别在其服务器证书中发布tls-aux支持的服务器的子集。对于tlsv1.2或以下的版本，ne应通过观察在线上的服务器证书来实现。对于tlsv1.3或以上的版本，服务器发送的证书被加密，因此不能被ne检查。在这种情况下，ne应该为由s服务的每个已知域名明确地发起与sni到s的tls握手。因此，它应从s检索所有域的证书，并检查它们以发现哪些域支持tls-aux。ne中配置的业务规则可能用于进一步初步列选ne应参与的与其的tls-aux通信的服务器。协商协议

一旦ne决定向服务器s发送和/或从服务器s接收元数据，则ne应该发起协商协议。优选地，该协议是来自实时用户流量的带外运行的。

1.所有协议协商都必须发生在ne向s发起的tls连接上。在建立tls连接之后，ne必须在进行任何进一步的通信之前将零长度的tls-aux记录插入此连接。如果此记录的插入会引起tls错误，那么ne必须断定s或到s的网络路径上的不可见网元不支持tls-aux。协议失败，且ne不可将任何tls-aux记录插入目的地为s的连接中。

2.如果步骤2没有失败，则ne应该向服务器证书中提供的协商url发出post请求。在post主体中，ne必须包含对服务器支持的元数据方案和加密方法的请求。

3.从ne接收到post请求主体后，s必须决定它是否参与和ne的元数据通信。为了拒绝，它必须使用http403(禁止)响应进行响应。如果s决定接受此请求，则它应创建用于在ne和s之间的元数据交换的新tls-aux会话。为了通知接受，它必须以http状态200(ok)进行响应。在响应主体中，s必须提供会话id、它要发送和/或接收的元数据类型、加密算法、密钥和密钥的到期时间。密钥是用于作为会话一部分交换的tls-aux记录的有效载荷的加密。ne和s都必须将密钥与会话相关联。如果s想要tls-aux记录的有效载荷在明文中，那么加密算法应该是这样指示的，且密钥将是无关紧要的。

4.如果ne的post请求指示它可能想从s接收元数据，那么在发送响应之前，s必须在此连接中包含零长度的tls-aux记录。

5.在接收到http200响应后，ne必须识别其想要向发送和/或接收的服务器的元数据类型的子集。然后它必须向同相同的url发出第二个post请求，识别会话中的发送和接收方向上的感兴趣的子集。

6.在接收到第二个post后，s必须用http200(ok)来确认或者用http403(禁止)来拒绝，结束协商。

在完成协商协议的步骤后，s和ne具有建立的tls-aux会话，其具有加密方案、会话密钥和到期时间的共同知识。元数据的发送者应使用密钥对通过tls-aux记录发送的元数据进行加密或签名。在到期日期后无法使用密钥。任何时间可以由ne重新协商tls-aux会话以获得有效的密钥。

互联网路由不稳定并可以随时间变化。这意味着任何新的不兼容网元可能会在现有tls-aux会话的生命周期内被引入到在ne和s之间的路径中，这可能会阻止流量，直到建立的会话的生命周期结束。到期后会话的重新协商将补救这种情况。可以认为，检查tls记录结构的网元可能存在于连接的端点附近(例如，移动网络的gi-lan中的服务或在托管服务器的数据中心里的安全设备)，而不是在公共互联网路径中。因此，与在端点附近网络配置的变化相比，互联网上的路径变化远不太可能引起这种情况。由于网络和服务器是tls-aux会话中的有意参与者，因此它们可被预期通过其操作流程避免这种情况。

会话识别

只要在ne和s之间存在有效的tls-aux会话，它们可以将tls-aux记录插入用户的数据流中/从用户的数据流中删除。然而，网络中间框通常是透明的或位于私有网络空间中，这使得它们对s不可见。因此，当用户的tls连接到达s时，其可能不可能辨别其可能属于哪个tls-aux会话，这是定位用于破译包含在tls-aux记录中的元数据和知道哪些元数据参数已经为该会话协商的解密密钥所需的。为了帮助s识别会话，如果ne打算与s交换用于任何tls连接的元数据，那么它应该向s发送tls-aux记录，其在tls连接建立开始时发送一个包含session-id。s不能在任何连接上发送任何tls-aux记录，除非它能够识别连接所属的tls-aux会话。

虽然协议在上文中在一个ne和一个s的背景中进行了描述，但是对于具有沿着客户端和s之间的路径的多个ne的环境是可扩展的。在这样的环境中，每个ne必须与服务器协商其自身的tls-aux会话，且客户端与服务器之间的tls连接可能属于多个tls-aux会话。下面的库描述假定用于每个连接的单个tls-aux会话。支持多个会话的扩展是明确的。

下文提供了关于在一个实施例中的tls-aux库的实现的另外细节。如上所述，在终止tls连接的任何实体处，在aux记录能到达tls层之前，必须处理和删除它们。下文是用于实现参考的库的方法。它是一个用户级库，其在编译时与应用程序链接，并具有几个特定的系统调用封装器选项。为了识别连接的tls-aux会话并在连接上发送/接收元数据，应用程序应调用api函数并提供tls连接的文件描述符。在tls-aux记录中处理加密或元数据签名的任何责任优选地位于库中，并且应用程序被期望使用未加密的元数据。

系统调用封装

诸如openssl的tls库是用户空间库，且它们为网络通信使用tcp套接字。它使用具有底层套接字的标准系统调用，例如open()、close()、read()、readv()、write()、writev()、listen()和accept())。tls-aux层通过使用系统调用封装的机制来拦截tls库和套接字之间的调用。tls-aux库劫持所有上述系统调用，从而使得当tls库进行这些系统调用的其中一个时，会调用tls-aux层的相应功能。如下文所述，除了执行其他操作之外，该层然后可唤起原始系统调用。

接收元数据

当tls层调用read()从网络接收数据时，tls-aux层的读取封装器函数被调用。这个功能反过来唤起原始系统调用read()来从网络接收数据。read()封装器函数然后对从网络接收到的数据进行操作，将tls-aux记录与原始的tls记录分开。从任何tls连接上的tls-aux记录接收的元数据被解密或存储在与该连接相对应的存储器表中。然后将剩余的数据作为read()调用的一部分传递到tls层。当应用程序调用api函数，如get_tlsaux_item_count()、read_tlsaux_item_size()、read_tlsaux_item()等时，tls-aux层使用为每个连接存储这些项目的表来响应调用。

发送元数据

如前所述，元数据可能不会在tls连接上被发送，除非可以识别其tls-aux会话。当其被发现并且应用层调用write_tlsaux_item()时，其被存储到存储用于每个文件描述符的输出元数据的另一个表中。当tls层在连接上进行write()调用时，tls-aux层的写入封装器函数被调用。此功能反过来负责将tls-aux记录写入连接，接着是作为write()函数的自变量来接收的原始加密的tls记录。

处理aux帧有效载荷的加密

一旦tls-aux会话由具有ne的应用程序建立，则其可以使用setsessiondetails()函数在库中设置会话的加密细节。然后，库可以使用加密方法和密钥来解密tls-aux消息中的元数据，或者检查签名的有效性。

所描述的机制的应用程序有很多。

典型的用例是其中移动网络想向位于公共互联网上的媒体服务器(cdn或其他)发送元数据从而可以优化媒体传递的一个用例。

另一种用例是其中移动网络将元数据发送到位于公共互联网上的媒体服务器以优化网络资源的使用并为其订阅者提供更好的qoe的一个用例。

又一种用例是其中公共互联网上的网页服务器想向位于移动网络的私有网络空间内的代理发送元数据的一个用力。当然这些只是表示性的例子。

现在描述用于插入充实的替代方法。在这种方法中，中间框上的充实库和连接的两个端点支持ssl记录封装协议。记录封装器的结构以例子的方式在图12中示出。在一个实施例中，封装器1200具有两个报头字段(版本和类型)，并且意图将ssl记录作为其有效载荷封装。报头字段的值优选地识别封装器是否包含ssl记录，或者其是否包含与ssl记录不同的信息。例如，封装器类型0可以用于指示封装器的有效载荷是原始的ssl记录，而封装器类型1可以指示有效载荷是充实信息。这些只是表示性的类型值。

下文描述参与者(连接的中间框或任一端点)如何在此替代技术中读取和写入充实。首先描述写入充实场景。特别地，在相关流程的每个参与者，优选地，充实库观察每个ssl连接上的记录流。记录可以是原始的ssl记录，或者它们可以由另一个实体封装。如果记录没有被封装，优选地，当它们通过时库将它们封装。然后，在任何封装的ssl记录结束之后插入将要插入连接的任何充实数据。在该示例中，可以将充实数据作为类型1的封装器的有效载荷插入。然后读取充实可以如下进行。在每个参与者处，充实库都观察记录流。记录可以作为常规ssl记录到达，或者它们可以作为封装记录到达。基于封装器类型字段，库识别充实，并从数据流中取出相关记录。如果库恰好位于任一端点上，那么在将封装的ssl记录传递到ssl库之前，库也优选地将它们打开。

更一般地，本文描述的技术是使用一起促进或提供上述描述的功能的一组一个或多个计算相关实体(系统、机器、过程、程序、库、功能等)来提供的。在典型的实现中，在其上执行软件的表示性的机器包括提供给定系统或子系统的功能的商用硬件、操作系统、应用程序运行时环境以及一组应用或过程和相关联的数据。如所描述的，功能可以在独立的机器中或跨分布式的机器组实现。该功能可以作为服务提供，例如作为saas解决方案。

虽然上面描述了由本发明的某些实施例执行的操作的特定顺序，但是应当理解，这种顺序是示例性的，而替代实施例可以以不同的顺序执行操作，组合某些操作，重叠某些操作等。本说明书中对给定实施例的参考指示所描述的实施方案可包括特定特征、结构或特性，但是每个实施方案可以不必包括该特定特征、结构或特性。

虽然已经在方法或过程的上下文中描述了所公开的主题，但主体公开还涉及用于执行本文操作的装置。该装置可以由于需要的目的而被特殊地构造，或者其可以包括由存储在计算机中的计算机程序选择性地激活或重新配置的通用计算机。这样的计算机程序可以被存储在计算机可读存储媒介中，例如，但不限于，包括光盘、cd-rom以及磁光盘的任何类型的盘、只读存储器(rom)、随机存取寄存器(ram)、磁性或光学卡或者适于存储电子指令且均耦合至计算机系统总线的任意类型的媒介。虽然已经分别描述了系统的给定组件，但是普通技术人员将会理解，一些功能可以在给定的指令、程序序列、代码部分等中组合或共享。

优选地，功能在应用层解决方案中实现，然而这不是限制，因为所识别的功能的部分可以内置到操作系统等中。

该功能可以使用除了https之外的其他应用层协议(例如sslvpn)或具有类似操作特性的任何其他协议来实现。

对于可以实现连接的客户端侧或服务器侧的计算实体的类型没有限制。任何计算实体(系统、机器、设备、程序、过程、实用程序等)可以充当客户端或服务器。