Home: www.vipan.com Vipan Singla e-mail: vipan@vipan.com
Secure Web Communications across Secure Socket Layer

Six Degrees of Paranoia

  1. The server does not know who is on the other end of the connection. The user thinks it is connected to the real (as opposed to fake or impersonator) server he asked for but may not be so.

    For all the server knows, it may be sending sensitive information (such as some other user's bank account balance) to the wrong user ("impersonation"). Same problem is faced by the real user.

    This is the routine mode. The user has not authenticated himself to the server by entering a username and a password. Nor is the HTTP connection established through the SSL.

    Additional problems include "eavesdropping" (someone can learn your credit card number) and "tampering" (someone can replace your ship-to address with his address). Such concerns are also called "the-man-in-the-middle" type concerns. All Internet data passes through so many servers on the way that any of them could be an evil server.

    Use this type of communication for exchanging public data only. You should not care if someone else sees it or modifies it.

  2. Both the server and the user think they know who is on the other end of the server.

    Here, the user has requested a server URL. Before supplying the requested URL, the server asks the user to enter his username and password on a form and send it to the server. The user complies. The information reaches the server where it (usually) makes a "one-way hash" of the password supplied by the user and compares the resulting value to the one-way hash of the password supplied by the user during registration. If they match, the user is authenticated and the server sends the requested URL.

    The problem is that user's browser has sent the password as clear text, or, at best, encoded with base-64 encoding. The-man-in-the-middle can very easily read it, save it for future impersonations to the server or change the included data. In addition, the user still does not know if he is talking to the real server or some impersonator in the middle.

    People usually use it log into their Yahoo, MSN, AOL or such accounts where they are not actually spending any money.

  3. Enter SSL. Usually you, a user, initiate a secure transaction. So you need to first convince yourself that the server you are talking to is the right server. Only then you want to log on to that server by providing your username and password.

    SSL makes sure that the user is talking to the real server, encrypts the user's data before sending it to the server (effectively wrapping the data in an (really, really secure) envelope, and decrypts server's data upon receipt. Each modern browser such as Netscape and Internet Explorer now-a-days comes with embedded Secure Socket Layer software.

    With SSL, the user KNOWS that he is talking to the real server and "the-man-in-the-middle" CANNOT view or change the data being communicated over the SSL connection. If he tries to view it, he will see scrambled data. If he tries to break the code to unscramble the data, it will take him a few MILLION years to do that given the current capabilities of such hardware and software. In frustration, if he tries to change the scrambled data by replacing it with some other scrambled data, the message digest will not match. And he can't really change the message digest because it has been encrypted also!

    The server still does not know that it is talking to the real user. As far as the server knows, somebody sitting on a computer entered the correct username and password and now, the server is supposed to be sending sensitive data to that computer.

    A user can be authenticated in two ways:
    1. By supplying a password already known to the server. This is the usual way. However, the first time the user registers, the server will have to go to some (extreme) lengths to really make sure that the user who is registering is the user he claims to be. Since most users have accounts at multiple servers, they will need a different password for each server or risk compromising the password by sharing it across servers.
    2. By supplying a server-provided random phrase encrypted with the user's private key, and a valid public digital certificate issued by a well known, responsible authority. Here, the issuing company takes care of authenticating the user (just as a Social Security or a Passport Office does before providing the Social Security Number or Passport). The digital certificate contains the user's public key which the server can use to decrypt the data sent by the user and see if the resulting phrase matches the phrase sent by the server.

      The down side is that each user will have to jump through some hoops in getting a valid certificate from a well recognized authority, or one from each well-known authority (VeriSign, Thawte etc.) just in case a server is picky about the brand of certificates it trusts.

  4. Sometimes, the server may want to know for sure that it is talking to the correct user i.e. the user who registered with the server in the first place. Such a need can arise for a bank when sending large sums of money to the user or for voting in elections.

    The server, being a machine, cannot really look at the user and match his photo to the one on his driver's license or passport. May be in future we will have iris scanners mounted on each computer by default and each server will have access to the iris print database to compare. Not yet!

    The solution is to have the user get a (digital) certificate from a trusted issuer who certifies that:

    1. The user is called "Jane Doe" (Actually, the user's real name)
    2. This certificate of the user's identity is valid till such-and-such date.
    3. You can encrypt/decrypt data to/from the user using this public key

    The certificate issuer "signs" the certificate and sends the digital file to the user. The user can then send it along with his request to the server over the SSL connection (so that "the-man-in-the-middle" can't mess with it). If it is really the user who gets the certificate and if the user keeps tight control of his private key, then the server is sure for all intent and purposes that it is the real user with whom the server is communicating.

    Additional Details: The browser encrypts some data known to the server with the user's private key, and sends both the encrypted data and the user's public certificate to the server. The server checks the "message digest" to make sure that the encrypted data was not tampered en-route, decrypts the data using the public key contained in the user's public certificate, and matches it against the one known to the server. Since only an authentic private key could have encrypted the data decryptable with the public key contained in the user's certificate, the server is quite sure that it is dealing with the real user.

    In addition, the server is supposed to check at the certificate issuer's central location if the certificate has been revoked before it expired.

    It is the user's responsibility to renew his digital certificate before it expires so that he may continue using it.

  5. With SSL, the data is protected from the world only during communication over the Internet. It is still available as an open book on the user's computer or on the server. Why can't you keep your sensitive data in an encrypted form on your computer or on the server? Certainly, you keep your important papers under lock and key, may be in a safe even!

    Well, you can use some encryption software (e.g. PGP) and your own personal encryption/decryption keys (symmetric or asymmetric, it doesn't matter), encrypt sensitive data (such as your Money or Quicken file or your entire hard disk, for that matter) with it, and save the encryption key at a safe location (such as save it on a floppy disk, CD-ROM or smart card, and store that media under lock and key, may be in a safe even!).

  6. Now both the user and the server know for sure who is on the other end of the connection. Nobody in the middle can mess with their data without them knowing about it automatically. And the user has protected his sensitive data even on his computer.

    But the user's data is not protected on the server. Yes, the server may encrypt and decrypt it using the server's own keys, but that's beyond the user's control. For all the user knows, the server may keep all of user's data as an open book. You will have to just trust the server's word that the server keeps all your sensitive data encrypted, and only decrypts it for you or other authorized entities. Good luck with that!

Getting Started

SSL - Step-by-Step

                 .---.
.-.              |B  |
|U|  .--------.  |R  |  .---------.
|S|  |Plain   |  |O S|  |  HOLD   |
|E|->|Text    |->|W S|->| REQUEST |
|R|  |Request |  |S L|  |         |
`-'  `--------'  |E  |  `---------'
                 |R  |
                 `---'

                   <--------Plain Text Communications-------->
                 .---.  .---------.  .---.  .-----------.  .---.  .-----------.
                 |B  |  |Client   |  |S  |  |Server     |  |B  |  |Verify     |
                 |R  |  |Hello w/ |  |E  |  |Hello w/   |  |R  |  |Server     |
                 |O S|  |Random   |  |R S|  |Certificate|  |O S|  |Certificate|
                 |W S|->|Challenge|->|V S|->|& Random   |->|W S|->|& Domain   |
                 |S L|  |Data     |  |E L|  |Connection |  |S L|  |Name       |
                 |E  |  |(Plain   |  |R  |  |ID (Plain  |  |E  |  |(Checks OK)|
                 |R  |  |Text)    |  |   |  |Text)      |  |R  |  |           |
                 `---'  `---------'  `---'  `-----------'  `---'  `-----------'

                   <--Asymmetric Key Encryption--->
                 .---.  .---------.  .-------.  .---.  .-------.  .---------.
                 |B  |  |Generate |  |       |  |S  |  |       |  |Generate |
                 |R  |  |Master   |  |Encrypt|  |E  |  |Decrypt|  |Symmetric|
                 |O S|  |Secret   |  |w/     |  |R S|  |w/     |  |Key Pair |
                 |W S|->|to be    |->|Server |->|V S|->|Server |->|for Read |
                 |S L|  |Shared   |  |Public |  |E L|  |Private|  |& Write  |
                 |E  |  |w/       |  |Key    |  |R  |  |Key    |  |(Session |
                 |R  |  |Server   |  |       |  |   |  |       |  |Keys)    |
                 `---'  `---------'  `-------'  `---'  `-------'  `---------'
                             |
Symmetric----------          V         -------------------------------Symmetric
Key                     .---------.  .---------.  .---.  .-------.          Key
Encryption              |Generate |  |Encrypt  |  |S  |  |Decrypt|   Encryption
 |  |  |                |Symmetric|  |Server   |  |E  |  |w/     |     |  |  |
 |  |  |                |Key Pair |  |Conn. ID |  |R S|  |Server |     |  |  |
 |  |  |                |for Read |->|w/ Client|->|V S|->|Read   |     |  |  |
 V  V  V                |Write    |  |Write Key|  |E L|  |Key    |     V  V  V
                        |(Session |  |- Client |  |R  |  |(Checks|
                        |Keys)    |  |Finish   |  |   |  |OK)    |
                        `---------'  `---------'  `---'  `-------'

                                    .---.  .---------.  .---.  .-------.
                                    |S  |  |Encrypt  |  |B  |  |Decrypt|
                                    |E  |  |Client   |  |R  |  |w/     |
                                    |R S|  |Challenge|  |O S|  |Client |
                                    |V S|->|Data w/  |->|W S|->|Read   |
                                    |E L|  |Server   |  |S L|  |Key    |
                                    |R  |  |Write    |  |E  |  |(Checks|
                                    |   |  |Key      |  |R  |  |OK)    |
                                    `---'  `---------'  `---'  `-------'

                                    .---.  .---------.  .---.  .-------.
                                    |S  |  |Server   |  |B  |  |Decrypt|
                                    |E  |  |Finish - |  |R  |  |w/     |
                                    |R S|  |Encrypted|  |O S|  |Client |
                                    |V S|->|New      |->|W S|->|Read   |
                                    |E L|  |Session  |  |S L|  |Key,   |
                                    |R  |  |ID       |  |E  |  |use in |
                                    |   |  |         |  |R  |  |session|
                                    `---'  `---------'  `---'  `-------'

                 .---.  .--------.  .---.  .---------.  .---.
                 |B  |  |ENCRYPT |  |S  |  |Decrypt  |  |B  |             .-.
                 |R  |  |HELD    |  |E  |  |& get    |  |R  |  .-------.  |U|
                 |O S|  |USER    |  |R S|  |resource |  |O S|  |Decrypt|  |S|
                 |W S|->|REQUEST,|->|V S|->|---------|->|W S|->|& Give |->|E|
                 |S L|  |Session |  |E L|  |Encrypt  |  |S L|  |to User|  |R|
                 |E  |  |ID      |  |R  |  |Response |  |E  |  `-------'  `-'
                 |R  |  `--------'  |   |  `---------'  |R  |
                 `---'              `---'               `---'

                 .---.              .---.  .---------.  .---.
.-.  .--------.  |B  |  .--------.  |S  |  |Decrypt  |  |B  |             .-.
|U|  |More    |  |R  |  |Encrypt |  |E  |  |& get    |  |R  |  .-------.  |U|
|S|  |Plain   |  |O S|  |User    |  |R S|  |resource |  |O S|  |Decrypt|  |S|
|E|->|Text    |->|W S|->|Request,|->|V S|->|---------|->|W S|->|& Give |->|E|
|R|  |Request |  |S L|  |Session |  |E L|  |Encrypt  |  |S L|  |to User|  |R|
`-'  `--------'  |E  |  |ID      |  |R  |  |Response |  |E  |  `-------'  `-'
                 |R  |  `--------'  |   |  `---------'  |R  |
                 `---'              `---'               `---'
  1. The browser sends the server some randomly generated "challenge" data (if a new connection) or a "Session ID" (if a pre-existing connection), and asymmetric and symmetric ciphers (encryption/decryption algorithms) installed in the browser as plain text.

    A Session ID identifies the pre-established browser session to a server. Think of it as a handle that both parties use to access a recorded secret key (Session Key). If both parties remember the Session ID, then the secret key is already known and need not be regenerated.

    The browser must choose at least one server-authentication and session-key-exchange algorithm (such as RSA or Triple DES), one symmetric key encryption algorithm (such as RC2 or RC4), and one message integrity (hashing) algorithm (such as MD5 or SHA). For example, the browser's CIPHER-CHOICE may be:

    SSL_CK_RC4_128_WITH_MD5
    SSL_CK_RC4_128_EXPORT40_WITH_MD5
    SSL_CK_RC2_128_CBC_WITH_MD5
    SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
    SSL_CK_IDEA_128_CBC_WITH_MD5 
  2. The server sets aside the browser's "challenge" data for the time being. It picks a cipher supported by the browser which is usually the strongest allowable depending on whether you are communicating within the USA or across US borders.

    For example, server CIPHER-KIND may be one of:

    SSL_CK_RC4_128_WITH_MD5
    SSL_CK_RC4_128_EXPORT40_WITH_MD5
    SSL_CK_RC2_128_CBC_WITH_MD5
    SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
    SSL_CK_IDEA_128_CBC_WITH_MD5
    SSL_CK_DES_64_CBC_WITH_MD5
    SSL_CK_DES_192_EDE3_CBC_WITH_MD5  

    The server then sends back the picked cipher, some randomly generated data of its own (call it "connection ID"), server's digital certificate, and the server's SSL version number as plain text.

    A Nonce is a randomly generated value used to defeat "playback" attacks. One party (usually server) randomly generates a nonce ("connection ID) and sends it to the other party. The receiver encrypts it using the agreed upon secret key and returns it to the sender. Because the nonce was randomly generated by the sender this defeats playback attacks because the replayer can't know in advance the nonce the sender will generate. The receiver denies connections that do not have the correctly encrypted nonce.

  3. The browser sets aside the "connection ID" data for the time being. It first checks the server's certificate for validity:
    1. Has the certificate expired? Warn user if yes.
    2. Does the "Distinguished Name" (DN) of the certficate issuer match one of the trusted DN's listed in the browser? (Browser recursively checks the chain of issuers until the answer is yes or no.) Warn user if no.
    3. Is the certificate still the same as issued by the issuer? (Create a message digest - a one-way hash - of the server's certificate and compare it with the value received by decrypting the issuer's signature with the issuer's public key.) Warn user if no.
    4. Does the DN of the server listed on its certificate match the domain name of the server that the browser requested? (Just in case the "man-in-the-middle" is intercepting the server's certificate and sending its own certificate to you.) Warn user if no.

    If the browser reaches this far, the server's certificate is authentic and still valid. So, the server's certificate (not the server itself) can be trusted.

    (If the user is warned, an encrypted and authenticated connection cannot be established with the requested server. The user decides whether to continue or not.)

  4. The browser generates a new master secret data just for this session with the server, encrypts it with the server's public key (obtained from the server's certificate), and sends the encrypted master secret to the server. Since only the real server can have its private key, if the server can decrypt the "master secret", it is the real server itself.

    This "master secret" will be used by both the browser and the server as a seed to create the same "symmetric" keys so that communications can be encrypted at both ends. Remember, any data the server encrypts with its private key can be decrypted by anyone using the server's public key, by definition. So, the server needs an encryption key that only the browser can "decrypt". SSL uses "symmetric" keys for this key exchange because they are much faster (128 to 168 bit long) than using "asymmetric" keys (1024 to 2048 bit long).

  5. The server uses its private key to decrypt the "master secret" data. Now both the browser and the server (and no body else) have the same "master secret" data.
  6. Both the browser and the server use the "master secret" to generate exactly "same" symmetric keys (called "session" keys) for "writing" (encrypting) and "reading" (decrypting) any further communications with each other.

    Each session uses a different session key, so even the theft of one key (however remote) does not result in multiple session eavesdropping or tampering.

    Actually, in SSL, there are four keys that are called session keys: CLIENT-READ-KEY, CLIENT-WRITE-KEY, SERVER-READ-KEY, and SERVER-WRITE-KEY. These are all generated from the "master secret".

  7. The browser sends a message to the server, informing it that any future messages from the browser will be encrypted with the "session" key. It does not send the "session" key also with the message.
  8. The browser then encrypts the "connection ID" originally sent by the server, and a "client-finish" header with the "session" key. It then sends the encrypted data to the server.

    The browser is now done with the "handshake" protocol, and has started the actual SSL session.

    The server decrypts the connection ID with its session key (which is an exact copy of the browser's session key) and compares it with the connection ID it originally sent. If they match, the client has the correct session key.

  9. The server also sends a message to the browser, informing it that any future messages from the server will be encrypted with the "session" key. It does not send the "session" key also with the message.
  10. The server then encrypts the "challenge" data originally sent by the browser, and a "server-finish" header with the "session" key. It then sends the encrypted data to the browser.

    The server is now also done with the "handshake" protocol, and has started the actual SSL session.

    The browser decrypts the "challenge" data with its session key (which is an exact copy of the server's session key) and compares it with the "challenge" data it originally sent. If they match, the server has the correct session key.

  11. SSL session has begun.

    From this point on, if message encryption is active (the default state), SSL encrypts and decrypts the byte stream of the application protocol being used (HTTP etc.) before passing it on to the underlying TCP/IP protocol. This means that all the information in both the HTTP request and the HTTP response is fully encrypted, including the URL the client is requesting, any submitted form contents, any HTTP access authorization information, and all the data returned from the server to the client.

    The browser and the server use the session keys to encrypt and decrypt the data they send to each other and to validate its integrity.

A Digital Certificate?

Other Secure Communication Procedures

References


© Vipan Singla 2000