Re: SSL/TLS client command line API?

[Denys Vlasenko]

On Fri, Jan 27, 2017 at 7:23 PM, Rob Landley  wrote:
>> "openssl s_client" is not a production tool, it's a debug thing.
>
> I lean towards 'use existing tool' vs 'invent a new thing'. It seems to
> be installed by default on the systems I've looked at.

Yes, I know, but being a debug thing, it prints various unwanted crap
on stderr. Currently, we deal with it by sending its stderr
to /dev/null. Which means, if there is an actual error,
then it's not seen too.

>> Bigger problem is, it can't be handed a fd to perform TLS on,
>> it takes hostname.
>
> Also required by the protocol: you have to verify the hostname attached
> to the certificate is the one you expected. (The main reason this is
> still on my todo list is I haven't tackled the certificate management
> can of worms for mkroot yet.)
>
>> Meaning, wget can't launch it saying "here's
>> a socket I already opened, please wrap it in TLS".
>
> And you want wget to do this because...?

It feels wrong when hostname resolution for FTP/HTTP
is done by wget's own code, but for HTTPS is is done in a helper.

> (In theory you can upgrade an existing connection to ssl, but dialing
> out again when you get a redirect is pretty normal...)
>
>> This second problem is shared by stunnel, various flavors of
>> "enhanced netcats" with --ssl options etc: none of them will wrap
>> a given fd.
>
> Because the protocol requires them to know the hostname they're
> connecting to.

You can give them the fd and the hostname.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: SSL/TLS client command line API?

[Rob Landley]

On 01/19/2017 08:17 AM, Denys Vlasenko wrote:
> Hi folks,
>
> Now that I have some code reaching a state where
> it does talk TLS 1.2, the question is how to integrate it.

This is one of my longstanding todo items for toybox too.

> TLS i/o entails some buffering.

Possibly protocol-required? You want to eliminate keystroke timings as
an attack vector. I was thinking some variant of nagle with 1/4 second
timeouts would probably be enough collating to defeat that without
annoying humans too much. (I added some code like this to busybox's vi a
few years back to collate escape sequences, possibly genericizable? On
my end I first wanted to test if the command line utility was already
_doing_ that...)

> I feel it would be better
> if we don't complicate other applets code with changes to
> accomodate that. Even if at first it looks "easy",
> just replace
> 
> write(fd, buf, len)
> with
> tls_write(tls, buf, len)
> 
> it quickly becomes much more difficult when you need a proper
> bidirectional piping, not a simple synchronous blocking reads
> and writes.

You either pipe through an external program or add busybox's first build
dependency. The first seems more in keeping with the project so far. :)

> wget already has a solution. It forks a child which does TLS magic,
> and talks to it over an ordinary socketpair.
> Right now it launched either "openssl s_client" or our own separate
> helper utility linked against a SSL library.
> 
> Our helper works like this:
> 
> ssl_helper -d N
> 
> it talks TLS over fd N, passing plaintext from/to stdin/out.
> 
> In order to add a real applet, I looked for an SSL/TLS client tool
> in widespread use to emulate, and did not find one with a suitable API.
> 
> "openssl s_client" is not a production tool, it's a debug thing.

I lean towards 'use existing tool' vs 'invent a new thing'. It seems to
be installed by default on the systems I've looked at.

There's also one in https://bearssl.org/ but I haven't played with it
much yet:

$ build/brssl client --help
ERROR: unknown option: '--help'
usage: brssl client server[:port] [ options ]
options:
   -q  suppress verbose messages
   -trace  activate extra debug messages (dump of all packets)
   -sni name   use this specific name for SNI
   -nosni  do not send any SNI
   -mono   use monodirectional buffering
   -buf length set the I/O buffer length (in bytes)
   -CA fileadd certificates in 'file' to trust anchors
   -cert file  set client certificate chain
   -key file   set client private key (for certificate authentication)
   -nostaticecdh   prohibit full-static ECDH (client certificate)
   -list   list supported names (protocols, algorithms...)
   -vmin name  set minimum supported version (default: TLS-1.0)
   -vmax name  set maximum supported version (default: TLS-1.2)
   -cs names   set list of supported cipher suites (comma-separated)
   -hf names   add support for some hash functions (comma-separated)
   -minhello len   set minimum ClientHello length (in bytes)
   -fallback   send the TLS_FALLBACK_SCSV (i.e. claim a downgrade)
   -norenegprohibit renegotiations
   -alpn name  add protocol name to list of protocols (ALPN extension)
   -strictalpn fail on ALPN mismatch

That one doesn't say it's a debug tool, it seems a normal part of the
package.

> Bigger problem is, it can't be handed a fd to perform TLS on,
> it takes hostname.

Also required by the protocol: you have to verify the hostname attached
to the certificate is the one you expected. (The main reason this is
still on my todo list is I haven't tackled the certificate management
can of worms for mkroot yet.)

> Meaning, wget can't launch it saying "here's
> a socket I already opened, please wrap it in TLS".

And you want wget to do this because...?

(In theory you can upgrade an existing connection to ssl, but dialing
out again when you get a redirect is pretty normal...)

> This second problem is shared by stunnel, various flavors of
> "enhanced netcats" with --ssl options etc: none of them will wrap
> a given fd.

Because the protocol requires them to know the hostname they're
connecting to.

> Do you know a tool whose command line is suitable for us?

