adulau/ssldump

ssldump - (de-facto repository gathering patches around the cyberspace)

ssldump - (de-facto repository gathering patches around the cyberspace)

Release and tagging

• Current version of ssldump is v1.8 (released: 2023-08-14) - ChangeLog

What about the original ssldump?

This repository is composed of the original SSLDUMP 0.9b3 + a myriad of patches (from Debian and other distributions) + contributions via PR

ssldump is an SSLv3/TLS network protocol analyzer. It identifies TCP connections on the chosen network interface and attempts to interpret them as SSLv3/TLS traffic. When it identifies SSLv3/TLS traffic, it decodes the records and displays them in a textual form to stdout. If provided with the appropriate keying material, it will also decrypt the connections and display the application data traffic. It also includes a JSON output option, supports JA3 and IPv6.

How to do I run ssldump?

./ssldump -j -ANH -n -i any | jq will run ssldump on all interfaces and output the result in JSON format including ja3 hashes.

For more details, check the man page.

How can I lookup ja3 hashes?

This example will query ja3er.com service to display the known ja3 hashes from the TLS handshaked in the pcap.

./ssldump -r yourcapture.pcap -j | jq -r 'select(.ja3_fp != null) | .ja3_fp' | parallel 'curl -s -X GET 'https://ja3er.com/search/{}' | jq .'

Why do you maintain this repository?

Because it's a mess. The software maintenance process for old free (unmaintained) software like ssldump is a complete chaotic process. I do this to ease my pain and this could help other too (but this is just a collateral damage).

Where ssldump is used?

• I used it for a relatively small project called Passive SSL. For more information, Passive SSL Passive Detection and Reconnaissance Techniques, to Find, Track, and Attribute Vulnerable ”Devices”. Additional back-end code available is in the crl-monitor repository.
• ssldump is used in the D4-Project.

Where ssldump is available?

• Alpine Linux ssldump
• Arch Linux ssldump
• CentOS, RHEL, Rocky (via EPEL) ssldump
• Fedora ssldump
• Kali Linux ssldump
• Ubuntu Linux ssldump

Build instructions

Install dependencies on Debian & Ubuntu (as root):

apt install build-essential git cmake ninja-build libssl-dev libpcap-dev libnet1-dev libjson-c-dev

On Fedora, CentOS, RHEL & Rocky (as root):

dnf install git cmake ninja-build gcc openssl-devel libpcap-devel libnet-devel json-c-devel

On OpenBSD (as root):

pkg_add git cmake ninja json-c libnet

On FreeBSD (as root):

pkg install git cmake ninja json-c libnet

On MacOS (as root):

brew install cmake ninja openssl@3 libpcap libnet json-c

Compile & install:

git clone https://github.com/adulau/ssldump.git
cd ssldump
cmake -G Ninja -B build
ninja -C build
./build/ssldump -v
(optional, as root) ninja -C build install

Notes

The "save to pcap" (-w) option by @ryabkov, is heavily based on the work of @droe on https://github.com/droe/sslsplit .

Contributing

The contributing policy is simple. If you have a patch to propose, make a pull-request via the interface. If the patch works for me, it's merged.

ssldump's Issues

Capture NIC in real time memory leak

I have found this https://sourceforge.net/p/ssldump/bugs/39/, it say read 2,8GB pcap file, SSLDump grows up to 720MB memory.

this issue is seem to me, in my case it decrypt 100 sessions(HTTP short link) per second and run 3 hours, memory usage 983MB, then CPU usage is always %99....

make And exec error

Parrot 2020.2
First the command make say make: Nothing to be done for 'all'. but sudo make install work.

When launching :

sudo ssldump
ssldump: error while loading shared libraries: libpcap.so.1: cannot open shared object file: No such file or directory

But ./configure was fine

The -d decrypting option not work

Hello

I have read soure code, the -d option not process in main function
see pcap-snoop.c 299 line
BTW, hope add a decrypting example, I can provide the private key and traffic

Missing extension type

