For example, http://svn.freebsd.org/base With http there is nothing there to stop MITM attack. Somebody may get malware with sources through the MITMed http. FreeBSD should follow the Wikipedia's approach, and discontinue http system-wide.
We have HTTPS available (https://svn.freebsd.org/) and where possible we recommend HTTPS. We could research redirecting svn, and see how the svn binary copes with it, but other than that I am not sure exactly what you are asking for.
> We could research redirecting svn, and see how the svn binary copes with it, but other than that I am not sure exactly what you are asking for. As long as http is available, some people might get hurt. I am asking to discontinue http entirely, so that the potential attack vector is eliminated.
That isn't tenable, far too many people around the world have limited internet access as it is.
(In reply to Brad Davis from comment #3) https doesn't limit anybody's access at all. It's just a different, more secure protocol.
It does if you are on a network that restricts outbound ports.
Http proxies tunnel https, so https doesn't limit connectivity in this case.
That cannot be said for all networks, so it is a moot point.
(In reply to Brad Davis from comment #5) Which then means those networks can't access half the internet already, since more and more of it is unconditionally redirecting to https. https is not just for "logins" and "passwords", it ensures no data has been (easily) modified in flight, which is especially important for javascripts. The reasons not to deprecate http given here are not making any sense. I'm in support of a redir to https wherever possible.
(In reply to Vladimir Krstulja from comment #8) > I'm in support of a redir to https wherever possible. Redirect isn't good enough since it too can be subject to MITM.
If HTTPS is avail, then people should pick that or we should prefer it, but unconditionally deciding for someone else is, I think against the spirit of the project.
(In reply to Brad Davis from comment #10) People don't necessarily choose this knowingly. They can choose this by mistake, oversight, or just assuming that it's okay since it is offered by the project.
For example: Tor is popular on FreeBSD. It's easy to get into thinking that accessing internet through Tor is more secure. At the same time, people synchronize subversion repositories on FreeBSD a lot. Syncing an http repository through Tor allows the operator of the Tor exit node, some random person, to alter the client's source code tree. https is free of this particular vulnerability scenario. There is even the toolkit for MITM attacks called EvilGrade: https://github.com/infobyte/evilgrade It allows to substitute results of http queries based on regular expressions, and to serve malicious content when certain conditions are met.
I'm going to research this a bit more to understand how we deliver bits to our users and the risk for the different delivery mechanisms.
Wether we provide HTTP or not is irrelevant to people being able to do MITM with it. If one can do a MITM attack on some network streams, and can trick the user into using HTTP, it does not matter at all if *we* provide HTTP as long as the person doing the MITM does. So, all in all, there is nothing we can do about it.
(In reply to Mathieu Arnold from comment #14) Mathieu, https can't be redirected to http. This would be a security violation. Any client that allows that has a security problem that needs to be fixed.
Disabling HTTP entirely may not be an option, but making sure that HTTPS is configured to the extent feasible to make MITM harder is achievable - and in at least some instances, already done. Since svn.freebsd.org is geographically distributed via svnmir.geo.freebsd.org, different instances may have different TLS configurations, but here's the Qualys SSL Labs analysis of the NYI mirror: https://www.ssllabs.com/ssltest/analyze.html?d=svn.freebsd.org&s=96.47.72.69&latest Its TLS configuration is quite good: * HSTS is lacking, but this makes sense given that the still providing HTTP is one of the goals. * They're publishing CAA records, adoption of which is still in its early stages. * They still support TLS 1.0 and 1.1 (so called "early TLS"), which has recently been deprecated by PCI. But to support a wide variety of clients, this will still be needed for some time to come. * HPKP is also possible and might help, but has been largely deprecated because it can also be used against a site by an attacker: https://blog.qualys.com/ssllabs/2016/09/06/is-http-public-key-pinning-dead * There is no TLS 1.3 support, but this is also understandable. The rise of TLS 1.3 should also make it at least somewhat harder to MITM, but wide adoption is still forthcoming (and the standard is still not finalized). In short, it looks to me as though at least the NYI mirror is doing a great job of keeping up with modern understanding of best HTTPS practices *given that HTTP must still be provided*. As has already been hashed out on freebsd-security, these things do not prevent nation-state MITM. But some of them could raise an attacker's cost to MITM. Brainstorming a couple of options: 1. It might be useful to come up with a way to let users opt in in some way to force the client side to A) require HTTPS and B) only allow specific CAs. An interesting compromise might be to provide a separate hostname (like "svn-tls.freebsd.org") that is configured to require HTTPS via HSTS and the other mechanisms. A one-line config change on the client side could let the user opt in - eventually, it could even be a question asked at install time. 2. Separately signing the code would also be interesting, but also could cause significant additional overhead. If it were up to me, I'd say there would be value in laying in the groundwork for option 1, as time permits.
In other words: Forcing *all* users to use HTTPS may not be the FreeBSD way, but supporting users *who want to require it for themselves* is.
(In reply to Royce Williams from comment #17) *No!* This is absolutely crazy to allow http which is fundamentally insecure.
Yuri, please let me try to negotiate a compromise here. I'm arguing for options, and a gradual transition. in which FreeBSD let people opt in to HTTPS - and perhaps, eventually, we might even be able to switch it so that HTTPS is the default, and HTTP is something that users can opt into if they need to. But we would need to take other steps to get there first. We cannot just switch to 100% HTTPS by default immediately. This issue, and the thread on freebsd-security, should make it clear why HTTPS is not a cure-all, and why HTTP is still sometimes needed at this time.
Yuri, unless you promise to solve all issues for all people on the world who might have a problem by this step, you please consider not putting in demands. i.e. this statement: "Http proxies tunnel https, so https doesn't limit connectivity in this case." is quite, well, uneducated and not helpful at all. Again, if people were to trust you on that, you'd better be ready to clean up the pile of garbage you create. With that being said, a good first step would be to ensure all defaults point to https. Last time I looked into this (and reported) some of the mirrors had invalid certs, too - i.e. wrong hostname. I think I even found the client didn't even validate the cert. All that should be fixed, without discussion and with priority. Once it's useable worldwide. Then make it clear it's discouraged to use http. With the announcement, leave an address for people who want to input pro http. I, too, would hope there are none. Then look at the remaining traffic. IF there is any, try forwarding it, and analyse how many % fail to follow. Assume it won't work for those. Personally I'd recommend keeping a non-default url around for http-only people who really want and need this. Everyone else should end up at https, without doubt. As they should have since quite some time. It would be wonderful if anything regarding defaults could be secured as soon as possible. It should have been done long ago and has been upsetting since a long time. Let's just skip the part where we produce a pile of collateral damage.
At a glance: does bug 224229 (closed fixed 2018-01-13) significantly change things here? > Changed http->https for subversion access in documentation