search

fredokun / cl-jupyter

An enhanced interactive Shell for Common Lisp (based on the Jupyter protocol)
BSD 2-Clause "Simplified" License
199 stars 29 forks source link

[offer to help] encryption support #7

Closed Yurlungur closed 9 years ago

Yurlungur commented 9 years ago

Hi,

I notice encryption support is not yet supported. I'm very interested in making a webserver with cl-jupyter notebooks. So I'd be interested in adding this feature. However, I don't have much experience with the internals of jupyter. Can you point me to the resources I'd need to learn how to do this? In return, I'll submit a pull request with encryption support. :)

Thanks for your time.

mmaul commented 9 years ago

The webserving bit is done by Jupyter which already has HTTPS support to run in HTTPS mode:

Generate a Cert.

openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout mycert.pem -out mycert.pem

Start ipython passing the cert you just created

 ipython3 notebook --Session.key="b''" --certfile=mycert.pem
Yurlungur commented 9 years ago

But correct me if I'm wrong: if I'm using a multi-user system, say jupyterhub (which is my use-case), then I don't just want web encryption, right? I also want the communication between the notebook and the server encrypted?

And this is why --Session.key="b''" is not a good idea.

mmaul commented 9 years ago

Okay, I misunderstood your question. So ipython communicates with the kernel using ZMQ not a webserver. ipython does not support using ZMQ's encryption mechanisms

See https://ipython.org/ipython-doc/3/parallel/parallel_intro.html#security

Work arounds for this have been to use ssl tunnels with openSSH. Generally though comm with the kernel happens on the localloop back port or on the local net which is not too much of a big deal. Though even with SSL tunnels the traffic is still going to be in the clear till it enters the localloop back port the tunnel is listening and also when it exits the tunnel on the localloop back port on the server that is running the kernel (So it could then be sniffed by a privileged user with access to either server).

I guess a bigger security issue than encryption is fixing the message signing. Which is not working at the moment which is why we need to start ipython3 with --Session.key="b''". It seems that other non python kernel implementations have not had luck with this. But getting this fixed would be great.

See: http://stackoverflow.com/questions/16240747/sending-messages-from-other-languages-to-an-ipython-kernel

Yurlungur commented 9 years ago

Okay, I'll do some reading then. Thanks for the links and the explanation!

fredokun commented 9 years ago

Hi, sorry for my late answer. I am not an expert in security and I cannot go beyond Mike's explanations. I will implement message signing ASAP (I think with ironclad it's easy, but as always in practice there might be some surprises ...), but signing is not security anyways.

fredokun commented 9 years ago

FYI, I just pushed a support for message signing (only while sending, I do not check the received messages wrt. their signature...). Ipython seems to accept the signatures ... But quoting ironclad: "A MAC is useful where maintaining data integrity is required, but the secrecy of the data is not paramount".

Yurlungur commented 9 years ago

Thanks for your help! I just tried the updated version and it seems to work great! I actually didn't understand what the key signing was for until Mike helpfully provided those links. It seems it's not for secrecy but for maintaining trust between the kernel and the notebook user. (Source: http://jupyter-notebook.readthedocs.org/en/latest/security.html) It's definitely important for the multi-user system I'm trying to set up.

Thanks very much for implementing it! I'm very excited to have a multi-user lisp interface.