On 12/11/2017 09:16, Shawn Webb wrote: > On Mon, Dec 11, 2017 at 03:08:37PM -0000, Christian Weisgerber wrote: >> On 2017-12-08, Luke Crooks <l...@solentwholesale.com> wrote: >> >>> The pull request was rejected for a valid reason, offering http allows >>> users with limited network access chance to clone or download freebsd where >>> https is not possible. >> Do users actually exist who have access to http but not to https? >> Or is this a myth? And how do these users access popular sites >> like Wikipedia, or www.FreeBSD.org for that matter? > In an effort to enforce encrypted comms, my network is the inverse: > TCP:80 is disallowed, but TCP:443 is accepted. > > Thanks, Wading back into this; it may be worth one half of 2 bits from other's points of view....
IMO there are three issues and we're conflating them/. This is unfortunate because only one of them matters. /Https allegedly provides three things: 1. Attestation (you're talking to who you think you are) 2. Data integrity (the data has not been tampered with) 3. Privacy during transport (nobody but the receiving party can observe the payload except on the sending and terminal ends) #2 in https comes about because if #1 is true then the payload will not decode if someone tampers with it or the certificate in use, /provided /the correct options are enforced. The problem is that if #1 is false then both #2 and #3 are ALSO false, because if I can tamper with attestation then I can MITM the data (insert discussion/debate/whatever on the existing CA structure, etc. which is really the never-ending debate on key management, distribution and the vouching process in any given certificate management design) This leads to all sorts of other issues (like intentional MITM behavior via wildcard certs and overrides on certificate checking by corporate IT departments, possibly ISPs, user anti-virus software, compromise of a CA by state actors or hackers, etc.) The premise of https is very pretty but the implementation -- not so much. Nonetheless a whole lot of commerce and such depends on it, because all three are required for commerce so imperfect beats nothing. But in the context of code distribution I care not about #3. I care /very much /that /the code is untampered with/ (#2)/, /but note that I really _*don't*_ care about #3 at all because the code is /intentionally published to the public at large/ and I don't care _*much*_ about #1 (if someone mirrors the source /exactly /then whether I get it from FreeBSD's server or some interloper doesn't really matter either.) SVN's shortcoming is that it does nothing for #2 on an inherent basis and this debate is thus about trying to use a tool that allegedly does three things when we really only need one of them. Maybe it's time to move toward something that can for source distribution to the public (e.g. Git) instead of trying to abuse something that we know can't actually meet the criteria required? Just sayin'..... -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
