Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×

Comment Re:Tmux (Score 1) 136

I'm not a tmux user, so I may be completely wrong, but I think what they are talking about is that in tmux you can share one window in a session without also sharing all your other windows in that session. You can also easily move tmux windows between sessions, which you can't do in screen. In addition, sharing a tmux window to another user with a different login account is a lot easier in tmux than in screen. There are also forks of tmux that allow two people to use one window with two independent cursors.

Basically, tmux is a lot more flexible and easier to hack than screen. I've never bothered with tmux though, screen is good enough for me.

Comment Re:Oops in title - "sans" ? (Score 2) 147

Doesn't "sans" mean without?

Yes, that's because WD's 6TB Ultrastar He6 was hermetically sealed with helium inside, something the company said was critical to reducing friction for additional platters, while also increasing power savings and reliability. Seagate, however, said it doesn't yet need to rely on Helium to achieve the 50% increase in capacity over it's last 4TB drive.

At least, I'm sure I read that somewhere.

Comment Re:A simple solution (Score 2) 97

wiziwig.tv does a pretty good job of pirating most live sports, albeit only in standard definition quality.

I think HD quality is overrated. Yes, I can tell the difference. Yes, I appreciate HD quality. But up until 2003 or so, I happily watched live sports in standard definition quality without feeling in the least bit cheated. So I see no reason why high quality is mandatory today.

Comment Old news (Score 5, Insightful) 144

This is quite old news, why is slashdot only picking up on it now?

The impact of this bug does not compare to the goto fail bug. Most Linux distributions use OpenSSL for TLS. Even if a program links to GnuTLS, it may not use GnuTLS for certificate validation, and if it doesn't, then it's not affected by this bug (one example is Google Chrome). It's not like iOS where everything is required (by App Store rules) to use SecureTransport.

Comment Re:Do they distribute the source? (Score 1) 208

There's a lot of GPL software in Ubuntu, starting with the Linux kernel. Does Tesla distribute the source code to Model S owners that ask?

The source disclosure requirements of the GPL are often misunderstood. To comply with the GPL, it is not enough to distribute the source code to Model S owners that ask.

The GPL provides three options for distributing binaries (Sections 3a, 3b, and 3c), and anybody distributing Linux source code must comply with at least one of these options. Tesla cannot use Section 3c, since Section 3c states that only non-commercial distributors can use Section 3c. Section 3a requires Tesla to distribute the source code to all Model S owners, not just those who ask. Section 3b requires Tesla to distribute the source code to anybody who asks, not just Model S owners who ask.

Therefore, Tesla is required to distribute the Linux source code that they use either:

  • To every Model S owner, regardless of whether the owner asks or not, or
  • To every legal entity that asks for the source code, regardless of whether the entity is a Model S owner or not.

Comment Re:Tip from a programmer (Score 1) 78

Another point that you missed completely is that your targeting assumption is wrong. If you're doing a MITM against a banking site, you DON'T need to target them. Not with SSL. You can compromise instead any one of the thousands of certificate authorities in the world. Any single successful compromise of any of these unrelated third parties gives you free rein to MITM any banking site in the world. From the point of view of the server administrator, this is absolutely insane. No matter how good my own security is, an attacker can MITM me by compromising any single one of any of thousands of unrelated CAs, 99.99% of which I as a server administrator have never done business with. At least with SSH if my own server keys get compromised it's my own damn fault. Not so with SSL.

Comment Re:Tip from a programmer (Score 1) 78

Your argument remains completely nonsensical for one very basic and unavoidable reason: SSL is also equally vulnerable to stolen keys. There is no way in which SSH is worse than SSL.

Of the MITM attacks against SSL actually deployed in the wild, what proportion rely on stolen keys compared to compromised certs? Answer that question, and you'll see that my "most attacks" claim is fully valid.

Comment Re:Tip from a programmer (Score 1) 78

