WebDAV not working over SSL on CSS11503

Question

SOME HISTORY
As you may recall we had an issue with interoperability between our WebCT Vista application and the Cisco CSS11503 Load Balancer. In a nutshell the Load Balancer would inject custom HTTP headers into HTTP packets, but only into the first HTTP packet of a TCP session. With your help we've learned that Cisco will change this in the August release of the CSS software.
OUR NEW PROBLEM
We are now having a related problem. In short, we cannot get WebDav to work over SSL. That is, when connect from Client to Load Balancer via SSL, and then Load Balancer to Web Server via plaintext, our application fails. Conversely, when we maintain a clear text connection straight through from Client to Web sever WebDav works.
After doing some network traces of WebDav connections both with and without SSL I think we've discovered the cause of the problem: the Load Balancer fails to add our custom HTTP header "WL-Proxy-SSL: true" to HTTP "PROPFIND" requests, even though it correctly adds them to the HTTP "OPTIONS" requests.
HOW WE CONFIGURED THE LOAD BALANCER
We configured our Load Balancer with the Global configuration of
http-method parse RFC2518-methods
and with the command
ssl-server 20 http-header static "WL-Proxy-SSL: true"
so that the header "WL-Proxy-SSL: true" will be passed with the HTTP headers used for WebDav was well as with the 'standard' HTTP headers "GET, POST, HEAD", etc.
Below is the relevant passage from the "CSS Command Reference" at
http://www.cisco.com/univercd/cc/td/doc/product/webscale/css/css_750/cmdrefgd/cmdgloba.htm#wp1432749
======================================================================
"By default, a Layer 5 content rule supports the HTTP CONNECT, GET, HEAD, POST, and PUT methods. Unless configured, the CSS recognizes and forwards the following HTTP methods directly to the destination server in a transparent caching environment, but does not load balance them:
OPTIONS, TRACE, PROPFIND, PROPPATCH, MKCOL, MOVE, LOCK, UNLOCK, COPY, and DELETE.
When you enable the CSS to support all RFC-2518 methods, the CSS parses the Request-URI field in an attempt to match a Layer 5 rule. If the contents of the Request-URI field are not in a compliant format of an absolute URI or an absolute path, the CSS tries to match the field to the next best wildcard ("/*") rule. If the match fails, the CSS attempts to match the Layer 4 rule, and then the Layer 3 rule."
========================================================================
I interpret this to mean that when we configure "http-method parse RFC2518-methods" that the load balancer will treat all the HTTP headers in the group "OPTIONS, TRACE, PROPFIND, ...", etc the same as the "standard" HTTP headers "GET, POST, HEAD", etc.
As I said earlier our network traces show that the "WL-Proxy-SSL: true"
header present in the HTTP header OPTIONS but *not* in the header "PROPFIND".
A BUG IN THE CSS COMMAND PROCESSOR?
By my reckoning, this behaviour must be a bug in the CSS Command processor, because whatever the CSS does for the "OPTIONS" header it should also do for the "PROFIND" header.
ATTACHMENTS
I've included three attachments.
trace.txt
- text output from Ethereal of the network trace
on the web server, with comments.
webdav.ssl.snoop
- the original network trace in Sun's 'snoop' format.
css.2.cfg
- the running configuration on the CSS11503
Thanks in advance for your help.

Answer 1

Hi
I finally discovered what is the issue here. In appears that in case of unsigned applets, the code is unable to access SunJCE provider which contains most of the ciphers used by SSL protocol. This means that a session with SSL server is broken and effectively applet is not initialised.
This problem is related to configuration of JRE under linux due to export control restrictions. Unfortunately I don't know how to make JRE to use SunJCE by default.
As a workaround I have set up the following policies using Policy Manager:
grant {
permission java.security.SecurityPermission "putProviderProperty.SunJCE";
grant {
permission java.lang.RuntimePermission "getProtectionDomain";
grant {
permission java.lang.RuntimePermission "accessClassInPackage.sun.security.*";
I don't know how insecure my actions are, but this definitely fixed problems with applets under SSL / HTTPS.
Feel free to send me your ideas how to fix this issue in more elegant way.
Best,
Marcin