Webdav - Working in cleartext, not working in SSL

[slykens]

Hello all -

I have an Alfresco 4.2d system that I've been contemplating replacing our basic Sharepoint server with but am struggling in getting Webdav to work properly over SSL.

I have a network scanner (Visioneer Netscan 4000) and Cyberduck (OSX Webdav client) that I have tested with - they both connect and work properly via cleartext http (port 80), however, they fail when attempting to access Alfresco Webdav via SSL (port 443).

Because of the nature of the data we are working with it may not be transported in cleartext over the Internet therefore SSL is a requirement.

It is important to note that SSL *does* work properly for Alfresco and Alfresco Share when accessed from a web browser and for Webdav when access from a web browser such as Safari.

I've captured the failing conversation in Wireshark and it appears that the server responds to the Client Hello with an ACK then a RST/ACK, closing the connection before any kind of negotiation can occur. I have enabled debug logging for the Webdav module but the connection appears to be dropped before it even gets to that module.

I'm hoping someone here has an idea what the error or problem might be.

Thank you.

[philtee]

What URLs are you using to access webdav on 80 and 443.
Feel free to change the hostname and domain.

[slykens]

I am using:

http://alfresco.example.com/alfresco/webdav

https://alfresco.example.com/alfresco/webdav

I have spent some additional time this morning to verify it is not the SSL protocol configuration in Tomcat nor the JRE.

[eswbitto]

Try and see if the UNC works

Example:

\\alfresco.example.com@SSL\DavWWWRoot\alfresco

*edit*
We are using apache ssl connection rather than tomcat's from the binary install. Not sure how you have your SSL setup.

[slykens]

Windows does not appear to work - initially reports the server is no longer available then subsequently reports that a device attached to the system is not functioning.

I then tested from OSX using the Connect to Server function in Finder and it worked fine. (!) I verified via lsof that the connection is to the SSL port. I believe this is the first true webdav client connection I have been able to make using SSL. Cyberduck, another OSX webdav client, still faces the same issue as before.

I am using Tomcat's SSL functionality - I considered trying a change to Apache but wanted to be sure I couldn't get it working with Tomcat before going down that path.

I am going to spend some time with Wireshark analyzing the successful OSX Finder connection versus the unsuccessful Cyberduck connection.

Thank you.

[slykens]

At this point it appears to be related to the SSL negotiation with Tomcat and the client.

OSX Finder is willing to speak TLSv1 or SSLv3 to establish the connection and both work respectively if Tomcat is configured only to accept one or the other. Cyberduck appears to use SSLv2 initially and instead of trying to negotiate to SSLv3 or TLSv1 the connection is terminated by the server as it does not support SSLv2. I imagine (but have not confirmed) my network scanner is probably the same.

I imagine this might be solved by switching to Apache for the SSL side but I can't believe that this problem hasn't been solved already by others with a simple configuration option.

[slykens]

As I started to lead to in my last post, the problem lies with Tomcat/Java's lack of support of SSLv2Hello - this is because SSLv2 is not secure so no part of the protocol is supported, even if the requested transfer protocol is TLS or SSLv3 in the SSLv2Hello packet.

I am not going to detail the configuration steps here but will provide a high level overview - there is plenty of documentation on these subjects on the internet.

To resolve this I installed Apache 2.2 with mod_jk. If you have experience configuring Apache this is a pretty straight forward task - be sure to set the SSL side to pass the standard environment variables. I then configured Tomcat not to listen on 80/443 but to listen to port 8009 using AJP. I then configured mod_jk to point to port 8009 using AJP for the virtual hosts configured on port 80 and 443.

Finally I started Tomcat and verified it was only listening on 8009 (sudo netstat -apn) then started Apache.

Imagine my surprise when it all worked properly, including the SSL redirect on port 80.