Note: Descriptions are shown in the official language in which they were submitted.
CA 02467988 2004-05-21
SYSTEM AND METHOD FOR INITIATING SECURE
NETWORK CONNECTION FROM A CLIENT TO A NETWORK HOST
Field of the Invention
This invention relates to electronic mail systems, and more particularly, this
invention relates to providing a secure network connection from a client to a
network host.
Background of the Invention
When dealing with sensitive data, it is a real-world requirement that all
transmission of sensitive data over a public network, such as the internet, be
conducted
over a secured communications channel. The defacto standard for a secured
communications channel over the internet is an encrypted transmission control
protocol
(TCP) connection known as Secure Sockets Layer (SSL), or alternatively, as the
Transport
Layer Security (TLS) protocol. The SSL protocol operates above the Transport
Control
Protocol/Internet Protocol (TCP/IP) layer, but below the Hypertext Transfer
Protocol
(HTTP). SSL establishes a secure session between a web client and server and
encrypts
all data passed between the client and server at the IP socket level.
In secure communications using SSL protocol, browsers and servers authenticate
each other and encrypt any data transmitted during a session. A client can
verify that a
web server is authentic before it submits confidential information, and a web
server can
verify a user is authentic before granting a user access to sensitive
information. Digital
certificates could be required. Usually, a one-way authentication is only
required for the
client or server to obtain a key to encrypt data. For example, a client could
contact the
server, which forwards a certificate signed by a certificate of authority. The
client could
use the web server's public key to open the certificate.
SSL uses a handshake protocol and record protocol. The record protocol defines
the format for transmitting data. The handshake protocol establishes the SSL
connection
and determines the parameters used during the communication, including what is
required
to authenticate a server to a client. It also could allow a client and a
server to select a
cryptographic algorithm or cipher to support or authenticate a client to a
server and use
public key encryption techniques to generate shared secrets and establish a
secured
connection.
1
CA 02467988 2004-05-21
Adding SSL support to existing and new applications can be difficult or
impossible
depending on various factors. For example, on certain computing platforms, it
is not
possible to use advanced, high performance features, such as multiplexed
asynchronous
input/output and SSL in the same application. Some prior art proposals "wrap"
an SSL
layer around inbound connections to a well-known network location. There are,
however,
no corresponding solutions to secure outbound connections to arbitrary network
locations.
One proposal set forth in published U.S. patent application no. 2002/0199098
receives encrypted network traffic and forwards the decrypted results to a
server. An SSL
proxy server is positioned close to the server, for example, as part of the
same computing
cluster, to handle inbound connections. The SSL proxy server decrypts traffic
and
forwards the decrypted package to a predetermined location. The system is
limited to
preconfigured destinations. Published U.S. patent application nos.
2003/0014623 and
2003/0014628 propose similar solutions. A client sends encrypted packets to a
proxy,
which decrypts them, forwards the package to the server, and reverses the
process for
unencrypted packets from the server back to the client.
These proposals are not acceptable if a client can only transmit unencrypted
packets.
Summary of the Invention
It is therefore an object of the present invention to provide a system and
method
that allows a client unable to encrypt data to establish a secure connection
with a server
that is able to communicate over a secured network connection.
The present invention allows a client computer that is not operable to
initiate an
SSL session on its own to establish a secure connection with a host, such as a
POP, IMAP
or web server, even though there are no preconfigured limitations on the
destination of the
connection. As part of the initiation sequence of an outbound connection, a
client first
privately communicates the destination host name and internet protocol (IP)
port number
to an SSL proxy. As a result, there is no requirement to preconfigure any
destination for
forwarded packets. The SSL proxy is not initially transparent and requires the
client to
communicate a desired destination to the SSL proxy. The client sends
unencrypted
packets. The SSL proxy encrypts the packets and forwards these encrypted
packets to the
arbitrary server specified at the time the unencrypted connection is
established.
2
CA 02467988 2009-11-17
In accordance with one aspect of the present invention, a system of the
present
invention is operable for initiating a secure network connection when a client
is operable
for transmitting only unencrypted data. A network server is operable to
receive data from
the client and operable to communicate with clients in a secure manner. A
proxy is
connected to the client and operable for receiving unencrypted data from the
client and
encrypting the data using the Secure Sockets Layer (SSL) protocol and
forwarding the
encrypted data to the network server. The client is typically operable for
transmitting only
unencrypted data to the designated network host through a designated internet
protocol
(IP) port number of the network host. The proxy is connected to the client and
close to the
client such as part of a data center and receives from the client the
unencrypted data, a
destination host name for the network host to be communicated, and the
internet protocol
(IP) port number.
In another aspect of the present invention, the SSL protocol comprises a
transport
layer security (TLS) protocol. The data transmitted from the client is
typically
unencrypted text data. The proxy is typically a proxy server and closely
associated with
the client. The proxy is operative for establishing a Transport Control
Protocol (TCP),
end-to-end connection between the client and the host, such as a network
server. The host
as a network server typically could be a POP, IMAP or web server, but could be
other
server types. The proxy is typically operative for closing its connection with
one of the
server or client after one of the server or client closes its connection. The
client could be
formed as a mobile device.
In yet another aspect of the invention, there is provided a system for
initiating a
secure network connection comprising a client operable for transmitting only
unencrypted
data; a network server operable to receive data from the client and operable
to
communicate in a secure manner; and a proxy connected to the client and
operable for
receiving unencrypted data from the client and encrypting the data using
secure sockets
layer (SSL) protocol and forwarding the encrypted data to the network server
on a
designated port number based on a destination host name and port number
provided by the
client to the proxy.
In yet another aspect, there is provided a system for initiating a secure
network
connection between a client and network host comprising a client operable for
transmitting
only unencrypted data to a designated network host through a designated
internet protocol
(IP) port number of the network host; and a proxy connected to the client and
operable for
3
CA 02467988 2009-11-17
receiving from the client the unencrypted data, a destination host name for
the network
host, and internet protocol (IP) port number, and encrypting the data using
secure sockets
layer (SSL) protocol and forwarding the encrypted data to the network host on
a
designated port number based on a destination host name and port number
provided by the
client to the proxy.
In yet another aspect, there is provided a system for initiating a secure
network
connection between a client and network host comprising a client operable for
transmitting
only unencrypted data to a designated network host through a designated
internet protocol
(IP) port number of the network host; and a proxy connected to the client and
operable for
receiving from the client the unencrypted data, a destination host name for
the network
host, and internet protocol (IP) port number and encrypting the data using
secure sockets
layer (SSL) protocol, and forwarding the encrypted data to the network host on
a
designated port number based on a destination host name and port number
provided by the
client to the proxy, said proxy also operative for receiving encrypted data
from the
network host and decrypting the data for transmission to the client.
In yet another aspect, there is provided a method for initiating a secure
network
connection comprising the steps of receiving at a proxy connected to a client
unsecured
data from the client wherein the client is operable for transmitting only
unencrypted data;
and initiating a secure connection from the proxy to a designed network host
using secure
sockets layer (SSL) protocol and forwarding the encrypted data to the network
host on a
designated port number based on a destination host name and port number
provided by the
client to the proxy.
In yet another aspect of the invention, there is provided a method for
initiating a
secure network connection comprising the steps of receiving at a proxy from a
client that
can transmit only unencrypted data as unsecured data, a destination host name
location for
a desired network host server, and a designated internet protocol (IP) port
number for
communication therewith; and initiating a secure connection from the proxy to
the desired
network host using secure sockets layer (SSL) protocol via the designated port
number and
forwarding encrypted data to a network server on a designated port number
based on a
destination host name and port number provided by the client to the proxy.
In yet another aspect, there is provided a method for initiating a secure
network
connection comprising the steps of receiving at a proxy unsecured data from a
client that is
operable for transmitting only unencrypted data; initiating a secure
connection from the
3a
CA 02467988 2009-11-17
proxy to a network host using secure sockets layer (SSL) protocol on a
designated port
number based on a destination host name and port number provided by the client
to the
proxy; receiving at the proxy secure data in a SSL protocol from the network
host;
decrypting the secure data at the proxy; and transmitting the decrypted data
from the proxy
to the client based on a destination host name and port number provided by the
client to
the proxy.
A method aspect of the invention is also set forth in detail.
Brief Description of the Drawings
Other objects, features and advantages of the present invention will become
apparent from the detailed description of the invention which follows, when
considered in
light of the accompanying drawings in which:
FIG. 1 is a block diagram showing prior art client-server encrypted
communications, for example, by using Secure Sockets Layer (SSL) protocol.
FIG. 2 is a block diagram showing use of a prior art, SSL proxy for port 993
and
IMAP4 over SSL in a 443 port connection using the internet mail access
protocol (IMAP).
3b
CA 02467988 2004-05-21
FIG. 3 is a block diagram showing the SSL proxy in the system of the present
invention, which allows a plaintext client to initiate a secure connection
with an arbitrary
host.
FIG. 4 is a high level flow chart illustrating an example of the method of the
present invention.
FIG. 5 is a more detailed flow chart illustrating an example of the sequence
and
steps for initiating a secure connection with a host from a client that is
operable for
transmitting only unencrypted data.
FIG. 6 is a schematic block diagram illustrating an exemplary mobile wireless
communications device for use in the present invention.
Detailed Description of the Preferred Embodiments
The present invention will now be described more fully hereinafter with
reference
to the accompanying drawings, in which preferred embodiments of the invention
are
shown. This invention may, however, be embodied in many different forms and
should
not be construed as limited to the embodiments set forth herein. Rather, these
embodiments are provided so that this disclosure will be thorough and
complete, and will
fully convey the scope of the invention to those skilled in the art. Like
numbers refer to
like elements throughout, and prime notation is used to indicate similar
elements in
alternative embodiments.
The present invention provides a system and method that initiates secure
network
connections to arbitrary hosts, in which the client that initiates the
connection typically
does not have the capability to perform encryption and related functions. The
present
invention solves the prior art problem of securing outbound connections to an
arbitrary
network location, such as a network host on a web server, by introducing an
intermediate,
Secure Socket Layer (SSL) enabled proxy server. Rather than attempting to
connect
directly to an SSL network service as in many prior art proposals, in the
present invention,
the client connects to the SSL proxy server that is typically associated close
to the client,
such as part of a data center as a non-limiting example. The client provides
the network
host name and TCP port number to the SSL proxy, which then initiates a secure
connection to the specified network host on the specified TCP port number.
From that
time onward, the SSL proxy is transparent to communications between the client
and the
SSL site, for example, the network server or web server. The SSL proxy can
provide on-
4
CA 02467988 2004-05-21
the-fly encryption of outbound packets and decryption of inbound packets. The
client
application typically only requires a minimal change to its software and can
be maintained
in a more simple manner than other more complicated systems, since it can
continue to do
network communications in plaintext.
The present invention solves the problem associated with many prior art
solutions
and proposals that "wrap" SSL security around a fixed network location. These
prior art
solutions typically work only for network connections to known, fixed network
locations,
and must have fixed network locations pre-programmed into a configuration
before the
solutions are run. When the solutions are running, there is no way to add,
remove, or
change a network destination without stopping the service, reprogramming a
configuration, and restarting the service. There is also no dynamic capability
to initiate a
connection to a run time determined network location. The present invention
can have the
network destination specified at run time because it has no limitation as to
which network
hosts it can communicate with.
FIG. 1 illustrates a prior art secure communications system 10, which
initiates a
secure connection between a client 12 and host, such as a web server or other
service
provider via the internet 16. The client 12 is SSL enabled and establishes an
encrypted
connection to the service provider 14 using a TCP connection via the internet
16. In some
prior art proposals as described above, an SSL proxy is used for buffering or
other
purposes. FIG. 2 shows a prior art SSL proxy 20 and IMAP service 22 that can
communicate via port 993 and port 443 for S-IMAP and IMAP4 over SSL. This type
of
arrangement has been proposed and in use by some providers.
It should be understood that the SSL protocol includes two sub-protocols,
i.e., an
SSL record protocol and SSL handshake protocol. The record protocol defines
the format
to transmit data, and the handshake protocol establishes the connection and
determines the
parameters used during the SSL communication session. The SSL communication
protocol and the SSL handshake protocol can authenticate a server to a client,
allow a
client and server to select a cryptographic algorithm or cipher to support,
authenticate a
client to the server, and use public key encryption techniques to generate
shared secrets
and establish a secured connection.
Some prior art proposals have used an SSL protocol and SSL proxy to receive
encrypted data from a client and provide buffering, such as in published U.S.
patent
application no. 2002/0199098. The SSL proxy, however, still receives encrypted
network
CA 02467988 2009-11-17
traffic from a client and forwards the encrypted results to a server. The SSL
proxy in
these types of proposals are transparent proxies. Clients have no knowledge of
the proxy's
presence.
In the present invention, on the other hand, the SSL proxy is not altogether
transparent and requires the client to communicate a desired destination to
the SSL proxy.
In the present invention, an SSL proxy is designed to be deployed close to the
client, such
as part of a data center for initiating outbound connections, as compared to
the published
publication and other prior art proposals that have SSL proxies deployed close
to the
server, for example, as part of the same computing cluster to handle inbound
connections.
There is also no requirement in the present invention to preconfigure any
destination for
forwarded packets. Also, in most prior art proposals, a client computer is
operable to
initiate an SSL session and send packets with encrypted payloads. In the
present claimed
invention, however, the SSL proxy is specifically designed for client
computers that are
not operable to initiate an SSL session on their own. The present invention
allows a client
to send unencrypted packets, while the SSL proxy encrypts and forwards the
packet to an
arbitrary server specified at the time the encrypted connection is
established.
FIG. 3 is an overall high level block diagram of an example of the system 30
of the
present invention. The internet 32 is the vehicle for encrypted network
connections
between a client 34 and various service providers 36, 38, 40, such as
different network
servers or web servers listed as servicel.com, service2.com and service3.com.
Although
the internet is shown, it should be understood that the present invention is
not limited only
to internet communications, but can be used with different intranets and other
types of
networks. The client 34 in this example has an application that is able to
transmit only
plaintext. The client could be part of a data center 42, which includes the
SSL proxy 44 of
the present invention. Although the SSL proxy 44 is shown as part of the data
center,
which includes the client 34, it should be understood that the SSL proxy 44
does not have
to be part of any client associated data center, but could be part of any
system that is
associated with the client. The present invention would also permit use of
asynchronous
input/output in JAVA programming environment. The client could also be a
wireless,
mobile communications device, such as a hand-held Blackberry unit.
FIG. 4 illustrates a high level block diagram of one example of the method of
the
present invention that can be used with the system shown in FIG. 3. As
illustrated, the
client application opens a socket for communication from the client to the SSL
proxy
6
CA 02467988 2004-05-21
(block 100). The client transmits the destination host name and port number to
the SSL
proxy (block 102), which then opens the SSL connection to the host via the
port (block
104). The SSL proxy shuttles bytes to the host using the SSL connection (block
106).
FIG. 5 illustrates another flow chart and greater details of a representative
example
of the method of the present invention that can be used with the system shown
in FIG. 3.
The client first opens a TCP connection to the SSL proxy (block 110). The
client informs
the SSL proxy which network host and port number is used to initiate a secure
connection
(block 112). The SSL proxy opens a secure connection to the destination host
(block 114).
The SSL proxy is at this point transparent either client or server may send
data to each
other, in any order. There is no requirement that the initial data be sent
from client to
server, although the description will proceed with the client sending data to
the server.
The SSL proxy receives plaintext data from the client during the communication
session
(block 116). It should be understood that plaintext data refers to "not
encrypted." The
SSL proxy encrypts the plaintext data and forwards the encrypted plaintext
data to the
host, for example, a service provider or other web server (block 118). The SSL
proxy
receives encrypted traffic from the service provider, for example, the web
server (block
120). The SSL proxy decrypts the received data from the server (block 122).
The
decrypted data is forwarded to the client (block 124). When the client or
server closes its
respective connection (block 126), the SSL proxy forwards this event by
closing its
corresponding connection (block 128).
It should be understood that the software and programming used for the present
invention can vary, and different applications can be used to accomplish the
purpose and
functions of the present invention. Many types of web service technology can
be used,
including different application services used by those skilled in the art. Web
services
could include a combination of programming and data, which are available from
a web
server for web users, or the use of other web-connected programs as provided
by an
application service provider. Web services could use an extensible mark-up
language
(XML) as a standard for formatting data to be communicated.
Different communication arrangements could be used, including peer-to-peer,
use
of a central server, or other architecture and communication systems,
including
middleware. Data formats could be standardized and data exchanged using an
extensive
mark-up language (XML), which is the foundation for the web services
description
language (WSDL). Different web servers could also be used, including the open
source
7
CA 02467988 2004-05-21
Apache or Microsoft's Internet Information Server (IIS). Other web services
could
include Novell's web server for users of its netware operating system or the
IBM family of
Lotus Domino service, for example, for IBM's OS/390 and AS/400 customers.
Any web server could download requests for File Transfer Protocol (FTP) files.
Different servers could include a Messaging Application Programming Interface
(MAPI)
and provide an Application Programming Interface (API). Configuration data
objects and
format data objects could be generated using an extensible mark-up language
(XML) for
submission to various XML-compliant web services. Any server and web service
could
be a Simple Object Access Protocol (SOAP) compliant service. SOAP would allow
one
program running in one kind of operating system to communicate with a program
in the
same or another type of operating system by using HTTP and XML for information
exchange.
ActiveX controls could be used as Component Object Models (COM) and provide
a framework for building software components that communicate with each other.
ActiveX controls could be automatically downloaded and executed by a web
browser.
Distributed object applications could be built in active web pages and ActiveX
controls
could be downloaded to different browsers and client. ActiveX controls could
be held in a
web browser as a container and distributed over an internet or corporate
intranet. ActiveX
controls could also manage and update web content and client systems and work
closely
with a user interface of a targeted operating system. JAVA objects or similar
component
objects could be used instead of ActiveX controls. An object model control
could also be
any type of Dynamic Link Library (DLL) module that runs in a container.
An exemplary hand-held mobile wireless communications device 1000 that can be
used in the present invention is further described in the example below with
reference to
FIG. 6. The device 1000 includes a housing 1200, a keyboard 1400 and an output
device
1600. The output device shown is a display 1600, which is preferably a full
graphic LCD.
Other types of output devices may alternatively be utilized. A processing
device 1800 is
contained within the housing 1200 and is coupled between the keyboard 1400 and
the
display 1600. The processing device 1800 controls the operation of the display
1600, as
well as the overall operation of the mobile device 1000, in response to
actuation of keys on
the keyboard 1400 by the user.
The housing 1200 may be elongated vertically, or may take on other sizes and
shapes (including clamshell housing structures). The keyboard may include a
mode
8
CA 02467988 2004-05-21
selection key, or other hardware or software for switching between text entry
and
telephony entry.
In addition to the processing device 1800, other parts of the mobile device
1000 are
shown schematically in FIG. 6. These include a communications subsystem 1001;
a short-
range communications subsystem 1020; the keyboard 1400 and the display 1600,
along
with other input/output devices 1060, 1080, 1100 and 1120; as well as memory
devices
1160, 1180 and various other device subsystems 1201. The mobile device 1000 is
preferably a two-way RF communications device having voice and data
communications
capabilities. In addition, the mobile device 1000 preferably has the
capability to
communicate with other computer systems via the Internet.
Operating system software executed by the processing device 1800 is preferably
stored in a persistent store, such as the flash memory 1160, but may be stored
in other
types of memory devices, such as a read only memory (ROM) or similar storage
element.
In addition, system software, specific device applications, or parts thereof,
may be
temporarily loaded into a volatile store, such as the random access memory
(RAM) 1180.
Communications signals received by the mobile device may also be stored in the
RAM
1180.
The processing device 1800, in addition to its operating system functions,
enables
execution of software applications 1300A-1300N on the device 1000. A
predetermined
set of applications that control basic device operations, such as data and
voice
communications 1300A and 1300B, may be installed on the device 1000 during
manufacture. In addition, a personal information manager (PIM) application may
be
installed during manufacture. The PIM is preferably capable of organizing and
managing
data items, such as e-mail, calendar events, voice mails, appointments, and
task items.
The PIM application is also preferably capable of sending and receiving data
items via a
wireless network 1401. Preferably, the PIM data items are seamlessly
integrated,
synchronized and updated via the wireless network 1401 with the device user's
corresponding data items stored or associated with a host computer system.
Communication functions, including data and voice communications, are
performed through the communications subsystem 1001, and possibly through the
short-
range communications subsystem. The communications subsystem 1001 includes a
receiver 1500, a transmitter 1520, and one or more antennas 1540 and 1560. In
addition,
the communications subsystem 1001 also includes a processing module, such as a
digital
9
CA 02467988 2004-05-21
signal processor (DSP) 1580, and local oscillators (LOs) 1601. The specific
design and
implementation of the communications subsystem 1001 is dependent upon the
communications network in which the mobile device 1000 is intended to operate.
For
example, a mobile device 1000 may include a communications subsystem 1001
designed
to operate with the MobitexTM, Data TACTM or General Packet Radio Service
(GPRS)
mobile data communications networks, and also designed to operate with any of
a variety
of voice communications networks, such as AMPS, TDMA, CDMA, PCS, GSM, etc.
Other types of data and voice networks, both separate and integrated, may also
be utilized
with the mobile device 1000.
Network access requirements vary depending upon the type of communication
system. For example, in the Mobitex and DataTAC networks, mobile devices are
registered on the network using a unique personal identification number or PIN
associated
with each device. In GPRS networks, however, network access is associated with
a
subscriber or user of a device. A GPRS device therefore requires a subscriber
identity
module, commonly referred to as a SIM card, in order to operate on a GPRS
network.
When required network registration or activation procedures have been
completed,
the mobile device 1000 may send and receive communications signals over the
communication network 1401. Signals received from the communications network
1401
by the antenna 1540 are routed to the receiver 1500, which provides for signal
amplification, frequency down conversion, filtering, channel selection, etc.,
and may also
provide analog to digital conversion. Analog-to-digital conversion of the
received signal
allows the DSP 1580 to perform more complex communications functions, such as
demodulation and decoding. In a similar manner, signals to be transmitted to
the network
1401 are processed (e.g. modulated and encoded) by the DSP 1580 and are then
provided
to the transmitter 1520 for digital to analog conversion, frequency up
conversion, filtering,
amplification and transmission to the communication network 1401 (or networks)
via the
antenna 1560.
In addition to processing communications signals, the DSP 1580 provides for
control of the receiver 1500 and the transmitter 1520. For example, gains
applied to
communications signals in the receiver 1500 and transmitter 1520 may be
adaptively
controlled through automatic gain control algorithms implemented in the DSP
1580.
In a data communications mode, a received signal, such as a text message or
web
page download, is processed by the communications subsystem 1001 and is input
to the
CA 02467988 2004-05-21
processing device 1800. The received signal is then further processed by the
processing
device 1800 for an output to the display 1600, or alternatively to some other
auxiliary I/O
device 1060. A device user may also compose data items, such as e-mail
messages, using
the keyboard 1400 and/or some other auxiliary I/O device 1060, such as a
touchpad, a
rocker switch, a thumb-wheel, or some other type of input device. The composed
data
items may then be transmitted over the communications network 1401 via the
communications subsystem 1001.
In a voice communications mode, overall operation of the device is
substantially
similar to the data communications mode, except that received signals are
output to a
speaker 1100, and signals for transmission are generated by a microphone 1120.
Alternative voice or audio I/O subsystems, such as a voice message recording
subsystem,
may also be implemented on the device 1000. In addition, the display 1600 may
also be
utilized in voice communications mode, for example to display the identity of
a calling
party, the duration of a voice call, or other voice call related information.
The short-range communications subsystem enables communication between the
mobile device 1000 and other proximate systems or devices, which need not
necessarily
be similar devices. For example, the short-range communications subsystem may
include
an infrared device and associated circuits and components, or a BluetoothTM
communications module to provide for communication with similarly-enabled
systems
and devices.
It is evident that the present claimed invention is advantageous and overcomes
the
prior art proposals that are designed to wrap SSL security around a fixed
network location.
The present invention is specifically able to have the network destination
specified at run
time because it has no limitation as to which network hosts it can
communicate. The
present invention is suitable when the client is operable only to transmit
unencrypted data,
and cannot use SSL protocol. A secure network connection can now be
established for
SSL protocol communication.
Many modifications and other embodiments of the invention will come to the
mind
of one skilled in the art having the benefit of the teachings presented in the
foregoing
descriptions and the associated drawings. Therefore, it is understood that the
invention is
not to be limited to the specific embodiments disclosed, and that
modifications and
embodiments are intended to be included within the scope of the appended
claims.
11
