topic Ken, I may have found the in Web Security

Adobe Creative Cloud application installs fail when going through our Ironport web content filters

Stafford Rau — Fri, 12 Sep 2014 00:36:15 GMT

As the title says, when our users try to install Adobe applications via the new (and execrable) Creative Cloud software subscription service, those installs and updates fail when going through our Ironports with a lovely "download appears corrupted" message.

We're using WCCP on our core routers to redirect web traffic through the S370 proxies. When I exempt those users from web redirection (via the access list that controls wccp on those routers), the installs work correctly.

One of the frustrating parts of this problem is that none of the requests appear to be blocked. If I can trust the Creative Cloud app's progress bar, the application is completely downloaded and just starts to be extracted when the error occurs.

I did a packet capture on a client when the installation failed, but I didn't find anything particularly enlightening there.

Any suggestions would be most welcome.

Hi,Could you please share the

Luis Silva Benavides — Mon, 15 Sep 2014 23:35:32 GMT

Hi,

Could you please share the access logs:

1. Grep
2. Enter the number of the log you wish to grep: 1 (for accesslogs)
3. Enter the regular expression to grep: <client IP>
4. Do you want this search to be case insensitive?: Y
5. Do you want to search for non-matching lines? N
6. Do you want to tail this log?: Y
7. Do you want to paginate the output?: N

Regards,

Luis Silva

We had the same issue. This

Matt Bowman — Tue, 23 Sep 2014 18:25:41 GMT

We had the same issue. This is what I did as a work around for the Identities that needed Adobe Creative Cloud:

Create a Custom URL Category
Add .adobe.com to it Sites section
Submit

Assign the Custom URL Category to your Access Policy and Decryption Policy
(we have it set to monitor)
Submit, Commit, Commit

Test

I hope this helps,
-MB

The access logs show all

Dominick Converse — Tue, 07 Apr 2015 20:54:59 GMT

The access logs show all communication as being open, no blocks or failures. The Creative Cloud manager connects and starts the updates but fails in the middle of a file download. Adobe states it is a proxy issue but there is nothing in the logs to reflect that assumption. The Creative Cloud logs state a communication failure has occurred. A network trace does not show any failures, the issue is within the manager software from what we have been able to figure out. The software updates work when they are completed manually without the Creative Cloud Manager using the same proxy appliances.

Dominick Converse

Hi,Adobe is using a range

Handy Putra — Thu, 09 Apr 2015 22:48:20 GMT

Hi,

Adobe is using a range request download method for its download and by default this method has been disabled in WSA due to security purpose.

You can enable this option from the CLI of WSA by issuing command rangerequestdownload and enable this.

Please note that this option is a global setting therefore it will effect the appliance globally and also if you enable this setting there might be some security risks where when WSA is getting the files in chunks instead of full size of file (the behaviour of range request download protocol), WSA scanning engine might not be able to perform scanning on them due to small size of files (due to per chunks)

Another way to get around this is to create custom URL category for the whole domains and subdomains of adobe: ".adobe.com" and set it to "Allow" instead of "Monitor".

By setting to "Allow" this will bypass the scanning all together and simply allowing the traffics, therefore WSA will not inspect the range request download protocol/method that adobe is using.

I have multiple users with

Dominick Converse — Mon, 11 May 2015 15:32:09 GMT

I have multiple users with the same issue, we are not decrypting the traffic and do not require user based authentication for any of the domains that are required. This has been confirmed by Adobe. Their tech support is totally clueless as to what the issue is and has been unable to assist. Has anyone found a workaround for the updates/ downloads?

Thanks

Dominick

Adobe download is using range

Handy Putra — Mon, 11 May 2015 23:22:03 GMT

Adobe download is using range request download method that by default is disabled in WSA globally due to security reason.

If you need to enable this (CLI -> rangerequestdownload) however when you enable this there could be security disadvantage since the scanning engine might not be able to scan correctly due to small sizes per chunks that been downloaded (this will apply globally).

The other workaround is to create custom url category for adobe (.adobe.com) and set it to "Allow"

By setting to "Allow" this will bypass the scanning all together and simply allowing the traffics, therefore WSA will not inspect the range request download protocol/method that adobe is using (this will only apply to adobe not globally).

what scanning are we

Dominick Converse — Tue, 12 May 2015 14:24:55 GMT

what scanning are we bypassing? The only scanning that I do on the WSA is WBRS, there is no malware or AV scanning on the WSA.

What security concerns would enabling rangerequestdownload expose?

With range requests enabled

Ken Stieers — Tue, 12 May 2015 14:39:00 GMT

With range requests enabled the WSA never has the whole file all at once so AV/malware scanning may miss things. If you're not using that you don't lose anything.

Thanks Ken and Handy, let me

Dominick Converse — Tue, 12 May 2015 14:47:07 GMT

Thanks Ken and Handy, let me give this a try and I will let you know.

I still have the same

Dominick Converse — Tue, 12 May 2015 16:05:45 GMT

I still have the same failures, updates get to 30-34% and then fail. Back to the drawing board.

At this point I'd open a TAC

Ken Stieers — Tue, 12 May 2015 16:40:17 GMT

At this point I'd open a TAC case. They will want a packet capture so they can see what's really happening...

Ken, I may have found the

Dominick Converse — Fri, 22 May 2015 15:22:46 GMT

Ken, I may have found the answer to this issue I am waiting for Adobe to verify. It seems that the software attempts to make an inbound connection(s) to validate downloads and licensing. Adobe expects you to have a rule that allows inbound TCP port 80 & 443 from the internet for this to work be completed. We I requested a list of their ip's or subnets that may do this I was given a listing of 38 domestic subnets including full class 'B' networks. This would explain why the updates work when not behind the WSA and firewall on a home network.

Dominick

I'm sure there's some

Ken Stieers — Fri, 22 May 2015 15:45:20 GMT

I'm sure there's some confusion there, because no one in their right mind would open that up like that...

I totally agree, 2 different

Dominick Converse — Fri, 22 May 2015 20:31:59 GMT

I totally agree, 2 different support personnel at Adobe have given me a similar response. So I requested my ticket be escalated for the issue. That was 2 days ago. We took a sniffer trace between the workstation and the WSA and the WSA and the internet and find nothing wrong. We may need to do another trace at the firewall to see if we find an inbound attempt being dropped.

Ken,Adobe confirmed that they

Dominick Converse — Thu, 28 May 2015 21:05:06 GMT

Ken,

Adobe confirmed that they require inbound access over port 80/443 for validation and verification during upgrades as stated in the below in the response:

"Our Applications require inbound connection if your Proxy network allows it without any issues and blockage for ports 80&443"

The only suggestion they made it to create an update server and let your user connect to the update server, but this server would also require the same connectivity.

Just wanted to let you know.

Thanks

Dominick