WO2015022701A2

WO2015022701A2 - Method and system of routing and handover of secure communication without knowledge of private/secret key

Info

Publication number: WO2015022701A2
Application number: PCT/IN2014/000519
Authority: WO
Inventors: Arun RAGURAMAN; Jitender SHARAN; Abhishek Kumar SHRIVASTAVA
Original assignee: Ciphergraph Networks Private Limited
Priority date: 2013-08-12
Filing date: 2014-08-08
Publication date: 2015-02-19
Also published as: WO2015022701A3

Abstract

A method and system tosecurely connect with a Web server via a Security server over a communication network between a browser and the Web server is disclosed. The method comprises the Security server acting as SSL session negotiator and receives a request to connect with the Web server from the browser. Further, the Security server negotiates a secure session with the Web server based on the request received; and thus hands over the secure session to the Web server through an independent secure back-end channel. Once the hand shake is completed a secure connection between the browser and the Web server is established through the secure session. This protects the Web server from the risk of being exposed and losing the private key to hackers, thus compromising the data security as well as content to unauthorized users impersonating as genuine users.

Description

METHOD AND SYSTEM OF ROUTING AND HANDOVER OF SECURE

COMMUNICATION WITHOUT KNOWLEDGE OF PRIVATE/SECRET KEY

FIELD OF INVENTION

[0001] The present invention is generally related to a method and system for connecting to a Web serverin a secured mannerand is more particularly related to the method and systemof establishing a connection securely between a Web server and a web browser via a Security server.

BACKGROU N D

[0002] Generally, users across the world connect with the Internet using browsers installed on their machines (typically referred to as client) to destination resources present on the Internet. The destination may be a Bank website, Email website, any other website having resources of interest to the user. The communication links between the user's devices or the client and Web servers are secured by encryption. To establish an encrypted channel, the client and the Web server must negotiate an encryption key. This exposes the client to a man-in-the- middle attack where an attacker capable of intercepting communications can impersonate the Web server in question, and record the information sent and received by the client.Hence the communication links between the client and the Web server are not completely secure.

[0003] To make an environment secure, one must be sure that any communication is with

"trusted" Web servers whose identity the user can be sure of, thus avoidingimpersonation attacks. Generally, the SSL protocol is used for encryption and authentication of the web sites requested. SSL uses certificates for authentication. Certificates are digitally signed documents incorporating two keys known as public key and private key, which together form a unique pair. Data encrypted by the public key can only be decrypted by the corresponding private key, and vice-versa. Authentication happens at connection time, and is independent of the application or the application protocol. The client authenticates a Web server by ensuring that the authentication information presented by the Web server can be validated using the known public key of the Web server, and also sends infonnation to the Web server encrypted with the known public key of the Web server, thus allowing only the Web server in question to decrypt it using its confidential private key. This information exchange leads to the negotiation of a shared secret between client and Web server, which is henceforth used to encrypt all communication at the application protocol level. Compromise of the confidential private key of the Web server can allow an attacker to impersonate the Web server and perform a man-in-the-middle attack to intercept all communication between the client and the web-server.

[0004] Hence, in light of mentioned risk of losing the private key to hackers thus enabling them to setup rogue systems that may masqueradeas genuine sites, what is needed therefore is a system and method that can setup the communication between the Web server and the client while enhancing the security of the confidential private key of the Web server by maintaining it within a high security environment which the Web server cannot provide.

SUMMARY

