Skip to content
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

Closed
fasterthanlime opened this issue Jun 29, 2023 · 4 comments

Comments

@fasterthanlime
Copy link
Contributor

fasterthanlime commented Jun 29, 2023

When enabling kTLS on a socket (which mostly involves setting up the SOL_TLS sockopt), that socket may receive some control messages like so:

  2023-06-29T11:56:33.154070Z TRACE ktls::ktls_stream: received UnknownCmsg(
    cmsghdr {
        cmsg_len: 17,
        cmsg_level: 282,
        cmsg_type: 2,
    },
    [
        23,
    ],
)

The cmsg_level corresponds to libc::SOL_TLS, cmsg_type corresponds to TLS_GET_RECORD_TYPE

I 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 a recvmsg() 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.

@Arnavion
Copy link
Contributor

Arnavion commented Nov 2, 2023

@fasterthanlime Are you going to upstream the setsockopt part of the kTLS setup to libc and nix too? I've been working on my own impl at https://github.com/arsing/ktls-test and have a bunch of extensions to libc and nix for it. There are some differences - eg I noticed hapsoc/ktls is doing it directly whereas mine integrates into the nix SetSockOpt mechanism - but parts like the definitions of the TlsCryptoInfo structs and constants are the same.

I was going to start PRing them, but since you've already done part of the effort maybe you want to do it.

@fasterthanlime
Copy link
Contributor Author

@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 🙃

@Arnavion
Copy link
Contributor

Arnavion commented Nov 3, 2023

Okay, thanks.

fasterthanlime added a commit to fasterthanlime/nix that referenced this issue Nov 5, 2023
github-merge-queue bot pushed a commit that referenced this issue Nov 10, 2023
* 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
@asomers
Copy link
Member

asomers commented Nov 11, 2023

Fixed by #2065

@asomers asomers closed this as completed Nov 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants