CN117527421A - 一种实现http协议安全传输的方法 - Google Patents

一种实现http协议安全传输的方法 Download PDF

Info

Publication number
CN117527421A
CN117527421A CN202311665526.7A CN202311665526A CN117527421A CN 117527421 A CN117527421 A CN 117527421A CN 202311665526 A CN202311665526 A CN 202311665526A CN 117527421 A CN117527421 A CN 117527421A
Authority
CN
China
Prior art keywords
server
client
key
data
keys
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.)
Pending
Application number
CN202311665526.7A
Other languages
English (en)
Inventor
蔡莉莉
钱海忠
张娟
张莉
熊芳强
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Jiangsu Maritime Institute
Original Assignee
Jiangsu Maritime Institute
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Jiangsu Maritime Institute filed Critical Jiangsu Maritime Institute
Priority to CN202311665526.7A priority Critical patent/CN117527421A/zh
Publication of CN117527421A publication Critical patent/CN117527421A/zh
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network 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/0442Network 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 asymmetric encryption, i.e. different keys for encryption and decryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols

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)

Abstract

本发明公开了一种实现HTTP协议进行安全传输的方法,主要是浏览器和服务器两者之间通信采用密文数据。通信双方采用非对称密钥机制。具体过程表现如下两种模式。第一种模式采用一方(客户端或服务端)生成一对非对称密钥:(1)服务端接收客户端的请求时,在本地生成一对密钥,把公开密钥发送给客户端,之后客户端发送给服务端都通过公共密钥进行加密,服务端接收数据利用私用密钥进行解密;(2)通信间隔一段时间后,会随机更换通信密钥;第二种模式客户端和服务端都各自生成一对密钥:(1)双方开始通信时,各自生成一对密钥,把公开发送给对方,利用私用密钥进行解密;(2)通信间隔一段时间后,双方协商后,更换密钥。

Description