[0005] The present invention provides a method and system for routing and handover of secure communication without knowledge of private/secret key between a client and a Web server where the client is accessing the Web server to gain access of the resources hosted on the Web server. [0006J In one embodiment of the invention, the user who wishes to access the resources hosted on a Web server sends a request to the Web serverusing the client. The said request between the client and the Web server is routed to a Security server where the Security server negotiates the SSL connection between the client and the Web server using the private key of the Web server. Once the initial handshake is complete between the Security server and the client, the SSL connection is handed over to the Web server through a signaling mechanism by which the Security server communicates the negotiated SSL connection parameters to the Web server, once the SSL connection initial handshake is complete. Thus, once the handover of the communication is complete from the Security server, the Web server stops forwarding traffic to the Security server and terminates all packets locally. The Security server is the repository for the confidential private key of the Web server, and is located in a highly secure environment where the private key can be protected with greater ease than the insecure environment of the Web server. This also allows an organization to allow a different entity (organization or individual) to control, administer, and maintain its Web server without sharing the confidential private key with that entity.

[0007] In one of the implementations of the invention, articles of manufacture are provided as computer program products. One implementation of a computer program product provides a computer program storage medium encoding a computer program that can be read and executed by a computer system. In another implementation of the invention, a computer program product may be provided in a computer data signal embodied in a carrier wave by a computing system and encoding the computer program. [0008] One implementation of the computer program product encodes a computer program to route transparently from a Web server any connection attempt from a browser to a Security server.

[0009] The summary is provided to give a brief idea of the invention and is not intended to be used as a means for limiting the scope of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

[00010] FIG. 1 is a diagram depicting an environment where a web browser connects to a

Web server via a Security server, according to an embodiment of the invention.

[00011] FIG. 2 illustrates communication flow between the web browser and the Web serverthrough a Security server, according to an embodiment of the invention.

[00012]

DETAILED DESCRIPTION

[00013] The exemplary embodiments, described in this section with details, are provided merely to illustrate the principles of the invention. Various details are set forth for the purpose of explanation rather than limitation. However, it will be apparent to a person skilled in the art that the invention can be practiced without these details and the given exemplary embodiments should not be construed as limiting the scope of the invention. Some of the terms as used in the patent application h ave been described below without limiting the scope of the invention.

[00014] Definitions:

[00015] Browser -A web browser (commonly referred to as a browser) is a software application for retrieving, presenting and traversing information resources on the World Wide Web. Although browsers are primarily intended to use the World Wide Web, they can also be used to access information provided by Web servers in private networks or files in file systems. Examples of browserinclude but not limited to Google Chrome™, Mozilla Firefox™, Internet Explorer™, Opera™, and Safari™.

[00016] Web Server - The term Web server can refer to either the hardware (the computer) or the software (the computer application) that helps to deliver web content that can be accessed through the Internet.lt is usually used in a context where it refers to both the hardware and the software as used in conjunction.

[00017] Certificates - Certificates are blocks of data in a format described in ITU-T standard X.509. The X.509 certificates are issued, and digitally signed by an external authority known as a certificate authority and are used to authenticate clients to servers, and servers to clients; the mechanism used is essentially the same in both cases.

[00018] Certificate Authority - In cryptography, certificate authority, or certification authority (CA), is an entity that issues digital certificates. The digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others (relying parties) to rely upon signatures or assertions made by the private key that corresponds to the public key that is certified.

[00019] Handshake - Handshake is an exchange of information that takes place between a client and a server when a connection is established. It is during the handshake that client and server negotiate the encryption algorithms that they will use, and authenticate one another .The handshake allows the server to authenticate itself to the client using public key techniques; this allows the client and the server to cooperate in the creation of symmetric keys used for rapid encryption, decryption, and tamper detection during the session that follows. The handshake also allows the client to authenticate itself to the server.

{00020] Stateful Connection -A stateful connection is one in which some information ("state") about a connection between two systems or servers is retained for future use. In some cases, the connection is kept open even though the two systems might not be transmitting information (i.e., the connection itself retains state). A TCP/SSL connection-oriented session is a stateful connection because both systems maintain information about the session itself during its life.

[00021] SSL-Secure Socket Layer (SSL) is cryptographic protocolthat defines theWeb server and the client authentication and encryption of communications. It uses asymmetric cryptography for authentication of key exchange, symmetric encryption for confidentiality and message authentication codes for message integrity.

[00022] TLS - Transport Security Layer - Is the successor of SSL and is essentially is based on the SSL protocols.

[00023] Security Server- A Security server is a physical computer (a computer hardware system) or a virtual machine (software implementation of a machine that executes programs like a physical machine) dedicated to running an application that is capable of SSL connection negotiation between client and Web server using the Web servers confidential private key, as well as handover of negotiated SSL connections. The embodiments are described below in order to explain the invention by referring to the figures.

[00024] FIG. 1 is a diagram depicting an environment where the invention may be practiced, according to an embodiment of the invention. Illustratively, the environment comprises a client 102 which requests a connection to a Web server 104 through aSecurity server 106 over a communication network 108. The communication network 106 can be the Internet, mobile communication network, 2G, 3G, 4G, 5G, CDMA, GPRS, WLAN, LAN or any other form of communication network that makes the communication feasible between the client 102 and the Web server 104. According to an embodiment of the invention, the communication network 108 is the Internet. The user connects over the Internet using client 102 to a destination resource present on the Internet. The destination resource may be a bank website, email website, shopping website, entertainment portal, any other website that may be in private, public, academic, business, or governmentdomainand having specific web address to be located uniquely on the Internet. The. user uses a browser 110 installed on the client 102 to request connect with the destination resource located over the Web server 104.

[00025] The request in turn is routed to the Security server 106 for initial negotiatio via the Web server 104. This insulates the Web server 104 from being directly involved in the handshake procedure, wherein the handshake procedure involves the private key of the Web server 104 to decrypt the connection signal from the client 102. The Security server 106 acts a security broker and master store of the plurality of private keys for different websites hosted on the Web server 104 along with the Web server 104's certificates. According to an embodiment of the invention, the Security server 106 is a computer application capable of negotiating a stateful connection between the browser 110 and the Web server 104 by using a handshake procedure. It may be noted that negotiation between Security server 106 and the client 102 involves to and fro communication between the client 102 and the Security server 106 over aSecure Socket Layer (SSL) or Transport Layer Security (TLS)cryptographic protocols and uses a standard handshake procedure. SSL/TLS allows the client 102 to confirm a Web server's identity. Further, the web browser 1 10 are SSL/TLS-enabled and can employ standard techniques of public key cryptography to check that theWeb server's 11Θ name and public key are contained in a valid certificate issued by a certificate authority (CA) listed in the client's 102 list of trusted CAs. Moreover, SSL/TLS can encrypt most of the information being transmitted between a browser and a Web server or even between two Web servers. With an appropriate encryption algorithm, SSL/TLS provides a high degree of confidentiality. In addition, all data sent over an encrypted SSL/TLS connection is protected with a mechanism for detecting tampering; that is, for automatically determining if the data has been altered in transit. Further, the meaning and scope of the TLS and SSL protocols as well as handshake procedure,is to be interpreted as understood by a person skilled in the art and the meaning of TLS and SSL protocols in no way limit the scope and spirit of the invention.

[00026] Hence, a SSL/TLS session is initiated by client 102 by exchange of messages called the SSL/TLS handshake. The SSL/TLS handshake messages are though directed towards the Web server 104, the messages are transparently routed to the Security server 106. After the Security serverl06 finishes the initial handshake, it hands over the SSL Session to the Web server 104 by signaling the Web server 102 through an independent secure connection, and providing the Web server 102 with the shared secret and/or other SSL session parameters that have been negotiated with the client 102. Thus, a connection between the client 102 and the Web server 104 is established without involving the Web server 104, thus excluding the Web server 104 from the critical security negotiation process. The details and the steps of the handshake procedure and the handing over of the SSL session by the Security server 106 is explained in conjunction with FIG. 2.

[00027] FIG. 2 illustrates the communication flow between the client 102 and Web server 104 through theSecurity server 106 over the Internet, according to an embodiment of the invention. At step 1, the client 102 sends a request to the Web server 104 to access the resources hosted on the Web server 104. The request to the Web server 104 is equivalent to initiating a SSL session with the Web server 104 for authentication of the Web server 104. Here, the request comprises of SSL version number of the browser 110, cipher settings, session-specific data, and other information that the Web server 104 needs to communicate with the browser 110 using SSL. The SSL version number refers to the version of the SSL protocol being used for encryption. Further, the cipher settings refer to the cipher suites that is supported by the browser 110. It will be apparent to a person skilled in the art that the cipher settings and the SSL version number have their usual meanings and that any other data may be exchanged between the browser 110, the Security server 106 and the Web server 104, that facilitates communication between them in a secured manner.

[00028] The request received at Web server 104 is routed transparentlythrough the Web server 104 to the Security server 106 at the step 2. It will be apparent to a person skilled in the art that the request is routed transparently by using connection-forwarding, routing or Network Address Translation (NAT) mechanisms. Hence, during the initial handshake procedure the Web server 104 acts as a transparent router which simply passes the communication signal from the browser 110 to the Security server 106 and vice-versa.

[00029] The Security server 106 then negotiates with the browser 110 for a stateful connection at step 3 via the Web server 104. The Security server 106 sends the client 102, the SSL version number of the Security server 106, cipher settings, session-specific data, Web server 104 certificateand other information that the client 102 needs to establish secure SSL connection with the Security server 106 over SSL. The Security server 106 also sends its own certificate, and the Security server 106 requests the client certificate of the browser 110 if the client 102 has requested a Web server 104 resource that requires client authentication.The client 102 checks the Web-server's 104 data sent by the Security server 106. Further communication is either flagged with a warning message to the user, aborted or authenticated with exchange of certificates of the browser 110 and the user credentials, depending on the handshake data received from the Security server 106. In case communication by the Security server 106 is authenticated, the client 102, depending on the cipher being used creates the premaster secret for the sessionand encrypts it with the Security server's 106 public key.Further, the client 102 uses the premaster secret, by executing a series of steps to generate amaster secret.

[00030] Next in step 4, the encrypted premaster secret is sent to the Security server 106. If the Security server 106 has requested client authentication the client 102authenticates another piece of data that is unique to handshake and known by both the client 102 and Security server 106. In this case, the client 102 sends both the authenticated or signed piece of data and the client's 102 own certificate to the Security server 106 along with the encrypted premaster secret in the step 4.

[00031] If the client 102 can be successfull y authenticated, the Security server 106 uses its private key to decrypt the premaster secret and then performs a series of steps to generate the master secret.Further, both the client 102 and the Security server 106 use the master secret to generate Session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL/TLS sessionand to verify its integrity— that is, to detect any changes in the data between the time it was sent and the time it is received over the SSL/TLS connection.

[00032] Once the initial handshake is completed, the Security server 106 hands over the SSL session to the- Web server 104, wherein the handing over the secure session to the Web server is executed over an independent secure channel established between the Security server 106 and the Web server 104. The handover includes communicating the SSL state and the Session key to the Web server 104, initializing the SSL Context on Web server 104, communicating a TCP Session state with the Web server 104 and initializing TCP Connection State on the Web server 104.

[00033] The Web server 104 creates the TCP session state or a connection in the network subsystem and SSL Context within the SSL framework required for communication. Hence, as the Web server 104 has successful handover, the Web server 104 stops forwarding traffic to the Security server 106 and terminates all packets received by the client 102 locally. A communication between Web server 104 and the client 102 is thus established at step 6, whereby all further communications between the client 102 and the Web server 104 happen directly using the Session keys generated in the handshake of the Security server 106 and the client 102. The client 102 and the Web server 104 use the Session keys to encrypt and decrypt the data they send to each other and to validate its integrity The steps described in the specification in conjunction with the FIGs 1 and 2 of the aforesaid invention, thus makes the Web server 104 secure from attackers and eaves-droppers.

[00034] The embodiments of the invention described above are intended for the purpose of illustration only. Numerous modifications, changes, variations, substitutions and equivalents will be apparent to those skilled in the art without departing from the spirit and scope of the invention as described in the claims.

Claims

Claims:

1. A method to securely connect with a Web server via a Security server over a communication network between a browser and the Web server, the method comprising the Security server:

a) receiving a request to connect with the Web server from the browser;

