Re: library/binding for sftp?

["Randy Brukardt" <randy@rrsoftware.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 8235 bytes --]

"Björn Persson" <bjorn@xn--rombobjrn-67a.se> wrote in message 
news:20130809104904.6ca91de2@hactar.xn--rombobjrn-67a.se...
>Randy Brukardt wrote:
>> "Björn Persson" <bjorn@xn--rombobjrn-67a.se> wrote in message
>> news:20130808133709.09dfef98@hactar.xn--rombobjrn-67a.se...
>> Dmitry A. Kazakov wrote:
>> >> Firstly, there is no protection against targeted attack. Secondly,
>> >> regarding spies, they aren't any good in programming. Obscuring is
>> >> the best method against unfocused surveillance which works only
>> >> with known protocols.
>> >
>> >Four false statements in a row.
>>
>> There are only three here,
>
>Three sentences, but I see two statements in the third sentence.

There is only one in the third sentence that I see. "best method". The rest 
is a definition.

...
>Let's try to remember the context now. I may have pruned my previous
>post too much, so I'll repeat the statement that Dmitry replied to:

...
>The context was file transfer protocols and Dmitry was arguing that
>"just open a socket and send whatever you want over it" would somehow
>be more secure than SFTP. I read all of Dmitry's statements in that
>context and understood "targeted attack" to mean an attack on a file
>transfer protocol.

That's certainly not how I read Dmitry's messages. Perhaps I was reading 
something into them that wasn't there, but my understanding was that he was 
saying that opening a socket and sending data in a custom protocol would be 
as secure as SFTP, so why bother with the fancy file transfer protocol 
(especially if you're not dealing with files)?

A custom protocol certainly wouldn't have to send plain text.

...
>But it's possible that I misunderstood that statement and your
>interpretation is closer to what Dmitry meant. His statement still
>isn't literally true. It's true that there is no *totally secure*
>defense against a determined attacker *with sufficient resources*, but
>that's not the same as there being "no protection" at all.

It's fairly close, as anyone with a stolen credit card can have sufficient 
resources these days. (Amazon and other clous are cheap and easy.)

>You can have various degrees of protection, just not total protection. 
>Anyway I
>don't see how this is an argument against SFTP. You wouldn't be able to
>fend off a squad of paratroopers coming to take your disk, so don't
>bother to authenticate your file transfers? That's just silly.

There are clearly levels of security. One of them is the "determined 
attacker", and if that is your concern, there isn't much really worth doing.

The other is the general attacker. They're just looking for easy targets, 
and for that the story of the two hikers and the grizzly bear applies (Two 
hikers encounter a grizzly bear which charges them. One of the hikers starts 
to run. The other yells "why are you running, you can't outrun a grizzly 
bear!?", The first hiker replies "No, but I can outrun you!".) You only have 
to have enough security so that you are outrunning a decent percentage of 
the other computers on the internet. So long as it is harder to attack your 
computers than many others, attackers will look elsewhere.

>> And Dmitry's point about spies (like the NSA) using "known protocols"
>> is certainly true. They are much less likely to generally monitor
>> what they don't know about. Of course, if they are targetting you
>> directly, see statement 1.
>
>Of course spies use knowledge of protocols to assemble packets into
>messages and conversations. They'd be stupid if they didn't, and now
>that Edward Snowden has told us about Xkeyscore we know that at least
>the NSA does. It is however naïve to assume that they spy *only* on
>selected "known" protocols. If I were in charge of a surveillance
>agency I would make sure to scan even unknown protocols for selected
>keywords, and to have unknown protocols analyzed to turn them into
>known protocols. I would also map out who communicates with whom
>regardless of protocols, and watch for changes in traffic patterns, for
>example traffic surges indicating that something has happened. I don't
>have any proof that surveillance agencies around the world actually do
>those things, but they'd be stupid if they didn't. Snowden might know,
>if you can reach him to ask.

Sure, you can't hide completely. But why make it easy for them? Just encrypt 
everything and send it directly using sockets (no obvious protocol to 
analyze). If they want you, it will be easy for them to figure it out, but 
most likely, they don't want you (yet), and the gibberish data will be 
unlikely to trigger any filters.

>The simplistic "just connect to a socket" protocol doesn't even qualify
>as an unknown protocol by the way. It's the data channel of FTP, just
>(probably) on another port.

True enough. There is no "unknown protocol" per-se, but there is a port 
sending unstructured data (to an generic scanner). That's what I'm talking 
about, and I presumed Dmitry was talking about (he's not an idiot).

>I'll finish by returning to the beginning of your message where you said:

> at least part of Dmitry's advice matches what I would give.
>
>Not every statement is advice. Dmitry's actual advice was, paraphrased:
>"Don't bother with encryption. Invent a proprietary protocol where you
>send everything in the clear. That will protect your secrets better
>than any encryption. Don't bother with authentication. Nobody will
>figure out how to connect with your proprietary protocol, so you can
>assume that all connections are legitimate." That's the advice that I'm
>calling dangerous. Does that match the advice you would give?

I'd call that dangerous if someone actually gave that advice. But that's not 
close to my understanding of what Dmitry was recommending.

First of all, he's talking about communication in a private application with 
low-value data (not credit card numbers or the like). In that case, the most 
important thing is to have as much code as possible in your direct control. 
For me, that means that unknown libraries ought to be avoided; I want 
everything written in Ada that I can put through checking tools and bring 
all of the advantages of Ada to bear. Something like 75% of the long-lived 
bugs in code I've involved with is in interfacing code. (By "long-lived", I 
mean bugs that don't immediately show up on the first run.) Straight Ada 
code is many, many times more likely to be correct than anything using a 
library.

So, for instance, faced with a choice of using several unknown SFTP 
libraries (both an Ada binding and the library proper, both of which may 
have errors), or using a simple socket connection and Ada libraries for 
encryption and the like, I certainly would lean toward the latter.

Second, I certainly don't think he said anything about skipping encryption. 
It's trivial to encrypt your data with one of the existing encryption 
algorithms written in Ada. (The original AES algorithm proposal was written 
in Ada, and it makes a very good library; I think every Ada programmer 
should have it in their toolbox. Nothing "roll-your-own" about that.)

Third, if your data is valuable enough that it needs authentication 
permission, I think you should think about 100 times about putting it 
on-line in the first place. Authentication will stop script-kiddie attacks, 
but that's about all. If there is much value/danger from having it on-line, 
then don't put it on-line. (What possible good could come from 
Internet-connected door locks? To take one obvious and current example. It's 
a high-value target, and it is guarenteed to be broken into repeatedly, no 
matter how much care the manufacturers put into it. Just don't do it.)

Obviously, many people disagree with me on the value of sharing. And I 
certainly agree that public applications (which includes anything sold to 
the public, even for "private" use) need to use high-security solutions. I 
just don't think that there exist any solutions high-security enough for 
truly critical data.

The real mitigation is to decrease the value of "secrets", but that takes 
algorithmic and operational changes that few want to make. Thus no-security 
will remain the norm.

                                              Randy.