Subject: [TLS] OCSP stapling problem

From: "T.Tributh" <[email-masked]>
Date: Sat, 15 Dec 2018 17:24:01 +0100

Hi,

first I may introduce my problem.

We take a small mail server, in this case exim and enabling TLS with an
OCSP-Must-Staple certificate. We add the status_request
like described in  RFC 6066 and everything works fine for all clients
connecting to that server and send mail.
Now we turn to sending out a mail. In this moment this server become a
client connecting to another server, which can request our certificate.
We serve (this) Must-Staple certificate, but the status_request from RFC
6066 is not included and the server should see this certificate as
"invalid".

some more details under:
https://bugs.exim.org/show_bug.cgi?id=2350

In RFC 6066:
Constrained clients may wish to use a certificate-status protocol
   such as OCSP [RFC2560] to check the validity of server certificates,

there is no information about the other direction, where a server may
request from a client ....

RFC 8446 section 4.4.2.1
A server MAY request that a client present an OCSP response with its
   certificate by sending an empty "status_request" extension in its
   CertificateRequest message.

So RFC8446 changes RFC6066 in the way that also a server can request OCSP.
Is that only intended to match for TLS 1.3 ?
Or does this change is meant also for TLS 1.2, where implementations
actually lacking this case?

Should in this case RFC 6066 changed to make the "server request from
client" case being also described?

In the moment such a mail system must have two certificates for the
server and the client mode to offer a valid cert until TLS libraries
have offered both methods.

I assume the same problem for example also for XMPP where the server is
changing to client mode too.
There may be much more protocols, which I have not in mind now.

Am I getting this right?

Kind regards

Torsten Tributh

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 18 Dec 2018 14:57:56 +0000

Does the server claim to support must-staple?

---

From: "T.Tributh" <[email-masked]>
Date: Tue, 18 Dec 2018 16:34:03 +0100

> Does the server claim to support must-staple?

The "exim" server claims to support stapling (for incoming connections)

The Must-Staple belongs to the certificate which was requested
including "1.3.6.1.5.5.7.1.24=DER:30:03:02:01:05"
in the CSR.

Most people will only request "ONE" Certificate for their server.
OCSP Must-Staple certificates are getting more popular.
When such a cert is used for incoming and outgoing connections, than
stapling must be supported when the cert is requested from a client too

This situation happens if the server asks for the certificate of the
sender, which is common.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 19 Dec 2018 01:18:29 +0000

>    The "exim" server claims to support stapling (for incoming connections)
  
Yes, which isn't what I asked.

Does the exim server understand that extension?  If, for example, exim was built with OpenSSL, then it does not handle that extension.  What TLS stack was the server built with?

>    OCSP Must-Staple certificates are getting more popular.

FWIW, I have not noticed this, but maybe I'm looking in the wrong places.  On the other hand, nobody has raised the issue, nor made a pull request, with OpenSSL, so it can't be very popular yet. 

	/r$

---

From: Rob Stradling <[email-masked]>
Date: Wed, 19 Dec 2018 11:48:38 +0000

> FWIW, I have not noticed this, but maybe I'm looking in the wrong places.  On the other hand, nobody has raised the issue, nor made a pull request, with OpenSSL, so it can't be very popular yet.

Rich,

OpenSSL already has some support for Must-Staple:
https://github.com/openssl/openssl/pull/495

