The channel layer could indeed use SECRET_KEY, since it's loaded in via a Django codepath in both the protocol server and the worker server.
It's better done as a channel layer feature rather than in Channels/Daphne directly, as then it requires no extra supporting code in anything else that does ASGI (like the WSGI adapter). The layer could also have options to turn it on only for certain channels (e.g. only http.request) - it would be harder to make deeper encryption choices, though, as things like the body content and headers both come through as a single message key. Maybe let people provide a regex to match against e.g. http.request and websocket.connect's `path` key. It's probably something we could pay for someone to work on for the "main" (Redis-backed) layer implementation? I could add it in too, but it's not as high priority as some other stuff I have to get to. Andrew On 21 Mar 2016 5:50 pm, "Josh Smeaton" <josh.smea...@gmail.com> wrote: > Assuming the frontend has access to DJANGO_SETTINGS_MODULE, couldn't it > use the SECRET_KEY to encrypt the message before passing it to the message > broker? On message receipt it could then use the SECRET_KEY to decrypt the > message. It'd be nice if encryption were an option encoded within the > message or route somehow, so it could be optionally turned on for sensitive > data. I'm guessing that there's probably an issue with my assumptions > though. > > On Tuesday, 22 March 2016 02:56:12 UTC+11, Andrew Godwin wrote: >> >> >> >> On Mon, Mar 21, 2016 at 12:11 PM, Sean Brant <brant...@gmail.com> wrote: >> >>> How does the new channels model handle requests with sensitive >>> information? Say you have a login view and the user is submitting a >>> username/password. Does the password get serialized into the message queue >>> as plain text? If so is that a security concern users should be aware of? >>> >>> >> With the default backend (redis), yes, it goes over the wire and into >> Redis as plain text - the overhead of both on-the-wire and at-rest >> encryption would be reasonably high, so I didn't include it by default; >> however, I very much hope we'll get at least one channel layer >> implementation that does do this. >> >> For Redis, at least, you can run a TLS tunnel between machines and point >> Channels at the local end of the tunnel to get transport security (as it >> has none of its own). At-rest is a bit harder - I plan to just turn my >> redis nodes into memory-only mode so that the data is never persisted, at >> least (channels doesn't need persistance beyond about a minute), but I can >> imagine a channel layer where you pass a symmetric encryption key in its >> configuration or similar. >> >> Andrew >> > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/3002448c-f36d-4f70-a2fd-c4d5e9bb2c34%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/3002448c-f36d-4f70-a2fd-c4d5e9bb2c34%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFwN1urDr0LWvgK%2BRx9maEPezoFxqyFXCzNQbHedJwwvJM9pgw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
