在无中间人代理的情况下解密传输层安全流量的制作方法

相关申请的交叉引用

本公开涉及序列号为15/946,597的美国专利申请，该美国专利申请与本申请具有相同发明名称、相同发明人、并且与本申请同日提交，该美国专利申请的全部内容通过引用合并于此以用于所有适用目的。

本文描述的实施方式总体上涉及用于支持更强密码和安全性增强以为web服务器和其它企业服务器提供恶意软件和病毒防御的改进的入站安全套接字层(ibssl)的方法、系统和装置。

背景技术：

如今，越来越多的web服务器正在迁移到安全超文本传输协议(通常称为https)的更安全的版本。https使用安全套接字层(ssl)和传输层安全性(tls)，以根据需要为不同级别的安全性提供不同级别的加密。随着利用https改进加密技术，像入侵防御系统(ips)或病毒/恶意软件扫描防火墙的网络感测设备执行数据包检查以分析网络流量并识别潜在攻击的难度越来越大。已经开发了能够以两种方式解密网络数据包中的数据的传感器。第一种方式称为中间人(mitm)代理。第二种方式称为“已知密钥”方法。

在一些实现方式中，有时称为传感器的网络安全平台(nsp)更倾向于使用“已知密钥”方法，因为对于大负荷(例如，大量网络流量和/或大量客户端)而言，该方法更高效。对于旨在保护企业网络内的web服务器免受公共网络(例如，因特网)上不受信任的客户端的攻击的web服务器而言，尤其如此。可以将这种网络数据的分析称为网络传感器或防火墙(例如，受保护网络边缘处的nsp或其它计算机设备)上的ibssl解密特征。在现有技术的系统中，解密特征基于以下原理：在nsp/传感器上提供“要保护的web服务器”的已知私钥，作为该nsp/传感器的网络配置的一部分。该单个私钥可以用于对去往/来自web服务器的加密流量进行解密。针对ssl/tls保护提供的标准为用于实现安全性的一套公钥加密算法提供了支持。然而，已知如今的ibssl仅支持rsa算法(rsa是以其发明者rivest-shamir-adleman的名字命名的)，rsa算法是一种广泛使用的算法。尽管rsa被广泛使用，但是在该算法中仍然存在弱点。结果，引入了具有更频繁更改的密钥的更强的密码。

过去，作为保护设备(例如，nsp)的配置的一部分，管理员提供了已知私钥，如上所述。结果，例如，nsp或其它设备可以执行其函数，直到在web服务器上更改密钥为止。用于保护网络流量的最新引入的技术包括更频繁地更改web服务器密钥，从而使管理员在nsp类型的设备上更改密钥变得不切实际。在没有密钥的情况下，nsp无法检查网络数据包的内容(例如，深度数据包分析)及其容量，至于对恶意数据的防护就会降级。公开的技术通过以下方式来部分地解决该问题和其它问题：提供一些增强功能，以允许nsp和其它网络保护设备即使在web服务器加密密钥(例如，由较新的密码套件使用的临时密钥)频繁更改的情况下也能够继续执行所需分析。

附图说明

图1是根据一些公开的实施方式的表示计算平台100和在通信上联接至计算平台100的网络的组件的框图。

图2是以流程图形式例示的处理200的示例，其表示根据一些公开的实施方式的、配置网络和处理加密网络消息的一个示例。

图3是根据一些公开的实施方式的表示网络安全平台(nsp)305的组件的子集和openssl310的逻辑分层表示的框图。

图4例示了根据一个或更多个公开的实施方式的框图400和框图450，框图400和框图450表示计算机处理设备和被配置成拦截加密信息(例如，密钥或解密数据)的计算机处理设备的逻辑层。

图5例示了根据一个或更多个公开的实施方式的、回调的流程图500表示，该回调可以用于为利用临时密钥的加密技术拦截和传送加密密钥信息。

图6例示了根据一个或更多个公开的实施方式的，客户端、传感器(例如，nsp)与web服务器之间的消息和信息流的时间线600。

图7是例示了根据一个或更多个实施方式的、与本文描述的技术一起使用的处理设备(例如，可编程设备700)的框图。

图8是例示了在通信上联接至网络的、与本文针对一个或更多个实施方式描述的技术一起使用的计算设备(例如，可编程设备800)的框图。

具体实施方式

如以上背景技术部分中简要提及的，网络传输的安全性仍在不断发展。随着攻击变得越来越复杂，用户和企业都在增加其安全措施。具体地，正在采用更强的加密技术(例如，更强的密码)和更不易受攻击的加密技术(例如，更安全的密钥)。就web通信而言，近年来tls/ssl的使用有所增加，并且这些标准已得到增强，以允许使用更强的密码和临时密钥。http2.0的使用也在增加。http2.0的当前已知实现方式要求使用tls来获得数据的机密性。需要诸如入侵防御系统ips或web应用防火墙waf的网络安全平台(有时称为网络安全设备，或简称为网络设备)，以对tls通信数据包进行解密，使得可以针对病毒和恶意软件检查tls通信数据包的内容，以保护web服务器免受攻击。通常，可以将网络设备实现成以下列三种方法中的一种或更多种方法执行解密分析(这三种方法的组合也是可能的)。

在第一种方法中，网络设备可以被配置成充当通信的中间人(mitm)tls代理。使用mitm方法，网络设备可以例如物理地和逻辑地位于客户端与受保护的web服务器之间的网络通信路径中。客户端与网络设备建立一个tls会话，也许没有意识到网络设备不是实际的web服务器，并且网络设备与服务器建立另一会话。在该mitm场景中，网络设备可以从客户端接收去往web服务器的所有消息，并在将消息的“确定是好的”数据包转发到web服务器之前执行分析。以这种方式，网络设备充当客户端与服务器之间的防火墙、网桥和代理。因为这两个会话(例如，客户端到网络设备和网络设备到web服务器)是由网络设备终止和启动的，所以设备可能能够解密有效载荷。具体地，针对与永远不会直接与web服务器进行通信的实际客户端的各个会话，可以使用不同的加密技术和密钥。因此，如果更改了通信加密密钥，则不必将其传送给所有各方。mitm方法的开销至少是两倍，因为在该示例中，作为mitm处理的一部分，mitm必须执行数据的完整的解密和重新加密。

在第二种方法中，基于用户(例如，web服务器管理员)配置，在web服务器与网络设备之间存在公钥/私钥对信息的共享。因为可以使加密密钥信息可用于网络设备，所以网络设备在将原始消息转发到服务器之前，可能能够解密所有tls通信以进行分析。因为网络设备正在使用与服务器用来解密和加密(例如，在客户端处)与该服务器的所有tls通信的密钥相同的密钥，所以这可以称为“共享密钥方法”。该方法可能比mitm方法(上面讨论的第一种方法)的开销要少得多，因为网络设备只需要解密通信，并且在将消息的“确定是好的”数据包转发到web服务器之前无需执行tcp分段操作或重新加密传输。也就是说，网络设备在来自网络的通信到达web服务器之前拦截该通信、在不更改数据包的通信参数的情况下执行“观察(look-in)”分析、并允许任何令人满意的数据包继续前进到web服务器。为了使传统的共享密钥方法工作，tls可以使用基于rsa的密码套件，因为该密钥对于web服务器而言是静态的，并且可以由系统管理员提供给网络设备作为其初始配置的一部分。网络设备可以利用该静态密钥来执行其分析。然而，由于所有会话的密钥都是相同的并且可能是持久的，因此静态密钥密码技术可能易于遭受密钥破解。有时，可以将密码配置成在客户端与服务器之间使用diffie-hellman交换来找到随每次会话而更改的密钥。因此，系统管理员方法将不适用于该加密技术。另外，tls版本1.3设置为移除对使用rsa来获得密钥的密码套件的支持。结果，可能需要用于密钥管理以实现密钥共享方法的新技术，并且在下面进一步讨论。

