Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
  • Sign in / Register
  • GnuTLS GnuTLS
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 17
    • Merge requests 17
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • gnutls
  • GnuTLSGnuTLS
  • Issues
  • #1011
Closed
Open
Created Jun 01, 2020 by Airtower@airtower-lunaDeveloper

CVE-2020-13777: TLS 1.3 session resumption works without master key, allowing MITM

GnuTLS servers are able to use tickets issued by each other without access to the secret key as generated by gnutls_session_ticket_key_generate(). This allows a MITM server without valid credentials to resume sessions with a client that first established an initial connection with a server with valid credentials. The issue applies to TLS 1.3, when using TLS 1.2 resumption fails as expected.

Because the ticket can be used for resumption without knowledge of the master key I assume (but haven't tested yet) that it can also be used for passive decryption of early data.

I first noticed the issue with Ubuntu version 3.6.13-2ubuntu1, and reproduced it with a build from master as of 52e78f1e.

Steps to Reproduce

  1. Start a server with valid credentials: gnutls-serv --x509keyfile=authority/server/secret.key --x509certfile=authority/server/x509.pem
  2. Connect to the server and store resumption data: openssl s_client -connect localhost:5556 -CAfile authority/x509.pem -verify_return_error -sess_out session.cache
  3. Stop the server started in step 1.
  4. Start a server with bogus credentials at the same address port (imagine a real attacker redirecting connections only if the client is attepting resumption): gnutls-serv --x509keyfile=rogueca/mitm/secret.key --x509certfile=rogueca/mitm/x509.pem
  5. Connect again, using the stored resumption data: openssl s_client -connect localhost:5556 -CAfile authority/x509.pem -verify_return_error -sess_in session.cache

I've used openssl s_client to reproduce the problem because gnutls-cli lacks a way to store resumption data across invocations, but the effect is also reproducible with applications using GnuTLS that cache session data long enough to change the server. I noticed the issue while implementing session resumption for proxy connections in mod_gnutls.

The certificates are just ones out of my test PKI, I can post them if it helps. What matters is that the server from step 1 has a certificate issued by a CA the client trusts, while the server from step 4 has one issued by a CA unknown to the client.

Actual results

The bogus server is able to resume the session, the client does not detect the attack.

Expected results

Session resumption should fail, leading to a full handshake, which must fail unless the second server has valid credentials. A successful full handshake would be the expected result if the server would be restarted with the same certificate instead of a bogus one.

Edited Jun 03, 2020 by Daiki Ueno
Assignee
Assign to
Time tracking