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: 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:
anonymous added on 2011-01-18 18:17:33 UTC: # /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 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: dmitry added on 2011-01-18 18:58:47 UTC: drh added on 2011-01-18 19:02:17 UTC: |