On 09/05/2017 04:52 PM, Robert Thompson wrote: > 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 > > https://github.com/ktls/af_ktls-tool/blob/master/client.c > https://github.com/ktls/af_ktls-tool/blob/master/xlibgnutls.c > > 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. > > It really looks like using ktls will depend on a full openssl or gnutls > library.
Yeah, that's what I was hoping to avoid. Piping data through a separate encryption executable ala stunnel isn't a _bad_ solution (same as tar piping through gzip), I just don't want an if/else staircase for stunnel, openssl, bearssl, and whatever else is out there's different command line syntaxes. :P > 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). All clients have to support that, but all servers don't? Makes perfect sense for servers are less up-to-date than clients, it's not like servers have the same exposure to security vulnerabilities as clients... Grumble grumble, Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
