On Fri, Oct 17, 2014 at 02:59:26PM -0400, Ian Grant wrote: > On Fri, Oct 17, 2014 at 2:49 PM, Bret Lambert <bret.lamb...@gmail.com> wrote: > > Well, if, as Herr Schroeder seems to be implying, this is used to > > avoid port scans, I'd look for traffic to/from address:port which > > don't show up on scans. > > That's why I want to hide it behind an ordinary service.
The point being, Herr Schroeder appears to be a man who would become one of your users, and has apparently missed that step. A manual that includes an advisory to do so would likely be a good idea. > > >> Also, the VPN could be tunneled > >> over HTTP if necessary. > > > I know of at least one company which sells a product which doesn't > > just read headers, but classifies traffic based upon behavior, e.g., > > "small request receives large response -> bulk transfer", or > > "series of tiny packets which receive a single, larger response -> > > interactive session". I assume nation-states have developed similar > > capabilities. > > That's fine. But they have to analyze all the traffic. This is a > needle in a haystack. It's a good thing we don't know any nation-states that analyze all the traffic, then. That would probably be bad. > > > The ability to use statistical methods to eavesdrop on encrypted > > SIP sessions comes to mind as an example of traffic analysis as a > > tool to defeat adversaries who are attempting to secure their > > communications. > > Again, a needle in a haystack. Assuming that your adversary is going into this blind, and hasn't been given a list of interesting targets that includes your systems. States also have access to human intelligence as well. > > Please read the OP before refuting stuff on the list. If you want to > argue, and you aren't sure of your argument, e-mail me off the list. > Otherwise it just adds to the general level of confusion, which is > already higher than I'd expected on this list. Quoting the original email you sent: > If anyone here has a better idea, or any other useful advice (even if > it's "this has already been done!" or "It won't work," but please > explain exactly why.) or pointers I'm not attempting to refute the validity of what you're attempting, I'm pointing out things that probably should be taken into consideration during implementation/deployment, which I think falls under the heading of "useful advice". Whether or not it's useful is a judgement left to the reader.
