| June 2000
> | Magic -SSL Dear Developer, We are happy to introduce SSL enhancement for Magic Requester . This feature is integrated in Magic Broker 8.30-7 and above. Overview How does SSL work in Magic? SSL Magic Setting Known Problems Appendix A- SSL documentation Appendix B – List of Cipher Suites Overview SSL stands for Secure Sockets Layer. It was developed by Netscape for use between clients and servers. SSL layers on top of any reliable transport protocol and can run under application protocols such as HTTP, FTP and telnet. SSL 3.0, the most widely used socket-level security protocol on the Internet; is supported by all major Web servers and most other Internet-accessible services. For more information about SSL see Appendix A. Magic has implemented a SSL by using Baltimore C/SSL v2.1. With the current SSL directory magic supplies 3 root certificates - for Baltimore,Thawte and Verisign (*.pem) that can be used for requests encryption. However, user can use it’s own certificate files according to listed instructions. Note : Magic SSL supports only Thawte,Verisign and Baltimore certificates formats. How does SSL work in Magic? SSL functionality has been implemented at the requester level (Mgrqgnrc.dll) so every request that will be sent through any of Magic’s code partitioning components will be secured (upon request). There is no difference in the SSL implementation between a Synchronic or an Asynchronic request, between requests for loading or downloading an engine, or among any of the functions that investigate the Broker. The following figure demonstrates the messaging path from end to end. The SSL component was built into the Mgrqgnrc.dll, and it ensures that all messages from every node to every node will be secured. The Mgrqgnrc.dll/SSL component will be executed according to the values in the Mgreq.ini -[SSL] section. It is very important that in a complicated environment that involves several Mgreq.ini files, all of them will be set according to the same set of [SSL] values. (See the “Error Codes” section.). ** It is recommended to use the same Mgreq.ini . This can be done by setting the /script alias to the same directory of Magic. The only connection that is not covered by Magic SSL is the one between the Browser and the Web server, which is handled by the Browser itself. Partitioning API calls External calls to the Magic Broker API functions will have the same SSL functionality as in the Magic requesting mechanism. Remember: Other Middleware such as Mq, Md, and CORBA will not be affected. The SSL protocol that was implemented into the Magic components Mgrqmrb, Mgrntw, Mgrqispi, Mgrqcgi, Mgrqnspi, and Mgrqgnrc is completely separate from the one between the Browser and The Web Server. SSL Magic Setting Important! In cases when scripts are not refered to Magic directory, Mgreq.ini and SSL subdirectory must be copied to your Web Server \Scripts directory. 3.1.1 Mgreq.ini SSL section 3.1.2 SSL Directory 3.1.3 Error Codes 3.1.4 MGINIENC.EXE- Encrypting INI Files 3.1.1 Mgreq.ini [SSL] The listed parameters in Mgreq.ini will define if and how Magic will activate SSL [SSL ]
> Parameter | Value
> Active = Y | Default=No Determines whether SSL will be activated or not.
> CipherSuit = Standard_strong | Default=Standart_strong Determines cipher suite type that will be implemented. If the runtime environment involves more than one Mgreq.ini, the cipher suites must be of a compatible type, otherwise an error will be issued. See “Error codes” session. See Appendix A for a detailed explanation about cipher suite. See Appendix B – List of cipher suites
> CertPassword = Magic Secret | Default- MagicSecret Password that is used for certificates. There must be a match between “CertPassword” value and the password that was used when PEM files were created (by Baltimore.bat, Versign.bat or Thawte.bat) otherwise error will be issued (see “Error Codes” session).
> RootCertDir = ssl\root | Default= ssl\root Location of root certificates. Root certificates identify the CAs (Certifications Authorities) that are authorized to produce personal certificates. Each personal certificate specified in ServerPersonalCert and ClientPersonalCert is compared against the list of root certificates, and only if matched, the personal certificate it trusted.
> ServerPersonalCert = ssl\personal\CA vendor name\FileName.pem | Default= ssl\personal\verisign\strongServerRSA.pem During the startup sequence of a server module (i.e. the Broker or an AppServer) the specified authentication certificate is loaded for the server module. Later, when client modules connect to the server, the server automatically and transparently presents this authentication certificate to the client. The ServerPersonalCert is mandatory - the client will not connect unless the server module has a trusted certificate.
> IdentifyClient = Y | Default = Y A server may decide to enforce a similar authentication protocol to make sure that the clients that try to connect can be trusted. By setting this keyword to Y, the server will accept connections only from clients that were started with an authentication certificate.
> ClientPersonalCert = ssl\personal\ CA vendor name\ FileName.pe | Default= ssl\personal\baltimore\strongClientRSA.pem During the startup sequence of a client module (e.g. HTTP requester or the command line requester),The specified authentication certificate is loaded for the client module. A client needs to load an authentication certificate only in case that the server was started with IdentifyClient = Y. A module can act as a SSL client and a SSL server at the same time. For example, an AppServer connecting to the Broker is a client of the Broker, in terms of the SSL protocol. At the same time, an AppServer accepts requests from requesters, meaning it's also a SSL server.
Implications: In case that the Broker was started with IdentifyClient = Y, AppServers must be started with a valid ClientPersonalCert. In case that both the Broker and AppServers were started with IdentifyClient = N, clients are not required to specify an authentication certificate. 3.1.2 SSL Directory A new directory “SSL” will be created under Magic Installation directory. This directory will have 3 subdirectories: SSL/Personal SSL/Root SSL/Util SSL/Personal will include all certificate files (*.pem) that will be used for authentication of the server and client. For example : strongClientDSA.pem,strongClientRSA.pem,strongServerDSA.pem,strongServerRSA.pem SSL/Root This directory will hold the root pem files of the various certificates vendors (e.g : Baltimore, Thawte,Verisign etc…) . Placing a root pem file is mandatory for using other pem files that were produced by the specific vendor. It defines a master certificate format for each one of the vendors. SSL/Util The directory contains the following utilities : Certreq.exe Generates a public and private key, and a certificate request containing that key .This utility is used to create CSR (Certificate Sequence Request). The result file should be sent to a CA vendor to receive a correlate certificate file. (see all parameters on Appendix A) Certsign.exe signs a certificate request, turning it into a certificate Convert.exe Converts private key and certificates among different formats. Use it for converting the certificate file that was received for a CA vendor. It converts certificate files that are downloaded in PKCS1/ PKCS7/PKCS8/ PKCS12 into pem/der or txt formats. (Magic uses Pem formats). Example of creating a new certificate file: 1. In the command line: certreq -alg rsa -str 512 -dn cn=bob -enc pem –req a.req -prv a.p8 -pass " Magic SSL password " Important: Case sensitive! 2. Go to: https://www.thawte.com/cgi/server/test.exe 3. Copy the contents of the fia.req into the CSR box. 4. Choose the "standard" output format. It's a radio button in the page. 5. Press "Generate Test Certificate". 6. Copy the result into a file called a.crt. 7. In the command line: convert -certificate a.crt -pkcs8 a.p8 "Our little Secret" toPEM -pkcs12 a.p12 " Magic SSL password " Important: Case sensitive! 8. Copy a.p12 into two files: StrongServerRsa.pem and StrongClientRsa.pem. Place them both in the directory "Personal". Baltimore.bat, Versign.bat or Thawte.bat This utility allows changing the certificate password that is complied into PEM files. Changing the “–pass” parameter value in all the lines where it appears and execute this Batch file will cause a recreation of all the PEM files in the SSL directory. The password compiled into the PEM files must be the same as the CertificatePassword 3.1.3 Error Codes 1)"Broker is not responding” In case one module was loaded with [SSL]Active=Y while its peer was loaded with [SSL]Active=N, or the SSL session could not be established during the hand shaking between the peers. 2)“SSL Session Denied” When the Cipher suites or the CertificateDir values cannot match between both peers. 3)“SSL Certificate Password mismatch” Appears when the Certificate Password is not equal to the one which was used in the compilation process of the CA certificates file (*.PEM ). 4)"SSL: Unknown cipher suit", When the keyword CipherSuit (in mgreq.ini) is not one of the known cipher suits Resolution: Select a correct value (from the list in the spec). In case cipher suite is empty or unknown , Magic will issue an error and (in a dialog window) and the Broker will be terminated. This behavior is also correct for other situations when one of the parameters is wrong and SSL can not be loaded or the SSL certificate has expired. 5Ñ)"SSL: Unknown certificates directory" Cause: When the keyword CertificateDir (in mgreq.ini) points to an invalid directory Resolution: Select a valid directory. 6)"SSL: Identity certificates not found" There must be certificates in the directory ssl in the root directory of Magic. These certificates depend on the value of the CipherSuit keyword. Log File SSL is active message will be added to the Log file, in case the Broker was loaded with SSL Active=Y 3.1.4 MGINIENC.EXE- Encrypting INI Files This utility enhances Magic security by converting INI files from ASCII format to binary format. The binary INI prevent end users read or change information. MGINIENC should be used to encrypt the original INI file and set an encrypted copy of it in a deployment environment. **MGINIENC should be used only for Mgreq.ini and Mgrb.ini. Syntax : Mginienc.exe <source ini file> <target ini file> For example: Mginienc.exe \development\mgrb.ini \runtime\mgrb.ini 4. Known Problems In case Mgrqcmdl -term=all, engines and broker are shut down, but an error message is displayed ("Broker not responding (code-105)). This happens because BrokerTimeout is not big enough (SSL effects communication speed) . To recover the problem increase Mgreq.ini ,BrokerTimeout parmeter to 30 . Appendix A-SSL documentation What is SSL? How does C/SSL work? C/SSL Support Services Generating Test Certificates How Will SSL Affect my Machine's Performance? 1. What is SSL? An SSL session usually involves the use of two separate protocols: The SSL Handshake Protocol. The SSL Record Protocol. The Handshake Protocol initiates an SSL session. This protocol covers authentication of the client, authentication of the server, agreement on which symmetric algorithm is to be used, and agreement on the key to be used with that algorithm. The Record Protocol handles the transmission of data during an SSL session. Four different kinds of messages can be sent: Application Data Alert Change Cipher Spec Handshake Once a message is passed to an SSL application, it is processed and put into a message block consisting of several fields. The most important of these fields are the encrypted content and the Message Authentication Code, a kind of simplified digital signature that guarantees the integrity of the whole data packet. The Message Authentication Code consists of a hash of: The encryption key, which guarantees authenticity because only the sender and recipient know what this key is. The unencrypted message data, which guarantees data integrity. The message ID, which prevents replay attacks. When the connection is closed and the session is terminated, C/SSL automatically sends the correct termination-of-session messages. To implement SSL in Magic, MSE has purchased the Baltimore C/SSL v2.1 software package. For more information on this package, see www.baltimore.com. C/SSL Supported platforms: Win32 Linux Sun Solaris HP-UX C/SSL is a powerful cryptographic toolkit that allows you to develop SSL and TLS-secured Internet and Intranet applications. C/SSL is fully compliant with version 3.0 of SSL and version 1.0 of TLS 2. How does C/SSL work? C/SSL defines support services that define the parameters under which the SSL or TLS session will be established. Among these parameters are the cipher-suites to use, the level of client authentication to require, and containers for user identities (private key and certificate chain) and certificates (trusted CA certificates). 3. C/SSL Support Services Before you can establish a C/SSL session with a remote host, you must decide what cipher suites you will accept, such as export-crippled RSA with 40-bit RC4 (weak), or full-strength Diffie-Hellman with 168-bit triple-DES (strong), and what Certification Authorities you will trust, and so forth. A cipher suite is an object that specifies the asymmetric, symmetric, and hash algorithms that will be used to secure an SSL connection. The asymmetric algorithm is used to verify the identify of the server (and optionally, that of the client), and to securely exchange secret key information. The symmetric algorithm is used to encrypt the bulk of data transmitted across the SSL connection. The hash algorithm is used to protect transmitted data against modification during transmission. There are five different strengths of cipher suites. These are: Export-strength: These suites contain 512-bit asymmetric algorithms (RSA or Diffie-Hellman) combined with 40-bit symmetric algorithms (RC2-40, RC4-40, DES-40) and either the SHA or MD5 hash algorithm. Non-export-strength: These are 1024+-bit asymmetric algorithms (RSA or Diffie-Hellman) combined with symmetric algorithms of at least 56 bits (DES, triple DES, IDEA, RC4-128) and either SHA or MD5. Strong: These are 1024+-bit asymmetric algorithms (RSA or Diffie-Hellman) combined with 128-bit+ symmetric algorithms (triple DES, IDEA, RC4-128) and either SHA or MD5. Mixed-strength: These cipher suites contain a full combination of all of the above. Export-1024-strength: These cipher suites are experimental suites supporting recently-exportable 1024-bit asymmetric and 56-bit symmetric algorithms. 3.1 Cipher Suite Key Exchange When choosing cipher suites, in addition to strength, you can choose the asymmetric algorithm employed for key exchange; for exchanging the secret information that is used to derive encryption keys. RSA: These non-exportable cipher suites use the public key encoded in the server's certificate to encrypt a piece of secret data for transfer from the client to the server. This secret data is then used at both endpoints to compute encryption keys. The asymmetric operations involved in this key exchange are an encryption, at the client, and a decryption, at the server. RSA-export: These exportable cipher suites have two options: If the server's public key is exportable (<= 512 bits or <= 1024 bits, depending on the cipher suite) and can be used for encryption, then it is used as above. Otherwise, the server generates an exportable temporary RSA key pair and transmits the public key to the client, signed by its certificate, which is the private key associated with the certificate. The client verifies the signature on the public key, and then uses it as above to transmit a secret to the server. The asymmetric operations involved in tkey exchange are: Key pair generation, at the server. Temporary keys can be reused so this cost is amortized over multiple connections. Signing, at the server. Verification, at the client. Encryption, at the client. Decryption, at the server. EDH-DSA/RSA: These cipher suites use Diffie-Hellman for key exchange: The server generates a temporary Diffie-Hellman key pair, and associated parameters, of the appropriate strength (512 bits for normal exportable cipher-suites, otherwise 1024). It then transmits the public key, signed by its certificate, to the client. The client verifies the public key with the server's certificate key, using RSA or DSA depending on the cipher suite, and then generates a key pair. It transmits its public key to the server, and then both client and server derive a shared secret from which they derive the encryption keys. The asymmetric operations involved in this key exchange are: Key pair generation, at the server. Temporary keys can be reused, so this cost is amortized over multiple connections. Signing, at the server. Verification, at the client. Key pair generation, at the client. Secret derivation, at both client and server. ADH: These cipher suites use Diffie=Hellman for key exchange, exactly as above. However, no certificates are used to prevent the server's public key from being compromised during the initial transfer. Your choice of cipher suites will depend upon your environment and security requirements. Typically, the RSA-based cipher suites are more useful than those using Diffie-Hellman, because they are faster and more widely compatible. However, the Diffie-Hellman cipher suites are subject to fewer patent problems. Ephemeral Diffie-Hellman can incur some connection delays because it requires expensive asymmetric parameter and key generation, but pre-generation and reuse of these keys can alleviate these problems somewhat. You should only use Anonymous Diffie-Hellman if you require a non-authenticated connection and understand the possible consequences of such a connection: Certificates are not used, leaving the protocol vulnerable to a man-in-the-middle attack. This service can be defined by the CipherSuit parameter in the MGREQ.INI file. Magic lets users pick any cipher suite listed in Appendix A. 3.2 CA Certificates CA certificates are certificates that supply C/SSL with the identities and public keys of known and trusted certification authorities. When a C/SSL application receives a certificate from a peer, it verifies that certificate against the trusted CA certificates. If the certificate was issued by a trusted CA and the certificate signature matches the CA's public key, then it is accepted. Otherwise C/SSL will issue an error. 3. 3 Certificate Pouches C/SSL manipulates CA certificates using Certificate Pouches. A certificate pouch is a collection of CA certificates and associated verification parameters. A certificate pouch is created, configured, and then installed in a support service (or, optionally, in a particular C/SSL session). To start with, you must load CA certificates from the filesystem and install them in a certificate pouch. Certificates can be loaded from the filesystem in PEM- or DER-encoding, in the following formats: Certificate files: A file containing a single certificate. Certificate sequences: A file containing a group of certificates. Certificate directories: A directory containing a group of certificates. PKCS#7 files: A PKCS#7 (or P7C) file containing a group of certificates. 3.4 Personal Certificates Personal certificates are certificates that supply C/SSL with the identity and public key of the server or client. Personal certificates are always associated with a private key that lets C/SSL perform asymmetric signing and decryption. The combination of a personal certificate and its associated private key is called an Identity in C/SSL. # 4. Generating Test Certificates For SSL to function, the server must have a private key and a certificate that contains the corresponding public key. The key pair, as it is known, need only be generated once. After that it is valid until the certificate expires. This means that your main SSL application does not actually have to perform any key generation. The key generation can be done by a separate application beforehand. There are different approaches to generating your key pair and creating a certificate from the public key: Get the CA to generate the key pair and certificate, and then send them to you. Generate the key pair locally. Create a "certificate request" containing your private key and send it to the CA. If you are maintaining a network with several servers, generate all their key pairs centrally, get them all certified, and distribute them all simultaneously. We would usually recommend generating the key pair locally. This ensures that the private key data only ever exists on your machine, which is obviously much better for security purposes. It is also the situation that SSL was designed for. However, it means that every server individually has to seed its own random number generator. The C/SSL package includes a number of command-line applications for your platform which will generate your key pair and provide a basic level of pass-phrase protection for your private key. These are: certreq - generates a public and private key, and a certificate request containing that key certsign - signs a certificate request, turning it into a certificate convert - converts private keys and certificates among different formats Note: Note: Under the terms of the license agreement, you may not use these applications to construct a commercial Certificate Authority. In general, we recommend that you use these applications purely for testing purposes, and that your users obtain their certificates from some existing CA when your system goes live. The whole point of certificates is to automate trust, and this only works if the CA's private key is rigorously protected (for example, if all signing is carried out in hardware) and you can be sure that due diligence has been exercised before a certificate was issued. A commercial CA will be able to guarantee this; you may not be. This chapter provides a brief guide to the three command-line applications that you can use to generate test certificates. You can also find a script file that runs the applications in makecerts.sh (Unix) or makecerts.bat (Windows). Remember! Signing is done with the private key and verification is done with the public key. The public key is included in the certificate, the private key must be kept secure. ## 4.1 Certreq - Generate a Certificate Request Generating a certificate takes two steps: The end-user must generate a public and private key, construct a certification request containing the public key and information about the end-user, and send it to the CA. The CA must sign the certificate. The application `certreq` allows you to generate your key pair and certificate request. It runs from the command line with the following possible arguments (flags are in bold; options for arguments to the flags are in italics): -rnd filename: gives the name of a file or stream to read random seed data from. OPTIONAL. -alg (rsa|dsa): generate a key pair for the specified algorithm. MANDATORY. -param filename: gives the name of a certificate to read community parameters from for DSA (this is explained in more detail below). OPTIONAL. -prv filename: gives the name of the file to write the PKCS#8- encoded private key to. MANDATORY. -pass passphrase: specifies a passphrase under which to encrypt the private key. OPTIONAL. -enc (der|pem): specifies DER (binary) or PEM (printable-character) encoding for the certificate request and private key. The information content of the two forms of file is exactly the same; PEM is simply a base-64 encoded DER file, and is easier to transport over e-mail or the clipboard. MANDATORY. -str number: strength of the key, given as the length in bits. Sensible values for RSA and DSA are 768, 1024 and 1536; anything longer gives too much of a performance hit, anything shorter is insufficiently secure. However, for use withexport RSA cipher suites, you may want to create a weak 512-bit RSA certificate anyway. MANDATORY -req filename: gives the name of the file to write the certificate request to. The convention followed in Baltimore is that this filename should end in .req. MANDATORY. -dn distinguished-name: The Distinguished Name of the applicant. This is discussed in more detail in the next section Example 1: An RSA Request: Distinguished Names. If this flag is not specified, the application will prompt you to enter your Dname in sections, which is probably the easiest way of entering it unless you have a specific need to run the application entirely from the command line. The `certreq` application outputs a format of certificate request known as PKCS#10. This request is signed with the private key to guarantee its integrity in transit. On receipt, the CA checks the signature, checks the identity of the senders, and issues the certificate. Whether you choose PEM or DER encoded certificate requests, and how you transport the request to the CA, depends on the CA you choose. The command-line CA application provided with C/SSL will read requests in either encoding ## 4.2 Certsign - Sign a Certificate Request The certsign application signs a certificate request produced by certreq. In fact, it will sign any PKCS#10-format, DER or PEM-encoded request. It runs from the command line with the following possible arguments (flags are in bold; options for arguments to the flags are in italics): -rnd filename: gives the name of a file or stream to read random seed data from. OPTIONAL. -prv filename: gives the name of the CA's private key file. MANDATORY. -pass passphrase: gives the passphrase under which the CA's private key is encrypted. OPTIONAL. -req filename: gives the name of the file containing the request. MANDATORY. -enc filename: specifies DER (binary) or PEM (printable-character) encoding for the certificate. The information content of the two forms of certificate is exactly the same. DER takes up less space but is binary data. MANDATORY -crt filename: gives the name of the file to write the certificate to. MANDATORY -ca filename: gives the name of the file with the CA's certificate in it. The issuing CA reads its Dname from this certificate and puts it into the Issuer Dname field of the output certificate. If the certificate is self-signed (if this flag is not specified) the Issuer Dname is the same as the Subject Dname from the cert request. MANDATORY if the certificate is not self-signed; MANDATORY NOT to be specified otherwise. -ext (s|e|c|C)+: specifies that the key in the certificate may be used for signing (s), encryption (e), certificate key signing (c) and whether the certificate is a CA certificate (C). Several options may be specified together; for example, specify cC for CA certs. This facility is not usually needed except for CA certs. OPTIONAL. ## 4.3 Convert - Convert Among Formats The convert application converts among files of different formats; for example, combining certificates and a private key into a PKCS#12 file. It runs from the command line with the following possible arguments (flags are in bold; options for arguments to the flags are in italics): -certificate filename: gives the name of a certificate file to read (PEM- or DER-encoded). Multiple certificates can be loaded by repeating this option. OPTIONAL. -sequence filename: gives the name of a certificate sequence file (i.e., a concatenation of PEM- or DER-encoded certificates) to read. OPTIONAL. -PKCS7 filename: gives the name of a PEM- or DER-encoded PKCS#7 file containing certificates to read (e.g., a P7C file). OPTIONAL. -PKCS1 filename: gives the name of an unencrypted PEM- or DER-encoded PKCS#1 RSA private key file to load. OPTIONAL. -PKCS8 filename passphrase: gives the name of a PEM- or DER-encoded, encrypted PKCS#8 private key file to load. If the passphrase is "" then the key is treated as unencrypted. OPTIONAL. -PKCS12 filename passphrase: gives the name of a PEM- or DER-encoded, encrypted PKCS#12 file containing a private key and certificate chain. OPTIONAL. toDER | toPEM: specifies that files loaded above should be converted to DER (binary) or PEM (printable-character) files as specified below. MANDATORY -certificate filename: writes out the first certificate loaded to the specified file. Multiple certificates can be written by repeating this option. OPTIONAL. -sequence filename: writes out all certificates loaded to the specified file. OPTIONAL. -PKCS1 filename: writes out the RSA private key that was loaded to the specified file, in unencrypted form. OPTIONAL. -PKCS8 filename passphrase: writes out the private key that was loaded to the specified PKCS#8 file, encrypted under the specified passphrase. If the passphrase is "" then the key is not encrypted. OPTIONAL. -PKCS12 filename passphrase: writes out the private key and certificate chain that were loaded to the specified PKCS#12 file, encrypted under the specified passphrase. If the passphrase is "" then the file is written in a special weakly-encrypted form with an empty passphrase, suitable for import into Netscape or Explorer. OPTIONAL. ## 5. How Will SSL Affect my Machine's Performance? The performance problems associated with most HTTP servers are CPU and memory related (this contradicts the common assumption that it is always the network which is the problem). The CPU has to process the HTTP request, write out HTTP headers, log the request, then put it all on the TCP stack. Memory bandwidth is also a problem (a lot of copies have to be done by the OS to put packets onto the network). SSL makes this bottleneck more severe: Bandwidth: SSL adds on average 1K bytes to each transaction. This is not noticeable in the case of large file transfers. Latency: SSL with client authentication requires 2 round trips between the server and the client before the HTTP session can be begin. This would typically mean at least a 500 ms addition to any user's HTTP service time. Bulk Encryption: SSL was designed to have RC4 and MD5 in its cipher suite. These run very efficiently on a 32 bit processor and it is unlikely that implementing these algorithms in hardware will ever be cost effective. However the algorithms DES and SHA-1 have been subject to more cryptographic analysis and would be more likely to be specified in government and banking institutions. Unfortunately DES and Triple-DES do not run as efficiently (Triple-DES being 25 times slower than RC4). Key Exchange: (RSA/Diffie-Hellman) This is where most of the CPU bottleneck on SSL servers occurs. SSL has been optimised to require a minimum amount of RSA operations to set up a secure session (only one RSA decryption to establish a secure session and server authentication). An 1024 bit RSA private key decryption using CST can take nearly a quarter of a second on a Pentium 150 machine. If you are using Diffie-Hellman key exchange, the performance hit will be at least the same on the client as it is on the server. If you are using ephemeral Diffie-Hellman or temporary RSA keys, the server will have to generate them, and this will be a massive performance hit - it can take up to 20 seconds to generate a 1024-bit RSA key pair. The hit can be alleviated to some extent by pregeneration of temporary keys. This topic is covered in the example in the Section A Simple Server Application. Netscape has published figures suggesting that the throughput (in hits/second) of an SSL-enabled server will be as low as 20% that of an unencrypted server. The greatest performance hit occurs when the server and client exchange handshake messages for authentication and key generation/exchange. These operations are performing computationally intensive public key operations. Subsequent hits will use the session restart feature of SSL. This allows the server and client to simply use the previously negotiated secret key. Appendix B – List of Cipher Suites Standard Standard_strong Standard_nonExport Standard_export RSA RSA_strong RSA_nonExport RSA_export RSA_unencrypted EDH EDH_strong EDH_nonExport EDH_export EDH_RSA EDH_RSA_strong EDH_RSA_nonExport EDH_RSA_export EDH_DSA EDH_DSA_strong EDH_DSA_nonExport EDH_DSA_export ADH ADH_strong ADH_nonExport ADH_export X_Standard X_Standard_strong X_Standard_nonExport X_Standard_export1024 X_Standard_export X_Standard_weak X_RSA X_RSA_strong X_RSA_nonExport X_RSA_export1024 X_RSA_export X_RSA_weak X_RSA_unencrypted X_EDH X_EDH_strong X_EDH_nonExport X_EDH_export1024 X_EDH_export X_EDH_weak X_EDH_RSA X_EDH_RSA_strong X_EDH_RSA_nonExport X_EDH_RSA_export X_EDH_RSA_weak X_EDH_DSA X_EDH_DSA_strong X_EDH_DSA_nonExport X_EDH_DSA_export1024 X_EDH_DSA_export X_EDH_DSA_weak X_ADH X_ADH_strong X_ADH_nonExport X_ADH_export X_ADH_weak RSA_with_RC4_128_SHA RSA_with_RC4_128_MD5 RSA_with_IDEA_CBC_SHA RSA_with_3DES_EDE_CBC_SHA RSA_with_DES_CBC_SHA RSA_Export_with_RC4_40_MD5 RSA_Export_with_RC2_CBC_40_MD5 RSA_Export_with_DES40_CBC_SHA RSA_with_Null_SHA RSA_with_Null_MD5 EDH_RSA_with_3DES_EDE_CBC_SHA EDH_RSA_with_DES_CBC_SHA EDH_RSA_Export_with_DES40_CBC_SHA EDH_DSA_with_3DES_EDE_CBC_SHA EDH_DSA_with_DES_CBC_SHA EDH_DSA_Export_with_DES40_CBC_SHA ADH_with_RC4_128_MD5 ADH_with_3DES_EDE_CBC_SHA ADH_with_DES_CBC_SHA ADH_Export_with_RC4_40_MD5 ADH_Export_with_DES40_CBC_SHA RSA_Export1024_with_DES_CBC_SHA EDH_DSA_Export1024_with_DES_CBC_SHA