17

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?

Peter Mortensen
  • 877
  • 5
  • 10
ShinobiUltra
  • 782
  • 7
  • 16
  • 1
    Just to be clear. Not all packets are encrypted. Are you talking only about encrypted packets? – Limit Dec 25 '16 at 14:47
  • As in your HTTP and FTP traffic goes as plain text to the receiver. – Limit Dec 25 '16 at 14:47
  • Yes you can, mitming your network and installing root certificate. Fiddler does it. – Xavier59 Dec 25 '16 at 15:38
  • 1
    Malware doesn't even need root privs to manipulate a client running on the same user. – CodesInChaos Dec 25 '16 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. – Peter Cordes Dec 25 '16 at 23:50
  • IDK if anyone uses IPsec, but it does encrypt each packet separately. [It can run](https://en.wikipedia.org/wiki/IPsec#Modes_of_operation) as a tunnel (VPN-style), or on top of IP (and then I guess with TCP inside the IPsec payload so port number would be secret?) Unless you use it as a VPN, anyone sniffing your packets can still see you're talking to facebook servers, though, they just can't tell what port you're connecting to. (This would be more relevant for some other kind of site, hiding e.g. FTP vs. HTTP vs. SSH vs. whatever.) – Peter Cordes Dec 25 '16 at 23:52
  • 1
    @PeterCordes I agree. Headers aren't encrypted – Limit Dec 26 '16 at 00:56

3 Answers3

27

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).

Lekensteyn
  • 5,898
  • 5
  • 37
  • 62
  • 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 '16 at 06: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](http://security.stackexchange.com/q/107306/2630). – Lekensteyn Dec 26 '16 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 '16 at 12:22
23

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.

tylerl
  • 82,225
  • 25
  • 148
  • 226
  • 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 '16 at 07: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 '16 at 03:45
  • Ha! I did not know that. I had a look at [RFC7469](https://tools.ietf.org/html/rfc7469#section-2.6) 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 '16 at 17:26
4

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.

David Schwartz
  • 4,203
  • 24
  • 21