aboutsummaryrefslogtreecommitdiff
path: root/src/lib/protocols/stun.c
Commit message (Collapse)AuthorAge
* Rework how hostname/SNI info is saved (#1330)Ivan Nardi2021-11-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | Looking at `struct ndpi_flow_struct` the two bigger fields are `host_server_name[240]` (mainly for HTTP hostnames and DNS domains) and `protos.tls_quic.client_requested_server_name[256]` (for TLS/QUIC SNIs). This commit aims to reduce `struct ndpi_flow_struct` size, according to two simple observations: 1) maximum one of these two fields is used for each flow. So it seems safe to merge them; 2) even if hostnames/SNIs might be very long, in practice they are rarely longer than a fews tens of bytes. So, using a (single) large buffer is a waste of memory for all kinds of flows. If we need to truncate the name, we keep the *last* characters, easing domain matching. Analyzing some real traffic, it seems safe to assume that the vast majority of hostnames/SNIs is shorter than 80 bytes. Hostnames/SNIs are always converted to lowercase. Attention was given so as to be sure that unit-tests outputs are not affected by this change. Because of a bug, TLS/QUIC SNI were always truncated to 64 bytes (the *first* 64 ones): as a consequence, there were some "Suspicious DGA domain name" and "TLS Certificate Mismatch" false positives.
* Fix writes to `flow->protos` union fields (#1354)Ivan Nardi2021-11-15
| | | | | | | | | | | | | | | | | | | | | | | | | We can write to `flow->protos` only after a proper classification. This issue has been found in Kerberos, DHCP, HTTP, STUN, IMO, FTP, SMTP, IMAP and POP code. There are two kinds of fixes: * write to `flow->protos` only if a final protocol has been detected * move protocol state out of `flow->protos` The hard part is to find, for each protocol, the right tradeoff between memory usage and code complexity. Handle Kerberos like DNS: if we find a request, we set the protocol and an extra callback to further parsing the reply. For all the other protocols, move the state out of `flow->protos`. This is an issue only for the FTP/MAIL stuff. Add DHCP Class Identification value to the output of ndpiReader and to the Jason serialization. Extend code coverage of fuzz tests. Close #1343 Close #1342
* Improved STUN and RTP detectionLuca Deri2021-10-27
|
* Fix compilation with clang-13 or if some debug macros are enabled (#1326)Ivan Nardi2021-10-06
|
* Remove `struct ndpi_packet_struct` from `struct ndpi_flow_struct` (#1319)Ivan Nardi2021-10-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are no real reasons to embed `struct ndpi_packet_struct` (i.e. "packet") in `struct ndpi_flow_struct` (i.e. "flow"). In other words, we can avoid saving dissection information of "current packet" into the "flow" state, i.e. in the flow management table. The nDPI detection module processes only one packet at the time, so it is safe to save packet dissection information in `struct ndpi_detection_module_struct`, reusing always the same "packet" instance and saving a huge amount of memory. Bottom line: we need only one copy of "packet" (for detection module), not one for each "flow". It is not clear how/why "packet" ended up in "flow" in the first place. It has been there since the beginning of the GIT history, but in the original OpenDPI code `struct ipoque_packet_struct` was embedded in `struct ipoque_detection_module_struct`, i.e. there was the same exact situation this commit wants to achieve. Most of the changes in this PR are some boilerplate to update something like "flow->packet" into something like "module->packet" throughout the code. Some attention has been paid to update `ndpi_init_packet()` since we need to reset some "packet" fields before starting to process another packet. There has been one important change, though, in ndpi_detection_giveup(). Nothing changed for the applications/users, but this function can't access "packet" anymore. The reason is that this function can be called "asynchronously" with respect to the data processing, i.e in context where there is no valid notion of "current packet"; for example ndpiReader calls it after having processed all the traffic, iterating the entire session table. Mining LRU stuff seems a bit odd (even before this patch): probably we need to rethink it, as a follow-up.
* STUN: fix extraction of Realm attributeNardi Ivan2021-09-20
| | | | While at it, improve detection of Facebook Messenger
* Cleaned up tls/quic datatypesLuca Deri2021-01-21
|
* Rewored UPnP protocol that in essence was WSD hence it has been renamedLuca2021-01-20
| | | | Cleaned up TLS code for DTLS detection by defining a new DTLS protocol
* Improves STUN dissection removing an invalid termination condition that ↵Luca Deri2021-01-13
| | | | prevented Skype calls to be properly identified
* (C) UpdateLuca Deri2021-01-07
|
* STUN: avoid false positives (#1110)Ivan Nardi2021-01-07
| | | STUN traffic doesn't use multicast addresses
* Various optimizations to reduce not-necessary callsLuca Deri2020-09-24
| | | | | Optimized various UDP dissectors Removed dead protocols such as pando and pplive
* Minor change for alignment issueLuca Deri2020-09-21
|
* Added (optional) notifier for LRU addLuca Deri2020-08-31
|
* Fixed valse positive whatsapp detectionLuca Deri2020-05-20
| | | | Cleaned Microsoft IP addresses list
* Updated (C)Luca Deri2020-01-05
|
* Fix read buffer overflow in stunPhilippe Antoine2019-12-18
|
* Code cleanupLuca Deri2019-12-09
|
* Fixed some false positivies with skype and stun-based protocolsLuca Deri2019-10-27
|
* nDPI TLS improvements using the server certificateLuca Deri2019-10-26
|
* Fixed false positive with STUN detectionLuca Deri2019-09-26
|
* Added Zoom protocol support removing invalid STUN/Skype detectionsLuca Deri2019-09-26
|
* Changed the packets handling with STUN msg_type > 0x000C and other fixes.marco-testa2019-09-24
| | | Eliminated double call to the ndpi_int_stun_add_connection function.
* Adedd DTLS check in STUNLuca Deri2019-09-21
| | | | Uodated (C)
* STUN protocol dissector code cleanupLuca2019-09-20
|
* Unified WhatsApp Video and Audio under WhatsAppCallLuca2019-09-20
|
* Improved STUN-based protocol heuristic both in terms of accuracy and packets ↵Luca2019-09-20
| | | | necessary for the detection
* Improved STUN cachingLuca Deri2019-09-18
|
* New instagram testing setLuca Deri2019-09-18
|
* Various STUN improvementsLuca Deri2019-09-17
|
* Added STUN check to avoid false positivesLuca Deri2019-09-11
| | | | | Added fingerprint comments in SSH/TLS Added netflow test pcap
* Skype STUN enhancementsLuca2019-09-06
|
* Enhanced Signal detectionLuca2019-09-05
|
* Enhanced STUN cacheLuca2019-09-05
|
* Implemented STUN cache to enhance matching of STUN-based protocolsLuca2019-08-12
|
* Improved google duo detectionLuca2019-08-12
|
* Various TLS/STUN improvememntsLuca2019-08-08
|
* Reworked SSL/TLS field namingLuca2019-08-08
|
* Implemented DTLS supportLuca2019-08-08
| | | | Renamed ssl to tls
* Better messenger traffic guessLuca Deri2019-07-25
|
* Added -e option to ndpiReader for searchign human readeable strings lenghtLuca Deri2019-07-24
| | | | Default human readeable strings lenght is not 5 chars (used to be 8)
* Updated results with new dissectionLuca Deri2019-07-24
|
* Merged Google Hangout and Duo as they are pretty similar from the network ↵Luca Deri2019-07-22
| | | | standpoint and from the features they implement
* Improved WhatsApp detectionLuca Deri2019-07-22
|
* STUN, Hangout, Duo dissection improvementsLuca Deri2019-07-21
|
* Added support for Google DuoLuca Deri2019-07-19
|
* Improved Facebook messnger mobile detectionLuca Deri2019-07-18
|
* Added Line protocol dissectionLuca Deri2019-07-15
| | | | Add fix for discarding STUN over TCP flows
* Solve remaining warningsStuart Reilly2019-07-12
|
* Improved whatsapp dissectionLuca Deri2019-07-11
|