I strongly agree, *if at all possible*. What I'm saying is that HSTS can break so much, even after you revert everything you've changed, that we should make sure users have a rough idea of determining when it is possible. Please deploy HSTS everywhere, but only after you've thought through what you're actually affecting and for how long.
We can be much more brief in recommendations regarding X-Frame-Options or the secure flag on cookies, because even in if it breaks everything, you can just revert back and everything will work again. And you'll only break the site you're working on. On 01 Sep 2014, at 18:34, Donald Stufft <[email protected]> wrote: > 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, 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. Upon discovering the error it can be corrected, but not before >> a unknown set of users has memorized that all of 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]> wrote: >> >>> After I wrote the original email, I found #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). 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]> wrote: >>> Hi Tim, >>> >>> On Thu, Aug 28, 2014 at 3:35 AM, Tim Graham <[email protected]> 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 >>> >>> 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]. >>> 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/CAJxq84_Tq1Fnm_pG4pMSy98DOLsnLtVp9jEgTo6X8%2BH%2BJYi1dQ%40mail.gmail.com. >>> >>> For more options, visit 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]. >>> 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/2d66a232-1f19-4bcc-8178-7e1e060f497b%40googlegroups.com. >>> For more options, visit 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]. >> 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/2316E343-8EEF-40B3-B043-CA64FA555382%40solidlinks.nl. >> For more options, visit 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. -- 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/56EA7C02-BE51-41B7-91D3-C61B55965E9A%40solidlinks.nl. For more options, visit https://groups.google.com/d/optout.
