Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: How to handle CA certificate bundles in portable application bundles (e.g., AppImages)?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dan Fandrich via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 18 May 2022 18:00:45 -0700
On Thu, May 19, 2022 at 02:24:15AM +0200, TheAssassin via curl-library wrote:
> On 18.05.22 22:57, Dan Fandrich via curl-library wrote:
> > This sounds like it would become a source of problems, since the same
> > application running on exactly the same OS would have different behaviour
> > depending on whether a user-specified file is available in a magic location or
> > not.
>
> What do you mean by user-specified file? The search path would be a
> compile-time option, classic distro libs would not enable the option.
> What do you mean by magic location?
Anything other than the standard OS-specific bundle is going to look magic to
the user. For example, if the path were set to
/etc/motd:/etc/pki/tls/certs/ca-bundle.crt then a file created at
/etc/motd would magically (i.e. unexpectedly) cause TLS connections to
stop working. Yes, that's a contrived worst-case example, and if AppImage
points it to an internal sandboxed path and documents it appropriately it
shouldn't be a problem.
> > There are security implications in setting up such a path.
>
> Could you please share your concerns? I have thought about this, too, but
> couldn't come up with any problems. Note that the search path would be used
> only by applications which come as an AppImage anyway. And the search within
> libcurl is no way worse than a search within the application itself.
The most straightforward example is if the path included a world-writable
location, then an attacker could place a bad certificate there and enable a
MITM attack. Since there currently is no search within libcurl, there is
currently no danger.
I'm probably more wary of this than I need to be, but if such a feature is
added the implications need to be thoroughly thought through.
Dan
Date: Wed, 18 May 2022 18:00:45 -0700
On Thu, May 19, 2022 at 02:24:15AM +0200, TheAssassin via curl-library wrote:
> On 18.05.22 22:57, Dan Fandrich via curl-library wrote:
> > This sounds like it would become a source of problems, since the same
> > application running on exactly the same OS would have different behaviour
> > depending on whether a user-specified file is available in a magic location or
> > not.
>
> What do you mean by user-specified file? The search path would be a
> compile-time option, classic distro libs would not enable the option.
> What do you mean by magic location?
Anything other than the standard OS-specific bundle is going to look magic to
the user. For example, if the path were set to
/etc/motd:/etc/pki/tls/certs/ca-bundle.crt then a file created at
/etc/motd would magically (i.e. unexpectedly) cause TLS connections to
stop working. Yes, that's a contrived worst-case example, and if AppImage
points it to an internal sandboxed path and documents it appropriately it
shouldn't be a problem.
> > There are security implications in setting up such a path.
>
> Could you please share your concerns? I have thought about this, too, but
> couldn't come up with any problems. Note that the search path would be used
> only by applications which come as an AppImage anyway. And the search within
> libcurl is no way worse than a search within the application itself.
The most straightforward example is if the path included a world-writable
location, then an attacker could place a bad certificate there and enable a
MITM attack. Since there currently is no search within libcurl, there is
currently no danger.
I'm probably more wary of this than I need to be, but if such a feature is
added the implications need to be thoroughly thought through.
Dan
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-05-19