You are here
Hi guy's,
First of all a well deserved Well Done with TKL it saves me a lot of time is a great addition for us.
Well I have a problem since most clients only have 1 server and 1 public IP, we often use several VMs with TKL images and use 1 as a reverse proxy, and the proxy redirects internally to the correct VM. Like proxy -> VM1, www.domain.tld -> VM2, blog.domain.tld -> VM3 and so on.
This is all fine except when it cames to https. Maybe I'm a bit newbie here but didn't had much success redirecting https calls to be validated by the curresponding VM, is allways verified in the proxy first, so solution was to install the certificate in the proxy and redirect to the machine as normal http.
This works but with the apliances of magento and wordpress I need to go into each VM and deactivate manully https for the main App (magento or wordpress in this case), phpmyadmin, webmin and so on.
Suggestion: it would be nice if I could define in the installation process if I need SSL or not.
Or maybe there is another way to do this...
By the way I'm also using Nginx TKL apliance for the reverse proxy.
If there is a different and easier way to achieve the same results I'm open to suggestions.
Thanks for the feedback
Firstly I'm glad to hear that TurnKey is useful for you and making life a little easier...
It's an interesting problem. Historically the default HTTP/HTTPS settings configured/enforced by the particular app were left as-is. However in more recent times there has been a push for enforcing HTTPS where possible; which IMO generally makes sense with a web app.
Obviously in your scenario though, it becomes problematic. TBH I would imagine that your usage would probably not be the norm so making everyone select it on firstboot may not be ideal. However, it would definitely be nice for people in your position to be at least be able to use a consistent command/script/etc that could do the hard work for you (regardless of the appliance). As the upstream software doesn't do that consistently it would be a fair bit of work I would imagine.
There are also possibly edge cases for particular software that may be extra painful. For example I think of Moodle; it forces HTTPS for it's login page. It also defaults to HTTPS once logged it - you need to manually change the URL to use plain HTTP once logged in. I haven't spent a lot of time looking into it, but it doesn't appear to be configurable from any of the standard settings/options so I suspect that it is buried in the code somewhere.
Generally TurnKey tries to keep (at least custom TurnKey added stuff) consistent among appliances so how we could achieve this would require a fair amount of work. My (OTTOMH) thought would be a consistent inithook script which would accept a preseeded value (so people in your usage situation could set http) but if not set would provide a default of https (so all users wouldn't have to answer another question). This script would then read from a config file that was specific and relevant to the upstream software installed.
Unfortunately though, from my perspective it is all something of a moot point. The harsh reality is that we are currently struggling to keep up to the things that we think are really important (e.g. the v13.1 update release), let alone the 'nice to have' things... So whilst this is a nice idea, I'm not sure whether it is anything we could realistically ever get around to (unless someone such as yourself took a lead on it).
Off on a tangent and thinking about this problem further; another thing occurs to me... For some web apps, doing the reverse proxy the way you have, may actually cause issues in some circumstance. Some web apps receiving an http request (which was originally an https one to the reverse proxy) may assume that they are using an http connection and return http forwards and links. In some situations that may be quite a security risk. And the only way around that (that I know of) would be reverse proxy config to add a header hint and custom code on the webapp to check for the header (so the backend app knows that it was actually an https request that it received as http). That sort of upstream code customisation is well outside the scope of TurnKey.
The problem with all that is that reverse proxying https internally is problematic. I have never done it (I've only ever done what you are doing). And my suspicion is that there will be complaints about man-in-middle attacks somewhere along the line - after all the idea of https is that it achieves an encrypted connection directly between host and client. Putting a proxy in the middle breaks that... Maybe having a wildcard cert on the proxy and the full subdomain cert (assuming you're using subdomains) on the backend host might work but I'm not at all sure (just throwing idea around really...) Or maybe you could use multiple vhosts on your reverse proxy and have the same full cert on both the proxy and the backend host... But again I have no idea...
Finally, this is a great conversation as a request/suggestion (I forget which) for a reverse proxy appliance has been hangng around for quite some time. It seemed to be a toss up between Apache (which has a Webmin module - thus making config for those scared of the commandline easier); Nginx (which has no Webmin module and argualbly quite complex config - thus making newb friendly config tricky; but has the best performance...); and Pound (which has no Webmin module, but is fairly easy config). If you'd like to share your Nginx proxy config perhaps others would benefit from that (obviously sanitise it if need be).
Just thought I would comment.
Just thought I would comment. I too run multi website using a reverse proxy. My web-router is just TKLCore with Apache2 installed and Webmin updated. I use apache as the config with webmin was pretty simple.
My redmine server uses SSL inside and out, the trick for me was to use the same cert on the redmine server and the proxy and some apache settings. I also had to get a REAL SSL cert not a self signed or one from my own CA.
I am looking into replacing my web proxy it's build on v11 of the core and I want to get it updated. I like the idea of a Reverse Proxy App (basiclly Core with Apache and some appache mods) maybe I can work on that too in my spare time! I have already commited to the RT App, but this I think would be a pretty easy one to setup depending on how it would be configured.
Regards,
Ken
":0)
http://www.github.com/DocCyblade
Great! Thanks for your input :)
Brilliant to have some real world feedback / experience!
As for making an appliance, FWIW another TKL community member; John Carver made a start on a Reverse Proxy wiki/whiteboard page but the conclusion he came to was that Nginx was the best way to go (as I think I mentioned above). Having said that though, the wiki was last updated well over a year ago and I'm guessing (by this empty repo) that he didn't get far with development. So if you want to have a crack at it, then I think it is totally legitimate to use whatever you think is best.
I must admit that for a TKL appliance I definitely lean towards an Apache based appliance as the Webmin module makes it instantly more newb friendly (a significant factor in TurnKey). Anyway, I hope you don't mind but I took the liberty of adding you as a supporter to the Reverse Proxy entry on the listing of appliance candidates.
Thanks!
I did take a look the repo there was some code in the dev branch not sure how far he got however. And thats fine to add my name to it.. I may just fork the project or create a new one, currently working on the RT app and that may be my next one :-)
Well, I went ahead and created a new repo for myself to track my progress on my own proxy since I am doing that anyway now. It will be for my own doings but I'll share for anyone who cares to build it.
Regards,
Ken
":0)
http://www.github.com/DocCyblade
Nginx as reverse proxy gets my vote
With SPDY support built in Nginx gets my vote for a reverse proxy appliance...faster SSL.
Cheers,
Tim (Managing Director - OnePressTech)
Does the Nginx version from the repos come with SPDY?
I guess I could do the research myself but I'm busy/lazy ATM. I'm curious if you're aware whether Nginx from the Debian repos has SPDY builtin too or whether just upstream?
Only in Nginx versions installed in Wheezy backports+
The version of NGinx in the Debian Wheezy distribution does not contain SPDY module but the Nginx version included in Wheezy-backports does.
Cheers,
Tim (Managing Director - OnePressTech)
Thanks for the feedback
Lets see if I can post this time, last 3 times I tried was blocked... :(
this is my nginx config example as you've asked:
upstream backends {
least_conn;
server 192.168.1.1;
}
server {
listen 443 ssl;
server_name .domain.com;
ssl on;
ssl_certificate /var/ssl/certs/domain.crt;
ssl_certificate_key /var/ssl/keys/domain.key;
ssl_trusted_certificate /var/ssl/certs/domain-bundle.crt;
keepalive_timeout 70;
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 10m;
ssl_prefer_server_ciphers on;
#ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; #Disable SSLv3 because of Poodle Attack
ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS;
location / {
proxy_pass http://backends;
proxy_set_header Host $host;
proxy_redirect http://$host/ /;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Ssl-Offloaded "1";
proxy_hide_header X-Forwarded-Proto;
#proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Proto "https";
}
}
And sure in some cases we need to add a few things to the app it self. in Magento for example you need to add in the index.php before Mage::run():
if( isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] =="https" ) {
$_SERVER['HTTPS'] = 'on';
$_SERVER['SERVER_PORT'] = 443;
}
At any rate as I said before I'm not a sysadmin so in terms of system I don't know how much I can be of help, but either testing or developing (as long as is something I can actually do) I can help.
Add new comment