针对跨网络周边防火墙的设备使能零接触引导的制作方法

相关申请交叉引用

本申请要求于2017年11月10日提交的美国临时申请no.62/584,168的权益，其通过引用整体并入本文。

本公开涉及网络安全。

背景技术：

在安全网络上以安全的方式配设和引导(bootstrap)设备可能是困难、耗时、昂贵和/或复杂的过程。存在许多不同类型的设备，例如协作端点(例如，视频端点和因特网协议(ip)电话)，以及依赖于云服务来简化引导和持续管理的更通用的物联网(iot)设备。当这些设备引导时，它们不信任本地网络；替代地，它们尝试通过传输安全协议(例如，传输层安全(tls)协议)直接与公知的云服务建立安全连接。

不幸的是，安全网络可能部署了tls拦截代理防火墙。当设备尝试联系本地域以外的可信云服务时，这些代理防火墙将自己插入作为所谓的中间人(mitm)。由于设备可能不信任tls拦截代理，因此设备可能被阻止建立到云服务的安全连接，因此无法成功引导。

此外，拦截代理不仅可能被广泛地部署，而且可能不频繁地更新。它们的存在、以及在它们存在的情况下建立安全连接的能力对于一大类设备来说是持续的问题。

附图说明

图1描绘了根据示例实施例的应用层传输层安全(atls)的网络部署。

图2是描绘根据示例实施例的由本文所提出的解决方案利用的传输层安全(tls)软件堆栈接口的图。

图3示出了根据示例实施例应用(客户端或服务器)如何能够与atls会话直接交互以提取原始tls记录。

图4是示出根据示例实施例的由本文所提出的技术利用的atls流的示例的图。

图5是描绘根据示例实施例的由本文所提出的技术采用的atls用例的示例的图。

图6描绘了根据示例实施例的可以由网络设备结合给定本地域中的引导执行的一系列操作。

图7示出了根据示例实施例的被配置为参与本文所提出的技术的客户端设备的框图。

图8是根据示例实施例的被配置为参与本文所提出的技术的其他实体(诸如云服务器)的框图。

具体实施方式

概述

本文提出的技术使设备能够即使在存在拦截代理的情况下也建立到因特网上的云服务的安全连接，并能够利用该云服务来执行针对本地域的零接触安全引导。该技术导致一旦设备通电就“零接触”引导，即使设备被部署在拦截到因特网的所有流量的安全网络上也是如此。

在独立权利要求中陈述了本发明的方面，在从属权利要求中陈述了优选特征。一方面的特征可以单独地或与其他方面结合地应用于每个方面。

根据一个实施例，提供了一种方法，该方法包括以下操作：通过从网络设备向云服务器发送传输协议消息体(例如，http消息体)中的tls记录，在网络设备和云服务器之间建立应用层传输层安全(atls)连接，该atls连接经过至少一个传输层安全(tls)代理设备；经由atls连接从云服务器接收认证机构的标识符；建立跟与标识符相关联的认证机构的连接并进而从认证机构接收用于访问不同于云服务器和认证机构的应用服务的证书；以及使用从认证机构接收到的证书连接到应用服务。

还提供了一种设备，该设备包括被配置为使能网络通信的接口单元、存储器、以及耦合至接口单元和存储器的一个或多个处理器，该设备被配置为：通过从设备向云服务器发送传输协议消息体(例如，http消息体)中的tls记录，在设备和云服务器之间建立应用层传输层安全(atls)连接，该atls连接经过至少一个传输层安全(tls)代理设备；经由atls连接从云服务器接收认证机构的标识符；建立跟与标识符相关联的认证机构的连接，并且进而从认证机构接收用于访问不同于云服务器和认证机构的应用服务的证书；以及通过使用从认证机构接收到的证书连接到应用服务，完成该设备的引导过程。

示例实施例

