From ImageWeb

Contents 1 Using Wireshark 1.1 Enabling interfaces 1.2 Filters 1.2.1 Capture filters 1.2.2 Display filter 1.3 HTTPS tracing 1.3.1 Cipher suite selection 1.3.2 This bit is suspect ... 1.4 Further information

Using Wireshark

Enabling interfaces

Linux:

 setcap 'CAP_NET_RAW+eip CAP_NET_ADMIN+eip' /usr/bin/dumpcap

(see http://wiki.wireshark.org/CaptureSetup/CapturePrivileges). I can confirm this works on Ubuntu 10.04 desktop.

MacOS: use this script (needs to be run after every reboot):

 #!/bin/bash
 #
 # Set device protection to allow Wireshark traffic monitoring
 #
 sudo chmod a+r /dev/bpf*
 
 # End.

Filters

Capture filters and display filters are different

Capture filters

HTTP to specified host:

host a.b.c.d and (port 80 or port 443)

See: http://wiki.wireshark.org/CaptureFilters for more examples

Display filter

Just this often works:

http

HTTPS tracing

Encrypted HTTP traffic can be traced (on Linux, at least) if a copy of the server private key is available.

For the following description, I assume the key is at /etc/wireshark/server.key. It goes without saying that keys for live servers should be guarded carefully. Preferably, only do this for test servers for which a key compromise would not be a big problem. NOTE: the server key must be an RSA key not protected by a passphrase.

Select Wireshark menu "Edit > Preferences > Protocols > SSL"

In field RSA keys list:

a.b.c.d,443,http,/etc/wireshark/server.key

where a.b.c.d is the IP address of the server.

In field SSL debug file:

/var/log/wireshark.log

(*or similar)

See:

• http://wiki.wireshark.org/SSL
• http://blogs.sun.com/beuchelt/entry/decrypting_ssl_traffic_with_wireshark

Cipher suite selection

Wireshark is unable to decode traffic that uses a certified Diffie-Helman key exchange. This can lead to wireshark trace like this:

 Private key imported: KeyID AF:9E:26:CC:30:BF:80:28:EE:21:D3:EA:E6:BC:9A:C6:...
 ssl_init private key file /home/graham/admiral-demo.key successfully loaded
 association_add TCP port 443 protocol http handle 0x20ae3d90

  :

 association_find: TCP port 443 found 0x20f58d00
 packet_from_server: is from server - TRUE
 decrypt_ssl3_record: using server decoder
 decrypt_ssl3_record: no decoder available

  :

 dissect_ssl3_hnd_srv_hello can't find cipher suite 0x39
   record: offset = 86, reported_length_remaining = 1172

The fix I found for this is to edit the Apache ssl.conf file torestrict the use of such ciphers (for testing purposes only). The default ssl.conf on at least some recent Ubuntu distributions contains the following:

 #   SSL Cipher Suite:
 #   List the ciphers that the client is permitted to negotiate.
 #   See the mod_ssl documentation for a complete list.
 #   enable only secure ciphers:
 SSLCipherSuite HIGH:MEDIUM:!ADH

By changing the SSL:CipherSuite line to:

 SSLCipherSuite HIGH:MEDIUM:!DH

I find I Wireshark is able to decode the protocol exchanges. (The change disable use of *any* Diffie-Helpman key exchange protocols, rather than disabling just anonymous exchanges, which is what the default configuration does.

This bit is suspect ...

Getting Wireshark to display the decoded HTTP trace seems to be a bit "magical", but something like this might work:

1. Capture some HTTPS traffic
2. Select packet at start of SSL/HTTPS exchange
3. Menu: Analyze > Decode as...
4. Select destination port 443
5. Select "SSL" from protocol list, click "Apply"
6. Select "HTTP" from protocol list, click "Apply"

With luck, the display will now show HTTP decodes of the HTTPS exchange.

Further information

• http://admiral-announce.blogspot.com/2010/04/wireshark.html
• http://wiki.wireshark.org/CaptureFilters
• Very good Presentation on SSL troubleshooting by Sake Blok (sake (@) euronet nl):
  • Powerpoint: https://www.cacetech.com/sharkfest.09/AU2_Blok_SSL_Troubleshooting_with_Wireshark_and_Tshark.pps
  • Video: http://www.lovemytool.com/blog/2009/06/sake_blok_11.html

(Add more links here as discovered)