在第三种方法中，可以在服务器负载平衡器处终止来自客户端的tls通信。然后，服务器负载平衡器可以在不加密的情况下将客户端通信发送到服务器。服务器负载平衡器与web服务器之间的网络通信路径中的网络设备可以被配置成检查并分析处于未加密状态的数据。与第一种方法或第二种方法相比，该第三种方法引入了不同类型的安全问题，因为入站消息的“最后一程(lastleg)”未解密，并且可能以纯文本形式使用。(例如，服务器负载平衡器与web服务器之间的)“内部”网络上的纯文本数据可能允许其它设备(或人员)潜在访问敏感数据。

本公开的技术通常应用于保持端到端安全性的实现方式中。与严格在私有数据中心内进行的通信相反，通信的端到端隐私可能是公共云环境上更为重要的问题。接下来呈现公开的实施方式的两个方面的高度概述，随后根据需要参照附图呈现公开的技术、方法和系统的更详细的实施方式。

密钥交换实施方式的高度概述

高度概括地，公开的实施方式解决了客户端到网络设备到web服务器tls通信会话的问题。下面讨论的图1例示了网络安全平台(nsp)105，该nsp105表示本概述讨论中使用的网络设备的示例。各个网络通信会话(通常简称为“会话”)都始于客户端通过发送clienthello握手消息来发起会话。配置有强密码(例如diffie-hellman)的服务器生成公钥值，该公钥值将用于会话其余部分的密钥生成。clienthello消息还包含加密强度高的随机数。接下来，网络设备可以在客户端和服务器通信的网络流与它们的随机数之间创建映射。

接下来，客户端可以生成其公共值、获得会话密钥、并利用其公共值做出响应。客户端还可以指示已准备好使用changecipherspec握手来协商加密的详细信息。然后，web服务器可以使用其自身的公共值以及客户端的公共值来生成会话密钥。拦截器逻辑(其可以例如在web服务器上的程序或库函数中实现)获取该会话密钥，并通过安全链路将会话密钥与客户端和服务器随机数一起提供给网络设备。然后，网络设备可以“查找”映射到上面创建和获取的该组客户端和服务器随机数的关联网络流。

网络设备可以将密钥信息存储在内部数据结构中，该内部数据结构可以保持特定客户端到服务器网络流(例如，会话)的关联。然后，web服务器可以以准备好使用changecipherspec进行加密来做出响应。此时，网络通信可以包括从客户端流向服务器或从服务器流向客户端的应用数据。

当应用数据经过网络设备时，网络设备现在能够使用所存储的并与特定网络流相关联的密钥来解密任何tls加密记录，并在网络设备上安全地且在本地检查未加密的应用数据。由于密钥是由上述拦截器逻辑自动获取的，因此每次密钥改变时都可以获取密钥，并经由辅助安全通信路径自动将密钥提供给网络设备。

出于安全性原因，按这样的方式提供拦截器逻辑可能是必要且期望的：由web服务器的系统管理员将其作为web服务器配置的一部分来配置。然后，拦截器逻辑可以在无需系统管理员的进一步日常介入的情况下运行。

密钥拦截实施方式的高度概述

在大多数实现方式中，web服务器使用共享库(例如，linux上的dso和windows上的dll)来实现tls协议。用于拦截密钥或解密数据的一种方法包括拦截或挂接(hooking)对该库的函数调用，以获取针对各个会话计算的加密密钥。一旦拦截，就可以通过所公开的安全辅助通信路径将密钥信息发送到被配置成保护对应web服务器的一个或更多个网络设备。

然后，使用密钥信息，适当的网络设备可能能够解密会话的数据消息，并执行适当的分析和检查(例如，深度数据包分析)。在密钥未被拦截的实施方式中，解密数据可以被拦截并且经由安全辅助通信路径发送到一个或更多个网络设备以供检查。

密钥的拦截表示更高效的实现方式，并且是该示例实施方式的主题。应注意，密钥是在会话中的应用数据流之前在客户端与web服务器之间协商和发送的。如果在初始密钥交换之后使来自会话流的数据可用于网络设备，则web服务器和网络设备可以暂时利用可能效率较低或次优的实现方式(例如，传输解密数据)，直到可以再次拦截到密钥数据为止。

当密钥被拦截后，可以使用在网络设备处存储的信息将密钥与特定会话相关联，以使得网络设备可以适当地保持各个会话的密钥数据。还应注意，由于密钥是在web服务器处拦截的，因此在该示例实施方式中，不需要网络设备执行生成密钥所需的密集加密操作，并且可以进一步提高网络设备的效率。另外，适当实现的密钥拦截实施方式不需要执行作为网络中的代理而需要的tcp分段，从而节省了否则将是tcp分段所需要的额外cpu周期。

在web服务器的openssl共享库实现方式中，在接收到每一个握手消息后，向服务器提供回调。tls会话的一般流程在称为rfc5246的因特网标准中定义，并在下面参照图6进行进一步讨论。在该握手框架中，客户端和服务器在分别接收到serverhello和clientkeyexchange消息后将计算加密密钥。在服务器上，在发送changecipherspec消息之前，拦截器库可以登记回调，其获取以下内容：将用于会话的加密密钥、客户端随机数和服务器随机数。一旦获取，例如，web服务器上的代理就可以经由安全辅助通信路径与网络设备上的代理进行通信，以将任何所需的已获取的数据发送到网络设备。

在完成会话的握手启动后，在会话上进行正常的应用数据流，并且可以在客户端与服务器之间交换加密应用数据。因为在应用数据流之前已经使网络设备知道密钥材料，所以网络设备可能能够解密该客户端/服务器会话中的所有消息。此外，在一些实施方式中，网络设备可以使用随机数(即，客户端和服务器随机数)来识别与适当的密钥材料相关联的网络流(或会话)。

该实施方式的变型可以是将挂接放置在web服务器进行的以读取解密数据的库调用中。例如，利用openssl，拦截器库可以挂接ssl_read()和ssl_write()调用，并经由网络或安全辅助通信路径(例如，明文)以某种方式将有效载荷发送到外部设备以进行处理。在该变型中，效率可能不是最佳的，但是由于网络设备接收到明文应用数据，因此无需向网络设备发送密钥。如以上简要提及的，由于预期具有端到端加密的数据的明文传输，这可能引入不同的安全问题，并且可能以临时方式使用，直到可以交换密钥为止。

针对上述各种实现方式，可以以客户端和web服务器不可见的方式来执行将拦截器库加载到web服务器程序环境中。在大多数情况下，这些实现方式应通过系统管理员配置更改来执行，但对于其它计算机系统(参见图4)而言可能仍然不可见。例如，在一些unix或posix兼容操作系统中，可以通过设置ld_preload环境变量来为程序预加载共享库。在加载期间，可以挂接必要的函数调用，以使得通过所公开的拦截器库创建了共享库“封装器(wrapper)”。

