[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH8yC8nYOGAsnPkm+f3-b7r4PvZ=QxeKT9DXK=MoFVoFDGav9w@mail.gmail.com>
Date: Thu, 20 Apr 2023 11:47:16 -0400
From: Jeffrey Walton <noloader@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Perl's HTTP::Tiny has insecure TLS cert default,
affecting CPAN.pm and other modules
On Thu, Apr 20, 2023 at 9:05 AM Steffen Nurpmeso <steffen@...oden.eu> wrote:
>
> Hanno Böck wrote in
> <20230420073459.003a5be2.hanno@...eck.de>:
> |On Wed, 19 Apr 2023 23:53:40 +0200
> |Steffen Nurpmeso <steffen@...oden.eu> wrote:
> |> IMO it is no vulnerability at all since it has "always" been _very
> |> clearly_ (even very lengthily) documented in the manual page.
> |
> |A vulnerability does not go away if it's documented, and I find that a
> |rather strange take.
>
> Hm no, i do not, the latter not at all. You can bundle a OpenPGP
> / signify / even OpenSSL signature with something and can get
> secure download even over non-encrypted channels. Even DNSSEC was
> over unencrypted channels for twenty years, and still mostly is,
> so, .. that i say that one day, _that_ is strange.
> I mean, i do not want to start useless and fruitless discussions,
> and it will be treated as a bug in HTTP::Tiny no matter what
> i say, hysteria is king.
According to the HTTP::Tiny docs:
Server identity verification is controversial and potentially tricky
because it depends on a (usually paid) third-party Certificate
Authority (CA) trust model to validate a certificate as legitimate.
This discriminates against servers with self-signed certificates or
certificates signed by free, community-driven CA's such as CAcert.org.
I think some of the premises no longer hold.
The threat models I have seen depend upon authentic comms. You have to
know which server you are talking to to ensure confidentiality and
authenticity. There's nothing controversial about them.
There's also the pervasive spying the world has evidence of since
leaks like Snowden. We know folks are being spied upon by the
government, and we know people can be tortured or die from it if they
live under a despot regime. There's nothing controversial about using
HTTPS to help achieve confidentiality.
I don't think HTTPS discriminates against servers with self-signed
certificates. A user is free to limit trust to a single, self-signed
certificate. The docs show the user how to do it.
I don't think HTTPS discriminates against free, community-driven CA's.
Let's Encrypt is quite popular and still free.
A more interesting question (to me) is, how does HTTP::Tiny
differentiate between comms that need server authentication (like
fetching a web page) versus those that don't (like a download with a
GPG signature). The answer is likely, HTTP::Tiny cannot.
SinceHTTP::Tiny cannot determine when the user needs HTTPS (or not),
it should default to HTTPS.
In general, nowadays, I think the person who is maintaining HTTP::Tiny
is plunging on the wrong sword. There are better battles to fight
nowadays.
(Sorry to wander off-topic).
Jeff
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
