[Owncloud] apache reverse proxy with ssl offload not possible (possible security problem)

[Phillip Sengel]

Hello Owncloud List,

I am running my owncloud on a webserver inside a private network. It is 
hosted here solely via http (port 80). Clients on the internal network 
access it without ssl protection.

Another webserver is running on a host which is facing both the internet 
as well as the private network. This instance provides reverse proxy 
functionality into the internal owncloud installation for external 
clients. It is configured to communicate to the clients only via https 
(port 443).

Problem:
When I access owncloud from the internet via the OC login page or via a 
shared link which is password protected I will be redirected to http 
protocol.

Troubleshooting done so far:

Shared Link with password protection:
For the shared link it was quite easy to find out the reason: looking at 
the html source of the shared link authentication page I found out it 
has the full quallified URL in the form action like this:

<form 
action="http://cloud.external.com/public.php?service=files&t=79797979797979797979797979797979" 
method="post">

This cannot be dealt by the reverse proxy unless you implement html 
rewriting here.
Considering the common practice to set up a http vhost "silently" 
redirecting to https the password would be transmitted not ssl secured 
without the user noticing it. Maybe recent browsers will show a warning 
message that the form information will be transfered unprotected as my 
firefox did, but still I would concider this a security problem.

According to the owncloud documentation there are built in mechanisms to 
auto-detect hostname, protocol and webroot. But they can fail in some 
situations: 
http://doc.owncloud.org/server/5.0/admin_manual/configuration/configuration_reverseproxy.html

So I have tried to work around my problem by setting the "overwrite..." 
directives in config.php. But that will not work for my setup because it 
will rewrite the protocol also for the internal clients.

The root-cause is the fully qualified URL in the form of the shared link 
authentication page. As I have not seen fully quallified URLs in any 
other parts of the OC webpages I guess it is a "bug" which can be fixed 
easily.

Can anyone point me to the proper .php file inside OC where I can remove 
the host and protcol part for creating that form action URL?

Main Login Page:
Regarding the main login page of OC, where the same problem occurs 
(getting redirected to http) I was not able to find the cause. The html 
source of the login page does not show any fully quallified URL but 
still I get redirected to the http version after submitting the login 
credentials.
Once I manually change the URL to include the http's' again I will be 
logged in correctly. Any further usage of the OC webinterface after that 
will stay in the https context. So I suppose that it is not a 
fundamental problem of the OC code but the login is broken.

Maybe someone has better knowledge of the OC code (particularly the 
login related code) to identify the cause here?

Here are the basic technical facts:

Internal webserver:
- debian 6.0
-- apache 2.2
--- owncloud 5.0.5

Internal vhost file:
<VirtualHost *:80>
   DocumentRoot /var/www/owncloud
   ServerName cloud.private.net
   <Directory /var/www/owncloud/>
     Options Indexes FollowSymLinks MultiViews
     AllowOverride All
     Order allow,deny
     allow from all
   </Directory>
   ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
   <Directory "/usr/lib/cgi-bin">
     AllowOverride None
     Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
     Order allow,deny
     Allow from all
   </Directory>
</VirtualHost>

Reverse proxy:
- debian 6.0
-- apache 2.2
--- owncloud 5.0.5

Reverse proxy vhost file:
<VirtualHost *:443>
   ServerName cloud.external.com
   ProxyRequests Off
   ProxyPass / http://cloud.private.net/
   ProxyPassReverse / http://cloud.private.net/
   SSLProxyEngine On
   SSLEngine on
   SSLCertificateFile    /etc/ssl/certs/cert.pem
   SSLCertificateKeyFile /etc/ssl/private/key.pem
</VirtualHost>