TLS listeners: support for multiple certificate/key pairs

[michaelklishin]

See e.g. [1] for background. Some algorithms are fixed at key generation time, so supporting a specific list of cipher suites might require support for multiple certificate/key pairs.

Erlang's ssl app does not support multiple pairs at the moment, and neither do Ranch
or our own configuration and ini format schema, so the scope of this right now is primarily to explore the possible solution space.

@essen @dumbbell any thoughts on this?

1. https://security.stackexchange.com/questions/133409/link-between-cipher-suites-and-certificate-key

[essen]

I had no idea this was even possible but it makes sense in the context of that example. I'm not sure how implementing in ssl would look like. For Ranch it's easy, just update types once ssl supports it. Maybe @IngelaAndin can provide more insight.

[essen]

Looked into this a little more:

When we try to connect with an invalid cipher, like ECDSA against an RSA certificate, this is what we get on the server side, along with the handshake failing:

=NOTICE REPORT==== 30-Jul-2019::11:25:54.570194 ===
TLS server: In state hello at tls_handshake.erl:295 generated SERVER ALERT: Fatal - Insufficient Security - no_suitable_ciphers

{error,{tls_alert,{insufficient_security,"received SERVER ALERT: Fatal - Insufficient Security - no_suitable_ciphers"}}}

In the provided link, I cannot get the connection to succeed using RSA, but it works with aRSA. Same applies when trying against Erlang. The link is from 2 years ago but Wikipedia still provides two separate certificates so it still seems useful to do.

The relevant code that needs to be changed to support 2+ certificates is around here:

• https://github.com/erlang/otp/blob/master/lib/ssl/src/ssl_handshake.erl#L946

It is called from here:

• https://github.com/erlang/otp/blob/master/lib/ssl/src/tls_handshake.erl#L287

I could do a proof of concept by just hardcoding the extra certificate and testing against both configured and hard coded certificates.

Alternatively, instead of giving the cert and key in the options, we could give them in the ssl:handshake function http://erlang.org/doc/man/ssl.html#handshake-3 directly. We can use {handshake, hello} to pause the handshake, figure out the connection information we need to select the certificate to use and then resume the handshake. http://erlang.org/doc/man/ssl.html#handshake_continue-3

Here is an example of switching the certificate in ssl:handshake_continue:

