In tools like tcpdump, when exactly are network packets captured?

Question

One of the tools I use uses encryption / decryption to send data over the network. I am changing the tool, and I need to be sure that the data is actually sent in encrypted form.

Are Wireshark and tcpdump the right tools for this purpose? At what point do they capture network packets during transmission?

Answer 1

Both of these tools capture data in exactly the same way as wire. (Think of it as the equivalent of "tee" for output, which will display the same as the file, as well as the same data coming into the socket, as well as into tcpdump or something else.)

So, if your tool is configured correctly to encrypt data before sending it, then tcpdump or Wireshark should reflect this in their packet captures.

Answer 2

Short answer: packages are used at the very end of the network software stack (for example, on Linux).

Long answer with code in tcpdump, libpcap and linux kernel 3.12:

Both Wireshark and tcpdump use libpcap, for example,

http://sources.debian.net/src/tcpdump/4.5.1-2/tcpdump.c#L1472

if (pcap_setfilter(pd, &fcode) < 0) 

which, in turn, set the packet filter through setfilter_op and activate_op. There are many implementations of these operations, and I think that in recent Linux PF_PACKET will be used with pcap_activate_linux libpcap-1.5.3-2 / pcap -linux. C # L1287 :

 /* * Current Linux kernels use the protocol family PF_PACKET to * allow direct access to all packets on the network while * older kernels had a special socket type SOCK_PACKET to * implement this feature. * While this old implementation is kind of obsolete we need * to be compatible with older kernels for a while so we are * trying both methods with the newer method preferred. */ status = activate_new(handle); ... activate_new(pcap_t *handle) ... /* * Open a socket with protocol family packet. If the * "any" device was specified, we open a SOCK_DGRAM * socket for the cooked interface, otherwise we first * try a SOCK_RAW socket for the raw interface. */ sock_fd = is_any_device ? socket(PF_PACKET, SOCK_DGRAM, htons(ETH_P_ALL)) : socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL)); 

PF_PACKET is implemented in the kernel in the file net / packet / af_packet.c . Initialization of PF_SOCKET is performed in packet_do_bind using the register_prot_hook(sk) function (if the device is in UP state), which calls dev_add_pack from net / core / dev.c to register the hook:

  370 /** 371 * dev_add_pack - add packet handler 372 * @pt: packet type declaration 373 * 374 * Add a protocol handler to the networking stack. The passed &packet_type 375 * is linked into kernel lists and may not be freed until it has been 376 * removed from the kernel lists. 377 * 378 * This call does not sleep therefore it can not 379 * guarantee all CPU that are in middle of receiving packets 380 * will see the new packet type (until the next received packet). 381 */ 382 383 void dev_add_pack(struct packet_type *pt) 384 { 385 struct list_head *head = ptype_head(pt); 386 387 spin_lock(&ptype_lock); 388 list_add_rcu(&pt->list, head); 389 spin_unlock(&ptype_lock); 390 } 

I think the pf_packet handler - tpacket_rcv(...) function - will be registered in ptype_all.

Hooks registered in ptype_all are called for outgoing packets from dev_queue_xmit_nit ("Subroutine support. Send outgoing frames to any currently used network cranes") using list_for_each_entry_rcu(ptype, &ptype_all, list) { ... deliver_skb ...} .. func , deliver_skb calls the tpacket_rcv function for libpcap.

dev_queue_xmit_nit is called from dev_hard_start_xmit ( line 2539 in net / core / dev.c ), which is AFAIK at the last stage (for outgoing packets) independent of the packet processing device in the Linux network stack.

The same applies to incoming packets, ptype_all -registered hooks are called from __netif_receive_skb_core with the same list_for_each_entry_rcu(ptype, &ptype_all, list) {.. deliver_skb..} . __netif_receive_skb_core is called from __netif_receive_skb at the very beginning of the processing of incoming packets

At the base of Linux there is a good description of the network stack ( http://www.linuxfoundation.org/collaborate/workgroups/networking/kernel_flow ), you can see dev_hard_start_xmit in the image http://www.linuxfoundation.org/images/1/1c/ Network_data_flow_through_kernel.png (warning, it is huge) on the left side under the legend. And netif_receive_skb is located inside the very right bottom square ("net / core / dev.c"), which is supplied from the IRQ, then a NAPI poll or netif_rx, and the only way out is netif_receive_skb .

The picture shows one of the two pf_packet hooks - the leftmost square under the symbol (net / packet / af_packet.c) - for outgoing packets.

What is your tool? How does it connect to the network stack? If you can find the tool in the Network_data_flow file , you will get a response. For example, Netfilter is connected ( NF_HOOK ) only in ip_rcv (inbound) ip_output (local outbound) and ip_forward (outbound routing) - immediately after netif_receive_skb and immediately before dev_queue_xmit .

Answer 3

Yes, these are the right tools. Wireshark will detect TLS and SSL packets if this is what you use for encryption. You can provide Wireshark with the server’s private key and decrypt the traffic if necessary (with the exception of ephemeral modes such as DHE and ECDHE).