Add support for testing TLS 1.3

[tomato42]

New version of protocol, new ciphers.

They are not controlled with the -cipher option but rather the -ciphersuites option in OpenSSL, so using OpenSSL 1.1.1 will likely give us wrong results.

[jvehent]

I've been thinking about this quite a bit, and I'm not sure we can get an openssl binary that supports both tls1.3 and sslv2 with all the intermediate patches @PeterMosmans used to maintain.

Is it time to replace openssl and rewrite cipherscan to use tlslite-ng?

[tomato42]

feels like it... I see two possible obstacles for that - lack of support for ECDSA (https://github.com/tomato42/tlslite-ng/issues/52) and lack of support for session tickets (https://github.com/tomato42/tlslite-ng/issues/60) in tlslite-ng

that's assuming that we want to duplicate as much functionality from current script as possible... if we're ok with not providing the ticket lifetimes and not performing full handshakes, then the situation is much simpler

I think we will have to settle for not being able to gather session ticket lifetimes for more obscure ciphers like SEED or ARIA for some time, but not being able to do it for servers that have just ECDSA certificates is more painful

[drwetter]

how about using 1.0.2 from Peter and 1.1.1?

[tomato42]

because TLS 1.3 ciphers are not the only problem, there are also additions like ARIA that are compatible with TLS 1.2 and there are ciphers that were removed in OpenSSL 1.1.1, so by running the test twice with TLS 1.2, we may end up with two disjoint lists that you can't provide ordering for

also, 1.0.2 will only get harder and harder to compile and run, so migrating from it is more future proof

[drwetter]

wrt to 1.0.2.: I agree moving away from seems future proof. But why should it get harder and harder to compile and run? Did you mean patch ?

[tomato42]

code bit rots

compilers become more and more picky about code they will compile, new architectures are born that will not be supported by the openssl 1.0.2 build system making it impossible to compile on them

[drwetter]

The official end of LTS support is still ahead (12/2019). Will any compiler until then really dare to hiccup?

[tomato42]

I'm not saying that it's something that we have to worry happening "tomorrow", but if we manage to fully convert cipherscan to python in just one year, I'll be surprised

[PeterMosmans]

Great discussion... and not one that's easy to solve. Granted, I haven't put much time so far in updating the 1.0.2 fork, but, looking at this discussion... What theoretically would make more sense for the OpenSSL fork: "Maintaining" 1.0.2, or backporting/patching a new 1.1.1-insecure fork? It would be so efficient to leverage the OpenSSL codebase for the heavy crypto-lifting, as opposed to implementing the missing parts (see @tomato42 's remarks) in Python

[tomato42]

the only way to show that a server does not support given protocol or cipher is to actually try making a connection with it, so we need something that can do SSLv2 protocol, TLS_RSAEXP1024* ciphers, etc.

while it is efficient to reuse OpenSSL's code, their goals are different than ours (and for a good reason), so we will just continue to diverge

oh, and actually, OpenSSL 1.1.1 will not be feature complete enough to scan TLS 1.3 servers running NSS or GnuTLS: https://github.com/openssl/openssl/issues/6519 . Then there is the problem of detecting if the server is not running one of the draft versions of TLS 1.3...

the tlslite-ng primary goal is to power tlsfuzzer, and it in turn has very similar goals to cipherscan – i.e. cipher or protocol termed "insecure" definitely will not be removed, exactly so that it can be used to verify that it doesn't work

also, while it does look like duplication of effort, the effort itself is not large – adding session ticket support is about a day's work, ECDSA support is something like 2 days, fully supporting new cipher is usually like a day or two (not having to worry about performance or side-channels makes the implementation much easier) – problem is that while cipherscan is a hobby project for me, tlslite-ng is a work project, and I want to keep them separate... (workaholism and all that :smile: ) In work, my priority now is TLS 1.3 and maintenance, not plugging holes in TLS 1.2 support :frowning_face:

[tomato42]

Small update: ECDSA is technically[1] supported in tlsllite-ng now: https://github.com/tomato42/tlslite-ng/pull/359, https://github.com/tomato42/tlslite-ng/pull/360

OpenSSL master also supports FFDHE now openssl/openssl#6519

1 - I'm saying "technically" as not the full checklist of features is addressed: https://github.com/tomato42/tlslite-ng/pull/196