1> ssl:start().
ok
2> {ok,S} = ssl:listen(12345, [{certfile, "rsacert.pem"}, {keyfile, "rsakey.pem"}, {handshake, hello}]).
{ok,{sslsocket,nil,
               {#Port<0.6>,
                {config,{ssl_options,tls,
                                     [{3,3}],
                                     verify_none,
                                     {#Fun<ssl.8.60207287>,[]},
                                     #Fun<ssl.9.60207287>,false,false,undefined,1,
                                     <<"rsacert.pem">>,undefined,<<"rsakey.pem">>,
                                     undefined,[],undefined,<<>>,undefined,undefined,
                                     undefined,...},
                        [{packet_size,0},
                         {packet,0},
                         {header,0},
                         {active,false},
                         {mode,binary}],
                        <0.101.0>,undefined,
                        [{packet_size,0},
                         {packet,0},
                         {header,0},
                         {active,false},
                         {mode,binary}],
                        {gen_tcp,tcp,tcp_closed,tcp_error,tcp_passive},
                        tls_connection}}}}
3> {ok,C}=ssl:transport_accept(S). {ok, C2, Ext} = ssl:handshake(C).
{ok,{sslsocket,{gen_tcp,#Port<0.7>,tls_connection,<0.101.0>},
               [<0.104.0>,<0.103.0>]}}
4> {ok, C2, Ext} = ssl:handshake(C).
{ok,{sslsocket,
        {gen_tcp,#Port<0.7>,tls_connection,<0.101.0>},
        [<0.104.0>,<0.103.0>]},
    #{alpn => undefined,
      client_hello_versions =>
          {client_hello_versions,[{3,4},{3,3},{3,2},{3,1}]},
      ec_point_formats => {ec_point_formats,[0,1,2]},
      elliptic_curves =>
          {elliptic_curves,
              [{1,2,840,10045,3,1,7},{1,3,132,0,35},{1,3,132,0,34}]},
      key_share =>
          {key_share_client_hello,
              [{key_share_entry,x25519,
                   <<42,10,158,201,236,145,236,12,76,32,253,214,15,199,
                     155,240,46,95,159,...>>}]},
      next_protocol_negotiation => undefined,
      renegotiation_info => undefined,
      signature_algs =>
          {hash_sign_algos,
              [{sha256,ecdsa},
               {sha384,ecdsa},
               {sha512,ecdsa},
               {unassigned,unassigned},
               {unassigned,unassigned},
               {unassigned,unassigned},
               {unassigned,unassigned},
               {unassigned,unassigned},
               {unassigned,unassigned},
               {unassigned,unassigned},
               {unassigned,unassigned},
               {sha256,rsa},
               {sha384,rsa},
               {sha512,rsa},
               {sha224,ecdsa},
               {sha,ecdsa},
               {sha224,rsa},
               {sha,rsa},
               {sha224,dsa},
               {sha,dsa},
               {sha256,dsa},
               {sha384,...},
               {...}]},
      sni => {sni,"localhost"},
      srp => undefined}}
8> ssl:handshake_continue(C2, [{certfile, "eccert.pem"}, {keyfile, "eckey.pem"}]).
=NOTICE REPORT==== 30-Jul-2019::12:04:21.557254 ===
TLS server: In state hello at tls_handshake.erl:295 generated SERVER ALERT: Fatal - Insufficient Security - no_suitable_ciphers

{error,{tls_alert,{insufficient_security,"received SERVER ALERT: Fatal - Insufficient Security - no_suitable_ciphers"}}}

The server was configured with RSA, the client as well, but in ssl:handshake_continue I switched the certificate to the ECDSA one leading to the connection failure.

Unfortunately ssl:connection_information does not seem to return while in the handshake state. I am not sure the information we want is available from the state, looking for it. If/when I find it I'll be able to produce a proof of concept using sys:get_state, and then we can look into patching ssl properly.

[essen]

Something like this works:

-module(manycerts).
-compile(export_all).

-include_lib("ssl/src/ssl_api.hrl").
-include_lib("ssl/src/ssl_connection.hrl").
-include_lib("ssl/src/tls_handshake.hrl").

run() ->
	ssl:start(),
	{ok, LS} = ssl:listen(22222, [
		{certfile, "eccert.pem"},
		{keyfile, "eckey.pem"},
		{handshake, hello},
		{reuseaddr, true} %% Not required, just makes testing easier.
	]),
	{ok, TS} = ssl:transport_accept(LS),
	{ok, HS, _Ext} = ssl:handshake(TS),
	#sslsocket{pid=[Pid|_]} = HS,
	{user_hello, #state{handshake_env=HandshakeEnv}} = sys:get_state(Pid),
	#handshake_env{hello=ClientHello} = HandshakeEnv,
	#client_hello{client_version=Version, cipher_suites=CipherSuites} = ClientHello,
	io:format("~p ~p~n", [Version, CipherSuites]),
	RSASuites = ssl_cipher:rsa_suites(Version),
	{ok, CS} = case CipherSuites -- RSASuites of
		CipherSuites ->
			ssl:handshake_continue(HS, []);
		%% A matching RSA suite was found, use the RSA certificate.
		_ ->
			ssl:handshake_continue(HS, [
				{certfile, "rsacert.pem"},
				{keyfile, "rsakey.pem"}
			])
	end,
	timer:sleep(1000),
	ssl:close(CS),
	ssl:close(LS).

In the same directory as manycerts.erl do:

Erlang/OTP 22 [erts-10.4.1] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [hipe]

Eshell V10.4.1  (abort with ^G)
1> c(manycerts).
manycerts.erl:2: Warning: export_all flag enabled - all functions will be exported
{ok,manycerts}
2> manycerts:run().
{3,3} [<<19,2>>,
       <<19,3>>,
       <<19,1>>,
       <<"À0">>,
       <<0,159>>,
       <<"̨">>,<<"̪">>,<<"À£">>,
       <<192,159>>,
       <<"Àa">>,<<"ÀS">>,<<"À/">>,
       <<0,158>>,
       <<"À¢">>,
       <<192,158>>,
       <<"À`">>,<<"ÀR">>,<<"À(">>,
       <<0,107>>,
       <<"Àw">>,
       <<0,196>>,
       <<"À'">>,
       <<0,103>>,
       <<"Àv">>,
       <<0,190>>,
       <<192,20>>,
       <<0,57>>,
       <<0,136>>,
       <<192,19>>,
       <<0,51>>,
       <<0,154>>,
       <<0,69>>,
       <<0,157>>,
       <<"À¡">>,
       <<192,157>>, 
       <<"ÀQ">>,
       <<0,156>>,
       <<"À ">>,
       <<192,156>>,
       <<"ÀP">>,
       <<0,61>>,
       <<0,192>>,
       <<0,60>>,
       <<0,186>>,
       <<0,53>>,
       <<0,132>>,
       <<0,47>>,
       <<0,150>>,
       <<0,65>>,
       <<0,7>>,
       <<0,255>>]
ok
3> manycerts:run().
{3,3} [<<19,2>>,
       <<19,3>>,
       <<19,1>>,
       <<"À,">>,<<"Ì©">>,<<"À¯">>,<<"À­">>,<<"À]">>,<<"À+">>,<<"À®">>,
       <<"À¬">>,<<"À\\">>,<<"À$">>,<<"Às">>,<<"À#">>,<<"Àr">>,<<"À\n">>,
       <<"À\t">>,
       <<0,255>>]
ok

And in another terminal:

$ openssl s_client -connect localhost:22222 -cipher 'aRSA' | openssl x509 -text -noout
depth=0 C = US, ST = Texas, O = Nine Nines, OU = Cowboy, CN = localhost
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = US, ST = Texas, O = Nine Nines, OU = Cowboy, CN = localhost
verify error:num=21:unable to verify the first certificate
verify return:1
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            eb:e9:53:4c:b6:7b:92:79
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C = US, ST = Texas, O = Nine Nines, OU = Cowboy, CN = ROOT CA
        Validity
            Not Before: Feb 28 05:23:34 2013 GMT
            Not After : Feb 23 05:23:34 2033 GMT
        Subject: C = US, ST = Texas, O = Nine Nines, OU = Cowboy, CN = localhost
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (1024 bit)
                Modulus:
                    00:cd:b5:b5:1a:31:02:cc:75:1c:fd:64:93:a8:b8:
                    80:1a:a8:c2:35:c7:11:e6:c6:95:4b:ec:a8:cf:64:
                    8f:46:1a:68:c9:fd:3f:a8:1a:d7:e4:16:34:b7:39:
                    a0:a3:3a:13:89:17:c4:e3:00:a2:54:3f:7d:09:cf:
                    83:ae:9f:c5:33:8f:6b:e0:4a:59:76:87:08:a2:fa:
                    6b:98:e9:af:fe:0c:24:a2:3f:79:cd:a0:3a:3c:a3:
                    67:d4:e7:66:0e:9d:a1:c0:9b:17:d9:99:b7:92:96:
                    c6:51:94:f1:8c:39:24:71:c9:a0:51:be:04:8c:be:
                    ea:34:7a:bb:b1:a4:2d:8a:f5
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                1E:A3:4C:42:16:23:C4:F5:72:43:91:03:81:9E:CD:BC:98:C6:D6:EF
            X509v3 Authority Key Identifier: 
                keyid:4A:7D:9F:0A:17:68:E5:2C:10:E6:34:BE:88:B8:4B:86:63:4A:5D:6F

    Signature Algorithm: sha1WithRSAEncryption
         23:1b:a1:54:23:af:1f:2e:fd:f9:37:82:5f:ec:47:4b:5b:03:
         45:9f:fc:d7:12:d8:3c:ec:cb:67:33:9d:d8:15:50:01:b8:4a:
         a6:fe:85:f8:27:d1:da:80:c9:42:a0:85:1a:e3:dc:90:dc:63:
         16:24:b0:63:c8:92:50:df:3f:36:5b:ef:22:77:f6:5d:7a:eb:
         1e:59:88:8c:e1:a7:c0:80:55:d3:ef:47:14:73:9f:0e:6b:67:
         06:97:7a:ca:f2:5e:ed:63:55:26:71:4e:bd:cc:61:97:64:1b:
         a2:9a:00:cd:2d:f7:4f:98:94:62:d9:50:6f:1f:02:27:31:d0:
         17:fe
$ openssl s_client -connect localhost:22222 -cipher 'ECDSA' | openssl x509 -text -noout 
depth=0 C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
verify error:num=18:self signed certificate
verify return:1
depth=0 C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
verify return:1
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            2b:63:13:9d:47:2d:71:ef:c8:99:fc:b2:27:81:82:30:83:8f:cd:24
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
        Validity
            Not Before: Jul 30 09:07:49 2019 GMT
            Not After : Jul 29 09:07:49 2020 GMT
        Subject: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:aa:de:ba:75:85:86:48:a5:6d:4b:30:9c:23:a5:
                    3a:17:3c:b5:62:9d:db:bb:bc:a6:c2:68:a5:9d:6b:
                    5a:a3:6d:92:ed:dd:f3:c8:f4:c6:b4:b5:31:14:14:
                    dd:4f:f8:83:21:35:98:05:e9:e2:ce:10:5d:c1:f5:
                    85:3d:98:de:63
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                85:97:35:4B:AA:61:C6:C2:B5:1C:67:15:97:CB:FD:1A:D9:76:F3:99
            X509v3 Authority Key Identifier: 
                keyid:85:97:35:4B:AA:61:C6:C2:B5:1C:67:15:97:CB:FD:1A:D9:76:F3:99

            X509v3 Basic Constraints: critical
                CA:TRUE
    Signature Algorithm: ecdsa-with-SHA256
         30:44:02:20:13:dc:59:ed:c7:09:62:9d:69:47:12:fe:b2:45:
         66:20:02:90:0d:ca:74:10:4a:6f:1b:48:fb:3f:71:29:46:60:
         02:20:6e:89:62:c3:ce:36:6a:d5:07:91:4a:4c:f2:a5:ec:2d:
         cb:d9:b3:fd:49:45:d2:6a:c2:c1:18:b6:8d:83:11:35

You can see that the certificate issuer, dates etc. are different between the two tries.

It's ugly, using a lot of internal ssl records, and -- probably isn't how we should select the certificate, but it should prove that it is currently already possible and just needs a little push to get into an easier to use state.

[michaelklishin]

@essen thank you very much for digging in!

[essen]

Opened https://bugs.erlang.org/browse/ERL-1016

[essen]

Per the OTP ticket a good patch would add the information we want to the map returned by ssl:handshake. I also opened a ticket in Ranch to natively support handshake/handshake_continue. I will work on both as time allows in the coming weeks and will try to make it in time for OTP-22.1.

[essen]

The Ranch part is done but is probably not necessary for this. The OTP ticket moved toward adding a new option. Feedback is necessary for the option name, and then there's the implementation that needs to be done. I have not been able to look into implementing yet.

[essen]

This has been added to OTP and will be in OTP-25: erlang/otp#5843

I haven't taken a good look at it yet but it sounds like we will be able to resume work on this soon-ish.