Hello.

I am experiencing some problems with facebook apps or facebook for mobile sites. I have two servers: one for regular traffic and the other for facebook and youtube.

For some reason, traffic to facebook from mobiles apps doesn't pass through the facebook server... Read something somewhere that these apps use HTTPS for their communication.

How if possible, can I send ALL facebook (http and https) traffic to the other server or cache_peer?

Thanks in advanced for your time and help.

You can't cache SSL traffic on the client side proxy server. That would require a man in the middle attack where you negotiate SSL on both ends of the squid server (which is unethical and frowned upon).

Perfectly ethical and acceptable as long as the users of the squid server are aware of it and accept it as part of their conditions for being able to access the internet via that particular network. This is why we have a policy document on internet usage from our work wired and wireless network, as part of our conditions if anyone wants their work e-mail on their personal phone they also have to sign remote block / wipe waivers.

I would disagree if one is accessing any website requiring security over SSL. I don't have a personal phone but a work phone. I keep a personal phone for personal communication and work can do what they want to my work phone. However, many companies require a "BYOD" policy of which I probably wouldn't ever consider myself. Back to the topic at hand I would disagree about the SSL middle man policy because it would violate my personal privacy to websites which would matter (banking websites are just one example). SSL is a privacy guarantee stating that the website you're accessing is whom they claim to be verified by a trusted third party. I would not consider a caching proxy server a trusted third party for banking information nor any website attempting to complete a purchase where you enter personal credit information. I would consider the company open for liability claims if such a server were compromised (even if a user did sign a "waiver" if the security of the server is negligent not meeting certain standards). PCI being one of many standards since it will likely cache credit card information and who knows what else (facebook takes credit card information).

If a company decides that they are going to only target "certain" websites for SSL man in the middle attacks then it is easily bypassed by an SSL proxy. And if they block proxies it is bypassed by SSH tunneling and modifying the hosts file to point to localhost (for e.g. facebook). In my opinion, it would just lead to an arms race of bypassing by the end user (which I'm sure is grounds for termination upon bypassing). The point I'm making is man in the middle attacking SSL is both unethical and frowned upon. Mozilla has a discussion on this where they talk about implementing built-in fingerprint verification on popular websites so that they can warn the user when this "trusted" man in the middle is happening. Google is doing the same thing with Chrome. It breaks the very purpose and trust model of SSL. In fact, this is such a big problem that the IETF is drafting a specification for certificate pinning in browsers that will likely be implemented in the future.

Caching plain text is okay. Attempting to man in the middle and cache SSL is not okay and a liability suit waiting to happen. I would consider this a hostile company/work environment and wouldn't ever work for such a company. I'd probably then whistle-blow the company policy while I'm at it.

So use your own connection for your private comms.

Once you start talking about PCI it becomes a WHOLE different issue. There is an auditor school of thought that any SSL web usage from within a PCI compliant environment be put through an SSL proxy with DLP scanning to prevent the transmission of credit card numbers to end sites.