[Clueless anti-s]ecurity quote of the week [LWN.net]

[Clueless anti-s]ecurity quote of the week

Posted May 7, 2015 12:42 UTC (Thu) by szbalint (guest, #95343)
In reply to: [Clueless anti-s]ecurity quote of the week by jschrod
Parent article: Security quote of the week

Let's get away from bad analogies and address the issue directly: even for your personal, static page - we need https. It's too easy for anyone with access to the communication channel to change the content of your page on the fly and add something malicious. Plenty of ISPs can't be trusted - and not in some kind of theoretical malware scenario but they'll inject tracking cookies and ads into unencrypted (unauthenticated) content.

There is a disparity here aswell, it's your site, but our security is what's at issue here. Mozilla is nudging you to secure your site not because you need it, but because everyone who views your site needs it.

I don't think Weinstein disputes the need for https-everywhere, he just seems to take issue with the tone he seems to detect from Mozilla on how to go on about it.

(I think he's wrong on several points - Mozilla is not really agressive in pushing https, since they don't plan on disabling plain http anytime soon but rather only enable new features over https. He's also wrong about the tls certificate infrastructure and self-signed certs. It's not ideal, noone is saying it is, but it's both the practically best we've got and it's been (not even that slowly) getting better, we have both HSTS and HPKP, deprecating SHA-1 certs is well underway and CA baseline requirements are getting stricter over time, enforced by the threat of removal from the Mozilla/Chrome trust store. Let's encrypt will bring command-line-only free certs to the masses and there is Certificate Transparency to better audit who issues what kind of certs.)

to post comments

[Clueless anti-s]ecurity quote of the week

Posted May 7, 2015 15:39 UTC (Thu) by jschrod (subscriber, #1646) [Link] (1 responses)

> Plenty of ISPs can't be trusted - and not in some kind of theoretical
> malware scenario but they'll inject tracking cookies and ads into
> unencrypted (unauthenticated) content.

OK; that's an argument that I buy (and that's missing in Mozilla's FAQ on that topic). This danger is real, and TLS would protect against it.

Still, I think this makes it more difficult for the non-technical folks to set up their own simple Web server. (After all, cert mgmt and maintenance makes it more difficult, the aboundance of servers with expired certs shows it.) One more force to drive them into the arms of hosted pre-packaged Web site services, without developing an understanding of the technology used. Setting up such services is left for the profis, the bar to get to be a tinkerer is raised. I don't need to like these developments.

[Clueless anti-s]ecurity quote of the week

Posted May 8, 2015 20:12 UTC (Fri) by peter-b (guest, #66996) [Link]

It's actually dead easy to set up nginx as a reverse proxy to convert an HTTP site to an HTTPS site; I did it with no prior experience at all of nginx or HTTPS a couple of weeks ago, and it took about an hour. Installing a certificate is as simple as dropping a couple of files in /etc/nginx.

[Clueless anti-s]ecurity quote of the week

Posted May 7, 2015 23:13 UTC (Thu) by dlang (guest, #313) [Link] (4 responses)

> Plenty of ISPs can't be trusted - and not in some kind of theoretical malware scenario but they'll inject tracking cookies and ads into unencrypted (unauthenticated) content.

The answer to some bad ISPs isn't to force the entire Internet to change, it's to identify those bad ISPs and arrange class action lawsuits against them by either their customers or (even better) the websites that the ISPs mangle.

[Clueless anti-s]ecurity quote of the week

Posted May 8, 2015 7:25 UTC (Fri) by kleptog (subscriber, #1183) [Link] (3 responses)

> The answer to some bad ISPs isn't to force the entire Internet to change, it's to identify those bad ISPs and arrange class action lawsuits against them by either their customers or (even better) the websites that the ISPs mangle.

For that to happen it would have to be illegal for ISPs to modify traffic as it passes through them, and this is by no means a certainty. Undoubtedly some countries have dealt with this, but by means a majority.

The Internet by its international nature has operated outside of the normal legal frameworks which is both a blessing (rapid development) and a curse (no legal recourse against violators). So we have a large body of rules like RFCs but we can't lock up people who violate them. I don't think that's even desirable. So we do the only option available to us, we stop sending traffic in a way that can be easily modified.

[Clueless anti-s]ecurity quote of the week

Posted May 8, 2015 7:39 UTC (Fri) by dlang (guest, #313) [Link] (2 responses)

> For that to happen it would have to be illegal for ISPs to modify traffic as it passes through them, and this is by no means a certainty. Undoubtedly some countries have dealt with this, but by means a majority.

Well, in the US (where I believe that most of the bad ISPs that are being described are owned) the recent classification of them as a 'common carrier' (like they were except for about the last decade) could sure be used as justification for going after them.

Even though IANAL, another thing that jumps out at me is that a content provider could go after them under several possible approaches

1. trademark violations (making it look like the trademark endorses the changes)

2. defamation or similar (for hurting their reputation)

or my favorite (given the actions of the owners of many of these ISPs

3. copyright violation for producing a derivative work of the page. Implicit permission to copy the page as-is is obviously granted, but permission to make a modified version of the page????

I'm sure a team of good lawyers could come up with other grounds without much work.

[Clueless anti-s]ecurity quote of the week

Posted May 8, 2015 14:18 UTC (Fri) by cesarb (subscriber, #6266) [Link] (1 responses)

> Even though IANAL, another thing that jumps out at me is that a content provider could go after them under several possible approaches [...]

None of them apply to the "tracking cookies" example.

> 3. copyright violation for producing a derivative work of the page. Implicit permission to copy the page as-is is obviously granted, but permission to make a modified version of the page????

That would also apply against page modifiers like ad blockers, user stylesheets/scripts, or mobile browsers which automatically reflow/resize the page elements to better fit the small screen.

[Clueless anti-s]ecurity quote of the week

Posted May 8, 2015 17:57 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

> That would also apply against page modifiers like ad blockers, user stylesheets/scripts

I'm pretty sure it is a violation to redistribute the derivative work, not to make it in the first place (barring silly EULA terms).