本文所描述的实施例引入了应用层tls(atls)，该应用层tls(atls)允许跨tls拦截“中间盒(middlebox)”在客户端和服务之间建立tls连接。在一种实现方式中，这是通过在客户端和服务(例如，托管在云服务器上的服务)之间传输超文本传输协议(http)消息体中的tls记录来实现的。这使客户端和服务能够在应用层使用tls建立安全连接，并将在网络层拦截流量的任何中间盒都视为不可信传输。对于本领域的普通技术人员来说将变得显而易见的是，本文描述的机制将tls握手从osi堆栈向上移动到应用层。

更具体地说，atls利用tls软件堆栈应用编程接口(api)，其使应用能够拔出(unplug)网络堆栈并从存储器中的字节缓冲器中读取tls数据/将tls数据写入存储器中的字节缓冲器。在这方面，客户端和服务器两者均可利用atls，使得在消息体(例如http消息体)中传输tls记录。客户端和服务之间的连接也可以升级到web套接字。这允许在应用层处通过不可信https传输进行客户端-服务器tls连接。

现在参考图1，其描绘了根据示例实施例的atls的网络部署。如图所示，客户端110经由不可信中间人(mitm)(或中间盒)网关120和tls终止器(terminator)130与服务(例如服务器)150通信。更具体地，客户端110建立与中间盒(客户端->网关tls)的传输层tls连接182，该连接182包括堆栈，该堆栈包含udp160、客户端->网关tls162、传输164(在此示例中，是受限应用协议(coap))、客户端->服务tls166和应用数据168。中间盒网关120进而打开与部署在服务的前面(m->ttls)的tls终止器130的传输层tls连接184。连接184包括堆栈，该堆栈包含tcp161、m->ttls163、http传输164、客户端->服务tls166和应用数据168。tls终止器130进而打开经由堆栈186的到服务150的连接，该堆栈186包括tcp161、http传输164、客户端->服务tls166和应用数据168。客户端110可以忽略连接到中间盒网关120时由162生成的任何证书验证错误。由166生成的证书验证错误将指示实际的攻击情形。例如，http消息在客户端和服务之间通过该层进行传输。因此，应用层tls消息在传输消息体(例如，http消息体)内部经由连接180来交换，以便在客户端和服务之间建立端对端tls会话(客户端->服务tls)。

注意，本文提出的技术可以通过中间人(mitm)设备或“中间盒”可能拦截的任何不可信传输来与任何密码交换协议结合地部署。应用密码交换的示例包括(但不限于)：传输层安全(tls)、噪声协议、javascript对象表示法(json)web令牌(jwt)等。传输协议的示例包括：超文本传输协议安全(https)+tls、http+传输控制协议(tcp)、http2、快速udp因特网连接(quic)协议+tls、数据报传输层安全(dtls)、tls、和iot传输(例如coap和zigbee)等。尽管经过中间盒到因特网的最常见的流量种类通常是http或https流量，但是某些浏览器(例如googlechrome)在可能的情况下使用quic。

图2示出了tls软件堆栈接口。如图2所示，tls堆栈210公开了应用编程接口(api)，其允许应用从字节缓冲器220注入/提取tls握手记录215。tls堆栈210还允许应用以将应用数据217、218加密/解密到字节缓冲器/从字节缓冲器加密/解密应用数据217、218。然后可以通过任何合适的传输在客户端110和服务器150之间交换字节。此外，可经由堆栈210获取密钥材料219。因此，换句话说，tls软件堆栈210可用于“拔出”默认网络套接字传输层并直接从字节缓冲器220读取和写入tls记录215和其他数据217、218、219。这使得创建应用层tls会话、从tls堆栈的底部提取原始tls记录字节、以及通过任何合适的传输方式传输这些字节成为可能。tls软件堆栈可以生成完整的tls飞行(flight)的字节流，其可以包含多个tls记录。