b) negotiating a secure session with the Web server based on the request received; and c) handing over the secure session to the Web server, wherein a secure connection between the browser and the Web server is established through the secure session.

2. The method as recited in claim 1 , wherein the request to connect with the Web server comprises browser's SSL version number, cipher settings, session-specific data, and other information that the Web server needs to communicate with the browser using SSL.

3. The method as recited in claim 1, wherein the step of negotiating the secure session further comprises the Security server generating a symmetric Session key using public key cryptography and the private key for the Web server certificate.

4. The method as recited in claim 1 and claim 2, wherein the step of negotiating the secure session further comprises initial handshake between the browser and the Security server using SSL, wherein the initial handshake is based on the information received from the browser.

5. The method as recited in claims 1 and 4, wherein the step of handing over the secure session to the Web server further comprises setting up of the SSL state, Session key and TCP session state on the Web server using SSL, wherein the SSL state, Session key and the TCP session state are determined by the Security server based on the data generated in the initial handshake.

6. The method as recited in claim 1 and 5, wherein thehanding over the secure session to the Web server is executed over an independent secure channel established between the Security server and the Web server.

7. A method to securely connect with a Web server via a Security server over a communication network between a browser and the Web server, the method comprising:

a) receiving a request to connect to the Web server, wherein the request is received from the browser;

