[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