About a year ago Luke Plant wontfixed ticket #14597, which requested that Django add support setting for request.is_secure based on proxy-added headers (like X-Forwarded-Protocol) when Django is served by an HTTPS proxy [1].
Luke's reasons for closing were analogous to the SetRemoteAddrFromForwardedFor header [2], which Django removed because it was unreliable, really easy to get wrong, and a security issue when configured incorrectly. More recently, we changed the way we support the X-Forwarded-Host header for security reasons [3]. Support defaults to disabled, and users who need it can turn it back on. I bring these two examples up, because they are conflicting examples of how we might handle the SSL header issue. One complicating factor for the ssl header is that there are many (4 or so) ways of specifying the same meaning (that the proxy received the request on a secure connection). CarlJM's django-secure package [4] solves this problem by requiring the user to specify which header they want, if they need support for this. Luke's concerns about the security of this setting are extremely well founded. Enabling it when it is not needed is a very serious security problem, and negates many of the benefits of using SSL. In contrast, since Django doesn't support this configuration out of the box, we have users who are losing other benefits that SSL could provide when Django assumes all requests are insecure. The most striking example of this is our CSRF protection, where we enforce much more rigorous requirements on secured connections. In light of our handling of X-Forwarded-Host (which has known security issues), I propose that we reconsider support for X-Forwarded-Protocol (and relatives). The setting should require the user to find out which header their server is using, and configure it appropriately. This is enough of a barrier to entry that users won't simply set it to "on" without thinking. Additionally, if the conversation about including a django-secure style configuration check command comes to fruition, it gives us a chance to warn users again about the dangers of needlessly enabling the setting. -Paul [1] https://code.djangoproject.com/ticket/14597 [2] https://docs.djangoproject.com/en/dev/releases/1.1/#removed-setremoteaddrfromforwardedfor-middleware [3] https://www.djangoproject.com/weblog/2011/sep/09/security-releases-issued/ [4] https://github.com/carljm/django-secure -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