New TCP connection #9: dobbertin(60424) <-> 108.177.126.189(443)
9 1  0.0203 (0.0203)  C>S V3.1(646)  Handshake
      ClientHello
        Version 3.3 
        random[32]=
          10 2a f7 64 92 ae b9 ed 92 fb 1d 8e f3 aa 25 ff 
          30 58 46 9b 46 ed e1 7f 58 af 17 fb 7c 0c a3 39 
        resume [32]=
          6a 94 8b ef 81 2f e8 d5 67 62 7f 0d 00 aa cf ce 
          fe 56 9c 37 7d 6a 4b ca 22 d1 e8 e3 5f 6b 0e 47 
        cipher suites
        TLS_AES_128_GCM_SHA256
        TLS_CHACHA20_POLY1305_SHA256
        TLS_AES_256_GCM_SHA384
        TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
        TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
        TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
        TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
        TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
        TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
        TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
        TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
        TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
        TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
        TLS_RSA_WITH_AES_128_GCM_SHA256
        TLS_RSA_WITH_AES_256_GCM_SHA384
        TLS_RSA_WITH_AES_128_CBC_SHA
        TLS_RSA_WITH_AES_256_CBC_SHA
        TLS_RSA_WITH_3DES_EDE_CBC_SHA
        compression methods
                  NULL
        extensions
          server_name
              host_name: cello.client-channel.google.com
          extended_master_secret
          renegotiation_info
        Extension type: 10 not yet implemented in ssldump
        Extension type: 11 not yet implemented in ssldump
          application_layer_protocol_negotiation
          status_request
        Extension type: 51 not yet implemented in ssldump
        Extension type: 43 not yet implemented in ssldump
          signature_algorithms
        Extension type: 45 not yet implemented in ssldump
        Extension type: 28 not yet implemented in ssldump
        Extension type: 41 not yet implemented in ssldump
9 2  0.0375 (0.0172)  S>C V3.3(128)  Handshake
      ServerHello
        Version 3.3 
        random[32]=
          27 f0 16 e4 40 b6 24 c2 1d 64 0a e0 71 98 c1 70 
          39 e8 35 ed de f2 72 d2 a9 9f 2c 0a 37 7e 6b eb 
        session_id[32]=
          6a 94 8b ef 81 2f e8 d5 67 62 7f 0d 00 aa cf ce 
          fe 56 9c 37 7d 6a 4b ca 22 d1 e8 e3 5f 6b 0e 47 
        cipherSuite         TLS_AES_128_GCM_SHA256
        compressionMethod                   NULL
        extensions
        Extension type: 41 not yet implemented in ssldump,
        Extension type: 51 not yet implemented in ssldump,
        Extension type: 43 not yet implemented in ssldump,

release v1.2 could not link openssl 1.1.0

hello, I find that release v1.2 could not link openssl 1.1.0, could you tell me what version is recommend.

yes

like all

When write pcap file the source port and destination port was 0

Hi,
when I write the pcap with version ssldump-1.5-1.el7.x86_64 the pcap file was write with source port and destination port 0.

can you correct this issue?

Write to pcap don't rotate and it was impossible to write into a pipe

Hi,
I am trying to write the outout pcap into a named pipe:

$ ssldump -v
ssldump 1.4b
Maintained by a bunch of volunteers, see https://github.com/adulau/ssldump/blob/master/CREDITS
Copyright (C) 2015-2021 the aforementioned volunteers
Copyright (C) 1998-2001 RTFM, Inc.
All rights reserved.
Compiled with OpenSSL: decryption enabled
$ mkfifo pcap_test.pcap
$ ls -ltr pcap_test.pcap
prw-r--r-- 1 root root 0 Jun 17 14:13 pcap_test.pcap
$ ssldump -w pcap_test.pcap
Can not open/create out pcap pcap_test.pcap

it possible to write the output packet into a pipe?

In alternative it was possible to rolling the pcap output file on size/time?

We would like to run a "continuos" packet capture/decode and read it only when we have some trouble.

thanks.

pcap-snoop.c:98: error: initializer element is not constant

I am trying to run make, some error occured:

make all-am
make[1]: Entering directory /root/ssldump-1.5' gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I. -I./common/include -I./common/lib -I./null -I./ssl -I./base -I./pcap -D_DEFAULT_SOURCE=1 -DLINUX -DOPENSSL -D_BSD_SOURCE=1 -O2 -MT base/ssldump-pcap-snoop.o -MD -MP -MF base/.deps/ssldump-pcap-snoop.Tpo -c -o base/ssldump-pcap-snoop.o test -f 'base/pcap-snoop.c' || echo './'base/pcap-snoop.c base/pcap-snoop.c:98: error: initializer element is not constant make[1]: *** [base/ssldump-pcap-snoop.o] Error 1 make[1]: Leaving directory /root/ssldump-1.5'
make: *** [all] Error 2

