There are important differences too though (beyond the fact that SPA is not encrypting/decrypting traffic for SSH itself). SPA is a UDP authenticator so it cannot be scanned.
No, SPA is the first picture: both SPA and OpenSSH are directly responsive to attacker communications. I don't think "attack surface" is the dispositive argument here (the fact that SPA doesn't protect OpenSSH connections at all is), but either way: SPA is inferior to spiped.
Not exactly. OpenSSH gated by SPA can only be interacted with by an attacker that can either hijack an SPA-authenticated connection, or is on the same network as the SPA client if the client must go through a NAT. This is a fairly limited set of possible attackers. For those not in this set, how can they interact with OpenSSH without first breaking SPA?
SPA is applicable to arbitrary services - not just SSH. Essentially it is a lightweight UDP authenticator, and it can be applied to commercial VPN's, webservers, or anything else. Achieving asymmetric costs on attackers is easily achievable for many such services.
Remember from the article that AFL is being run from a VM. So, my guess is that OS X (host) doesn't know anything about whether what is being written on the VM is a small file or not. There are two possibilities: 1) either the OS X activity monitor is actually measuring disk+cache when it says "disk writes" or 2) disk writes really are happening as fast as shown in the graphs. My bet is the later. What saves things here is the usage of the RAM disk on the guest, since at least that is a clean mechanism for really only using RAM instead of disk - and that carries through from the guest to the host.
You make good points, and I hadn't considered how the VM would affect things. I'm still doubtful that frequent rewrites of the same file would actually hit the flash of the SSD, but with much less certainty. If it is writing this frequently, this seems like a place for an easy optimization of the VM. Or maybe I'm misunderstanding, and it's writing a series of small files rather than rewriting the same one?
On the VM, AFL is rewriting the same small file millions of times, and the fuzzed program is reading this file from disk (as opposed to stdin). I think the main question is why does the OS X activity monitor show a massive spike in disk writes when AFL is started and a corresponding decrease when it is stopped? This is 100% reproducible, and the magnitude of the change is unmistakable. It is absolutely clear that the spike in disk writes is due to AFL activity. Further, this same spike does not happen when running under a RAM disk on the VM. I'm confident you would see the same result. So, either the OS X activity monitor has some special way to measure caching in the VM and that is what it is showing (surely this is unlikely), or the writes really are hitting the SSD when not running under the RAM disk. If not the later, what other (realistic) possibility is there?
How about this interpretation (which is only a guess, although I think it's likely):
Activity Monitor does not distinguish between cache hits and misses, and counts the number of reads and writes to the host filesystem rather than summing the requests to the physical devices. Parallels presents the guest with a virtual filesystem, and the device driver for this filesystem does no caching of its own, as this would waste memory due to double caching. Instead, it merely passes requests through to the real filesystem on the host. These requests (read or write) produce system calls, and this is what is being reported in Activity Monitor regardless of whether they use the page cache or physical SSD.
One way to test this would be to use DTrace, which can distinguish between requests to the filesystem and activity that reaches the device. The scripts "hfsslower.d" and "iosnoop" are here: http://dtrace.org/blogs/brendan/2011/10/10/top-10-dtrace-scr...
Ok, that sounds like a reasonable alternative, and Brendan Greeg is certainly a powerful force in this area. I'll run dtrace and see what happens, but I'm going to let a current long-running fuzzing run finish first.
First, let me state that I have a lot of respect for Moxie. That out of the way, knockknock is not above criticism too:
1) It is possible to mount a MITM attack against knockknock just by intercepting a knockknock packet, changing the source IP, and retransmitting. This is a consequence of knockknock not encrypting the source IP within any payload (which involve only packet headers in the knockknock implementation). fwknop does not suffer from this problem because it encrypts the IP to be allowed within the SPA payload.
2) You mention time synchronization issues above. Well, knockknock uses AES in CTR mode, and this also requires synchronization between the client and server of a different kind. If synchronization were a problem for fwknop, then you must apply this critique to knockknock too.
You _can_ disable time sync in fwknop if you really want to, but it was added to prevent MITM attacks.
Here are the design goals that fwknop is developed around:
I agree that there are certainly a number of tradeoffs involved, and reading the design goals you linked, I see that (in particular) the desire to be able to run fwknop on OpenWRT and other particularly resource-constrained setups makes a strong argument for your implementation strategy.
Your comments on MITM and synchronization are well-received. It's clear that you take the security of the fwknop implementation seriously, and I apologize if I was overly negative. I should have read more about the design goals before criticizing the project so harshly.
For what it's worth, in place of my first comment, I should probably instead say that fwknop was not a good fit for my needs at the time, but that there certainly exist cases where it will be an excellent solution, and to watch out for a practical gotcha I learned the hard way. :)
