You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Session keys created by a TLS handshake are small and should be thrown out after a while (usually a certain number of payload bytes transferred within the session) to mitigate an attacker's ability to guess them.
The current handshake upcall does not support renegotiation. Instead, it treats a key reneg request as an error that is fatal to a session, then sets up a fresh session. This is typically not a significant problem because RPC connections/sessions are long-lived.
We would like the netlink upcall protocol and tlshd eventually to handle renegotiation. In this case, the upcall would pass a socket that already has a TLS session on it, and tlshd would redirect that to the library so that a reneg handshake can be done. The result should be that a fresh session key is plugged into the socket via setsockopt(3).
The text was updated successfully, but these errors were encountered:
Session keys created by a TLS handshake are small and should be thrown out after a while (usually a certain number of payload bytes transferred within the session) to mitigate an attacker's ability to guess them.
The current handshake upcall does not support renegotiation. Instead, it treats a key reneg request as an error that is fatal to a session, then sets up a fresh session. This is typically not a significant problem because RPC connections/sessions are long-lived.
We would like the netlink upcall protocol and tlshd eventually to handle renegotiation. In this case, the upcall would pass a socket that already has a TLS session on it, and tlshd would redirect that to the library so that a reneg handshake can be done. The result should be that a fresh session key is plugged into the socket via setsockopt(3).
The text was updated successfully, but these errors were encountered: