[erlang-questions] iPhone unable to connect over SSL after upgrading to R16B01

Ingela Andin ingela.andin@REDACTED
Thu Jul 4 22:24:06 CEST 2013 

For the list too as it is apparently is so easy to push the wrong button!

---------- Forwarded message ----------
From: Ingela Andin <ingela.andin@REDACTED>
Date: 2013/7/3
Subject: Re: [erlang-questions] iPhone unable to connect over SSL after
upgrading to R16B01
To: Ransom Richardson <ransomr@REDACTED>


Hi!

If you have a none Erlang client that is broken then there is not much I
can do about it.  Maybe the client will let you configure which chipher
suites to use so that you can disable the ones it can not handle (but
claims it can)? Maybe there is a patch for the client? The server will pick
the first cipher suite that the client advertises and that it supports. Of
course you can disable cipher suites in the server too but that will of
course disable them for all client connections. Elliptic curve cipher
suites where not supported before R16B01 by Erlang ssl application.

Regards Ingela Erlang/OTP team - Ericsson AB


2013/7/2 Ransom Richardson <ransomr@REDACTED>

>  Ingela, thanks for looking at this. Do you still need additional
> information? The issue seems to be client specific, and I don't have an
> isolated repro. Based on what I'm seeing it looks like {ecdhe_rsa,aes_256_cbc,sha}
> works fine when I connect with a python client, but not when I connect with
> an iOS client. This is the case even if I also support {rsa,aes_256_cbc,sha256},
> which does work with the iOS client. So the iOS client/Erlang R16B01 server
> are choosing an EC cipher that then doesn't work. I think you will see the
> issue if you implement just a basic ssl server and connect with an iOS
> client. Please let me know if I can provide more information.
>
>  Ransom
>
>  ------------------------------
> *From:* erlang-questions-bounces@REDACTED <
> erlang-questions-bounces@REDACTED> on behalf of Andrew Shu <
> talklittle@REDACTED>
> *Sent:* Monday, June 24, 2013 10:49 AM
> *To:* Ingela Andin
> *Cc:* erlang-questions@REDACTED
>
> *Subject:* Re: [erlang-questions] iPhone unable to connect over SSL after
> upgrading to R16B01
>
>  Hi Ingela thanks for troubleshooting this. I ran the openssl server and
> pointed Chromium at https://localhost:4433, using the same certs from the
> Cowboy example.
>
>  It works, so I don't think the web browser client is the issue.
>
>  Here's the long HTML printout by openssl server, when I hit
> https://localhost:4433 using Chromium:
>
>  s_server -accept 4433 -CAfile cowboy-ca.crt -cert server.crt -key
> server.key -www
> Ciphers supported in s_server binary
>
> TLSv1/SSLv3:ECDHE-RSA-AES256-GCM-SHA384TLSv1/SSLv3:ECDHE-ECDSA-AES256-GCM-SHA384
> TLSv1/SSLv3:ECDHE-RSA-AES256-SHA384  TLSv1/SSLv3:ECDHE-ECDSA-AES256-SHA384
> TLSv1/SSLv3:ECDHE-RSA-AES256-SHA     TLSv1/SSLv3:ECDHE-ECDSA-AES256-SHA
> TLSv1/SSLv3:SRP-DSS-AES-256-CBC-SHA  TLSv1/SSLv3:SRP-RSA-AES-256-CBC-SHA
> TLSv1/SSLv3:DHE-DSS-AES256-GCM-SHA384TLSv1/SSLv3:DHE-RSA-AES256-GCM-SHA384
> TLSv1/SSLv3:DHE-RSA-AES256-SHA256    TLSv1/SSLv3:DHE-DSS-AES256-SHA256
> TLSv1/SSLv3:DHE-RSA-AES256-SHA       TLSv1/SSLv3:DHE-DSS-AES256-SHA
> TLSv1/SSLv3:DHE-RSA-CAMELLIA256-SHA  TLSv1/SSLv3:DHE-DSS-CAMELLIA256-SHA
>
> TLSv1/SSLv3:ECDH-RSA-AES256-GCM-SHA384TLSv1/SSLv3:ECDH-ECDSA-AES256-GCM-SHA384
> TLSv1/SSLv3:ECDH-RSA-AES256-SHA384   TLSv1/SSLv3:ECDH-ECDSA-AES256-SHA384
> TLSv1/SSLv3:ECDH-RSA-AES256-SHA      TLSv1/SSLv3:ECDH-ECDSA-AES256-SHA
> TLSv1/SSLv3:AES256-GCM-SHA384        TLSv1/SSLv3:AES256-SHA256
> TLSv1/SSLv3:AES256-SHA               TLSv1/SSLv3:CAMELLIA256-SHA
> TLSv1/SSLv3:PSK-AES256-CBC-SHA       TLSv1/SSLv3:ECDHE-RSA-DES-CBC3-SHA
> TLSv1/SSLv3:ECDHE-ECDSA-DES-CBC3-SHA TLSv1/SSLv3:SRP-DSS-3DES-EDE-CBC-SHA
> TLSv1/SSLv3:SRP-RSA-3DES-EDE-CBC-SHA TLSv1/SSLv3:EDH-RSA-DES-CBC3-SHA
> TLSv1/SSLv3:EDH-DSS-DES-CBC3-SHA     TLSv1/SSLv3:ECDH-RSA-DES-CBC3-SHA
> TLSv1/SSLv3:ECDH-ECDSA-DES-CBC3-SHA  TLSv1/SSLv3:DES-CBC3-SHA
> TLSv1/SSLv3:PSK-3DES-EDE-CBC-SHA
> TLSv1/SSLv3:ECDHE-RSA-AES128-GCM-SHA256
> TLSv1/SSLv3:ECDHE-ECDSA-AES128-GCM-SHA256TLSv1/SSLv3:ECDHE-RSA-AES128-SHA256
>
> TLSv1/SSLv3:ECDHE-ECDSA-AES128-SHA256TLSv1/SSLv3:ECDHE-RSA-AES128-SHA
> TLSv1/SSLv3:ECDHE-ECDSA-AES128-SHA   TLSv1/SSLv3:SRP-DSS-AES-128-CBC-SHA
> TLSv1/SSLv3:SRP-RSA-AES-128-CBC-SHA  TLSv1/SSLv3:DHE-DSS-AES128-GCM-SHA256
> TLSv1/SSLv3:DHE-RSA-AES128-GCM-SHA256TLSv1/SSLv3:DHE-RSA-AES128-SHA256
> TLSv1/SSLv3:DHE-DSS-AES128-SHA256    TLSv1/SSLv3:DHE-RSA-AES128-SHA
> TLSv1/SSLv3:DHE-DSS-AES128-SHA       TLSv1/SSLv3:DHE-RSA-SEED-SHA
> TLSv1/SSLv3:DHE-DSS-SEED-SHA         TLSv1/SSLv3:DHE-RSA-CAMELLIA128-SHA
> TLSv1/SSLv3:DHE-DSS-CAMELLIA128-SHA  TLSv1/SSLv3:ECDH-RSA-AES128-GCM-SHA256
> TLSv1/SSLv3:ECDH-ECDSA-AES128-GCM-SHA256TLSv1/SSLv3:ECDH-RSA-AES128-SHA256
>
> TLSv1/SSLv3:ECDH-ECDSA-AES128-SHA256 TLSv1/SSLv3:ECDH-RSA-AES128-SHA
> TLSv1/SSLv3:ECDH-ECDSA-AES128-SHA    TLSv1/SSLv3:AES128-GCM-SHA256
> TLSv1/SSLv3:AES128-SHA256            TLSv1/SSLv3:AES128-SHA
> TLSv1/SSLv3:SEED-SHA                 TLSv1/SSLv3:CAMELLIA128-SHA
> TLSv1/SSLv3:PSK-AES128-CBC-SHA       TLSv1/SSLv3:ECDHE-RSA-RC4-SHA
> TLSv1/SSLv3:ECDHE-ECDSA-RC4-SHA      TLSv1/SSLv3:ECDH-RSA-RC4-SHA
> TLSv1/SSLv3:ECDH-ECDSA-RC4-SHA       TLSv1/SSLv3:RC4-SHA
> TLSv1/SSLv3:RC4-MD5                  TLSv1/SSLv3:PSK-RC4-SHA
> TLSv1/SSLv3:EDH-RSA-DES-CBC-SHA      TLSv1/SSLv3:EDH-DSS-DES-CBC-SHA
> TLSv1/SSLv3:DES-CBC-SHA              TLSv1/SSLv3:EXP-EDH-RSA-DES-CBC-SHA
> TLSv1/SSLv3:EXP-EDH-DSS-DES-CBC-SHA  TLSv1/SSLv3:EXP-DES-CBC-SHA
> TLSv1/SSLv3:EXP-RC2-CBC-MD5          TLSv1/SSLv3:EXP-RC4-MD5
> ---
> Ciphers common between both SSL end points:
> ECDHE-ECDSA-AES256-SHA     ECDHE-RSA-AES256-SHA
> DHE-RSA-CAMELLIA256-SHA
> DHE-DSS-CAMELLIA256-SHA    DHE-RSA-AES256-SHA         DHE-DSS-AES256-SHA
>
> ECDH-RSA-AES256-SHA        ECDH-ECDSA-AES256-SHA      CAMELLIA256-SHA
>
> AES256-SHA                 ECDHE-ECDSA-RC4-SHA
>  ECDHE-ECDSA-AES128-SHA
> ECDHE-RSA-RC4-SHA          ECDHE-RSA-AES128-SHA
> DHE-RSA-CAMELLIA128-SHA
> DHE-DSS-CAMELLIA128-SHA    DHE-RSA-AES128-SHA         DHE-DSS-AES128-SHA
>
> ECDH-RSA-RC4-SHA           ECDH-RSA-AES128-SHA        ECDH-ECDSA-RC4-SHA
>
> ECDH-ECDSA-AES128-SHA      SEED-SHA                   CAMELLIA128-SHA
>
> RC4-SHA                    RC4-MD5                    AES128-SHA
>
> ECDHE-ECDSA-DES-CBC3-SHA   ECDHE-RSA-DES-CBC3-SHA     EDH-RSA-DES-CBC3-SHA
>
> EDH-DSS-DES-CBC3-SHA       ECDH-RSA-DES-CBC3-SHA
>  ECDH-ECDSA-DES-CBC3-SHA
> DES-CBC3-SHA
> ---
> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
> SSL-Session:
>     Protocol  : TLSv1.1
>     Cipher    : ECDHE-RSA-AES256-SHA
>     Session-ID:
>     Session-ID-ctx: 01000000
>     Master-Key:
> 9D707F79ED6FCF06935AAEC6C52E1E42642B2900EC790BC3BBC602F6DD19619220C3C800E173D75313D83DA6053E6786
>     Key-Arg   : None
>     PSK identity: None
>     PSK identity hint: None
>     SRP username: None
>     Start Time: 1372085057
>     Timeout   : 300 (sec)
>     Verify return code: 0 (ok)
> ---
>    0 items in the session cache
>    0 client connects (SSL_connect())
>    0 client renegotiates (SSL_connect())
>    0 client connects that finished
>    1 server accepts (SSL_accept())
>    0 server renegotiates (SSL_accept())
>    1 server accepts that finished
>    0 session cache hits
>    1 session cache misses
>    0 session cache timeouts
>    0 callback cache hits
>    0 cache full overflows (128 allowed)
> ---
> no client certificate available
>
>
>
> On Mon, Jun 24, 2013 at 8:35 AM, Ingela Andin <ingela.andin@REDACTED>wrote:
>
>> Hi again,
>>
>>  2013/6/23 Andrew Shu <talklittle@REDACTED>
>>
>>> THANK YOU for posting this! This being my first time using Cowboy HTTPS
>>> and secure websockets, I was going crazy trying to figure out why SSL
>>> wasn't working via Chromium on Linux, while curl seemed to handle the
>>> self-signed certificates okay. It wouldn't have occurred to me that it
>>> could be an Erlang bug.
>>>
>>>  After reverting to R16B, and removing all traces of R16B01, everything
>>> seems working.
>>> I wasted a lot of time swapping out SSL certificates to no avail. I
>>> think sticking with R16B is the best, or only, solution for now.
>>>
>>>  I had been getting a Chromium gray error screen with
>>> "ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED". Not the usual "this certificate is
>>> not trusted" red screen.
>>> Firefox choked too. Curl seemed ok, strangely enough.
>>>
>>>
>>  Ok just make sure I run an openssl client against the erlang server
>> too, with the cowboy example (as you
>>  try to connect to an erlang-server with other clients).  This works
>> too. So it seems openssl and curl can connect to the erlang-server but not
>> chrom and firefox?  And the connection fails due to that the client sends
>> and alert.  So atleas this problem seems not to be related to ECDSA
>> certificates. (The missed TODO) .
>>
>>  The other clients could also have issues with ecc-cipher suites, you
>> could try to setting up an openssl server using
>>
>>  openssl s_server -accept 4433  -CAfile ca.crt -cert server.crt -key
>> server.key
>>
>>  and trying the clients to see if they can connect with ecc-ciphers.
>>
>>  The following command must return elliptic curve ciper cuites ECDH*
>> ECDSA*
>>
>>  > openssl ciphers
>>
>>
>>  Regards Ingela Erlang/OTP team - Ericsson AB
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130704/13b4277c/attachment.htm>

More information about the erlang-questions mailing list