在实施例中，图2的tls软件堆栈api使能图3所描绘的架构，该架构示出了应用310(客户端或服务器)如何能够与应用atls会话320直接交互以提取原始tls记录330。也就是说，应用310创建应用层tls会话320并与应用层tls会话320交互以生成和消费原始tls记录330和应用数据315。应用310使用(标准http)堆栈350在消息体(例如，http消息体)内部传输原始tls记录330。堆栈350可以进而使用独立的通信信道和具有相同或不同tls堆栈340(或tcp传输)的传输加密360来与其对等体传送分组370。值得注意的是，应用层tls会话320和网络层传输加密360两者都可以利用共享的、通用的tls软件堆栈340。这种高级架构适用于客户端和服务(对等体)两者。

图4示出了使用http的atls流的示例。如图所示，设备410(例如，客户端设备)经由mitm设备420建立网络tls连接411、421。在412处，与第一飞行结合，设备410向服务450发送httppost，服务450在413处以“200ok”对其进行回复，表示服务(服务器)450能够成功解析请求并使用其tls软件堆栈处理tls记录。与第二飞行结合，在414处，设备410向服务450发送httppost，服务450在415处以“200ok”对其进行回复。在此过程的这点处，atls已完全建立。此后，在416处，设备410可以在416处发送httppost，该httppost包括加密应用数据，服务450在417处用“200ok”以及服务(服务器)应用数据对该加密应用数据进行回复。请注意，状态码200ok不一定表示正在协商的tls连接无错误。也就是说，由tls产生的警报将在编码的tls记录中返回。200ok响应仅表示客户端应将响应中编码的记录提供给其tls堆栈。

图5示出了根据示例实施例的atls用例的示例。如所指出的，atls使客户端设备510和服务器(云服务550)能够通过不可信传输建立安全的相互认证的信道。例如，不可信的mitmtls拦截代理(例如网关或mitm2)520可以位于客户端设备510与服务器/服务550之间，并且tls终止器(例如mitm1)530也可以位于客户端设备510与服务器/服务550之间。如所指出的，如上所述，atls使得位于各种类型的中间盒后面的服务器仍然能够被访问，并且根据本文所述的实施例，对连接的客户端执行基于pki证书的认证。

仍参考图5，引导远程安全密钥基础结构(brski)是允许在本地域上引导的设备进行以下操作的协议：查询因特网上的默认制造商服务(被称为注册器540)并询问该注册器540该设备应信任什么域以及什么域认证机构(ca)。注意，可以使用注册机构(ra)来代替ca。应当理解，出于相互认证的目的，brski依赖于设备510和注册器540之间的网络层tls连接的建立：客户端设备510使用tlspki机制来验证注册器540身份，反之亦然。传统地，brski要求注册器直接在本地网络上可用，或者要求将任何tls代理(中间盒)配置为忽略通信流。在操作上，这在一系列部署中可能很困难。例如，通常情况是无法修改tls代理，或者网络管理员对“低管理”解决方案感兴趣，该解决方案要求对其网络进行最少的专业配置。协作解决方案(例如，支持视频的终端单元)尤其会受到这种缺陷的影响。

本文所描述的实施例解决了前述问题，并且结合atls和brski以使能基于云的引导(尽管存在tls代理(例如，mitm1530和/或mitm2520))。也就是说，设备510可以利用云注册器服务540来针对ca和应用服务进行零接触引导。ca可以在云中(例如，云ca560)或在本地域中(本地ca570)。

在实施例中，需要引导的设备510具有初始安全设备标识符(idevid)，其也被称为制造商安装的证书(mic)。设备510被配置为使用其idevid针对ca进行自动登记(enroll)以获得本地有效设备标识符(ldevid)，其也被称为本地有效证书(lsc)。但是，由于mitm或中间盒520、530可以位于设备510与云注册器540、认证机构(ca)560和应用服务550之间，因此设备与所有云服务之间的网络层tls连接可能会断开，从而阻止设备成功引导。

