mirror of
https://github.com/vel21ripn/nDPI.git
synced 2026-05-22 03:03:07 +00:00
d62ae567d1
To support QUIC payload and header decryption, it is necessary to choose an external crypto library to handle the low-level crypto stuff. Since we will use some Wireshark code, it is quite natural to choose the same library used by Wireshark itself: libgcrypt. More precisely, we will use libgcrypt and libgpg-error. Both libraries have LGPL license, so there should be no issue from this point of view. These libraries are not required to build nDPI, and their usage is optional: nDPI will keep working (and compiling) even if they are not available. However, without them, QUIC sub-classification is next to impossible. The configure flag "--disable-gcrypt" forces the build system to ignore these libraries. libgpg-error is only used for debug to have meaningful error messages and its usage is trivial. The same cannot be said for libgcrypt because its initialization is a significant issue. The rest of this commit message try explaining how libgcrypt is initialized. According to the documentation https://gnupg.org/documentation/manuals/gcrypt/Initializing-the-library.html https://gnupg.org/documentation/manuals/gcrypt/Multi_002dThreading.html#Multi_002dThreading libgcrypt must be initialized before using it, but such initialization should be performed by the actual application and not by any library. Forcing the users to proper initialize libgcrypt in their own code seems unreasonable: most people using nDPI might be complete unaware of any crypto stuff and update each and every one application linking to nDPI with specific libgcrypt code should be out of question, anyway. Fortunately, it seems a workaround exists to initialize libgcrypt in a library https://lists.gnupg.org/pipermail/gcrypt-devel/2003-August/000458.html Therefore, we could provide a wrapper to this initialization stuff in a nDPI function. Unfortunately nDPI API lacks a global init function that must be called only once, before any other functions. We could add it, but that would be a major API break. AFAIK, ndpi_init_detection_module() might be called multiple times, for example to create multiple independent dpi engines in the same program. The proposed solution is to (optionally) initialize libgcrypt in ndpi_init_detection_module() anyway: * if the actual application doesn't directly use libgcrypt and only calls ndpi_init_detection_module() once, everything is formally correct and it should work out of the box [by far the most common user case]; * if the actual application already uses libgcrypt directly, it already performs the required initialization. In this case the ndpi_prefs.ndpi_dont_init_libgcrypt flag should be passed to ndpi_init_detection_module() to avoid further initializations. The only scenario not supported by this solution is when the application is unaware of libgcrypt and calls ndpi_init_detection_module() multiple times concurrently. But this scenario should be uncommon. A completely different option should be to switch to another crypto library, with a huge impact on the QUIC dissector code. Bottom line: crypto is hard, using libgcrypt is complex and the proposed initialization, even if not perfect, should cover the most frequent user cases and should work, for the time being. If anyone has some suggestions... |
||
|---|---|---|
| .. | ||
| MacOS | ||
| Win32 | ||
| categories.txt | ||
| intrusion_detection.c | ||
| intrusion_detection.h | ||
| Makefile.dpdk.in | ||
| Makefile.in | ||
| mining_hosts.txt | ||
| ndpi2timeline.py | ||
| ndpiReader.c | ||
| ndpiSimpleIntegration.c | ||
| protos.txt | ||
| reader_util.c | ||
| reader_util.h | ||
| README.DPDK | ||
| uthash.h | ||
Prerequisites ------------- You need to install and compile DPDK in your HOME directory as explained in See http://core.dpdk.org/doc/quick-start/ for DPDK installation and setup Once DPDK is built make sure to create a symbolic link $ cd $ ln -s dpdk-18.08 DPDK so the build process will use the DPDK directory letting you have multiple DPDK versions available on your system Build ----- Everything will happen automagically but if you want to do it by hand do: make -f Makefile.dpdk Run Application --------------- Supposing to capture packets from device eno1 you can start the application as follows: sudo ./build/ndpiReader -c 1 --vdev=net_pcap0,iface=eno1 -- -v 1 NOTE: - ndpiReader without DPDK support sits in this directory - ndpiReader with DPDK support can be found inside the ./build directory