[erlang-patches] RFC: experimental TLS-1.2 support

Andreas Schultz <>
Sat Dec 10 17:10:33 CET 2011


I would like to get some feedback and directions for further development
on TLS-1.2 support for the SSL application.

The current state of my work can be found here:

  git fetch git://github.com/RoadRunnr/otp.git tls12


TLS-1.2 connections work, but have only been tested with RSA certificates
and RSA cipher suites. Anything else is broken, I'll explain in a minute why.

This is all very alpha and contains tons of debug output. Ecliptic curve
support is somewhere in my old tree, I'll add it back once the general
implementation is sane.

The changes to the crypto application are not really important and can
eventually be reverted. They are only implementing some additional hashes
that I needed, but that have been added in the meantime.

A quick run through the changes:


- mostly support for the pseudo random functions (PRF) required by TLS-1.2
  TLS-1.0 used MD5+SHA for everything, since TLS-1.2 the minimum is SHA-256
- layout of some key exchange structures has changed


- use variable PRF function in pre- and master secret calculation
- hashes of the handshake are not longer calculated during handshake, instead
  the handshake is recorded and the hash is calculate when need, before
  TLS-1.2 the hash was always MD5+SHA1, now it can be negotiated and TLS-1.2
  has a minimum requirement of SHA-256 (same as PRF)

this breaks TLS-1.0:
- signature structures are now pre-pended by hash and signature id,
  around line 1050
- server_key_exchange uses RSA signatures, before it used a digest,
  around line 363

- moved handshake hashes to handshake history
- extract PRF hashes from negotiated cipher (get_current_connection_state_prf
  and get_pending_connection_state_prf need verification)

- new chiphers
- extended cipher info (breaks API)
- new IV handling for TLS-1.2 block ciphers

Here is what I really need suggestions for:

- general code review (please, no comments yet on the white space changes and debug stuff,
  I'll fix them up later)

- get_current_connection_state_prf/get_pending_connection_state_prf - the PRF depends on
  the negotiated cipher suite, but I'm note sure what the right state is to get that info
- hashsign_algorithm argument in state - this is needed to later support negotiating the
  hash and signature algorithm, does this make sense or should it go somewhere else?

breakage in ssl_handshake.erl - this is the biggest problem

Currently the version of the connection is not passed down to key_exchange and enc_hs.
What is the best way to make them version aware? Move them to ssl_tlsv1, add a TLS version
parameter or a encoding type parameter?

The negotiation of the hash signature algorithm depends on the key material we have, this
is currently done implicitly, but if we ever wish to support negotiating it, then we need
better approach. That includes support for multiple server certificates (RSA, DSA and EC).
My initial idea would be to go through the list of available certificates, build a list
of private key types we have and offer that in the negotiation (probably fall back to some
primary certificate if the connection is lower that TLS-1.2). I have not yet investigated
where that logic should go or if it even makes sense.


cipher info's have been extended to include the PRF hash. For TLS < 1.1, sha256 is treated as
md5+sha. Is that ok? It does break the cipherinfo API!


Dipl. Inform.
Andreas Schultz


------------------ managed broadband access ------------------

Travelping GmbH               phone:           +49-391-8190990
Roentgenstr. 13               fax:           +49-391-819099299
D-39108 Magdeburg             email:       
GERMANY                       web:   http://www.travelping.com

Company Registration: HRB21276 Handelsregistergericht Chemnitz
Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780

More information about the erlang-patches mailing list