鉴于对密钥交换方面和密钥拦截方面的以上理解，现在将根据需要参照附图来讨论公开的技术、方法和系统的更详细的实施方式。尽管从web服务器的角度描述了拦截技术，但是在ssl连接的客户端侧上进行拦截的另一实现方式也是可能的。在一些实现方式中，客户端侧拦截器库和例如这次在客户端与nsp105之间的安全辅助通信路径可以被配置成按与本文针对web服务器描述的方式类似的方式工作。

如上所述，在tls通信中，终端节点客户端和服务器通告其加密算法能力，并基于双方都支持的共同因素通过称为握手的过程达成协议。在握手中，客户端和服务器开始使用非对称密码算法来交换对称密钥，该对称密钥将用于加密应用数据。tls规范推荐三种算法：rsa、dh和ecdh。第一种算法是密钥交换算法，其中客户端生成对称密钥并通过加密网络发送该对称密钥，而后两种算法是密钥协商算法，其中，两个终端方通过数学函数生成公共对称密钥。本质上，没有通过网络交换密钥。

由于不断提高的安全性要求和数据隐私限制，客户(和web服务器)正从rsa公钥交换套件转变到支持完美前向保密(pfs)的更强密码。简而言之，pfs意味着如果流氓实体在以后的一时间点获取了私钥，则该流氓实体将无法解密先前的加密通信。diffie-hellman及其变型是提供pfs的加密算法。但是由于公钥和私钥的密钥对是动态生成的，因此ibssl的现有技术实现方式中使用的已知密钥方法无法利用pfs密码套件。结果，被配置成使用pfs套件的现有技术的web服务器导致传感器(例如，网络设备)只是使具有临时密钥的任何会话的加密流量通过。显然，不期望在不进行检查的情况下就传递数据，因为这可能在任何web服务器保护方案中都会导致安全漏洞。

图1例示了根据一些公开的实施方式的表示计算平台100和在通信上联接到计算平台100的网络的组件的框图。在计算平台100中，nsp105可以被配置成执行称为“sslkeyserver”112的安全服务器。在该示例中，各个sslkeyserver112被示为与sslagent151具有安全辅助连接。例如，经由nsp105上的带外管理端口120的“带外”连接。通过管理端口120的带外连接可以是本文描述的安全辅助连接的一个实现方式。安全辅助连接可以用于在web服务器150与网络安全平台nsp105之间安全地共享未加密数据或密钥。在一个实施方式中，安全辅助连接可以使用pfs密码通过加密信道传输数据。另选地，可以使用基于网络的连接或非网络连接(诸如，各个web服务器150上的io端口与nsp105上的io端口(例如，带外管理端口120)之间的数据电缆连接)来实现安全辅助连接。此外，可以建立虚拟专用网络(vpn)，作为用于sslkeyserver112与sslagent151之间的安全辅助连接的数据传输。

安全辅助连接的其它实现方式也是可能的(或者如果需要，可以使用多个不同类型的同时可用的连接)，目的是使得仅web服务器150和适当的nsp105能够获取密钥数据或未加密会话信息。当然，在可能不太安全的实施方式中，可能不需要利用安全辅助连接来实践公开的实施方式。本来可以通过安全辅助连接发送的数据也可以例如经由网络接口115通过web服务器150与nsp105之间的传统网络通信路径发送。不管安全辅助连接的实现方式如何，可以使用网络接口115或管理端口120在任何web服务器150与nsp105之间交换会话数据流。例如，除了具有与网络130的标准网络通信连接之外，各个web服务器150可以连接到网络130，以在安全辅助连接上与nsp105进行通信。尽管为了附图清楚起见，在图1中例示了单个网络130，但可以使用任何数量的互连网络。

图1还例示了公共网络135和可以经由公共网络135连接到计算平台100的客户端计算机140。在计算平台100内部，网络130可以表示私有网络(例如，托管web服务器150的企业内部的网络)。密钥服务145也被示为连接到网络130，并且在一些实施方式中可以被用于存储加密密钥，例如，针对未存储在密钥存储部129中的密钥，或者针对可以从密钥服务145提供给附接到网络130的其它计算实体的密钥。nsp105是网络设备的示例，并且可以包括一个或更多个处理器110。处理器110可以在通信上联接到非暂时性存储设备125，该非暂时性存储设备125可以存储处理代码(例如，模块或程序)，以将处理器110配置为执行被描述成由根据本公开的网络设备执行的一个或更多个动作。例如，处理代码126可以用于解密会话数据或接收先前解密的(例如，纯文本)数据，使得可以由处理代码128对其进行分析。处理代码127表示密钥交换代码，该密钥交换代码可以包括参与如在整个本公开中描述的密钥拦截的代码。最后，非暂时性存储设备125包括密钥存储部129，该密钥存储部129可以用于存储密码信息和用于保持与可能在计算平台100中同时活动并由nsp105处理的多个会话的适当关联的信息。附加代码模块是可能的，并且非暂时性存储设备125的该组件列表不一定是穷举的。此外，代码模块的集合可以一起参与以充当在nsp105上执行的sslkeyserver112，以与存在于任何web服务器150上的sslagent151进行交互。

在以下几段中，讨论了针对以下项的实现要求和选项的示例：sslkeyserver112(在与sslagent151进行通信的nsp105上执行)；sslagent151(在作为sslkeyserver112的通信配对方的web服务器150上执行)；以及传感器设备(例如，在防火墙或路由器上实现的nsp105)。在对可以被配置成一起工作以支持本公开的系统范围的实现方式的这些组件的该讨论之后，参照图2至图6提供了对总体系统的讨论以及一个或更多个可能的实现方式的其它细节。在系统级别讨论之后，参照图7至图8提供了可以使用的处理器和组件的各方面。

sslkeyserver112

在一个示例实现方式中，sslkeyserver112可以被配置成执行支持一个或更多个公开的实施方式的各种功能(或者甚至不与本公开直接相关的附加功能)。也就是说，sslkeyserver112(和sslagent151)可以被配置成通过插件或其它类型的后期开发(后部署)配置方法来自适应，以使得网络管理员可以使用所公开的基础设施来支持附加能力。

为了实现sslkeyserver112，可以部分地基于操作系统和硬件能力的架构含义来使用各种类型的软件应用配置选项。例如，实现技术可以包括：web服务器应用的插件；独立的可执行文件；持久进程、操作系统的扩展(例如，共享库)等。在一个示例中，可以在会话边界控制器(sbc)进程组内部引入新的linux进程。该新进程可以被配置成运行sslkeyserver112，该sslkeyserver112可以被配置成接受来自安装在客户端传感器设备上的(例如，nsp105上的)任何sslagent151的ssl连接。

为了清楚起见，在本公开中讨论了两个客户端。在客户端设备(例如，计算机140)上执行的web浏览器可以称为客户端应用/设备。同样，传感器(例如，nsp105)表示相对于服务器(例如，web服务器150)的客户端设备，并且sslagent151表示关于sslkeyserver112的客户端。使用“客户端”一词的上下文将使本领域普通技术人员清楚所指的是哪个客户端。通常，无条件地引用“客户端”将指web浏览器客户端。