I was pretty happy with the bearssl one, but haven't tried to do that
much with it yet.

I have a todo item to poke the bearssl guy to let his command line
server mode run an inetd-style command line with each connection (like
netcat server mode does). I'd also like to convince him that cutting
releases is a good idea...

I have no idea what openssl's server mode thinks it's doing...

Rob
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: SSL/TLS client command line API?

[Denys Vlasenko]

On Fri, Jan 20, 2017 at 1:38 AM, Laurent Bercot
 wrote:
>> In order to add a real applet, I looked for an SSL/TLS client tool
>> in widespread use to emulate, and did not find one with a suitable API.
>>
>> "openssl s_client" is not a production tool, it's a debug thing.
>> Bigger problem is, it can't be handed a fd to perform TLS on,
>> it takes hostname. Meaning, wget can't launch it saying "here's
>> a socket I already opened, please wrap it in TLS".
>>
>> This second problem is shared by stunnel, various flavors of
>> "enhanced netcats" with --ssl options etc: none of them will wrap
>> a given fd.
>>
>> Do you know a tool whose command line is suitable for us?
>
>
>  I have written one a couple months ago:
>  http://skarnet.org/software/s6-networking/s6-tlsc.html
>
>  The goal was to do the exact thing you want, i.e. use an existing fd
> instead of connecting to the host.
> (There is also the "easy to use" interface that connects to the host,
> http://skarnet.org/software/s6-networking/s6-tlsclient.html , but it's
> just a wrapper around s6-tlsc.)

Basically, a "ncat --ssl".

I'm leaning towards just adding that to our netcat instead of inventing
Yet Another Tool.

>  Since I'm here, let me use the opportunity to fanboy over BearSSL
> (https://bearssl.org/), which is a SSL library still being developed
> and considered experimental by its author, but already incredibly good.
> s6-tlsc can be linked against it and it makes for a very small executable
> - the static binary is seven times smaller than the same program linked
> against LibreSSL - and an even smaller memory footprint.

Thanks, but it's a bit too late... I bit the bullet and wrote one
(rudimentary one, yes) from scratch:

https://git.busybox.net/busybox/tree/networking/tls.c

I did not check BearSSL, but libraries which I did check tended to be
way, way too big for bbox's very limited goals of
"make HTTPS work so that I can wget a kernel, dammit".

They link in something like 150 kb of code.
This is against wolfSSL, for example:
$ size ssl_helper
   text   databssdechexfilename
 178991696  13424 193111  2f257ssl_helper
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: SSL/TLS client command line API?

[Lauri Kasanen]

On Thu, Jan 19, 2017, at 16:17, Denys Vlasenko wrote:
> Hi folks,
>
> So far bbox is completely SSL/TLS-illiterate. wget can't talk
> HTTPS. sendmail groks neither smtps not STARTTLS command. nc can't
> do TLS either.
...
> Do you know a tool whose command line is suitable for us?

Don't know of any, but this seems to be a reasonably common need. About
a year ago, I needed almost the same thing, "do the SSL magic for me and
let me handle the raw protocol" in a curl-using app, but curl did not
have such a mode, and no plans to add it. Their reply was "do it
manually using openssl", which pushed it down on the interesting-things-
list and so didn't get done.

- Lauri

-- 
http://www.fastmail.com - mmm... Fastmail...

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

SSL/TLS client command line API?

[Denys Vlasenko]

Hi folks,

So far bbox is completely SSL/TLS-illiterate.
wget can't talk HTTPS. sendmail groks neither
smtps not STARTTLS command.
nc can't do TLS either.

Now that I have some code reaching a state where
it does talk TLS 1.2, the question is how to integrate it.

TLS i/o entails some buffering. I feel it would be better
if we don't complicate other applets code with changes to
accomodate that. Even if at first it looks "easy",
just replace

write(fd, buf, len)
with
tls_write(tls, buf, len)

it quickly becomes much more difficult when you need a proper
bidirectional piping, not a simple synchronous blocking reads
and writes.

wget already has a solution. It forks a child which does TLS magic,
and talks to it over an ordinary socketpair.
Right now it launched either "openssl s_client" or our own separate
helper utility linked against a SSL library.

Our helper works like this:

ssl_helper -d N

it talks TLS over fd N, passing plaintext from/to stdin/out.

In order to add a real applet, I looked for an SSL/TLS client tool
in widespread use to emulate, and did not find one with a suitable API.

"openssl s_client" is not a production tool, it's a debug thing.
Bigger problem is, it can't be handed a fd to perform TLS on,
it takes hostname. Meaning, wget can't launch it saying "here's
a socket I already opened, please wrap it in TLS".

This second problem is shared by stunnel, various flavors of
"enhanced netcats" with --ssl options etc: none of them will wrap
a given fd.

Do you know a tool whose command line is suitable for us?

If bbox has to invent its own, how about this:

ssl_client -sN [-rM] [--sni HOST]

send/recv TLS data over fds N and M
--sni NAME: send SNI in TLS handshake (wget needs this for vhosts)

This can be used by wget, sendmail (, ftps?)

ssl_client HOST[:PORT] [-e PROG] [other nc-like opts]

netcat-like operation

Possible later we can add "ssl_server" applet, if necessary.
(SSL client and server handshake is not particularly symmetrical,
for coder sanity it makes sense to keep them separate.
See tftp.c for a nightmarish entangled code which does both at once
for a rather simple TFTP protocol).
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox