From nobody Mon Apr 22 09:16:17 2024 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VNKPS6CQXz5JhTT; Mon, 22 Apr 2024 09:16:28 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VNKPR5M1Mz4GFp; Mon, 22 Apr 2024 09:16:27 +0000 (UTC) (envelope-from freebsd@omnilan.de) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@omnilan.de designates 2a00:e10:2800::a130 as permitted sender) smtp.mailfrom=freebsd@omnilan.de Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800:0:0:0:0:a135]) by mx0.gentlemail.de (8.15.2/8.15.2) with ESMTP id 43M9GIaJ011306; Mon, 22 Apr 2024 11:16:18 +0200 (CEST) (envelope-from freebsd@omnilan.de) X-Authentication-Warning: mx0.gentlemail.de: Host ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800:0:0:0:0:a135] claimed to be mh0.gentlemail.de Received: from [172.21.3.1] (s1.omnilan.de [217.91.127.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 097F6E68; Mon, 22 Apr 2024 11:16:18 +0200 (CEST) Content-Type: multipart/alternative; boundary="------------Djtb7k34W0VVt4JFbvQmeUvu" Message-ID: <04ea81b1-c6a2-4dcd-921c-729fb5f5f944@omnilan.de> Date: Mon, 22 Apr 2024 11:16:17 +0200 List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: git: 9c59988175ff - main - bsdinstall: prefer HTTP To: Shawn Webb , Philip Paeps Cc: Ronald Klop , dev-commits-src-main@freebsd.org, dev-commits-src-all@freebsd.org References: <901819076.6938.1708005969197@localhost> <7B54789B-90DD-4A85-8E2B-84E13DAE54B5@freebsd.org> <4A6EC239-4B9B-442C-ACFB-8F99A951630A@freebsd.org> Content-Language: en-US From: Harry Schmalzbauer Organization: OmniLAN In-Reply-To: X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.27 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.979]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; HAS_ORG_HEADER(0.00)[]; ASN(0.00)[asn:61157, ipnet:2a00:e10:2800::/38, country:DE]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; HAS_XAW(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[dev-commits-src-main@freebsd.org,dev-commits-src-all@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[omnilan.de]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4VNKPR5M1Mz4GFp This is a multi-part message in MIME format. --------------Djtb7k34W0VVt4JFbvQmeUvu Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2024-02-15 15:55, Shawn Webb wrote: ... >>> I'm curious to learn why you chose http:// rather than https://. >> Because https:// only adds work. And work is heat. >> >> bsdinstall uses the MANIFEST to confirm integrity. >> >> If your bsdinstall and MANIFEST are from a trustworthy source, anything >> downloaded over http:// will be trustworthy. Just as trustworthy, in fact, >> as anything downloaded over ftp://. > There is the problem of metadata leakage, which HTTPS helps to address > (though not completely.) The connection itself leaks the significant part, no matter if it's HTTP or HTTPS. Anything else from the header, which is plain on HTTP vs. HTTPS, doesn't tell much more: A 500MB stream from ftp.freebsd.org let's anyone guess you're downloading a setup image.  Which one exactly isn't hurting privacy imho, nor which agent is in use etc... I totally agree that general TLSing is a bad idea. Another advantage of HTTP (plain) vs. HTTPS is that proxies can easily cache, saving load from the net and the servers alike. (if intercepting beforehand anyways - which is 'standard' wherever I access the internet @work! - caching would work too of course, but in real world, the mitm-boxes rarely are proxies. Even small sized companies utilize F.ate/P.lto SSL-inspection feature - cheap and easy to turn on.  If TLSing madness wouldn't have caused encypted weather/newspaper/ads, maybe we wouldn't have precautionary man-in-the-middle boxes all over the places - which do inspect banking and everything else if not carefully extra ruled out) Just my 2 ¢ --------------Djtb7k34W0VVt4JFbvQmeUvu Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 2024-02-15 15:55, Shawn Webb wrote:
... 
I'm curious to learn why you chose http:// rather than https://.

Because https:// only adds work.  And work is heat.

bsdinstall uses the MANIFEST to confirm integrity.

If your bsdinstall and MANIFEST are from a trustworthy source, anything
downloaded over http:// will be trustworthy.  Just as trustworthy, in fact,
as anything downloaded over ftp://.

There is the problem of metadata leakage, which HTTPS helps to address
(though not completely.)


The connection itself leaks the significant part, no matter if it's HTTP or HTTPS.
Anything else from the header, which is plain on HTTP vs. HTTPS, doesn't tell much more: A 500MB stream from ftp.freebsd.org let's anyone guess you're downloading a setup image.  Which one exactly isn't hurting privacy imho, nor which agent is in use etc...

I totally agree that general TLSing is a bad idea.
Another advantage of HTTP (plain) vs. HTTPS is that proxies can easily cache, saving load from the net and the servers alike.

(if intercepting beforehand anyways - which is 'standard' wherever I access the internet @work! - caching would work too of course, but in real world, the mitm-boxes rarely are proxies. Even small sized companies utilize F.ate/P.lto SSL-inspection feature - cheap and easy to turn on.  If TLSing madness wouldn't have caused encypted weather/newspaper/ads, maybe we wouldn't have precautionary man-in-the-middle boxes all over the places - which do inspect banking and everything else if not carefully extra ruled out)

Just my 2 ¢

--------------Djtb7k34W0VVt4JFbvQmeUvu--