Hacker News Reader

Comment by storborg | Hacker News Reader

And how do you do that at the corner Starbucks without using the command line?

Edited to clarify since apparently I can't reply to a child comment: There are tools that require next-to-no technical expertise to passively observe HTTP sessions. There are no such tools that I'm aware of to execute an HTTP MITM without control of the network infrastructure.

I think what the original poster meant was basically just "in a situation where you absolutely, definitely, cannot have SSL, javascript crypto is an iota better than nothing, because at least it breaks Firesheep and Wireshark".

View on HN

What do I care whether there's a pretty UI for an attack?

HTTPS/TLS is designed to be secure against adversaries with millions of dollars dedicated to attacking it. Why am I even dignifying systems that rely on the attacker's inability to use a command line, or write Perl code?

Have you reasoned through how much code it would take to make a "Firesheep" that worked against Javascript crypto implementations? It's not even a little bit hard.

So do it, and render the entire line of discussion pointless. This argument comes up often when discussing JS crypto, and while I agree it's silly for any system that actually has assets worth protecting--personal or financial info, for example--there are plenty of attackers that don't have financial motivation, resources, or knowledge, and just want to use the easiest crap available to them to mess with other users.

This sounds like the US military's rational for not scrambling video feeds, and using armour piercing rounds in the Middle East. The Soviet Union can unscramble insecure cryptography, and their soldiers will have armour, so insecure encryption and non-armour piercing bullets are considered harmful.

JS encryption is certainly less secure than SSL, and may give a false sense of security to people who want to use it as a replacement.

On the other hand, it may be better than nothing.

The part you're missing is the bit where ad-hoc JS crypto takes longer to implement and is more expensive than turning on SSL.

US military's rational for not scrambling video feeds

Bruce Schneier wrote about why encrypting the video feed of predator drones was not as straightforward: http://www.schneier.com/blog/archives/2009/12/intercepting_p...

The command and control channel is, and always has been, encrypted -- because that's both more important and easier to manage. UAVs are flown by airmen sitting at comfortable desks on U.S. military bases, where key management is simpler. But the video feed is different. It needs to be available to all sorts of people, of varying nationalities and security clearances, on a variety of field terminals, in a variety of geographical areas, in all sorts of conditions -- with everything constantly changing. Key management in this environment would be a nightmare.

You can reply to child comments, you just have to wait a minute or three.

Clicking "link" will also allow it.

And how do you do that at the corner Starbucks without using the command line?

Despite what Hollywood says, using a command line does not make you a super leet hacker. If your security system can be broken with a command line, then I doubt you care that much about the data you're securing. Just put the data in plain text and call a spade a spade.

Reply on news.ycombinator.com