here are configure info

################################################
SSLDump build setup
Host system: linux-gnu
Host architecture: x86_64
Compiler: gcc -std=gnu99
Installation prefix: /usr/local
CFLAGS: -O2
LDFLAGS:
LIBS: -ljson-c -lnet -lssl -lpcap
Optimizations enabled: yes
Debug info enabled: no
ASAN enabled: no
################################################

stdout syn packet information missing timestamp

When print to stdout the packet information is missing the timestamp of the syn packets:

TCP: 10.139.67.98(57151) -> 10.180.65.22(636) Seq 1197153098.(0) SYN
TCP: 10.180.65.22(636) -> 10.139.67.98(57151) Seq 4242385654.(0) ACK 1197153099 SYN
TCP: 10.139.67.98(57151) -> 10.180.65.22(636) Seq 1197153099.(0) ACK 4242385655
New TCP connection #1: 10.139.67.98(57151) <-> 10.180.65.22(636)
TCP: 10.139.67.98(57151) -> 10.180.65.22(636) Seq 1197153099.(383) ACK 4242385655 PUSH
1 1 1675954215.6833 (0.0343) C>S V3.3(378) Handshake
ClientHello

With this configuration we don't know when the connection was opened.

here the command line used:

ssldump -d -i eth0 -k -n -P -a -A -e -T -x -X -w dump.pcap port

New feature - Export JSON (certificate/hello)

A new option --output json in ssldump to replace the current text output into a JSON like output. The JSON is a single object output per packet decoded.

The required output to have is the following:

• cert_base64 a Base64 version of the certificate (DER)
• source_ip
• source_port
• destination_ip
• destination_port
• a specific array of the decoded certificate to include the existing fields such as Subject, Issuer, Serial, Extension

Maybe some additional fields for the SSL/TLS handshake itself (like we have currently in the ssldump output).

Did ssldump support tls 1.3 decrypt?

configure & make on debian jessie

Hello

Running ./configure yields config.status: WARNING: 'Makefile.in' seems to ignore the --datarootdir setting

There are other errors as well; please see the below URL.
Here is the output from make on pastebin

ii openssl 1.0.1t-1+deb8u5 amd64 Secure Sockets Layer toolkit - cryptographic utility
ii libpcap-dev 1.6.2-2 all development library for libpcap (transitional package)
ii libpcap0.8:amd64 1.6.2-2 amd64 system interface for user-level packet capture
ii libpcap0.8-dev 1.6.2-2 amd64 development library and header files for libpcap0.8

Thanks!

Did ssldump support SM2/SM3/SM4 decrypt?

Did ssldump support SM2/SM3/SM4 decrypt?

Switching to cmake

Hi,

I just pushed my initial setup for using cmake instead of autotools at https://github.com/wllm-rbnt/ssldump/tree/cmake

You can test it with the following commands:

using make:

$ sudo apt install cmake
$ git clone -b cmake https://github.com/wllm-rbnt/ssldump/ ssldump-cmake
$ cd ssldump-cmake
$ mkdir build
$ cd build
$ cmake ../
$ make
$ ./ssldump -v

or with ninja instead of make

$ sudo apt install cmake ninja-build
$ git clone -b cmake https://github.com/wllm-rbnt/ssldump/ ssldump-cmake
$ cd ssldump-cmake
$ mkdir build
$ cd build
$ cmake -G Ninja ../
$ ninja
$ ./ssldump -v

Here are some stats:

Autotools:
   ( ./autogen.sh && ./configure && make -j6; )  7.93s user 3.37s system 122% cpu 9.255 total

cmake + make:
  ( cmake ../ && make -j6; )  2.71s user 1.03s system 169% cpu 2.210 total

cmake + ninja:
  ( cmake -G Ninja ../ && ninja -j6; )  2.28s user 0.71s system 222% cpu 1.341 total

Feedback is welcome !

William

IPv6 support review

IPv6 support review

provide Dockerfile/docker image

Faced openssl library issues on a Ubuntu 16 box while compiling. I was thinking should a Dockerfile be provided in this repo so people could simply build & use ssldump inside a container, any thoughts?

Version 1.6 not write decoded packet into pcap

I try the last version 1.6 but the pcap written not contains the decrypted packet but contains the tls packet.

can you verify?

