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. _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
