SSL acceleration is a method of offloading the processor-intensive public-key encryption algorithms involved in SSL transactions to a hardware accelerator.
How it works
The most computationally expensive part of an SSL session is the SSL handshake, where the SSL server (usually an SSL webserver) and the SSL client (usually a web browser) agree on a number of parameters that establish the security of the connection.
Part of the role of the SSL handshake is to agree on session keys (symmetric keys, used for the duration of a given session), but the encryption and signature of the SSL handshake messages itself is done using asymmetric keys (contained in the certificates), which requires more computational power than the symmetric cryptography used for the encryption/decryption of the session data.
Typically a hardware SSL accelerator will offload processing of the SSL handshake while leaving it to the server software to process the less intense symmetric cryptography of the actual SSL data exchange, but some accelerators handle all SSL operations and terminate the SSL connection, thus leaving the server seeing only unencrypted connections. Modern x86 CPUs support AES encoding and decoding in hardware, using the AES instruction set proposed by Intel in March 2008.
TLS & SSL
TLS 1 was first defined in RFC 2246 in January 1999 as an upgrade to SSL Version 3. Because TLS is essentially an updated form of SSL, TLS session acceleration is essentially the same thing as SSL acceleration.
As stated in the RFC, "the differences between this protocol and SSL 3 are not dramatic, but they are significant enough that TLS 1 and SSL 3 do not interoperate." TLS 1 does include a means by which a TLS implementation can downgrade the connection to SSL 3.
The current version of TLS (1.2) was defined in RFC 5246 in August 2008. It is based on the earlier TLS 1.1 specification.