Fog Creek Software
Discussion Board




https tracking - public privacy enemy #1

Hey everybody,

Nobody seems to have caught on to this thing that everyone is doing so I thought I'd blow the lid off this scam. I am hoping some nice journalist will read this and put a good spin on it since the practice needs to be stopped.

Anyway, https connections were once considered something that *protects* your privacy, and now they have instead become the #1 way to invade your privacy surrepititiously.

Here's how the scam works:

You connect to random-site.com. You have cookies, javascript,  everything you can think of disabled. Your dial-up rotates ip addresses. Your privacy is assured, right? Wrong!

Random-site.com contains a link to an image at paypal.com stored using a https, which is a strange thing to be doing. A secure connection for a logo image?? That image is loaded using a secure connection. Your computer gives it a encryption key which it uses to send the data. That encryption key is -- Surprise! Unique to your computer! It is your fingerprint!

At some point you have given one of these sites your real name and email address. From then on out, there is a link between your public encryption key and your actual identity.

Public key encryption - decimating your privacy.

Only three solutions here:

1. Disable all image loading.
2. Disable all https connections.
3. Pass legislation.

Oh wait, here's a good one actually that would work. I thought of it myself:

4 Browsers should have an option to refuse to even make a connection to any image using a https protocol. Any scripted connnection as well. Only clicks using https should be allowed and even then a warning should be put up that privacy is about to be compromised.

Dennis Atkins
Tuesday, June 29, 2004

I simply blocked the entire paypal.com domain ages ago, though I confess I hadn't considered the encryption key aspect. I did it because the junkbuster proxy will not block cookies sent via https connections so I kept getting annoying messages from my browser asking me if I wanted to accept some cookie or not.

You might have a look and see if junkbuster suits your needs, Dennis (junkbuster.com) - I'm not sure you can set it up to do exactly what you want, but maybe you can. I have a feeling you can allow port 443 access only for sites which you specify and not for anything else, which might suit your needs.


Tuesday, June 29, 2004

If you're running firefox,  just delete your certificates from your profile directory.  Or use tools->options->advanced->certificates.

Koz
Tuesday, June 29, 2004

This is totally bogus. How does random-site.com get your "fingerprint"? And also the SSL system just encrypts your submitted data with the sites public key. That hardly is a fingerprint.

Matthew Lock
Tuesday, June 29, 2004

random-site.com is a unaware party in all this - its paypal that aggregates the data. Its similar to the scheme that adclick and all those ad sites were running to do tracking via cookies. But this method doesn't require cookies. The information sent to you is encoded using your key. The information you send them is encoded using their key. But you don't send them any information, they send you information - the https'd image file with the paypal logo. You send them your key to get that data and that key identifies you uniquely.

There are others besides paypal doing this - I just picked them as an example. Start monitoring outgoing https connections unexpectedly initiated by your browser to get a handle on the practice for yourself. You'll see.

Dennis Atkins
Tuesday, June 29, 2004

I meant doubleclick not adclick.

For myself, I have a traffic filter that notifies me of all outgoing https requests and gives me a chance to block or permit them. Seems an ok solution unless there is something I am missing, but I think the general public needs to know they are being monitored with this insidious tracking scheme.

Dennis Atkins
Tuesday, June 29, 2004

Make sure you check your tinfoil hat for any gaps in the foil too.

Matthew Lock
Tuesday, June 29, 2004

Have you tried Mozilla AdBlock Extension. I think it will work on HTTPS connections also. 

Anyone has experience on using AdBlock HTTPS connections and how well it works.

I used to use JunkBuster then shifted to Proxomitron.

Nitin Bhide
Tuesday, June 29, 2004

Matthew,

Thanks for your insightful technical analysis.

Dennis Atkins
Tuesday, June 29, 2004

In normal SSL, the client's public key is not sent. It is only sent if the server requests it.

So for this to work, one of two things must be true:
1) The information sent to initiate an SSL connection (the client's SSL version number, cipher settings, randomly generated data, and other information the server needs to communicate with the client using SSL) is unique and constant on a per-user basis.

2) The server can request the client PK with no configuration required on the part of the user.

If this is really a problem, then there are two easy fixes:
1) Ensure that this data is *not* unique and constant on a per-user basis
2) Ensure that the client certificate can't be sent to the server without client permission.

Feedback cc'd to IE team on both.

Philo

Philo
Tuesday, June 29, 2004

One other thought, in the "why are they using SSL for images" realm - perhaps
https://www.paypal.com/  != http://www.paypal.com/

and therefore the images can duck around many/most ad blockers?

Philo

Philo
Tuesday, June 29, 2004

Dennis, can you give us an examples of this snooping?

