Introduction

In this article I’ll move 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. My hope is that, after you read this article, you’llbe among the 1% of the Internet users that know what solution hasactually been found.

Security in the LAN Environment

There is nothing such as a perfect security solution that can fit into any kind of environment. 
Each solution is based on some assumptions regarding the environment where it has to be deployed. If such assumptions do not hold, the solution will likely fail miserably. 
The approach used to provide authentication and data security on a “controlled” LAN environment basically lies on these basic facts:

* Spoofing is not possible (no man in the middle scenarios).
* Authentication is delegated to an authentication authority.

Under such assumptions the security mechanism used by NTLM or Kerberos work effectively.

Security on the WEB

Authentication in a LAN environment is focused on authenticating clients; authenticating servers is not an issue cause the LAN network is considered “secure” regarding spoofing; on the contrary, on the Web the focus is reversed; providing a way to protect clients from spoofed servers isof higher concern.

You still need some form of client authentication in some cases, but, as long as e-Commerce sites are concerned, the client Credit Card number vs. it’s billing address is enough: the problem is delegated to the credit card authority.
You could then think, well NTLM is all about authenticating clients, but Kerberos can provide server authentication, so where’s the problem?

The problem is that authentication authorities can be spoofed as well. If you try to deploy the security schema used in LAN environments into the Internet, an authentication authority should provide a mean to authenticate itself to everyone that’s asking for authentication services. 
This means that the authentication authority must meet everyone to share a secret: a different secret to everyone subscribed for authentication services. This is clearly not feasible, and even if it was, client and servers cannot delegate authentication to”authentication authorities” simply since it wouldn’t scale. 

In his article “Web Security” [1] Keith Brown goes deeper into showing how there is no way to modify in some way a security framework based on “sharing secrets” to have it working in a feasible and scalable way on the globalInternet, since you always end up with the need of meet for lunch to whispersecrets.

Public Key Cryptography

Internet security problems find an acceptable solution using a new security approach called “Public Key Cryptography”. 
Public Key Cryptography was invented in the mid-1970s by Whitfield Diffie. The idea is basically this: Instead of having a single secret key that’s used for authentication and encryption/decryption, you’ve a Public key that you share to everyone that wants to communicate in a secure way with you. You then have a corresponding Private key that you never share with anyone. 

If you encrypt some text with Key A, you can only decrypt the resulting encrypted text with Key B. Because two different keys must be used public key algorithms are also known as asymmetric algorithms. With public key you can achieve both authentication and data protection.

• Authentication: Bob encrypt a message with his private key and send it. Anyone that has Bob’s public key can successfully decrypt the message. The receiver knows that If the message didn’t come from Bob the encrypted text would decrypt to complete gibberish.
• Secure data transmission: Bob encrypt a message with Alice’s public key and send it to her. Only Alice can successfully decrypt the message. 

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 algorithmused 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 roleindeed here: during the initial handshake phase of theSSL communication certificates are used for authenticating the server (eventually the client as well) and establishing the secret sessionkey in a secure way. 
Done that, asymmetric encryption is out of the picture and you can happily shop at Amazon.

Conclusions

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