b) routing the request to the Security server for an initial handshake;

c) theSecurity server negotiating a secure session with the browseron the request received; and d) handing over the secure session to the Web server, thereby establishing a secure connection between the browser and the Web server.

8. The method as recited in claim 7, wherein the request to connect with the Web server comprises browser's SSL version number, cipher settings, session-specific data, and other information that the Web server needs to communicate with the browser using SSL.

9. The method as recited in claim 7, wherein the step of negotiating the secure session further comprises the Security server generating a symmetric Session key using public key cryptography and the private key for the Web server certificate.

10. The method as recited in claim 7 and claim 8, wherein the step of negotiating the secure session further comprises initial handshake between the browser and the Security server using SSL, wherein the initial handshake is based on the information received from the browser.

11. The method as recited in claims 7 and 10, wherein the step of handing over the secure session to the Web server further comprises setting up of the SSL state, Session key and TCP session state on the Web server using SSL, wherein the SSL state, Session key and the TCP session state are determined by the Security server based on the data generated in the initial handshake.

12. The method as recited in claim 7 and 11, wherein thehanding over the secure session to the Web server is executed over an independent secure channel established between the Security server and the Web server.

13. A Security server to broker an SSL session and securely connect a Web server to a browser, over a communication network, the Security server:

a) receives a request to connect with the Web server from the browser;

b) negotiates a secure session with the Web server based on the request received; and

c) hands over the secure session to the Web server, wherein a secure connection between the browser and the Web server is established through the secure session using SSL.