Re: [TLS] OCSP stapling problem
On 12/19/18 at 11:15 AM, ietf-d...@dukhovni.org (Viktor Dukhovni) wrote: > What I'd rather see is automation of certificate rotation, and > increasingly (decreasingly?) short certificate lifetimes as > 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] OCSP stapling problem
On Wed, Dec 19, 2018 at 01:40:43PM -0500, Viktor Dukhovni wrote: > 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. 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] OCSP stapling problem
On Wed, Dec 19, 2018 at 03:47:25PM +0100, T.Tributh wrote:
> 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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] OCSP stapling problem
>Shall I open a ticket for openssl? GnuTLS seems also not be able to staple the status_response when in client mode. 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] OCSP stapling problem
Am 19.12.18 um 14:20 schrieb Rob Stradling: > On 19/12/2018 13:13, Salz, Rich wrote: >>> OpenSSL already has some support for Must-Staple: >>> 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. > > 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? > 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] OCSP stapling problem
On 19/12/2018 13:13, Salz, Rich wrote: >> OpenSSL already has some support for Must-Staple: >> 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. 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? -- Rob Stradling Senior Research & Development Scientist Sectigo Limited ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] OCSP stapling problem
>OpenSSL already has some support for Must-Staple: >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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] OCSP stapling problem
On 19/12/2018 01:18, Salz, Rich wrote: >> The "exim" server claims to support stapling (for incoming connections) > > Yes, which isn't what I asked. > >> 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. > > 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. 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] OCSP stapling problem
>The "exim" server claims to support stapling (for incoming connections) Yes, which isn't what I asked. >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. 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$ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] OCSP stapling problem
Am 18.12.18 um 15:57 schrieb Salz, Rich: > 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] OCSP stapling problem
Does the server claim to support must-staple? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
