New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFE: Add TLS v1.3 ciphers #1348

Open
landgraf opened this Issue Oct 9, 2018 · 1 comment

Comments

Projects
None yet
2 participants
@landgraf

landgraf commented Oct 9, 2018

Currently ssl-enum-ciphers can detect tls v1.0,1.1 and 1.2 but doesnt' detect v1.3 as well as sslv3 (tested with 7.70 on Linux). It'd be good to add support for missed ciphers.
Probably related to #162

@dmiller-nmap

This comment has been minimized.

Show comment
Hide comment
@dmiller-nmap

dmiller-nmap Oct 9, 2018

I have a private branch where I'm working on TLSv1.3 support for tls.lua and ssl-enum-ciphers. There are enough big changes in the protocol to make it a challenge to implement. Here are some of the sticking points:

  1. Non-AEAD ciphers are not valid in TLSv1.3. Should we test them anyway in case implementations misbehave, or should we go for speed? If we go for speed, should we maintain separate cipher lists for all protocol versions?
  2. Parts of the handshake (most notably for us, Certificate and EncryptedExtensions) are encrypted. Should we extend tls.lua to do actual encryption, or make some features of scripts (e.g. certificate parsing) not able to handle TLSv1.3?
  3. The legacy_version field needs special handling; TLSv1.3 doesn't get its own handshake version, but uses TLSv1.2 with an additional supported_versions extension. A TLSv1.3 ClientHello could get a TLSv1.2 ServerHello in response, so we have to add extra checking for that.

Thanks for creating this issue to track progress.

dmiller-nmap commented Oct 9, 2018

I have a private branch where I'm working on TLSv1.3 support for tls.lua and ssl-enum-ciphers. There are enough big changes in the protocol to make it a challenge to implement. Here are some of the sticking points:

  1. Non-AEAD ciphers are not valid in TLSv1.3. Should we test them anyway in case implementations misbehave, or should we go for speed? If we go for speed, should we maintain separate cipher lists for all protocol versions?
  2. Parts of the handshake (most notably for us, Certificate and EncryptedExtensions) are encrypted. Should we extend tls.lua to do actual encryption, or make some features of scripts (e.g. certificate parsing) not able to handle TLSv1.3?
  3. The legacy_version field needs special handling; TLSv1.3 doesn't get its own handshake version, but uses TLSv1.2 with an additional supported_versions extension. A TLSv1.3 ClientHello could get a TLSv1.2 ServerHello in response, so we have to add extra checking for that.

Thanks for creating this issue to track progress.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment