I mean, if I am, for example, on Facebook, every packet I send out of my NIC is encrypted. But there must be phase of that packet before it is encrypted. The browser (I think) must create that packet and encrypt it afterwards. So if I am on the machine creating those packets, am I able to see them before encryption?

And if yes, are there malware capable of doing this? I think with administrator/root privileges it is certain that it can, but what about without them?

  • 1
    Just to be clear. Not all packets are encrypted. Are you talking only about encrypted packets?
    – Limit
    Dec 25, 2016 at 14:47
  • As in your HTTP and FTP traffic goes as plain text to the receiver.
    – Limit
    Dec 25, 2016 at 14:47
  • 1
    Malware doesn't even need root privs to manipulate a client running on the same user. Dec 25, 2016 at 18:52
  • 3
    @Limit: Even with HTTPS, your packets aren't encrypted, only the data in them. The TCP and IP headers on each packet are no different than for an HTTP connection (except the server's port number in the TCP header is usually 443 instead of 80). Anyone that can see your packets can tell you're on facebook, unless you use a VPN. Dec 25, 2016 at 23:50
  • 1
    @PeterCordes I agree. Headers aren't encrypted
    – Limit
    Dec 26, 2016 at 0:56

3 Answers 3


With the availability of browser extensions, actually reading the traffic should be quite doable. If both the malware and web browser run as the same user (and therefore can write to the browser profile directory), then installation of browser extensions can be done relatively easily.

You can also open the Web Developer Tools, typically accessible by pressing F12 and visit the Networking tab. That will show you all traffic before it is encrypted and pushed onto the network.

The above methods are passive ways that do not interfere with communications. Active methods perform a man in the middle (MitM) attack and actually modify data before it gets forwarded (Tylerl describes an example with Fiddler).

  • You can use the SSLKEYLOG environment variable to have the browser dump the encryption secrets, so that Wireshark can reassemble the plaintext content.
    – Riking
    Dec 26, 2016 at 6:13
  • The SSLKEYLOGFILE method is another passive method, but technically you are then decrypting traffic and not looking at the data before they get encrypted. For the concerned, see also this question about how this is done.
    – Lekensteyn
    Dec 26, 2016 at 10:58
  • installation of browser extensions can be done relatively easily - not so feasible nowadays. Extensions has to be signed by vendor in order to run (at least recent FF and Chrome).
    – rkosegi
    Dec 27, 2016 at 12:22

The network traffic out of your browser gets encrypted before the browser calls send() to put it on the network. So to intercept it before encryption, you'd have to intercept it before it's sent at all -- that is, within the browser itself. This isn't impossible, but it's a lot of work.

An alternative is to set up a "Man In The Middle" proxy, such as fiddler, which decrypts the traffic before it leaves your network, inspects it, and then re-encrypts it on its way out. Generally SSL is designed to prevent this, so you'll need some amount of cooperation by your computer to allow it (i.e. your browser will have to trust fiddler's public key) but this is all part of how you set up fiddler, so it's well-enough documented.

  • 1
    This approach may not work if the server implements [HPKP](en.m.wikipedia.org/wiki/HTTP_Public_Key_Pinning) , that is actively prevents the decoding-reincoding part to work
    – WoJ
    Dec 27, 2016 at 7:20
  • 1
    @WoJ - Browsers will automatically disable HPKP in cases of a locally-trusted cert specifically to allow companies to inspect their own traffic with local MITM proxies for AV, DLP, and similar concerns. This is a lesser-known feature of key pinning that probably would be a lot more controversial if people knew it was there.
    – tylerl
    Dec 28, 2016 at 3:45
  • Ha! I did not know that. I had a look at RFC7469 and, indeed, it states that Pin Validation might not be in effect, e.g., (...) because a presented certificate chain chains up to a user-defined trust anchor. In such cases, UAs SHOULD NOT send reports.. I agree, the feature becomes way more controversial in an enterprise setting.
    – WoJ
    Dec 29, 2016 at 17:26

The browser (I think) must create that packet and encrypt it afterwards. So if I am on the machine creating those packets, am I able to see them before encryption?

No, that's not how it works. Inside the browser, the data is encrypted and only encrypted data is passed between the browser and the network stack. The network stack splits the encrypted data into packets and re-assembles received encrypted data from packets back into the stream of data for the browser to decrypt. There simply aren't any packets at the level the browser handles, and the browser handles the encryption and decryption.

So your question is based on a false premise.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .