SSL Sessions and Connections
SSL makes a distinction between a connection and a session. A session represents the negotiated algorithm and the master_secret; that is, a session is established every time the master_secret is negotiated. A connection is the specific communications channel along with the associated keys, cipher choices, and so on.
SSL allows a way to circumvent the handshake, since it is expensive (in CPU time and the number of round trips), if the client and server have already communicated once. Client and server are allowed to establish a new connection using a master_secret from the previous handshake, and each connection has a different set of keys because it is achieved by combining the old master secret with a random number. The first time the client interacts with the server, both the client and server create a session and a connection. The server sends a session_id in the ServerHello message and caches the master_secret for later reference. When the client initiates a new connection with the same server, it uses the session_id in the ClientHello message, and the server resumes the session using the session_id in the ServerHello . The rest of the handshake is skipped ; this is much faster because it re-uses previously processed key material. So far you have seen how the server is authenticated; however, SSL allows the authentication of the client as well, which is described in Figure 22-5. The server initializes the authentication by requesting a certificate (via the CertificateRequest message). The client sends a Certificate message and a CertificateVerify message (with the private key associated with the certificate) to identify itself. If the client has no certificate, a Certificate message with no certificates should be sent, the server may then decide to continue without authentication, or with other means of authentication; otherwise , the server sends a fatal handshake_failure .  Figure 22-5: SSL Handshake with client authentication The SSL session is stateful , meaning that the client and server have synchronized states between each other. SSL performance is slow, especially compared to TCP connections. The main factor is the cryptography because it is computationally expensive and it affects the performance because each data fragment is encrypted. Therefore, fragmenting the data into small pieces decreases performance and if the data to be transmitted is large, cryptography is the main factor affecting performance. Also, the choice of the algorithms used during the handshake phase affects performance; you have to choose between a fast algorithm and a strong one. For example, RSA with 1024 bits is about four times slower than the one with 512 bits.
SSL/TLS modesWhen SSL was designed, U.S. export regulations restricted the size of keys that could be used by applications exported from the U.S. Therefore, SSL was designed to have 1024-bit and 512-bit key exchanges to allow the option of strong cryptography providing maximum security while still remaining exportable. SSL v3 and TLS incorporate Ephemeral RSA for communication to an exportable client. The server generates a 512-bit key and associates it with its strong key; for domestic clients it just uses the strong key. The Ephemeral RSA mode has the ServerKeyExchange message to transmit the signed RSA key, and the client verifies the server's signature. The other mode for SSL v3 and TLS is the Server Gated Security (Microsoft's Server Gated Cryptograph [SGC] or Netscape's Step-Up). Exceptions to the export regulations were allowed so that exportable clients could communicate with secure servers when absolutely necessary - such as in financial applications. The server has a certificate; this certificate identifies the server as able to engage in strong cryptography with exportable clients. Very few trustworthy Certificate Authorities (CAs), such as Verisign, issue this certificate. During the handshake, the client offers weak ciphers, and the server presents its certificate. The client verifies the server and confirms that more secure communication is appropriate; the client initiates a second handshake by offering strong ciphers in the ClientHello message. Therefore, SSL v3 and TLS have two modes: Ephemeral RSA and Server Gated Security. SSL and authenticationSo far we have discussed RSA because it is the dominant public algorithm, but SSL v3 supports a number of other ciphers such as DSS and DH, both of which are mandatory in TLS. The TLS standard specifies DH/DSS key exchange and less-used cipher suites that use Elliptic Curves, Kerberos, and Fortezza algorithms. Unlike RSA, which can be used for digital signature and key agreement, DH can only be used for key agreement and DSS for digital signatures. So, DSS and DH are typically used together. One way that DSS and DH are used together is for the server to generate a temporary DH key, sign it with DSS key, and transmit the signed key using the ServerKeyExchange message. The client uses the DH key for key agreement. Another way to use the DSS/DH combination is to use DH keys as fixed keys: The server has a certificate signed with DSS and that contains the DH key; the client uses the DH key in the certificate for key agreement. For the key agreement, the client and server must be able to compute the shared DH secret. For that, they need their own DH key and the other side's public key. For this to happen, the client gets the server's DH key and generates a DH key in the same family - unless it already has one. The client then sends its public key in the ClientKeyExchange message. The DH secret is used as the pre_master_secret, and the rest of the connection is the same as with RSA. Elliptic Curve (EC) ciphers use points in an elliptic curve but no cipher suites - so far - have been standardized. Kerberos is a symmetric key authentication system. It uses a central server trusted by the entities in the system, and the ticket is used to encrypt the pre_master_secret . The ClientKeyExchange contains both the ticket and the encrypted pre_master_secret . The server extracts the shared key from the ticket and decrypts the pre_master_secret . The process continues as in the previous cases.
The Fortezza card is a U.S.-government-designed cryptographic token that uses Key Exchange Algorithm (KEA) for the key agreement and SKIPLACK (a block cipher) for the block encryption algorithm. Fortezza cards were specified in SSL v3 but removed for TLS.
 Java Security Solutions ISBN: 0764549286
EAN: 2147483647 Year: 2001
Pages: 222 Authors: Rich Helton, Johennie Helton
flylib.com © 2008-2017. If you may any questions please contact us: flylib@qtcs.net |