为了克服这种潜在的断开连接问题，设备510使用atls来建立跨mitm的与云服务的tls连接。设备还可以在atls会话上使用其idevid或ldevid来跨mitm向服务验证其身份。一旦设备具有了ldevid(或多个ldevid)，它就可以使用ldevid或idevid，这取决于服务要求的内容。换句话说，客户端可以使用网络要求的任何证明。例如，设备510可以使用其ldevid来自动连接到本地域服务580或云应用服务550。值得注意的是，所有上述情况都可以发生，而无需设备的安装者必须在设备上输入或配置任何信息-安装者只需给设备通电。此外，没有什么会阻止设备使用其idevid来在需要时针对多个不同的ca进行登记并获取多个ldevid。

设备510经由连接501利用云注册器服务540来促进针对一个或多个ca560、570的零接触登记以及针对应用服务550、580的零接触注册。注册器服务540基于设备的idevid来确定设备本地域。如图所示，在设备510与所有云服务540、550、560之间可以存在tls拦截代理/中间人(mitm1)530，但是atls机制克服了连接断开的可能性。如图所示，本地ca570驻留在第一网络(网络1)512中，并且本地服务580驻留在第二网络(网络2)514中。

如果在设备510与所有本地服务570、580之间存在mitm(mitm2)520，则所示出的架构也可以工作，不过这种部署配置可能不那么常见。ca(560或570)可以在云中(经由连接502b)或在本地域中(经由连接502a)，其中设备510用其idevid从该ca获得其ldevid。如所指出的，如果需要，设备510可以从多个ca登记并获得多个ldevid。

在交换适当的证书时，设备510可以经由连接503a连接至云应用服务550和/或经由连接503b连接至本地域应用服务580。

取决于网络配置或拓扑，设备510可以在连接过程中以不同的方式连接到本地域网络或通过本地域网络。