Matthew Lock
Tuesday, June 29, 2004

> and therefore the images can duck around many/most ad blockers?

Firefox's adblock just accepts expressions. So a few like */ad/* and */banners/* will still work no matter what the transport used.

Matthew Lock
Tuesday, June 29, 2004

Well if paypal own the domain I can't see anyone else using it to run an https server without their knowledge. It's not like https uses separate DNS or anything?

Matt
Tuesday, June 29, 2004

oops i got the wrong end of the sticl../ nevermind

Matt
Tuesday, June 29, 2004

This thread is such a load.

> Your computer gives it a encryption key which it uses to send the data. That encryption key is -- Surprise! Unique to your computer! It is your fingerprint!

That's not how SSL works.  If it were, the situation would be worse than you describe.  Not only could they track you, anybody you had ever had an SSL session with could read all of your SSL traffic ever.  The session key is generated on the fly and encrypted with the server certificate key.  If the server requests, the browser can authenticate itself with a certificate.

Brian
Tuesday, June 29, 2004

dennis, take off the tin-foil hat... or provide details on how SSL is different than the rest of us think it is.

however, there is one possible reason why they'd do this for tracking: proxy servers. someplace like AOL might decide to ignore the proxy settings on the http connection and cache the file anyway, so they can't track you. but the proxy won't stop you from connecting the server directly. and a proxy like proxomotron will also have problems filtering stuff from the https connection, though i believe you can set it up as a man-in-the-middle with a few tweaks in your IE settings.

mb
Tuesday, June 29, 2004

Brian:
"That's not how SSL works.  If it were, the situation would be worse than you describe.  Not only could they track you, anybody you had ever had an SSL session with could read all of your SSL traffic ever. "

You also have SSL wrong.  The key referred to higher up is your public key, which is what someone else uses to encrypt data to send to you.  A private key is used to un-encrypt the data.  Having someone's public key doesn't allow you to read data EVER, not even during your transaction with them.  So you don't change your SSL public key.  That’s the beauty of SSL, you can sent people your key over a non-secure connection without having to worry about someone else getting the key and reading the data returned to you.

Steamrolla
Tuesday, June 29, 2004

If I remember right (and maybe I am wrong and Dennis is right), the public key cryptography is done entirely with the server's keys.  That is, the server's public key is sent out, the client verifies its signature, and the client just uses random info to pick out a hash.

The rest of the connection actually uses a stream cipher with a one-time generated key.

Note: Client authentication has both sides sharing public keys. Again, this is only done in the handshake. And most user agents will prompt you when this is happening, and most people don't even have a client cert.

mb
Tuesday, June 29, 2004

I think I read something similar to this on Phil Greenspun's website..I think it was his web publishing book.

Prakash S
Tuesday, June 29, 2004

Public key encryption has nothing to do with the OP's tinfoil hat panic mode proclamation. There is absolutely nothing sent to the server that uniquely identifies you, UNLESS:

1. The server is set to require a client-side certificate;
2. You have a client-side certificate (most people don't);
3. You have told the browser that it's okay to send it.

99.9999999% of internet users don't have a personal certificate. As far as I know, every single browser on the market prompts before EVER sending a client-side certificate.

/resume paranoid delusions

Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, June 29, 2004

Yes. This thread is generously referred to as 'a crock'. Using SSL, the only asymmetric key that gets used is the server's key (except, as mentioned, in that 0.000001% of cases where client certs are in use -- requiring installation no user will do 'accidentally'). The symmetric keys are completely random, and unique to each session. In fact, there was a very, very early flaw in Netscape (~1.0 or 1.1) where the keys weren't random enough; it's been long since fixed.

There is no way people can track you via SSL. At least, not by exploiting any SSL-level mechanism. Web bugs and so forth are made neither more nor less secure over SSL.

Re: proxying, all proxies just plain step aside entirely for SSL traffic. I worked at a company that needed to tunnel over HTTP, which is a huge pain in the ass for asynchronous, bidirectional data like we had; we eventually just embedded ourselves in SSL. The proxy method for SSL simply builds you a totally transparent tunnel between you and the HTTPS server; you can then pass anything you want. Only one of the many proxies we tested even validated that it was SSL traffic -- you could talk SMTP, IM protocols, or anything else if you wanted. Of course, it has to be this way, because the proxy doesn't have the server's cert -- that's the whole point of SSL (to prevent man-in-the-middle attacks). I suppose some proxies might let you add their own cert to your browser's list of CAs, then do the necessary faking in the middle, but none of the ones we tried did.

It really makes 'protection through proxies' something of a joke.

Midlands
Tuesday, June 29, 2004

*  Recent Topics

*  Fog Creek Home