On 02 Dec 2015, at 02:09, Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost> wrote: > Niels Möller <nisse%lysator.liu.se@localhost> writes: > >> The ssh transport machinery can encrypt these, then split them into fixed >> size blocks and send off with pre-determined intervals, and whatever else you >> think is a useful counter measure to traffic analysis. When an input message >> or message fragment is too short, insert ignore messages (preferable in >> *front* of the real data, for the byte-by-byte dribble attack). > > The important point there is that it *can*, not that it actually *does*. I've > heard that there was an OpenSSH patch some years ago that did something like > this, but in about 15 years of interop-testing my code I've never seen any > evidence that the other side is applying any traffic-analysis countermeasures. > A quick Google turns up this blog post from a few months ago: > > http://malwaremusings.com/2015/07/13/traffic-analysis-openssh-with-an-interactive-shell/ > > which indicates that OpenSSH doesn't implement traffic-analysis protection > (not trying to single out OpenSSH here, but that seems to have the most bells > and whistles added to it so if it was implemented I'd sort of expect to see it > there first), and that some random guy with a copy of Wireshark (not an > intelligence agency, if that's what the perceived threat is) doesn't have much > problem in doing traffic analysis on it. > > So there appears to be either zero or close to zero support out there for > anti-traffic-analysis. Even if, say, OpenSSH were to add support, that would > only affect two similar OpenSSH implementations talking to each other. As > soon as you get a single other SSH implementation involved (and there are a > lot of them out there), you lose the anti-traffic analysis. That’s only the case with your approach of leaving all headers (SSH or TLS) in cleartext. With cleartext headers, any SSH or TLS implementation that fails to do padding gets basically no traffic analysis protection at all, even if its communication partner does. It’s indeed partly an “ecosystem problem” as Eben Moglen would say, and in the long term we need to try to fix that, but it’s hard. With encrypted headers, however, *every* SSH or TLS conversation can get at least some (admittedly weak but still useful) protection against at least passive traffic analysis. As many have said already, not all attackers are active MITM attackers; we need to care about passive attackers as well. And as I pointed out on the TLS list, TCP segments can be desynchronized from SSH or TLS records for many reasons and in a variety of points in the network, either intentionally or unintentionally: e.g., in the SSH or TLS implementation, in the TCP stack (by merging adjacent or time-proximate writes), or in middleboxes that resegment TCP streams. Even if none of those network elements are *intentionally* trying to provide traffic analysis protection, even just the fact that they are sometimes unintentionally “messing up” the TCP segmentation boundaries makes things at least a bit harder and more noisy for passive attackers who only get to watch segments fly past and don’t get to mount dribble attacks and such. And a single administrator can deploy a middlebox at the edge of a corporate or campus network to provide even better (still weak but better) traffic analysis protection for all SSH/TLS traffic crossing that middlebox, by deliberately delaying TCP segments just slightly and re-segmenting them on uniform MTU-size boundaries. But only if SSH maintains encrypted headers, or if TLS adopts encrypted headers. >> I'm happy to discuss the tradeoffs here, but it seems that you keep repeating >> that the attacker gets as much useful info from observing tcp segment >> boundaries as from observing ssh message boundaries. > > At the moment it seems they do. Unless actual, real countermeasures to > traffic analysis are actively applied by as many SSH implementations as > possible, encrypting the headers does nothing more than inconvenience > implementers. > > So, let's turn this around: Show me evidence of assorted SSH implementations > performing anti-traffic-analysis measures, and then we can debate whether > encrypting the length hinders those countermeasures. Your point that “serious" anti-traffic-analysis measures such as uniform padding are (currently) rarely implemented, which I believe, only makes the case stronger that we need to do everything we can to make traffic streams coming from that vast majority of non-traffic-analysis-protected implementations even just a bit more protected “at the outset” from even a subset of traffic analysis attackers. Security is not a black-or-white, all-or-nothing thing where you might as well give up unless you can win the whole war in the first battle. B > > Peter.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature