OTP 22.1 ssl env protocol_version causes malformed_handshake_data alert

[Danil Zagoskin]

Hi!

While upgrading to OTP 22.1 I've hit an issue with ssl.

The problem: when connecting to a TLS server with a client certificate,
  'ssl_handshake:select_hashsign' may fail with '{error,badarg}',
  causing 'Handshake Failure - malformed_handshake_data'

This happens because 'SupportedHashSigns = undefined',
  which comes from 'ssl:handle_options' in 'ssl_connection:init'.

    signature_algs = handle_option(signature_algs, Opts, undefined, Role,
undefined, HighestVersion),
    ^^^   this returns 'undefined' because
'tls_v1:default_signature_algs(HighestVersion)' returns 'undefined'

And the problem here was 'HighestVersion = {3,1}' which seemed wrong.

When 'versions' option is not passed, HighestVersion is the head of list
returned from 'tls_record:supported_protocol_versions()',
  and that function just maps 'protocol_version' environment parameter.
If the first version specified in environment is low, the 'HighestVersion'
will contain not a highest version.

So, after setting default ssl protocol versions like this:
  'application:set_env(ssl, protocol_version, [tlsv1,'tlsv1.1','tlsv1.2']).'
the client raises an alert while handling '#certificate_request{}' from
server.



OTP 21 and earlier tolerated the version order in 'protocol_version' env,
and the code was like this:
  signature_algs =
handle_hashsigns_option(...,
tls_version(RecordCb:highest_protocol_version(Versions)))


If the new behaviour is intended, it may be useful to describe it in the
man page:
  http://erlang.org/doc/man/ssl_app.html
If 'HighestVersion' should always contain a highest version, the obvious
  (but may be not the best) fix is to sort default versions in
'ssl:handle_options',
  like it is done for specified 'versions'.


Obvious workaround for this is to store 'protocol_version' env parameter
starting from highest version.


-- 
Danil Zagoskin | z@REDACTED
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20191024/c9b196b5/attachment.htm>