示例新进程还可以创建共享存储区来存储密钥信息。在一个示例中，密钥被存储在映射在共享存储器上的哈希表中。在该示例中，客户端随机数(cr)和服务器随机数(sr)字段可以用作哈希函数的密钥(例如，类似于提供唯一查找的数据库表的记录中的密钥要素)。然后可以将主密码(mastersecret，ms)存储为值。该进程可以获取(例如，被分配)的共享存储区应该足够大以容纳用于平台上支持的最大数量的ssl连接的密钥和其它所需数据。

在一个实现方式中，sslkeyserver112可以创建共享存储器以托管随机数(例如，cr和sr两者)和主密码。各个记录可以是占用128字节数据的可变长度消息。参见图5的要素550，该要素550包含客户端随机数555、服务器随机数556和主密码557。在一些情况下，可以填充记录以具有一致的记录长度。可选地，可变长度消息可以占用不同量的数据，但是该实现方式可能更复杂并且不能提供足够的益处来抵消复杂性带来的成本(例如，处理开销vs存储器)。如上所述，被配置成支持在共享存储器中存储0.1m记录的系统可能导致共享存储器使用16mb来存储密钥信息。

在一个实施方式中，sslkeyserver112可以读取从ip地址(例如ipv4和ipv6两者)的网络安全监控(nsm)获取的配置，以用于可以连接到传感器并更新传感器的防火墙配置的设备。在不具有该信息的情况下，由于安全限制或其它原因，sslagent151可能无法连接到传感器(例如，nsp105)。在使用中，sslkeyserver112可以提供自签名证书。例如，适用于与nsp105连接的rsa证书可以与sslagent库一起打包，以安装在各个适当的web服务器150上。该证书和私钥可以与传感器软件一起预先配置，使得安装特定传感器的系统管理员将获取适当匹配的sslagent库。在打包在传感器映像中之前(例如，由传感器供应商存储在非暂时性存储设备125中)，可以使用aes256-gcm(或某种其它加密技术)对私钥进行加密。sslkeyserver112然后可以在其初始化过程期间解密文件系统上的私钥，并将该私钥提供给web服务器上的openssl库。sslagent151和sslkeyserver112也可以使用安全网络连接，并能够支持用于对称密码的dh(e)或ecdh(e)密钥交换算法以及aes256(cbc/gcm)。在一些实现方式中，sslkeyserver112执行清理任务以清除已被任何nsp模块(参见图3的表示与共享存储器315交互的硬件或软件nsp模块的要素325)标记为删除的任何记录。例如，在成功查找之后或进行清理，因为记录可能已经老化了一段可配置的时间(例如，10秒或更多秒)。在一个示例中，sslkeyserver112可以使用linuxepoll机制来复用来自sslagent151的ssl/tcp连接。这可以使用可变数量的p线程来实现，以基于容量提供适当的缩放。

sslagent151(在web服务器150上)

如上所述，可以将sslagent151配置成被安装在各个web服务器150上的软件，以与openssl库连接(或封装openssl库)。在一些实现方式中，sslagent151利用openssl中提供的回调机制来获取对各个ssl握手进程的访问。在一些情况中，例如，当无法使用回调机制时，sslagent151可能覆盖由web服务器调用的sslapi的一个或更多个函数。因此，sslagent151可以使用回调和api封装器的组合来得到所需的信息(例如，用于解密和/或密钥交换)。在一些实施方式中，sslagent151可以建立到各个传感器(例如，nsp105)的安全辅助连接，并在该安全通信路径上提供会话密钥。sslagent151可以被配置成支持大多数常用的操作系统发行版。sslagent151还可以与关联的传感器的公钥一起打包(例如，在传感器供应商处)，并且可以使用该预打包密钥来建立到适当传感器的初始ssl连接。以这种方式，可以向系统管理员(和公司)提供初始安全网络，使得当新设备最初插入网络时不存在安全漏洞。认证可能是关键的，因为各个sslagent151可以访问适当的传感器(例如，nsp105)并与其共享将来的会话密钥。获取信息的任何流氓实体(例如，在配置安全性之前)都可能破坏安全通信基础设施。部分由于这个原因，所公开的示例表示在供应商处为安全性而预先配置的设备和库，而不是作为安装的一部分。显然，使用出厂安全默认值(其对每个购买者而言可以是唯一的)完成安全安装后，系统管理员能够更改这些密钥以使其相对于出厂安全默认值而改变。

可以在现有的tcp连接上建立各个ssl连接。因此，唯一识别ssl连接的方法之一是使用tcp连接的5元组。然而，似乎没有直接方法可以从openssl库得到该5元组信息。为了解决这个问题，一个实现方式使用了ssl握手过程的已知字段，这些字段被假定为跨在特定设备上活动的所有ssl连接是唯一的。用于该用途的两个潜在参数的一个示例是在clienthello中发送的客户端随机(cr)数和在serverhello中发送的服务器随机(sr)数，这些随机数是在针对ssl握手协议的一系列消息中发送的。在一些实现方式中，这两个字段用于识别ssl连接并映射到对应会话密钥。cr字段和sr字段的大小通常均为32字节。会话密钥通常为48字节。因此，当将所有这些全部加在一起时，针对期望传感器支持的每一个新的ssl连接，sslagent151向传感器(例如，nsp105)发送128字节(根据需要添加填充)。还应注意，有时仅在连接开始时交换密钥。这里涉及的会话密钥是指使用ssl术语描述的主密码(ms)。在实际的ssl实现方式中，首先生成预主密码(pre-mastersecret，pms)，然后根据pms生成ms。然后，可以根据ms生成不同密钥块，以进行加密、哈希处理等。在一些公开的实施方式中，sslagent151获取ms(使用任何公开的技术)并与传感器(例如，nsp105上的sslkeyserver112)共享该信息。

在一些实现方式中，sslagent151可以采用共享库(或共享对象(.so文件))的形式，该共享库在任何web服务器的服务器侧支持代码加载之前被加载。这可以通过多种方式来实现，例如，通过使用linux加载器环境变量ld_preload。ld_preload变量可以在命令行处设置，如下例所示：

ld_preload＝/home/aabraham/ssl_shim/lib/libmcafee_sslshim.so

$httpd${apache_arguments}-k$argv

该实现方式可以用于确保首先加载适当的共享库(例如，配置有sslagent151支持的共享库)。任何后续加载的共享库中也将存在的要覆盖的任何函数可以在覆盖的sslagent库中实现，并更改原始实现方式。也就是说，因为这些共享库是首先加载的，所以它们将有效地替换和否决具有相同入口点(例如，函数名或共享代码的地址)的后续加载的库。可以以这种方式捕获和替换的ssl库调用包括但不限于：

ssl_library_init():调用以对库进行初始化

ssl_ctx_new():在创建新的ssl上下文时调用。通常，每一个进程存在一个ssl上下文。

ssl_new():创建新的ssl连接时调用。ssl连接是指经由ssl握手建立的各个连接。同一基础tcp连接上可能有多个ssl连接。

ssl_read():web服务器调用该opensslapi来读取数据包。这是一个阻塞调用，并且直到完成握手才返回。完成握手之后，其返回解密数据。

ssl_write():web服务器调用该api，以将纯文本数据传递到openssl库，然后该openssl库对数据进行加密，然后通过tcp连接发送该数据。

ssl_set_msg_callback():opensslapi定义用于观察ssl/tls协议消息的函数回调。

