SSL Digital Certificates
=======================
SSL is an acronym for Secure Sockets Layer, a global standard security technology developed by Netscape in 1994. SSL is all about encryption. It creates an encrypted link between a web server and a web browser. The link ensures that all data passed between the web server and browser remains private and secure and is recognized by millions of consumers by a secure padlock which appears in their browser.
How it works when access a secure web page?
1. A browser requests a secure page (usually https ://).
2. The web server sends its public key with its certificate.
3. The browser checks that the certificate was issued by a trusted party (usually a trusted root CA), that the certificate is still valid and that the certificate is related to the site contacted.
4. The browser then uses the public key, to encrypt a random symmetric encryption key and sends it to the server with the encrypted URL required as well as other encrypted http data.
5. The web server decrypts the symmetric encryption key using its private key and uses the
symmetric key to decrypt the URL and http data.
6. The web server sends back the requested ht ml document and http data encrypted with the symmetric key.
7. The browser decrypts the http data and html document using the symmetric key and displays the information.
Concepts we have to understand
Private Key/Public Key:
The encryption using a private key/public key pair ensures that the data can be encrypted by one key but can only be decrypted by the other key pair. This is sometime hard to understand, but believe me it works. The keys are similar in nature and can be used alternatively: what one key encrypts, the other key pair can decrypt. The key pair is based on prime numbers and their length in terms of bits ensures the difficulty of being able to decrypt the message without the key pairs. The trick in a key pair is to keep one key secret
(the private key) and to distribute the other key (the public key) to everybody. Anybody can send you an encrypted message, which only you will be able to decrypt. You are the only one to have the other key pair, right? In the opposite, you can certify that a message is only coming from you, because you have encrypted it with you private key, and only the associated public key will decrypt it correctly. Beware, in this case the message is not secured you have only signed it. Everybody has the public key, remember!
One of the problems left is to know the public key of your correspondent. Usually you will ask him to send you a non confidential signed message that will contains his public key as well as a certificate.
Message–>[Public Key]–>Encrypted Message –>[Private Key]—>Message
The Certificate:
How do you know that you are dealing with the right person or rather the right web site? Well, someone has taken great length (if they are serious) to ensure that the web site owners are who they claim to be. This someone, you have to implicitly trust: you have his/her certificate loaded in your browser (a root Certificate). A certificate contains information about the owner of the certificate, like e-mail address, owner’s name, certificate usage, duration of validity, resource location or Distinguished Name (DN) which includes the Common Name (CN) (web site address or e-mail address depending of the usage) and the certificate ID of the person who certifies (signs) this information. It contains also the public key and finally a hash to ensure that the certificate has not been tampered with. As you made the choice to trust the person who signs this certificate, therefore you also trust this certificate. This is a certificate trust tree or certificate path. Usually y our browser or application has already loaded the root certificate of well known Certification Authorities (CA) or root CA Certificates. The CA maintains a list of all signed certificates as well as a list of revoked certificates. A certificate is insecure until it is signed, as only a signed certificate cannot be modified. You can sign a certificate using itself; it is called a self signed certificate. All root CA certificates are self signed.
Certificate:
Data:
Version: 3 (0×2)
Serial Number: 1 (0×1)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=ABC, ST=CA, L=US, O=XYZ, OU=INC, CN=XYZ Root
CA/Email=administrator@xyz.org
Validity
Not Before: Jan23 20 05:47:44 2010 GMT
Not After : Jan 22 05:47:44 2012 GMT
Subject: C=ABC, ST=CA, L=US, O=XYZ, OU=INC,
CN=www.xyz.org/Email=administrator@xyz.org
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1 024 bit)
Modulus (1024 bit):
00:ba:54:2c:ab:88:74:aa:6b:35:a5:a9:c1:d0:5a:
9b:fb:6b:b5:71:bc:ef:d3:ab:15:cc:5b:75:73:36:
b8:01:d1:59:3f:c1:88:c0:33:91:04:f1:bf:1a:b4:
7a:c8:39:c2:89:1f:87:0f:91:19:81:09:46:0c:86:
08:d8:75:c4:6f:5a:98:4a:f9:f8:f7:38:24:fc:bd:
94:24:37:ab:f1:1c:d8:91:ee:fb:1b:9f:88:ba:25:
da:f6:21:7f:04:32:35:17:3d:36:1c:fb:b7:32:9 e:
42:af:77:b6:25:1c:59:69:af:be:00:a1:f8:b0:1a:
6c:14:e2:ae:62:e7:6b:30:e9
Exponent: 65537 (0×10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
FE:04:46:ED:A0:15:BE:C1:4B:59:03:F8:2D:0D:ED:2A:E0:ED:F9:2F
X509v3 Authority Key Identifier:
keyid:E6:12:7C:3D:A1:02:E5:BA:1F:DA:9E:37:BE:E3:45:3E:9B:AE:E5:A6
DirName:/C=ABC/ST=CA/L=US/O=XYZ/OU=INC/CN=XYZ Root
CA/Email=administrator@xyz.org
serial:00
Signature Algorithm: md5WithRSAEncrypti on
34:8d:fb:65:0b:85:5b:e2:44:09:f0:55:31:3b:29:2b:f4:fd:
aa:5f:db:b8:11:1a:c6:ab:33:67:59:c1:04:de:34:df:08:57:
2e:c6:60:dc:f7:d4:e2:f1:73:97:57:23:50:02:63:fc:78:96:
34:b3:ca:c4:1b:c5:4c:c8:16:69:bb:9c:4a:7e:00:19:48:62 :
e2:51:ab:3a:fa:fd:88:cd:e0:9d:ef:67:50:da:fe:4b:13:c5:
0c:8c:fc:ad:6e:b5:ee:40:e3:fd:34:10:9f:ad:34:bd:db:06:
ed:09:3d:f2:a6:81:22:63:16:dc:ae:33:0c:70:fd:0a:6c:af:
bc:5a
—–BEGIN CERTIFICATE —–
MIIDoTCCAwqgAwIBAg IBATANBgkqhkiG9w0BAQQFADCBiTELMAkGA1UEBhMCRkox
DTALBgNVBAgTBEZpamkxDTALBgNVBAcTBFN1dmExDjAMBgNVBAoTBVNPUEFDMQww
CgYDVQQLEwNJQ1QxFjAUBgNVBAMTDVNPUEFDIFJvb3QgQ0ExJjAkBgkqhkiG9w0B
CQEWF2FkbWluaXN0cmF0b3JAc29wYWMub3JnMB4XDTAxMTEyMDA1NDc0NFoXDTAy
MTEyMDA1NDc0NFowgYkxCzAJBgNVBAYTAkZKMQ0wCwYDVQQIEwRGaWppMQ0wCwYD
VQQHEwRTdXZhMQ4wDAYDVQQKEwVTT1BBQzEMMAoGA1UECxMDSUNUMRYwFAYDVQQD
Ew13d3cuc29wYWMub3JnMSYwJAYJKoZIhvcNAQkBFhdhZG1pbmlzdHJhdG9yQHNv
cGFjLm9yZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAulQsq4h0qms1pansB
0Fqb+2u1cbzv06sVzFt1cza4AdFZP8GIwDORBPG/GrR6yDnCiR+HD5EZgQlGDIYI
2HXEb1qYSvn49zgk/L2UJDer8RzYke77G5+IuiXa9iF/BDI1Fz02HPu3Mp5Cr3e2
JRxZaa++AKH4sBpsFOKuYudrMOkCAwEAAaOCARUwggERMAkGA1UdEwQCMAAwLAYJ
YIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0 GA1Ud
DgQWBBT+BEbtoBW+wUtZA/gtDe0q4O35LzCBtgYDVR0jBIGuMIGrgBTmEnw9oQLl
uh/anje+40U+m67lpqGBj6SBjDCBiTELMAkGA1UEBhMCRkoxDTALBgNVBAgTBEZp
amkxDTALBgNVBAcTBFN1dmExDjAMBgNVBAoTBVNPUEFDMQwwCgYDVQQLEwNJQ1Qx
FjAUBgNVBAMTDVNPUEFDIFJvb3QgQ0ExJjAkBgkqhkiG9w0BCQEW F2FkbWluaXN0
cmF0b3JAc29wYWMub3JnggEAMA0GCSqGSIb3DQEBBAUAA4GBADSN+2ULhVviRAnw
VTE7KSv0/apf27gRGsarM2dZwQTeNN8IVy7GYNz31OLxc5dXI1ACY/x4ljSzysQb
xUzIFmm7nEp+ABlIYuJRqzr6/YjN4J3vZ1Da/ksTxQyM/K1ute5A4/00EJ+tNL3b
Bu0JPfKmgSJjFtyuMwxw/Qpsr7xa
—–END CERTIF ICATE—–
As you may have noticed, the certificate contains the reference to the issuer, the public key of the owner of this certificate, the dates of validity of this certificate and the signature of the certificate to ensure this certificate hasn’t bee n tampered with. The certificate does not contain the private key as it should never be transmitted in any form whatsoever. This certificate has all the elements to send an encrypted message to the owner (using the public key) or to verify a message signed by the author of this certificate.
The Symmetric key:
Well, Private Key/Public Key encryption algorithms are great, but they are not usually practical. It is asymmetric because you need the other key pair to decrypt. You can’t use the same key to encrypt and decrypt. An algorithm using the same key to decrypt and encrypt is deemed to have a symmetric key. A symmetric algorithm is much faster in doing its job than an asymmetric algorithm. But a symmetric key is potentially highly insecure. If the enemy gets hold of the key then you have no more secret information. You must therefore transmit the key to the other party without the enemy getting its hands on it. As you know, nothing is secure on the Internet. The solution is to encapsulate the symmetric key inside a message encrypted with an asymmetric algorithm. You have never transmitted your private key to anybody, then the message encrypted with the public key is secure (relatively secure, nothing is certain except death and taxes). The symmetric key is also chosen randomly, so that if the symmetric secret key is discovered then the next transaction will be totally different.
Symetric Key–>[Public Key] –>Encrypted Symetric Key –>[Private Key] –>Symetric Key
Encryption algorithm:
There are several encryption algorithms available, using symmetric or asymmetric methods, with keys of various lengths. Usually, algorithms cannot be patented, if Henri Poincare had patented his algorithms, then he would have been able to sue Albert Einstein… So algorithms cannot be patented except mainly in USA. OpenSSL is developed in a country where algorithms cannot be patented and where encryption technology is not reserved to state agencies like military and secret services. During the negotiation between browser and web server, the applications will indicate to each other a list of algorithms that can be understood ranked by order of preference. The common preferred algorithm is then chosen. OpenSSL can be compiled with or without certain algorithms, so that it can be used in many countries where restrictions apply.
The Hash:
A hash is a number given by a hash function from a message. This is a one way function; it means that it is impossible to get the original message knowing the hash. However the hash will drastically change even for the slightest modification in the message. It is therefore extremely difficult to modify a message while keeping its original hash. It is also called a message digest. Hash functions are used in password mechanisms, in certifying th at applications are original (MD5 sum), and in general in ensuring that any message has not been tampered with. It seems that the Internet Engineering Task Force (IETF) prefers SHA1 over MD5 for a number of technical reasons (Cf RFC2459 7.1.2 and 7.1.3).
Signing:
Signing a message, means authentifying that you have yourself assured the authenticity of the message (most of the time it means you are the author, but not necessarily). The message can be a text message, or someone else’s certificate. To sign a message, you create its hash, and then encrypt the hash with your private key; you then add the encrypted hash and your signed certificate with the message. The recipient will recreate the message hash, decrypts the encrypted hash using your well known public key stored in your signed certificate, check that both hash are equals and finally check the certificate.
The other advantage of signing your messages is that you transmit your public key and certificate automatically to all your recipients.
There are usually 2 ways to sign, encapsulating the text message inside the signature (with delimiters), or encoding the message altogether with the signature. This later form is a very simple encryption form as any software can decrypt it if it can read the embedded public key. The advantage of the first form is that the message is human readable allowing any non complaint client to pass the message as is for the user to read, while the second form does not even allow reading part of the message if it has been tampered with.
PassPhrase:
“A passprase is like a password except it is longer”. In the early days passwords on UNIX system were limited to 8 characters, so the term passphrase for longer passwords. Longer is the password harder it is to guess. Nowadays UNIX systems use MD5 hashes which have no limitation in length of the password.
Public Key Infrastructure
The Public Key Infrastructure (PKI) is the software management system and database system that allows to sign certificate, keep a list of revoked certificates, distribute public key,… You can usually access it via a website and/or ldap server. There will be also some people checking that you are who you are… For securing individual applications, you can use any well known commercial PKI as their root CA certificate is most likely to be inside your browser/application. The problem is for securing e -mail, either you get a generic type certificate for your e-mail or you must pay about USD100 a year per certificate/e –mail address. There is also no way to find someone’s public key if you have never received a prior e -mail with his certificate (including his public key).
Establishing Encrypted Communications and Ending it
The most basic function that an SSL client and server can perform is establishing a channel for encrypted communications. Below figure shows the SSL message exchange this operation requires, and below list summarizes the steps in the figure. This section looks at these steps in more detail by considering each message in the exchange. SSL uses 9 messages to establish encrypted communications
image
Figure-1 Negotiation of Encrypted Communications (Steps)
1 Client sends ClientHello message proposing SSL options.
2 Server responds with ServerHel lo message selecting the SSL options.
3 Server sends its public key information in ServerKeyExchange message.
4 Server concludes its part of the negotiation with ServerHello -Done message.
5 Client sends session key information (encrypted with server’ s public key) in ClientKeyExchange message.
6 Client sends ChangeCipherSpec message to activate the negotiated options for all future messages it will send.
7 Client sends Finished message to let the server check the newly activated options.
8 Server sends ChangeCipherSpec message to activate the negotiated options for all future messages it will send.
9 Server sends Finished message to let the client check the newly activated options.
Step1: ClientHello
The ClientHello message starts the SSL communication between the two parties. The client uses this message to ask the server to begin negotiating security services by using SSL.
ClientHello Components
Version: Identifies the highest version of the SSL protocol that the client can support.
RandomNumber: A 32-byte random number used to seed the cryptographic calculations.
SessionID: Identifies a specific SSL session.
CipherSuites: A list of cryptographic parameters that the client can support.
CompressionMethods: Identifies data compression methods that the client can support.
The Version field of the ClientHello message contains the highest version number of SSL that the client can support. The current SSL version is 3.0, and it is by far the most widely deployed on the Internet. (But see the sidebar for information on tls.) Note that a server may assume that the client can support all SSL versions up to and including the value of this field. If, for example, a client sends a version 3.0 ClientHello to a server that only supports version 2.0 of SSL, the server may respond with version 2.0 messages that it expects the client to understand. In such cases, that client can decide to continue with the SSL session using version 2.0functionality, or it can abandon the communication attempt.
The RandomNumber field, as you might expect, contains a random number. This random value, along with a similar random value that the server creates, provides the seed for critical cryptographic calculations. Chapter 4 has the details. The SSL specification suggests that four of this field’s 32 bytes consist of the time and date. The SSL protocol does not require a particular level of accuracy for this value, as it is not intended to provide an accurate time indication. Instead, the specification suggests using the date and time as a way to ensure that the client never uses the same random value twice. This precaution protects against an impostor copying old SSL messages from a legitimate client and reusing them to establish a counterfeit session. The remaining 28 bytes of this value should be a “cryptographically secure” random number. Security is not something we ordinarily associate with randomness, but it is important in this cas e. Most computer programs use a technique known as pseudorandom number generation to create random numbers. When used correctly, this approach does yield numbers that have the appearance of randomness. However, the technique does have a serious flaw when used in a security context: if an attacker knows the exact algorithm and one random value, that attacker can correctly predict all future random values. This knowledge might allow the attacker to anticipate a particular future value and prepare an attack against it. To prevent this type of attack, SSL implementations should use a different technique for generating random numbers; typically, they use one based on cryptographic algorithms.
The next field in the ClientHello message is SessionID. Although all ClientHello messages may include his field, in this example, the field is meaningless and would be empty.
The CipherSuites field allows a client to list the various cryptographic services that the client can support, including exact algorithms and key sizes. The server actually makes the final decision as to which cryptographic services will be used for the communication, but it is limited to choosing from this list.
The CompressionMethods field is, in theory, similar to the Cipher -Suites field. In it, the client may list all of the various data compression methods that it can support. Compression methods are an important part of SSL because encryption has significant consequences on the effectiveness of any data compression techniques. Encryption changes the mathematical properties of information in a way that makes data compression virtually impossible. In fact, if it were possible to compress encrypted data, that would likely indicate a security weakness in the encryption algorithm. For this reason, if two parties are going to employ data compression for a communication, it is important that they compress their data before
encrypting it. The SSL protocol accommodates this behavior by including the capacity for data compression, and by making sure that the compression occurs before encryption. In the current version of SSL, however, no actual compression methods have been defined. This field, therefore, currently is of limited use. In the future, additional compression methods may be defined and added to the tls (but not SSL) specifications.
Step2: ServerHello
When the server receives the ClientHello message, it responds with a ServerHello. As below list shows, the contents of a ServerHello are much the same as a ClientHello. There are a few important differences, though, which we’ll examine in this subsection. In general, where the client makes suggestions in its ClientHello message, the server makes the final decision in its ServerHello.
ServerHello Components
Version: Identifies the version of the SSL protocol to be used for this communication.
RandomNumber: A 32-byte random number used to seed the cryptographic calculations.
SessionID: Identifies the specific SSL session.
CipherSuite: The cryptographic parameters to be used for this communication.
Compression-Method: The data compression method to be used for this communication.
The Version field is the first example of a server making a final decision for the communications. The ClientHello’s version simply identifies which SSL versions the client can support. The ServerHello’ s version, on the other hand, determines the SSL version that the communication will use. A server is not completely free to choose any SSL version, however; it cannot pick a version newer than the latest that the client can support. If the client does not like the server’s choice, it may abandon the communication. As of this writing, nearly all SSL clients and servers support version 3.0 of the SSL protocol.
The RandomNumber field of the ServerHello is essentially the same as in the ClientHello, though this random value is chosen by the server. Along with the client’s value, this number seeds important cryptographic calculations. The server’s value does share the same properties as in the ClientHello. Four of the 32 bytes are the date and time (to avoid repeating random values); the remaining bytes should be created by a cryptographically secure random number generator.
The SessionID field of a ServerHello may contain a value, unlike the ClientHello’s field just discussed. The value in this case uniquely identifies this particular SSL communication, or session. The main reason for explicitly identifying a particular SSL session is to refer to it again later. If the server does not intend the session to ever be reused, it can omit the SessionID field from its ServerHello message.
The CipherSuite field (note that the name is singular, not plural, as in the case of a ClientHello) determines the exact cryptographic parameters, specifically algorithms and key sizes, to be used for the session. The server must select a single cipher suite from among those listed by the client in its ClientHello message.
The CompressionMethod field is also singular for a Se rverHello. In theory, the server uses this field to identify the data compression to be used for the session. Again, the server must pick from among those listed in the ClientHello. Current SSL versions have not defined any compression methods, however, so this field has no practical utility.
Step3: ServerKeyExchange
The server follows its ServerHello message with a ServerKeyExchange message. This message complements the Cipher -Suite field of the ServerHello. While the CipherSuite field indicates the cryptographic algorithms and key sizes, this message contains the public key information itself. The exact format of the key information depends on the particular public key algorithm used. For the rsa algorithm, for example, the server includes the modulus and public exponent of the server’s rsa public key. Note that the ServerKeyExchange message is transmitted without encryption, so that only public key information can be safely included within it. The client will use the server’s public key to encrypt a session key, which the parties will use to actually encrypt the application data for the session.
Step4: ServerHelloDone
The ServerHelloDone message tells the client that the server has finished with its initial negotiation messages. The message itself contains no other information, but it is important to the client, because once the client receives a ServerHelloDone, it can move to the next phase of establishing the secure communications.
Step5: ClientKeyExchange
When the server has finish ed its part of the initial SSL negotiation, the client responds with a
ClientKeyExchange message. Just as the ServerKeyExchange provides the key information for the server, the ClientKeyExchange tells the server the client’s key information. In this case, however, the key information is for the symmetric encryption algorithm both parties will use for the session. Furthermore, the information in the client’s message is encrypted using the public key of the server. This encryption protects the key information as it traverses the network, and it allows the client to verify that the server truly possesses the private key corresponding to its public key. Otherwise, the server won’t be able to decrypt this message. This operation is an important protection against an attacker that intercepts messages from a legitimate server and pretends to be that server by forwarding the messages to an unsuspecting client. Since a fake server won’t know the real server’s private key, it won’t be able to decrypt the ClientKeyExcha nge message. Without the information in that message, communication between the two parties cannot succeed.
Step6: ChangeCipherSpec
After the client sends key information in a ClientKeyExchange message, the preliminary SSL negotiation is complete. At that point, the parties are ready to begin using the security services they have negotiated. The SSL protocol defines a special message—ChangeCipherSpec—to explicitly indicate that the security services should now be invoked. Since the transition to secured communication is critical, and both parties have to get it exactly right, the SSL specification is very precise in describing the process. First, it identifies the set of information that defines security services. That information includes a specific symmetric encryption algorithm, a specific message integrity algorithm, and specific key material for those algorithms. The SSL specification also recognizes that some of that information (in particular, the key material) will be different for each direction of communication. In other words, one set of keys will secure data the client sends to the server, and a different set of keys will secure data the server sends to the client. (In principle, the actual algorithms could differ as well, but SSL does not define a way to negotiate such an option.) For any given system, whether it is a client or a server, SSL defines a write state and a read state. The write state defines the security information for data that the system sends, and the read state defines the security information for data that the system receives. The ChangeCipherSpec message serves as the cue for a system to begin using its security information. Before a client or server sends a ChangeCipherSpec message, it must know the complete security information it is about to activate. As soon as the system sends this message, it activates its write state. Similarly, as soon as a system re- ceives a ChangeCipherSpec from its peer, the system activates its read state. Figures-2 and 3 illustrate this process in more detail. The first shows how the client views the process, while the second takes the server’s perspective.
imageFigure2: Clients build pending cipher suites while using active ones
In both figures, the matrices on the side show the systems’ read and write states. The events showed in black (as opposed to gray) cause the systems to update their states. As the figures indicate, SSL actually defines two separate read and write states for each system.
imageFigure3: SSL servers also build pending cipher suites.
One of the states is active and the second is pending. Both the client and the server, therefore, maintain a total of four different states: the active write state, the pending write state, the active read state, and the pending read state. (The figures use the abbreviations “Act” and “Pnd” for active and pending, respectively.) The figures also show the key elements of a state. They are the encryption algorithm (abbreviated “Encr”), the message integrity algorithm (abbreviated “mac” for Message Authentication Code), and the key material. In figures -2 and 3, the systems agree to use the Data Encryption Standard (des) for symmetric encryption and Message Digest 5 (md5) for message integrity. As the figures show, all systems start out in active states wit h no security services whatsoever. This initial condition is necessary for the systems to begin any communication; until they have negotiated security services and parameters, secure communication is not possible. As the systems exchange SSL messages, they begin building the pending state. First they agree on encryption and message integrity algorithms, then they exchange key information. Only then, when both the client and the server have full pending states, can the systems activate those pending states with ChangeCipherSpec messages. Below list details the client processing that figure 2 illustrates. It describes the steps in the figure that are shown in solid black; those are the steps that result in a change of the client’s states.
Client State Processing
*
Step1 When the client initiates an SSL communication by sending a ClientHello message, it sets both of its active states to null (no security); initially, its pending states are unknown.
*
Step2 When the client receives a ServerHello message, it knows the algorithms that the server has selected for the session. It updates both of its pending states accordingly. Key information for the pending states is still unknown at this point.
*
Step5 Once the client has built and transmitted a ClientK eyExchange message, it knows the key material that will be used for the communication, so it updates the pending states.
*
Step6 When the client sends a ChangeCipherSpec message, it moves its pending write state to the active write state and resets the pending state to unknown. No changes are made to the read states. From this point on, all data the client sends will use DES encryption and MD5 authentication as indicated by the now active write state.
*
Step8 When the client receives a ChangeCipherSpec, it updates the active read state with the pending values and resets the pending read state to unknown. From this point on, the client will expect received data to be secured with DES encryption and MD5 authentication.
Server State Processing
*
Step1 When the server first receives a ClientHello message, it sets both of its active states
to null; its pending states are unknown.
*
Step2 When the server sends its ServerHello message, it knows the algorithms that will be used for the session, and it updates both of its pending states accordingly. Key information for the pending states is still unknown at this point.
*
Step5 Once the server has received a ClientKeyE xchange message, it knows the key material that will be used for the communication, so it updates the pending states appropriately.
*
Step6 When the server receives a ChangeCipherSpec message, it moves its pending read state to the active read state and reset s the pending state to unknown. No changes are made to the write states. from this point on, the server will expect received data to be secured with DES encryption and MD5 authentication.
*
Step8 When the server sends its own ChangeCipherSpec, it updates the active write state with the pending values and resets the pending state to unknown. From this point on, all data the server sends will use DES encryption and MD5 authentication as indicated by the now active write state.
Notice from the figures that one system’s active write state is the same as the other system’s active read state—with one exception. The exception occurs during the transmission of a ChangeCipherSpec active states. The other system, however, does not change its active states until it receives the message. In the interim, the two systems are temporarily out of synchronization.
Step7: Finished
Immediately after sending their ChangeCipherSpec messages, each system also sends a Finished message. The Finished messages allow both systems to verify that the negotiation has been successful and that security has not been compromised. Two aspects of the Finished message contribute to this security. First, as the previous subsection explained, the Finished message itself is subject to the negotiated cipher suite. That means that it is encrypted and authenticated according to that suite. If the receiving party cannot successfully decrypt and verify the message, then clearly something has gone awry with the security negotiation. The contents of the Finished message also serve to protect the security of the SSL negotiation. Each Finished message contains a cryptographic hash of important information about the just-finished negotiation. Below list details the information that is secured by the hash. Notice that protected data includes the exact content of all handshake messages used in the exchange (though ChangeCipher -Spec messages are not considered “handshake” messages in the strict sense of the word, and thus are not included). This protects against an attacker who manages to insert fictitious messages or remove legitimate messages from the communication. If an attacker were able to do so, the client’s and server’s hash calculations would not match, and they would detect the compromise.
Information Authenticated by Finished Message
* Key information
* Contents of all previous SSL handshake messages exchanged by the systems
* A special value indicating whether the sender is a client or server
Step 8&9: Ending Secure Communications
Although as a practical matter it is rarely used (primarily due to the nature of Web sessions), SSL does have a defined procedure for ending a secure communication between two parties. As figure -3 shows, the two systems each send a special ClosureAlert to the other. Explicitly closing a session protects against a runcation attack , in which an attacker is able to compromise security by prematurely terminating a communication. Imagine, for example, that an attack er was able to delete just the second phrase of the following sentence: “Please destroy all the documents, unless you hear from me tomorrow.” The ClosureAlert message helps systems detect such attacks. If a system received the message “Please destroy all documents” but did not receive a ClosureAlert, it would recognize that the complete message may not have arrived. As mentioned, it is not always possible to receive ClosureAlert messages reliably for Web transactions.
=======================
SSL is an acronym for Secure Sockets Layer, a global standard security technology developed by Netscape in 1994. SSL is all about encryption. It creates an encrypted link between a web server and a web browser. The link ensures that all data passed between the web server and browser remains private and secure and is recognized by millions of consumers by a secure padlock which appears in their browser.
How it works when access a secure web page?
1. A browser requests a secure page (usually https ://).
2. The web server sends its public key with its certificate.
3. The browser checks that the certificate was issued by a trusted party (usually a trusted root CA), that the certificate is still valid and that the certificate is related to the site contacted.
4. The browser then uses the public key, to encrypt a random symmetric encryption key and sends it to the server with the encrypted URL required as well as other encrypted http data.
5. The web server decrypts the symmetric encryption key using its private key and uses the
symmetric key to decrypt the URL and http data.
6. The web server sends back the requested ht ml document and http data encrypted with the symmetric key.
7. The browser decrypts the http data and html document using the symmetric key and displays the information.
Concepts we have to understand
Private Key/Public Key:
The encryption using a private key/public key pair ensures that the data can be encrypted by one key but can only be decrypted by the other key pair. This is sometime hard to understand, but believe me it works. The keys are similar in nature and can be used alternatively: what one key encrypts, the other key pair can decrypt. The key pair is based on prime numbers and their length in terms of bits ensures the difficulty of being able to decrypt the message without the key pairs. The trick in a key pair is to keep one key secret
(the private key) and to distribute the other key (the public key) to everybody. Anybody can send you an encrypted message, which only you will be able to decrypt. You are the only one to have the other key pair, right? In the opposite, you can certify that a message is only coming from you, because you have encrypted it with you private key, and only the associated public key will decrypt it correctly. Beware, in this case the message is not secured you have only signed it. Everybody has the public key, remember!
One of the problems left is to know the public key of your correspondent. Usually you will ask him to send you a non confidential signed message that will contains his public key as well as a certificate.
Message–>[Public Key]–>Encrypted Message –>[Private Key]—>Message
The Certificate:
How do you know that you are dealing with the right person or rather the right web site? Well, someone has taken great length (if they are serious) to ensure that the web site owners are who they claim to be. This someone, you have to implicitly trust: you have his/her certificate loaded in your browser (a root Certificate). A certificate contains information about the owner of the certificate, like e-mail address, owner’s name, certificate usage, duration of validity, resource location or Distinguished Name (DN) which includes the Common Name (CN) (web site address or e-mail address depending of the usage) and the certificate ID of the person who certifies (signs) this information. It contains also the public key and finally a hash to ensure that the certificate has not been tampered with. As you made the choice to trust the person who signs this certificate, therefore you also trust this certificate. This is a certificate trust tree or certificate path. Usually y our browser or application has already loaded the root certificate of well known Certification Authorities (CA) or root CA Certificates. The CA maintains a list of all signed certificates as well as a list of revoked certificates. A certificate is insecure until it is signed, as only a signed certificate cannot be modified. You can sign a certificate using itself; it is called a self signed certificate. All root CA certificates are self signed.
Certificate:
Data:
Version: 3 (0×2)
Serial Number: 1 (0×1)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=ABC, ST=CA, L=US, O=XYZ, OU=INC, CN=XYZ Root
CA/Email=administrator@xyz.org
Validity
Not Before: Jan23 20 05:47:44 2010 GMT
Not After : Jan 22 05:47:44 2012 GMT
Subject: C=ABC, ST=CA, L=US, O=XYZ, OU=INC,
CN=www.xyz.org/Email=administrator@xyz.org
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1 024 bit)
Modulus (1024 bit):
00:ba:54:2c:ab:88:74:aa:6b:35:a5:a9:c1:d0:5a:
9b:fb:6b:b5:71:bc:ef:d3:ab:15:cc:5b:75:73:36:
b8:01:d1:59:3f:c1:88:c0:33:91:04:f1:bf:1a:b4:
7a:c8:39:c2:89:1f:87:0f:91:19:81:09:46:0c:86:
08:d8:75:c4:6f:5a:98:4a:f9:f8:f7:38:24:fc:bd:
94:24:37:ab:f1:1c:d8:91:ee:fb:1b:9f:88:ba:25:
da:f6:21:7f:04:32:35:17:3d:36:1c:fb:b7:32:9 e:
42:af:77:b6:25:1c:59:69:af:be:00:a1:f8:b0:1a:
6c:14:e2:ae:62:e7:6b:30:e9
Exponent: 65537 (0×10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
FE:04:46:ED:A0:15:BE:C1:4B:59:03:F8:2D:0D:ED:2A:E0:ED:F9:2F
X509v3 Authority Key Identifier:
keyid:E6:12:7C:3D:A1:02:E5:BA:1F:DA:9E:37:BE:E3:45:3E:9B:AE:E5:A6
DirName:/C=ABC/ST=CA/L=US/O=XYZ/OU=INC/CN=XYZ Root
CA/Email=administrator@xyz.org
serial:00
Signature Algorithm: md5WithRSAEncrypti on
34:8d:fb:65:0b:85:5b:e2:44:09:f0:55:31:3b:29:2b:f4:fd:
aa:5f:db:b8:11:1a:c6:ab:33:67:59:c1:04:de:34:df:08:57:
2e:c6:60:dc:f7:d4:e2:f1:73:97:57:23:50:02:63:fc:78:96:
34:b3:ca:c4:1b:c5:4c:c8:16:69:bb:9c:4a:7e:00:19:48:62 :
e2:51:ab:3a:fa:fd:88:cd:e0:9d:ef:67:50:da:fe:4b:13:c5:
0c:8c:fc:ad:6e:b5:ee:40:e3:fd:34:10:9f:ad:34:bd:db:06:
ed:09:3d:f2:a6:81:22:63:16:dc:ae:33:0c:70:fd:0a:6c:af:
bc:5a
—–BEGIN CERTIFICATE —–
MIIDoTCCAwqgAwIBAg IBATANBgkqhkiG9w0BAQQFADCBiTELMAkGA1UEBhMCRkox
DTALBgNVBAgTBEZpamkxDTALBgNVBAcTBFN1dmExDjAMBgNVBAoTBVNPUEFDMQww
CgYDVQQLEwNJQ1QxFjAUBgNVBAMTDVNPUEFDIFJvb3QgQ0ExJjAkBgkqhkiG9w0B
CQEWF2FkbWluaXN0cmF0b3JAc29wYWMub3JnMB4XDTAxMTEyMDA1NDc0NFoXDTAy
MTEyMDA1NDc0NFowgYkxCzAJBgNVBAYTAkZKMQ0wCwYDVQQIEwRGaWppMQ0wCwYD
VQQHEwRTdXZhMQ4wDAYDVQQKEwVTT1BBQzEMMAoGA1UECxMDSUNUMRYwFAYDVQQD
Ew13d3cuc29wYWMub3JnMSYwJAYJKoZIhvcNAQkBFhdhZG1pbmlzdHJhdG9yQHNv
cGFjLm9yZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAulQsq4h0qms1pansB
0Fqb+2u1cbzv06sVzFt1cza4AdFZP8GIwDORBPG/GrR6yDnCiR+HD5EZgQlGDIYI
2HXEb1qYSvn49zgk/L2UJDer8RzYke77G5+IuiXa9iF/BDI1Fz02HPu3Mp5Cr3e2
JRxZaa++AKH4sBpsFOKuYudrMOkCAwEAAaOCARUwggERMAkGA1UdEwQCMAAwLAYJ
YIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0 GA1Ud
DgQWBBT+BEbtoBW+wUtZA/gtDe0q4O35LzCBtgYDVR0jBIGuMIGrgBTmEnw9oQLl
uh/anje+40U+m67lpqGBj6SBjDCBiTELMAkGA1UEBhMCRkoxDTALBgNVBAgTBEZp
amkxDTALBgNVBAcTBFN1dmExDjAMBgNVBAoTBVNPUEFDMQwwCgYDVQQLEwNJQ1Qx
FjAUBgNVBAMTDVNPUEFDIFJvb3QgQ0ExJjAkBgkqhkiG9w0BCQEW F2FkbWluaXN0
cmF0b3JAc29wYWMub3JnggEAMA0GCSqGSIb3DQEBBAUAA4GBADSN+2ULhVviRAnw
VTE7KSv0/apf27gRGsarM2dZwQTeNN8IVy7GYNz31OLxc5dXI1ACY/x4ljSzysQb
xUzIFmm7nEp+ABlIYuJRqzr6/YjN4J3vZ1Da/ksTxQyM/K1ute5A4/00EJ+tNL3b
Bu0JPfKmgSJjFtyuMwxw/Qpsr7xa
—–END CERTIF ICATE—–
As you may have noticed, the certificate contains the reference to the issuer, the public key of the owner of this certificate, the dates of validity of this certificate and the signature of the certificate to ensure this certificate hasn’t bee n tampered with. The certificate does not contain the private key as it should never be transmitted in any form whatsoever. This certificate has all the elements to send an encrypted message to the owner (using the public key) or to verify a message signed by the author of this certificate.
The Symmetric key:
Well, Private Key/Public Key encryption algorithms are great, but they are not usually practical. It is asymmetric because you need the other key pair to decrypt. You can’t use the same key to encrypt and decrypt. An algorithm using the same key to decrypt and encrypt is deemed to have a symmetric key. A symmetric algorithm is much faster in doing its job than an asymmetric algorithm. But a symmetric key is potentially highly insecure. If the enemy gets hold of the key then you have no more secret information. You must therefore transmit the key to the other party without the enemy getting its hands on it. As you know, nothing is secure on the Internet. The solution is to encapsulate the symmetric key inside a message encrypted with an asymmetric algorithm. You have never transmitted your private key to anybody, then the message encrypted with the public key is secure (relatively secure, nothing is certain except death and taxes). The symmetric key is also chosen randomly, so that if the symmetric secret key is discovered then the next transaction will be totally different.
Symetric Key–>[Public Key] –>Encrypted Symetric Key –>[Private Key] –>Symetric Key
Encryption algorithm:
There are several encryption algorithms available, using symmetric or asymmetric methods, with keys of various lengths. Usually, algorithms cannot be patented, if Henri Poincare had patented his algorithms, then he would have been able to sue Albert Einstein… So algorithms cannot be patented except mainly in USA. OpenSSL is developed in a country where algorithms cannot be patented and where encryption technology is not reserved to state agencies like military and secret services. During the negotiation between browser and web server, the applications will indicate to each other a list of algorithms that can be understood ranked by order of preference. The common preferred algorithm is then chosen. OpenSSL can be compiled with or without certain algorithms, so that it can be used in many countries where restrictions apply.
The Hash:
A hash is a number given by a hash function from a message. This is a one way function; it means that it is impossible to get the original message knowing the hash. However the hash will drastically change even for the slightest modification in the message. It is therefore extremely difficult to modify a message while keeping its original hash. It is also called a message digest. Hash functions are used in password mechanisms, in certifying th at applications are original (MD5 sum), and in general in ensuring that any message has not been tampered with. It seems that the Internet Engineering Task Force (IETF) prefers SHA1 over MD5 for a number of technical reasons (Cf RFC2459 7.1.2 and 7.1.3).
Signing:
Signing a message, means authentifying that you have yourself assured the authenticity of the message (most of the time it means you are the author, but not necessarily). The message can be a text message, or someone else’s certificate. To sign a message, you create its hash, and then encrypt the hash with your private key; you then add the encrypted hash and your signed certificate with the message. The recipient will recreate the message hash, decrypts the encrypted hash using your well known public key stored in your signed certificate, check that both hash are equals and finally check the certificate.
The other advantage of signing your messages is that you transmit your public key and certificate automatically to all your recipients.
There are usually 2 ways to sign, encapsulating the text message inside the signature (with delimiters), or encoding the message altogether with the signature. This later form is a very simple encryption form as any software can decrypt it if it can read the embedded public key. The advantage of the first form is that the message is human readable allowing any non complaint client to pass the message as is for the user to read, while the second form does not even allow reading part of the message if it has been tampered with.
PassPhrase:
“A passprase is like a password except it is longer”. In the early days passwords on UNIX system were limited to 8 characters, so the term passphrase for longer passwords. Longer is the password harder it is to guess. Nowadays UNIX systems use MD5 hashes which have no limitation in length of the password.
Public Key Infrastructure
The Public Key Infrastructure (PKI) is the software management system and database system that allows to sign certificate, keep a list of revoked certificates, distribute public key,… You can usually access it via a website and/or ldap server. There will be also some people checking that you are who you are… For securing individual applications, you can use any well known commercial PKI as their root CA certificate is most likely to be inside your browser/application. The problem is for securing e -mail, either you get a generic type certificate for your e-mail or you must pay about USD100 a year per certificate/e –mail address. There is also no way to find someone’s public key if you have never received a prior e -mail with his certificate (including his public key).
Establishing Encrypted Communications and Ending it
The most basic function that an SSL client and server can perform is establishing a channel for encrypted communications. Below figure shows the SSL message exchange this operation requires, and below list summarizes the steps in the figure. This section looks at these steps in more detail by considering each message in the exchange. SSL uses 9 messages to establish encrypted communications
image
Figure-1 Negotiation of Encrypted Communications (Steps)
1 Client sends ClientHello message proposing SSL options.
2 Server responds with ServerHel lo message selecting the SSL options.
3 Server sends its public key information in ServerKeyExchange message.
4 Server concludes its part of the negotiation with ServerHello -Done message.
5 Client sends session key information (encrypted with server’ s public key) in ClientKeyExchange message.
6 Client sends ChangeCipherSpec message to activate the negotiated options for all future messages it will send.
7 Client sends Finished message to let the server check the newly activated options.
8 Server sends ChangeCipherSpec message to activate the negotiated options for all future messages it will send.
9 Server sends Finished message to let the client check the newly activated options.
Step1: ClientHello
The ClientHello message starts the SSL communication between the two parties. The client uses this message to ask the server to begin negotiating security services by using SSL.
ClientHello Components
Version: Identifies the highest version of the SSL protocol that the client can support.
RandomNumber: A 32-byte random number used to seed the cryptographic calculations.
SessionID: Identifies a specific SSL session.
CipherSuites: A list of cryptographic parameters that the client can support.
CompressionMethods: Identifies data compression methods that the client can support.
The Version field of the ClientHello message contains the highest version number of SSL that the client can support. The current SSL version is 3.0, and it is by far the most widely deployed on the Internet. (But see the sidebar for information on tls.) Note that a server may assume that the client can support all SSL versions up to and including the value of this field. If, for example, a client sends a version 3.0 ClientHello to a server that only supports version 2.0 of SSL, the server may respond with version 2.0 messages that it expects the client to understand. In such cases, that client can decide to continue with the SSL session using version 2.0functionality, or it can abandon the communication attempt.
The RandomNumber field, as you might expect, contains a random number. This random value, along with a similar random value that the server creates, provides the seed for critical cryptographic calculations. Chapter 4 has the details. The SSL specification suggests that four of this field’s 32 bytes consist of the time and date. The SSL protocol does not require a particular level of accuracy for this value, as it is not intended to provide an accurate time indication. Instead, the specification suggests using the date and time as a way to ensure that the client never uses the same random value twice. This precaution protects against an impostor copying old SSL messages from a legitimate client and reusing them to establish a counterfeit session. The remaining 28 bytes of this value should be a “cryptographically secure” random number. Security is not something we ordinarily associate with randomness, but it is important in this cas e. Most computer programs use a technique known as pseudorandom number generation to create random numbers. When used correctly, this approach does yield numbers that have the appearance of randomness. However, the technique does have a serious flaw when used in a security context: if an attacker knows the exact algorithm and one random value, that attacker can correctly predict all future random values. This knowledge might allow the attacker to anticipate a particular future value and prepare an attack against it. To prevent this type of attack, SSL implementations should use a different technique for generating random numbers; typically, they use one based on cryptographic algorithms.
The next field in the ClientHello message is SessionID. Although all ClientHello messages may include his field, in this example, the field is meaningless and would be empty.
The CipherSuites field allows a client to list the various cryptographic services that the client can support, including exact algorithms and key sizes. The server actually makes the final decision as to which cryptographic services will be used for the communication, but it is limited to choosing from this list.
The CompressionMethods field is, in theory, similar to the Cipher -Suites field. In it, the client may list all of the various data compression methods that it can support. Compression methods are an important part of SSL because encryption has significant consequences on the effectiveness of any data compression techniques. Encryption changes the mathematical properties of information in a way that makes data compression virtually impossible. In fact, if it were possible to compress encrypted data, that would likely indicate a security weakness in the encryption algorithm. For this reason, if two parties are going to employ data compression for a communication, it is important that they compress their data before
encrypting it. The SSL protocol accommodates this behavior by including the capacity for data compression, and by making sure that the compression occurs before encryption. In the current version of SSL, however, no actual compression methods have been defined. This field, therefore, currently is of limited use. In the future, additional compression methods may be defined and added to the tls (but not SSL) specifications.
Step2: ServerHello
When the server receives the ClientHello message, it responds with a ServerHello. As below list shows, the contents of a ServerHello are much the same as a ClientHello. There are a few important differences, though, which we’ll examine in this subsection. In general, where the client makes suggestions in its ClientHello message, the server makes the final decision in its ServerHello.
ServerHello Components
Version: Identifies the version of the SSL protocol to be used for this communication.
RandomNumber: A 32-byte random number used to seed the cryptographic calculations.
SessionID: Identifies the specific SSL session.
CipherSuite: The cryptographic parameters to be used for this communication.
Compression-Method: The data compression method to be used for this communication.
The Version field is the first example of a server making a final decision for the communications. The ClientHello’s version simply identifies which SSL versions the client can support. The ServerHello’ s version, on the other hand, determines the SSL version that the communication will use. A server is not completely free to choose any SSL version, however; it cannot pick a version newer than the latest that the client can support. If the client does not like the server’s choice, it may abandon the communication. As of this writing, nearly all SSL clients and servers support version 3.0 of the SSL protocol.
The RandomNumber field of the ServerHello is essentially the same as in the ClientHello, though this random value is chosen by the server. Along with the client’s value, this number seeds important cryptographic calculations. The server’s value does share the same properties as in the ClientHello. Four of the 32 bytes are the date and time (to avoid repeating random values); the remaining bytes should be created by a cryptographically secure random number generator.
The SessionID field of a ServerHello may contain a value, unlike the ClientHello’s field just discussed. The value in this case uniquely identifies this particular SSL communication, or session. The main reason for explicitly identifying a particular SSL session is to refer to it again later. If the server does not intend the session to ever be reused, it can omit the SessionID field from its ServerHello message.
The CipherSuite field (note that the name is singular, not plural, as in the case of a ClientHello) determines the exact cryptographic parameters, specifically algorithms and key sizes, to be used for the session. The server must select a single cipher suite from among those listed by the client in its ClientHello message.
The CompressionMethod field is also singular for a Se rverHello. In theory, the server uses this field to identify the data compression to be used for the session. Again, the server must pick from among those listed in the ClientHello. Current SSL versions have not defined any compression methods, however, so this field has no practical utility.
Step3: ServerKeyExchange
The server follows its ServerHello message with a ServerKeyExchange message. This message complements the Cipher -Suite field of the ServerHello. While the CipherSuite field indicates the cryptographic algorithms and key sizes, this message contains the public key information itself. The exact format of the key information depends on the particular public key algorithm used. For the rsa algorithm, for example, the server includes the modulus and public exponent of the server’s rsa public key. Note that the ServerKeyExchange message is transmitted without encryption, so that only public key information can be safely included within it. The client will use the server’s public key to encrypt a session key, which the parties will use to actually encrypt the application data for the session.
Step4: ServerHelloDone
The ServerHelloDone message tells the client that the server has finished with its initial negotiation messages. The message itself contains no other information, but it is important to the client, because once the client receives a ServerHelloDone, it can move to the next phase of establishing the secure communications.
Step5: ClientKeyExchange
When the server has finish ed its part of the initial SSL negotiation, the client responds with a
ClientKeyExchange message. Just as the ServerKeyExchange provides the key information for the server, the ClientKeyExchange tells the server the client’s key information. In this case, however, the key information is for the symmetric encryption algorithm both parties will use for the session. Furthermore, the information in the client’s message is encrypted using the public key of the server. This encryption protects the key information as it traverses the network, and it allows the client to verify that the server truly possesses the private key corresponding to its public key. Otherwise, the server won’t be able to decrypt this message. This operation is an important protection against an attacker that intercepts messages from a legitimate server and pretends to be that server by forwarding the messages to an unsuspecting client. Since a fake server won’t know the real server’s private key, it won’t be able to decrypt the ClientKeyExcha nge message. Without the information in that message, communication between the two parties cannot succeed.
Step6: ChangeCipherSpec
After the client sends key information in a ClientKeyExchange message, the preliminary SSL negotiation is complete. At that point, the parties are ready to begin using the security services they have negotiated. The SSL protocol defines a special message—ChangeCipherSpec—to explicitly indicate that the security services should now be invoked. Since the transition to secured communication is critical, and both parties have to get it exactly right, the SSL specification is very precise in describing the process. First, it identifies the set of information that defines security services. That information includes a specific symmetric encryption algorithm, a specific message integrity algorithm, and specific key material for those algorithms. The SSL specification also recognizes that some of that information (in particular, the key material) will be different for each direction of communication. In other words, one set of keys will secure data the client sends to the server, and a different set of keys will secure data the server sends to the client. (In principle, the actual algorithms could differ as well, but SSL does not define a way to negotiate such an option.) For any given system, whether it is a client or a server, SSL defines a write state and a read state. The write state defines the security information for data that the system sends, and the read state defines the security information for data that the system receives. The ChangeCipherSpec message serves as the cue for a system to begin using its security information. Before a client or server sends a ChangeCipherSpec message, it must know the complete security information it is about to activate. As soon as the system sends this message, it activates its write state. Similarly, as soon as a system re- ceives a ChangeCipherSpec from its peer, the system activates its read state. Figures-2 and 3 illustrate this process in more detail. The first shows how the client views the process, while the second takes the server’s perspective.
imageFigure2: Clients build pending cipher suites while using active ones
In both figures, the matrices on the side show the systems’ read and write states. The events showed in black (as opposed to gray) cause the systems to update their states. As the figures indicate, SSL actually defines two separate read and write states for each system.
imageFigure3: SSL servers also build pending cipher suites.
One of the states is active and the second is pending. Both the client and the server, therefore, maintain a total of four different states: the active write state, the pending write state, the active read state, and the pending read state. (The figures use the abbreviations “Act” and “Pnd” for active and pending, respectively.) The figures also show the key elements of a state. They are the encryption algorithm (abbreviated “Encr”), the message integrity algorithm (abbreviated “mac” for Message Authentication Code), and the key material. In figures -2 and 3, the systems agree to use the Data Encryption Standard (des) for symmetric encryption and Message Digest 5 (md5) for message integrity. As the figures show, all systems start out in active states wit h no security services whatsoever. This initial condition is necessary for the systems to begin any communication; until they have negotiated security services and parameters, secure communication is not possible. As the systems exchange SSL messages, they begin building the pending state. First they agree on encryption and message integrity algorithms, then they exchange key information. Only then, when both the client and the server have full pending states, can the systems activate those pending states with ChangeCipherSpec messages. Below list details the client processing that figure 2 illustrates. It describes the steps in the figure that are shown in solid black; those are the steps that result in a change of the client’s states.
Client State Processing
*
Step1 When the client initiates an SSL communication by sending a ClientHello message, it sets both of its active states to null (no security); initially, its pending states are unknown.
*
Step2 When the client receives a ServerHello message, it knows the algorithms that the server has selected for the session. It updates both of its pending states accordingly. Key information for the pending states is still unknown at this point.
*
Step5 Once the client has built and transmitted a ClientK eyExchange message, it knows the key material that will be used for the communication, so it updates the pending states.
*
Step6 When the client sends a ChangeCipherSpec message, it moves its pending write state to the active write state and resets the pending state to unknown. No changes are made to the read states. From this point on, all data the client sends will use DES encryption and MD5 authentication as indicated by the now active write state.
*
Step8 When the client receives a ChangeCipherSpec, it updates the active read state with the pending values and resets the pending read state to unknown. From this point on, the client will expect received data to be secured with DES encryption and MD5 authentication.
Server State Processing
*
Step1 When the server first receives a ClientHello message, it sets both of its active states
to null; its pending states are unknown.
*
Step2 When the server sends its ServerHello message, it knows the algorithms that will be used for the session, and it updates both of its pending states accordingly. Key information for the pending states is still unknown at this point.
*
Step5 Once the server has received a ClientKeyE xchange message, it knows the key material that will be used for the communication, so it updates the pending states appropriately.
*
Step6 When the server receives a ChangeCipherSpec message, it moves its pending read state to the active read state and reset s the pending state to unknown. No changes are made to the write states. from this point on, the server will expect received data to be secured with DES encryption and MD5 authentication.
*
Step8 When the server sends its own ChangeCipherSpec, it updates the active write state with the pending values and resets the pending state to unknown. From this point on, all data the server sends will use DES encryption and MD5 authentication as indicated by the now active write state.
Notice from the figures that one system’s active write state is the same as the other system’s active read state—with one exception. The exception occurs during the transmission of a ChangeCipherSpec active states. The other system, however, does not change its active states until it receives the message. In the interim, the two systems are temporarily out of synchronization.
Step7: Finished
Immediately after sending their ChangeCipherSpec messages, each system also sends a Finished message. The Finished messages allow both systems to verify that the negotiation has been successful and that security has not been compromised. Two aspects of the Finished message contribute to this security. First, as the previous subsection explained, the Finished message itself is subject to the negotiated cipher suite. That means that it is encrypted and authenticated according to that suite. If the receiving party cannot successfully decrypt and verify the message, then clearly something has gone awry with the security negotiation. The contents of the Finished message also serve to protect the security of the SSL negotiation. Each Finished message contains a cryptographic hash of important information about the just-finished negotiation. Below list details the information that is secured by the hash. Notice that protected data includes the exact content of all handshake messages used in the exchange (though ChangeCipher -Spec messages are not considered “handshake” messages in the strict sense of the word, and thus are not included). This protects against an attacker who manages to insert fictitious messages or remove legitimate messages from the communication. If an attacker were able to do so, the client’s and server’s hash calculations would not match, and they would detect the compromise.
Information Authenticated by Finished Message
* Key information
* Contents of all previous SSL handshake messages exchanged by the systems
* A special value indicating whether the sender is a client or server
Step 8&9: Ending Secure Communications
Although as a practical matter it is rarely used (primarily due to the nature of Web sessions), SSL does have a defined procedure for ending a secure communication between two parties. As figure -3 shows, the two systems each send a special ClosureAlert to the other. Explicitly closing a session protects against a runcation attack , in which an attacker is able to compromise security by prematurely terminating a communication. Imagine, for example, that an attack er was able to delete just the second phrase of the following sentence: “Please destroy all the documents, unless you hear from me tomorrow.” The ClosureAlert message helps systems detect such attacks. If a system received the message “Please destroy all documents” but did not receive a ClosureAlert, it would recognize that the complete message may not have arrived. As mentioned, it is not always possible to receive ClosureAlert messages reliably for Web transactions.
This is a very technical article which is really hard for me to understand. After reading it multiple times finally I have understood a lot about ssl digital certificates.
ReplyDeletedigital signature certificate