Issue #251: Secure flag not set on cookie.
| Reported by: | Chris Wesseling |
| State: | closed |
| Created on: | 2016-11-08 15:40 |
| Updated on: | 2016-11-10 13:15 |
Description
I'm running 0.3.2 with apache in front of it to provide TLS. I set these headers on the request to make clear to kallithea that it is being accessed securely:
RequestHeader set X-FORWARDED-PROTOCOL https
RequestHeader set X-FORWARDED-SSL on
RequestHeader set X-URL-SCHEME https
And I even tried the advised (even though I don't understand how setting something in the apache env can have consequences on a backend that is only communicated with through http):
SetEnvIf X-Url-Scheme https HTTPS=1
But the kallithea-cookie doesn't have the secure flag set (just the httponly flag):
Set-Cookie:kallithea=bf7e93[...cut...]db8ce7d9; httponly; Path=/
Is there something in the kallithea config that I should set?
Attachments
Comments
Comment by Mads Kiilerich, on 2016-11-08 16:00
That should happen automatically if you are running Kallithea in a proper WSGI server that sets wsgi.url_scheme correctly.
If you have a funky setup where you have a standalone WSGI server that runs http but has to pretend that it is running https, then you have to tell it that. It may or may not trust the http headers, depending on which wsgi server and configuration you use.
Have you read http://kallithea.readthedocs.io/en/0.3.1/overview.html#web-server and http://kallithea.readthedocs.io/en/0.3.1/setup.html#https-support ?
Comment by Chris Wesseling, on 2016-11-08 16:29
I'm using the default waitress with Apache as a reverse proxy for the ssl.
Tried setting beaker.session.secure, but, like you say, that gets overwritten by whatever the waitress reports.
I've changed the headers to include X-FORWARDED-PROTO https, like the waitress docs say. Now I'm looking for a way to put the IP of my proxy to waitreses trusted_proxy. Whatever that means...
Comment by Chris Wesseling, on 2016-11-08 16:35
https_fixup = true fixed it. Thanks for the pointer.
Should I create a patch that adds this option to the generated .ini with a description? The other https options were generated, but didn't fit my situation.
Comment by Andrej Shadura, on 2016-11-08 17:15
In a correct setup, https_fixup should not be needed, it’s needed to provide the missing environment bits in setups when they can’t be normally set for some reason.
Comment by Chris Wesseling, on 2016-11-08 17:48
In a setup where the wsgi server and the reverse proxy are on different boxes, is it incorrect to use X-Forwarded- headers to communicate? (At least until RFC7239 becomes an Internet Standard)
I found this little flag kind of obscure, as all major things that should know about https being used, like clone url creation, worked as expected without the https_fixup.
Comment by Mads Kiilerich, on 2016-11-09 17:41
I don't know rfc7239, but I consider it essential that any web server explicitly is told if it has a trusted proxy in front and thus can trust these headers. It would be a security issue if a web server exposed to untrusted users trusted these headers. It must thus be off by default.
If the setup has a chain of web servers then it makes sense that they use something like rfc7239 headers. That is kind of what various web/wsgi servers do - it is just not standardized.
I find it essential for having a maintainable stack that it is handled at the web server / wsgi server level. The https_fixup hacks in Kallithea are just layering violating hacks.
From looking at documentation and source of waitress, it seems like it should be possible to add a 'trusted_proxy = 10.0.0.1' (IP of your proxy) line in the kallithea .ini file that waitress also is reading. But note: despite the nice words in their own documentation, waitress really seems to have a very limited feature set. It has some support for X_FORWARDED_PROTO but no support for forwarding other important information. I thus don't recommend using it in production - and I don't understand why people keep trying to do it.
It would be great if we could get better documentation of how to configure the various web/wsgi servers to forward and trust this information (with or without being rfc7239 compliant). I think that would be great to get added to the .ini templates. I am more reluctant to endorse use of the https_fixup hack.
It seems like you have a good understanding of the problem and the concerns. It would be great if you can review the various parts (documentation and .ini and perhaps code) and suggest patches to improve it.
Comment by Chris Wesseling, on 2016-11-10 12:41
ValueError: Unknown adjustment 'trusted_proxy'
I'll stick with https_fixup, for the time being and will prepare a transition to trusty gunicorn, or perhaps nginx and uwsgi. Thanks for all the help, people!
Maybe a documentation change steering newcomers away from the default sqlite and waitress for production would be nice.
Comment by Mads Kiilerich, on 2016-11-10 13:15
Weird. It seems like you are using an old waitress version that doesn't support trusted_proxy. Is it referenced in your .../site-packages/waitress/adjustments.py ?
I tried to not offend the fans of the python web servers, but tried to hint towards their limitations in http://kallithea.readthedocs.io/en/0.3.1/overview.html#web-server . It would be great if can help make it more clear and helpful ... while also keeping it fair and balanced.