[erlang-questions] SSL connection problem

[Phil Calvin]

On 07-06-2015 16:12, Denis Justinek wrote:
> Hello!
>
> For the last few days I stared experiencing problems when connecting
> to Apple Push Notification Service (APNS) with
> Erlangs SSL.
>

Us too! As others have noted, it looks like Apple is testing some
changes on the sandbox. Presumably they'll deploy these to the
production environment sooner or later.

> When trying to connect I encounter the following error:
>
> ...
> 16:53:13.961 <0.1221.0> Undefined Undefined [error] gen_fsm <0.1221.0>
> in state certify terminated with reason: no function clause matching
> ssl_cipher:hash_algorithm(239) line 1196
> 16:53:13.964 <0.1221.0> Undefined Undefined [error] CRASH REPORT
> Process <0.1221.0> with 0 neighbours exited with reason: no function
> clause matching ssl_cipher:hash_algorithm(239) line 1196 in
> gen_fsm:terminate/7 line 611
> 16:53:13.965 <0.174.0> Undefined Undefined [error] Supervisor
> tls_connection_sup had child undefined started with
> {tls_connection,start_link,undefined} at <0.1221.0> exit with reason
> no function clause matching ssl_cipher:hash_algorithm(239) line 1196
> in context child_terminated
>
> Steps to reproduce (you need an APNS certificate for this):
>
>     application:ensure_all_started(ssl).
>     Address = "gateway.sandbox.push.apple.com
> <http://gateway.sandbox.push.apple.com>".
>     Port = 2195.
>     Cert = "cert.pem".
>     CertPass = "*****".
>     Options1 = [{certfile,Cert},{password,CertPass},{mode,binary}].
>     Timeout = 1000.
>     {ok,Socket} = ssl:connect(Address, Port, Options1, Timeout).

We haven't had a chance to test the proposed patches from this thread,
but we were able to work around the issue by forcing the connection to
use TLSv1.1 rather than TLSv1.2. Apple doesn't send the additional
private Signature Hash Algorithms in the CertificateRequest when the
client connects using v1.1, I think because v1.1 doesn't permit this.

The following connects successfully under R16B03-1 by adding
`{versions,['tlsv1.1']}` to the connect options:

     application:ensure_all_started(ssl).
     Address = "gateway.sandbox.push.apple.com".
     Port = 2195.
     Cert = "cert.pem".
     CertPass = "*****".
     Options1 =
[{certfile,Cert},{password,CertPass},{mode,binary},{versions,['tlsv1.1']}].
     Timeout = 1000.
     {ok,Socket} = ssl:connect(Address, Port, Options1, Timeout).

>
> If we try to connect with the same certificate by using OpenSSL from
> command line (s_client) if works fine with no errors.

s_client (at least the version I have, and the version shown below)
doesn't support TLSv1.1 or TLSv1.2 at all, so it doesn't see these
private signature algorithms at all. The s_client in OpenSSL 1.0.2 will
use TLSv1.2 (when prompted with the -tls1_2 flag) and connects
successfully after ignoring the unrecognized algorithms, which sounds
like what the RFC dictates and Ingela's patch does.

...
Requested Signature Algorithms:
RSA+SHA512:DSA+SHA512:ECDSA+SHA512:0xEF+0xEF:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:0xEE+0xEE:0xED+0xED:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms:
RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1

>
> ...
>
> Is this an issue with Erlang SSL module? How can it be mitigated?
>
> This can be reproduced on OSX and Linux - Erlang 17.4.

This workaround is probably not optimal long-term, but I believe TLSv1.1
is generally considered secure (unlike, say, SSLv3) and might be more
acceptable in production than running a patched OTP.

I can provide decrypted Wireshark dissections / pcap files of the
failing handshake if it would be helpful to the developers -- just email
me privately. We'll test the proposed patch soon.

Best,

Phil Calvin