|
||
 |
||
|
| Secure Web Sites |
 Email This
 Print ThisView My Personal Library |
|
Internet & E-mail Safety April 2002 • Vol.8 Issue 4 Page(s) 79-82 in print issue |
Secure Web Sites How SSL Works | ||
 If you've spent any time at all surfing the Web, you've probably encountered secure Web pages. These pages are usually designed to process financial transactions or collect personal information from a client (you) and send this data to a merchant or financial institution. A secure Web page is characterized by the appearance of a yellow, locked padlock icon in the bottom-right portion of the Web browser's window. In addition, the Web site address of a secure page begins with https:// rather than the normal http://. This indicates the SSL (Secure Sockets Layer) protocol is enabled. With the recent increase in computer fraud and identity theft, it is important to understand how SSL works and what protection it provides before you use the Internet to transmit your Social Security number or checking account PIN (personal identification number) to an institution or merchant.  The Big Picture. Simply stated, SSL provides a secure connection, often called a tunnel, between your computer's browser and a specific Web server. Data passing between the client and the server is encrypted using a technology called public-key encryption to ensure only the intended recipient can decrypt and read the information. Each secured Web site has its own unique digital certificate that defines the public and private encryption keys used during secure communications. If you jump from one secure site to another, the original tunnel is closed and a new one is created using a different set of encryption keys. Today, nearly all Web-based purchases and other monetary transactions use SSL. Web sites providing access to personal banking and credit card data use SSL to encrypt both the logon information from the customer and the account information being sent back Look Under The Hood. Netscape Communications introduced the SSL protocol in 1994 to enable encrypted and authenticated communications across the Internet. This original implementation of SSL, based on encryption algorithms developed by RSA Data Security, quickly became the de facto industry standard. Today, all popular Web browsers support SSL, and it is also used by many other client/server applications that require secure communications. SSL software is available for most major server OSes (operating systems). The current version of SSL is 3.0, and it was released in November 1995. The IETF (Internet Engineering Task Force) is currently developing a new standard called TLS (Transport Layer Security) that will be based on SSL.
