[Toybox] [RFC] ktls is in 4.13.
Rob Landley
rob at landley.net
Tue Sep 5 04:59:38 PDT 2017
On 09/04/2017 10:19 PM, scsijon wrote:
>
>> Date: Sun, 3 Sep 2017 23:12:05 -0500
>> From: Rob Landley <rob at landley.net>
>> To: toybox <toybox at lists.landley.net>
>> Subject: [Toybox] [RFC] ktls is in 4.13.
>> Message-ID: <2ada100d-1403-989e-c2bc-4f5fef1d97fd at landley.net>
>> Content-Type: text/plain; charset=utf-8
>>
>> The kernel just merged "ssl renamed after thread local storage" support:
>>
>> vpaper: https://netdevconf.org/1.2/papers/ktls.pdf
>> sample code: https://github.com/ktls/af_ktls
>>
>> It's basic https plumbing in the kernel, but doesn't do the handshake or
>> renegotiation. What I'm wondering is would this be a better thing to try
>> to plug into than the openssl command line utility?
>>
>> Worth bothering with?
>>
>> Rob
>
> And the security issues if it's within toybox rather than an external
> via openssl, especially as a lot of us run as root so we can 'play'?
Well hopefully most of the plumbing is in the kernel and auditied by the
kernel guys. That's what's interesting about this. I dunno how much
plumbing is left for toybox to implement. (Sadly it seems like a
nontrivial amount...)
The actual math doesn't seem that much worse than stuff like sha1sum,
but the security auditing is a blocking issue. I believe Android had
boringssl professionally audited and doesn't want to mess with two
codebases doing the same security-critical thing, and I can't blame 'em.
I'm thinking "leverage kernel auditing" might help reduce that concern,
but not if there's still significant security plumbing gratuitously left
for userspace to get wrong? Haven't had a chance to do a deep dive into
this yet, probably won't for a while...
Part of my frustration is openssl and bearssl don't have quite the same
command line syntax. There's no standard "stunnel blah" command line I
can use that's implementation independent. Otherwise I'd just do the
"pipe it through a child process" thing and be done with it. (Might
still, it's just nontrivial.)
> scsijon
> ps do you prefer top-posts in-posts or bottom-posts for this sort of
> thing please rob?
I prefer bottom posts but I'm aware doubtlook goes out of its way to
make that as hard as possible. (I've had to use it at a couple of small
contracts and half my email time was manually inserting > stuff. Recent
releases of Mozilla's Thunderbird copied the stupid even _closer_, but
you can cut the blue reply sections and paste them back so they stop
being magic and become normally editable again as a workaround...)
I mostly tend to follow whichever style the previous poster did. Mixing
them is worse than either, and fixing up a top post to not be a top post
is time consuming. :)
Rob
More information about the Toybox
mailing list