Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

There is software installed on all client machines for DLP (Data Loss Prevention) and HIPAA compliance. Supposedly it can read HTTPS data clearly. I always thought that between the browser and the server, this was encrypted entirely. How can software sneak in and grab this data from the browser prior to it is encrypted or after it is decrypted? I am just curious as to how this could be possible. I would think that a browser wouldn't be considered very secure if this was possible.

share|improve this question
You probably know this already but the browser is only as secure as the machine it runs on. If I have unfettered access to a PC then there are numerous ways to monitor (all) activity on the machine. – BJ292 Jun 18 '12 at 20:09
up vote 2 down vote accepted

Software installed on the client can access data before it is encrypted (or after it is decrypted) by modifying or hooking into browser code. Numerous methods of injecting code into the browser exist, including Browser Helper Objects (Internet Explorer) or extensions (other browsers).

In addition to data loss prevention software, malware that steals online banking credentials, including Zeus, uses this "man-in-the browser" technique. Some malware even uses a kernel-mode rootkit to avoid detection.

Note that other methods of sniffing HTTPS traffic also exist, including the addition of a "trusted" CA (certification authority) to the browser to make a man-in-the-middle attack possible. (In at least one case, an established CA actually signed such a subordinate CA, making installation of the certificate unnecessary for a successful attack.)

share|improve this answer
This is commonly done. An enterprise configures a proxy server and installs a certificate that matches * - all the browsers make https connections which terminate at the proxy server which thens reads/saves/modifies/scans the data and establishes an https session with the actualy destination server. A sophisticated user can look at the certificate presented to their browser and know, but no one but me checks the certificates manually ;) – Ram Jun 18 '12 at 20:01

I believe it is possible to sniff the connection via a proxy, but is not possible to see the encrypted data. It would have be prior or post encryption.

Does https prevent man in the middle attacks by proxy server?

Observing an HTTPS connection... decrypt it?

Here is one analogy as to what transpires during a https connection:

Imagine a lock-box, the kind with a metal flap that you put a padlock on to secure. Imagine that the loop where you put the padlock is large enough to fit two padlocks. To securely exchange send something to another party without sharing padlock keys, you would

  1. put the "Thing" in the box, and lock it with your padlock.
  2. send the locked box to the other party.
  3. they put their padlock on the loop also (so that there are two locks on it), and return the double-locked box to you
  4. You remove your padlock, and return the now singly-locked box to them.
  5. they remove their own lock and open the box.

With encryption the locks and keys are math, but the general concept is vaguely like this.

share|improve this answer
That's an excellent non-technical analogy of the process! Continuing the analogy, I assume there are ways (hopefully unbreakable/unspoofable) to tell: who owns the box, who sent you the box, who applied the locks, who the locks belong to, ... – Kevin Fegan Oct 8 '12 at 0:49

You must log in to answer this question.

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