Mythology About Security
gettys.wordpress.com
gettys.wordpress.com
Fascinating.
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.
Not quite. Downgrade attacks has been a huge problem for TLS.
The mere lack of any kind of encryption in our basic protocols can be considered the most important "downgrade attack" around since we never are quite sure when something is going to leak out into the huge background of plaintext.
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.
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.
Related to this, you should definitely watch Moxie Marlinspike's (lead dev of Signal) talk where he tells about his discussion with Kipp Hickman, a developer of SSL: https://www.youtube.com/watch?v=UawS3_iuHoA#t=13m52s (until 16:33)
(Disclaimer: this is for the sake of argument. I'm actually a laid-back person and against government surveillance and stuff.)
I’ve been reading Crypto by Steven Levy, it’s on exactly this topic, and I’m astounded by how actively the NSA discouraged commercial research, and how early on it happened: mid-1970s.
But I suppose the reason NSA was delaying was they had to develop a workaround for the encryption. Remember, while public key crypto got strong in 1996 when the key lengths ended Tailored Access Operations (NSA's hacking team) was created in 1998, before DES was replaced with AES in 2001.
Now obviously it's not that simple. Phasing out weak standards has taken very long. Personally, I would love to understand what goes on in the heads of developers who still use age old primitives like MD5 and RSA-1280 (iMessage).
No. Their primary purpose was never to protect anybody else but their own operations (the concept "Nobody but us" is older and broader than Wikipedia currently knows https://en.wikipedia.org/wiki/NOBUS ) especially not "common citizens". The NSA is mainly a military institution. Had they been able to get by with nobody being allowed to use crypto but they, they would have done that and continue doing.
Bonus: this is directly from the NSA:
https://www.nsa.gov/resources/everyone/digital-media-center/...
Covered here:
What do you mean? The tendency for bad guys to exploit bugs is really important. But the fact that a government deliberately broke security for everyone is an additional thing, not a special case.
And its worthwhile noting that it is a failure mode we can expect from governments. The US had a realistic concern that opposing nations would use strong crypto against them. The trouble was that they put that concern above all the other consequences that followed from their laws. The policy makers probably couldn't even imagine most of those consequences.
It is in the nature of legislation that it can amplify whatever particular concern captures the political imagination without having to consider the broader picture.
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?
There's a world of difference between choosing not to implement security features to allow faster shipping; and keeping security features out because with them you are not allowed to ship.
The first is garden-variety negligence. The second is politically mandated malfeasance.
To use analogy, there is difference between risking a dollar in a bet and risking five thousands of dollars+broken collarbone.
So if you wanted to offer it to anyone outside of USA, you were treated as if you were trying to deal in tanks or fighter jets.
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 your X session through the browser, and for the most part X was used to talk to trusted programs on trusted hosts.
Wayland, by contrast, has a security model for the modern, hostile internet built in from the start.
That's a feature that I have used many times in the past. Isolation should be handled at the X server level, where it can be handled without excessive complexity or require breaking backward compatibility.
> default
Locked down defaults and enabling features opt-in is good design. (Principle of Least Privilege)
> Wayland
Isn't compatible as it's missing required features (by design).
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.
Can't always make wise improvements if you don't first make awful mistakes that weren't properly considered in practice.
Ubuntu wanted to do this with Mir. The rest is history...
It took the X11 devs, many of whom were also involved in Mesa and Linux graphics development, literally years just to get all of the necessary plumbing in place in order to replace what X11 was previously doing.
These developments help not only X11 or Wayland, but make the development of a newer, superior protocol to X11 and Wayland much easier, because the hard yards have been done for them.
It also makes it easier for those who might want to transition from Wayland to a hypothetical superior protocol.
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?
Wanting to run mutually distrustful sandboxed apps side by side was not a popular use case back then.
These days network transparency is a) irrelevant for most use cases and b) much better implemented with newer protocols like RDP and PCoIP. That's why it was removed from Wayland.