Run WDTK over https

[crowbot]

This seems like the simplest pre-requisite for moving WDTK to use super user accounts for admin authentication, which we'd probably want to resolve before getting too far into #73.

[Flupsy]

I'll use nginx to do SSL termination as a proof-of-concept for using it more widely.

[frabcus]

Glad this is finally being fixed!

Sorry I made it such a mess. We were being really skinflint about
buying SSL certificates.

On Tue, Oct 30, 2012 at 09:57:18AM -0700, Louise Crow wrote:

This seems like the simplest pre-requisite for moving WDTK to use super user accounts for admin authentication, which we'd probably want to resolve before getting too far into #73.

---

Reply to this email directly or view it on GitHub:
#684

[Flupsy]

cert issued

[Flupsy]

Installed and configured nginx as an SSL proxy on atlas, but some URIs returned by the site are absolute and thus still use http (see #692).

[mlandauer]

Related issue #71

[mlandauer]

There's a proof of concept up and running over at https://www.righttoknow.org.au

The lovely thing is that it hasn't required any code change to Alaveteli itself.

The next steps:

• Add the rack-ssl gem https://github.com/josh/rack-ssl to force redirect of http to https (Make this switchable in config/general.yml)
• Remove the proxying setup Remove proxying setup for admin interface #804
• Even though it isn't strictly necessary (ssl now should work fine without it) I still think it's a really good idea to do URIs on WDTK pages should be relative #692. I've done most of the work already and it cleans up a lot of confusing stuff in the code which is using absolute and relative urls in fairly arbitrary ways.

What's the setup for ssl for https://www.righttoknow.org.au?

We're using apache as the SSL terminator which is reverse proxying to varnish and varnish in turn is getting its requests from apache which is running passenger.

The bit of magic is the line in the Apache configuration below which sets the header X_FORWARDED_PROTO to https.

This ultimately tells Rails that the real requests are coming via https and so absolute urls should be served via https.

<VirtualHost *:443>
    ServerName www.righttoknow.org.au

    ProxyRequests       Off
    ProxyPreserveHost On
    ProxyPass           /       http://localhost:80/
    ProxyPassReverse    /       http://localhost:80/
    RequestHeader set X_FORWARDED_PROTO 'https'

    SSLEngine on
    SSLProtocol all -SSLv2
    SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM

    SSLCertificateFile /etc/apache2/ssl/ssl.crt
    SSLCertificateKeyFile /etc/apache2/ssl/ssl.key
    SSLCertificateChainFile /etc/apache2/ssl/sub.class2.server.ca.pem
    SSLCACertificateFile /etc/apache2/ssl/ca.pem
    SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
</VirtualHost>

[mlandauer]

One issue that's surfaced so far is with the blog section of the site. It pulls in content from an external blog which is most likely running over http. This means that the page ends with a mixture of http and https. In Firefox that just means that the url isn't displayed with the "lock" symbol. In Chrome that means it shows the "lock" symbol with a warning next to it.

I'm not sure how much of an issue this really is.

I can't think of a simple fix that would work. The only general solution I can think of is to proxy all the content. We have to do this because things like images in a blog can come from anywhere and we can't be certain that a simply http -> https rewrite will work.

Proxying the content seems like an awfully complex thing for very little benefit.

What do you think?

[mlandauer]

A couple of small things:

• The RequestHeader line in the apache config above should in fact read RequestHeader set X-Forwarded-Proto 'https' see 2e2fb24
• We also need to update the Varnish configuration to separately cache http and https requests. see 521122e

[dracos]

blog <-- easier perhaps just to run it at a separate HTTP blog subdomain?

[crowbot]

Closing this issue as https now enabled. Handling of blog ticketed at #880