signature_algs TLS 1.2 compatability

There are some TLS servers on the internet (Microsoft IIS) that have a
very strict reading of the tls1.2 rfc (rfc5246 -
https://tools.ietf.org/html/rfc5246) and if they have a certificate
which is incompatible with the default signature_algs then they will
kill the connection. Now people are starting to roll out SHA-256 bit
certs but SHA-256 certs are not compatible with the default
signature_algs. When we try to connect to these servers with tls1.2
the server will close the connection after the client hello.

This issue has already been discussed on erlang-questions here (
http://osdir.com/ml/erlang-questions-programming/2016-07/msg00062.html).
Unfortunately, the solution discussed there is not useful for us. If
you set signature_algs then you must also set the versions to only
tlsv1.2. Since if you have any other versions selected then the erlang
client will ignore the signature_algs parameter.

This is problematic for our use cases for 2 reasons:

1) We are connecting to a server that is 'interesting'. It consists of
load balanced IIS servers. Some of which do not support tlsv1.2 and
some of which support tlsv1.2 but require the signature_algs
extension. The only way to connect to these servers is to set versions
to tlsv1. Thus we are not able to use tlsv1.2 even though some of
their servers support it.

2) In our product we support webhooks for making callbacks to other
people's servers when events happen. It would be nice if all the user
had to supply was their URL and we didn't have to worry them about
what TLS version they needed or whether they needed a special work
around for TLSv1.2. For example presently we either have to force the
TLS version to be 1.2 or (1.1 + 1.0) we can't concurrently support
1.0, 1.1 and 1.2.

I was wondering whether it would be possible to always send the
signature_algs value even if versions contain non tls1.2 versions?
This would solve our problem. If this is considered risky
functionality maybe this could only happen when you explicitly set
signature_algs or it could be put behind some flag.
_______________________________________________
erlang-bugs mailing list
[email protected]
http://erlang.org/mailman/listinfo/erlang-bugs