Authenticating Logins - The Super Socket Network Library
(Page 13 of 24 )
SQL Server 2000 introduces a new special network library that offers an alternative to the Multiprotocol network library for encrypting both the authentication network packets and the data packets as they travel between the client and server. As Figure 2-6 shows, the Super Socket network library is not a typical network library, in that it does not directly communicate with clients. Instead, it is a helper library that sits between the database engine and the other network libraries and encrypts the data using Secure Sockets Layer (SSL) before passing it to them. This architecture permits encrypting authentication information for clients who do not use the Multiprotocol network library’s encryption. To understand how SSL compares to encryption in the Multiprotocol network library, let’s look briefly at how SSL works.
Figure 2-6. The Super Socket network library architecture
SSL is based on the premise that the server has a pair of keys, one given to the public and one kept private, which have a special relationship to each other: data encrypted with one key can only be unencrypted by using the other key. The keys themselves are very large prime numbers, and you cannot derive one key from the other. The size of the number depends on the number of bits used to store it, with 128 bits being the current RC4 standard for SSL symmetric key encryption. That means the keys can be numbers as large as 2 to the 128th power, which is a very large number indeed. With the current technology, you’d have a better chance of winning the lottery, getting hit by lightning, and sinking a hole in one, all on the same day, than of deriving the second key in a pair knowing the first key.
Public key encryption itself is based on the fact that the private key is always kept completely secret from everyone. Only the key’s owner knows it. If you encrypt data using your private key, only your public key can decrypt it. Anyone receiving the encrypted data will know you sent it, because only you have the private key that is paired with the public key. Conversely, if someone uses your public key to encrypt data, that person can be assured that only you can decrypt the data, because only you have the private key.
Prior to public key encryption, two people who wanted to share encrypted data would need to agree on an encryption key before they encrypted the data. Known as symmetric encryption, a single key both encrypts and decrypts the data. If only two people know the key, then they both know that data came from one of them and that only the two of them will be able to read the data. The benefit of symmetric keys is that they are much faster than public key encryption, and the size of the key can be smaller. The problem is that it is quite impossible to set up shared, private keys with everyone in the world.
To implement this combination of public key encryption and symmetric key encryption, SSL has to exchange several messages with the client. In Figure 2-7, the first step is the client sends a ClientHello message, which includes a large random number, to the server. In response, the server sends a ServerHello message, which also includes a large random number, followed by the server’s public key and a ServerHelloDone message. At this point, the client and the server have agreed on what kind of encryption they will use and the size of the keys they will use. Now the client will create a 384-bit symmetric key known as the “master secret,” encrypt it with the server’s public key, and send it back to the server using a ClientKeyExchange message. When the client and the server both have the master secret, they use a special set of one-way hashing functions to combine the master key and the random numbers sent in the hello messages into a single symmetric key that will be used to encrypt the data stream.
Figure 2-7. Message exchange across SSL during encryption
The client then sends a ChangeCipherSpec message telling the server it wants to start encrypting data and a Finished message that contains various pieces of information encrypted using the new key. The server responds with its own ChangeCipherSpec and Finished messages to inform the client that the secure channel has been established. All subsequent packets sent in this transaction will be encrypted, but only at the session level.
This is a very abbreviated explanation of SSL, but the main point to understand in this process is that the client uses the fact that no one but the server can decrypt a session key that has been encrypted with the server’s public key. That allows the client and server to share a symmetric key without having some sort of prearrangement. It also allows a client to choose different keys for different sessions to keep would-be eavesdroppers from being able to use one session key to listen in on another session.
It is also important to understand what SSL does not protect. The first point to recognize about SSL is that the only identity you can authenticate is the server’s. The digital certificate is digitally signed by a certificate authority, which is supposed to verify the identity of the person requesting the certificate. VeriSign is the primary certificate authority in the world today, and it asks people to provide a lot of paperwork to prove that they own the domain name that will be in the certifi-cate—that they are in fact who they say they are. The end result is that there can be ahigh level of trust over the identity of a server with a VeriSign digital certificate.
The same cannot be said about the client, however. There is no authentication of the client’s identity other than the account and password. A server that uses SSL does not have any better way of determining the client’s identity than one that does not use SSL. SSL is simply not designed to offer that kind of authentication. Its sole purpose for SQL Server is to encrypt the data traveling between the server and the client, including the account and password for SQL Server authenticated logins.
Another common misconception is that SSL will improve the security of authentication process for Windows authenticated logins. This is not the case. Referring back to the OSI model earlier in the chapter, SSL is a session layer protocol, and it cannot encrypt any part of the network packet added by the lower layers or packets created by other services. That means that there is no protection for the source and destination addresses, TCP protocol headers, or other information in the packet, and there is no encryption of data from other services, such as the network login service in Windows NT and 2000. As you will see in the next section, Windows authentication occurs before SQL Server sees the client’s login request; therefore, there is nowhere to send the ClientHello message. SSL must wait until after Windows has authenticated the user’s account and password.
The other limitation to SSL is that it does not prevent tampering with the network packet. It is possible for an attacker to set up a “man-in-the-middle” attack by intercepting packets from the client and then rerouting them to the server. In this scenario, the attacker’s computer sets up a SSL session with the client using his digital certificate and then sets up a second session with SQL Server as proxy between the client and server. As packets pass through the attacker’s computer, he can store them and examine them for passwords and other information.
The man-in-the-middle attack works because the client does not check the authenticity of the digital certificate and SQL Server does not validate the identity of the clients that connect to it. You will see in Chapter 5 how IPSec and Kerberos provide encryption equal to SSL and prevent man-in-the-middle attacks, among others.
For now, recognize that SSL is only part of the solution to protect your data from unauthorized access.
NOTE Because there are several different paths you can take in setting up SSL, I do not cover the process of getting a certificate, installing it on the server, and turning on encryption in this book. Consult SQL Server Books Online for detailed instructions on how to implement SSL in SQL Server 2000.
 This is from SQL Server Security Distilled, second edition, by Morris Lewis (Apress, ISBN 1590592190). Check it out at your favorite bookstore today. Buy this book now. |
Next: The TCP/IP Network Library >>
More MS SQL Server Articles
More By Apress Publishing
/ 17 
