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

[Ingela Anderton Andin]

Hi!

Firstly thank you very much for your efforts. We will have a closer look 
and get back to you with some feedback.

Regards Ingela Erlang/OTP team - Ericsson AB

Andreas Schultz wrote:
> Hi,
>
> 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
>
>   https://github.com/RoadRunnr/otp/compare/tls12
>   https://github.com/RoadRunnr/otp/compare/tls12.patch
>
> 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:
> ================================
>
> ssl_tls1.erl
> ------------
>
> - 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
>
> ssl_handshake.erl
> -----------------
>
> - 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
>
> ssl_connection.erl
> ------------------
> - 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)
>
> ssl_cipher.erl
> --------------
> - 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)
>
> ssl_connection.erl
> ------------------
> - 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
>   from
> - 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.
>
> ssl_cipher.erl
> --------------
>
> 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!
>
>
> Andreas
>
>