Cannot find libssl in ubuntu 16.04

error:

`Unable to find libssl on this system
Check 'config.log' for more information

On Debian and Ubuntu systems you can
install the required library and header
files with
apt install libssl-dev`

dpkg -l | grep libssl shows:
ii libssl-dev:amd64 1.0.2g-1ubuntu4.20 amd64 Secure Sockets Layer toolkit - development files ii libssl-doc 1.0.2g-1ubuntu4.20 all Secure Sockets Layer toolkit - development documentation ii libssl1.0.0:amd64 1.0.2g-1ubuntu4.20 amd64 Secure Sockets Layer toolkit - shared libraries

Not sure how to proceed. The default ssldump in the repos just coredumps almost as soon as I invoke it.

Add ja3 and ja3s output in ssldump

Add ja3 and ja3s output in ssldump

Could you provide a static link library and decryption interface？

Thanks for the ongoing maintenance of the project, this is a very valuable project, could you provide a static link library and decryption interface to link to the bypass packet capture program?Thank you.

Write to pcap write the packet without port information

Hi, during the write to pcap (-w options) the packet was printed without the source port and the destination port; either was set to zero:

ssldump -w test.pcap
::::::::::::::::::::::::::::::
tcpdump -r prova.pcap

you can see that the port was setted to zero.

Add OpenSSL 3.0 support

Building ssldump version 1.8 using OpenSSL 3.0 results in a number of deprecation warnings of the following kind:

/<<PKGBUILDDIR>>/ssl/ssldecode.c: In function ‘ssl_process_client_key_exchange’:
/<<PKGBUILDDIR>>/ssl/ssldecode.c:670:7: warning: ‘RSA_get0_key’ is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations]
  670 |       RSA_get0_key(EVP_PKEY_get0_RSA(pk), &n, NULL, NULL);
      |       ^~~~~~~~~~~~
In file included from /usr/include/openssl/x509.h:36,
                 from /usr/include/openssl/ssl.h:31,
                 from /<<PKGBUILDDIR>>/ssl/ssldecode.c:53:
/usr/include/openssl/rsa.h:217:28: note: declared here

Website down

The website referenced in the README is 404ing.

Thanks for your time,
Michael

circl.lu ssl error

hi,
unsure where else to report this. going to https://circl.lu/services/passive-ssl/ I get a privacy error in chrome because the certificate is for *.circl.lu

Compilation warning in pcap/logpkt.c CHKSUM_ADD_RANGE [-Waddress-of-packed-member]

There is a compilation warning about pointer alignment in pcap/logpkt.c

[...]
gcc -DHAVE_CONFIG_H -I.  -I. -I./common/include -I./common/lib -I./null -I./ssl -I./base -I./pcap -D_DEFAULT_SOURCE=1 -DLINUX -DOPENSSL -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -O2 -c -o pcap/ssldump-pcap_logger.o `test -f 'pcap/pcap_logger.c' || echo './'`pcap/pcap_logger.c
pcap/logpkt.c: In function ‘logpkt_pcap_build’:
pcap/logpkt.c:351:3: warning: converting a packed ‘ip4_hdr_t’ pointer (alignment 1) to a ‘uint16_t’ {aka ‘short unsigned int’} pointer (alignment 2) may result in an unaligned pointer value [-Waddress-of-packed-member]
  351 |   CHKSUM_ADD_RANGE(sum, ip4_hdr, sizeof(ip4_hdr_t));
      |   ^~~~~~~~~~~~~~~~
