openssl/openssl

Partial record decryption

Closed

#21,685 opened on Aug 8, 2023

View on GitHubContributor guide
 (3 comments) (0 reactions) (0 assignees)C (11,262 forks)batch import
help wantedtriaged: feature

Repository metrics

Stars
 (30,157 stars)
PR merge metrics
 (No merged PRs in 30d)

Description

Consider the application of a network monitoring system.

The NMS intercepts TLS traffic and it is critical that it reacts immediately to the presence of certain application data on the wire. The NMS does not want to wait for full records to be available as it might be too late, so the problem to solve is decryption of partial records. I cannot rely on RFC6066 max_fragment_length or DTLS to improve granularity of reads because that requires the other peer to collaborate.

I understand that partial record decryption should be possible for all ciphers, as long as I attempt decryption at a multiple of the block size. Integrity is not important for this use case.

My intent is to:

  • Read into the underlying buffer before a full record is available with rl->funcs->read_n , where rl is the OSSL_RECORD_LAYER object, as done by tls_get_more_records via tls_default_read_n.
  • Make a copy of the cipher context with EVP_CIPHER_CTX_copy and decrypt as usual with the EVP apis (although I can see that not every cipher registers dupctx at the moment #20978).
  • If I see anything other than SSL3_RT_APPLICATION_DATA in the header type field, give up the partial read and let it be handled as usual.

Is this reasonable?

Contributor guide

Research direction
The issue proposes partial record decryption for immediate reaction to application data in network monitoring. Investigate the feasibility by examining the record layer code (tls get more records, tls default read n, EVP CIPHER CTX copy) and determine if decryption at block size multiples works for all ciphers. Check if current dupctx registration is a blocker as noted in issue #20978. Consider integration with the existing OSSL RECORD LAYER and whether integrity can be safely ignored.
Tech stack
c
Domain
securitybackend
Issue type
Feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
5
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
Over 1 week
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Fresh
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Needs investigation
Prerequisites
C programmingTLS protocol knowledgeOpenSSL internals
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
5