Closed
Description
Important
@dosu AI robot
similar with #360, for large file fragment transfer scenarios, the output data of ecapture is sometimes incomplete. Since max size is defined as #define MAX_DATA_SIZE_OPENSSL 1024 * 4 , data over 4K will be lost. but based on the rfc5246 and openssl code, is 16kB more accurate here? However, increasing the size of MAX_DATA_SIZE_OPENSSL will inevitably have a negative impact on memory
rfc5246 section-6.2. Record Layer
length
The length (in bytes) of the following TLSPlaintext.fragment. The
length MUST NOT exceed 2^14.
SSL3_RT_MAX_PLAIN_LENGTH (16384)
SSL_CTX_set_max_send_fragment() and SSL_set_max_send_fragment() set the max_send_fragment parameter for SSL_CTX and SSL objects respectively. This value restricts the amount of plaintext bytes that will be sent in any one SSL/TLS record. By default its value is SSL3_RT_MAX_PLAIN_LENGTH (16384). These functions will only accept a value in the range 512 - SSL3_RT_MAX_PLAIN_LENGTH.
Describe the bug
The ssl data output of ecapture is sometimes incomplete when transfer large file fragment transfer
To Reproduce
Steps to reproduce the behavior:
- run ecapture
- trans some bigfiles with https which size over 4kB
- ecapture output is incomplete
Screenshots
here is some debug log
[root@xx ~]# cat /sys/kernel/debug/tracing/trace_pipe | grep "xxx: process_SSL_data"
nginx-680600[017]d... 612945.433807: bpf_trace_printk: xxx: process_SSL_data len 47.
nginx-680600[017]d... 612945.434001: bpf_trace_printk: xxx: process_SSL_data len 17.
nginx-680600[017]d... 612945.434089: bpf_trace_printk: xxx: process_SSL_data len 8319.
nginx-680600[017]d... 612945.435206: bpf_trace_printk: xxx: process_SSL_data len 17.