Bug#792490: openssl s_client doesn't allow for certificate pinning anymore!

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#792490: openssl s_client doesn't allow for certificate pinning anymore!

Florent Daignière (NextGen$)
Package: openssl
Version: 1.0.2d-1
Severity: grave
Tags: security
Justification: user security hole

Dear Maintainer,

It looks like openssl s_client is not providing any way to disregard the system's trusted CAs anymore... and this is a regression from Jessie.

with 1.0.2d-1 (sid)
$strace -f -e open openssl s_client -no_alt_chains -CAfile /dev/null -CApath /var/empty/ -connect imap.gmail.com:imaps
....
open("/usr/lib/ssl/certs/578d5c04.0", O_RDONLY) = 4
....
    Verify return code: 0 (ok)


with 1.0.1k-3+deb8u1 (Jessie)
$openssl s_client -CAfile /dev/null -CApath /var/empty/ -connect imap.gmail.com:imaps
....
    Verify return code: 20 (unable to get local issuer certificate)


other options like -verify_return_error don't seem to help either...

Three questions spring to mind:
        - How can we get it to do what's expected? (new options have been introduced... but I can't seem to find the equivalent of -trusted for openssl verify)
        - Is it sane to change the behaviour like that without documenting it?

Regards,
        Florent


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openssl depends on:
ii  libc6        2.19-19
ii  libssl1.0.0  1.0.2d-1

openssl recommends no packages.

Versions of packages openssl suggests:
ii  ca-certificates  20150426


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#792490: openssl s_client doesn't allow for certificate pinning anymore!

Ben Hutchings-3
Control: severity -1 important
Control: tag -1 - security

On Wed, 15 Jul 2015 12:52:24 +0200 Florent Daigniere <
[hidden email]> wrote:
> Package: openssl
> Version: 1.0.2d-1
> Severity: grave
> Tags: security
> Justification: user security hole
>
> Dear Maintainer,
>
> It looks like openssl s_client is not providing any way to disregard
the system's trusted CAs anymore... and this is a regression from
Jessie.
[...]

openssl s_client doesn't check the certificate's names either, and
never has.  It should only be used for debugging, not to make a secure
tunnel.  For secure tunnelling see the example in
<https://www.decadent.org.uk/ben/blog/securing-git-imap-send-in-debian.html>

Ben.

--
Ben Hutchings
Kids!  Bringing about Armageddon can be dangerous.  Do not attempt it in
your own home. - Terry Pratchett and Neil Gaiman, `Good Omens'


signature.asc (828 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#792490: openssl s_client doesn't allow for certificate pinning anymore!

Florent Daignière (NextGen$)
On Mon, 2015-09-07 at 13:00 +0100, Ben Hutchings wrote:

>
> openssl s_client doesn't check the certificate's names either, and
> never has.  It should only be used for debugging, not to make a
> secure
> tunnel.  For secure tunnelling see the example in
> <https://www.decadent.org.uk/ben/blog/securing-git-imap-send-in
> -debian.html>
>
> Ben.
>

Agreed. The catch is that it's useless as a debugging tool too with the
new behaviour (see bug #792396). There's no indication whatsoever that
the system's CA path has been added to the certificate chain... and the
manual goes as far as suggesting that it isn't:

"      
-CApath directory
The directory to use for server certificate verification. [...]
"

Florent

Reply | Threaded
Open this post in threaded view
|

Bug#792490: [Pkg-openssl-devel] Bug#792490: openssl s_client doesn't allow for certificate pinning anymore!

Kurt Roeckx
On Mon, Sep 07, 2015 at 02:56:44PM +0200, Florent Daigniere wrote:

>
> Agreed. The catch is that it's useless as a debugging tool too with the
> new behaviour (see bug #792396). There's no indication whatsoever that
> the system's CA path has been added to the certificate chain... and the
> manual goes as far as suggesting that it isn't:
>
> "      
> -CApath directory
> The directory to use for server certificate verification. [...]
> "

As far as I know there is a default CApath being used, and using
-CApath adds that directory.  But I think it might be unexpected,
and clearly is still under documented.

I think there was some change in behaviour between 1.0.1 and
1.0.2, but I can't remember the details.


Kurt

Reply | Threaded
Open this post in threaded view
|

Bug#792490: [Pkg-openssl-devel] Bug#792490: openssl s_client doesn't allow for certificate pinning anymore!

Jean-Marc
On Mon, 7 Sep 2015 15:24:33 +0200 Kurt Roeckx <[hidden email]> wrote:

> On Mon, Sep 07, 2015 at 02:56:44PM +0200, Florent Daigniere wrote:
> >
> > Agreed. The catch is that it's useless as a debugging tool too with the
> > new behaviour (see bug #792396). There's no indication whatsoever that
> > the system's CA path has been added to the certificate chain... and the
> > manual goes as far as suggesting that it isn't:
> >
> > "      
> > -CApath directory
> > The directory to use for server certificate verification. [...]
> > "
The bug reports a problem because "openssl s_client is not providing any way to disregard the system's trusted CAs anymore" found in version openssl/1.0.2d-1.

I tested the option -no-CApath on a Debian stable (openssl 1.1.0j-1~deb9u1) and on a Debian testing/sid (openssl 1.1.1a-1) and it forced openssl to disregard the local system's CAs.

Can you tell me if this is what you are looking for ?

In this case, we can maybe ask to close this bug.

Regards,

Jean-Marc <[hidden email]>
https://6jf.be/keys/ED863AD1.txt

attachment0 (849 bytes) Download Attachment