Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Dec 2017 04:08:29 +0000
From:      Matthew Finkel <matthew.finkel@gmail.com>
To:        Karl Denninger <karl@denninger.net>
Cc:        freebsd-security@freebsd.org
Subject:   Re: http subversion URLs should be discontinued in favor of https URLs
Message-ID:  <20171212040829.2nn6etffkcentglm@localhost>
In-Reply-To: <63cb70da-4e6f-af20-af3a-9741afaf03b9@denninger.net>
References:  <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> <CAC0r6X94N4Dv=droSC=B8ri-sH2eb9gJgdvpVqwPt0pSenXfog@mail.gmail.com> <slrnp2t7rl.nqg.naddy@lorvorc.mips.inka.de> <632cd44e-2072-8abf-ef3c-86701881e723@whitewinterwolf.com> <20171211180839.ycc7es5ekstq44gn@localhost> <63cb70da-4e6f-af20-af3a-9741afaf03b9@denninger.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 11, 2017 at 12:18:27PM -0600, Karl Denninger wrote:
> 
> On 12/11/2017 12:08, Matthew Finkel wrote:
> > On Mon, Dec 11, 2017 at 05:34:48PM +0100, WhiteWinterWolf wrote:
> >
> >> 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.
> It is NOT forced.  You can use SVN now over http OR https.

Yes, sorry, my mistake. I saw portsnap only uses http (with signed
snapshots from mirrors), and I misread the website documentation (where
it does specify https for `svn checkout https://[...]`). And no, I
didn't look at the ticket first.

> >> 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.
> Again, let's target the actual problem.
> 
> Advocating the FORCING of https is IMHO utterly ridiculous for the
> reasons I pointed out.

I understand why some people believe a resource should be available over
http. It makes life easier in many situations. However, Yuri is correct,
serving svn with http over the Internet is dangerous and should be
discontinued. It is too easy for someone to make a mistake and checkout
the ports repo over http (if they type it by hand instead of copying and
pasting it from the handbook). That being said, if users can checkout
the svn repos over an onion service, then the threat of tampering with
the traffic in-transit is mitigated.

The simple and undeniable fact of this matter is users make mistakes. As
it was already mentioned multiple times, the recent trend by
organizations on this topic is disabling access over plaintext HTTP
entirely. It's obvious FreeBSD are unwilling to follow this pattern
based on the presumption "That isn't tenable, far too many people around
the world have limited internet access as it is."[0]

Sure.

[0] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224097#c3

> 
> Today you CAN use https with svn if you wish.  You are not *forced* to. 
> There are good reasons not to, including caching.  The problem with not
> knowing if what you got is authentic and not tampered with is simply not
> resolved by forcing https; it's an out-of-scope hack that fails to
> target the actual issue.

Correct. TLS accomplishes a different goal, it does not provide any
guarantee about the whether the data is authentic. It simply provides
assurance the data was not tampered in transit and it significantly
increases the probability none of the intermediate parties learned what
data was transmitted.

> 
> A forced election of something that doesn't actually solve the problem
> is IMHO a political argument rather than a technical one.  The issue of
> potentially-tampered-with source code not only can't be dealt with
> correctly through the use of https (at least not with the public CA
> infrastructure that "everyone" relies on for "pedestrian" https) there
> ARE other means of dealing with it correctly that do not require using
> https.

Yes. On the other hand, code authenticity isn't the reason software
projects use TLS. I fully agree another mechanism should be put in place
for this. Whether hacking a Merkle Hash Tree on top of SVN is the correct
decision is an entirely different discussion.

> 
> That's where attention should be focused.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171212040829.2nn6etffkcentglm>