网络1512例如可以允许设备510连接到因特网上的注册器540，并且可以允许设备510连接到ca(无论该ca是被部署在因特网上(云ca560)还是被部署在本地域上(本地ca570)。这样的连接发生在设备510已经登记以获得ldevid之前。网络可以授予对附加服务的访问权限，但这不是必需的。此外，在授予网络访问权限之前，网络可以要求设备具有可信的idevid。

作为另一示例，网络2514可以允许设备510分别连接到本地域和因特网上的所有需要的应用服务580、550。在被授予网络访问权限之前，设备510通常将必须呈现由可信ca发布的ldevid。

连接可以利用相互的tls连接，其中客户端和服务使用pki证书来验证相互身份并且其中该连接通过利用atls来经过mitm。也就是说，在设备510与云服务之间存在mitm的情况下，这意味着例如连接501、502b和503a是atls连接。在设备510与所有本地域服务之间存在mitm的情况下，这意味着例如连接502a和503b是atls连接。

仍然参考图5，与云ca以及本地域和云应用服务两者相关联的高级流程如下。

1.设备510在经过mitm1530的同时与云注册器540建立atls连接501。如所解释的，设备510可以通过在http交换上分层(layering)应用层tls握手来与云中的注册器540建立atls连接，该握手进而可以通过tcp或tls网络层连接来传输，即，该连接可以是基于tcp的http上的atls(atlsoverhttpovertcp)或基于tls的http(s)上的atls。当建立到云注册器540的atls连接时，设备510使用其制造商安装的证书(idevid)。

2.网络1512允许设备510连接到注册器540(以及下一步中的ca560)。网络1512可以检查设备510具有由可信制造商发布的可信idevid。

3.注册器540使用设备的idevid以经由一些合适的命令履行、供应链、或类似的后端服务集成来查找设备主域(homedomain)。设备510和云注册器540使用在atls连接中呈现的pki证书来相互认证彼此的身份。云注册器540使用客户端pki证书(例如，idevid)来查找拥有客户端的域(使用销售渠道整合(saleschannelintegration)或某种合适的机制)。该查找机制在本公开的范围之外，并且在此不进一步讨论。

4.注册器540返回供设备510使用的ca的标识(即，在该示例中为云ca560)以及针对该ca的信任锚信息。设备也可以针对多个ca进行登记以获得多个身份证明。信任锚信息可以包括针对ca的信任锚信息和针对本地网络域的信任锚信息。这允许设备信任ca，并信任本地网络域(包括任何mitm)。云注册器540将包括本地ca信息和任何其他必要细节的域信息返回给设备510。设备510信任它从云注册器540接收到的信息。

5.设备510在经过mitm1530的同时与云ca560建立atls连接502b，并使用其idevid以获得ldevid。此时，由于设备510现在具有用于访问服务的信息/证书，因此可以认为设备510已完成其引导。

6.云ca560可以基于所呈现的idevid以及用于签名idevid的制造商ca来做出关于是否发布ldevid的策略决策。

7.设备510在经过mitm1530的同时与云应用服务550建立atls连接503a，并使用其ldevid以获得访问权限、或服务要求的任何证明。

8.云应用服务550可以基于所呈现的ldevid以及用于签名ldevid的ca来做出关于是否授予访问权限的策略决策。

9.设备510在经过mitm2520的同时与本地域应用服务580建立atls连接503b，并使用其ldevid以获得访问权限。

10.本地域应用服务580可以基于所呈现的ldevid以及用于签名ldevid的ca来做出关于是否授予访问权限的策略决策。

11.网络2514通过检查设备510具有由可信ca发布的可信ldevid来允许设备510连接到应用服务。

在设备针对本地域成功引导并且可以成功连接到本地域和云应用服务两者之后，可能存在多种潜在的行为。例如，一旦设备510使用合适的idevid或ldevid证书成功连接到应用服务550、580，则服务550、580可以向设备510发布令牌或者与设备510建立会话，使得所有后续的访问是通过会话或令牌授权的，而不是通过使用证书授权的。此外，一旦设备510信任mitm520、530，设备510就可以退回到使用标准的tls而不是atls。此外，后续的流可以使用来自本地网络的ldevid证书链，以在与服务150的后续(非引导)通信期间完全认证客户端->网关120tls会话120(图1)。这提供了182和150之间的唯一的多安全(multi-secured)流，其既被认证到本地mitmtls代理，又被认证到服务150或tls终止器130。

图6描绘了可以由设备510结合给定本地域中的引导执行的一系列操作。在610处，网络设备通过从网络设备向云服务器发送传输协议消息体(例如，http消息体)中的tls记录来在网络设备与云服务器之间建立应用层传输层安全(atls)连接，该atls连接经过至少一个传输层安全(tls)代理设备。在612处，网络设备经由atls连接从云服务器接收认证机构的标识符。在614处，网络设备建立与跟该标识符相关联的认证机构的连接，并且进而从认证机构接收用于访问不同于云服务器和认证机构的应用服务的证书。此时，可以认为网络设备已完成引导。在616处，网络设备使用从认证机构接收到的证书连接到应用服务。

如本领域技术人员将理解的，尽管存在tls代理，但是本文呈现的实施例利用机制来使能基于云的引导。具体地，客户端(设备)通过在http交换上分层应用层tls握手来与云中的注册器建立atls连接，其中该握手进而可以通过tcp或tls网络层连接来传输，即，该连接可以是基于tcp的http上的atls或基于tls的https上的atls。

客户端在建立到云注册器的atls连接时使用其制造商安装的证书(idevid)。客户端和云注册器使用atls连接中呈现的pki证书来相互认证彼此的身份。云注册器使用客户端pki证书(例如，idevid)来查找拥有客户端的域(通过使用销售渠道整合、通过使用任何适当的机制)。然后，云注册器将包括本地ca信息和任何其他必要细节的域信息(例如信任锚信息等)返回给客户端。客户端信任它从云注册器接收到的信息。

如所指出的，即使在客户端与ca之间存在tls代理，客户端也可以例如再次利用atls来使用其idevid针对一个或多个ca进行登记以获得一个或多个ldevid。作为另一示例，客户端可以使用其新的ldevid来连接到本地域和本地域服务。这可以包括使用ldevid连接到802.lx网络，使用ldevid连接到http代理或连接到mitm，使用ldevid针对本地域服务或因特网上的服务执行多路复用tls(在网络层或使用atls的应用层)。

本文所描述的实施例允许客户端使用atls来验证服务的pki身份并且允许服务使用标准的tls软件堆栈来验证客户端的pki身份，但在应用级运行并且有效地绕过任何网络层tls中间盒。客户端可以使用atls来通过使用其用于认证的idevid针对ca进行登记以便获得ldevid，同时可能经过tls中间盒。此外，客户端可以使用atls来通过使用其用于认证的ldevid连接到云服务以便访问服务特征，同时可能经过tls中间盒。

与引导、登记和服务访问对于安装者都是零接触的事实相结合，并进一步与客户端还获取可用于802.lx网络认证的ldevid的事实相结合，这些能力特别有利和独特。

图7示出了被配置为参与本文提出的技术的客户端(设备)710的框图。客户端710可以采取各种形式，但是为了简单起见，图7示出了客户端710包括全部经由例如公共总线705互连的一个或多个处理器720、存储器730、用户接口740、显示器750和网络接口760。

处理器720可以包括例如专用集成电路(asic)或可配置逻辑器件(例如，简单可编程逻辑器件(spld)、复杂可编程逻辑器件(cpld)、和现场可编程门阵列(fpga))，除了微处理器和数字信号处理器之外，其还可以作为处理电路而单独或共同地工作。这样的处理电路可以位于一个设备中或分布在多个设备中。

存储器730可以包括磁盘存储介质设备、光学存储介质设备、随机存取存储器(ram)或其他动态存储设备(例如，动态ram(dram)、静态ram(sram)、和同步dram(sdram))、只读存储器(rom)或其他静态存储设备(例如，可编程rom(prom)、可擦除prom(eprom)、和电可擦除prom(eeprom))、或其他物理/有形存储器存储设备。

用户接口740可以包括鼠标、键盘、轨迹球、或触摸屏以及其他类似的人机接口。

显示器750可以是用于向计算机用户显示信息的阴极射线管(crt)、液晶显示器(lcd)、发光二极管(led)显示器等。

网络接口760使能网络连接/通信(有线和/或无线)，并且可以是例如物理或虚拟网络接口卡(nic)。

存储器730可以存储用于atls/零触摸引导使能软件的指令或逻辑(软件)780，以允许客户端710执行参与本文描述的技术所需的操作。替代地，网络接口760可以被配置为执行这些操作。通常，存储器730可以包括一种或多种用包括计算机可执行指令的软件编码的有形(非暂时性)计算机可读存储介质(例如，存储设备)，并且当该软件被执行时，其可操作以执行本文所描述的操作。

图8示出了可以被配置为参与本文所描述的技术或操作的设备(服务器)810的框图，例如注册器540、云ca560、云服务550、本地ca570和本地服务580。与客户端设备一样，服务器810可以包括网络接口860(类似于上述那些)、一个或多个处理器820(类似于上述那些)以及存储器830(类似于上述那个)，该存储器存储用于零触摸引导使能软件的设备适当功能的指令(逻辑)880。逻辑880被配置为例如执行如例如图4中所示的atls握手的操作。并且，如上所述，通常，存储器830可以包括一种或多种用包括计算机可执行指令的软件编码的有形(非暂时性)计算机可读存储介质(例如，存储设备)，并且当该软件被执行时，它可操作以执行本文描述的操作。

总之，以一种形式提供了一种方法。该方法包括通过从网络设备向云服务器发送传输协议消息体中的tls记录来建立在网络设备和云服务器之间的应用层传输层安全(atls)连接，该atls连接经过至少一个传输层安全(tls)代理设备；经由atls连接从云服务器接收认证机构的标识符；建立与跟该标识符相关联的认证机构的连接，并且进而从认证机构接收用于访问与云服务器和认证机构不同的应用服务的证书；以及使用从认证机构接收到的证书来连接到应用服务。

该方法可以进一步包括由网络设备向云服务器发送网络设备的唯一标识符。该唯一标识符可以是网络设备的初始安全设备标识符(idevid)或制造商安装的证书(mic)。

在该方法中，证书可以是网络设备的本地有效设备标识符(ldevid)或本地有效证书(lsc)。因此，可以使用ldevid或lsc与本地域应用服务建立连接。

根据实施例，在网络设备和云服务器之间的atls连接可以被实例化为基于传输控制协议(tcp)的超文本传输协议(http)上的atls。在网络设备和云服务器之间的atls连接可以替代地被实例化为基于tls的http上的atls。

根据实施例，该方法包括通过从网络设备向云服务器发送超文本传输协议(http)消息体中的tls记录来建立在网络设备与另一云服务器之间的另一应用层传输层安全(atls)连接，该另一atls连接经过至少一个传输层安全(tls)代理设备；以及经由另一atls连接从另一云服务器接收另一认证机构的另一标识符。

在一个实现方式中，至少一个tls代理设备包括tls终止负载平衡器，并且至少一个传输层安全(tls)代理设备包括tls拦截中间盒。

在另一实施例中，提供了一种设备。该设备可以包括：被配置为使能网络通信的接口单元；存储器；以及一个或多个处理器，其耦合到接口单元和存储器，并且被配置为进行以下操作：通过从设备向云服务器发送传输协议消息体中的tls记录来建立在设备和云之间的应用层传输层安全(atls)连接，该atls连接经过至少一个传输层安全(tls)代理设备；经由atls连接从云服务器接收认证机构的标识符；建立与跟标识符相关联的认证机构的连接，并进而从认证机构接收用于访问不同于云服务器和认证机构的应用服务的证书；以及使用从认证机构接收到的证书连接到应用服务。

在实施例中，一个或多个处理器可以进一步被配置为由设备向云服务器发送设备的唯一标识符。

该唯一标识符可以包括设备的初始安全设备标识符(idevid)或制造商安装的证书(mic)。

证书可以包括设备的本地有效设备标识符(ldevid)或本地有效证书(lsc)，并且一个或多个处理器可以被进一步配置为使用ldevid或lsc建立与本地域应用服务的连接。

在设备和云服务器之间的atls连接可以被实例化为基于传输控制协议(tcp)的超文本传输协议(http)上的atls，或者替代地，在设备和云服务器之间的atls连接可以被实例化为基于tls的http上的atls。

在又一实施例中，提供了一种用指令编码的非暂时性有形计算机可读存储介质，这些指令在被至少一个处理器执行时，被配置为使处理器执行以下操作：通过从网络设备向云服务器发送传输协议消息体中的tls记录来建立在网络设备和云服务器之间的应用层传输层安全(atls)连接，该atls连接经过至少一个传输层安全(tls)代理设备；经由atls连接从云服务器接收认证机构的标识符；建立与跟该标识符相关联的认证机构的连接，并进而从认证机构接收用于访问与云服务器和认证机构不同的应用服务的证书；以及使用从认证机构接收到的证书连接到应用服务。

在实施例中，这些指令可以进一步可操作以由网络设备向云服务器发送网络设备的唯一标识符。该唯一标识符包括网络设备的初始安全设备标识符(idevid)或制造商安装的证书(mic)。

在本文中还描述了一种解决方案，该解决方案使设备能够即使在存在拦截代理的情况下也建立与因特网上的云服务的安全连接并能够利用该服务针对本地域执行零接触安全引导。从安装者的角度来看，解决方案是“零接触的”。也就是说，安装者仅需给设备通电，它就会自动并安全地进行引导，即使它被部署在拦截到因特网的所有流量的安全网络上。

以上描述仅旨在作为示例。