一种实现HTTP协议安全传输的方法
技术领域
本发明涉及安全通信领域,尤其是一种实现HTTP协议安全传输的方法。
背景技术
HTTP(Hypertext Transfer Protocol)是一种用于在Web上传输数据的协议。它是应用层协议,用于在客户端和服务器之间进行通信。HTTP协议的应用非常广泛。,它在现代互联网中起着至关重要的作用,但是该协议也存在一些不足之处:(1)明文传输:HTTP协议默认使用明文传输数据,这意味着网络中的攻击者可以截取和查看传输的数据。这使得信息泄露和隐私泄露成为可能;(2)不安全性:由于HTTP协议缺乏安全性,无法对传输的数据进行加密和认证。使得HTTP易受网络攻击,例如中间人攻击、数据篡改和会话劫持。
目前主要的解决方案是采用HTTPS协议,它是基于HTTP协议的安全版本,通过使用SSL(Secure Sockets Layer)或TLS(Transport Layer Security)协议来保护在网络上传输的数据的安全性。通过这些安全机制,HTTPS协议能够确保在客户端和服务器之间传输的数据是加密的、完整的,并且在传输过程中不被窃取或篡改。这使得HTTPS成为互联网上安全传输敏感信息的重要协议,如在线支付、个人信息和登录凭证等。现有技术中HTTP协议最大的缺点就是明文传输,由于HTTPS协议是构建在SSL之上因此在web部署时需要使用证书,而生成证书需要通过CA中心,进而造成一些使用费用。总的来说,HTTPS协议部署CA的费用因组织的规模和需求而异,但通常以几百美元到几千美元不等。但是,这种成本通常比未加密的HTTP通信的风险要低得多,因此可以考虑它作为保障企业安全的一个重要组成部分。HTTP协议是用于从WWW服务器传输超文本到本地浏览器的传送协议,是客户端和服务器之间请求和响应的标准,目前大多数网站和app的接口都是采用HTTP协议。然而,HTTP协议却存在一些不足,例如,HTTP协议使用明文方式发送内容,其本身不具备加密的功能,内容可能被窃听;使用HTTP协议的服务端与客户端都不会验证通信方的身份,可能遭遇伪装,即无法确定正在通信的对方是否是真实意图的对方,也就无法识别该请求是否被拦截、重放,无法避免重放攻击的发生;HTTP协议无法证明通信的报文完整性,报文可能被篡改。
因此,有必要提供一种实现HTTP协议安全传输的方法来解决上述技术问题。
发明内容
本部分的目的在于概述本发明的实施例的一些方面以及简要介绍一些较佳实施例,在本部分以及本申请的说明书摘要和发明名称中可能会做些简化或省略以避免使本部分、说明书摘要和发明名称的目的模糊,而这种简化或省略不能用于限制本发明的范围。
因此,本发明所要解决的技术问题如何提升HTTP协议传输存在安全性问题及采用HTTPS协议需要一定证书成本,采用非对称密钥体系应用到HTTP现有的协议之上,可以避免CA证书的费用问题。为解决上述技术问题,本发明提供如下技术方案:一种实现HTTP协议安全传输的方法,其特征在于,包括以下步骤:S1、数据传输是采用非对称密钥机制;
S2、双方通信不需要经过CA进行认证;
S3、采用服务端下发公开密钥及客户端和服务端都各生成一对公开和私有密钥的两种方式;
S4、在实际应用场景中,根据应用需要加密不同的数据;
S5、web服务端与每个客户端保持一对密钥;
S6、一旦一个会话结束后,或是客户端与服务端无交互时间超过了设定时间,服务端会自动销毁密钥;
S7、服务端或客户端在发送公开密钥给对方时,采用非对称加密算法实现双方的加密通信进行传输。
作为本发明所述实现HTTP协议安全传输的方法的一种优选方案,所述客户端在首次请求服务端时,申请获取服务端的公开密钥和会话标识ID。
作为本发明所述实现HTTP协议安全传输的方法的一种优选方案,所述服务端接收请求时,做以下操作:
3.1在判断会话是否新的会话,不是新会话则直接回送已有的密钥和ID;否则进入3.2;
3.2创建会话机制,生成一个标识该会话的唯一ID;
3.3利用非对称密钥算法生成一对密钥,建立ID和密钥的映射关系存储的本地,每个会话是使用的密钥都是独立生成的;
3.4以传统加密算法对公开密钥和会话标识ID进行加密,向客户端发送响应报文,报文含有服务端公开密钥和会话标识ID的密文。
作为本发明所述实现HTTP协议安全传输的方法的一种优选方案,客户端接收到服务端的请求后,利用传统解密算法对报文进行解密,把ID和公开密钥存储在客户端本地。
作为本发明所述实现HTTP协议安全传输的方法的一种优选方案,客户端在后续发送请求报文时,利用服务端的公开密钥对数据进行加密,并额外附加会话标识ID一并发送的服务端。
作为本发明所述实现HTTP协议安全传输的方法的一种优选方案,服务端收到报文后,从中提取会话标识ID,在本地提取私有密钥,对报文进行解密后,再做后续的业务操作。
作为本发明所述实现HTTP协议安全传输的方法的一种优选方案,在后续双方通信的工程中,服务端根据一定策略更换密钥。
作为本发明所述实现HTTP协议安全传输的方法的一种优选方案,所述S3中第一种方式:服务端下发公开密钥,具体过程如下:
(1)http协议客户端首次向服务端发送请求信息时,服务端会生成一对私有和公开密码,并把公开密钥发送给客户端;
(2)http客户端后续发送数据给服务端都会利用公开密钥进行加密,然后发送;服务端利用私有密钥对数据进行解密;
(3)在一个会话周期内,服务端可以通知客户端可以随时更换公开密码;
第二种方式:客户端和服务端都各生成一对公开和私有密钥
(1)客户端首次向服务端发送请求的同时携带一个公开密钥;
(2)服务端响应客户端请求时,生成一对密钥;利用客户端的公开密匙进行加密,把数据传输到客户端;
(3)客户端收到数据,利用私有密钥进行解密,实现双方的通信;
(4)在一个会话周期内,服务端可以通知客户端可以随时更换公开密码。
作为本发明所述实现HTTP协议安全传输的方法的一种优选方案,所述S4中HTTP协议报文中请求体的内容;只对动态数据进行加密,而对于静态资源不加密,可以提高运行速度。
本发明的有益效果:(1)简单性;该方法只是在HTTP协议传输过程中,增加了对数据进行进行加密一些简单的扩展,没有增加web应用开发和部署的复杂性;
(2)web部署无费用:本发明虽然采用非对称加密技术,不需要第三方发放证书,因此不存在收费情况,可以降低现有web部署的费用;
(3)传输安全性得到一定程度保证,由于双方是通过公开的密钥进行加密传输,中间者截获数据,也难以进行破解。
附图说明
为了更清楚地说明本发明实施例的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其它的附图。
其中:
图1为本发明提供的一种实施例所述实现HTTP协议安全传输的方法的方法步骤流程图;
图2为本发明提供的一种实施例所述实现HTTP协议安全传输的方法的只有服务端生成一对非对称秘钥方式的示意图;
图3为本发明提供的一种实施例所述实现HTTP协议安全传输的方法的服务端与客户端各自生成一对非对称秘钥方式的示意图;
图4为本发明提供的一种实施例所述实现HTTP协议安全传输的方法的web服务典型业务示意图。
具体实施方式
为使本发明的上述目的、特征和优点能够更加明显易懂,下面结合说明书附图对本发明的具体实施方式做详细的说明。
在下面的描述中阐述了很多具体细节以便于充分理解本发明,但是本发明还可以采用其他不同于在此描述的其它方式来实施,本领域技术人员可以在不违背本发明内涵的情况下做类似推广,因此本发明不受下面公开的具体实施例的限制。
其次,本发明结合示意图进行详细描述,在详述本发明实施例时,为便于说明,表示器件结构的剖面图会不依一般比例作局部放大,而且所述示意图只是示例,其在此不应限制本发明保护的范围。此外,在实际制作中应包含长度、宽度及深度的三维空间尺寸。
再其次,此处所称的“一个实施例”或“实施例”是指可包含于本发明至少一个实现方式中的特定特征、结构或特性。在本说明书中不同地方出现的“在一个实施例中”并非均指同一个实施例,也不是单独的或选择性的与其他实施例互相排斥的实施例。
实施例1
参照图1-4,本发明第一个实施例,该实施例提供了一种实现HTTP协议安全传输的方法,其特征在于,包括以下步骤:
S1、数据传输是采用非对称密钥机制;
本发明的第一个实施例采用非对称加密算法实现双方的加密通信,进而保证数据的可靠性。对于浏览器直接访问web服务器的场景,由于浏览器计算能力要弱一些,可以采用客户端在首次请求服务端时,申请获取服务端的公开密钥和会话标识ID。
S2、双方通信不需要经过CA进行认证;
根据本发明的第一个实施例采用非对称密钥体系应用到HTTP现有的协议之上,可以避免CA证书的费用。在部署HTTPS协议时,需要使用数字证书来加密和认证传输的数据。数字证书是由证书颁发机构(CA,Certificate Authority)颁发的,它们使用数字签名和公钥机密来验证证书的真实性。企业需要向CA购买为其颁布数字证书,因此会产生一些费用。
数字证书的费用取决于证书的类型、颁发机构、证书的有效期和需要覆盖的域名数量。一般来说,基于域名的证书(Domain Validated,DV)是最简单和最便宜的证书类型,它们只覆盖一个域名,并验证该域名是否由申请者拥有。在大多数情况下,DV证书的费用非常低廉,只需几十到数百美元不等。企业可以选择自己的CA颁发证书来减少成本,但这需要更多的技术知识和工程实施。更高级别的证书类型,如组织验证(OrganizationValidation,OV)和扩展验证(Extended Validation,EV)证书,需要更多的审核和验证,因此成本更高。OV和EV证书的费用通常是数百到数千美元不等,并与所需的审核和验证程度成正比。此外,企业还需要定期更新数字证书,以确保其有效性和安全性。证书的有效期可以是几个月到几年。保持证书的有效性可以通过自动化证书管理和续订机制来减少企业的管理成本。
S3、采用服务端下发公开密钥及客户端和服务端都各生成一对公开和私有密钥的两种方式;具体的,本协议可以采用两种方式进行部署:第一种方式:服务端下发公开密钥,具体过程如下:(1)http协议客户端首次向服务端发送请求信息时,服务端会生成一对私有和公开密码,并把公开密钥发送给客户端;(2)http客户端后续发送数据给服务端都会利用公开密钥进行加密,然后发送;服务端利用私有密钥对数据进行解密;(3)在一个会话周期内,服务端可以通知客户端可以随时更换公开密码;
第二种方式:客户端和服务端都各生成一对公开和私有密钥;
(1)客户端首次向服务端发送请求的同时携带一个公开密钥;
(2)服务端响应客户端请求时,生成一对密钥;利用客户端的公开密钥进行加密,把数据传输到客户端;
(3)客户端收到数据,利用私有密钥进行解密,实现双方的通信;
(4)在一个会话周期内,服务端可以通知客户端可以随时更换公开密码;
S4、在实际应用场景中,可以根据应用需要加密不同的数据;(1)HTTP协议(请求/响应)报文中请求体(或是响应体)的内容;
(2)只对动态数据进行加密,而对于静态资源(HTML,CSS,jpg等)不加密,可以提高运行速度。
采用HTTPS协议,它是基于HTTP协议的安全版本,通过使用SSL(Secure SocketsLayer)或TLS(Transport Layer Security)协议来保护在网络上传输的数据的安全性。(1)明文传输:HTTP协议默认使用明文传输数据,这意味着网络中的攻击者可以截取和查看传输的数据。这使得信息泄露和隐私泄露成为可能。
(2)不安全性:由于HTTP协议缺乏安全性,无法对传输的数据进行加密和认证。使得HTTP易受网络攻击,例如中间人攻击、数据篡改和会话劫持。
S5、web服务端与每个客户端保持一对密钥;具体的,每个证书都具有两个密钥:一个私钥和一个公钥,并且这两个密钥称为一个“交换密钥对”。简言之,只有证书的所有者知道私钥,而公钥则可以从证书中读取。这两个密钥都可用来加密和解密摘要、哈希或其他密钥,但它们只能用于相反的操作。例如,如果客户端使用公钥加密,则只有网站可以使用私钥对消息进行解密。同样,如果网站使用私钥加密,则客户端可以使用公钥解密。这可以使客户端确信只与私钥的拥有者交换消息,因为只有使用私钥加密的消息才可以使用公钥进行解密。而网站可以确信它正在与已经使用公钥加密的客户端交换消息。然而,这种交换仅对初次握手是安全的,因此在创建实际的对称密钥时要复杂得多。尽管如此,所有通信都依赖于服务具有有效的SSL证书。会话密钥还被描述为对称密钥,或“共享秘密”。具有对称密钥很重要,因为它减少了事务双方所需执行的计算量。如果每个消息都要求对Nonce和哈希进行新的交换,那么性能将会下降。因此,SSL的最终目标是使用允许消息在通信双方之间自由流动的对称密钥,同时具有更高程度的安全和效率。
S6、一旦一个会话结束后,或是客户端与服务端无交互时间超过了设定时间,服务端会自动销毁密钥;具体的,当用户第一次访问该站点时,SSL机制启动一系列与用户客户端(在此情况下为Web浏览器)的协商,称为“握手”。SSL首先向客户证明银行网站的身份。这一步骤是必需的,因为客户首先必须知道他们正在与真实网站进行通信,而不是与一个试图引诱他们键入自己的用户名和密码的诈骗网站进行通信。SSL通过使用由受信任的颁发机构(例如VeriSign)提供的SSL证书来执行此身份验证。其逻辑如下:VeriSign担保该银行网站的身份是真实的。由于浏览器信任VeriSign,因此也信任该站点。如果您希望向VeriSign进行核实,可以通过单击VeriSign徽标执行此操作。这将显示一份含有到期日期以及接受方(银行网站)的真实性声明。若要启动一个安全会话,客户端向服务器发送一个等效于“你好”的项,连同一个它可以用来签名、生成哈希以及进行加密和解密的加密算法列表。作为响应,该网站发送回一个确认以及它对算法套件之一的选择。在该初次握手期间,双方都发送和接收Nonce。“Nonce”是一段随机生成的数据,该数据与站点的公钥一起使用以创建哈希。“哈希”是使用某种标准算法(例如SHA1)从两个数得到的一个新数。(客户端和网站还交换消息以协商要使用的哈希算法。)哈希是唯一的,并且仅在客户端和网站之间的会话中使用,以便对消息进行加密和解密。客户端和服务都具有原始Nonce和证书的公钥,所以通信两端可以生成同一个哈希。因此,客户端可以通过以下方式验证服务所发送的哈希:(a)使用商定的算法根据数据计算哈希;并(b)将计算出的哈希与服务所发送的哈希进行比较。如果二者匹配,则客户端可以确信该哈希未遭篡改。客户端随后可以将此哈希用作密钥,以便对同时包含另一个新哈希的消息进行加密。服务可以使用此哈希对消息进行解密,并重新获得倒数第二个哈希。这样,通信双方就都获知累积的信息(Nonce、公钥和其他数据),并且可以创建最后一个哈希(也称主密钥)。这个最终的密钥使用倒数第二个哈希加密后发送。然后,使用主密钥对会话其余部分的消息进行加密和解密。由于客户端和服务都使用同一密钥,因此该密钥又称为“会话密钥”。会话密钥还被描述为对称密钥,或“共享秘密”。具有对称密钥很重要,因为它减少了事务双方所需执行的计算量。如果每个消息都要求对Nonce和哈希进行新的交换,那么性能将会下降。因此,SSL的最终目标是使用允许消息在通信双方之间自由流动的对称密钥,同时具有更高程度的安全和效率。因为协议可能因网站而异,所以前面的描述只是所发生过程的简化版本。还有一种可能,就是客户端和网站都在握手期间生成在算法上相结合的Nonce,以增加数据交换过程的复杂性,从而为该过程提供更多的保护。服务端接收请求时,做如下操作:3.1在判断会话是否新的会话,不是新会话则直接回送已有的密钥和ID;否则进入3.2;
3.2创建会话机制,生成一个标识该会话的唯一ID;
3.3利用非对称密钥算法生成一对密钥,建立ID和密钥的映射关系存储的本地,每个会话是使用的密钥都是独立生成的。
3.4以传统加密算法对公开密钥和会话标识ID进行加密,向客户端发送响应报文,报文含有服务端公开密钥和会话标识ID的密文;
客户端接收到服务端的请求后,利用传统解密算法对报文进行解密,把ID和公开密钥存储在客户端本地;客户端在后续发送请求报文时,利用服务端的公开密钥对数据进行加密,并额外附加会话标识ID一并发送的服务端;服务端收到报文后,从中提取会话标识ID,在本地提取私有密钥,对报文进行解密后,再做后续的业务操作;在后续双方通信的工程中,服务端可以根据一定策略(间隔一定时间),更换密钥。
S7、服务端或客户端在发送公开密钥给对方时,采用非对称加密算法实现双方的加密通信进行传输。具体的,其中,非对称加密算法包括但不限于RSA算法、DSA算法及ECC算法。对于采用一些APP应用采用RPC调用方式,由于APP本地具有一定的计算能力,可以双方都各自生成一对非对称秘钥进行通信,区别就是客户端也会生成密钥对,然后把公钥发送给服务端,其他过程都是一样的。
本发明应用于web服务一个典型应用——用户登录,交互过程,如图4所示:
(1)客户端发起HTTP请求,请求登录页面;
(2)服务端响应请求,回送登录页面HTML文件;
(3)浏览器解析HTML时,发送HTTP请求,获取服务端的公开密钥
(4)服务端收到请求后,在本地利用非对称密钥体系生成一对密钥,同时生成一个唯一ID(标识这个客户端),也可以用
sessionID(但是有的web服务部署是前后端分离,sessionID是不匹配的),建立两者映射关系;通过HTTP响应报文把ID和公开密钥发送到客户端;
(5)客户端接收ID和密钥后,对账号和密码进行加密,通过HTTP协议请求报文,送到服务端;
(6)服务端对接收到数据,通过ID和密钥的对应关系,取出私有密钥进行解密,再进行后续业务层操作,并把最终结果回送给客户端。
通过本发明,可以发现客户端和服务端数据交互过程中,被第三方截获,也是可以保证客户端发送的数据不会被泄露,除非客户端请求的钓鱼网站。服务端发送给客户端的数据,存在一定泄露风险,主要是服务端的公开密钥被获取。这个问题,可以通过web应用开发时,在客户端与服务端设定密钥动态更新机制,就可以很大程度降低该类风险。
基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。为了提供示例性实施方案的简练描述,可以不描述实际实施方案的所有特征(即,与当前考虑的执行本发明的最佳模式不相关的那些特征,或于实现本发明不相关的那些特征)。
应理解的是,在任何实际实施方式的开发过程中,如在任何工程或设计项目中,可做出大量的具体实施方式决定。这样的开发努力可能是复杂的且耗时的,但对于那些得益于此公开内容的普通技术人员来说,不需要过多实验,所述开发努力将是一个设计、制造和生产的常规工作。
应说明的是,以上实施例仅用以说明本发明的技术方案而非限制,尽管参照较佳实施例对本发明进行了详细说明,本领域的普通技术人员应当理解,可以对本发明的技术方案进行修改或者同替换,而不脱离本发明技术方案的精神和范围,其均应涵盖在本发明的权利要求范围当中。

