From owner-freebsd-security@freebsd.org Mon Dec 11 18:08:43 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3574E99388 for ; Mon, 11 Dec 2017 18:08:43 +0000 (UTC) (envelope-from matthew.finkel@gmail.com) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5FC6771171 for ; Mon, 11 Dec 2017 18:08:43 +0000 (UTC) (envelope-from matthew.finkel@gmail.com) Received: by mail-qt0-x233.google.com with SMTP id k19so40801687qtj.6 for ; Mon, 11 Dec 2017 10:08:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=YU7UukiIB4D6GubZX6WlTW0TKKEOM0f9Hxh8Hp7lpXc=; b=DGDoCc/MYCGHvvVJXsOFmRoNAxTu8TVSRdJ/xdpfiYgvDzMNI7a6k+urKWNdsCBzvo JAdFp/6ZIeCz3i73leS8fGh5UyWA1a0rIGpFkHkaIuzDaXLGcuedBdRkwraU/TYBNiZK QgMbyRe59RADViDKhpxObXnq4pmBGAnkxHKxECmR6xZLh1G8hMFnzs+TA3uOmGLblVcF WQyHmZUph+VQ9gr9b3VjPgUs3XKWdrzbRutCbXZcH0/ffzcLZJczO1qwdMFKj6PAvrmB nCXOI2nXlFybbo0QpjeTJAtYt5zj2DOkYTOO2hpuA7vHIcObvtT7Rqzy+RBUTQMXmULQ b0IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=YU7UukiIB4D6GubZX6WlTW0TKKEOM0f9Hxh8Hp7lpXc=; b=YTKu2Fs6BQdAKqdR8OqMrkZqh5OfOJrmjFUp0mCCQ95XWW6+dsi2Eex1p+TZuho9T6 kWxBfUW4Ru1Hd38TEusoY0aRfkmYPDypBcXIjN9wFxi6HSrRlLcWiwhdiGAqj5smaDCg aORrXujcGiFGelSzSazmEHpj82YrDdJMmXrDqRUVvVE6D4+20x/VIqYt0OUkHR3kKywc XnodVPytuFKX/rWVL2Bx8PoWfPkL0vFkgG8qZe8LMJqursxPz69pd1w9f51pqboBhFyw nbaYuC1LfOuioq7Ws3ZUV4qeI1TYG9d5SCOw047Wj9IBZnjoTMIgaS9xxwohJINsDR20 WonQ== X-Gm-Message-State: AKGB3mL31FercnnKbI5vytzC2EoKKnzWC5VZ3CyNxSuyTqWpGBTAQYxr pHtaYJkMgLwZtk7mLwh5Hjk= X-Google-Smtp-Source: ACJfBot0kWRTRAXF7liuDSNAxfx8vlNFK6DeeymxKt1MXGKy5GxpO/tQr4LrtlhL67WeD86v+vq0aw== X-Received: by 10.55.169.5 with SMTP id s5mr1755787qke.79.1513015722317; Mon, 11 Dec 2017 10:08:42 -0800 (PST) Received: from localhost (ool-18e477b0.dyn.optonline.net. [24.228.119.176]) by smtp.gmail.com with ESMTPSA id k34sm4558000qtk.5.2017.12.11.10.08.41 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 11 Dec 2017 10:08:41 -0800 (PST) From: Matthew Finkel X-Google-Original-From: Matthew Finkel Date: Mon, 11 Dec 2017 18:08:39 +0000 To: WhiteWinterWolf Cc: Christian Weisgerber , freebsd-security@freebsd.org, karl@denninger.net Subject: Re: http subversion URLs should be discontinued in favor of https URLs Message-ID: <20171211180839.ycc7es5ekstq44gn@localhost> References: <8788fb0d-4ee9-968a-1e33-e3bd84ffb892@heuristicsystems.com.au> <20171205220849.GH9701@gmail.com> <24153.1512513836@critter.freebsd.dk> <1C30FE91-753A-47A4-9B33-481184F853E1@tetlows.org> <867etyzlad.fsf@desk.des.no> <1291.1512658230@critter.freebsd.dk> <2a8d9a0a-7a64-2dde-4e53-77ee52632846@tjvarghese.com> <632cd44e-2072-8abf-ef3c-86701881e723@whitewinterwolf.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <632cd44e-2072-8abf-ef3c-86701881e723@whitewinterwolf.com> User-Agent: NeoMutt/20170113 (1.7.2) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 18:08:43 -0000 On Mon, Dec 11, 2017 at 05:34:48PM +0100, WhiteWinterWolf wrote: > Hi, > > Le 11/12/2017 à 16:08, Christian Weisgerber a écrit : > > Do users actually exist who have access to http but not to https? > > I don't know about users, but caching is not possible anymore as soon > you use end-to-end HTTPS. Why must caching be at a MiTM? Why not simply have a subversion mirror on the same network? It is utterly unacceptable that "caching" is a reason why encryption is not considered as an option. > > This is a reason why I personally like software and system updates to be > served through HTTP instead of HTTPS. You don't need to fetch the same > update for each environment each time from the remote vendor's system, > you just need them to be somehow signed by him to ensure their authenticity. That's fine, you should have this ability if you understand the risks/consequences, but this should not be forced on other users. > > This was just to give an example of why one would prefer to use HTTP > over HTTPS, and how as highlighted by Karl Denninger a system which does > too much may actually be harmful. I disagree with this. The importance of message confidentiality doesn't magically disappear because someone is retrieving public information. The intermediate ISPs do not have the privilege of knowing what an end user is sending or receiving, we should not give them this information. They are simply passing along those packets based on aggregated route summaries, but no one should blindly trust these companies. The Internet is not a benevolent series of tubes - intentionally endangering users by not providing a mechanism for cryptographic authentication and checking data integrity is absolutely unacceptable. Everyone should have the option of hiding from intermediate parties what information they are retrieiving, verifying the information they received was not tampered in-transit, and verifying the information they received was not tampered on-disk prior to transmission. I also advocate for preventing the tracking of user activities, but at a minimum please provide message authentication and message confidentiality. While I find this entire discussion ridiculous, because I can't believe a software project is actually debating the necessity of secure code transmission, removing the option of an unauthenticated connection to the subversion server is not necessary, but imposing this on every user is completely irresponsible. > > When you need signature, then apply signature, don't add encryption, > tunneling, dynamic cipher suites negotiation, session keys exchange and > so on as overhead. Yes, TLS is a bloated protocal and most of it is not necessary, but are you saying the additional ~100 millisecond latency with its ~5KB handshake is too much overhead for downloading subversion updates? We are talking about 7 additional packets. This is not too much, even on a terrible Internet connection with high packet loss. TLS does not authenticate the revisions a user downloads, it's remarkable subversion still does not provide this ability after 16 years. > Regards, > Simon. > > -- > WhiteWinterWolf > https://www.whitewinterwolf.com