I do think encrypting the Redis channel layer is something we should offer: Redis out of the box doesn't do transport-layer encryption, which is going to make Channels a hard sell to anyone with any for of regulatory/compliance requirements. [1]
I think probably Fernet [2] is the right way to do this -- since we've got a key we can share between Daphne and Django -- though I'd welcome the input of people who know more about crypto than me! Jacob [1] I do view it more as a compliance problem than a security one. You really shouldn't be routing things like channels over public networks, and if someone's snooping on your private network you've probably got bigger problems than unencrypted channels. Nonetheless, encryption-in-transit is a basic requirement of nearly every regulatory regime, and we should do what we can to help. [2] https://cryptography.io/en/latest/fernet/ On Mon, Mar 21, 2016 at 7:15 PM, Andrew Godwin <andrewgod...@gmail.com> wrote: > 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 > <https://groups.google.com/d/msgid/django-developers/CAFwN1urDr0LWvgK%2BRx9maEPezoFxqyFXCzNQbHedJwwvJM9pgw%40mail.gmail.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/CAK8PqJEMx6Mk4_O1cfYECxechKXMViNyLXXSoaK4eGRQjpEdxw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
