Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Security for the global Internet  : Page 2

In this article Enrico moves away from COM security to provide an overview about that vast subject generally referred as "Internet security". As you will see, providing an effective and scalable security infrastructure in the Internet is a very challenging goal. No panic anyway, since sites like Amazon.com are up and running (hem .. well most times) a solution has been found. The hope is that, after you read this article, you'll be among the 1% of the Internet users that know what solution has actually been found.

It's pretty simple to put these two things together to get authentication and data protection. 

Alice encrypts her message using Bob's public key; in this way she can achieve Bob authentication: only the one that owns the corresponding private key will be able to decrypt the message. 
Alice then, to prove her identity, will encrypt with her private key the message she has encrypted with Bob's public key in the previous step. 
Bob will know that the message comes from Alice since he can successfully decrypt the message using Alice's public key (and then using his private key).

There is still one problem here though; we didn't mention how Bob and Alice came to pass each other their public keys. Since these are public keys you may think that public key exchange doesn't need any protection; this is not true. 
If Fred intercepts the message where Bob sends Alice his public key, he can grab the key and pass Alice his own public key instead. Now Fred can sit in the middle, having hijacked a router, decrypting Alice messages and then encrypting the plain text back with Bob's public Key. 

Humm .. it looks like we are back whispering. This time we are not whispering secrets but public keys.  You must note anyway that the situation is somewhat better. You don't need to whisper a different secret to everyone. There are situations where whispering public keys is still feasible: This is the model used by Pretty Good Privacy (PGP).

A more general solution is to use a X.509 security model. This model asserts that there is a rigid hierarchy of authorities whose public key is "well known". "Well known" means that the validity of their public key is out of question. In the real world there are several authorities whose public keys actually ship with Web browsers.  There are also companies that set up their own independent hierarchy of authorities.  These authorities are called Certificate Authorities since their role is to provide certificates that guaranties secure public key exchange.

If Bob wants to communicate in a safe way with Alice, he must ask to a certification authority for a digital certificate for him (and pay for it). A digital certificate is an electronic envelope whose content is encrypted with the certification authority private key. The content of the envelope contains Bob's Public key. Bob sends Alice the certificate. Alice uses the certification authority public key to open the envelope and get Bob's public key. Done that, Alice and Bob can communicate in a safe and trusted way without resorting to the certification authority any more.

Secure Socket Layer SSL

Secure Socket Layer (SSL) is the de-facto standard protocol for encrypted communication over the Internet (HTTPS). SSL is authentication unaware; it deals only on encryption and decryption based on a session secret key. You will probably be thinking right now: what the hell? We have been talking about asymmetric algorithms as the only mean to set a proper secured communication! Why is a symmetric algorithm used instead? 

The reason why asymmetric encryption is not used is because symmetric algorithms are hundreds of times faster than asymmetric ones when it comes to exchange bulk data. Still asymmetric algorithms (in the form of Server Certificates) do have a basic and fundamental role indeed here: during the initial handshake phase of the SSL communication certificates are used for authenticating the server (eventually the client as well) and establishing the secret session key in a secure way. 
Done that, asymmetric encryption is out of the picture and you can happily shop at Amazon.


I hope I have provided a clear enough overview about Internet security issues. In my opinion this subject is quite overlooked during web application development, still it is fundamental to understand all the issues involved in order to make the proper choices among the different authentication options that IIS offers you. How you will authenticate Internet users is not a last minute choice, since it may heavily influence your COM application deployment choices. 
We will see in my next article the different security configurations that IIS offers and, specifically how certificate can be used in IIS to provide web server authentication to clients and how client certificates can be used for client authentication.

[1] Web Security, MSDN magazine - June 2000, Keith Brown



Enrico Sabbadin is a software developer (MCP) that works, since 1995, on distributed and Internet based applications design on the Microsoft platform. He is an author for several Italian programming magazines and for the ASPToday web site, and occasionally speaks at Microsoft MSDN conferences in Italy. Enrico maintains at his own site a MTS FAQ (http://www.sabbasoft.com).
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date