 | |
Secure your data communication between two networked machines
UDAParts
support@udaparts.com
Updated on January 2, 2006
Some of data such as password, social security number, credit card number and
many others are just very private, and must be secured through all of data
movement path nodes. Therefore, as programmers we have to do our best to prevent
hackers from sniffing these sensitive data with whatever methods. With help of
SocketPro, you can easily develop a highly secured Internet-enabled application.
This short article tells you how SocketPro helps you develop a secure internet
application according to a few following key points.
- Encrypt data communication
In many cases, your sensitivity
data must be encrypted so that no thirty party can be possible to sniff data
communication through all networked devices between a client and server.
SocketPro internally supports two methods, SSL/TLSv1 and Blowfish to serve
this purpose. In most cases, you may just use SSL/TLSv1 with help of two
OpenSSL libraries, which is an industry standard, and also very simple to
use with SocketPro. In regards to performance, SSL/TLSv1 is slow in
comparison to Blowfish because SSL/TLSv1 requires (1) handshakes for
exchanging public key and other data, and (2) that all of both sensitive and
non-sensitive data are encrypted. However, Blowfish requires no handshake
and it can encrypt a small portion of your selected sensitive data. To use
SSL/TLSv1 within SocketPro, it is extremely simple and all you need is
injecting one line code in client and one line code in server.
In many cases, you may run
SocketPro over a virtual private network (VPN). Because VPN is already
secured, you don't have to use the above two methods SocketPro over VPN.
In addition to the above three
ways to protect data communication, you can turn on online compressing at
both client and server, it is also somewhat helpful to protect data because
zipped data is not readable directly. Note that it is not secure because a
hacker can intercept data into a file and unzip it back into original binary
data.
Without specifying any encryption
method, SocketPro just exchanges data in binary format nakedly. With a
network monitor, a hacker can easily see all of data transferred in the
path.
- Authenticate a remote SocketPro
server enabled with SSL3/TLSv1
If using SSL3 or TLSv1 to secure a socket communication, we must make sure
that there is no third party in the middle of the secure transaction. To
prevent from this attack, first we need to verify if a certificate from a
remote server is indeed from our expected server and not from a man in the
middle. Therefore, we need to compare a previously stored certificate in a
client machine with the certificate from a remote host. If the two
certificates match against each other, we are sure that the remote host is
indeed an expected host and not a unknown hacker. Beginning from SocketPro
version 4.4.0.1, you can use the interface IUCert to retrieve a certificate
from a remote host by retrieving the property CertPem in the OpenSSL pem
text format. Second, we can call the method IUCert::CompareDomain to compare
a remote host domain with the domain indicating with certificate subject. If
both of them can match, it is fine. Otherwise, it is somewhat dangerous or
abnormal at least. If any one of the two points has a problem, we can
shutdown the socket connection and don't send any data to a remote server.
- Validate clients
A client must call
IUSocket::SwitchTo for a service with a specified service identification
number as well as user id and password after building a socket connection.
SocketPro server will retrieve the transferred user id and password.
Afterwards, SocketPro server uses the two data to validate a client
according to the two data. At this time, SocketPro supports three ways,
amOwn, amMixed and amIntegrated, to authenticate the client by calling
SetAutheticationMethod at the server side.
amOwn -- It uses your own method
to authenticate a client through your callback function by calling SetOnIsPermitted.
amIntegarted -- Internally
SocketPro uses Security Support Provider Interface (SSPI) to validate user
credentials. For details, you may see MS support short article How To Validate User Credentials on Microsoft Operating Systems
(Article ID : 180548).
amMixed -- It is the combination
of the above two method. SocketPro first calls your callback function
OnIsPermitted to authenticate a client. If your callback function returns
true,
SocketPro will immediately give a permission to the client. Otherwise,
SocketPro will uses amIntegrated method to continue validating the client.
Whenever the authentication
fails, the socket connection will be aborted at the server side with an
event OnClose having an error code ERROR_UAUTHENTICATION_FAILED.
Note that you may be required to
use one of the three methods in the above section to encrypt transferring
password so that you should never send a password nakedly if you need to
transferring sensitive data over Internet.
- Clean password as soon as possible
Assuming a hacker can inject some
code into your SocketPro client or server application with a whatever way,
the hacker may steal your password by calling IUSocket::get_Password at
client and GetPassword at server side. To solve this potential security
problem, beginning the version 4.3.0.1 SocketPro always cleans a password as
soon as possible at the server side. If you set authentication method to
amIntegrated, you will never use the method GetPassword to retrieve a
password. Internally, SocketPro will immediately clean password right after
authentication using SSPI. When you set authentication method to amOwn, a
password is cleaned right after your callback function OnIsPermitted at the
global level is returned. For amMixed, it is also cleaned right after either
your OnIsPermitted is returned with true or SSPI authentication is performed
assuming your OnIsPermitted is firstly returned with false.
No matter what authentication
method is used, beginning from SocketPro version 4.3.0.1 a password is
always cleaned before the callback function OnIsPermitted at a service level
is called. The callback function OnIsPermitted at a service level will be
never used to validate user credentials any more. With the callback
function, you can know that a client successfully logs in SocketPro server
when it is called.
Similarly, it is also recommended
to clean a password at client side right after calling IUSocket::SwitchTo by
setting the property Password to empty (IUSocket::put_Password).
- Clean memory track
Beginning SocketPro version
4.4.2.1, you can clean all of memory tracks that may contain your
sensitivity data. Whenever you send a request to a server or the server
returns a result to the client, data will move through a set of memory
chunks within SocketPro. However, these memory chunks are not immediately
destroyed but reused later. A hacker may map memory chucks and peek
sensitive data, though it is somewhat difficult. Also, window platform may
page these memory chunks. To reduce this potential security, you can call
the method CleanTrack on either client or server side right after sending a
request or result.
- Restrict a set of functions to
prevent SocketPro server from being changed into other functions
After a listening socket is
started by calling the function StartSocketProServer, you can not call the
following functions any more so that a better security is ensured because
these functions may possibly have security problems if there are no
restrictions applied:
a. AddADll
b. AddSvsContext
c. ReplaceSvsContext
d. SetDefaultEncryptionMethod
e. SetEncryptionMethod
f. SetOnIsPermitted
In addition, you can change
authentication method from amOwn to amMixed or from amMixed to amIntegrated,
but you can not change authentication method from amIntegrated to amMixed,
from amMixed to amOwn, or from amIntegrated from amOwn. By default,
authentication method is set to amOwn.
- Share authentication among
different services over one socket connection
SocketPro can provide multiple
services over one established socket connection by calling
IUSocket::SwitchTo, different from other common remoting frameworks. In many
cases, you can share a successful authentication with all of services over
one socket connection by calling the function SetSharedAM. Doing so will
avoid extra authentication and improve the performance because
authentication may be considerably expensive. By default, SocketPro do
authentication whenevr a client calls IUSocket::SwitchTo. Note that you can
not share a successful authentication across different socket connections.
At last, you can change shared
authentication from true to false but you can't change it from false to
true, after a listening socket is started.
|
