Topic: A Comparison of TLS 1.1 and TLS 1.2

As stated in the TLS 1.1 and 1.2 protocol definitions (RFC 4346, RFC 5246), “The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications.”  TLS 1.2 is an improvement to the TLS 1.2 standard, but how exactly do they differ?  What was changed in TLS 1.2 to warrant a new version of the protocol?

Listed below are the changes made to both version 1.1 and 1.2 of the TLS protocol.  TLS 1.2 support is slowly making it’s way into existing projects.  The wolfSSL embedded SSL/TLS library fully supports SSL 3.0, TLS 1.0, TLS 1.1, and TLS 1.2.

A.  TLS 1.1
This protocol was defined in RFC 4346 in April of 2006, and is an update to TLS 1.0.  The major changes are:
- The Implicit Initialization Vector (IV) is replaced with an explicit IV to protect against Cipher block chaining (CBC) attacks.
- Handling of padded errors is changed to use the bad_record_mac alert rather than the decryption_failed alert to protect against CBC attacks.
- IANA registries are defined for protocol parameters
- Premature closes no longer cause a session to be non-resumable.

RFC 4346:

B.  TLS 1.2
This protocol was defined in RFC 5246 in August of 2008.  Based on TLS 1.1, TLS 1.2 contains improved flexibility. One of the primary goals of the TLS 1.2 revision was to remove the protocol’s dependency on the MD5 and SHA-1 digest algorithms.  The major differences include:
- The MD5/SHA-1 combination in the pseudorandom function (PRF) was replaced with cipher-suite-specified PRFs.
- The MD5/SHA-1 combination in the digitally-signed element was replaced with a single hash.  Signed elements include a field explicitly specifying the hash algorithm used.
- There was substantial cleanup to the client's and server's ability to specify which hash and signature algorithms they will accept.
- Addition of support for authenticated encryption with additional data modes.
- TLS Extensions definition and AES Cipher Suites were merged in.
- Tighter checking of EncryptedPreMasterSecret version numbers.
- Many of the requirements were tightened
- Verify_data length depends on the cipher suite
- Description of Bleichenbacher/Dlima attack defenses cleaned up.
- Alerts must be sent in many cases
- After a certificate_request, if no certificates are available, clients now MUST send an empty certificate list.
- TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement cipher suite.
- Added HMAC-SHA256 cipher suites.
- Removed IDEA and DES cipher suites.  They are now deprecated.

RFC 5246:

C.  Goals of the TLS Protocol

- Cryptographic security: TLS should be used to establish a secure connection between two parties.
- Interoperability: Independent programmers should be able to develop applications utilizing TLS that can successfully exchange cryptographic parameters without knowledge of one another's code.
- Extensibility: TLS seeks to provide a framework into which new public key and bulk encryption methods can be incorporated as necessary.  This will also accomplish two sub-goals: preventing the need to create a new protocol (and risking the introduction of possible new weaknesses) and avoiding the need to implement an entire new security library.
- Relative efficiency: Cryptographic operations tend to be highly CPU intensive, particularly public key operations.  For this reason, the TLS protocol has incorporated an optional session caching scheme to reduce the number of connections that need to be established from scratch.  Additionally, care has been taken to reduce network activity.

If you would like to read more about SSL or TLS, here are several resources that might be helpful:
TLS - Wikipedia (
SSL versus TLS - What's the Difference? ( … rence.html)
Cisco - SSL: Foundation for Web Security ( … 1/ssl.html)

As always, if you have any questions or would like to talk to the yaSSL team about more information, please contact