as I'm thinking that someone is doing nasty things in the SSL-traffic, I thought of decrypting the ssl, capture the decrypted packets and put the into wireshark to look at it.
Only I could not find a way of explicit tell the PA to capture the decrypted traffic only.
Is there someone out being able to help me with that topic?
Thanks a lot
Solved! Go to Solution.
It is not possible to get the unencrypted traffic out of the box. To be able to decrypt SSL you need the certificate to be able to do this. Since you want to look inside I assume that you have the certificate. What you can do is capture the SSL traffic and use this trace and wireshark to decrypt it.
For more info I found this site:
As mentioned by marcel, we are not able to get decrypted traffic of the box.
We are also unable to get a private key from the certificate that was generated/used for ssl decryption (forward-proxy).
So we can't decrypt forward proxy captures at all.
I would like to ask some more questions on this.
We are decrypting traffic towards one of the websites.
The decryption is successful and we see that application is now web-browsing and not SSL.
I want to create a custom application for certain part of this site.
While taking the packet capture on Palo Alto I have to specify the following:
debug dataplane packet-diag set capture stage (drop,firewall,receive,transmit) , so I ended up with 4 .PCAP files.
All traffic appears encrypted in Wireshark.
I extracted Private Key from the certificate and tried to apply it to Wireshark but wireshark doesn't decrypt anything in any of the 4 files.
My question is if I have to have all traffic in one log file (one pcap) in order to decrypt it in wireshark ?
Have anybody been successful taking packet capture from Palo Alto and decrypting it in Wireshark after ?
Traffic detected in PCAP show as TLSv1 for the interesting traffic.
Any thoughts of advice?
Thank You in advance!
It's best to start a new thread if you have your own question. That'll make things more easily searchable in the forum for future users.
To answer your question, the certificate is created on the fly when doing SSL decryption. That private key is not exportable, and is discarded after a cache period. You will not be able to decode the traffic later in Wireshark (or any other tool) because of that.
Hope this helps,
Thank You for your prompt reply Greg,
I found this easy by "ssl decrypt wireshark " and thought to keep it that way :smileyhappy:
I went a bit further ahead and placed the certificate into Wireshark capture.
I found interesting entries:
dissect_ssl3_hnd_srv_hello found CIPHER 0x0035 -> state 0x16
dissect_ssl3_hnd_srv_hello trying to generate keys
ssl_generate_keyring_material not enough data to generate key (0x16 required 0x37 or 0x57)
According to some posts in other forums, Wireshark throws that error when it doesn't have a full SSL Handshake, but only short SSL handshakes (resumed SSL sessions).
Indeed my capture was taken from resumed session, I already had website open.
I was thinking to do the full capture again, start fresh but your post made me thinking again.
You are saying that the Private Key is generated on the fly on Palo Alto so It's impossible to capture decrypted traffic into PCAP files for analysis ?
How can Palo Alto build custom apps then ? Surly, they are not being given Server Certificates of the companies they are making signatures for ?
The firewall acts as the client when talking to the web server. It pulls the cert info from the server cert, then uses the CN and validity period to generate a new private/public key pair on the fly. It is that newly generated cert that is sent to the client in a separate session. This temporary cert is discarded after a cache period, and a new one is created again should another user go to that site.
The firewall has the data fully decrypted on-box, but with the two separate SSL connections (separate session keys, etc.) the encryption is maintained client- and server-side.
By the way there are two modes of SSL decryption within PA:
1) SSL Decrypt
Client traffic is being intercepted towards outbound server (MITM-attack). One SSL session towards client and another towards server. Client should have the CA which the PA uses to create the MITM cert towards the client as a trusted CA to not get any warnings. This is for the case when you have control of the clients (but not the servers). For example if you want to control and log what the clients at your company does on the Internet.
2) SSL Inspection
Client setups a SSL session straight to the server. In this case there is only a single SSL session (between the client and the server). Because the PA unit has got the private key of the server PA can then inspect whats happening within this SSL session and if something bad is detected it can kill the session. This is for the case when you have control of the servers (but not the clients). For example if you wish to protect your DMZ webservers against evil clients on the Internet. Note however that this method doesnt work if DH (Diffie-Hellman) is being used in the SSL session.
SSL Inspection is the same method as if you do a tcpdump on the network (or on the server) and feed wireshark the private key (again only works if DH is not being used).
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!
The Live Community thanks you for your participation!