<div dir="ltr"><div><div><div>When you get back to this, probably the two most useful places for seeing how much existing tls code is required for ktls would be<br><br><a href="https://github.com/ktls/af_ktls-tool/blob/master/client.c">https://github.com/ktls/af_ktls-tool/blob/master/client.c</a><br><a href="https://github.com/ktls/af_ktls-tool/blob/master/xlibgnutls.c">https://github.com/ktls/af_ktls-tool/blob/master/xlibgnutls.c</a><br><br></div>The af_ktls-tool contains a bunch of testing noise, but also contains a test client. The test client (starting around client.c line 1096) calls the gnutls-based initiator (in xlibgnutls) then uses the ktls feature with the gnutls-initiated session info.<br><br></div>It really looks like using ktls will depend on a full openssl or gnutls library. Also, at the moment, ktls only implements one crypto suite (AES GCM), so a client using ktls can't interoperate with all webservers. (on the server side it matters less because the server-operator can choose only to use AES GCM, and all clients will have to support that).<br><br><br></div><div><div><div><div><br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 5, 2017 at 5:33 AM, Rob Landley <span dir="ltr"><<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 09/04/2017 08:22 PM, Robert Thompson wrote:<br>
> From the toybox point of view, wouldn't this introduce direct link<br>
> dependency on ssl/tls libraries?<br>
<br>
</span>There's already an optional dependency to accelerate hash calculations<br>
(CONFIG_TOYBOX_LIBCRYPTO), and another to accelerate zlib, so I'm ok<br>
with having that as an optional dependency.<br>
<br>
Having functionality you can _only_ get by linking that in is a much<br>
bigger ask. I want a self-contained system bootstrap build and/or<br>
hermetic build with minimal dependencies.<br>
<br>
So ideally I'd want the part of tls negotiation the kernel doesn't do<br>
implemented in toybox code, but I dunno how much that is yet...<br>
<span class=""><br>
> If that's acceptable, the ktls stuff looks like a simple addition (on<br>
> top of base in-toybox tls) with potential performance improvements, once<br>
> the code settles down.<br>
<br>
</span>Another thing is this adds a kernel version dependency, so I'd want a<br>
compile time probe for "is support there in this build environment"<br>
because <a href="http://landley.net/toybox/faq.html#support_horizon" rel="noreferrer" target="_blank">http://landley.net/toybox/faq.<wbr>html#support_horizon</a><br>
<br>
That said, my plan to spend the evening grinding on the toybox todo list<br>
seamlessly transitioned into hours analyzing GPS code and traces trying<br>
to figure out where the race condition is in the response to the<br>
correlator output (answer: there's two _different_ problems), so... :P<br>
<div class="HOEnZb"><div class="h5"><br>
Rob<br>
______________________________<wbr>_________________<br>
Toybox mailing list<br>
<a href="mailto:Toybox@lists.landley.net">Toybox@lists.landley.net</a><br>
<a href="http://lists.landley.net/listinfo.cgi/toybox-landley.net" rel="noreferrer" target="_blank">http://lists.landley.net/<wbr>listinfo.cgi/toybox-landley.<wbr>net</a><br>
</div></div></blockquote></div><br></div>