Dropbox - allow web app but block client?

[oaus]

Our IT department has decided to allow Dropbox, but only the web interface. Installed client traffic should still be blocked.

Since the only identified app in Palo Alto is dropbox, we cannot block that app.

Is there any suggestion on how can I do this? I've played around with SSL decryption but I get conflicting results.

[mikand]

I think your best option is to request an app enhancement from the Apps and Threats Research Center.

http://www.paloaltonetworks.com/researchcenter/tools/

From there you can click on Submit an app and provide details there.

If im not mistaken the dropbox client uses http/https on its own (basically acting like a webbrowser) which makes it hard to just limit it to a special tcp/udp port or for that matter combine the rule with web-browsing or such.

Perhaps if you could set this up along with URL filtering as a workaround (in case dropbox uses a special URL for the client compared to the webbrowser edition)?

Edit: There are a few URLs available in the source code at https://bitbucket.org/dkocher/dropbox-client-java/src/100b8c7d183b/src/main/java/com/dropbox/client but this version seems to be 2 years old so I dunno how how much differs from how dropbox works nowadays.

[oaus]

If im not mistaken the dropbox client uses http/https on its own (basically acting like a webbrowser) which makes it hard to just limit it to a special tcp/udp port or for that matter combine the rule with web-browsing or such.
Perhaps if you could set this up along with URL filtering as a workaround (in case dropbox uses a special URL for the client compared to the webbrowser edition)?
Edit: There are a few URLs available in the source code at https://bitbucket.org/dkocher/dropbox-client-java/src/100b8c7d183b/src/main/java/com/dropbox/client but this version seems to be 2 years old so I dunno how how much differs from how dropbox works nowadays.

According to this, *.dropbox.com is excluded from SSL decryption because it breaks the installed client's connection (because the client maintains its own list of trusted root CA).

Without SSL decryption, it's not possible to see the actual URL, all the firewall sees is the common name in the certificate, which is *.dropbox.com. This is how the firewall recognises the app as dropbox. In my URL filtering log, all the dropbox URL shows *.dropbox.com as expected.

To make things more confusing, this and this state we can control dropbox using Data Filtering Profiles. I was baffled - How do you apply data filtering if you can't see the content? I configured a simple data filtering rule and did some tests. These are the results:

	Action	Result	Implication / my interpretation
1	Browse to https://www.dropbox.com	SSL Decryption Opt-out Page shown	SSL decryption ENABLE
2	Accept SSL Decryption on Opt-out Page	Browser (Firefox1) gives invalid SSL warning	SSL decryption ENABLE
3	After websites loads, check the certificate details	Real certificate is in used. It’s issued by Thawte to   *.dropbox.com	SSL decryption DISABLE
4	Data Filtering – Upload using web browser	Upload failed – Data Filtering log shows block file name, and   indicates traffic was decrypted2.	SSL decryption IN USE
5	Data Filtering – Upload using dropbox client	Upload succeeded – Same file used in step 4 is uploaded without   error	SSL decryption DISABLE

Note 1 – IE and Chrome don’t give the warning as the certificate is signed by a trusted root domain controller certificate

Note 2 – See attached screen capture

As you can see, I get conflicting documentations and test results.

I have submitted a new application request form as you suggested, but I don't have high hopes on that.

Action

[mikand]

I find it odd that PAN would whitelist certain urls as the first document states - perhaps someone from PA could verify if this document is still valid?

I believe that any whitelisting such as this should be done by the admin of the unit for security reasons.

For example if I setup to decrypt EVERYTHING then I expect that EVERYTHING is being decrypted (and if one client fails such as with windowsupdate and I wish to allow it then I would add windowsupdate to the exclude list manually).

As long as the dropbox client maintains its own trusted CA list and use a CA which isnt allowed by the PAN then allowing "dropbox" would mean that you only allow the webbrowser version (and can perform datafiltering regarding what type of files are allowed, antiviruscontrol and such). However this feels like far from 100% method to block the client itself (just look at the javaclient I linked to earlier).

I believe that best option is still that PA develops two different applications for this (if possible) such as:

dropbox

- dropbox-webbrowser

- dropbox-client

Regarding your termination tests, how is your termination certificate setup in your PAN unit? Since there are flags if unsuccesful termination should be allowed or not (along with which cert to use for that case - the effect can be one cert when termination works and another cert where it fails, if you then in your browser placed the second cert as blocked the client would get a warning and decide on its own if it like to continue or not (for example if the cert at the webserver have expired or such)).

[oaus]

I agree the best option is to have different applications, but without decryption it's not possible. Even if decryption is enabled, the actual http traffic might be identical between web app and client

The conflicting documentations and test results are really making this very confusing. It seems like the white list is enforced most but not all of the time, so upload traffic using web app can be decrypted and scanned.

Regarding my setup:

1. Decryption Policy - It's configured to "Block sessions that cannot be decrypted", but nothing is blocked even though the browser session to dropbox.com is not decrypted.

2. Certificates - Currently the same cert is used for Forward Trust Certificate and Forward Untrust Certificate, and I understand the difference, but I just don't think it's relevant for the purpose of my test since the certificate is not used at all. The actual certificate issued by Thawte is presented when I checked. Just for comparison, I did the same test for Facebook, and I can see my cert being used.

At this moment our aim is just to block the official dropbox client, I didn't even know other client exists until I saw the java client. I know there is a portable version called DropboxPortableAHK, but it's just a wrapper for the official client that makes it portable.

If only PAN will remove *.dropbox.com from the whitelist, or just get rid of the white list all together, or at least allow admin of the unit to modify it!

[SRA]

The Dropbox Common Name *.dropbox.com is in the exclude list for SSL decryption, so its traffic will not be decrypted. This was done to allow the client to function when decryption is enabled, since it does not accept .

Data filtering and File blocking profiles are possible on traffic from the web applicationwhen using decryption. To allow this to happen, we plan to remove the dropbox CN from the exclude list for SSL decryption. You can add it back to the SSL exclude list manually if you want using this CLI command:#  set shared ssl-decrypt ssl-exclude-cert "*.dropbox.com"

[essnet]

Great news savasarala ,

I have been fighting for ages with PA about that.

Regards

[oaus]

savasarala wrote:
The Dropbox Common Name *.dropbox.com is in the exclude list for SSL decryption, so its traffic will not be decrypted. This was done to allow the client to function when decryption is enabled, since it does not accept .

Data filtering and File blocking profiles are possible on traffic from the web applicationwhen using decryption. To allow this to happen, we plan to remove the dropbox CN from the exclude list for SSL decryption. You can add it back to the SSL exclude list manually if you want using this CLI command:#  set shared ssl-decrypt ssl-exclude-cert "*.dropbox.com"

Any idea when dropbox CN will be removed from the exclude list for SSL decryption?

[SRA]

This change is targeted for Content Update version 308 due for release tomorrow 5/15.