在函数ssl_ctx_new中，sslagent151替换库可以使用预定端口(例如，端口8501)与在传感器(例如，nsp105)上运行的sslkeyserver112建立连接。传感器ip地址可以被配置在配置文件中，以供系统管理员安装，例如，与web服务器上的sslagent151一起被安装。一些web服务器实现方式运行独立的进程，并在各个进程中运行多个线程，以扩展来自多个客户端的连接处理(例如，apacheweb服务器)。另选地，一些web服务器仅运行多个线程以进行扩展(例如，nginxweb服务器)。sslagent151替换库应被配置成处理任一模型。在一个实现方式中，sslagent151通过针对web服务器的每一个线程使用新连接来进行扩展。在仅使用进程的web服务器线程模型中，每个进程可能与传感器建立一个连接。在单个进程内使用多个线程的web服务器线程模型中，每个进程可能与传感器建立许多个连接。这样做部分是为了避免共享web服务器线程/进程之间的连接，从而解决同步问题。通常，web服务器被设计用于扩展，并且所公开的实现方式不应引入sslagent库覆盖的瓶颈。由于高端web服务器上可以有大量进程和线程，因此可以在传感器(例如，nsp105)处建立对应的大量连接。结果，可以适当地优化用于任何特定nsp105的连接设置，以在可能的情况下减少连接的总数。

sslagent151可以使用ssl连接来确保客户端(例如，web浏览器)与服务器之间的通信的安全，因为可能交换关键数据(例如，信用卡或个人信息)。获取该数据或能看见该数据的任何不当人员可能能够解密流并接近数据。ssl旨在通过安全会话连接来确保机密性。在一些实现方式中，sslagent151可以使用服务器的证书(例如，有时由证书颁发机构提供并被指派为认证特定的web服务器)来认证服务器。此外，如上所述，sslagent代理库可以作为其出厂配置的一部分将用于特定nsp105的sslkeyserver112服务器的公钥打包。在这种情况下，仅需要nsp105认证服务器，使得客户端(例如，连接到nsp105或通过nsp105的web浏览器会话)确保其在共享任何机密数据或密钥信息之前连接到真正的服务器。在该示例中，不需要客户端认证，因为与传感器(nsp105)共享任何客户端侧密钥对于流氓实体没有好处。

建立与服务器的连接之后，可以使用apissl_set_msg_callback()来设置函数回调。针对发送/接收的每个协议消息，都会调用该回调。例如，clienthello、serverhello等。此外，不同实现方式尤其关注由服务器发出到特定客户端计算机的changecipherspec消息。来自服务器的该消息可以直接响应于来自特定客户端的changecipherspec消息而被发送。可以捕获该特定握手消息，使得覆盖库(例如，sslagent覆盖库)可以询问openssl库以得到上述3个变量：客户端随机数(cr)、服务器随机数(sr)和主密码(ms)。在一个实现方式中，在消息处理之后调用回调。因此，在这种情况下，当回调被调用时，changecipherspec已由服务器侧处理/生成，并且与会话有关的新信息已准备好被获取，使得可以例如经由安全辅助连接将该信息提供到传感器(诸如nsp105)。

较新的openssl库版本(版本1.1.0之后)提供了用于得到这些变量的api。为了解决早期的较低版本，可以间接引用ssl对象以得到上述信息，如下面的伪代码示例所示：

在获取以上cr、sr和ms信息之后，可以将cr、sr和ms信息发送到支持该特定会话的传感器(诸如nsp105)。例如，可以使用安全辅助连接将cr、sr和ms信息从web服务器发送到传感器。在一个示例中，可以使用标签长度值(tlv)格式或传感器可以理解的其它格式来发送信息。例如，参见图5的要素550。

nsp传感器

如上所述，可能需要使用nsm来建立sslagent151与nsp传感器(诸如nsp105)之间的连接。一些当前可用的nsm实现方式具有用于配置ibssl设置的ui框架“域>ips设备设置>ssl解密”。可以使用子框架选项“内部web服务器证书”来加载rsa公钥证书。本公开的实现方式可以被设计成继续支持基于rsa的已知密钥方法。可以更新当前的ssl解密主线框架，以提供启用/禁用基于dh的解密的选项。可以添加新的子框架(标签)，以添加安装了sslagent151并被授权与传感器(诸如nsp105)进行通信的web服务器的ip地址(例如，白名单方法)。该白名单稍后可以用于确定是否授权了sslagent151连接到特定nsp105。另外，白名单可以用于限制连接到特定nsp105的sslagent151的数量(例如，减载、安全性、性能)。在一个实现方式中，nsm将向传感器提供ip地址列表作为atomicsnmp更新。可以定义ibssl配置的新分段。该ip地址列表还可以用于打开传感器上的防火墙端口。这也有帮助，因为传感器不必认证通过ssl通道与其连接的客户端。如上所述，在一些实现方式中，未在ssl通道上使用客户端侧认证。

图2是以流程图形式例示的处理200的示例，其表示根据一些公开的实施方式的、配置网络和处理加密网络消息的一个示例。在框202处开始，web服务器可以配置有代理通信逻辑和适当的拦截器逻辑(参见图4)。例如，代理通信逻辑可以是被配置成在安全辅助通信路径上在web服务器(例如，web服务器150)与nsp105之间进行通信的应用。如上所述，该安全辅助通信路径可以是或可以不是基于网络的通信。此外，拦截器逻辑可以实现为专门配置成“封装”现有共享库(例如openssl共享库)的共享库。框204表明网络安全平台(例如，nsp105)可以配置有到受保护的web服务器(例如，web服务器150)的安全通信接口。根据一些实施方式，该安全通信接口代表安全辅助通信路径的nsp侧。框206表明在nsp处从客户端接收到消息传输并且该消息传输的目的地是web服务器。例如，握手消息或作为已建立的会话的一部分的消息。决策208确定nsp是否已经知道与当前正在处理的消息相关联的数据通信会话的加密数据消息的解密密钥。如果在nsp处已知用于会话的解密密钥(决策208的“是”分支)，则流程继续前进到框210，在框210处，可以解密消息的有效载荷以进行检查和其它适当的分析(框212)。然后，流程继续前进到决策214，在该决策214处，可以基于总体分析确定传输是否安全。另选地，如果密钥是未知的(决策208的“否”分支)，则流程继续前进到框230，在框230处，可以在不进行需要解密的分析的情况下将消息发送到web服务器。例如，这可以是握手消息。框235表明在web服务器处执行的逻辑可以拦截该会话的解密密钥，或者可以在数据被解密之后(在nsp处)拦截该数据以进行分析。拦截信息的类型可以取决于会话的状态和/或web服务器的配置实现方式。框240表明可以例如经由安全辅助连接将适当的拦截信息从web服务器传递到nsp。然后流程可以继续前进到框212，在框212处，nsp可以根据需要对拦截信息执行检查和其它分析。