pcap/logpkt.c:80:9: note: defined here
   80 | typedef struct __attribute__((packed)) {
      |         ^~~~~~
pcap/logpkt.c:399:2: warning: converting a packed ‘tcp_hdr_t’ pointer (alignment 1) to a ‘uint16_t’ {aka ‘short unsigned int’} pointer (alignment 2) may result in an unaligned pointer value [-Waddress-of-packed-member]
  399 |  CHKSUM_ADD_RANGE(sum, tcp_hdr, sizeof(tcp_hdr_t) + payloadlen);
      |  ^~~~~~~~~~~~~~~~
pcap/logpkt.c:102:9: note: defined here
  102 | typedef struct __attribute__((packed)) {
      |         ^~~~~~
[...]

This issue is related to the code imported from https://github.com/droe/sslsplit
It is tracked at droe/sslsplit#256

Add decryption test in ssldump

Add decryption test in ssldump like the ones in wireshark:

https://git.bocc.de/jochen/wireshark/commit/57b0527821b69dc8aa0786a3b5a425192795aff2

Crash with buffer overflow detected

I have repeatedly observed the crash with suspicious console output:

Short read: -48141 bytes available (expecting 2)

F39 1.8-1

Log and relevant packet capture attached.
SSLdump.log
Cloudflare.pcapng.gz

Long run capture memory leak

I am trying to make a long run capture with ssldump latest version:

ssldump -T -z -P -n -H -e -A -d port

but I see that the memory in use of the ssldump process grows indefinitely.

It is possible to run ssldump for long time without having memory issues?

Can you check if all memory was released when a connection was closed?

On linux/unix the key file and password was visible by ps

Hi,
if I launch the ssldump with a key file and the password this was visible launching a "ps" on the VM, this is a security bug because all the users can see the key file location and it's decrypt password.

Not enough data. Found 45 bytes

Getting that error. And I also don't get how this app was supposed to work. Shall it print certificate summary, exchanges, etc like Wireshark does? Because right now I'm only getting terse messages about flow directions and that's it.

# ssldump -d  -r   /tmp/del.bin      
New TCP connection #1: localhost(40422) <-> localhost(9339)
1 1  0.0001 (0.0001)  C>S  Handshake
      ClientHello
        Version 3.3 
        cipher suites
        Unknown value 0xc02b
        Unknown value 0xc02c
        Unknown value 0xc02f
        Unknown value 0xc030
        Unknown value 0xff
        compression methods
                  NULL
1 2  0.0020 (0.0018)  S>C  Handshake
      ServerHello
        Version 3.3 
        session_id[0]=

        cipherSuite         Unknown value 0xc02f
        compressionMethod                   NULL
1 3  0.0020 (0.0000)  S>C  Handshake
      Certificate
1 4  0.0020 (0.0000)  S>C  Handshake
      ServerKeyExchange
1 5  0.0020 (0.0000)  S>C  Handshake
      CertificateRequest
        certificate_types                   rsa_sign
        certificate_types                 unknown value
Not enough data. Found 45 bytes (expecting 32767)
1 6  0.0020 (0.0000)  S>C  Handshake
      ServerHelloDone
1    0.0022 (0.0002)  C>S  TCP FIN
1    0.0023 (0.0000)  S>C  TCP FIN

Where's SNI request, where's the cert sent by the server?
Compare that to wireshark. See attached.
a.zip

Crash

*** glibc detected *** ../ssldump/ssldump: munmap_chunk(): invalid pointer: 0x0000000019911220 ***
======= Backtrace: =========
/lib/libc.so.6(+0x788d6)[0x7f797347f8d6]
../ssldump/ssldump[0x4025f7]
../ssldump/ssldump[0x40332d]
../ssldump/ssldump[0x40343f]
../ssldump/ssldump[0x4034fe]
../ssldump/ssldump[0x4031b0]
/usr/lib/libpcap.so.0.8(+0x530f)[0x7f7973a1830f]
/usr/lib/libpcap.so.0.8(pcap_loop+0x59)[0x7f7973a1c559]
../ssldump/ssldump[0x402d2c]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7f7973425c8d]
../ssldump/ssldump[0x4012d9]
======= Memory map: ========
00400000-0040d000 r-xp 00000000 08:01 371160                             /home/adulau/git/ssldump/ssldump
0060c000-0060d000 r--p 0000c000 08:01 371160                             /home/adulau/git/ssldump/ssldump
0060d000-00612000 rw-p 0000d000 08:01 371160                             /home/adulau/git/ssldump/ssldump
0153d000-31654000 rw-p 00000000 00:00 0                                  [heap]
7f7972e10000-7f7972e26000 r-xp 00000000 08:01 26872                      /lib/libgcc_s.so.1
7f7972e26000-7f7973025000 ---p 00016000 08:01 26872                      /lib/libgcc_s.so.1
7f7973025000-7f7973026000 r--p 00015000 08:01 26872                      /lib/libgcc_s.so.1
7f7973026000-7f7973027000 rw-p 00016000 08:01 26872                      /lib/libgcc_s.so.1
7f7973027000-7f7973407000 rw-s 00000000 00:06 7051833                    socket:[7051833]
7f7973407000-7f7973586000 r-xp 00000000 08:01 49570                      /lib/libc-2.11.1.so
7f7973586000-7f7973786000 ---p 0017f000 08:01 49570                      /lib/libc-2.11.1.so
7f7973786000-7f797378a000 r--p 0017f000 08:01 49570                      /lib/libc-2.11.1.so
7f797378a000-7f797378b000 rw-p 00183000 08:01 49570                      /lib/libc-2.11.1.so
7f797378b000-7f7973790000 rw-p 00000000 00:00 0
7f7973790000-7f7973812000 r-xp 00000000 08:01 30310                      /lib/libm-2.11.1.so
7f7973812000-7f7973a11000 ---p 00082000 08:01 30310                      /lib/libm-2.11.1.so
7f7973a11000-7f7973a12000 r--p 00081000 08:01 30310                      /lib/libm-2.11.1.so
7f7973a12000-7f7973a13000 rw-p 00082000 08:01 30310                      /lib/libm-2.11.1.so
7f7973a13000-7f7973a43000 r-xp 00000000 08:01 16610                      /usr/lib/libpcap.so.1.0.0
7f7973a43000-7f7973c43000 ---p 00030000 08:01 16610                      /usr/lib/libpcap.so.1.0.0
7f7973c43000-7f7973c44000 r--p 00030000 08:01 16610                      /usr/lib/libpcap.so.1.0.0
7f7973c44000-7f7973c45000 rw-p 00031000 08:01 16610                      /usr/lib/libpcap.so.1.0.0
7f7973c45000-7f7973c46000 rw-p 00000000 00:00 0
7f7973c46000-7f7973c66000 r-xp 00000000 08:01 30319                      /lib/ld-2.11.1.so
7f7973e57000-7f7973e5a000 rw-p 00000000 00:00 0
7f7973e62000-7f7973e65000 rw-p 00000000 00:00 0
7f7973e65000-7f7973e66000 r--p 0001f000 08:01 30319                      /lib/ld-2.11.1.so
7f7973e66000-7f7973e67000 rw-p 00020000 08:01 30319                      /lib/ld-2.11.1.so
7f7973e67000-7f7973e68000 rw-p 00000000 00:00 0
7fffeb4a9000-7fffeb4be000 rw-p 00000000 00:00 0                          [stack]
7fffeb5ff000-7fffeb600000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Aborted

Some times the -X option display only ASCII character

We see that in ssldump with -d and -X if the packet contains only ASCII character the hex dump was not printed.
The expectations is to have always two columns one with hex and one for the char.

Write the pcap into a fifo file

Hi, into the fork wllm-rbnt/ssldump was added the possibility to write the pcap into a fifo file (mkfifo test; ssldump -w test).

it is possible to merge this modification into the main branch?

here the link of the modify file.

https://github.com/wllm-rbnt/ssldump/blob/4a6fcb5963538e3d25fc6ab8d57095d6388ef563/pcap/logpkt.c

TLS 1.2: Decryption failure with a Session Ticket

Overview

Just found an issue with TLS 1.2 Session Tickets. Consider the following:

1 1  0.0180 (0.0180)  C>S  Handshake
      ClientHello
        Version 3.3
        cipher suites
        TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
        TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
        .....
        compression methods
                  NULL
        extensions
          server_name
              host_name: www.googleapis.com
          status_request
          supported_groups
            supported group                           x25519
            supported group                           secp256r1
            supported group                           secp384r1

          ec_point_formats
            ec point format                           uncompressed

          signature_algorithms
          session_ticket
          extended_master_secret
          renegotiation_info
1 2  0.0540 (0.0360)  S>C  Handshake
      ServerHello
        Version 3.3
        session_id[0]=

        cipherSuite         TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
        compressionMethod                   NULL
        extensions
          extended_master_secret
          renegotiation_info
          ec_point_formats
1 3  0.0540 (0.0000)  S>C  ChangeCipherSpec
1 4  0.0540 (0.0000)  S>C  Handshake
1 5  0.0550 (0.0010)  C>S  ChangeCipherSpec
1 6  0.0550 (0.0000)  C>S  Handshake
1 7  0.0710 (0.0160)  C>S  application_data

Analysis

Wireshark is able to decrypt this TLS 1.2 traffic with the previously captured secret (it's a CLIENT_RANDOM record, of course).

The issue with ssldump is that ssl_process_client_key_exchange() never runs because there is no "client key exchange" method.