According to wikipedia, "Ettercap is a [..] tool for man-in-the-middle attacks on LAN". It requires you to gain access to a victim's LAN! If the wikipedia page is right, it performs ARP ARP poisoning to redirect vicitm's connections. This can be detected. On a properly administrated network, this attack can automatically be detected, alerting admins etc.

Requiring access to the LAN and being easily detected for me qualifies as "difficult to deploy". Also note that the computing resources needed to MiTM SSL are pretty enormous (SSL handshake takes a lot of computation). I don't think this will scale to substantial portions of the SSL traffic of a country. Compare that with the almost complete capturing of non-encrypted traffic allegedly implemented by NSA.

I really don't understand why everybody tries to reduce these encryption problems on the "false security" vs. "no security" dichotomy. No this is not about false security. This is about security against undetectable passive attackers vs. detectable active attackers. The amount of data a detectable active attacker is able to collect about my person are many orders of magnitude smaller than the amount of data a passive attacker is able to obtain. The active attacker will also only be able to obtain data from the point of time I was chosen as a target. The passive attacker will be able to go back in time and look at my communication (probably many years) before I became interesting enough to be deemed a target.

This is why implementing SSL, even if no protection at all against MITM existed, is much much better than no SSL at all.

The attack the FBI attempted on Lavabit had no relation at all to certificate authorities. They merely requested the private host key of the server to be able to decrypt any recorded SSL traffic for that site. Note how this kind of attack only works when you have access to the server in question (in which case you would be able to directly monitor the plaintext communication anyway by tracing the web server executable). I repeat, this is not related at all to certificate authorities. Also note how this attack does not really scale, as it requires you to actively request and collect SSL host keys (not certs!) of all webservers whose traffic you are interested in. For that reason I would expect that information about your operations *will* inevitably leak to the public. Also web servers in other countries will be relatively well protected against this kind of attack.