接下来，处理200到达决策214，以确定传输是否是安全的从而可以提供给web服务器(即，是否已令人满意地通过了框212的分析测试)。如果是(决策214的“是”分支)，则处理200继续前进到框216，在框216处，可以向web服务器发送该传输，或者在web服务器已经接收到并且解密了信息的情况下(即，从框230)，可以发送消息是安全的从而可以前进的确认。简而言之，为web服务器提供了继续处理该消息所需的信息。然而，如果确定传输不安全(决策214的“否”分支)，则流程继续前进到框218，在框218处，可以阻塞传输(或告知web服务器丢弃消息)，并且可以呈现错误状态(框220)。该路径表示这样的情况：在nsp处执行的分析和检查已确定消息传输内可能存在威胁，并且可以在web服务器、nsp或两者处执行附加错误状态逻辑(框222)。因此，针对从客户端到达nsp的消息，处理200可以根据需要进行重复(从框206)，并且表示ibssl实现方式的一个示例。

现在参照图3，框图300表示根据一些公开的实施方式的网络安全平台(nsp)305的组件的子集和openssl310的逻辑分层表示。框图300例示了一种逻辑表示，该逻辑表示包括一个或更多个实现方式中可能涉及的各种软件模块。在该示例实现方式中，左手侧nsp305表示传感器侧组件。sbc320是管理平面应用，而nsp模块325实现传感器数据平面。sbc320和nsp模块325处理可以建模为linux进程，并且根据硬件配置，它们可以在同一物理cpu或不同的物理cpu上运行。nsp模块325可以以软件来实现或通过使用专门配置的微处理器作为nsp的硬件元件来实现。sbc320本身是不同进程的集合。在图3的右手侧示出的openssl310描绘了服务器侧(例如，web服务器)上的软件堆栈。openssl充当web服务器应用代码与通过套接字338接口暴露的内核340tcp/ip堆栈之间的粘合层。北边界侧上的openssl310将解密数据呈现给web服务器330，并且在南边界侧上将加密数据传递给内核340ip堆栈。web服务器上的sslagent151客户端可以连接到特定网络设备上的sslkeyserver112，并共享会话密钥(例如，共享获取的更改后的密钥信息)。在一个示例实现方式中，与sslkeyserver112相关联的服务器侧函数可以作为独立的linux进程(例如，sbc进程组的一部分)运行。传感器可以监听来自带外管理端口的连接或其它安全辅助连接(例如，vpn)。在一些实现方式中，因为仅共享密钥，所以大多数平台的管理链路带宽应该是足够的。在共享解密数据而不是密钥的示例中，应使用足以满足预期流量(例如，具有足够带宽)的链路来实现安全辅助连接的吞吐量。

与sslkeyserver112相关联的服务器进程可以将所需的密钥信息写入可由数据平面nsp模块325访问的共享存储器。各个nsp模块325可以处理一个或更多个ssl连接，并使用适当的密钥来解密必要的流。这可能与ibssl模型的其它实现方式有所不同，在这些实现方式中，密钥可能是从流中获得的，部分原因是，密钥可能已经在服务器处可用并且经由辅助安全连接与任何客户端(例如，诸如nsp105的网络设备)共享。参见图1。

在一个示例实现方式中，sslagent151将针对每个连接生成最多128字节数据的记录。示例高性能nsp每秒最多支持3000个ssl连接。因此，该示例nsp上的、所有可能的连接处于活动状态的实现方式将经历分布在多个连接上的大约128×3000＝3mbps(128字节×8位×3000)的数据。因为大多数高性能nsp还包括能够显著提高吞吐量(例如，10g链路)的管理接口，所以该接口应该是足够的。另外，公开的示例实现方式不应给处理该3mbps数据速率的linuxtcp堆栈过大压力。即使每秒建立的ssl连接的数量大于该示例实现方式，管理链路上也应该有足够的附加容量，因为3mbps加上其它预期流量未达到10g链路容量。为了进一步解决性能，可以使用多线程方法来实现sslkeyserver112，以处理任何数量的连接和数据，并且能够根据需要进行扩展(例如，通过启动附加线程)。

共享存储器315也可以用于托管主密码表。在一个实现方式中，表中的各个条目都需要128字节(32×2字节的随机数、48字节的主密码和填充)。参见图5的要素550，其中包含客户端随机数555、服务器随机数556和主密码557。该开销量表明可以使用每个ssl连接支持的、共享存储器315的总最大值(再次基于当前示例的参数)约16mb的总共0.1m的存储器。另外，存储器还可以用于托管ipv4和ipv6客户端两者的sslagent151连接表。因此，应该将nsp的存储器配置成具有足够的容量来处理附加(最小)开销，并且大多数当前可用的nsp都是足够的。

密钥和解密数据的拦截(非详尽示例)

图4例示了根据一个或更多个公开的实施方式的框图400和框图450，框图400和框图450表示计算机处理设备和被配置成拦截加密信息(例如，密钥或解密数据)的计算机处理设备的逻辑层。图4示出了例示硬件和软件堆栈的示例的两个框图(400和450)，它们均按分层模型的形式，用于说明实现拦截或替换函数挂接的一些方法。替换函数可能有助于更改特定库的功能，例如，以拦截信息，而无需更改已配置系统的其它部分。

框图400包括描绘计算机实现的解决方案的不同功能组件之间的交互点的层。在分层模型的顶部描绘了应用层405，以表明其在功能上“最接近”用户。在典型的操作中，用户与应用(如操作系统所支持的)进行交互，以引入用于执行的命令(例如，命令行输入或图形用户界面选择)，其中执行在应用层405处开始。应用进而向操作系统层410发送命令和信息并从操作系统层410接收命令和信息。如图所示，操作系统层410位于应用层405与设备驱动器层415之间。

设备驱动器层415在操作系统层405与由硬件层420表示的硬件组件之间提供接口。硬件组件可以包括输入设备(诸如用于接收用户输入的键盘和鼠标)、输出设备(诸如传统的监视器和扬声器)以及输入/输出设备(诸如触摸屏监视器、网络接口(经由网络425进行通信)、磁盘控制器卡、存储器设备等)。

框图400中示出的分层模型表示软件/硬件堆栈的传统逻辑表示，并且对于所有实现方式可能不是完全确切的。例如，取决于如何实现操作系统，设备驱动器的一些部分可能更确切地存在于操作系统层410内。在任何情况下，框图400表示处理设备的不同组件如何被配置成支持应用执行的概念模型。

如框图400中进一步例示的，网络425(其可以包括网络130或网络135中的任一者)可以用于将处理设备彼此在通信上联接。在该示例中，api调用和密钥拦截逻辑可以在模型的不同层处实现。例如，可以对硬件进行修改，以提供指向拦截基础设施的附加事件以及传统提供的事件。类似地，可以将设备驱动器或操作系统修改成包括旨在支持api监视和分析的公开实施方式的附加功能。

最终，各个应用可以适配成包括附加逻辑以支持api监视和分析的公开实施方式。尽管所有这些实现方式都是可能的，但它们表示在开发时间和可能的处理设备性能两方面的不同程度的“成本”。因此，可能期望不同层处的更改的某一组合。此外，下面讨论的框图450例示了可能不需要改变其它层的监视能力的示例实现方式。实施方式可以包括公开的可能实现方式的组合。

继续图4，框图450例示了上述分层模型的变型。具体地，框图450包括在应用层405与操作系统层410之间实现的拦截器层455。如图所示，拦截器层455的引入可以表示在模型的其它层处需要最小变化(如果有的话)的实施方式。甚至有可能在应用层405或操作系统层410不必改变其与模型相邻层的操作的方法的情况下实现拦截层455。拦截层455可以被配置成识别应用层405与操作系统层410之间的任何相关交互(例如，握手以初始化或更改会话上的加密密钥)(在该示例中，认为openssl310和web服务器330在应用层405处执行)。所有其它交互将不受影响地“穿过”拦截层455。对于任何相关交互，拦截层455可以发起经由网络130或从sslagent151(在拦截层455中实现)到nsp105的安全辅助通信路径的拦截信息的传输。一旦在nsp105处接收到，就可以如本文所述使用密钥信息。

