Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mythology About Security

gettys.wordpress.com

Post reply on HN
Print view View original

31–40 of 45 posts

Re: Mythology About Security

#31

Post by wolfgke »

Valmar wrote: post #27
educar wrote: post #25

Earlier quoted context omitted.

> Wayland, by contrast, has a security model for the modern, hostile internet built in from the start. And yet basic video and screen capture is not working for years now. Arbitrary rectangle capture still doesn't work on Ubuntu 16.04 in any tool I know of. So they made it so secure to make basic features not work.

I wonder if there will be a successor to Wayland and X11 that learns from the mistakes of both? Can't always make wise improvements if you don't first make awful mistakes that weren't properly considered in practice.

> I wonder if there will be a successor to Wayland and X11 that learns from the mistakes of both?

Ubuntu wanted to do this with Mir. The rest is history...

Re: Mythology About Security

#32

Post by tombrossman »

educar wrote: post #25
bitwize wrote: post #3

So uh, why did you design X in such a manner that any client could sniff any other client's events and windows by default, and only later add a (quite inadequate) SECURITY extension? This is what we mean when we say that the security model of X is obsolete, and an afterthought besides. The threat model was completely different back then: every griefer, troll, thief, and state actor didn't have a pipe straight into yo…

> Wayland, by contrast, has a security model for the modern, hostile internet built in from the start. And yet basic video and screen capture is not working for years now. Arbitrary rectangle capture still doesn't work on Ubuntu 16.04 in any tool I know of. So they made it so secure to make basic features not work.

> And yet basic video and screen capture is not working for years now. Arbitrary rectangle capture still doesn't work on Ubuntu 16.04 in any tool I know of.

I'm curious, what tools have you tried? I ask because the default screenshot tool works perfectly for stills (including stills of video playing in a window or full-screen), and the few video screen recording tools I've tried all worked perfectly. At the moment I'm using Kazam on 16.04 with the default Nouveau drivers, and a quick test with Chromium playing a video stream + Totem simultaneously playing a local video file confirms that everything is captured no problem. Full screen, arbitrary windows, all tested and working.

Tl;dr try Kazam, unless I'm misunderstanding the issue you describe?

Re: Mythology About Security

#33

Post by watwut »

petermcneeley wrote: post #5

"The choice for all of us working on that software was stark: we could either distribute the product of our work, or enter a legal morass, and getting it wrong could end up in court" Is this not simply an economically expedient choice? To put the security and privacy of users below that of product distribution? How is this choice really different than any tradeoff a software company today makes about security?

It is difference between risk of "loosing some money+time" and risk of "loosing huge huge amount of money and possibly ending in jail".

To use analogy, there is difference between risking a dollar in a bet and risking five thousands of dollars+broken collarbone.

Re: Mythology About Security

#34

Post by stordoff »

colorincorrect wrote: post #28

I often hear that (quote the article) "Government export controls crippled Internet security and the design of Internet protocols from the very beginning" Can anyone give me examples of which a design flaw in the protocol results directly in poorer security, and how it could have been better designed? Not that I doubt the claim but I am not literate in this area.

https://en.wikipedia.org/wiki/Export_of_cryptography_from_th... is probably a good place to start.

One fairly concrete example:

> Shortly afterward, Netscape's SSL technology was widely adopted as a method for protecting credit card transactions using public key cryptography. Netscape developed two versions of its web browser. The "U.S. edition" supported full size (typically 1024-bit or larger) RSA public keys in combination with full size symmetric keys (secret keys) (128-bit RC4 or 3DES in SSL 3.0 and TLS 1.0). The "International Edition" had its effective key lengths reduced to 512 bits and 40 bits respectively (RSA_EXPORT with 40-bit RC2 or RC4 in SSL 2.0, SSL 3.0 and TLS 1.0), by zero-padding 88 bits of the normal 128-bit symmetric key. Acquiring the 'U.S. domestic' version turned out to be sufficient hassle that most computer users, even in the U.S., ended up with the 'International' version, whose weak 40-bit encryption could be broken in a matter of days using a single computer. A similar situation occurred with Lotus Notes for the same reasons.

It's not necessarily a design flaw in the protocol, but it has basically the same effect.

Re: Mythology About Security

#35

Post by fulafel »

bitwize wrote: post #3

So uh, why did you design X in such a manner that any client could sniff any other client's events and windows by default, and only later add a (quite inadequate) SECURITY extension? This is what we mean when we say that the security model of X is obsolete, and an afterthought besides. The threat model was completely different back then: every griefer, troll, thief, and state actor didn't have a pipe straight into yo…

Because all programs were running under the same user account, so there was no use trying to build a security boundary between them in the X server.

Wanting to run mutually distrustful sandboxed apps side by side was not a popular use case back then.

Re: Mythology About Security

#38

Post by geerlingguy »

acqq wrote: post #22
lordofmoria wrote: post #12

Earlier quoted context omitted.

I would argue that usually it doesn’t matter because of the reasons you mentioned, but in this particular case it really did. The US government, and the NSA in particular, made it a matter of explicit policy to delay and discourage commercial crypto research and development in the US. Off hand, I’d guess this delayed crypto by 10 years. Imagine if 10 years ago, we had today’s understanding of crypto. I’d wager TLS wo…

To help other possible readers: it's "Crypto: How the Code Rebels Beat the Government -- Saving Privacy in the Digital Age" by Steven Levy, from 2001.

Strong recommendation to read this book; it's a pretty approachable introduction to modern cryptography and the people we have to thank for where we are today.

Re: Mythology About Security

#39

Post by mannykannot »

GuB-42 wrote: post #7
collinmanderson wrote: post #2

> We asked MIT whether we could incorporate Kerberos (and other encryption) into the X Window System. According to the advice at the time (and MIT’s lawyers were expert in export control, and later involved in PGP), if we had even incorporated strong crypto for authentication into our sources, this would have put the distribution under export control, and that that would have defeated X’s easy distribution. Fascinati…

Did they really have to include strong crypto? Most secure protocols negotiate a cipher suite. They just had to add the ability to do so, and maybe some placeholder algorithm using the maximum allowed strength at the time.

The article says "even calls to functions to use strong authentication/encryption by providing an external library would have made it covered under export control." Would your proposal have been ruled out by this? They seem to have gone to considerable lengths to find a solution.

Re: Mythology About Security

#40

Post by mikeash »

I find this hard to believe. I can certainly believe that American crypto laws resulted in a lot of unencrypted protocols, but there’s more to security than just crypto. What about things like rlogin? A lot of older stuff (and newer stuff, for that matter) assumes that the other side is trustworthy, which is a separate concern from encryption.
Post reply on HN