Re: [Doh] DoH and PAC
Guoye Zhang <guoye_zhang@apple.com> Tue, 06 September 2022 21:43 UTC
Return-Path: <guoye_zhang@apple.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD056C14CE22 for <doh@ietfa.amsl.com>; Tue, 6 Sep 2022 14:43:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.676
X-Spam-Level:
X-Spam-Status: No, score=-7.676 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.571, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxxXyWQCxLqS for <doh@ietfa.amsl.com>; Tue, 6 Sep 2022 14:43:11 -0700 (PDT)
Received: from rn-mailsvcp-ppex-lapp24.apple.com (rn-mailsvcp-ppex-lapp24.rno.apple.com [17.179.253.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21009C14F72D for <doh@ietf.org>; Tue, 6 Sep 2022 14:43:11 -0700 (PDT)
Received: from pps.filterd (rn-mailsvcp-ppex-lapp24.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp24.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 286LefSd006937; Tue, 6 Sep 2022 14:43:08 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=Jh6X/LXPUI0seYUki59rwUtr8Coc/q2XBtVZcZn1+BI=; b=wZnS0+0l+1HDtgjXutzQs3vXSra0Xk2T5G/Sm5XiVAtXQVIVB1t/HzqGl7f6sUIkPlf4 fxGggtEOTWdQPULLpuKdPv4vbsSU7dvn3J9ESJd93/v1/wVSZ/xkuTV1jB5me79MzcdM 6KTYBaA7lUW0p+hGRxLTWz6DGp6+FWUWCB7QBvCgFGR2SZQ9Ojo+e8S4gTqaF5GeN3zr Degls67OCDvFmis/AeauZlXHgYtCWlk/oNb1NXfr5xUHbMqAd5lXezajKvX1Z9xt0zYu Is1z1yfco/nj4aaDQFpj34jJHI0wppj5NyIT6H6ULSHrreHFuYS3T8aoQuv8G+nOzt4o 1w==
Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by rn-mailsvcp-ppex-lapp24.rno.apple.com with ESMTP id 3jc4h9n0dg-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 06 Sep 2022 14:43:08 -0700
Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.19.20220711 64bit (built Jul 11 2022)) with ESMTPS id <0RHT00F1W5NVBEL0@rn-mailsvcp-mta-lapp04.rno.apple.com>; Tue, 06 Sep 2022 14:43:07 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.19.20220711 64bit (built Jul 11 2022)) id <0RHT00J005IV0H00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 06 Sep 2022 14:43:07 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 6785de579c47fb093a8e94ae65c3a417
X-Va-E-CD: 9002f7af58af178137d87fee3705cf3b
X-Va-R-CD: 7efe762b0cba86912f1e01c743981a41
X-Va-CD: 0
X-Va-ID: f1147350-2c5d-4c73-ab3c-9b455e2882bf
X-V-A:
X-V-T-CD: 6785de579c47fb093a8e94ae65c3a417
X-V-E-CD: 9002f7af58af178137d87fee3705cf3b
X-V-R-CD: 7efe762b0cba86912f1e01c743981a41
X-V-CD: 0
X-V-ID: c404ff37-aa05-4aef-a957-478419fdae2d
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.528, 18.0.895 definitions=2022-09-06_09:2022-09-06, 2022-09-06 signatures=0
Received: from smtpclient.apple (unknown [17.192.40.234]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.19.20220711 64bit (built Jul 11 2022)) with ESMTPSA id <0RHT00QKF5NVDJ00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 06 Sep 2022 14:43:07 -0700 (PDT)
From: Guoye Zhang <guoye_zhang@apple.com>
Message-id: <850C29AA-5966-4550-B47F-7DD8FC6F2904@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_C2FADC5E-F82E-4ABF-ABBF-BF27FD5A851D"
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3731.200.64\))
Date: Tue, 06 Sep 2022 14:42:56 -0700
In-reply-to: <CACQYfi+hc0PYiPqeQwWb-Wvzq451ttaaejoc2X9Ta06gHVZVDA@mail.gmail.com>
Cc: ietf-http-wg <ietf-http-wg@w3.org>, doh@ietf.org
To: Valentin Gosu <valentin.gosu@gmail.com>
References: <A896A2AB-8E65-4C63-BE6A-B4086E14F51E@apple.com> <CACQYfi+hc0PYiPqeQwWb-Wvzq451ttaaejoc2X9Ta06gHVZVDA@mail.gmail.com>
X-Mailer: Apple Mail (2.3731.200.64)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.528, 18.0.895 definitions=2022-09-06_09:2022-09-06, 2022-09-06 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/SqQCTU5ye8kVB-dgKDvWX2KLxAA>
Subject: Re: [Doh] DoH and PAC
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Sep 2022 21:43:14 -0000
Thank you for letting me know! Good to learn that this is the same behavior as FireFox. Guoye > On Sep 6, 2022, at 03:54, Valentin Gosu <valentin.gosu@gmail.com> wrote: > > Hi Guoye, > > We had the same problem in Firefox, and our solution was the same [1]. Given the way PAC is used I think not using DoH makes sense. > We also had a similar deadlock with OCSP [2], where you need to wait for the OCSP check for the DoH server's certificate, but that OCSP check also needs to resolve DNS. > > Cheers! > > [1] https://searchfox.org/mozilla-central/rev/3f9dcc016dd96a0336d46f4a19aeabdd796ab9e9/netwerk/base/ProxyAutoConfig.cpp#237-242 > [2] https://searchfox.org/mozilla-central/rev/3f9dcc016dd96a0336d46f4a19aeabdd796ab9e9/netwerk/protocol/http/HttpBaseChannel.cpp#488-494 > > On Mon, 5 Sept 2022 at 20:06, Guoye Zhang <guoye_zhang=40apple.com@dmarc.ietf.org <mailto:40apple.com@dmarc.ietf.org>> wrote: >> Hi, >> >> Recently, we identified an issue that DNS over HTTPS (DoH) and Proxy Auto-Configuration (PAC) deadlock with each other. >> >> To briefly introduce what they are: As its name indicates, DoH is DNS queries over HTTPS; PAC is a JavaScript function where given a URL, it tells you whether we should go over a proxy or connect directly. >> >> The problem arises when both DoH and PAC are configured on the system. In order to fetch an HTTP resource, we first need to consult the PAC script. The PAC script is usually fetched from an HTTP URL and we are smart enough not to consult PAC script for itself. However, fetching the script does require DNS resolution which goes over DoH. DoH creates an HTTP connection and consults PAC and here is where it deadlocks. Another case is where PAC scripts can also manually initiate DNS resolution through JavaScript APIs like `dnsResolve()`. >> >> DoH depends on PAC and PAC depends on DoH. We have to break the chain somewhere, and the decision was to never use DoH in PAC: Fetching PAC script and JavaScript DNS APIs inside PAC always use cleartext DNS. >> >> Are there any other HTTP client implementations facing the same issue? What are your solutions? >> >> Thanks, >> Guoye Zhang >> _______________________________________________ >> Doh mailing list >> Doh@ietf.org <mailto:Doh@ietf.org> >> https://www.ietf.org/mailman/listinfo/doh
- [Doh] DoH and PAC Guoye Zhang
- Re: [Doh] DoH and PAC Valentin Gosu
- Re: [Doh] DoH and PAC Guoye Zhang