[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: SSL/TLS client command line API?
From:       Denys Vlasenko <vda.linux () googlemail ! com>
Date:       2017-02-05 18:25:19
Message-ID: CAK1hOcPgp+OAGwSDfL1dfR=c8sEteTotHV=Tho9tQjhm49NhRQ () mail ! gmail ! com
[Download RAW message or body]

On Fri, Jan 27, 2017 at 7:23 PM, Rob Landley <rob@landley.net> 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
[prev in list] [next in list] [prev in thread] [next in thread]