Security quote of the week [LWN.net]

Now, if Mozilla is willing to establish a cadre of bonded and insured site design experts willing to perform https conversions for such sites without charge, and help maintain them forevermore, well, I'd certainly be interested in having that conversation. That's using the carrot approach I mentioned earlier.

On the other hand, plans to try use those sharp sticks and prods to try bully these sites into the https camp like cattle -- well, if you think the world has a mixed view of technologists now, if Mozilla gets its way we'll end up with a positive rating on par with politicians -- if we're lucky.

I very much want to see an Internet where all communications are securely encrypted, but only if it's done the right way, with sites and users treated as valued partners with a full understanding of their resource constraints and sensibilities -- and not as "losers" to be treated with what amounts fundamentally to arrogant contempt.

— Lauren Weinstein

to post comments

[Clueless anti-s]ecurity quote of the week

Posted May 7, 2015 7:34 UTC (Thu) by fredrik (subscriber, #232) [Link] (16 responses)

I fail to see what this quote contributes to LWN or the debate on Mozillas 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. Oh, wait, wikipedia tells me he's a Internet authority. I suppose it serves as some form of public shaming of mr Weinstein then?

The opponents of Mozilla's proposal need to realize that this is a multi-year effort. People will have plenty of time to move to new platforms that makes certificate use easier. Much of the work will happen more or less automatically. The platforms and servers that provide insecure http today will likely be modified to provide https by default, if nothing else than to stay relevant for new deployments. The cadre of experts that will make this happen already exists among ISP:s, web platform developers, the outstanding developers of open source web servers like Apache and Nginx, etc. And small things like search engine algorithms that prioritize https over http will be the carrot that makes even the most clueless web 2.0 designer put in the effort.

Yes, there are issuses to be dealt with. But just like the web had to adjust to threats like CSRF it will have to move forward and adjust to this change too.

[Clueless anti-s]ecurity quote of the week

Posted May 7, 2015 10:17 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (1 responses)

Because Mozilla people think they are in the RIGHT they do not need to help others to migrate, or listen to them (since they are in the WRONG).

Their whole approach is summed up by your "The platforms and servers that provide insecure http today will likely be modified to provide https by default" (ie someone else will do the work) and when that's not enough, instead of contributing some help, they'll contribute some sticks.

From what I've seen in the IETF forums, the quoted article is spot on.

[Clueless anti-s]ecurity quote of the week

Posted May 7, 2015 11:04 UTC (Thu) by PaXTeam (guest, #24616) [Link]

> ie someone else will do the work

i don't understand, who is supposed to 'do the work'? the browser vendor?

[Clueless anti-s]ecurity quote of the week

Posted May 7, 2015 12:03 UTC (Thu) by jschrod (subscriber, #1646) [Link] (13 responses)

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

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

Security quote of the week

Posted May 7, 2015 9:06 UTC (Thu) by TMM (guest, #79398) [Link] (2 responses)

This is also the exact same argument some 'internet authority' makes every single time a web change is proposed.

"We're breaking working sites."

Yes, yes we are. The web is too important to let it just fester because there are some sites unable to upgrade when the platform chances.

CORS, other javascript security measures, SSLv3 deprecation etc. etc. etc. There's always someone who shouts bloody murder. "Someone else has to pay to fix the old sites."

right.

Security quote of the week

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

> "We're breaking working sites."

Your comment reminded me of this: https://xkcd.com/1172/

Security quote of the week

Posted May 7, 2015 15:40 UTC (Thu) by mitr (subscriber, #31599) [Link]

AFAICS this is not actually breaking working sites.

If you have a working, not really maintained, site, you can keep it as it is, unencrypted, with no new features, and it will keep working fine. No need to touch the server hosting the site at all.

If you are actively maintaining your site and taking advantage of new browser features, then you have to move to HTTPS. In effect, “move to HTTPS” just becomes a required part of the API of the new features—but you still have the option to not use these new features if that effort is too much work.

Security quote of the week

Posted May 7, 2015 10:07 UTC (Thu) by tcourbon (guest, #60669) [Link]

I'm so happy to see that the other commenters managed to express my feeling on this quote much better than I would have been able to due to my poor English skills (and more probably due my relative lack of knowledge on this matter).

Thank you !

Security quote of the week

Posted May 13, 2015 15:47 UTC (Wed) by gerv (guest, #3376) [Link]

I wrote a response to another critical article, where I cover some of the misunderstandings Lauren shows here. It kind of feels like he got out of bed on the wrong side, as well. Digging through all that, his problem seems to be that switching to HTTPS is hard. Well a) people are making it easier, b) old sites which don't use newer web features will continue to be viewable, and c) China's Great Cannon, plus other ways that intermediaries can nefariously interfere with your non-encrypted connection, mean that HTTPS everywhere needs to be the future.

Also, he says we're all stick and no carrot. Is withholding a new web feature from HTTP, and having it be HTTPS-only, a stick or a carrot in his mind? In one sense, it's a carrot - what you never had, you still don't have. In another, it's a stick - there's often no technical reason it couldn't be HTTP as well, that's Mozilla's choice. I think, on balance, it's a carrot, but if he disagrees, perhaps that's why he thinks we're all stick.

Gerv