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. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
