Peter Wemm
2017-Dec-13 21:29 UTC
http subversion URLs should be discontinued in favor of https URLs
On 12/12/17 5:38 PM, Yuri wrote:> On 12/12/17 16:37, Peter Wemm wrote: >> I think you're missing the point.? It is a sad reality that SSL/TLS >> corporate >> (and ISP) MITM exists and is enforced on a larger scale than we'd like.? But >> it is there, and when mandated/enforced you have to go through the MITM >> appliance, or not connect at all.? Private CA's generally break those >> appliances - an unfortunate FreeBSD user in this situation is cut off. >> How is >> this better? > > > This is certainly better for users because it informs the user. Now he has > a choice to use a special override key to use MITMed https anyway or > refuse, vs. with http he is not informed.You misunderstand the problem. A well-behaving corporate with TLS MITM will *block* connections to the freebsd-ca signed services as they will fail it's validation. The user is left with: * can't connect on 443 (proxy blocks failed validations), or * can't connect on 80 (because you don't like people having options). .. which leads to stop using FreeBSD. -- Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com; KI6FJV
Gordon Tetlow
2017-Dec-15 05:04 UTC
http subversion URLs should be discontinued in favor of https URLs
On Wed, Dec 13, 2017 at 01:29:26PM -0800, Peter Wemm wrote:> On 12/12/17 5:38 PM, Yuri wrote: > > On 12/12/17 16:37, Peter Wemm wrote: > >> I think you're missing the point.? It is a sad reality that SSL/TLS > >> corporate > >> (and ISP) MITM exists and is enforced on a larger scale than we'd like.? But > >> it is there, and when mandated/enforced you have to go through the MITM > >> appliance, or not connect at all.? Private CA's generally break those > >> appliances - an unfortunate FreeBSD user in this situation is cut off. > >> How is > >> this better? > > > > > > This is certainly better for users because it informs the user. Now he has > > a choice to use a special override key to use MITMed https anyway or > > refuse, vs. with http he is not informed. > > You misunderstand the problem. > > A well-behaving corporate with TLS MITM will *block* connections to the > freebsd-ca signed services as they will fail it's validation. > > The user is left with: > * can't connect on 443 (proxy blocks failed validations), or > * can't connect on 80 (because you don't like people having options). > .. which leads to stop using FreeBSD.I'm going to put my SO hat on here for a second, put on the flame retardant suit, and make the following statement: I want to move the default for svn to be HTTPS. This would mean setting up a redirect on http://svn.freebsd.org -> https://svn.freebsd.org. For those people that are unable (for whatever reason) to use HTTPS, we can make a vhost they are able to use HTTP on. I would suggest something like: http://i-love-waffles-and-svn-over-http.freebsd.org. (Waffles are awesome.) The CA for this HTTPS server should be the standard publicly trusted CA we use for everything (Let's Encrypt). We can debate the brokeness of the current CA system (and I completely agree there is a ton of brokeness there), but it is the system we have today. We should follow industry best practice here. Running a Root CA brings a huge amount of baggage and we are not mature enough in policy to build in a manner that would align with established practice for running a Root CA. Gordon