This was an informative video, especially wrt unikernels. Certainly this Haskell implementation can be a useful research tool.
However, the author strongly implies that it would/could be a "good thing" having this other implementation running in the wild, side by side with the current implementation. But doesn't research suggest multiple implementations tend to widen the attack surface. Unfortunately I don't have access to academic research. Does anybody have relevant citations? I only have a reference to a video of Patterson/Sassaman talking about it wrt langsec: https://www.youtube.com/watch?v=Rk0vpTGFr9Y And here's the relevant snippet: Meredith: ...another boundary that tends to be ripe for problems is when you have multiple implementations of the same protocol. This was what we had a lot of fun with last year between nss, cryptoapi and openssl. Len: Because you wind up with a situation where they're not all speaking the same protocol. They're all speaking versions of the same protocol in-- in most cases-- mutually intelligible dialects. However, if you can wind up with situations where one implementation of the same protocol parses the same input data in a different way than a second implementation of this same protocol parsing this same input data, you now have-- first of all-- proved that they're not identical-- and secondly you've got a point of weakness. We refer to this as "differential parse string attacks." We'll have a slide on that later, but this allows you to pinpoint the area where there's likely to be some manoeuvrability to build an attack. This is where your attack vector is likely to be because you can confuse the recipient by crafting an expression of some sort of payload for this packet so it means one thing that's safe to the one implementation. In x509 we had the problem of-- as we mentioned before-- openssl pretty much doing things correctly: parsing things as they were-- we've got string literals here, we've got this null character-- obviously that's a character and we're going to treat it as such and validate against everything after it. We were not going to ignore it. The problem, though, was we got special rights based on that-- the signing of our csr. And then we turned around and had a different implementation parse those same parts. They parsed them differently, and differently in such a way that it escalated privilege for us. So had openssl been doing things as identically but as haphazardly as the browsers, the attacks probably would not have been possible. Or, most of them. Meredith: It's a little bit unexpected, but if everybody's doing something wrong the same way, then it's actually not as bad. if one person is doing things right and everybody else is doing things wrong, then you actually end up playing them off each other. *** -Jonathan On Friday, March 18, 2016 12:19 AM, grarpamp <grarp...@gmail.com> wrote: On 3/17/16, Erik de Castro Lopo <mle+to...@mega-nerd.com> wrote: > http://www.infoq.com/presentations/tor-haskell > an implementation of Tor written in Haskell and running on a > Haskell unikernel called HaLVM. Add it here, and get this page linked to the front, or at least not orphaned... https://trac.torproject.org/projects/tor/wiki/doc/ListOfTorImplementations -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
