On Fri, Jan 27, 2017 at 7:23 PM, Rob Landley <[email protected]> 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 [email protected] http://lists.busybox.net/mailman/listinfo/busybox
