Re: [PLUG] news

[Rich Kulawiec via plug <plug@lists.phillylinux.org>]

1. There's another trade-off here which I haven't seen mentioned (forgive
me if I overlooked it in this discussion).

The big push for the use of encryption on web sites has led to things like
LetsEncrypt which is well-intentioned and good and apple pie and all that.

However...every time another certificate is issued by LetsEncrypt, there's
a side effect: it becomes a better target.  That is: the value of successfully
attacking it goes up by some unknown and unknowable increment.

By February 2020, they'd issued a billion certificates.  What's the value,
on the open market, of control of that?  I'm asking that not-really-rhetorical
question because that number, whatever it is, gives us a clue about what
the potential attacker budget is and who they might be.

It thus also gives us a clue about what the defender budget needs to be and
how good they need to be.  (The correct answers are "large" and "very".)


2. Encryption doesn't solve all privacy issues.  MITM traffic analysis
can still yield useful information about what sites someone's accessing
and which documents on those sites they're fetching.  And of course
if the site itself is compromised -- or compromisable -- which is true
on inspection for anything in the cloud, then privacy is just wishful
thinking.  Given the rate at which we see breach reports (and that what
we see is only the tip of the iceberg) we're a very very long way from
actually having the kind of privacy/security that lots of people are
pretending that we have.


3. Encryption doesn't necessarily make things more secure.  One side
effect of encryption is that it makes things more interesting.  It is
well known, for example, that PGP-encrypted email traffic is much more
interesting than non-PGP-encrypted email traffic.  Consider how this
observation, combined with consolidation of thousands of email systems
into centralized ones, combined with the presence of insiders, yield
an effective outcome that's, shall we say, less than optimal.

Note that even if the encryption can't be cracked that this may still
be an effective attack - because it facilitates traffic analysis.

(For those of you not familiar: consider the universe [A, B, ... Z]
of correspondents.  If we have MITM'd the traffic at the right point or
points, then even if we can't decrypt the messages, we can see that K and
S are exchanging a lot of encrypted messages with each other but almost
none with anyone else.  We can augment that observation with sizes,
rates, timestamps, intervals, etc. and thus extract potentially useful
intelligence.  Repeat over the universe of correspondents and we will
very likely discover patterns and networks.  This in itself can be
very useful, but beyond that: it helps us identify targets for further
research so that we focus our effort on those which are most likely
to be of interest to us rather than blindly going after all of them.
Thus one effect of this is concentration of effort which in turn reduces
the expected time to compromise a particular target.)


4. Encryption can make some things less secure.  Consider the case
of correspondents A and B who are encrypting the email messages
they're exchanging.  One of the side effects of this is that neither
A's nor B's MTAs can check the content of those messages. (Don't read
this as a tacit endorsement of content inspection/message filtering; for
the most part it's a bad idea but there are cases when it's okay.)
Now suppose B's system is breached.  The new owner(s) can also encrypt
email messages with B's key -- thus they'll pass cryptographic
verification by A -- and include a little something extra that's
designed to gain a toehold in A's system by hijacking the MUA, or maybe
to breach some of A's privacy by including a tracking link/web bug.
A's MTA isn't going to be able to do anything about this because the
message in transit is opaque to it.

More elaborate/dangerous variations are left as an exercise.


To put all of these points another way: "encrypt everything by default" is
not by itself a bad idea, but it doesn't take into account a systemic view
that includes networks, servers, clients, people, software, money, etc.

---rsk
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug