[Cryptography] Encryption opinion

[ianG]

On 26/08/2014 23:29 pm, Paul Ferguson wrote:
> On 8/26/2014 3:15 PM, Bear wrote:
> 
>> HTTPS is NOT an effective protection against MITM.  Furthermore, 
>> MITM is easier, not harder, to address than phishing, and even if
>> HTTPS were effective protection against MITM it still would not be
>> an effective protection against phishing.
> 
> The real "in the middle" threat these days is credential-stealing
> Man-in-the-Browser (MitB) malware, such as most modern day banking
> Trojans (ZeuS, et al).
> 
> This is truly "in the middle" insofar as the attacker is actively and
> surreptitiously part of the end-to-end session.


It's curious that you say that.  In MITM there are the two end nodes and
a node in the middle.  When MITB takes over Alice's node, he isn't in
the middle anymore, he's Alice's node.

The sort of working assumption that was behind the common thinking of
the times, aka ITM or Internet Threat Model, was:

======
    Designers of Internet security protocols typically share a more or
less common threat model. First, it's assumed that the actual end
systems that the protocol is being executed on are secure. Protecting
against attacks where one of the end systems is under the control of the
attacker is extraordinarily difficult, if not impossible. This
assumption comes with two caveats. First, compromise of any single end
system shouldn't break security for everyone. There should be no single
point of failure. For instance, if an attacker breaks system A, then all
communications between B and C should be safe. If we must have a single
point of failure it must be possible to harden it against attack.
Second, attackers may control systems that attempt to pose as legitimate
end systems. All we're assuming is that users can expect that their own
machines haven't been compromised.

Other than that, we assume that the attacker has more or less complete
control of the communications channel between any two machines. ...

Eric Rescorla, _SSL and TLS -- Designing and Building Secure Systems_
http://www.iang.org/ssl/rescorla_1.html
=======


Although I wouldn't swear to it, when Philipp was writing his essay on
MITB in 2007 or so, it got christened with a new title because the
attack wasn't an MITM and it wasn't phishing either.  But in order to
grab attention it was felt that a term closer to MITM was more sexy
whereas something like "New Developments in Phishing" was already too
boring for words.

So, terms matter.  In using the term MITM narrowly or broadly, or new
terms such as MITB, we are framing the conversation.  We're making
statements about whether it is IN or OUT of our bailiwick.  And we're
making statements as to who is responsible for it.


=======
    An obvious corollary of the assumption that the attacker can modify
traffic is that the attacker can shut down all communications between
any pair of machines simply by removing all relevant packets. This is
one form of denial-of-service attack. Another form would be to force you
to use up enormous CPU resources responding to connections.
Conventionally, protocol designers don't worry about denial-of-service
attacks not because these attacks aren't important but because they're
extraordinarily difficult to prevent.
=======


So, back in those days, us protocol designers totally ignored DOS.  And
node compromise, and all sorts of other things.  Now we know better.
Now we know that even if we can't do much about it, the attacks outside
will frame the security result of our protocol.  And, attackers don't
care what we label it.



iang