Matthew Finkel
2017-Dec-11 18:08 UTC
http subversion URLs should be discontinued in favor of https URLs
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
Karl Denninger
2017-Dec-11 18:18 UTC
http subversion URLs should be discontinued in favor of https URLs
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.>> 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. 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. 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. That's where attention should be focused. -- Karl Denninger karl at denninger.net <mailto:karl at denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4897 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20171211/f48fe8f4/attachment.bin>