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
Making impl ClientHelloPayload public ? #1915
Comments
👋 Hi there,
Have you looked at using the If you look in the issue tracker I believe there have been previous discussions about exporting internal message types and this hasn't been something the project has been keen to support. In this case I'm not sure it's necessary at all given the |
Thanks for a quick response. I think our use case is slightly different. The main problem with using the Acceptor (I am actually using LazyConfigAcceptor ) is that we can't get back the consumed bytes. That's why I resolved to peeking bytes from TCP stream and then deserializing Having ClientHelloPayload public as building block is a great simplification since I don't have to do my own parsing. Being able to retrieve extensions would simplify it even further. |
@dawid-nowak have a look at rustls/tokio-rustls#54. |
I also just submitted #1916, maybe it could help? |
Super, i will need to dig deeper into it. My code looks pretty much as this snippet in rustls/tokio-rustls#54. We use something like below to figure out if the incoming stream is TCP/TLS. So really, we are using public APIs anyway. The missing bit is to be able to get the extensions cleanly without having to re-writing/hacking at stuff that rustls is doing anyway :)
I don't like the |
Perhaps we could also add an |
If I understand it correctly with |
Okay, I see how that doesn't work. So maybe we should move the |
That could work... Still think that making |
Why do you think it would be easier and less error prone? |
Sure :) just for the conversations sake
Yes, the application has a dependency on rustls low level building blocks which could change but at the same time it can trust that these blocks are sound. Additionally, the normal flow of rustls is not affected. There are no changes to the APIs so the existing applications will work as normal. That would be my thinking but I am happy to go with whichever way. |
These are not intended to be used by downstream applications and are not bound by semver constraints. |
I left a comment with a WIP branch on #1916 but I think it makes more sense to discuss here. Using the acceptor API and the fns on an accepted I think what's lacking is a way to accept a plaintext connection in some cases. To solve that, what if instead of exposing the deframer buffer and having the caller need to figure out if its TLS we do the reverse and have the acceptor return the buffer when it has already decided it isn't TLS as part of a returned error? I think that strikes a good balance. Existing TLS focused users can continue exactly as they do now, treating accept errors of any kind as fatal, sending an alert and closing. Users that want to dispatch non-TLS data can match on the new error type and unpack the data that Rustls couldn't deframe as the expected first TLS message. Does that seem workable? |
Your WIP branch makes sense to me, though I'm not sure I understand the need for |
My feeling on this is: it is very clear within the first few bytes whether the conversation is TLS or not. It seems quite reasonable to have downstream code that wants to do plaintext and TLS on the same stream port to read the bytes and do the demultiplexing up-front? |
Yup! That's a better idea, not sure why I didn't think of that initially. I will change it out.
I thought about this approach but it felt fairly unnatural. I'm not sure I understand what makes it simpler, except that it avoids adding a new variant to the
Yeah, that sounds like a good idea 👍
@ctz Sorry, I'm having trouble mapping your response to an indicator of support/dissent for the proposal I have in mind. Are you thinking the demultiplexing shouldn't be done in Rustls and we should continue to expect it to be done donwstream ala the approach used in rustls/tokio-rustls#54 (comment) ? |
Yeah that's the sort of thing I had in mind. |
wrong butan |
OK, I won't pursue turning the WIP branch into a PR in that case 👍 Should this issue be closed? |
I am happy to close this for time being. There seem to be two radically different approaches here and we can't get a consensus :
I think Option 2 makes sense if for example the basic blocks to parse ClientHello are available as a public API. That would save people from having to re-invent the logic here and since those blocks are part of rustls then there is trust that the logic is good. Option 1 is tightly integrated into rustls. Thing to consider here is that the new API would need to be exposed via higher level adapters such as tokio-rustls. |
From my read I think Option 3, the status quo, is where maintainer consensus is today. Solutions outside of the crate are possible without change here (as demonstrated in the tokio-rustls issue). I think the parts required to do it reliably are already exposed under the |
In our application we would like to make a decision based on contents of SNI in ClientHelloPayload without necessary affecting the how rustls flow. So we peek some bytes from the stream and initialize Reader and then use Reader to produce ClientHelloPayload. Everything works as expected and it is great that these two are part of the public API. Unfortunately, getting the SNI extension is not as straightforward since those APIs are not part of public API.
If would be also very helpful if other methods on ClientHelloPayload such as sni_extension, sni_extension, find_extension were added to public API. It seems that they were but now they visibility is only within the crate.
So the question really is if it makes sense to make
impl ClientHelloPublic
part of the public API from rustls perspective?The text was updated successfully, but these errors were encountered: