On Fri, Jan 30, 2009 at 03:25:06AM +0000, Herbert Xu wrote: > Pierre Habouzit <madcoder@xxxxxxxxxx> wrote: > > > > My endgame is simple, I'd like to see an in-kernel SSL/TLS > > implementation in Linux happen. There are many reasons to want that, > > ranging from performance reasons (waking the userland each time you > > perform a handshake isn't particularly nice, and it's easy to make > > system-wide session caches) to really cool features being enabled: > > - you can send "secure" file descriptors around through Unix Sockets, > > or prepare a "secure" socket, let it be your stdin/stdout pair and > > exec a service knowing nothing about SSL (think inetd-like stuff) ; > > - you can deploy secure services where the actual server knows nothing > > about the certificate that is used ; > > - you can have a system-wide service dealing with peer certificate > > validations and have a real system-wide policy in this regard ; > > - you could even think of some netfilter stuff to enforce security on > > a given socket, even if the service behind the socket knows nothing > > about it (bye bye stunnel)... > > > > Nowadays, the kernel has most of what we need cipher-wise for TLS/SSL. > > Only the key-exchange protocols and the very TLS protocol are lacking. > > I'm currently addressing the former issue, namely, bringing RSA and > > Diffie-Hellman to the kernel. > > Stop right there. There is absolutely no reason why you need > to do the TLS stuff in kernel to achieve the goals you listed > above. > > What you should do is have user-space create the session, and > then give the keys to the kernel to do the data-path. Please > take a look at IPsec for an example of how the work is divided > between user-space and the kernel. So let me rephrase that to be sure we've understood each other. What you suggest is to have an IKE-like daemon dealing with the keys and all the handshakes, and that the kernel would only deal with the symmetric ciphers used on the data path. Is that right ? -- ·O· Pierre Habouzit ··O madcoder@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgpb6PIQPXJeO.pgp
Description: PGP signature
