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] ESNI and Multi-CDN
>At least the client can tell the result is not going to work and disable ESNI. Whereas with addresses there is no indication anything is wrong, leading to potentially unrecoverable failure. So on the one hand, fallback to public ESNI seems likely and on the other hand, communication fails. Not much difference? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ESNI and Multi-CDN
On Wed, Dec 19, 2018 at 01:47:35PM -0500, Ben Schwartz wrote: > On Wed, Dec 19, 2018 at 6:28 AM Ilari Liusvaara > wrote: > > > > But one could do that by > > including address masks in ESNI records so clients can match ESNI > > keys to addresses without breaking database normalization. > > > > No, this doesn't work. If the client has a RRSET and an ESNI RRSET, > and the ESNI RRSET contains a mask that is not compatible with the > RRSET, then the client can tell that it has the wrong IP addresses, but it > has no way to acquire the right IP addresses. At least the client can tell the result is not going to work and disable ESNI. Whereas with addresses there is no indication anything is wrong, leading to potentially unrecoverable failure. -Ilari ___ 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] ESNI and Multi-CDN
On Tue, Dec 18, 2018 at 10:46:29PM +, Salz, Rich wrote: > Here is how it usually works. Not everyone necessarily does it this > way, but in our experience almost all of them do. > > 1. Sites use a CNAME, usually using a host-specific name. > > 2. Sometimes the CDN owns the DNS entry. There is also: 3. The site owns the zone apex DNS entry. And since it is zone apex, no CNAME can be used (yes, everything falls apart in practice if you do). So zone owner inserts a bunch of A/ records pointing at the CDN (or worse, CDNs). Fixing the above is a perennial topic. Proposals include CNAME-like mechanisms scoped to just addresses, and HTTP service discovery mechanisms (as most popular things other than HTTP already do service discovery). > Having the ESNI RRtype include optional a/quadA records is something > we have talked about internally. If so, it should be part of the RRtype > definition, of course. We came to the same idea. Of course, we will > then have to fight the intent to make this "generic server record" > data such as draft-nygren-service-bindings. :) The only use for addresses in ESNI records I can come up with is scoping keys to practicular addresses. But one could do that by including address masks in ESNI records so clients can match ESNI keys to addresses without breaking database normalization. And if one is dealing with the third case above, the solutions are basically service discovery. And then one presumably would want it to be service-specific (as there are other rarer services that also lack discovery besides HTTP). > DNS is a strange and wondrous beast, like a bear riding a bicycle. > We should make sure that DNS folks are heavily involved in this draft. Here are some tips: - If you have name references, encode those in DNS wire format and preferably put them first, so that recursives can follow them and include records they think are helpful. - Do not assume the above happens (but do assume it may happen). Client has to act as a backstop. - DNS is 8-bit clean just fine with new types. - Records do not need explicit terminators. - There can be many records for each type on the same owner. - The unit of atomicity is set of records with the same (owner, class, type) combo. - The 64kB limit is not just for individual record but whole set of records with (owner, class, type). And to be safe, limit it to 63.5kB minus 12 bytes per record. The following are Bad Idea: - Using type or class ANY (a.k.a. *). - Type ANY does the wrong thing. - Class ANY does completely nonsensical thing. - Defining a new class. - Using class other than IN (Internet). - If you use labels, using lots of different labels at outermost level. - Putting anything into new type that DNS can not treat as a blob. - Assuming authoritatives do anything smart. - Assuming authoritatives follow any references. - Assuming different types are in any way atomic w.r.t. each other. - Copying TXT record wire format. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
