How to Capture Browser Traffic

[cfc4n]

Discussed in #711

^{Originally posted by xiewayne December 31, 2024}
Why is ecapture unable to capture HTTPS traffic from the Chrome browser? Checking Chrome's dependencies reveals that it has NSS.

# ./ecapture nss --nspr=/lib/x86_64-linux-gnu/libnspr4.so
2024-12-31T17:40:42+08:00 INF AppName="eCapture(旁观者)"
2024-12-31T17:40:42+08:00 INF HomePage=https://ecapture.cc
2024-12-31T17:40:42+08:00 INF Repository=https://github.com/gojue/ecapture
2024-12-31T17:40:42+08:00 INF Author="CFC4N <cfc4ncs@gmail.com>"
2024-12-31T17:40:42+08:00 INF Description="Capturing SSL/TLS plaintext without a CA certificate using eBPF. Supported on Linux/Android kernels for amd64/arm64."
2024-12-31T17:40:42+08:00 INF Version=linux_amd64:v0.8.10:6.5.0-1025-azure
2024-12-31T17:40:42+08:00 INF Listen=localhost:28256
2024-12-31T17:40:42+08:00 INF eCapture running logs logger=
2024-12-31T17:40:42+08:00 INF the file handler that receives the captured event eventCollector=
2024-12-31T17:40:42+08:00 WRN ========== module starting. ==========
2024-12-31T17:40:42+08:00 INF Kernel Info=6.6.28 Pid=12022
2024-12-31T17:40:42+08:00 INF listen=localhost:28256
2024-12-31T17:40:42+08:00 INF BTF bytecode mode: CORE. btfMode=0
2024-12-31T17:40:42+08:00 INF https server starting...You can update the configuration file via the HTTP interface.
2024-12-31T17:40:42+08:00 INF module initialization. isReload=false moduleName=EBPFProbeNSPR
2024-12-31T17:40:42+08:00 INF Module.Run()
2024-12-31T17:40:42+08:00 INF BPF bytecode file is matched. bpfFileName=user/bytecode/nspr_kern_core.o
2024-12-31T17:40:42+08:00 INF HOOK type:nspr elf ElfType=2 binrayPath=/lib/x86_64-linux-gnu/libnspr4.so
2024-12-31T17:40:42+08:00 INF target all process.
2024-12-31T17:40:42+08:00 INF target all users.
2024-12-31T17:40:42+08:00 INF perfEventReader created mapSize(MB)=4
2024-12-31T17:40:42+08:00 INF module started successfully. isReload=false moduleName=EBPFProbeNSPR

# ldd /opt/apps/cn.google.chrome/files/google/chrome/chrome
	linux-vdso.so.1 (0x00007ffffef7d000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f724d84c000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f724d82b000)
	libgobject-2.0.so.0 => /lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f724d7d5000)
	libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f724d6b5000)
	libnss3.so => /lib/x86_64-linux-gnu/libnss3.so (0x00007f723feb2000)
	libnssutil3.so => /lib/x86_64-linux-gnu/libnssutil3.so (0x00007f723fe80000)
	libsmime3.so => /lib/x86_64-linux-gnu/libsmime3.so (0x00007f723fe51000)
	libnspr4.so => /lib/x86_64-linux-gnu/libnspr4.so (0x00007f723fe10000)
        .....

But my own test program(https_test) that relies on NSS works.

"module started successfully. isReload=false moduleName=EBPFProbeNSPR
2024-12-31T17:14:51+08:00 ??? UUID:10609_10609_https_test_1, Name:HTTPRequest, Type:1, Length:58
GET / HTTP/1.1
Host: www.baidu.com
Connection: close
"
# ldd https_test 
	linux-vdso.so.1 (0x00007ffc2371c000)
	libssl3.so => /lib/x86_64-linux-gnu/libssl3.so (0x00007fa4dbfc1000)
	libnss3.so => /lib/x86_64-linux-gnu/libnss3.so (0x00007fa4dbe73000)
	libnssutil3.so => /lib/x86_64-linux-gnu/libnssutil3.so (0x00007fa4dbe41000)
	libnspr4.so => /lib/x86_64-linux-gnu/libnspr4.so (0x00007fa4dbe00000)