图5例示了根据一个或更多个公开的实施方式的、回调的流程图500表示，该回调可以用于为利用临时密钥的加密技术拦截和传送加密密钥信息。在框505处开始，从模块或子系统接收到回调，该模块或子系统例如可以是拦截层455的一部分。例如，每次调用openssl的一部分时，都可以自动调用该回调。一旦被调用，决策510表明在回调中发起的代码可以确定是否已经调用changeciperspec函数来更改加密信息。如果是(决策510的“是”分支)，则流程继续前进到框520，在框520处，可以获取传感器(例如，nsp105)上的、所公开的一个或更多个实施方式的特定实现方式所需的相关信息，并例如使用从web服务器150到nsp105的安全辅助通信路径将该相关信息传递给传感器。如果不是changeciperspec情况(决策510的“否”分支)，则流程可以简单地继续前进到框515并被忽略，因为其不被视为是相关的。

图5还包括可变长度消息550的示例，该可变长度消息550包含客户端随机数555、服务器随机数556和主密码557。如上所述，每次协商加密信息或稍后更改加密信息时，可以在传感器与web服务器之间共享诸如可变长度消息555的可变长度消息。在一些实现方式中，可变长度消息可以被填充，使得其具有一致的大小(例如，128字节)。例如，可以使用安全辅助通信路径在设备之间共享该可变长度消息。

图6例示了根据一个或更多个公开的实施方式的，客户端、传感器(例如，nsp)与web服务器之间的消息和信息流的时间线600。这只是可能发生的一个示例时间线序列。在现实实现方式中，可以预期该时间线上的变化并且这些变化仍然符合本公开的概念。此外，nsp(例如，传感器)和sslkeyserver(例如，web服务器)的单个实现方式可以基于由不同客户端设备(例如，执行web浏览器或web服务客户端应用的处理器)发起的活动来支持该时间线的许多不同变型。时间线700例示了在顶部的时间t0处开始的时间，其中随着向下浏览页面，事件按时间顺序进行。从左到右以及从右到左示出了信息交换。时间线700例示了如上文已经讨论的经由传感器(nsp)在客户端与服务器之间的示例交换，并且在此处被提供以进一步例示(例如，以图形方式)上述讨论。在该示例中，在时间t0处开始，客户端利用clienthello605发起连接请求。传感器复制客户端随机数610以供以后使用，并将clienthello615发送到服务器。服务器经由所述传感器(部分因为是该传感器向服务器发送的消息)以serverhello620来响应客户端。在经过传感器时，复制625来自serverhello630的服务器随机数，以供将来使用。接下来，将服务器证书635和serverhellodone发送到客户端(现在在t1)。取决于实现方式，这些消息可以直接发送，也可以简单地经过传感器。接下来，客户端可以向服务器发送客户端密钥交换(例如，加密的专用主密码(privatemastersecret，pms))。这可能会在建立会话的初始握手时或在更改密钥的任何时间发生。如本示例所示，从客户端向服务器发送三个消息(客户端密钥交换、changecipherspec640和已完成)。服务器在时间t2利用changeciperspec响应645来确收所述三个消息。接下来，服务器经由进行复制655的传感器向客户端发送650共享密钥(包括当前客户端随机数(cr)和服务器随机数(sr))。该动作可以表示sslagent151库具有拦截信息(如上所述)并将该拦截信息提供给传感器。因为该信息是之前刚发送给客户端的，所以传感器需要该可能且极有可能已更改的信息来保持能够解密该会话的通信。一旦如从服务器到客户端的已完成通信所示完成了changecipherspec交换，时间就前进到t3，在t3处，加密数据660可以在会话上从客户端流动到web服务器。当在传感器处接收到潜在加密数据的各个消息时，可以在将(原始)加密数据680传递到web服务器之前执行密钥查找665、解密670和检查675。

通常，cipher/cipher套件支持可以大致分为两种类型的支持功能：密钥交换/密钥算法支持和对称密码支持。在一些公开的实施方式中，诸如nsp105的传感器在密钥交换或密钥生成中起透明作用。也就是说，nsp105依赖于终端服务器主机来共享密钥，因此对算法的支持取决于终端服务器所支持的内容。然而，可以以可支持多种算法的方式设计该方法，这些算法包括但不限于：

·rsa

·dh(e)

·ecdh(e)

在传感器(诸如nsp105)被配置成在使用在握手期间达成共识的对称密码来解密应用记录中发挥积极作用的方法中，至少以下对称密码可以被配置成发挥作用：

·null

·arc4

·des/cbc

·3des/cbc

·aes(cbc/gcm)

现在参照图7，框图例示了根据一个或更多个实施方式的可以在诸如设备nsp105或web服务器150的网络设备内使用的可编程设备700。设备可能不包括图7的所有要素。图7所例示的可编程设备700是包括第一处理元件770和第二处理元件780的多处理器可编程设备。虽然示出了两个处理元件770和780，但是可编程设备700的实施方式还可以仅包括一个这样的处理元件。可编程设备700被例示为点对点互连系统，其中第一处理元件770和第二处理元件780经由点对点互连750联接。可以将图7所例示的任何或所有互连实现为多点分支总线而不是点对点互连。

如图7所示，处理元件770和780均可以是多核处理器，包括第一处理器核和第二处理器核(即，处理器核774a和774b以及处理器核784a和784b)。这样的核774a、774b、784a、784b可以被配置成按与上文结合图1至图6所讨论的方式类似的方式来执行指令代码。然而，其它实施方式可以根据需要使用作为单核处理器的处理元件。在具有多个处理元件770、780的实施方式中，各个处理元件可以根据需要用不同数量的核来实现。

各个处理元件770、780可以分别包括至少一个共享缓存746a或746b。共享缓存746a、746b可以存储由对应处理元件的一个或更多个组件(诸如分别为核774a、774b和784a、784b)利用的数据(例如，指令)。例如，共享缓存可以在本地对存储在存储器732、734中的数据进行缓存，以供处理元件770、780的组件更快地访问。在一个或更多个实施方式中，共享缓存746a、746b可以包括一个或更多个中间级别的缓存(诸如2级(l2)、3级(l3)、4级(l4)或其它级别的缓存)、最后一级缓存(llc)或其组合。

虽然图7为了附图清楚而例示了具有两个处理元件770、780的可编程设备，但本发明的范围不限于此，并且可以存在任何数量的处理元件。另选地，处理元件770、780中的一个或更多个可以是除处理器之外的元件，诸如图形处理单元(gpu)、数字信号处理(dsp)单元、现场可编程门阵列或任何其它可编程处理元件。处理元件780可以与处理元件770异构或不对称。就包括架构、微架构、热、功耗特性等的一系列度量指标而言，处理元件770、780之间可以存在多种差异。这些差异可以有效地将其自身表现为处理元件770、780间的不对称性和异构性。在一些实施方式中，各种处理元件770、780可以存在于同一管芯封装中。

