Re: [Bug-wget] libtlssep and wget

[Ángel González]

Great work, Michael and Leo.

I really like that. I should also note however that the API is too 
simple for many advanced uses.
The --no-check-certificate is one example. Another could be cipher 
selection.
wget explicitely disavows ciphers like RC4 or NULL, libtlsep doesn't allow
choosing accepted ciphers (neither through API nor the config file), 
sadly, that
would easily break actual tls lib transparency. I might also wish to 
perform
certificate pinning.


Regarding the related work, I miss a mention to tlscourier. courier mta 
has been
handling tls using a separate process for years.

Have you considered a variant where the ssl library itself is split into 
several processes?
One doing the hard work and the other just handling the private key. 
Such approach would
greatly reduce the surface even for bugs in the ssl library. I recall 
thinking on that shortly after
heartbldeed. You would probably be restricted to PFS ciphers, but that 
isn't necessarily a
bad thing...


On 23/07/15 14:30, W. Michael Petullo wrote:
> We presently take the more firm approach that only a configuration file
> change can affect if/how verification takes place. We could certainly
> add an API call to transition into "unsafe" mode, or we could allow the
> application to poll the setting and warn users that --no-check-certificate
> has no effect. Yet introducing these abilities would allow a compromised
> application to reconfigure itself; this might not be an additional
> capability on many systems, but with (something like) SELinux forcing
> applications to use libtlssep, this might allow the compromised
> application to make a connection in a way not otherwise permitted.
>
> I would be interested to hear other programmers' ideas.
>
> Thank you!
I would simply allow that flag just when initialising the connection. I 
would add
a flags parameter to tlssep_connect() which when containing 
NO_CERTIFICATE_CHECK
would mark the connection as that.
I don't see the problem of a “compromised application reconfiguring 
itself”, you should
clarify the attack. If you managed to compromise the application before 
opening the secure
connection, it could as well replace the secure connection with a 
plaintext one. [And if the
connection is running, I don't see how to "reconfigure" it without 
closing it and opening a
new one]. If you insist of making things hard the flag may be required 
in tlssep_init(), and it
could pass a parameter to the separate process (thus showing that to a 
casual look to the
process list).

I support adding tlssep as an option to wget, although some options need 
more work.

This piece of the patch looks like an error and isn't used anywhere:
> --- a/src/build_info.c.in
> +++ b/src/build_info.c.in
> @@ -12,3 +12,4 @@ psl defined HAVE_LIBPSL
> ssl choice:
> openssl defined HAVE_LIBSSL || defined HAVE_LIBSSL32
> gnutls defined HAVE_LIBGNUTLS
> + grayline defined HAVE_LIBGRAYLINE


In the library code, tlssep.c contains a footnote about the use of 
static variables, but nothing
seems to reference it (and the file doesn't contain static globals).

Best regards