4 ms·

It's easier for an attacker to passively observe a stream than to actively inject specifically tailored code into it. At least with JS Crypto, amateurs with Wi

It's easier for an attacker to passively observe a stream than to actively inject specifically tailored code into it. At least with JS Crypto, amateurs with Wireshark and Firesheep probably can't steal your stuff. But since that's all the protection it offers, it shouldn't be advertised as anything more ("This NOTEr 2.0 App uses AES-256 in JS over HTTP to provide NSA GRADE security and privacy!"). In that sense, it probably causes harm to use JS crypto, but JS crypt isn't absolutely ineffective.

amalcon 15y ago
It's only a little easier. There are three scenarios I've been able to come up with: The attacker triggers some kind of bug or odd mode in a router. That router happily floods packets to the wrong places, but still only accepts them from the right place. The attacker can decrypt your WiFi plaintext, but not in realtime. You've already received the response from the server by the time the attacker can craft one for you. The attacker is afraid of getting caught (he possibly needs to be on-location, and can't work through an intermediary), and is therefore restricted to passive methods. As it happens, all three of these are pretty unlikely. They aren't impossible, but why put forth a large effort for JS crypto when you could put forth a small effort for SSL?
- marshray 15y ago
  Here are some ways to modify traffic on typical networks, most have command-line or GUI point-and-click attack tools available. Some of these are documented to have been conducted on wide blocks of internet traffic. The attacker broadcasts a SSID of 'Free Public Wifi', or one similar to what you normally use, then DoSes all other access points when you try to use them. The attacker is on the same ethernet broadcast domain and replies to your DHCP query quicker than the legitimate DHCP server does. The attacker poisons the router's ARP cache and impersonates your MAC. The attacker leverages the unauthenticated nature of Spanning Tree Protocol STP. The attacker pwns your home wifi router through a default password on its admin page or any number of other bugs. The attacker messes with your DNS name resolution for sites of interest. Remember that time DNS resolution for some S. American (and a few US) ISPs got routed through the great firewall of China? The attacker advertises a more-specific route for your IP address or that of a target site. Remember when that little ISP in Pakistan took YouTube offline? The attacker could be your ISP working under order of some government. Yours, that of a country you're visiting, or of some territory the packets pass through along the way. Or you could be using a hotel, airplane, library, mobile, etc. internet connection where transparent intercepting MitM proxies are standard fare. How good do you think the hotel staff are at securing that internet billing appliance they bought? And of course, the attacker could always cut a cable somewhere and install a tap.
  - lawnchair_larry 15y ago
    The BGP examples are a little far fetched. Few adversaries have that capability, and when someone fucks with BGP, the world knows about it.
    - tptacek 15y ago
      Wow is that ever far from true.
      - bonzoesc 15y ago
        That was DEF CON 17 when somebody BGP'd the whole LAN through their datacenter in NYC, right?
    - marshray 15y ago
      Just about every ISP in the world, from the backbone providers to small ISPs in Pakistan, has the capability. More often than not, it happens by 'accident'. http://www.renesys.com/blog/2008/02/pakistan_hijacks_youtube_1.shtml http://www.renesys.com/blog/2008/02/pakistan_hijacks_youtube... If you were very selective about it, and pulled it off without any disruption, you could get away without anyone noticing. Or, do it from a third-world ISP, and say "It was an accident whaduyagonnadoaboutit".
    - amalcon 15y ago
      If there are big BGP changes, the world notices. If the BGP for the specific netblock your site is hosted on changes, the world probably does not notice. Your users will see slightly degraded performance (actually, in some cases it will improve), and (presumably) a number in the NSA will be <1% higher for a few minutes, but that's about it. I've worked on software that literally (intentionally) publishes BGP updates every ~10 seconds. It didn't bother anyone, because it wasn't playing with many addresses.
  - tptacek 15y ago
    Now to understand why I like HTTPS/TLS so much: Do all of these things. You still can't break my secure HTTPS channel to Amazon.com.
tptacek 15y ago
No, it isn't. It's actually harder. To intercept a stream, you need only capture a few packets. To passively observe it, you have to position yourself in a place that sees all the packets.
- storborg 15y ago
  You're talking about computational difficulty. He's talking about practicality for people who aren't experts. AFAIK there is no browser plugin that you can download that will help you MITM an HTTP session, whereas there is a browser plugin that will let you passively capture plaintext from said session.
  - tptacek 15y ago
    No, I'm talking about practicality. An attacker can intercept a session simply by controlling any part of the DNS resolution chain. An attacker can passively observe an entire session only by being situated somewhere in the actual path between the victim and the server.
    - storborg 15y ago
      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".
      - tptacek 15y ago
        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.
