View Ticket
Not logged in
Ticket UUID: 0ffa37e70e885cfc5c86d2546e51480c83b819b0
Title: There is currently no way to enforce 100% use of SSL
Status: Fixed Type: Feature_Request
Severity: Severe Priority:
Subsystem: Resolution: Fixed
Last Modified: 2011-01-18 19:02:17
Version Found In: d0753799e4
Description & Comments:
I'm noticing that there doesn't seem to be a configuration parameter or any reasonable way to enforce all communications to use SSL-secured HTTP in the Web interface.

My current hosting setup is as follows:

# /etc/xinetd.d/fossil-some-site 
service fossil-some-site
{
    socket_type = stream
    type = UNLISTED
    wait = no
    disable = no
    user = root
    server = /opt/fossil/bin/fossil
    server_args = http /opt/fossil/repositories/some.site/fossil --notfound http://fossil.some.site/cgi-bin/fossil-list-repositories.cgi
    bind = fossil-some-site.fossil01.internal
    port = 8060
}
# /etc/httpd/vhosts.d/includes/fossil.some.site.conf 
# Mostly standard Red Hat virtual host boilerplate elided.

ProxyPass /cgi-bin !
ProxyPass / http://fossil.some.site/
ProxyPassReverse /cgi-bin !
ProxyPassReverse / http://fossil.some.site/
# /etc/hosts
127.0.0.1 localhost.localdomain localhost fossil01.internal fossil01
127.0.0.101 fossil-some-site.fossil01.internal fossil.some.site
...

I haven't explored using the CGI method of deployment yet, nor have I explored the possibility of contributing patches to make this functionality a reality. I also haven't explored whether or not this functionality already exists in a newer release, seeing as I am running a relatively ancient version of Fossil:

fossil01% /opt/fossil/bin/fossil version
This is fossil version [d0753799e4] 2010-11-01 14:23:35 UTC

My current workaround is just to interact with the software through the shell on the remote end (to set configuration parameters, manage users, etc.) and through the usual fossil update, fossil sync, et al. commands from my working copy, wherever it might be at the time.

I would like to be able to use the Web interface running remotely however. :)


drh added on 2011-01-18 15:16:11 UTC:
See http://www.stunnel.org/ for a better solution.

service https
{
  port = 443
  socket_type = stream
  wait = no
  user = root
  server = /usr/bin/stunnel
  server_args = -l /opt/fossil -- fossil http /var/repo/some-site.fossil
}

dmitry added on 2011-01-18 16:00:06 UTC:
Will this work (untested)?


# /etc/httpd/vhosts.d/includes/fossil.some.site.conf 
# Mostly standard Red Hat virtual host boilerplate elided.

<VirtualHost *:80> ServerName fossil.some.site Redirect / https://fossil.some.site </VirtualHost>

<VirtualHost _default_:443> ServerName fossil.some.site # ... your proxy settings ... </VirtualHost>


anonymous added on 2011-01-18 18:17:33 UTC:
I'm thinking that I need to provide a bit more informative context. I'm inferring from your response that your assumption is that I don't have the SSL-enabled vhost set up. Alas, I do:

# /etc/httpd/vhosts.d/fossil.some.site-ssl.conf 
<VirtualHost 10.10.161.25:443>
	Include vhosts.d/includes/fossil.some.site.conf

	SSLEngine on
	SSLCertificateFile /var/www/domains/some.site/fossil/ssl/fossil.some.site.crt
	SSLCertificateKeyFile /var/www/domains/some.site/fossil/ssl/fossil.some.site.2048.key
	SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
</VirtualHost>
# /etc/httpd/vhosts.d/fossil.some.site.conf 
<VirtualHost 10.10.161.25:80>
	Include vhosts.d/includes/fossil.some.site.conf

        RewriteEngine On
        RewriteCond %{HTTPS} off [NC]
        RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [R=permanent,L]
</VirtualHost>

The relevant resulting HTML of, e.g., https://fossil.some.site/Fossil-Repository/wikinew is as follows:

<form method="post" action="http://fossil.some.site/Fossil-Repository/wikinew">
<p>Name of new wiki page:
<input style="width: 35;" type="text" name="name" value="" />
<input type="submit" value="Create" />
</p></form>

The issue is that, while Fossil traffic using the fossil tool is carried over SSL-secured HTTP just fine, the Web interface will revert back to insecure HTTP for communications in situations like these.


dmitry added on 2011-01-18 18:29:28 UTC:
I see, thanks for explanation (I forgot about the actual data sent to webserver, and thought redirects would handle this).

I think the fix for this would be to change "http://" everywhere in fossil's code which generates webpages to just "//", so that it prints them like this:

<form method="post" action="http://fossil.some.site/Fossil-Repository/wikinew">
<form method="post" action="//fossil.some.site/Fossil-Repository/wikinew">

This will use whatever protocol (http or https) this page were originally, and yes, this is in RFC, and supported by all browsers.

Even better, though harder, would be making all links relative.


anonymous added on 2011-01-18 18:36:56 UTC:
That's a pretty novel approach! Would you like me to implement these changes and test them, or would you like this honor? Either way works for me.


dmitry added on 2011-01-18 18:58:47 UTC:
I'm busy implementing symlink support, so do it :-)


drh added on 2011-01-18 19:02:17 UTC:
Please use the new --https and --host parameters to the "http" command to force the generated URLs to be whatever you want them to be.