Discussion:
[RFC] ktls is in 4.13.
(too old to reply)
Rob Landley
2017-09-04 04:12:05 UTC
Permalink
Raw Message
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
Robert Thompson
2017-09-05 01:22:10 UTC
Permalink
Raw Message
From the toybox point of view, wouldn't this introduce direct link
dependency on ssl/tls libraries?

If that's acceptable, the ktls stuff looks like a simple addition (on top
of base in-toybox tls) with potential performance improvements, once the
code settles down.
Post by Rob Landley
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
_______________________________________________
Toybox mailing list
http://lists.landley.net/listinfo.cgi/toybox-landley.net
Rob Landley
2017-09-05 10:33:19 UTC
Permalink
Raw Message
Post by Robert Thompson
From the toybox point of view, wouldn't this introduce direct link
dependency on ssl/tls libraries?
There's already an optional dependency to accelerate hash calculations
(CONFIG_TOYBOX_LIBCRYPTO), and another to accelerate zlib, so I'm ok
with having that as an optional dependency.

Having functionality you can _only_ get by linking that in is a much
bigger ask. I want a self-contained system bootstrap build and/or
hermetic build with minimal dependencies.

So ideally I'd want the part of tls negotiation the kernel doesn't do
implemented in toybox code, but I dunno how much that is yet...
Post by Robert Thompson
If that's acceptable, the ktls stuff looks like a simple addition (on
top of base in-toybox tls) with potential performance improvements, once
the code settles down.
Another thing is this adds a kernel version dependency, so I'd want a
compile time probe for "is support there in this build environment"
because http://landley.net/toybox/faq.html#support_horizon

That said, my plan to spend the evening grinding on the toybox todo list
seamlessly transitioned into hours analyzing GPS code and traces trying
to figure out where the race condition is in the response to the
correlator output (answer: there's two _different_ problems), so... :P

Rob
Robert Thompson
2017-09-05 21:52:05 UTC
Permalink
Raw Message
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. 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).
Post by Rob Landley
Post by Robert Thompson
From the toybox point of view, wouldn't this introduce direct link
dependency on ssl/tls libraries?
There's already an optional dependency to accelerate hash calculations
(CONFIG_TOYBOX_LIBCRYPTO), and another to accelerate zlib, so I'm ok
with having that as an optional dependency.
Having functionality you can _only_ get by linking that in is a much
bigger ask. I want a self-contained system bootstrap build and/or
hermetic build with minimal dependencies.
So ideally I'd want the part of tls negotiation the kernel doesn't do
implemented in toybox code, but I dunno how much that is yet...
Post by Robert Thompson
If that's acceptable, the ktls stuff looks like a simple addition (on
top of base in-toybox tls) with potential performance improvements, once
the code settles down.
Another thing is this adds a kernel version dependency, so I'd want a
compile time probe for "is support there in this build environment"
because http://landley.net/toybox/faq.html#support_horizon
That said, my plan to spend the evening grinding on the toybox todo list
seamlessly transitioned into hours analyzing GPS code and traces trying
to figure out where the race condition is in the response to the
correlator output (answer: there's two _different_ problems), so... :P
Rob
_______________________________________________
Toybox mailing list
http://lists.landley.net/listinfo.cgi/toybox-landley.net
Rob Landley
2017-09-06 01:33:08 UTC
Permalink
Raw Message
Post by Robert Thompson
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
Post by Robert Thompson
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
Alain Toussaint
2017-09-05 02:22:41 UTC
Permalink
Raw Message
[snip] replied directly to Rob first but worth sending to the list­...
Post by Rob Landley
Worth bothering with?
With tcpsrv, wget and the wireless tools planned into toybox, you're
bound to support tls in one form or another, thus, ktls would bring
one question from me:

Given that part of tls is in the kernel, does that bring enough of a
code reduction in toybox to use it (i.e. only deal with handshake in
toybox instead of bring a full tls stack)?

Alain
scsijon
2017-09-05 03:19:00 UTC
Permalink
Raw Message
Date: Sun, 3 Sep 2017 23:12:05 -0500
Subject: [Toybox] [RFC] ktls is in 4.13.
Content-Type: text/plain; charset=utf-8
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'?

scsijon
ps do you prefer top-posts in-posts or bottom-posts for this sort of
thing please rob?
Rob Landley
2017-09-05 11:59:38 UTC
Permalink
Raw Message
Post by scsijon
Date: Sun, 3 Sep 2017 23:12:05 -0500
Subject: [Toybox] [RFC] ktls is in 4.13.
Content-Type: text/plain; charset=utf-8
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.)
Post by scsijon
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
scsijon
2017-09-07 05:14:15 UTC
Permalink
Raw Message
Post by Rob Landley
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.)
Post by scsijon
scsijon
Rob
And just now i've found about Libressl (libressl.org) to maybe add to
your woes, I wonder if they would be willing to work with you?

and i'll go sleep again :-)} (bearded smile)

scsijon
Rob Landley
2017-09-09 00:02:53 UTC
Permalink
Raw Message
Post by scsijon
Post by Rob Landley
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.)
Post by scsijon
scsijon
Rob
And just now i've found about Libressl (libressl.org) to maybe add to
your woes, I wonder if they would be willing to work with you?
libressl and boringssl are forks of openssl that happened after
heartbleed reminded everybody OpenBSD doesn't really care about Linux
(except when it needs money).

Bearssl is independently developed (clean C, mit licensed, reasonably
usable in an embedded environment). PolarSSL used to be another one but
the company behind it changed and relicensed it and I stopped paying
attention. There are a dozen others:

https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations

(Sadly, dropbear is not one. Many people have asked him to add it over
the years, but apparently it's significantly different plumbing. Which
makes openssh depending on openssl kinda confusing, but ok...)

Rob

Loading...