crdoconnor 15y ago
>At least with JS Crypto, amateurs with Wireshark and Firesheep probably can't steal your stuff. They can't with SSL either.

amalcon 15y ago

It's only a little easier. There are three scenarios I've been able to come up with: The attacker triggers some kind of bug or odd mode in a router. That router happily floods packets to the wrong places, but still only accepts them from the right place. The attacker can decrypt your WiFi plaintext, but not in realtime. You've already received the response from the server by the time the attacker can craft one for you. The attacker is afraid of getting caught (he possibly needs to be on-location, and can't work through an intermediary), and is therefore restricted to passive methods. As it happens, all three of these are pretty unlikely. They aren't impossible, but why put forth a large effort for JS crypto when you could put forth a small effort for SSL?

marshray 15y ago
Here are some ways to modify traffic on typical networks, most have command-line or GUI point-and-click attack tools available. Some of these are documented to have been conducted on wide blocks of internet traffic. The attacker broadcasts a SSID of 'Free Public Wifi', or one similar to what you normally use, then DoSes all other access points when you try to use them. The attacker is on the same ethernet broadcast domain and replies to your DHCP query quicker than the legitimate DHCP server does. The attacker poisons the router's ARP cache and impersonates your MAC. The attacker leverages the unauthenticated nature of Spanning Tree Protocol STP. The attacker pwns your home wifi router through a default password on its admin page or any number of other bugs. The attacker messes with your DNS name resolution for sites of interest. Remember that time DNS resolution for some S. American (and a few US) ISPs got routed through the great firewall of China? The attacker advertises a more-specific route for your IP address or that of a target site. Remember when that little ISP in Pakistan took YouTube offline? The attacker could be your ISP working under order of some government. Yours, that of a country you're visiting, or of some territory the packets pass through along the way. Or you could be using a hotel, airplane, library, mobile, etc. internet connection where transparent intercepting MitM proxies are standard fare. How good do you think the hotel staff are at securing that internet billing appliance they bought? And of course, the attacker could always cut a cable somewhere and install a tap.
- lawnchair_larry 15y ago
  The BGP examples are a little far fetched. Few adversaries have that capability, and when someone fucks with BGP, the world knows about it.
  - tptacek 15y ago
    Wow is that ever far from true.
    - bonzoesc 15y ago
      That was DEF CON 17 when somebody BGP'd the whole LAN through their datacenter in NYC, right?
  - marshray 15y ago
    Just about every ISP in the world, from the backbone providers to small ISPs in Pakistan, has the capability. More often than not, it happens by 'accident'. http://www.renesys.com/blog/2008/02/pakistan_hijacks_youtube_1.shtml http://www.renesys.com/blog/2008/02/pakistan_hijacks_youtube... If you were very selective about it, and pulled it off without any disruption, you could get away without anyone noticing. Or, do it from a third-world ISP, and say "It was an accident whaduyagonnadoaboutit".
  - amalcon 15y ago
    If there are big BGP changes, the world notices. If the BGP for the specific netblock your site is hosted on changes, the world probably does not notice. Your users will see slightly degraded performance (actually, in some cases it will improve), and (presumably) a number in the NSA will be <1% higher for a few minutes, but that's about it. I've worked on software that literally (intentionally) publishes BGP updates every ~10 seconds. It didn't bother anyone, because it wasn't playing with many addresses.
- tptacek 15y ago
  Now to understand why I like HTTPS/TLS so much: Do all of these things. You still can't break my secure HTTPS channel to Amazon.com.

tptacek 15y ago

No, it isn't. It's actually harder. To intercept a stream, you need only capture a few packets. To passively observe it, you have to position yourself in a place that sees all the packets.

storborg 15y ago
You're talking about computational difficulty. He's talking about practicality for people who aren't experts. AFAIK there is no browser plugin that you can download that will help you MITM an HTTP session, whereas there is a browser plugin that will let you passively capture plaintext from said session.
- tptacek 15y ago
  No, I'm talking about practicality. An attacker can intercept a session simply by controlling any part of the DNS resolution chain. An attacker can passively observe an entire session only by being situated somewhere in the actual path between the victim and the server.
  - storborg 15y ago
    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".
    - tptacek 15y ago
      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.

crdoconnor 15y ago

>At least with JS Crypto, amateurs with Wireshark and Firesheep probably can't steal your stuff. They can't with SSL either.