```</div>

[dosubot]

Hello, @cfc4n! I'm here to help you with any bugs, questions, or contributions while you're waiting for a human maintainer. Let's work together to resolve the issue you're facing.

I found a similar discussion titled "How to Capture Browser Traffic" on the eCapture GitHub page, which addresses the issue of eCapture not being able to capture HTTPS traffic from Chrome. The discussion highlights that while a user's test program relying on NSS successfully captures HTTPS traffic, eCapture fails to do so with Chrome. This suggests that the issue might be specific to how eCapture interacts with Chrome's NSS implementation ^[1].

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other}

[cfc4n]

@xiewayne

Chrome may use multiple TLS libraries, and you need to confirm which one or which ones they are.

[xiewayne]

@xiewayne

Chrome may use multiple TLS libraries, and you need to confirm which one or which ones they are.

Thank you for your reply. After checking, it appears that Chrome uses BoringSSL, and it seems to be a static dependency. Given this, does it mean that capturing plaintext is no longer feasible?

[cfc4n]

@xiewayne
Chrome may use multiple TLS libraries, and you need to confirm which one or which ones they are.

Thank you for your reply. After checking, it appears that Chrome uses BoringSSL, and it seems to be a static dependency. Given this, does it mean that capturing plaintext is no longer feasible?

@dosu please answer this question.

@xiewayne If you have additional questions, you can metion @dosu for faster answers. (ecapture tls --libssl=/path/chrome)

[dosubot]

Capturing plaintext from applications using static libraries like BoringSSL is still feasible with eCapture. You can set the --libssl parameter to the path of the program using static compilation. For example, you can use the following command:

sudo ecapture tls --libssl=/path/to/chrome

This approach is part of the OpenSSL module in eCapture, which supports capturing plaintext data from various TLS/SSL encryption libraries, including BoringSSL ^[1][2].

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other}

[xiewayne]

@xiewayne
Chrome may use multiple TLS libraries, and you need to confirm which one or which ones they are.

Thank you for your reply. After checking, it appears that Chrome uses BoringSSL, and it seems to be a static dependency. Given this, does it mean that capturing plaintext is no longer feasible?

@dosu please answer this question.

@xiewayne If you have additional questions, you can metion @dosu for faster answers. (ecapture tls --libssl=/path/chrome)

OK.

When I ran

./ecapture tls --libssl=/opt/apps/cn.google.chrome/files/google/chrome/chrome. I encountered the following error: 
FTL module run failed, skip it. error="couldn't start bootstrap manager error:7 errors occurred:\n\t* error:opening uprobe: symbol SSL_write: not found , isRet:false, opts:&{0 0 0 0 0 }, {UID:, EbpfFuncName:probe_entry_SSL_write}\n\t* error:opening uprobe: symbol SSL_write: not found , isRet:true, opts:&{0 0 0 0 0 }, {UID:, EbpfFuncName:probe_ret_SSL_write}\n\t* error:opening uprobe: symbol SSL_read: not found , isRet:false, opts:&{0 0 0 0 0 }, {UID:, EbpfFuncName:probe_entry_SSL_read}\n\t* error:opening uprobe: symbol SSL_read: not found , isRet:true, opts:&{0 0 0 0 0 }, {UID:, EbpfFuncName:probe_ret_SSL_read}\n\t* error:opening uprobe: symbol SSL_set_fd: not found , isRet:false, opts:&{0 0 0 0 0 }, {UID:uprobe_ssl_set_fd, EbpfFuncName:probe_SSL_set_fd}\n\t* error:opening uprobe: symbol SSL_set_rfd: not found , isRet:false, opts:&{0 0 0 0 0 }, {UID:uprobe_ssl_set_rfd, EbpfFuncName:probe_SSL_set_fd}\n\t* error:opening uprobe: symbol SSL_set_wfd: not found , isRet:false, opts:&{0 0 0 0 0 }, {UID:uprobe_ssl_set_wfd, EbpfFuncName:probe_SSL_set_fd}\n\n, probes activation validation failed .

@dosu How to solve this problem?

[xiewayne]

I also used a test program with a statically linked SSL library. When the symbol table was not stripped, it indeed worked by specifying --ssl=/path/to/https-test-static. However, if the symbols were stripped during compilation, ecapture would fail to run due to the inability to find the symbols, resulting in the same error as when running with Chrome.

[hengyoush]

I also used a test program with a statically linked SSL library. When the symbol table was not stripped, it indeed worked by specifying --ssl=/path/to/https-test-static. However, if the symbols were stripped during compilation, ecapture would fail to run due to the inability to find the symbols, resulting in the same error as when running with Chrome.

@dosu Please answer this question.

[cfc4n]

I also used a test program with a statically linked SSL library. When the symbol table was not stripped, it indeed worked by specifying --ssl=/path/to/https-test-static. However, if the symbols were stripped during compilation, ecapture would fail to run due to the inability to find the symbols, resulting in the same error as when running with Chrome.

@dosu Please answer this question.

@dosu Please answer this question

[dosubot]

When dealing with statically linked libraries and stripped symbols, eCapture faces challenges in locating the necessary symbols to hook into SSL/TLS functions. This is because the symbols required for setting up probes are not available in the binary, making it difficult for eCapture to function as intended.

For binaries with stripped symbols, eCapture typically relies on reconstructing the symbol table using sections like .gopclntab in Go binaries. However, this approach is not applicable to all binaries, especially those using libraries like BoringSSL, which may not provide similar sections for symbol reconstruction.

Unfortunately, if the symbols are stripped and eCapture cannot reconstruct them, capturing plaintext traffic becomes infeasible with the current capabilities of eCapture. One potential workaround is to ensure that the binaries are compiled without stripping symbols, allowing eCapture to access the necessary symbol information. Alternatively, you might need to explore other tools or methods that can handle stripped binaries more effectively, though this might involve more complex setups or custom solutions.

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other}

[cfc4n]

@xiewayne refer #633

[xiewayne]

OKay, thank you for your answer. I have no other questions. @cfc4n @dosu

[dosubot]

Hey @cfc4n! It looks like you're asking about something that I can't help with directly. I'm here to tackle bugs, technical questions, and engineering knowledge. If you think I should have been able to help, feel free to reach out to the Dosu Team. They'll be happy to hear from you!

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other}