[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] libtlssep and wget

From: Ángel González
Subject: Re: [Bug-wget] libtlssep and wget
Date: Fri, 24 Jul 2015 00:26:20 +0200
User-agent: Thunderbird

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]