超文本传输协议解密的处理方法及装置制造方法
【专利摘要】本发明涉及一种超文本传输协议解密处理方法，该方法包括：接收第一数据包，判断第一数据包是否为超文本传输协议数据包；若数据包为超文本传输协议数据包时，则对第一数据包进行解密处理，得到原始的数据报文；将数据报文注入到内核中，将数据报文封装为第二数据包，并对第二数据包进行安全性检测；将第二数据包发送。本发明在用户态加解密程序与既有的内核转发框架之间建立了数据通道，在将报文通过数据通道注入内核转发框架之前，通过预处理模块的预处理，避免了重新开发转发路径，从而提高了原有内核转发框架的利用率，将报文通过数据通道注入内核中，屏蔽了加密流量和解密流量的差异性，重用既有的内核转发框架，提高了开发效率，降低了成本。
【专利说明】超文本传输协议解密的处理方法及装置
【技术领域】
[0001]本发明涉及互联网技术，尤其涉及一种超文本传输协议解密的处理方法及装置。【背景技术】
[0002]安全套接层协议(Secure Sockets Layer, SSL)是为保证两通讯体在网络上传输的敏感信息的完整性和机密性而设计出的可靠的端到端服务。企业安全系统能够正常运行的关键之一就是流量可读。如果加密的流量带有病毒，而普通的防火墙无法解析这些加密的数据，用户的安全得不到保障。所以处于网络边界的防火墙产品应该具备超文本传输协议(Hyper Text Transport Protocol, HTTPS)解密功能,对不安全流量进行过滤。所以越来越多的防火墙产品都加入了 HTTPS解密功能。
[0003]现有的技术方案在加解密程序处理完成后，都为HTTPS解密功能设计了一套完整的报文转发框架，对原有代码进行大量修改以适应HTTPS解密功能，研发成本高且效率低。
[0004]在用户态加解密程序与既有的内核转发框架之间建立数据通道，将用户态解密后的报文通过数据通道注入到内核中，屏蔽加密流量和解密流量的差异性，重用既有的内核转发框架，可以解决现有技术的不足。
【发明内容】
[0005]本发明的目的是针对现有技术的不足，主要解决在最大限度重用系统中明文处理逻辑的情况下，加入新的HTTPS解密功能。在用户态加解密程序与既有的明文报文转发框架之间建立了数据通道，在将报文通过数据通道注入内核转发框架之前，通过预处理模块的预处理，避免了重新开发转发路径，从而提高了原有内核转发框架的利用率，降低了成本。
[0006]在本发明第一方面，提供了一种超文本传输协议解密处理方法，该方法包括:
[0007]接收第一数据包，判断第一数据包是否为超文本传输协议数据包；
[0008]若数据包为超文本传输协议数据包时，则对第一数据包进行解密处理，得到原始的数据报文；
[0009]将数据报文注入到内核中，将数据报文封装为第二数据包，并对第二数据包进行安全性检测；
[0010]将第二数据包发送。
[0011]优选地，对第一数据包进行解密处理具体包括:利用用户态的加密解密程序对第一数据包进行解密处理。
[0012]优选地，将第二数据包发送具体包括:
[0013]利用转发逻辑对第二数据包进行处理，对于带有病毒流量的第二数据包进行丢弃处理，对于安全的第二数据包转发。
[0014]优选地，若第一数据包不是超文本传输协议数据包时，则直接转发第一数据包。
[0015]优选地，直接转发第一数据包包括:利用转发逻辑对第一数据包进行处理，对于带有病毒流量的第一数据包进行丢弃处理，对于安全的第一数据包转发。
[0016]在本发明第二方面，提供了 一种超文本传输协议解密处理装置，装置包括:接收单元、判断单元、解密单元、检测单元、封装单元和发送单元；
[0017]接收单元，用于接收第一数据包，并发送给判断单元；
[0018]判断单元，用于判断第一数据包是否为超文本传输协议数据包，并将第一数据包发送给解密单元；
[0019]解密单元，用于接收判断单元发送的第一数据包，并若数据包为超文本传输协议数据包时，则对第一数据包进行解密处理，得到原始的数据报文，并将数据报文发送给检测单元；
[0020]封装单元，用于接受解密单元发送的数据报文，并将数据报文注入到内核中，将数据报文封装为第二数据包，并将第二数据包发送给检测单元；
[0021]检测单元，用于接收封装单元发送的第二数据包，并对第二数据包进行安全性检测，并将进行安全性检测后的第二数据包发送给发送单元；
[0022]发送单元，用于发送第二数据包。
[0023]优选地，解密单元具体用于利用用户态的加密解密程序对第一数据包进行解密处理。
[0024]优选地，发送单元具体用于利用转发逻辑对第二数据包进行处理，对于带有病毒流量的第二数据包进行丢弃处理，对于安全的第二数据包转发。
[0025]优选地，发送单元还用于若第一数据包不是超文本传输协议数据包时，则直接转发第一数据包。
[0026]优选地，发送单元具体用于利用转发逻辑对第一数据包进行处理，对于带有病毒流量的第一数据包进行丢弃处理，对于安全的第一数据包转发。
[0027]本发明的优点在于在用户态加解密程序与既有的内核转发框架之间建立了数据通道，在将报文通过数据通道注入内核转发框架之前，通过预处理模块的预处理，避免了重新开发转发路径，从而提高了原有内核转发框架的利用率，将报文通过数据通道注入内核中，屏蔽了加密流量和解密流量的差异性，重用既有的内核转发框架，提高了开发效率，降低了成本。
【专利附图】
【附图说明】
[0028]图1为本发明实施例的超文本传输协议解密处理装置位置部署示意图；
[0029]图2为本发明实施例的超文本传输协议解密处理流程图；
[0030]图3为本发明实施例的超文本传输协议报文转发示意图；
[0031]图4为本发明实施例的超文本传输协议解密处理装置示意图。
【具体实施方式】
[0032]为使本发明实施例的技术方案以及优点表达的更清楚，下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。
[0033]图1为本发明一个实施例的超文本传输协议解密处理装置位置部署示意图，如图所示，本发明提供的装置可以应用于获取客户和服务器之间的数据包。包括解密处理装置，客户端(client)和服务器(server),解密处理装置位于client和server之间，并作为代理装置，其功能是可以获取client和server相互发送的数据包，然后判断解密装置获取的数据包是否为HTTPS报文，若数据包为HTTPS报文，为了对数据包的HTTPS报文进行安全性检测，则需对数据包进行解密处理。
[0034]图2为本发明实施例的超文本传输协议解密处理流程图，如图所示，本实施例具体包括如下步骤:
[0035]步骤101、接收第一数据包。通过网络从数据链路层获取数据包，数据链路层例如是对应客户端的设备驱动程序、网卡、服务器等。
[0036]步骤102、判断第一数据包是否为超文本传输协议数据包。判断单元判断第一数据包是否为超文本传输协议数据包，并将第一数据包发送给解密单元。
[0037]步骤103、若步骤102中数据包为超文本传输协议数据包时，则对第一数据包进行解密处理，得到原始的数据报文。
[0038]具体地，如图3所示为本发明实施例的超文本传输协议报文转发示意图。其中，解密单元对第一数据包进行解密处理具体包括:利用用户态的加密解密程序对第一数据包进行解密处理。
[0039]步骤104、将数据报文注入到内核中。
[0040]具体地，通过用户态和内核态的数据通道，将解密后的数据报文注入到内核系统中进行处理。由于不能直接将数据包注入内核中，因此将解密后的数据报文注入到内核中。
[0041]步骤105、在内核中将数据报文封装为第二数据包。
[0042]具体地，将解密后的明文数据重新封装为数据包。由于后续中，转发框架将决定该数据包是否转发，因此，需要通过封装单元对解密后的数据报文进行重新封装为数据包。
[0043]步骤106、对第二数据包进行安全性检测，判断第二数据包是否安全，对安全的数据包进行转发，对不安全的数据包终止转发。
[0044]具体地，检测对第二数据包进行安全性检测，并将进行安全性检测后的第二数据包发送给发送单元，由于第二数据包将会发送给客户端或者服务器，因此有必要对数据包进行安全性检测。通过既有转发框架的检测机制，判断数据包是否包含有病毒。若经过检测后的第二数据包带有病毒，则转发逻辑将中止转发第二数据包；若经过检测后的第二数据包安全，则转发逻辑将第二数据包发送给发送单元。
[0045]步骤107、接收106中转发逻辑发送的第二数据包，并将第二数据包转发给客户端或者服务器。
[0046]步骤108、将步骤106中的包含有病毒第二数据包丢弃。
[0047]步骤109、若步骤102中数据包不为超文本传输协议数据包，则直接判断步骤102
中的第一数据包是否安全。
[0048]具体地，检测对第一数据包进行安全性检测，并将进行安全性检测后的第一数据包发送给发送单元，由于第一数据包将会发送给客户端或者服务器，因此有必要对数据包进行安全性检测。通过既有转发框架的检测机制，判断数据包是否包含有病毒。若经过检测后的第一数据包带有病毒，则转发逻辑将中止转发第一数据包；若经过检测后的第一数据包安全，则转发逻辑将第一数据包发送给发送单元。
[0049]步骤110、若步骤102中的第一数据包安全，则将第一数据包转发给客户端或者服务器。
[0050]步骤111、若步骤102中的第一数据包带有病毒，则将第一数据包丢弃。
[0051]图4为本发明实施例的超文本传输协议解密处理装置示意图，如图所示，超文本传输协议解密处理装置包括:接收单元201、判断单元202、解密单元203、封装单元204、检测单元205和发送单元206。
[0052]接收单元201，用于接收第一数据包，并发送给判断单元；
[0053]判断单元202，用于判断第一数据包是否为超文本传输协议数据包，并将第一数据包发送给解密单元；
[0054]解密单元203，用于接收判断单元发送的第一数据包，并若数据包为超文本传输协议数据包时，则对第一数据包进行解密处理，得到原始的数据报文，并将数据报文发送给检测单元；
[0055]封装单元204，用于接受解密单元发送的数据报文，并将数据报文注入到内核中，将数据报文封装为第二数据包，并将第二数据包发送给检测单元；
[0056]检测单元205，用于接收封装单元发送的第二数据包，并对第二数据包进行安全性检测，并将进行安全性检测后的第二数据包发送给发送单元；
[0057]发送单元206，用于发送第二数据包。
[0058]具体地，发送单元用于利用转发逻辑对第二数据包进行处理，对于带有病毒流量的第二数据包进行丢弃处理，对于安全的第二数据包转发。
[0059]发送单元还用于若第一数据包不是超文本传输协议数据包时，利用转发逻辑对第一数据包进行处理，对于带有病毒流量的第一数据包进行丢弃处理，对于安全的第一数据包转发。
[0060]本发明HTTPS解密的实现方法及设备，优点在于在用户态加解密程序与既有的内核转发框架之间建立了数据通道，在将报文通过数据通道注入内核转发框架之前，通过预处理模块的预处理，避免了重新开发转发路径，从而提高了原有内核转发框架的利用率，将报文通过数据通道注入内核中，屏蔽了加密流量和解密流量的差异性，重用既有的内核转发框架，提高了开发效率，降低了成本。
[0061]以上所述的【具体实施方式】，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的【具体实施方式】而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
【权利要求】
1.一种超文本传输协议解密处理方法，其特征在于，所述方法包括: 接收第一数据包，判断所述第一数据包是否为超文本传输协议数据包； 若所述数据包为超文本传输协议数据包时，则对所述第一数据包进行解密处理，得到原始的数据报文； 将所述数据报文注入到内核中，将所述数据报文封装为第二数据包，并对所述第二数据包进行安全性检测； 将所述第二数据包发送。
2.根据权利要求1所述的方法，其特征在于所述对所述第一数据包进行解密处理具体包括:利用用户态的加密解密程序对所述第一数据包进行解密处理。
3.根据权利要求1所述的方法，其特征在于所述将所述第二数据包发送具体包括: 利用转发逻辑对所述第二数据包进行处理，对于带有病毒流量的第二数据包进行丢弃处理，对于安全的第二数据包转发。
4.根据权利要求1所述的方法，其特征在于所述方法包括:若所述第一数据包不是超文本传输协议数据包时，则直接转发所述第一数据包。
5.根据权利要求4所述的方法，其特征在于所述直接转发所述第一数据包包括:利用转发逻辑对所述第一数据包进行处理，对于带有病毒流量的第一数据包进行丢弃处理，对于安全的第一数据包转发 。
6.一种超文本传输协议解密处理装置，其特征在于，所述装置包括:接收单元、判断单元、解密单元、检测单元、封装单元和发送单元； 所述接收单元，用于接收第一数据包，并发送给所述判断单元； 所述判断单元，用于判断所述第一数据包是否为超文本传输协议数据包，并将所述第一数据包发送给所述解密单元； 所述解密单元，用于接收所述判断单元发送的第一数据包，并若所述数据包为超文本传输协议数据包时，则对所述第一数据包进行解密处理，得到原始的数据报文，并将所述数据报文发送给所述检测单元； 所述封装单元，用于接受所述解密单元发送的所述数据报文，并将所述数据报文注入到内核中，将所述数据报文封装为第二数据包，并将所述第二数据包发送给所述检测单元; 所述检测单元，用于接收所述封装单元发送的所述第二数据包，并对第二数据包进行安全性检测，并将进行安全性检测后的第二数据包发送给所述发送单元； 所述发送单元，用于发送所述第二数据包。
7.根据权利要求6所述的装置，其特征在于所述解密单元具体用于利用用户态的加密解密程序对所述第一数据包进行解密处理。
8.根据权利要求6所述的方法，其特征在于所述发送单元具体用于利用转发逻辑对所述第二数据包进行处理，对于带有病毒流量的第二数据包进行丢弃处理，对于安全的第二数据包转发。
9.根据权利要求6所述的方法，其特征在于发送单元还用于若所述第一数据包不是超文本传输协议数据包时，则直接转发所述第一数据包。
10.根据权利要求9所述的方法，其特征在于所述发送单元具体用于利用转发逻辑对所述第一数据包进行处理，对于带有病毒流量的第一数据包进行丢弃处理，对于安全的第一数据包转发。`
【文档编号】H04L29/06GK103701819SQ201310744077
【公开日】2014年4月2日 申请日期:2013年12月30日 优先权日:2013年12月30日
【发明者】刘春辉, 米嘉, 梁志勇 申请人:北京网康科技有限公司