第一处理元件770还可以包括存储器控制器逻辑(mc)772以及点对点(p-p)互连776和778。类似地，第二处理元件780可以包括mc782以及p-p互连786和788。如图7所示，mc772和mc782将处理元件770和780联接至相应存储器(即存储器732和存储器734)，这些存储器可以是在本地附接至相应处理器的主存储器的一部分。尽管mc逻辑772和782被例示为集成在处理元件770和780中，但是在一些实施方式中，存储器控制器逻辑可以是处理元件770、780外部的分立逻辑，而不是集成在其中。

处理元件770和处理元件780可以经由相应p-p互连776和786通过链路752和754联接至i/o子系统790。如图7所示，i/o子系统790包括p-p互连794和798。此外，i/o子系统790包括接口792，以将i/o子系统790联接至高性能图形引擎738。在一个实施方式中，总线(未示出)可以用于将图形引擎738联接至i/o子系统790。另选地，点对点互连739可以联接这些组件。

进而，i/o子系统790可以经由接口796联接至第一链路716。在一个实施方式中，第一链路716可以是外围组件互连(pci)总线，或者诸如pciexpress总线的总线或另一i/o互连总线，但是本发明的范围不限于此。

如图7所示，各种i/o设备714、724可以与桥接器718一起联接至第一链路716，该桥接器718可以将第一链路716联接至第二链路720。在一个实施方式中，第二链路720可以是低引脚数(lpc)总线。各种设备可以联接至第二链路720，在一个实施方式中，所述各种设备例如包括键盘/鼠标712、通信设备726(其可以进而与计算机网络703进行通信)以及可包括代码730的数据存储单元728(诸如磁盘驱动器或其它大容量存储设备)。代码730可以包括用于执行上述技术中的一种或更多种技术的实施方式的指令。此外，音频i/o724可以联接至第二总线720。

注意，可以设想其它实施方式。例如，代替图7的点对点架构，系统可以实现多点分支总线或另一种这样的通信拓扑。尽管链路716和链路720在图7中被例示为总线，但是可以使用任何期望类型的链路。此外，图7的元件可以另选地使用比图7所示的更多或更少的集成芯片来划分。

现在参照图8，框图例示了根据另一实施方式的可编程设备800。图8省略了图7的某些方面，以避免混淆图8的其它方面。

图8例示了处理元件870和880可以分别包括集成存储器和i/o控制逻辑(“cl”)872和882。在一些实施方式中，872、882可以包括诸如上文结合图7所描述的存储器控制逻辑(mc)。另外，cl872、882还可以包括i/o控制逻辑。图8例示了不仅存储器832、834可以联接至872、882，而且i/o设备844也可以联接至控制逻辑872、882。传统i/o设备815可以通过接口896联接至i/o子系统890。各个处理元件870、880可以包括在图8中例示为处理器核874a、874b、884a和884b的多个处理器核。如图8所示，i/o子系统890包括p-p互连894和898，p-p互连894和898利用链路852和854连接至处理元件870和880的p-p互连876和886。处理元件870和880也可以分别通过链路850以及互连878和888互连。

图7和图8中描绘的可编程设备是可以用于实现本文讨论的各种实施方式的可编程设备的实施方式的示意性例示。图7和图8中描绘的可编程设备的各种组件可以组合在片上系统(soc)架构中。

将理解，上述流程图的各个组成部分可以以不同的顺序或者甚至同时发生。还应理解，本发明的各种实施方式可以包括上述全部或只是一些组成部分。因此，提供流程图是为了更好地理解实施方式，但是流程图的组成部分的特定顺序并不旨在是限制性的，除非另外这样说明。

程序指令可以用于引起利用该指令编程的通用或专用处理系统执行本文描述的操作。另选地，可以由包含用于执行操作的硬连线逻辑的特定硬件组件来执行操作，或者由编程计算机组件和定制硬件组件的任何组合来执行操作。本文中描述的方法可以被提供为计算机程序产品，该计算机程序产品可以包括存储有指令的机器可读介质，这些指令可以用于对处理系统或其它电子设备进行编程以执行所述方法。本文所使用的术语“机器可读介质”应包括能够存储或编码由机器执行的指令序列并且使机器执行本文所述方法中的任何一种方法的任何介质。因此，术语“机器可读介质”应包括但不限于有形的非暂时性存储器(诸如固态存储器、光盘和磁盘)。此外，在本领域中通常将软件(一种形式)或另一形式(例如，程序、过程、处理、应用、模块、逻辑等)称为采取动作或造成结果。这样的表达仅仅是表示处理系统执行软件造成处理器执行动作或产生结果的简略方式。

示例

以下示例属于另外的实施方式。

一个示例是一种在位于客户端设备与服务器设备之间的网络通信路径中的传感器设备上分析加密网络流量的方法，该方法包括以下步骤：在传感器设备处检测从客户端设备发送到服务器设备的客户端发起的hello消息；从客户端hello消息复制第一信息，以部分地跟踪会话发起握手，其中，客户端hello消息是握手的第一消息；向服务器设备发送客户端hello消息；在传感器设备处，检测从服务器设备发送到客户端设备的服务器hello消息中的对客户端hello的响应；从服务器hello消息复制第二信息，以部分地跟踪会话发起握手；在传感器设备处，检测会话的加密密钥信息的协商；存储来自协商的第三信息；在传感器设备处，检测作为会话的一部分的从客户端设备发送到服务器设备的加密数据消息信息；以及使用第一信息、第二信息和第三信息来分析加密数据消息信息。

示例1可以扩展为包括表示针对会话协商的加密密钥的第三信息，该会话可以表示传输控制协议(tcp)会话上的传输层安全(tls)通信。示例1可以另选地包括：其中，第一信息和第二信息表示用于针对在传感器设备上同时活动的多个会话唯一地识别在传感器设备的存储器中存储的至少一个加密密钥数据的信息。示例1还可以包括：监视会话，以识别加密密钥的变化并更新在传感器设备的存储器中存储的至少一个加密密钥数据。在一些情况下，监视会话包括在传感器设备处检测客户端设备与服务器设备之间的changecipherspec通信。除了经由会话发送的数据之外，示例1还可以包括经由安全辅助通信路径从服务器设备发送到传感器设备的第四信息，并且第四信息可以包括来自已经在服务器设备处解密的会话的数据。另外，第四信息可以包括与先前在服务器设备处协商的会话有关的加密密钥信息。在一些情况下，安全辅助通信路径使用服务器设备与传感器设备之间的非网络通信路径。安全辅助通信路径可以使用服务器设备与传感器设备之间的独立且安全的附加网络通信路径。可以这样实现示例1，其中，独立且安全的附加网络通信路径包括虚拟专用网络或单独的物理网络。可以部分地使用包括存储在其上的指令的非暂时性计算机可读介质来实现示例1，这些指令在由一个或更多个处理器执行时使所述一个或更多个处理器执行或帮助执行上述示例之一。此外，诸如nsp105的装置可以被配置成整体或部分地执行上述示例中的任何示例。

将理解，以上描述旨在是例示性的，而不是限制性的。例如，上述实施方式可以彼此组合使用。在阅读以上描述之后，对于本领域技术人员而言显然可以有许多其它实施方式。因此，应参照所附的权利要求以及这些权利要求所赋予的等同物的全部范围来确定本发明的范围。