But here again at MITM attack would be detectable. If the SSL Everywhere guys were not completely stupid they will check the host key of the SSL Observatory against a private certificate authority that they completely own (with the certifcate authorities' key hard-coded into their browser extension). Or more simple, they could just hard-code the public key of the observatory. Or implement certificate pinning etc. etc.

The only working attack would be for the NSA to MITM every download of the SSL Everywhere executable, patching the certificates contained in its code. But again, this is easy to detect after the fact by inspecting the sources, comparing checksums etc.

For that reason I'm not afraid at all about MITM, as it does not allow for the broad, secret, non-discriminatory data collection that Snowden's leaks show to be implemented by NSA.

Having the keys from multiple SSL cert vendors does not help a bit (and having the keys from many vendors isn't much better than having the keys of a single vendor). It does NOT magically allow you to decrypt SSL traffic from servers whose host key was signed against that cert vendor's certificate!

To decrypt traffic of multiple SSL websites requires you to obtain the private part of the SSL host keys from all the web-servers themselves. Note that web server host keys are signed via signing requests that do not contain a copy of the private key, so even when the cert vendors (CAs) are hacked, you cannot directly listen in on SSL communication. When the servers implement Perfect Forward Secrecy, then even obtaining a copy of the server's host key won't help as each connection uses a temporary key that's exchanged via Diffie Hellman Key Exchange, a method that generates a key shared between two hosts, that (somewhat counter-intuitively) cannot be deduced by sniffing the traffic between those two participants.

What you can still do is to set up a MITM attack: you set up your own intermediate server with its own host key and sign your host key(s) using one of the SSL vendor's certs that you obtained. Then you redirect all traffic to the servers that interest you via your server (i.e. proxying all SSL connections) and then obviously in the process you obtain the cleartext of all SSL sessions running via your server.

However, the MITM attack is much more difficult to deploy and scale than simple monitoring and recording IP data. Also skilled users will easily detect the MITM attack, as the host key's public part of the servers in question will suddenly change. There are firefox extensions to check for these signs of a MITM. Even SSL Everywhere has a checker built in (via the SSL Observatory). Or try Certificate Patrol.

You suggest that MITM attacks on SSL are as bad as someone sniffing on unencrypted traffic. It is not! MITM attacks are active attacks and are much more invasive to carry out. That's not all: in principle all these MITM attacks can be detected: the host key of the Man In The Middle will differ from the host key of the original server (though your browser will accept the differing host key when it is signed by a rogue CA).

It is pretty dangerous for an adversary to carry out MITM attacks on a large scale, as sooner or later, this is going to be detected. The SSL Everywhere extension for example can (optionally) collect information for and check with the SSL Observatory to detect differing certificates that indicate MITM attacks.

There's also the Certificate Patrol Firefox Extension that persistently remembers certificates and warns when certificates changed for no apparent reason.

Also a lot of houses have remote heating using residual heat from gas or coal power stations. This way these power stations get an efficiency rating of close to 100%, something that wouldn't be possible otherwise (due to the second law of thermodynamics).

This is about putting dedicated hardware on board to load default firmware from a flash-ROM into the Marvell WLAN chip, so you d o not need to load the firmware after every boot. There is plenty of explanation on the project page , and quite clearly it writes

But why bother reading about details when it is so much fun to just complain and whine and repeat your half understood rants on half understood topics, right?

I won't even start to tell you how many mis-statements are contained in this sentence, let alone the whole paragraph I'm not bothering to quote. Luckily /. features a Foes list that will save me from ever attempting to argue on any matter with you again.

You know that Emacs does not parse most of its .elc or .el files at startup? These are parsed during Emacs compilation, then an image of the Emacs process' memory is dumped to disk and used for quick startup. Only system config files from /etc or ~/.emacs and dependent files need to be parsed.

He was "joking" (?) about *his* piece of software, Git, quite clearly claiming that people complaining about it are just idiots. Using a pretty offensive language (even if just joking), on a public mailing list. If Linus was a little bit more open-minded or tolerant or spending one second of his time thinking about the users of his software (let's better call them victims), I think he might at least acknowledge that the problem might with Git's lack of consistency, lack of documentation and general complexity (when compared to alternate DVCS). There are more Linus-quotes that reflect a (IMO) questionable attitude towards his users, enough that I take everything he boasts about with a grain of salt. But we're getting off-topic.

Yeah, now I get the point you were referring to. It might seem inconsisten, but maybe you didn't think his reasoning to the end: If a WLAN-chip required a closed firmware to operate, than the Linux kernel has to be shipped with a copy of the (binary and non-modifyable!) firmware embedded. Now suddenly your operating system isn't free any more, as it's bound not only by the Linux license, but also by the license of the firmware. What when it stated that export to Cuba was forbidden? Or specific uses were excluded? You generally don't want to teint your GPLed operating system with non-GPLed bits and pieces protected by copyright. Putting the questionable firmware in an on-board ROM at leasts frees people that deal with the Linux-OS images from having to care about the copyrights of the non-free firmware (the board's manufacturer will still have to deal with it, though).

I won't consider myself a RMS fan or a free software zealot, just by knowing some of RMS' opinions and quoting them when I think they provide a valid point on some issue. On the other hand, you seem to be a complete anti-RMS zealot. "Please don't quote RMS"? Just because some of his stuff is too extreme for your taste?

You think Torvalds is any better? Hey, I have a quote for you (source)

If I were you, I'd rather ask people to not quote Torvalds than to not quote RMS.

I am the only one who's annoyed by the poster's complete lack of critical reflection on those "IP" claims? Are the IP lawyers and lobbyists now getting their anonymous postings on slashdot, too? I'm close to deleting my /. account.

BTW I'm also annoyed by the fact that people got so used to the somewhat nonsensical oxymoron "Intelectual Property".

No, what they found is that she copied other author's text including footnotes. At other places she reformatted in-line references of the original into footnotes of her text. Whether she copied the text literally or not; if you copy references&footnotes, keeping the original order and semantics, it's pretty clear that you didn't think of your own. I don't think reformulating and reformatting skills entitle you to a PhD.