-
Notifications
You must be signed in to change notification settings - Fork 677
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ControlMessage: SOL_TLS control message falls back to ControlMessageOwned::Unknown #2064
Comments
@fasterthanlime Are you going to upstream the I was going to start PRing them, but since you've already done part of the effort maybe you want to do it. |
@Arnavion feel free to go ahead with your own PRs, I’d be delighted to have it but am having enough trouble landing that one PR as is 🙃 |
Okay, thanks. |
* Parse SOL_TLS control message, closes #2064 * Only Linux gets SOL_TLS I guess (this is wrong, BSDs have it too) * Use libc constants * Also parse SOL_TLS on Android * Decode TLS record types * Only have TlsGetRecordType enum variant on supported platforms * Remove android from target platforms ...since the corresponding libc constant isn't gated for Android. * Add changelog entry
Fixed by #2065 |
When enabling kTLS on a socket (which mostly involves setting up the SOL_TLS sockopt), that socket may receive some control messages like so:
The cmsg_level corresponds to
libc::SOL_TLS
, cmsg_type corresponds to TLS_GET_RECORD_TYPEI believe the additional data in the
Vec<u8>
corresponds to TLS message types: 22 is handshake, 23 is application data, see RFC 5246.This happens because, after the TLS 1.3 handshake, tickets can be sent by the server to the client (for resumption, see rustls 0.21's flag for that).
If you're doing userland TLS, your deframer handles those messages gracefully and either throws away or stores the tickets for further use. But with kTLS, they have to go somewhere, and.. if you've received a ticket and you do a
read()
on the socket, you get errno 5 (helpful, I know!). If you do arecvmsg()
you get one of these with the "bonus data" set to 22, which again, is the TLS 1.2/1.3 "handshake" type.I'm working on a PR that recognizes those message types, adding a variant to
ControlMessageOwned
. The diff is probably a handful of lines and y'all don't need to bother yourselves with those details anyway but since there's fuck-all documentation about kTLS offline I needed to put it down somewhere.The text was updated successfully, but these errors were encountered: