function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

SSL Interception via proxy

One of the ways that we enforce security policy is that we perform ssl interception on all ssl traffic headed out of the network via our proxy servers.  SalesForce is really the first place we've hit a big snag in this operation - specifcally  Other salesforce tools we use function fine.  You can log in to chatter, but when you try to use the people or groups functionality, you get an error that says you've done something invalid for your session.  When we disable ssl-interception, it works again.  We've tried modifying the policy to ignore key things like invalid issuer, hostname mismatches, and expired certs - but no luck.  You have to complete disable ssl interception.  SalesForce won't provide support for this and directed me here.  Anyone else do SSL interception with salesforce, specifically Chatter?  Have you run into a similar issue?




I don't want to derail this thread, but I feel that its necessary to say that playing Man in the Middle with all of your user's SSL traffic is a a very bad security practice.


Now to your original question:


Your proxy is most likely configured incorrectly.  Chatter XML HTTP Requests (XHRs) require an anti-CSRF token that is passed in the HTTP Request Header of the AJAX call.  If you directly inspect the traffic, you will see a new Header value called "Authorization" that does not appear on standard or custom objects.  The value of this header is unique to each user and each user session.  Your proxy is either stripping this value or not correctly maintaining session state.


Steps to reproduce:

Take your network proxy out of the equation and just use a local proxy such as Paros or Burp.  Put the proxy in passive inspection mode and make a chatter post to a user or group.

On the POST request you should clearly see the Authorization: header in the HTTP request.

Now turn on active inspection/request trapping.  Make another chatter post to the same user or group, but tamper with the request.  You can either mangle the value of the Authorization header, or simply remove it.  You should receive a server error that says "The action you performed was invalid for your session. Please refresh your page and try again"


I'm not sure what kind of network proxy you are using, but you should be able to fix this issue by configuring it in such a way as to leave the Authorization header intact and making sure that it remains stateful with respect to unique user sessions.


Hope that helps!



Thanks for the suggestions, I'll take a look at the proxy config!  In reference to the man in the middle piece, certain categories are exempted as identified by the proxy appliance (things we don't want to see like healthcare, banking, etc).  Everything else gets intercepted and inspected.  Considering chatter is a "business" social network, there's a need to inspect the traffic for the data loss prevention solution to work.  Anyway, I'll post back if we get it solved.  Thanks again!


I understand the need for DLP, and there's more than one way to do it.  In my humble opinion, intercepting user's SSL traffic, even for "business use only" applications, completely breaks non-repudiation.  Anyone with access to the proxy had de-facto access to every user's password and session cookies.  This allows for user impersonation (without an auditable Login event in the case of session cookies.)  If users re-use passwords across multiple systems (extremely common), having access to Alice's password may allow access to her personal email, online banking, healthcare/benefits applications, etc.


Just my 2 cents.



You make a good point.  That's definitely something worth thinking about.