Complete client hello (socket)

[drwetter]

all extensions are missing

[drwetter]

For TLS 1.2 Windows SChannel seems to need this.

[drwetter]

@dcooper16 : for TLS 1.2 we still have the EXPERIMENTAL flag.

Q: technically is that still needed with your improvements?

Q: have you tested it? I remember with my old implementation IIS 7.5 server hiccuped.

[dcooper16]

My guess is that the EXPERIMENTAL flag is no longer needed. I've tested it on quite a few servers, including an IIS/8.0 server that didn't work for TLS 1.2 with sockets before, but does now. However, I haven't tested it against an IIS/7.5 server that has been configured to support TLS 1.2.

There is one minor issue that I've discovered with tls_sockets(), but it's not an issue that will affect v2.8.

Currently, socksend_tls_clienthello() sets the supported elliptic curves extension as follows:

          00, 0a,                    # Type: Supported Elliptic Curves , see RFC 4492
          00, 3e, 00, 3c,            # lengths
          00, 01, 00, 02, 00, 03, 00, 04, 00, 05, 00, 06, 00, 07, 00, 08,
          00, 09, 00, 0a, 00, 0b, 00, 0c, 00, 0d, 00, 0e, 00, 0f, 00, 10,
          00, 11, 00, 12, 00, 13, 00, 14, 00, 15, 00, 16, 00, 17, 00, 18,
          00, 19, 00, 1a, 00, 1b, 00, 1c, 00, 1d, 00, 1e,

It just lists all of the named curves specified in Section 5.1.1 of RFC 4492 (plus a few new ones) in numerical order. The "problem" is that it turns out that the order has meaning:

   Items in elliptic_curve_list are ordered according to the client's
   preferences (favorite choice first).

The result is that if tls_sockets() is used to implement run_allciphers() (see https://github.com/dcooper16/testssl.sh/tree/extended_tls_sockets), then the ephemeral key size displayed for ECDHE ciphers may be different than what would be shown if OpenSSL were used. In the case of fpki-graph.fpki-lab.gov, using OpenSSL shows 256 bits for ECDHE ciphers, whereas the sockets version shows 163 bits for ECDHE ciphers (and SSL labs shows 571 bits).

So, there's nothing wrong with the current ordering of the ciphers, but it may make sense to re-order them at some point (e.g., order from weakest to strongest, in the same order as OpenSSL, or in an order that causes the results to match those of SSL labs).

[drwetter]

Oh, I haven't thought about that order. Thx for catching this!

Real browser like Chrome and Firefox nowadays only send a few curves (3 each with recent revisions (see https://drwetter.eu/talks/Dirk%20Wetter%20--%20Calm%20down,%20HTTPS%20is%20not%20a%20VPN.pdf, page 20). I just tried with ``openssl -trace:

      extension_type=elliptic_curves(10), length=58
          sect571r1 (B-571) (14)
          sect571k1 (K-571) (13)
          secp521r1 (P-521) (25)
          brainpoolP512r1 (28)
          sect409k1 (K-409) (11)
          sect409r1 (B-409) (12)
          brainpoolP384r1 (27)
          secp384r1 (P-384) (24)
          sect283k1 (K-283) (9)
          sect283r1 (B-283) (10)
          brainpoolP256r1 (26)
          secp256k1 (22)
          secp256r1 (P-256) (23)
          sect239k1 (8)
          sect233k1 (K-233) (6)
          sect233r1 (B-233) (7)
          secp224k1 (20)
          secp224r1 (P-224) (21)
          sect193r1 (4)
          sect193r2 (5)
          secp192k1 (18)
          secp192r1 (P-192) (19)
          sect163k1 (K-163) (1)
          sect163r1 (2)
          sect163r2 (B-163) (3)
          secp160k1 (15)
          secp160r1 (16)
          secp160r2 (17)

So, in fact, the stronger ones comes first.

In the case of fpki-graph.fpki-lab.gov, using OpenSSL shows 256 bits for ECDHE ciphers,
whereas the sockets version shows 163 bits for ECDHE ciphers (and SSL labs shows 571 bits).

The openssl I compiled shows 570 bits.

163 vs. 57x bits in fact makes a hugh difference. Would you mind change the order accordingly in `socksend_tls_clienthello()``?

BTW: fpki-graph.fpki-lab.gov seems remarkable because only never nginx/apache are able to have multiple curves configured (fpki-graph.fpki-lab.gov seems to be Tomcat though).

At this moment I leave it up to the results of further testing whether in the upcoming stable testssl.sh will have TLS 1.2 enabled per default with sockets

[dcooper16]

It's not surprising that real clients are only offering a few curves. That is consistent with the draft of TLS v1.3 and 4492bis, where most of the curves have been deprecated:

           enum {
               deprecated(1..22),
               secp256r1 (23), secp384r1 (24), secp521r1 (25),
               ecdh_x25519(29), ecdh_x448(30),
               eddsa_ed25519(TBD3), eddsa_ed448(TBD4),
               reserved (0xFE00..0xFEFF),
               deprecated(0xFF01..0xFF02),
               (0xFFFF)
           } NamedCurve;

I can change to order of the curves to match OpenSSL, but I like the idea of ordering them from weakest to strongest, since I want to know if a server I'm testing is willing to choose a weak curve, as fpki-graph.fpki-lab.gov does. The client simulations (in https://github.com/dcooper16/testssl.sh/tree/extended_tls_sockets) show that a strong curve will be used with almost all real clients, but I think the server's configuration should be changed to disable the use of the 163-bit curve.

On a related note, I just noticed that draft-ietf-tls-negotiated-ff-dhe extends NamedCurve in TLSv1.0 - TLSv1.2 to allow finite field Diffie-Hellman groups to be listed (as the draft of TLS v1.3 does for TLSv1.3:

           enum {
           // other already defined elliptic curves (see RFC 4492)
               ffdhe2048(256), ffdhe3072(257), ffdhe4096(258),
               ffdhe6144(259), ffdhe8192(260),
           //
           } NamedCurve;

Should I go ahead and add these to the Supported Groups (formerly Supported Elliptic Curves) extension, in the case that the client is offering any TLS_DHE_... ciphers, or wait until draft-ietf-tls-negotiated-ff-dhe becomes an RFC?

[drwetter]

It's not surprising that real clients are only offering a few curves. That is consistent with the draft > of TLS v1.3 and 4492bis, where most of the curves have been deprecated:

IIRC I saw that referenced in vanilla openssl as curves have been removed.

I can change to order of the curves to match OpenSSL, but I like the idea of ordering them from > weakest to strongest, since I want to know if a server I'm testing is willing to choose a weak
curve, as fpki-graph.fpki-lab.gov does

That host is really interesting. I actually had a script since September last year which tested the curves but never found a good host. So I just published (eb58598) it because it maybe useful.

As far as testssl.sh is concerned. yes, I definitely agree there should be an indicator whether there are weak curves and I see your point. I planned a curve test as an additional feature, see #123.. I am not convinced though that always the weak curve should be displayed.

Actually if you want to implement my script in sockets, pls go ahead. That is anyway the better solution. As you are working faster that I am able to release 2.8 that (and #94) I would gladly include this.

As far as the NamedCurve extension is concerned: I need to do a little homework.

Every new feature which makes sense is welcome, unless it conflicts or breaks things. Off the top of my head: With this one I rather would be careful as I don't know how tolerant ALL servers are if you would include this. IMO: rather keep this for 2.9dev

[drwetter]

I am closing this one as I copied the open issues to #463 and #464