The kernel connection multiplexer [LWN.net]

The kernel connection multiplexer

Posted Sep 22, 2015 20:40 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
In reply to: The kernel connection multiplexer by smckay
Parent article: The kernel connection multiplexer

Certainly, handling TLS setup in userspace is OK, but after connection is established and keys are negotiated it'd be nice to delegate decryption to the kernel.

to post comments

The kernel connection multiplexer

Posted Sep 22, 2015 20:49 UTC (Tue) by smckay (guest, #103253) [Link] (6 responses)

Yeah, I can see that, especially to keep key material out of userspace.

The kernel connection multiplexer

Posted Sep 22, 2015 21:14 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

Also, what I'd like to see is an ability to send TLS sockets between processes. So this way Apache can delegate SSL connection negotiation to a separate process that has access to private keys and once it's done, just send the socket to the actual web-server process.

Can be done in userspace, but no existing TLS library can serialize its internal state for inter-process transmission (bad OpenSSL, bad).

The kernel connection multiplexer

Posted Sep 24, 2015 19:24 UTC (Thu) by luto (subscriber, #39314) [Link] (4 responses)

Will this really outperform a well-written epoll-based userspace SSL terminator that passes ends of socketpairs around?

Also, TLS supports things like renegotiation, so it's not as simple as "create a connection, set up session keys, and you're done".

The kernel connection multiplexer

Posted Sep 24, 2015 20:35 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

> Will this really outperform a well-written epoll-based userspace SSL terminator that passes ends of socketpairs around?
Absolutely. "SSL Terminator" is about the worst pattern for high-performance services. You have _multiple_ kernel switches with lots of TLB thrashing for each packet as a result.

> Also, TLS supports things like renegotiation, so it's not as simple as "create a connection, set up session keys, and you're done".
They are optional (and should not be used, anyway). Just terminate the connection in this case.

Also, having a dedicated userspace component is also a possibility - i.e. the kernel happily demuxes everything during the normal operation but punts requests back to userspace if anything is abnormal (like requests for renegotiation or PFS key renewal).

The kernel connection multiplexer

Posted Sep 25, 2015 9:49 UTC (Fri) by hkario (subscriber, #94864) [Link] (2 responses)

For long-lived sessions (remember, it has to be completely transparent), you need to do key renegotiation simply because you have transferred so much data (even petabytes with 10Gbps Ethernet isn't much) that you will start leaking keys.

The kernel connection multiplexer

Posted May 19, 2016 6:12 UTC (Thu) by wahern (subscriber, #37304) [Link] (1 responses)

I believe both libressl and BoringSSL have ripped out renegotiation. I'm not sure about their reasons beyond concern with the complexity of the implementing code, but IMO the safer course going forwarding is probably using a cipher mode with a longer period instead of relying on a complex, error prone protocol-level renegotiation. I'm unsure if there are any standardized cipher modes with a long-enough period (AES-GCM or ChaCha20-Poly1035?), but given the current state of TLS and TLS implementations, worrying about the ability to send such large streams is a good problem to have at the moment.

It also might be the case that TLS session resumption permits rekeying, and that might still be supported by libressl and BoringSSL. In that case applications could still do a little dance to rekey a session.

The kernel connection multiplexer

Posted Dec 20, 2024 5:09 UTC (Fri) by matthijs (guest, #128389) [Link]

Renegotiation was a source of security vulnerabilities. Nowadays it's typically disabled by implementations and TLS 1.3 entirely removed it as a feature.

The kernel connection multiplexer

Posted Sep 23, 2015 7:40 UTC (Wed) by lsl (subscriber, #86508) [Link]

Yep. Plan 9 does it that way with its TLS device. Pretty nice to be able to push TLS onto any file descriptor.