Re: [Toybox] [RFC] ktls is in 4.13.

[Rob Landley]

On 09/07/2017 12:14 AM, scsijon wrote:
> 
>>
>> 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
> 
>>
>> 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
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [RFC] ktls is in 4.13.

[scsijon]

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




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
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [RFC] ktls is in 4.13.

[Rob Landley]

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
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [RFC] ktls is in 4.13.

[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. 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).




On Tue, Sep 5, 2017 at 5:33 AM, Rob Landley  wrote:

> On 09/04/2017 08:22 PM, Robert Thompson wrote:
> > 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...
>
> > 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
> Toybox@lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [RFC] ktls is in 4.13.

[Rob Landley]

On 09/04/2017 08:22 PM, Robert Thompson wrote:
> 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...

> 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
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [RFC] ktls is in 4.13.

[scsijon]

Date: Sun, 3 Sep 2017 23:12:05 -0500
From: Rob Landley <r...@landley.net>
To: toybox <toybox@lists.landley.net>
Subject: [Toybox] [RFC] ktls is in 4.13.
Message-ID: <2ada100d-1403-989e-c2bc-4f5fef1d9...@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'?


scsijon
ps do you prefer top-posts in-posts or bottom-posts  for this sort of 
thing please rob?

___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [RFC] ktls is in 4.13.

[Robert Thompson]

>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.


On Sun, Sep 3, 2017 at 11:12 PM, Rob Landley  wrote:

> 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
> ___
> Toybox mailing list
> Toybox@lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net