freebsd security - Dec 2017 - http subversion URLs should be discontinued in favor of https URLs

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.

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.

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.

When you need signature, then apply signature, don't add encryption,
tunneling, dynamic cipher suites negotiation, session keys exchange and
so on as overhead.

Regards,
Simon.

-- 
WhiteWinterWolf
https://www.whitewinterwolf.com

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