Yeah great. This kind of SSH compromise requires a targeted attack, and will only work on that one server. By contrast, with SSL, a single DigiNotar stunt allows you to attack thousands of servers and millions of users all at once. See the difference? SSL is great in theory, horrible in practice. Anyone claiming otherwise is willfully blind of real-world considerations. This includes most cryptography researchers.

Comment Re:Tip from a programmer (Score 1) 78

Mobile apps can and do use key pinning, but certificates are not necessary for that. They can just pin individual self-signed public keys. For that matter, they don't even need SSL; they could just use SSH.

It's possible, but useless, to implemet public-key TOFU in web browsers. Almost all web sites rotate keys too fast for the pin to be useful.

Comment Re:Tip from a programmer (Score 1) 78

If you don't trust your CA chain then do cert pinning. Either way you need to know you're talking to the right server, pretending that's impossible so it's not worth trying is a cop out.

Certificate pinning is not possible in any real-world scenario. The problem is that certificates change too often. Certificate authorities are part of the problem: they encourage high turnover, because it increases their profits. Certificate pinning only works in situations where you have inside knowledge of a company's certificate policies. Google implements certificate pinning on their own Google properties in Chrome in this way. There is nothing in SSL that technically prevents certificate pinning, but the design of SSL has inevitably led to non-technical economic incentives that indirectly make certificate pinning impossible.

SSH essentially relies exclusively on key pinning (not certificate pinning) for authentication, and it works beautifully. SSH has no certificates, and yet has a higher market share in the shell connection market than SSL has in the http connection market. SSL should become more like SSH, but this is impossible to achieve, because CAs are already economically entrenched.

Comment Re:Tip from a programmer (Score 4, Insightful) 78

True MITMs are reasonably rare in large part because of SSL.

WRONG. Provably wrong.

There exists an extremely widely-used crypto protocol which uses no certificate validation and yet prevents almost all MITM attacks. It's called SSH. In fact SSH has done something that SSL will never do: it has completely replaced the corresponding unencrypted protocol, to the point where no one, I mean no one, uses telnet anymore.

How does this magic work? SSH performs key validation. It performs this validation without requiring certificates. The validation model is very simple: trust on first use (TOFU). Although TOFU on paper is theoretically inferior to CA validation in every way, real life does not take place on paper. In the real world, TOFU is far superior to CA validation. It prevents the kinds of attacks that actually matter, while ignoring the kinds of attacks that look great on paper but aren't really a big deal in practice.

Comment Re:Cherry Picking is Much of the Issue (Score 1) 335

No, it's more like:

If you pick 17 years you get one conclusion.*

If you pick 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33 or 34 years you get another conclusion.

(*actually, you don't. I've no idea where this "17 years" thing came from. The temperature data shows a rise over the last 17 years)

Comment Re:The numbers game. (Score 1) 199

Oh good! A substantive response for once. Let's discuss the points you raised.

I admit I made up the 1% figure, but I believe it is a reasonable estimate. Would you like to challenge the accuracy of the number? If anything, I am convinced that closer scrutiny would reveal it to be too high of an estimate. 2013 US GDP was 17 trillion dollars. Microsoft's 2013 revenue was 77 billion dollars, about 0.5% of GDP. Of course, Microsoft is not a pure software company; some portion of that revenue is hardware, services, and so on. There are other software companies, of course. I have never heard anyone reasonably justify a much higher cost than 1%.

It is true that the benefits of commercial software far exceed its costs, but from a public policy perspective that's completely irrelevant. The cost of producing this software is ~1% of the economy. If commercial software did not exist, the government or any public body could (provably) replicate the exact same benefits at the exact same cost. Government support for something on this scale is not a ridiculous idea; it's exactly how most basic research in science is actually done in the US. Hence 1% (or less, if I'm overestimating the cost) is the correct figure to use for policy prescrptions.

Slashdot Top Deals

"If it ain't broke, don't fix it." - Bert Lantz

Working...