Consider using zcrypto/ztls tls.PortableCiphers by default or as a flag to enhance success rates on SSL/TLS handshakes

[mzpqnxow]

Please describe your feature request:

Hello there, I'm reasonably new to nuclei but am very impressed with the tool. One small detail about it that I appreciated (separately from the very impressive core features) is the fact that it provides an option to use ztls, from the zmap zcrypto package. It's very useful when dealing with endpoints that have SSLv2/SSLv3 and/or obscure cipher-suites- which are obviously rare, but not non-existent, especially when working at scale. Attention to detail like this is really important for some users, especially those who may not know enough to worry about such a fine detail

The purpose of this issue- I have some experience working with zcrypto/ztls and previously submitted a small patch to the package. It little bit of reworking of the ciphers it supported and/or used by default. That PR can be found here and was merged some time ago to the master zcrypto package

Among a few other basic things (like adding ciphers to the list that were left off for one reason or another) that patch also adds an pre-built ordered list of cipher-suites intended to be as portable as possible, for both older and newer SSL/TLS implementations. It was added (selfishly) to support my own use of zgrab2 (see the accompanying PR for zgrab2 here via a command-line flag --cipher-suite=portable and resulted in non-negligible collection improvement (~.5% more successful negotiations, a big deal at scale)

Might it make sense for nuclei to make use of this cipher-list either by default or as a flag/configuration option in the same way that zgrab2 does? The way that I look at it, nuclei has the same community of users and a similar objective as zgrab2 - penetration testers and security researchers, gathering data from a wide range of hosts, including many with rare or out-of-date configurations

I don't currently have any measurements that show any deficiencies when using nuclei -ztls (and I haven't closely inspected which cipher-suites are used by default, I just confirmed it was not the pre-bundled PortableCiphers

I think both zcrypto, zgrab2 and nuclei might benefit from aligning their cipher-suite choices/list. If that's not intuitive then maybe it's just my opinion :>

Proposed Action(s)

• I'm proposing that by default tls.PortableCiphers be used for the cipher-suites list when -ztls is enabled
• Optionally, If there's hesitation about changing a default behavior (even though -ztls is a non-default option itself) an option like --cipher-suite=portable, as is done in zgrab2, would be very convenient for some users who do want to opt-in to this

I'm sure developers here are as busy if not busier than I am, but I would also propose that someone (other than me, to catch any mistakes or misjudgements I might have made) takes a look at the current nuclei cipher-suite list when -ztls is used in comparison to the ztls tls.PortableCiphers list, to identify potential deficiencies in either, regardless of whether there is any interest in making a chance to the nuclei code. This could be helpful to both the zmap (zcrypto, zgrab2) projects and nuclei

Risks / Drawbacks / Benefits

• RISK: Theoretically, this could actually be detrimental to nuclei if there mistakes in the PortableCiphers list that have not yet been caught. I say theoretically because as I understand it, nuclei will fall back to the standard golang tls package upon negotiation failure, and also because that cipher-suite list has been tested and reviewed by several parties by now, in the context of both zcrypto and zgrab2
• BENEFITS: Potential improvement in total endpoint compatibility- more templates will run across users' inputs, in cases where handshakes otherwise might have failed

Describe the use case of this feature:

• Potentially more comprehensive compatibility with unusual SSL/TLS configurations

Data

I will do my best to collect some data, but if this is a non-controversial idea, it would be great if I could avoid putting the time into that. Otherwise I'll get back as I get the chance

Thanks for all the great work on this project. I'll do my best to get back with some data but I don't expect to have much time for it in the next couple of months

[ehsandeep]

Hey @mzpqnxow, thank you for the detailed issue and information you included here, I need to see dig into what PortableCiphers data, but there could be a chance it might be already supported as part of tlsx integration (currently in the dev branch) which imports our dedicated project for the TLS connection and offers multiple modes for TLS scanning including tls/crypto, zcrypto and OpenSSL (conditional), (default to auto) and use them with auto fall back manner, this integration also means, you don't have to use -ztls anymore as it will be covered with auto fallback behavior if standard library fails to make the connection.

tlsx uses all the ciphers from the standard lib + ztls as default and is listed here, and from what I can see, most of the ciphers (from PortableCiphers) are already part of it, if anything is missing that you can point out, we can directly work on tlsx and will be used indirectly in nuclei.

Thanks again for sharing detailed information and observation, which helps to improve the project.

[mzpqnxow]

Hey @mzpqnxow, thank you for the detailed issue and information you included here, I need to see dig into what PortableCiphers data, but there could be a chance it might be already supported as part of tlsx integration (currently in the dev branch) which imports our dedicated project for the TLS connection and offers multiple modes for TLS scanning including tls/crypto, zcrypto and OpenSSL (conditional), (default to auto) and use them with auto fall back manner, this integration also means, you don't have to use -ztls anymore as it will be covered with auto fallback behavior if standard library fails to make the connection.

Thank you for taking the time to offer this info- I was unaware of the extensive work that has gone into this specific area. I'm going to close this issue for now and see if I can dig up the (very small) set of endpoints that caused me issues with the zcrypto ztls implementation with other tools (err, tool- zgrab2) and ensure they're handled as expected by nuclei

Of course I'll report back if there are any handshake failures

Thanks again, I realize that unwinding what I posted here took quite a bit of time and effort not to mention the detailed response

[ehsandeep]

@mzpqnxow This is now supported in default mode to use ciphers from ztls as auto fallback with https://github.com/projectdiscovery/nuclei/pull/3909