(Perhaps I've misunderstood what is "the issue" that "nobody has raised"?)

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 19 Dec 2018 13:13:46 +0000

>    https://github.com/openssl/openssl/pull/495
  
Oops, yeah, you're aright.  But it's not really documented and not hooked up to any popular server, is it?  OpenSSL can parse it, but that's about it.

---

From: Rob Stradling <[email-masked]>
Date: Wed, 19 Dec 2018 13:20:51 +0000

> Oops, yeah, you're aright.  But it's not really documented and not hooked up to any popular server, is it?  OpenSSL can parse it, but that's about it.

I suspect that's true.

What would hooking it up to a webserver look like, I wonder?  Would the 
webserver automatically enable OCSP stapling if the server cert 
indicates Must Staple?  Or would the webserver throw an error and refuse 
to start until the administrator has manually enabled OCSP stapling?

---

From: "T.Tributh" <[email-masked]>
Date: Wed, 19 Dec 2018 15:47:25 +0100

> to start until the administrator has manually enabled OCSP stapling?

Let me answer also some previously questions:

The problem exists on an exim server.
Exim is compiled with openssl 1.1.1a
Their is an 384bit-Ecdsa Certtificate from letsencrypt with Must-Staple
enabled in place.
The config adds a staple file with the status_response from
letsencrypt-OCSP server.

This part works very well without any issues.

To check the functionality, their was openssl commandline,
https://hardenize.com & Thunderbird as mailclient.
Thunderbird (recent version) refuses to establish a TLS connection, when
the stapling file is not added as an extension to the certificate.

OCSP-Must-Staple certificates work also very well on apache & nginx.
Nginx starts without any issue when stapling is not enabled, but Firefox
& Chrome will fail to connect with TLS errors.
Other browsers may behave similar.

Shall I open a ticket for openssl?
GnuTLS seems also not be able to staple the status_response when in
client mode.

Have I missed to clarify something?

Torsten

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 19 Dec 2018 17:19:05 +0000

Feel free.  One possible result is that the OpenSSL maintainers will say that this is more about integration for the different servers that accept client certificates. But it seems there is at least a documentation issue in OpenSSL.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 19 Dec 2018 13:40:43 -0500

> Shall I open a ticket for openssl?

Before you do that, it would be good to have clarity about the
specific behaviour you're seeing and how it differs from what you
want, and whether you want to see changes in the client or in the
server.

To that end, please post a "tshark" decode of a TLS 1.2 handshake
(thus avoiding encrypted handshake records that make much of the
TLS 1.3 handshake opaque, and your tshark may not yet support TLS
1.3).  With reference to that handshake explain what you'd like
to see happen differently on either the client or server end.

Capture a PCAP file of the traffic with

    # pcap=$(mktemp -t ocsp)
    # port=25 # or 587, 465, ...
    # tcpdump -s0 -w "${pcap}" tcp port "${port}"

extract traffic for a specific connection of interest
(you may need to look through the pcap interactively
looking for the connection you wanted).

    # conn=$(mktemp -t session)
    # client_port=... # provide the desired value
    # tcpdump -s0 -r "${pcap}" -w "${conn}" tcp port "${client_port}"

and post the decoded handshake from:

    # tshark -r "${conn}" -d "tcp.port==${port},ssl" -V |
	sed -ne '/^Secure Sockets Layer/,/^$/p'

Make sure to not rewrap the text.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 19 Dec 2018 14:15:16 -0500

> to see happen differently on either the client or server end.

That said, there is no mechanism for servers to request OCSP stapling
from clients in TLS 1.2 and below.  The TLS 1.2 CertificateRequest
message is a fixed structure with no room for extensions, such as
needed to request OCSP stapling from clients:

    https://tools.ietf.org/html/rfc5246#section-7.4.4

so if you're looking for an implementation of (and API to trigger)
the "status_request" extension for the TLS 1.3 CertificateRequest
message, that'd of course be specific to TLS 1.3, and would likely
be a new feature.

Support for OCSP stapling in OpenSSL is IIRC presently rather
anaemic.  An interface is provided for applications to examine and
validate OCSP messages, but nothing exists to ask the library to
do that internally.  The interfaces are subtle, and some applications
go through the motions, but get the details wrong.  IIRC curl (i.e.
libcurl) is one of the few places where the code looked right after
a cursory review.

So before the existing OCSP stapling support is extended in the
client-to-server direction, I'd rather see more robust support for
handling the OCSP status extension inside the library, so that
client applications can just ask for one of:

    * Mandatory OCSP stapling
    * Conditional OCSP stapling (based on must-staple in the certificate)
    * Ignore OCSP stapling (regardless of must-staple in the certificate)

and have all the details handled in the library.  Once that's done,
one might ask for the reverse direction in TLS 1.3.

-- 
	Viktor.

P.S. personal soapbox:

FWIW, OCSP is IMHO too fragile for too little benefit, and I've
steered well clear of it in Postfix.  OCSP has and will likely for
some time continue to have insecure fallback modes (the attacker
won't ask for a must-staple certificate, and most CAs will not
refuse to issue certificates without must-staple).  So what you get
is more opportunities to fail, and little meaningful security gain.

What I'd rather see is automation of certificate rotation, and
increasingly (decreasingly?) short certificate lifetimes as
with Let's Encrypt.  I think that in practice that's more beneficial
than OCSP.

---

From: Bill Frantz <[email-masked]>
Date: Wed, 19 Dec 2018 15:40:52 -0800

On 12/19/18 at 11:15 AM, [email-masked] (Viktor Dukhovni) wrote:

> with Let's Encrypt.

I think what you wanted to say was "increasingly shorter certificate lifetimes" :-)

Happy New Year - Bill

-----------------------------------------------------------------------
Bill Frantz        | Concurrency is hard. 12 out  | Periwinkle
(408)356-8506      | 10 programmers get it wrong. | 16345 Englewood Ave
www.pwpconsult.com |                - Jeff Frantz | Los Gatos, CA 95032