zgrab2 with tls1.3

[Damian96gz]

Hello, my project need some scans for tls1.3 connections, are there any field I can set while using the tls scanner to use tls 1.3?

The command I used is :
./zgrab2 tls -f input2.csv --connections-per-host=2

[mzpqnxow]

Hi @Damian96gz unfortunately there is no TLSv1.3 support. You can see zmap/zcrypto#206 for more on this, but the summary is it requires a lot of work. zgrab2 uses zcrypto for encryption. zcrypto is a frozen golang stdlib with some compatibility hacks. To add support for TLSv1.3 will require a good amount of effort

Nobody seems to have had enough time to do this but it looks like @dissoupo is working on it according to recent notes on that PR - he has a fork here but I'm not sure how far along it is - https://github.com/dissoupov/zcrypto

[mzpqnxow]

Hi @Damian96gz unfortunately there is no TLSv1.3 support. You can see zmap/zcrypto#206 for more on this, but the summary is it requires a lot of work. zgrab2 uses zcrypto for encryption. zcrypto is a frozen golang stdlib with some compatibility hacks. To add support for TLSv1.3 will require a good amount of effort

Nobody seems to have had enough time to do this but it looks like @dissoupo is working on it according to recent notes on that PR - he has a fork here but I'm not sure how far along it is - https://github.com/dissoupov/zcrypto

Note, since this post, there is now a TLS1.3 branch available and it works very well

[mzpqnxow]

I think this can be closed

[mzpqnxow]

@Damian96gz have you tried to use a recent build from master? You should see TLS1.3 support there now

[funkshun]

What are the steps for specifying TLS1.3 grabs on the master branch? Setting the --max-version flag to 0 still results in TLS1.2 usage for IPs that support TLS1.3.

[mzpqnxow]

What are the steps for specifying TLS1.3 grabs on the master branch? Setting the --max-version flag to 0 still results in TLS1.2 usage for IPs that support TLS1.3.

I've not done this before using --min-version / --max-version, so I can't comment on whether that should work or not. However, I can suggest alternatives

Before the alternatives that I suggest below, though, you may try adding --min-version 0

Again, I'm not too familiar with how --min-version and --max-version are supposed to work for TLS1.3 in theory or in practice, so that's just a preliminary suggestion. I do know that TLS1.3 uses the same 16bit value for TLS1.3 as it does for TLS1.2 (0x0303 iirc) which is probably why those flags didn't translate well with the addition of TLS1.3

In my experience, failure to negotiate TLS1.3 when TLS1.2 is also present is often caused by the choices made on the client or server with regard to the supported cipher list (including the order)

Reference: zcrypto is the package that provides zgrab2 with TLS functionality. You can see more about the current set of ciphers here

There are two ways to approach this, both use the --cipher-suite flag

1. Specify cipher(s)** only supported by TLS1.3. Basically, this means "do TLS1.3 or fail"
2. Specify ciphers only supported by TLS1.3, followed by those supported by TLS1.3 and TLS1.2

For the second approach, the logic in zcrypto should pick the first one common to client and server and the highest protocol version both sides are configured for, unless there are quirks in zcrypto that I'm not aware of (quite possible)

The --cipher-suite flag supports either a string representing a canned collection of ciphers (e.g. "portable", "chrome-only", "firefox-only") or a list of 8bit or 16bit integers, I believe separated by commas

The list of canned ones (including the string value used to reference them via --cipher-suites in zgrab2) is as follows, from here:

cipherMap := map[string][]uint16{
	"portable":        tls.PortableCiphers,
	"dhe-only":        tls.DHECiphers,
	"ecdhe-only":      tls.ECDHECiphers,
	"exports-dh-only": tls.DHEExportCiphers,
	"chrome-only":     tls.ChromeCiphers,
	"chrome-no-dhe":   tls.ChromeNoDHECiphers,
	"firefox-only":    tls.FirefoxCiphers,
	"firefox-no-dhe":  tls.FirefoxNoDHECiphers,
	"safari-only":     tls.SafariCiphers,
	"safari-no-dhe":   tls.SafariNoDHECiphers,
}

Though it's known that these canned lists aren't actively maintained, you may want to first try a few of them to see if they aid in negotiating TLS1.3 over TLS1.2, because it's quick to test:

zgrab2 ... --cipher-suite chrome-only
zgrab2 ... --cipher-suite firefox-only
zgrab2 ... --cipher-suite portable

If no luck there, you'll have to get your hands a little dirty and provide your own list

To specify TLS_CHACHA20_POLY1305_SHA256, which is only supported in TLS1.3, you can reference ciphersuite.info to get its 16bit value, which is:

0x13, 0x3

Because I'm not certain of the endianness there off the top of my head, try either of these to see if TLS1.3 is negotiated:

zgrab2 ... --cipher-suite 0x0313
zgrab2 ... --cipher-suite 0x1303

That will of course only work if that cipher is supported on the server. Otherwise you'll get a handshake failure

You can also try adding ciphers supported by both TLS1.2 and TLS1.3, with the TLS1.3 cipher(s)** first for good measure. This should cause TLS1.3 to be negotiated unless there's an issue with zcrypto or the server is not configured appropriately

For example, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 is a TLS1.2 and TLS1.3 cipher. It is represented by either 0xc030 or 0x30c0 (sorry, once again, not certain of endianness here)

zgrab2 ... --cipher-suite 0x0313
zgrab2 ... --cipher-suite 0x1303

You may say "well that's stupid, now servers without that cipher will fail" - true. But once you confirm something that works for the TLS1.3 case, you can add a longer set of ciphers based on the canned ones, or whatever you choose. Just be aware of the significance of the ordering

Hope this is helpful, I'm not in a position to test this right now, which is why a few of the above are estimates. I think it gives you enough to work it out

Finally- is what you're seeing a bug? Maybe. It depends very much on the details of the server configuration- which ciphers it offers, and in what order. If you would like to investigate that further, I recommend testssl.sh to get a detailed list of the ciphers. Or better yet, set up your own local TLS listener, where you control the protocol parameters, something like this:

openssl s_server -accept 12345 -tls1_3 -ciphersuites TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256 -cert server.crt -key server.key -debug -msg

Sorry for typos and other problems, this is a post from a telephone

**I'm not certain, but I think the only cipher-suite that is exclusively supported by TLS1.3 and suitable for use with HTTPS is the poly1305 chacha20 one