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

[Clueless anti-s]ecurity quote of the week

Posted May 7, 2015 12:03 UTC (Thu) by jschrod (subscriber, #1646)
In reply to: [Clueless anti-s]ecurity quote of the week by fredrik
Parent article: Security quote of the week

> very sensible decision to gradually phase out a protocol that in a
> security and authenticity perspective is to the web what telnet was to
> remote terminals.

Publishing my personal homepage and some of my pictures on the Internet without secured transport protocol is *not* akin to using telnet. telnet is used to issue commands on a remote system, that's a whole different affair than transmitting static pages and images that I explicitely put up for unlimited publication. I need neither encryption nor authentication for that.

Establishing https sites is more work than http sites, and be it because of certificate management. Quite some sites are not worth that effort, or any migration effort whatsoever.

You're comment's tone (and your subject line) is a prime example of the "arrogant contempt" that Weinstein bemoaned.

You think he's clueless; I think you demonstrated that he's spot on.

to post comments

[Clueless anti-s]ecurity quote of the week

Posted May 7, 2015 12:07 UTC (Thu) by johill (subscriber, #25196) [Link] (1 responses)

telnet would be a better analogy if the "telnet" binary was now saying "sorry, you cannot connect to anything that's not ssh protocol any more" - and then you couldn't watch "telnet towel.blinkenlights.nl" afterwards :)

...

[Clueless anti-s]ecurity quote of the week

Posted May 8, 2015 8:06 UTC (Fri) by fredrik (subscriber, #232) [Link]

Well, as you just illustrated so well, one can still deploy and access a telnet service today. Even though telnet has been deprecated by the world for decades.

And you can deploy a gopher site. With an add-on you can use Firefox to visit that site. Even though the protocol has been more or less abandoned for two decades.

There will in all likelihood be a long tail of personal sites, sites of historic interest, cat picture sites, etc, served by plain http for decades more. When I read Mozillas proposal my conclusion is that you will be able to continue to use Firefox to visit those sites too. Am I really mistaken?

What is changing is that new web features - new javascript features and maybe some upcoming html5 features, etc - will not work on contemporary sites unless they are served over https. In my view the approach is very much a carrot thing, not a stick thing. You want new features? Well, move to https then.

Apart from the unreasonable demand that Mozilla stop hacking on Firefox and dedicate all their resources to solve all aspects of https server deployment for everyone before deprecating http, how else can they implement a carrot approach to migration to https?

Speaking of carrots, Mozilla are already involved in Let' Encrypt, an effort to make certificate deployment very much easier and available at no cost. How is that not to engage in a carrot approach?

To reiterate: Your old HTML 4.01 site that you last edited 1999 and still are proud validates to this day, and which is served over a HTTP 1.0 server that you implemented yourself in C and lost the source code to a long time ago, will keep on working. Please, just don't go and spoil it with html5 and javascript. Thanks! :)

[Clueless anti-s]ecurity quote of the week

Posted May 7, 2015 12:42 UTC (Thu) by szbalint (guest, #95343) [Link] (7 responses)

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.)

[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).

[Clueless anti-s]ecurity quote of the week

Posted May 7, 2015 14:05 UTC (Thu) by cesarb (subscriber, #6266) [Link]

> telnet is used to issue commands on a remote system, that's a whole different affair than transmitting static pages and images that I explicitely put up for unlimited publication.

You forgot JavaScript and Flash (and Java if you still have it installed because your bank's online banking depends on it). HTTP _is_ used to issue commands on a remote system, that remote system being your browser. Yes, it's supposed to be sandboxed, but we all know from reading security advisories how porous that sandbox can be.

Your site might have only static pages and images, but a MITM attacker (which is what TLS protects against) can easily "fix" that by injecting a few elements into your HTML.

[Clueless anti-s]ecurity quote of the week

Posted Jun 13, 2015 0:50 UTC (Sat) by Rudd-O (guest, #61155) [Link] (1 responses)

Actually, it's not like telnet. It's worse. You posting your site with your pictures but no HTTPS enables anyone -- who positions themselves between your site and your viewers' browsers -- to run arbitrary, malicious computer programs on the computers of your viewers. This is, in fact, how the NSA deploys FOXFIRE and many other race-to-response browser exploits. So you are right, not like telnet, but much worse, with you / your dinky little website enabling those attacks.

[Clueless anti-s]ecurity quote of the week

Posted Jun 19, 2015 16:55 UTC (Fri) by flussence (guest, #85566) [Link]

>So you are right, not like telnet, but much worse, with you / your dinky little website enabling those attacks.

No, it's the web browser that enables those attacks by silently executing arbitrary code with network access by default, without seeking the user's permission informed or otherwise, or offering reasonable access controls, and furthermore encouraging a culture of development where this kind of blatant insecurity is the social norm.