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: Has the time come to drop NSS?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Henrik Holst via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 21 Feb 2022 14:45:25 +0100
Den mån 21 feb. 2022 kl 14:40 skrev Michael Stahl via curl-library <
curl-library_at_lists.haxx.se>:
> On 20/02/2022 14.18, Cristian Rodríguez wrote:
> > On Fri, Feb 18, 2022 at 12:29 PM Michael Stahl via curl-library
> > <curl-library_at_lists.haxx.se> wrote:
> >
> >> NSS is much preferred over OpenSSL because it has an ABI;
> >
> > I do not know which openssl version are you basing your analysis on..
> > but much work and breakage
> > have gone in during and after 1.1.x development cycle to make a stable
> > ABI at least possible.
> > haven't checked but it is likely that effort continued on 3.x.
>
> so possibly the situation will be improved in 10 years' time.
>
> meanwhile the oldest system our application is supposed to run on
> (RHEL7) ships with OpenSSL 1.0.2.
>
> >> OpenSSL on the other hand must be statically linked into every library
> >> that uses it because inevitably some system library will load the
> >> system's OpenSSL into the process which is a different version and then
> >> symbols from 2 shared libs will trample over each other in ELF global
> >> namespace and crash is inevitable.
> >
> > Well.. yeah. that is one of the many downsides of the approach you are
> taking..
> >
> >> i believe that the OpenSSL libraries we ship use a hard-coded list of
> >> built-in trusted CAs, which the user can't modify in any way, but i
> >> haven't actually checked if that is still the case.
> >
> > You can add a trusted CA before the handshake takes place..so no. it
> > is ot the case.
>
> this is not entirely satisfying.
>
> ideally we do not really want to be in the business of deciding for the
> user which CAs they do or do not trust.
>
> we can easily make this decision Somebody Else's Problem on Windows and
> macOS by using the system TLS stack, at least with curl.
>
> do you know if it's possible to initialize OpenSSL in such a way that it
> reads a trust database from the operating system, and do that centrally
> for the whole process?
>
Unfortunately not without doing it all yourself. There are no code in
OpenSSL for doing anything with e.g the WIndows certificate store. So one
would have to use the callbacks in OpenSSL to handle the certificate
verification yourself and then add code for the CryptoAPI to do that.
/HH
>
> if we would need to patch 4 bundled libraries separately to get
> this effect i would be rather sad.
>
> but this could be helpful, in case such a database can be conveniently
> located on every distro...
>
> i think we already have this with NSS by using NSS_InitReadWrite().
> --
> Unsubscribe: https://lists.haxx.se/listinfo/curl-library
> Etiquette: https://curl.haxx.se/mail/etiquette.html
>
Date: Mon, 21 Feb 2022 14:45:25 +0100
Den mån 21 feb. 2022 kl 14:40 skrev Michael Stahl via curl-library <
curl-library_at_lists.haxx.se>:
> On 20/02/2022 14.18, Cristian Rodríguez wrote:
> > On Fri, Feb 18, 2022 at 12:29 PM Michael Stahl via curl-library
> > <curl-library_at_lists.haxx.se> wrote:
> >
> >> NSS is much preferred over OpenSSL because it has an ABI;
> >
> > I do not know which openssl version are you basing your analysis on..
> > but much work and breakage
> > have gone in during and after 1.1.x development cycle to make a stable
> > ABI at least possible.
> > haven't checked but it is likely that effort continued on 3.x.
>
> so possibly the situation will be improved in 10 years' time.
>
> meanwhile the oldest system our application is supposed to run on
> (RHEL7) ships with OpenSSL 1.0.2.
>
> >> OpenSSL on the other hand must be statically linked into every library
> >> that uses it because inevitably some system library will load the
> >> system's OpenSSL into the process which is a different version and then
> >> symbols from 2 shared libs will trample over each other in ELF global
> >> namespace and crash is inevitable.
> >
> > Well.. yeah. that is one of the many downsides of the approach you are
> taking..
> >
> >> i believe that the OpenSSL libraries we ship use a hard-coded list of
> >> built-in trusted CAs, which the user can't modify in any way, but i
> >> haven't actually checked if that is still the case.
> >
> > You can add a trusted CA before the handshake takes place..so no. it
> > is ot the case.
>
> this is not entirely satisfying.
>
> ideally we do not really want to be in the business of deciding for the
> user which CAs they do or do not trust.
>
> we can easily make this decision Somebody Else's Problem on Windows and
> macOS by using the system TLS stack, at least with curl.
>
> do you know if it's possible to initialize OpenSSL in such a way that it
> reads a trust database from the operating system, and do that centrally
> for the whole process?
>
Unfortunately not without doing it all yourself. There are no code in
OpenSSL for doing anything with e.g the WIndows certificate store. So one
would have to use the callbacks in OpenSSL to handle the certificate
verification yourself and then add code for the CryptoAPI to do that.
/HH
>
> if we would need to patch 4 bundled libraries separately to get
> this effect i would be rather sad.
>
> but this could be helpful, in case such a database can be conveniently
> located on every distro...
>
> i think we already have this with NSS by using NSS_InitReadWrite().
> --
> Unsubscribe: https://lists.haxx.se/listinfo/curl-library
> Etiquette: https://curl.haxx.se/mail/etiquette.html
>
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-02-21