Skip to content
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

TLSv1.2 support is not detected when server uses client certificate authentication #472

Closed
tmalherbe opened this issue Jan 6, 2021 · 1 comment

Comments

@tmalherbe
Copy link

The bug

  • When scanning an Apache server where client certificate is required (SSLVerifyClient verbs shall be set to "require" in /etc/apache2/sites-enabled/default-ssl.conf), SSLyze wrongly claims that this server doesn't support TLSv1.2 (only TLSv1.3).

  • When client certificate auhtentication is deactivated in Apache, SSLyze reports TLSv1.2 as supported by the server.

To Reproduce

  1. Install an Apache server where client certificate authentication is required
  2. Install SSLyze using pip, for instance
  3. Run SSLyze (sslyze 1.2.3.4)
  4. Deactivate client certificate authentication in Apache configuration, then relaunch Apache process
  5. Run sslyze in the same way as in 3

Expected behavior
SSLyze should report TLSv1.2 as supported whether client cert auth is activated or not.

Environment

  • OS: Ubuntu 20.04
  • Python 3.8.5

Additional context

  • sslyze logs when client authentication is activated (sslyze_log_with_cli_auth)
  • sslyze logs when client authentication is deactivated (sslyze_log_no_cli_auth)
  • ssl traffic capture when client authentication is activated (scan_sslyze_with_cli_auth_TLSv12_undetected.pcap).

issue_github_sslyze.zip

In this pcap,

  • frame n°45 (dst port = 56134) is a TLSv1.2 ClientHello;
  • Server response is a ServerHello in frame n°49, and this ServerHello cannot be considered as a TLSv1.3 ServerHello:
    - TLS version is 1.2 (no supported_versions extension can be found)
    - Selected CipherSuite is 0xc030 (possible CipherSuites in TLSv1.3 are 0x1301, 0x1302, 0x1303, 0x1304, 0x1305)
    - Moreover, server certificate is sent in plaintext (afaik server certificate is encrypted in TLSv1.3).
@nabla-c0d3 nabla-c0d3 added the bug label Jan 15, 2021
@nabla-c0d3 nabla-c0d3 added this to To do in 4.0.0 Jan 15, 2021
@nabla-c0d3 nabla-c0d3 removed this from To do in 4.0.0 Jan 19, 2021
@nabla-c0d3 nabla-c0d3 added this to To do in 5.0.0 Jan 19, 2021
@nabla-c0d3 nabla-c0d3 added this to In progress in 4.0.2 Jan 31, 2021
@nabla-c0d3 nabla-c0d3 removed this from To do in 5.0.0 Jan 31, 2021
nabla-c0d3 added a commit that referenced this issue Jan 31, 2021
Update gitignore

Add self-signed key

Tweak

Try without TLS

Do not use pipenv

Re-add TLS

Try

sudo

Debug

Try

Run the actual scan
nabla-c0d3 added a commit that referenced this issue Jan 31, 2021
Update gitignore

Add self-signed key

Tweak

Try without TLS

Do not use pipenv

Re-add TLS

Try

sudo

Debug

Try

Run the actual scan
@nabla-c0d3 nabla-c0d3 moved this from In progress to Done in 4.0.2 Jan 31, 2021
@nabla-c0d3
Copy link
Owner

Thanks for the detailed report. I released a fix as part of v4.0.2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
4.0.2
Done
Development

No branches or pull requests

2 participants