Claims (9)

1.一种实现HTTP协议安全传输的方法,其特征在于,包括以下步骤:
S1、数据传输是采用非对称密钥机制;
S2、双方通信不需要经过CA进行认证;
S3、采用服务端下发公开密钥及客户端和服务端都各生成一对公开和私有密钥的两种方式;
S4、在实际应用场景中,根据应用需要加密不同的数据;
S5、web服务端与每个客户端保持一对密钥;
S6、一个会话结束后,客户端与服务端无交互时间超过了设定时间,服务端会自动销毁密钥;
S7、服务端及客户端在发送公开密钥给对方时,采用非对称加密算法实现双方的加密通信进行传输。
2.根据权利要求1所述的实现HTTP协议安全传输的方法,其特征在于:所述客户端在首次请求服务端时,申请获取服务端的公开密钥和会话标识ID。
3.根据权利要求1所述的实现HTTP协议安全传输的方法,其特征在于:所述服务端接收请求时,做如下操作:
3.1在判断会话是否新的会话,不是新会话则直接回送已有的密钥和ID;否则进入3.2;
3.2创建会话机制,生成一个标识该会话的唯一ID;
3.3利用非对称密钥算法生成一对密钥,建立ID和密钥的映射关系存储的本地,每个会话是使用的密钥都是独立生成的;
3.4以传统加密算法对公开密钥和会话标识ID进行加密,向客户端发送响应报文,报文含有服务端公开密钥和会话标识ID的密文。
4.根据权利要求1所述的实现HTTP协议安全传输的方法,其特征在于:客户端接收到服务端的请求后,利用传统解密算法对报文进行解密,把ID和公开密钥存储在客户端本地。
5.根据权利要求1所述的实现HTTP协议安全传输的方法,其特征在于:客户端在后续发送请求报文时,利用服务端的公开密钥对数据进行加密,并额外附加会话标识ID一并发送的服务端。
6.根据权利要求1所述的实现HTTP协议安全传输的方法,其特征在于:服务端收到报文后,从中提取会话标识ID,在本地提取私有密钥,对报文进行解密后,再做后续的业务操作。
7.根据权利要求1所述的实现HTTP协议安全传输的方法,其特征在于:在后续双方通信的工程中,服务端根据策略更换密钥。
8.根据权利要求1所述的实现HTTP协议安全传输的方法,其特征在于:所述S3中第一种方式:服务端下发公开密钥,具体过程如下:
(1)http协议客户端首次向服务端发送请求信息时,服务端会生成一对私有和公开密码,并把公开密钥发送给客户端;
(2)http客户端后续发送数据给服务端都会利用公开密钥进行加密,然后发送;服务端利用私有密钥对数据进行解密;
(3)在一个会话周期内,服务端可以通知客户端可以随时更换公开密码;
第二种方式:客户端和服务端都各生成一对公开和私有密钥
(1)客户端首次向服务端发送请求的同时携带一个公开密钥;
(2)服务端响应客户端请求时,生成一对密钥;利用客户端的公开密匙进行加密,把数据传输到客户端;
(3)客户端收到数据,利用私有密钥进行解密,实现双方的通信;
(4)在一个会话周期内,服务端可以通知客户端可以随时更换公开密码。
9.根据权利要求1所述的实现HTTP协议安全传输的方法,其特征在于:所述S4中HTTP协议报文中请求体的内容;只对动态数据进行加密,而对于静态资源不加密,提高运行速度。
CN202311665526.7A 2023-12-06 2023-12-06 一种实现http协议安全传输的方法 Pending CN117527421A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311665526.7A CN117527421A (zh) 2023-12-06 2023-12-06 一种实现http协议安全传输的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311665526.7A CN117527421A (zh) 2023-12-06 2023-12-06 一种实现http协议安全传输的方法

