Re: [TLS] OCSP stapling problem

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 19 December 2018 18:40 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C712130EB4 for <tls@ietfa.amsl.com>; Wed, 19 Dec 2018 10:40:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OY2xUq-wt-oR for <tls@ietfa.amsl.com>; Wed, 19 Dec 2018 10:40:45 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D981130EAE for <tls@ietf.org>; Wed, 19 Dec 2018 10:40:45 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 7D30D190BC; Wed, 19 Dec 2018 13:40:43 -0500 (EST)
Date: Wed, 19 Dec 2018 13:40:43 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20181219184043.GA79754@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <20181215162408.55DD3130DCD@ietfa.amsl.com> <597308EA-C2A0-4BC8-9BFF-AAC4E036F470@akamai.com> <20181218163448.2B642131170@ietfa.amsl.com> <043B351E-28A3-4981-8555-9D950FA2FF98@akamai.com> <8ee97d12-606c-f7a7-09a1-eecdd84807d1@sectigo.com> <B05F4EC2-9B1C-4587-B29F-4C8644476C16@akamai.com> <9314a20a-fe11-825a-454f-20f3104d4b3c@sectigo.com> <20181219144731.8F555124BE5@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20181219144731.8F555124BE5@ietfa.amsl.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/43Ozxi7ztdbFrW4drBiaBcwKPRM>
Subject: Re: [TLS] OCSP stapling problem
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Dec 2018 18:40:47 -0000

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.