CN110324365A - 无密钥前端集群***、应用方法、存储介质、电子装置 - Google Patents
无密钥前端集群***、应用方法、存储介质、电子装置 Download PDFInfo
- Publication number
- CN110324365A CN110324365A CN201810266477.2A CN201810266477A CN110324365A CN 110324365 A CN110324365 A CN 110324365A CN 201810266477 A CN201810266477 A CN 201810266477A CN 110324365 A CN110324365 A CN 110324365A
- Authority
- CN
- China
- Prior art keywords
- handshake request
- cluster
- nginx
- cryptography
- context
- 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
Links
Classifications
-
- 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/0435—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 wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
-
- 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/16—Implementing security features at a particular protocol layer
- H04L63/168—Implementing security features at a particular protocol layer above the transport layer
-
- 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]
-
- 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/10—Protocols in which an application is distributed across nodes in the network
-
- 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/14—Session management
- H04L67/141—Setup of application sessions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
- H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer And Data Communications (AREA)
- Storage Device Security (AREA)
Abstract
本发明公开了一种无密钥前端集群***、应用方法、存储介质、电子装置。其中,该***包括:第一nginx集群,设置在***的前端,用于将握手请求转发到第二nginx集群;所述第二nginx集群,与所述第一nginx集群连接,用于接收所述握手请求,并与客户端执行握手操作。本发明解决了相关技术中实现keyless功能过于复杂的技术问题。
Description
技术领域
本发明涉及计算机领域,具体而言,涉及一种无密钥前端集群***、应用方法、存储介质、电子装置。
背景技术
相关技术中的Keyless(无钥匙)项目的目的在于使得证书独立于7层代理集群存在,证书放到统一的集群统一进行管理,如此不需要在前端ng分发私钥。核心目的是安全的考虑,是Cloudfare于2014年率先在美国的银行***发现的这个应用需求,之后全球逐步跟进。国际市场市面上的商业解决方案很多都是基于Cloudfare于2014年7月份发布的keyless***,至今能提供此服务的厂商也并不多。
在本申请相关技术中,目前公开的提供类似解决方案的都是非常重量级的,典型的是腾讯、百度和Cloudfare的。一个代表性的Cloudfare提供的实现方案中,需要对整个握手的过程进行了比较重度的改造,无论是腾讯、百度还是UCLOUD的思路都是类似的握手过程的修改。
Cloudfare的keyless***是一个深度改动握手过程的实现,其对于握手的密码学过程进行了自定义的改造,使得keyless server只完成特定的少量计算和网络IO。国内对于keyless方案的研究这几年也在如火如荼的展开,很多小厂是直接的采用Cloudfare开源出来的方案进行修改。UCLOUD的核心产品UEWAF于2017年6月份也开始支持Keyless方案(思路和Cloudfare类似)。QCLOUD腾讯云也于近年对Keyless方案进行自己的实现和深度的优化(握手使用QAT自研开发)。百度于16年前后展开HTTPS的Keyless工作,同时展开的还有性能。也是一站式解决性能和Keyless的思路。采用的方案在ng端与Cloudfare类似,是密码学层面的重新架构。
相关技术中的方案都是重度投入的密码学层面的解构或者SSL(安全套接层)/TLS(传输层安全)握手上的深度定制,每一个方案的成本都非常高,其中百度对现有的组件依赖较低,大量自研,投入非常高,其实现的效果也最好。腾讯主要是使用Cloudfare的思路进行了深度的开发。
针对上述的问题,目前尚未提出有效的解决方案。
发明内容
本发明实施例提供了一种无密钥前端集群***、应用方法、存储介质、电子装置,以至少解决相关技术中实现keyless功能过于复杂的技术问题。
根据本发明实施例的一个方面,提供了一种无密钥前端集群***,包括:第一nginx集群,设置在***的前端,用于将握手请求转发到第二nginx集群;所述第二nginx集群,与所述第一nginx集群连接,用于接收所述握手请求,并与客户端执行握手操作。
根据本发明实施例的另一方面,还提供了一种无密钥前端集群应用方法,包括:在***前端接收握手请求后,将所述握手请求转发到无密钥HTTPS前端服务器;在所述无密钥HTTPS前端服务器上,根据所述握手请求与客户端执行握手操作。
根据本发明的又一个实施例,还提供了一种存储介质,所述存储介质中存储有计算机程序,其中,所述计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。
根据本发明的又一个实施例,还提供了一种电子装置,包括存储器和处理器,所述存储器中存储有计算机程序,所述处理器被设置为运行所述计算机程序以执行上述任一项方法实施例中的步骤。
在本发明实施例中,通过两个nginx集群的配合,达到了转移握手请求的目的,从而实现了一种keyless的功能,进而解决了相关技术中实现keyless功能过于复杂的技术问题。
附图说明
此处所说明的附图用来提供对本发明的进一步理解,构成本申请的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
图1是根据本发明实施例的无密钥前端集群***的结构图;
图2是本实施例的Keyless***架构图;
图3是根据本发明实施例的无密钥前端集群应用方法流程图。
具体实施方式
为了使本技术领域的人员更好地理解本发明方案,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分的实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本发明保护的范围。
需要说明的是,本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
根据本发明实施例,提供了一种无密钥前端集群***实施例,图1是根据本发明实施例的无密钥前端集群***的结构图,如图1所示,包括:
第一nginx集群10,设置在***的前端,用于将握手请求转发到第二nginx集群;
第二nginx集群20,与第一nginx集群连接,用于接收握手请求,并与客户端执行握手操作。
本实施例的***包括两个nginx集群:faker(对应第一nginx集群)和shaker(对应第二nginx集群),第一个nginx(faker)是前端的ng(nginx的简称)集群,要同时使用streamproxy和HTTP proxy,并且要修改stream proxy使其支持upstream动态切换,同时还要实现一个stream proxy的SSL/TLS endpoint,faker端的nginx还需要使用一个7层的代理,在4层的stream proxy动态切换代理之后直接将数据导入到faker的7层代理。这个7层代理可以监听lp设备,使用TCP,也可以监听UNIX Domain Socket。
为了使后端服务器能够拿到真实的源IP,在stream proxy动态切换upstream的同时,我们还实现了在UNIX Domain Socket上的proxy protocol协议,同时使得UNIX DomainSocket的访问输出依然是TCP格式的。
在shaker端(负责握手的nginx),在握手结束之后需要传回对称加密的密码学上下文,在faker端进行上下文重建。这里的恢复重建只涉及到对称加密,非对称加密的整个过程被从方案级别绕过,这与相关技术中的Cloudfare系列的方案有显著的不同。
通过stream proxy,完整的绕过了对TLS握手的修改,使得整个方案不需要修改TLS握手的密码学内容,节省了大量的密码学方面投入,而这方面的人力投入成本通常非常高昂。同时这样带来一个很大的优点,无论TLS协议本身如何变动,本实施例的方案由于将整个握手过程作为一个黑盒子,不需要变动,从而达到了工程上的稳定性。这是Cludfare系列方案所不能达到的效果。这个方案还有一个有益效果就是session复用也直接在握手的ng(shaker)进行。这种将整个握手集中在后端的方案,使得可以使用QAT(QualityAssurance Technical,质量保证技术)在后端进行加速,而前端由于只有对称加密的过程,节省了所有的非对称加密相关的计算。现代CPU都有AES指令集,可以让前端nginx不需要QAT也能达到较高的效率,从而节省集群成本。
对对称加密的密码学重构,可以选择性支持几种最具代表性的数据传输方案,例如单纯的CBC(Cipher Block Chaining,分组链接模式)和带AEAD(AuthenticatedEncryption Associated Data)的CBC、GCM(Galois/Counter Mode),如此使得我们的服务器服务于特定的集中密码学套件,在达到最大兼容性的同时,使得所有的加密算法集中到我们选定的算法中,相对于太多中密码学套件的自由选择,能够有效的提高并发效率和管理效率。
本实施例在4层proxy到7层proxy转换的过程中,使用了UNIX Domain Socket和proxy protocol,使得性能和源IP的安全审计需求得到了同时的保证。
下面在具体实施例中进行详细解释和说明本实施例的***:
图2是本实施例的Keyless***架构图,其中,Keyless server对应上文所说的shaker,ng机器对应上文所说的faker,c(client)为客户端。
本实施例的Nginx是一个多进程模型的4层和7层流量代理。Keyless方案中同时采用4层和7层的功能。在4层层面,用于将SSL握手直接转发到shaker后端,由shaker后端完成握手之后再由shaker将对称加密的上下文同步到faker,在faker端进行对称加密上下文的重建,后续由faker接手数据的发送和接受。这个后续faker接手的方法就是nginx streamproxy的upstream的偷梁换柱,转发到自身的7层监听,然后faker nginx的7层部分就如常的处理整个数据流量。
在技术内容上,涉及到很多细节。首先是faker端的代理功能,原版的ng是不支持动态切换upstream的,我们必须要让他支持,并且是在特定的节点切换(SSL握手完成),这就需要一个握手完成的通知机制。而握手完成只有shaker知道,所以shaker端的NG在握手完成的时候传回一个用于复原faker端密码学上下文的我们自定义数据结构。这个密码学上下文非常复杂,后面详细介绍。在faker端的stream模块拿到这个上下文之后,就开始重定向upstream,早期的方案是使用lp设备(Loopback,Linux上的一个本地回环设备),但是lp设备涉及到TCP的三次握手开销,后来将TCP连接改为UNIX Domain Socket连接。
而由于涉及到多次中转,服务端安全审计所依赖的源IP信息已经不见了,所以参照Proxy Protocol的原理,在切换Upstream的时候,实现了Proxy Protocol协议。ProxyProtocol是指在一个TCP连接的开始,三次握手之后,立刻发送一个字符串,这个字符串里面写明源IP、端口等信息,这样后端并不是依赖IP层的源IP来判断,而是依赖这里设置的源IP,因为IP层的源IP已经变为了本机。又由于Proxy Protocol本身不适用于UNIX DomainSocket,所以Keyless在实现的时候,直接套用了Proxy Protocol的原理,将其修改应用于UNIX Domain Socket上,从而达到UNIX Domain Socket也能得到源IP,并且日志上也是TCP的效果。
另外一个考量是当TLS握手来临的时候,用户端的最后一次握手会和数据一起到达,而最后一次握手在Keyless方案中是在shaker端完成,而数据是在faker端完成,对于用户端一起发送的情况,在faker端就必须要做出区分。也就是将数据分割开,属于握手的发送到shaker,属于数据的留在faker。而留在faker的非握手数据必须要等握手完成,在faker端复原了对称加密的密码学上下文之后才能够正常解密,所以数据必须要缓存。缓存的思路有两种,一种是在NG端读取出来,放在应用层buf中进行缓存,另外一种别出心裁,是直接PEEK之后,判断是数据就放在内核,不去读取,让这部分数据留在内核的TCP空间,等待握手完成之后再去读取。显然第一种能提供更好的控制,但是第二种能提供更简单稳定的实现。
本实施例一个很重要的维度是异步方案,NG和OpenSSL本来都是不支持异步的,但是随着QAT的退出,异步方案逐渐被支持,Keyless在实现的时候完整的考虑异步的思路。异步在OpenSSL中的原理是一个接口多次进入,直到返回了正确的状态。也就是是C++Boost式的coroutine,而不是Golang式的协程。这种模式就决定了使用者在使用API的时候需要多次调用同一个API,例如如果是同步模式调用SSL_do_handshake只需要调用一次,阻塞等待TLS握手完成,然后返回一个1,如果返回-1就是出错了。但是在异步方案下,前两次调用SSL_do_handshake的时候一定会返回-1,这表示,进入了到了握手的两个等待另一侧的状态,这个等待在异步中是不能接受的,这个等待会被直接跳过继续执行,下一次再调用一次SSL_do_handshake时等待的事件很可能就会已经完成了,完成了之后就能够继续原来的流程向下处理,整个过程不需要等待,本来需要同步等待的地方会被其他的任务填充。直到第三次调用这个函数的时候,这个函数才可能返回1,真正的表示握手的完成。在使用上,这是非常典型的同步与异步的区别,所以在修改的时候,Keyless的修改位置一定是在最后一次调用成功API的时候修改,而不是调用了就可以认为完成,并且在NG的连接结构体中添加了表示我们的特殊密码学构造是否完成的标志。怎么构建密码学上下文是一回事,什么时候构建又是另外一回事。
TLS有一个很重要的概念是session,session复用是提高性能的最有效方法。因为我们的Keyless方案完整的将握手过程交给了shaker,而session复用的协商是属于握手的一部分,所以我们在设计上将session复用交给shaker是性价比最高的方式。Session是TLS协议规定的协议机制,OpenSSL实现了这个机制。
本实施例所要解决的问题是提出已久的https握手过程中的keyless问题,能够将私钥和证书独立保存和管理。由于目前市面上的投入都相对重量级,虽然能达到的性能更高(例如百度的显卡计算),但是成本投入上是大部分企业所不能接受的。本方案是针对大部分的厂商并没有腾讯、百度那样的投入能力,提出的充分利用现有架构的低成本高性能方案,通过两个nginx和两个openssl(软件套件)的配合,充分利用nginx的4层代理和7层代理的能力,对两个nginx进行了最小的修改,达到keyless项目目的。
根据本发明实施例,提供了一种无密钥前端集群应用的方法实施例,可以解释本实施例中***的处理逻辑,需要说明的是,在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机***中执行,并且,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。
图3是根据本发明实施例的无密钥前端集群应用方法流程图,如图3所示,该方法包括如下步骤:
步骤S302,在***前端接收握手请求后,将握手请求转发到无密钥HTTPS前端服务器;
步骤S304,在无密钥HTTPS前端服务器上,根据握手请求与客户端执行握手操作。
可选地,在根据握手请求与客户端执行握手操作之后,方法还包括:在握手操作执行结束之后传回对称加密的密码学上下文至***前端,其中,密码学上下文用于在***前端进行上下文重建。
可选地,方法还包括:使用密码学上下文在***前端进行上下文重建,在上下文重建完成之后,与客户端传输***数据。
在本实施例中,握手请求包括以下至少之一:传输层安全TLS协议握手请求,安全套接层SSL协议握手请求。TLS协议握手请求包括:session复用。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
在本发明的上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中,应该理解到,所揭露的技术内容,可通过其它的方式实现。其中,以上所描述的装置实施例仅仅是示意性的,例如所述单元的划分,可以为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个***,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,单元或模块的间接耦合或通信连接,可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。
Claims (12)
1.一种无密钥前端集群***,其特征在于,包括:
第一nginx集群,设置在***的前端,用于将握手请求转发到第二nginx集群;
所述第二nginx集群,与所述第一nginx集群连接,用于接收所述握手请求,并与客户端执行握手操作。
2.根据权利要求1所述的***,其特征在于,所述第二nginx集群还用于:在所述握手操作执行结束之后传回对称加密的密码学上下文至所述第一nginx集群,其中,所述密码学上下文用于在所述第一nginx集群进行上下文重建。
3.根据权利要求2所述的***,其特征在于,第一nginx集群还用于:使用所述密码学上下文在所述第一nginx集群进行上下文重建,在上下文重建完成之后,与所述客户端传输***数据。
4.根据权利要求1所述的***,其特征在于,所述握手请求包括以下至少之一:传输层安全TLS协议握手请求,安全套接层SSL协议握手请求。
5.根据权利要求4所述的***,其特征在于,所述TLS协议握手请求包括:session复用。
6.根据权利要求1所述的***,其特征在于,所述第一nginx集群包括:
流代理stream proxy,用于接收新建的到Loopback的上行tcp,以及将所述握手请求转发到所述第二nginx集群,其中,所述stream proxy支持上行动态切换。
7.一种无密钥前端集群应用方法,其特征在于,包括:
在***前端接收握手请求后,将所述握手请求转发到无密钥HTTPS前端服务器;
在所述无密钥HTTPS前端服务器上,根据所述握手请求与客户端执行握手操作。
8.根据权利要求7所述的方法,其特征在于,在根据所述握手请求与客户端执行握手操作之后,所述方法还包括:
在所述握手操作执行结束之后传回对称加密的密码学上下文至所述***前端,其中,所述密码学上下文用于在所述***前端进行上下文重建。
9.根据权利要求8所述的方法,其特征在于,所述方法还包括:
使用所述密码学上下文在所述***前端进行上下文重建,在上下文重建完成之后,与所述客户端传输***数据。
10.根据权利要求7所述的方法,其特征在于,所述握手请求包括以下至少之一:传输层安全TLS协议握手请求,安全套接层SSL协议握手请求。
11.一种存储介质,其特征在于,所述存储介质中存储有计算机程序,其中,所述计算机程序被设置为运行时执行所述权利要求7至10任一项中所述的方法。
12.一种电子装置,包括存储器和处理器,其特征在于,所述存储器中存储有计算机程序,所述处理器被设置为运行所述计算机程序以执行所述权利要求7至10任一项中所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810266477.2A CN110324365B (zh) | 2018-03-28 | 2018-03-28 | 无密钥前端集群***、应用方法、存储介质、电子装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810266477.2A CN110324365B (zh) | 2018-03-28 | 2018-03-28 | 无密钥前端集群***、应用方法、存储介质、电子装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN110324365A true CN110324365A (zh) | 2019-10-11 |
CN110324365B CN110324365B (zh) | 2023-01-24 |
Family
ID=68110203
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810266477.2A Active CN110324365B (zh) | 2018-03-28 | 2018-03-28 | 无密钥前端集群***、应用方法、存储介质、电子装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN110324365B (zh) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111190569A (zh) * | 2019-12-30 | 2020-05-22 | 中国科学技术大学 | 一种基于Intel QAT的同态加密卸载方法 |
CN114338629A (zh) * | 2020-09-25 | 2022-04-12 | 北京金山云网络技术有限公司 | 数据处理方法、装置、设备及介质 |
CN115987652A (zh) * | 2022-12-27 | 2023-04-18 | 北京深盾科技股份有限公司 | 一种账号管理方法、***、设备及计算机存储介质 |
WO2024139903A1 (zh) * | 2022-12-28 | 2024-07-04 | 中国互联网络信息中心 | 一种面向通用互联网平台的集群密码加速方法及装置 |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2000021275A1 (en) * | 1998-10-02 | 2000-04-13 | Microtalk Corporation | Keyless portable cellular phone system having remote voice recognition |
WO2008042459A2 (en) * | 2006-09-29 | 2008-04-10 | Witness Systems, Inc. | Recording using proxy servers |
EP2573738A1 (en) * | 2011-09-21 | 2013-03-27 | Delphi Technologies, Inc. | System and method to operate an extended range keyless entry system to recognize a keyless entry transmitter. |
CN106341417A (zh) * | 2016-09-30 | 2017-01-18 | 贵州白山云科技有限公司 | 一种基于内容分发网络的https加速方法和*** |
CN106411893A (zh) * | 2016-09-30 | 2017-02-15 | 成都知道创宇信息技术有限公司 | 一种https服务的部署方法 |
CN106790090A (zh) * | 2016-12-23 | 2017-05-31 | 北京奇虎科技有限公司 | 基于ssl的通信方法、装置及*** |
CN107426193A (zh) * | 2017-06-30 | 2017-12-01 | 重庆大学 | 一种https应用中针对硬件加速的新型I/O通路设计 |
CN107707517A (zh) * | 2017-05-09 | 2018-02-16 | 贵州白山云科技有限公司 | 一种HTTPs握手方法、装置和*** |
-
2018
- 2018-03-28 CN CN201810266477.2A patent/CN110324365B/zh active Active
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2000021275A1 (en) * | 1998-10-02 | 2000-04-13 | Microtalk Corporation | Keyless portable cellular phone system having remote voice recognition |
WO2008042459A2 (en) * | 2006-09-29 | 2008-04-10 | Witness Systems, Inc. | Recording using proxy servers |
EP2573738A1 (en) * | 2011-09-21 | 2013-03-27 | Delphi Technologies, Inc. | System and method to operate an extended range keyless entry system to recognize a keyless entry transmitter. |
CN106341417A (zh) * | 2016-09-30 | 2017-01-18 | 贵州白山云科技有限公司 | 一种基于内容分发网络的https加速方法和*** |
CN106411893A (zh) * | 2016-09-30 | 2017-02-15 | 成都知道创宇信息技术有限公司 | 一种https服务的部署方法 |
CN106790090A (zh) * | 2016-12-23 | 2017-05-31 | 北京奇虎科技有限公司 | 基于ssl的通信方法、装置及*** |
CN107707517A (zh) * | 2017-05-09 | 2018-02-16 | 贵州白山云科技有限公司 | 一种HTTPs握手方法、装置和*** |
CN107426193A (zh) * | 2017-06-30 | 2017-12-01 | 重庆大学 | 一种https应用中针对硬件加速的新型I/O通路设计 |
Non-Patent Citations (2)
Title |
---|
NICK SULLIVAN: "keyless SSL:The nitty gitty tecnical details", 《THE CLOUDFLARE BLOG》 * |
WEIXIN_30799995: "转:HTTPS协议", 《HTTPS://BLOG.CSDN.NET/WEIXIN_30799995/ARTICLE/DATAILS/97698077》 * |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111190569A (zh) * | 2019-12-30 | 2020-05-22 | 中国科学技术大学 | 一种基于Intel QAT的同态加密卸载方法 |
CN111190569B (zh) * | 2019-12-30 | 2022-05-13 | 中国科学技术大学 | 一种基于Intel QAT的同态加密卸载方法 |
CN114338629A (zh) * | 2020-09-25 | 2022-04-12 | 北京金山云网络技术有限公司 | 数据处理方法、装置、设备及介质 |
CN115987652A (zh) * | 2022-12-27 | 2023-04-18 | 北京深盾科技股份有限公司 | 一种账号管理方法、***、设备及计算机存储介质 |
CN115987652B (zh) * | 2022-12-27 | 2023-11-03 | 北京深盾科技股份有限公司 | 一种账号管理方法、***、设备及计算机存储介质 |
WO2024139903A1 (zh) * | 2022-12-28 | 2024-07-04 | 中国互联网络信息中心 | 一种面向通用互联网平台的集群密码加速方法及装置 |
Also Published As
Publication number | Publication date |
---|---|
CN110324365B (zh) | 2023-01-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Miller et al. | The honey badger of BFT protocols | |
Johansen et al. | Operating system support for mobile agents | |
CN104753817B (zh) | 一种云计算消息队列服务本地模拟方法和*** | |
CN110324365A (zh) | 无密钥前端集群***、应用方法、存储介质、电子装置 | |
CN103038749B (zh) | 为了优化群集特定配置的使用而按进程类型在群集之间分割进程 | |
CN102170440B (zh) | 适用于存储云间数据安全迁移的方法 | |
CN111598566A (zh) | 基于混合跨链的网络支付*** | |
US20200372360A1 (en) | Secure cloud-based machine learning without sending original data to the cloud | |
JP2021508877A (ja) | 高性能分散型記録システム | |
CN108683747A (zh) | 资源获取、分发、下载方法、装置、设备及存储介质 | |
CN109741068B (zh) | 网银跨行签约方法、装置及*** | |
CN108390881A (zh) | 一种分布式高并发实时消息推送方法及*** | |
EP2899947A1 (en) | Component oriented hybrid cloud operating system architecture and communication method thereof | |
CN111754216A (zh) | 一种支付链路自动切换方法 | |
CN111625497B (zh) | 一种分布式文件***的部署方法、装置、设备及存储介质 | |
CN106961429B (zh) | 一种面向混合云计算平台的协同服务方法 | |
CN105530266B (zh) | 一种许可证书管理方法、装置及*** | |
CN108964880A (zh) | 一种数据传输方法及装置 | |
CN107315972A (zh) | 一种大数据非结构化文件动态脱敏方法及*** | |
CN115373796A (zh) | 具有分区和动态混洗模型更新的联合学习 | |
CN107070942A (zh) | 一种数据保全方法及相关*** | |
Palmieri et al. | Towards a federated Metropolitan Area Grid environment: The SCoPE network-aware infrastructure | |
CN110099031A (zh) | 一种服务调用方法、装置及微服务平台 | |
CN107634989A (zh) | 一种云钱包构建方法及服务器 | |
CN105321121A (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 |