Publications (1)

Publication Number Publication Date
CN117527421A true CN117527421A (zh) 2024-02-06

Family

ID=89751255

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311665526.7A Pending CN117527421A (zh) 2023-12-06 2023-12-06 一种实现http协议安全传输的方法

Country Status (1)

Country Link
CN (1) CN117527421A (zh)

Similar Documents

Publication Publication Date Title
CA2446304C (en) Use and generation of a session key in a secure socket layer connection
US6985953B1 (en) System and apparatus for storage and transfer of secure data on web
JP5599910B2 (ja) 暗号証拠の再検証に基づく認証委任
EP1714422B1 (en) Establishing a secure context for communicating messages between computer systems
US8799981B2 (en) Privacy protection system
EP1697818B1 (en) Authentication system for networked computer applications
EP2020797B1 (en) Client-server Opaque token passing apparatus and method
JP2001511982A (ja) 秘密保持性の遠隔命令を実行するための方法
CN113225302B (zh) 一种基于代理重加密的数据共享系统及方法
Bhiogade Secure socket layer
WO2018030289A1 (ja) Ssl通信システム、クライアント、サーバ、ssl通信方法、コンピュータプログラム
WO2008020991A2 (en) Notarized federated identity management
Persiano et al. User privacy issues regarding certificates and the TLS protocol: the design and implementation of the SPSL protocol
CN117527421A (zh) 一种实现http协议安全传输的方法
CN111935164A (zh) 一种https接口请求方法
Goodrich et al. Notarized federated ID management and authentication
Téllez et al. Security in mobile payment systems
JP2014081887A (ja) セキュアシングルサインオン方式およびプログラム
Joshi Kerberos Security in Distributed Systems
CA3231904A1 (en) System and method of creating symmetric keys using elliptic curve cryptography
AU2002259074B2 (en) Use and generation of a session key in a secure socket layer connection
Renu et al. INTERNATIONAL JOURNAL OF ENGINEERING SCIENCES & RESEARCH TECHNOLOGY A Noval Approach on Online Transaction Protocols
Chouhan et al. Privacy Preservation and Data Security on Internet Using Mutual SSL
Rao A Fixed Network Transmission Based on Kerberos Authentication Protocol
Longjun et al. A trusted third party based secure authentication scheme of E-commerce

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication