[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-wget] libtlssep and wget
W. Michael Petullo
Re: [Bug-wget] libtlssep and wget
Sun, 26 Jul 2015 14:47:30 -0400
> 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.
I am leaning towards printing an error message which points the user to
the configuration files and terminates on --no-check-certificate. (See
With libtlssep, we think certificate pinning (and other verification
techniques) should be selected at configuration time.
> Regarding the related work, I miss a mention to tlscourier. courier
> mta has been handling tls using a separate process for years.
We certainly missed that one. Shoot.
> 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...
I agree that would be great. Rewriting the TLS library itself was a
bit beyond our scope. We have since reached out to the s2n folks, and
perhaps some of these concepts will make their way into that library.
>> 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 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).
We are really pushing for systems that are more understandable, that is,
both users and administrators (and folks who satisfy both) need to have
more confidence about what their computer is doing on their behalf.
Fine-grained access control systems such as SELinux would allow a policy
that *requires* applications to make use of the libtlssep decorator and
further *forbids* applications from reconfiguring cetificate validation.
One possible scenario is that a system is configured such that *no*
application can trust invalid certificates (say, invalid with respect
to CAs + pinning).
Another possible scenario is to permit users to configure particular
applications to trust unsafe certificates such as self-signed, etc.
Here are some things to consider:
I have just downloaded a script or program that makes use of wget
(or really any alternative). How do I know that the script or
program does not use --no-check-certificate (or similar options
available to alternatives)? Recall that I can, using SELinux,
already force the use of libtlssep's decorator.
I am an administrator who is trying to categorically prevent my
users from avoiding CA-based verification. How can I do this?
In any case, adding the option to use --no-check-certificate to
libtlssep's configuration---as well as other applications honoring
similar parameters, environment variables, etc.---all serves to make it
less possible to determine what is permitted on a given computer.
For these reasons, I am leaning towards --no-check-certificate on
libtlssep/wget merely printing an error message pointing the user to
libtlssep's configuration path and terminating.
There are other alternatives. Angel suggested a NO_CERTIFICATE_CHECK
parameter for tlssep_init. That could work, but to provide the properties
that we want this would have to couple with something else. For example,
we could hard link tlssep-decorator-unsafe to tlssep-decorator, and
running either program name could result in the corresponding behavior.
Then, a restrictive SELinux policy could forbid the execution of
tlssep-decorator-unsafe, and a permissive policy could allow it. However,
this makes the error semantics a bit strange; a "cannot execute
tlssep-decorator-unsafe" error does not exactly represent "you can only
avoid certificate verification by reconfiguring libtlssep".
> I support adding tlssep as an option to wget, although some options need
> more work.
My team certainly has to consider each HTTPS-related wget option in turn.
> 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
Fixed. Thank you.
> 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).
This used to be relevant and referenced, but it no longer is either. I
removed this comment in Git master. Thank you.