Re: [PLUG] news

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

On Tue, Aug 11, 2020 at 1:18 PM brent timothy saner
<brent.saner@gmail.com> wrote:
>
> On 8/11/20 12:49 PM, Rich Freeman wrote:
> > On Mon, Aug 10, 2020 at 5:15 PM brent timothy saner
>
> >> Step 1: "I have more trust (as a person/org) in this connection, because
> >> it is encrypted and authenticated."
> >> Step 2: Flaw/vulnerability in verification or encryption
> >> Step 3: "I now trust (as a person/org) this fraudulent connection more
> >> than other connections."
> >>
> >> You've now granted more trust *value* to the compromised connection than
> >> to the unencrypted connection.
> >
> > Rightly so, because if you have the ability to exploit a vulnerability
> > in step 2 with an encrypted connection, you can exploit the same
> > vulnerability in an unencrypted connection.
> >
>
> The attack mentions an attack directly on the encryption.

Ok, I assumed you were referring to an encryption vulnerability that
allowed you to modify or read the contents of the connection.  If
you're just exploiting the SSL libraries on one of the endpoints then
I agree that attack surface doesn't exist if you aren't using SSL.  Of
course, SSL libraries are some of the most heavily-tested code in
existence, as testified to by the sheer number of vulnerabilities
reported in them.  Chances are that whatever application you're using
it on top of hasn't had nearly as many vulnerabilities fixed in it.

> The trust value you have placed on this is greater than the trust value
> on a plaintext connection. Meaning you have *more* data/access afforded
> to it. Which is now accessed, and is less likely to throw alarms because
> it wasn't treated with the same level of paranoia, for the lack of a
> better word, than the plaintext channel was.

Why would you put more sensitive data in a communications simply
because it is encrypted?

Obviously not transmitting sensitive information protects it.
However, transmitting it encrypted is certainly more secure than
transmitting it unencrypted.

Just because this email is probably using TLS over most of its travel
doesn't mean that I feel compelled to stick my credit card info in
it...

>
> I think X.509 is pretty broken as a model, partly for the complete trust
> one places in CA trust, and enforcing it as the de facto is going to
> lead to some unexpected results.

++

> I'm not advocating for never using it, I'm advocating for nuance -
> context, risk assessment, and the like - rather than a blind and blunt
> approach with no consideration for foresight.

Absolutely, if you want to selectively use a more secure system that
makes complete sense.

If you're arguing for just sending stuff in the clear because x.509 is
broken, that makes no sense, because the only bad thing that happens
when x.509 breaks is that your data is effectively sent in the clear,
which is what you're proposing as an alternative.

-- 
Rich
___________________________________________________________________________
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