Eh, I think we should advise people to switch on HSTS and with includeSubdomains if at all possible.
> On Sep 1, 2014, at 1:31 PM, Erik Romijn <[email protected]> wrote: > > Hi all, > > I think finally integrating django-secure is a great step. Making a separate > deploy check also makes sense to me. However, I think we should be very > cautious with pushing people to enable HSTS. > > Some of our security headers can cause things to break. For example > redirecting to SSL when your HTTPS is broken, will break your site. Enabling > strict X-Frame-Options when you do use external iframes, will break your > site. However, if you then fix the setting, everything will work again. > Inconvenient, but easy to recover. Also, these effects are limited to the > Django site you are working on. > > If I were hosting a Django site on example.com <http://example.com/>, and > enable HSTS with includeSubdomains and a lifetime of 6 months, as seems to be > common now, I might not only break my own site, but also every other side > under example.com <http://example.com/>. Upon discovering the error it can be > corrected, but not before a unknown set of users has memorized that all of > example.com <http://example.com/> and any site under it must use HTTPS. > > So, although I encourage anyone to enable HSTS, we should not recommend > people to just "switch it on". They should be well aware of the consequences > as it can affect an unknown set of users beyond their Django site, long after > the change has been reverted. The possible seriousness should be reflected in > any encouragement we make for HSTS to be enabled. > > Erik > > > On 28 Aug 2014, at 02:25, Tim Graham <[email protected] > <mailto:[email protected]>> wrote: > >> After I wrote the original email, I found #17101 >> <https://code.djangoproject.com/ticket/17101> which is where the checkdeploy >> idea came from. We can just close that ticket (or modify it) if we decide on >> a different solution. It was created before the checks framework was merged >> and I agree a separate command may not be ideal, although it may make the >> implementation slightly easier. I'll look into using DEBUG tomorrow. One >> issue is that we don't want these checks run during testing (and DEBUG is >> often False there). Maybe if these checks are registered with something like >> checks.register(foo, deploy=True), we can skip any checks registered like >> that during testing. I'll have to see if there's some way to make this work >> with 'manage.py test' as well as with 3rd party test runners. If we had a >> separate checkdeploy command, avoiding this problem might be somewhat easier. >> >> I am fine with putting it in core instead of contrib. That just means we >> need to figure out what to do about settings since we cannot put them on an >> AppConfig. Assuming we don't want to add them as normal settings, we may be >> able to use the approach proposed on this mailing list for the CSRF settings >> -- using attributes on the middleware class (PR >> <https://github.com/django/django/pull/1995>). In that case, the check could >> work by iterating through MIIDDLEWARE_CLASSES until it finds a subclass of >> SecurityMiddleware and then check the attributes (settings) on that class. I >> will look into this approach tomorrow. >> >> Thanks for the feedback! >> >> On Wednesday, August 27, 2014 8:47:26 PM UTC-4, Curtis Maloney wrote: >> For what it's worth, I agree with Russ. >> >> Having security as an optional extra [which is how it will look to >> outsiders] is a bad look for Django, and certainly doesn't fit with the >> "Secure by default" philosophy. >> >> -- >> Curtis >> >> >> On 28 August 2014 10:34, Russell Keith-Magee <[email protected] >> <javascript:>> wrote: >> Hi Tim, >> >> On Thu, Aug 28, 2014 at 3:35 AM, Tim Graham <[email protected] >> <javascript:>> wrote: >> I've started tackling one of the ideas that's been on our GSoC ideas >> page for a couple years now: integrating django-secure. I chatted with >> Carl about the idea and he's onboard. There are a couple of design >> decisions we'll need to make. >> >> +1 to the idea. It was part of Chris' original proposal; we just didn't get >> around to it with the available time. >> >> 1. How to integrate django-secure with the checks framework >> django-secure essentially implements its own checks framework (which >> predates the one in Django). The tricky part is that django-secure's >> checks are not ones that generally should pass on a >> development instance; they're checks that only make sense to run on a >> production server (or at least against a production settings file). >> I'm thinking to have some way to skip these new checks by default and >> run them only when requested (e.g. manage.py check secure >> --settings=prod_settings). Other options include an entirely separate >> command like django-secure implements (curently called checksecure), >> but perhaps could be called checkdeploy and eventually extended with >> other checks that are relevant only in production. Idea/insight from >> those more familiar with the checks framework (Chris, Russ), would be >> welcome. >> >> Generally, I'd be opposed to the idea of Yet Another Command to run checks - >> if you make it optional, it won't get run, and this is something we want to >> be forced in front of everyone. >> >> We use DEBUG as a proxy for "In Production" in other locations in the >> codebase - e.g., whether ALLOWED_HOSTS checks are run. If we were to >> supplement that with a --production=true/false flag to the checks command >> (to override the rare legitimate occasions where DEBUG=True in production, >> or DEBUG=False in development), wouldn't that meet all the needs here? >> >> 2. How to add settings for django-secure >> As discussed in the thread below, I'm going to explore developing an >> API for storing settings on an AppConfig to avoid adding more global >> settings. >> https://groups.google.com/d/topic/django-developers/qnnCLppwA3o/discussion >> <https://groups.google.com/d/topic/django-developers/qnnCLppwA3o/discussion> >> >> I have imported django-secure into django.contrib.secure and started >> work on integrating it with the built-in checks framework as well as >> removing some bits of it that have since been added to Django >> (frame-deny, SSL-proxy support). >> >> Is it appropriate for this to be a contrib package? That implies it needs to >> be added to INSTALLED_APPS; I'm not convinced that this is a desirable >> approach. >> >> If django-secure is important enough to include as part of Django's codebase >> (and I fully agree it is), I'd consider security to be part of core, not >> something you can opt out of. Including it as django.core.checks.security >> (or similar) would make more sense to me. >> >> Russ %-) >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at http://groups.google.com/group/django-developers >> <http://groups.google.com/group/django-developers>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/CAJxq84_Tq1Fnm_pG4pMSy98DOLsnLtVp9jEgTo6X8%2BH%2BJYi1dQ%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/django-developers/CAJxq84_Tq1Fnm_pG4pMSy98DOLsnLtVp9jEgTo6X8%2BH%2BJYi1dQ%40mail.gmail.com?utm_medium=email&utm_source=footer>. >> >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] >> <mailto:[email protected]>. >> To post to this group, send email to [email protected] >> <mailto:[email protected]>. >> Visit this group at http://groups.google.com/group/django-developers >> <http://groups.google.com/group/django-developers>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/2d66a232-1f19-4bcc-8178-7e1e060f497b%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/2d66a232-1f19-4bcc-8178-7e1e060f497b%40googlegroups.com?utm_medium=email&utm_source=footer>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at http://groups.google.com/group/django-developers > <http://groups.google.com/group/django-developers>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/2316E343-8EEF-40B3-B043-CA64FA555382%40solidlinks.nl > > <https://groups.google.com/d/msgid/django-developers/2316E343-8EEF-40B3-B043-CA64FA555382%40solidlinks.nl?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6E64C365-8959-40F3-95F2-FDB4C86F7158%40stufft.io. For more options, visit https://groups.google.com/d/optout.