When SSL is enabled, it inserts itself between TCP/IP and the higher-level protocols, providing authentication and encryption/decryption services on behalf of the applications. SSL decrypts data arriving from a secure Web server before the data is passed along to the browser and, ultimately, the user. This layered design eliminates the need to include encryption/decryption features in every Web-based application. Take It For A Test Drive. SSL provides three fundamental TCP/IP services: server authentication, client authentication, and encrypted communications. Of the three, client authentication is the least frequently used. Server authentication lets SSL-enabled client software verify that the server's digital certificate and public ID have been issued by a CA (Certificate Authority) and that these credentials are current and valid. This verification process guarantees to the client that it is communicating with the intended server. Client authentication lets a server validate a user's credentials. Because the client usually initiates the secure communication and originates the data requiring encryption, it is not usually necessary for the server to verify the identity of the client. An exception might be where the client was requesting sensitive financial information. In this case, the server might require the use of client authentication to confirm the identity of the requester. Encrypted communications are those in which all data sent in either direction is encrypted by the source computer and decrypted by the destination computer. All transmitted data is also protected by a mechanism to detect in-transit tampering. Server Certificates. Before a server can support SSL communications it must be issued a digital certificate by a CA, such as VeriSign (http://www.verisign.com), Thawte Consulting (http://www.thawte.com), or Entrust (http://www.entrust.com). A digital certificate is a license to operate a secure server much the same way as a driver's license is a license to operate a motor vehicle. You would tend to accept a driver's license issued by the state of California as being valid but you would probably question the validity of a license issued by Tony's Fish Market; the same concept applies to digital certificates. Because anyone with the right software can create a digital certificate, most Web browsers include a list of trusted CAs and their public keys. Certificates from these trusted CAs will be accepted without question. If, however, a Web server presents a certificate from Tony's Security Shop, your browser will ask you whether you wish to accept the certificate. If you respond negatively, your browser will not establish a secure connection with the server. If you agree to accept the certificate, Tony's Security Shop and its corresponding public key will be added to your browser's list of trusted CAs. A digital certificate is nothing more than a file containing the secure server's public encryption key and a variety of other identification information. The certificate is digitally signed using the CA's own public key. When a browser receives a digital certificate from a secure Web server, it uses the CA's public key from its list of trusted CAs to decrypt the digital signature and verify the issuing authority. The browser also checks to make sure your current system date falls within the certificate's validity period and the server's actual domain name matches the domain name specified in the certificate. If any of these authentication tests fail, the browser notifies you immediately, and the page will not continue loading unless you indicate you are willing to accept the invalid certificate. If the certificate is validated, the browser extracts the server's public key and uses it to encrypt subsequent messages to the server. Most digital certificates issued today follow the X.509 v3 standard developed by the International Telecommunications Union. This international standards body and the many reputable CAs around the world make every effort to guard against forged or misused certificates. The information contained in a certificate is very specific to the server it is issued to, and the CA's digital signature makes forgery virtually impossible. The authentication process incorporated into SSL makes it very difficult for servers to misrepresent their status to your browser. If you encounter an invalid certificate, you should not let your browser load the Web page. Instead, contact the owner of the Web page immediately. An expired certificate might be nothing more than a simple oversight on the part of the certificate holder, and you would be doing them a favor by bringing the problem to his attention.
To view the contents of a server's digital certificate, browse to a secure Web page and double-click the padlock icon. This will open a Certificate window with three tabs. Click the Details tab and then click the Public Key field to view the actual hexadecimal value of the public key being used. An example of a secure Web page can be found at https://digitalid.verisign.com (don't forget the letter ‘s' after http). Client Certificates. If you use a service requiring client authentication, you will have to acquire your own digital certificate from a CA. Personal digital certificates, sometimes called Digital IDs, range in price from free (Thawte) to $14.95 per year (VeriSign). Once you receive your certificate file, you must configure it into your browser. Netscape Navigator and Microsoft Internet Explorer provide tools for importing certificates. If you use IE, you install certificates with the Certificate Import Wizard. Click the Tools menu, click Internet Options, and select the Content tab. Click the Certificates button and the Import button to start the wizard. IE supports digital certificates stored in three formats: PKCS #12, PKCS #7, and Microsoft Serialized Certificate Store. Netscape Navigator 6 supports a similar facility. Click the Tasks menu, point to Privacy and Security, and select Security Manager. Click the Certificates tab and the Obtain New button to display a page of hyperlinks to 19 personal certificate providers. Data Encryption. Cryptography is the transforming (encrypting) of information into an unreadable format called cipher text. Only those who possess the correct key can decipher (decrypt) that information back into plain text. Cryptographic algorithms, called ciphers, use mathematical functions to encrypt or decrypt the data based on the value of the key. Sets of these algorithms, known as cipher suites, have been designed to provide varying degrees of security and processing speed. Companies implementing SSL choose which suites they will support based on the nature of the data being transmitted and the variety of client applications they intend to support. Common cipher suites are the following: •DES (Data Encryption Standard), an encryption algorithm used by the U.S. government. •DSA (Digital Signature Algorithm), part of the digital authentication standard used by the U.S. government. •KEA (Key Exchange Algorithm), an algorithm used for key exchange by the U.S. government. •MD5 (Message Digest), an algorithm developed by Professor Ronald Rivest, a pioneer in data security and co-founder of RSA Data Security. •RC2 and RC4 (Rivest Ciphers), developed for RSA Data Security. •RSA, a public-key algorithm for encryption and authentication developed by Rivest, Adi Shamir, and Leonard Adleman, the co-founders of RSA Data Security. •RSA Key Exchange, a key-exchange algorithm designed for SSL and based on the RSA algorithm. •SHA-1 (Secure Hash Algorithm), a hash function used by the U.S. government. •SKIPJACK, a classified symmetric-key algorithm implemented in certain hardware used by the U.S. government. •Triple-DES, the DES algorithm, applied three times in succession. After the original data is encrypted using DES, the resulting code is encrypted and that result is encrypted again.
Key lengths are measured in bits and keys consisting of 40, 56, and 128 bits are commonly used in SSL ciphers. To put key size into perspective, a 128-bit key is approximately 309 septillion (309,485,000,000,000,000,000,000,000) times larger than a 40-bit key. On its Web site, RSA Security (http://www.rsasecurity.com) equates key strength to real-world objects in the following manner: • No encryption: the same as sending information on a postcard, the contents are visible to anyone who wants to look. •40-bit key: the same as sending information in a plain, white envelope. •56-bit key: the same as sending information in a security envelope that is printed to prevent the contents from showing through. •128-bit key: the same as sending information in a lead-lined, 12-inch-thick titanium safe transported by an armored tank with a convoy of a hundred armed guards. If 128-bit encryption is so much better, why not use it exclusively and abandon 40-bit and 56-bit keys? The answer lies in the fact that encryption algorithms are actually mathematical processes applied to the data. Longer keys require more computation time to encrypt the same amount of data, and the resulting increased security may not be necessary. For simple Web pages, the 128-bit processing time is small, but if you are moving large amounts of data from one point to another with SSL enabled, you might choose speed over security. The issue of encryption time also explains why Web connections don't use SSL all the time. Even 40-bit encryption adds a certain amount of delay to the total transit time when compared to plain text traffic. If a server were required to encrypt and decrypt every byte of data, its performance would be seriously impacted. Prior to 2000, the U.S. government prohibited the export of software products that used very strong encryption techniques, including 128-bit keys. Microsoft, Netscape, and other software vendors were forced to create, supply, and maintain two different versions of their products: a domestic version with 128-bit encryption and an export version with 40- or 56-bit encryption. These limitations have since been lifted, except for some specific countries, such as Libya, and today, software vendors can market a single version of their products.
Take The Keys. Data encryption techniques can be divided into two broad categories: symmetric-key encryption and public-key encryption. As the name implies, symmetric- key encryption uses the same key for the encryption and decryption processes, and the key must be kept secret at all times. Public-key encryption uses a pair of related keys, one known to the public and one known only to the decryption cipher. Symmetric-key encryption can be implemented in a way that makes it very efficient, and users don't experience significant transit delays as a result of the encryption and decryption process. As long as the key remains a secret, efficient and secure transmission is assured. The disadvantage of the symmetric-key system is that both parties need to use the same key so the key has to be exchanged at some point. It is during these exchanges that symmetric keys are most commonly compromised. If a symmetric key is compromised, both the confidentiality and the integrity of the transmission are affected. An individual with an unauthorized symmetric key cannot only decrypt messages but also encrypt new messages and make them appear to have originated from one of the authorized parties. Public-key encryption always uses a pair of related keys. Once data has been encrypted with the public key, it can only be decrypted using the corresponding private key. The advantage of public-key encryption is that the sender can obtain a recipient's public key from a number of sources and the private key never has to be shared, eliminating problems with exchanging symmetric keys. On the other hand, public-key encryption requires more computational time and is usually not appropriate for large amounts of data. Take The Best Of Both Worlds. SSL was designed to take advantage of the strengths of both encryption schemes. Public-key encryption is used to initiate a session and verify the identity of the server against information in its digital certificate. Once the authentication process is complete, the client sends the server a symmetric session key by securely encrypting it using the server's public key. The server decrypts the session key using its private key, and efficient, secure communications can then take place. A very important step in this process is the server verification, where the client checks the Web address specified in the certificate against the actual Web address of the server sending the certificate. Without this check, a rogue program could attempt a man-in-the-middle attack. This is a situation where the rogue program intercepts the legitimate keys passed back and forth during the SSL initialization and substitutes its own. To the client, the rogue appears to be the server; to the server, the rogue appears to be the client. This lets the rogue decrypt and read all data flowing back and forth and to actually change or insert data.
How Good Is It? SSL was designed to provide secure communications between a Web-based client and a specific server. It uses sophisticated encryption algorithms and complex keys that make it nearly impossible to break. With all that said, just how secure is your Internet transaction? Unfortunately, the answer to this question depends on the sophistication and design of the secure Web site itself and what happens to the data once it reaches the intended server and is decrypted. With large companies that operate their own Web servers and communications networks, your risk is probably minimal. As long as you trust the company to manage its IT (information technology) resources properly, you can assume your data is safe. Smaller companies often use a third-party Web hosting company to support their sites, and these providers are often located geographically far away from the merchant. When you send your credit card information to a secure Web site, it may actually end up on a third party's server. If you're lucky, the merchant will be required to retrieve your information using its own secure connection to the server. If you're not so lucky, the hosting company will offer to e-mail all the collected data to the merchant on a regular basis. Because most e-mail is not encrypted or protected in any way, your personal information will be just as vulnerable as if you had sent it in plain text in the first place. Several companies, such as Secure Hosting (http://www.securehosting.com), offer a service that lets merchants create an order capturing form on a secure server while leaving the rest of the Web site on an unsecured server. The order form data is stored in an encrypted database at Secure Hosting where the merchant may retrieve it using a secure connection. As orders arrive, the merchant is notified by e-mail but the message does not include any of the customer's sensitive information. Other hosting services, such as The Host Group (http://www.thehostgroup.com), tightly integrate their shopping cart, merchant account, and SSL services together so sensitive customer information never leaves their control. Lock Down. There is no excuse for weak security, especially when it involves someone else's personal information, but there is no way to guarantee the safety of your data once it leaves your hands. This is true whether you're conducting an electronic transaction over the Internet, giving someone you've never even seen your credit card number over the phone, or simply handing your credit card to a stranger in a restaurant who then disappears for minutes at a time. In the final analysis, it all boils down to caveat emptor: "let the buyer beware."  by Dick Archer
|
|
Home Copyright & Legal Information Privacy Policy Site Map Contact Us