Re: [PLUG] news

[brent timothy saner via plug <plug@lists.phillylinux.org>]

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.

You're referring to the implicated additional attack on the TLS-tunneled
layer underneath (or "inside", more accurately).

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.

>>> Can somebody execute a MITM attack against an unauthenticated
>>> encrypted connection? Sure.  However, they can't just passively
>>> evesdrop on the connection, which they can do with an unencrypted
>>> connection.
>>
>> Which is my entire point, yes. As mentioned, you now have no option to
>> do that and place your entire trust chain in the hands of an external
>> party, unless you want to install your CA on all machines of your org.
>> Which is certainly a possibility, but the intranet is (should be) lower
>> risk than internet.
> 
> I'm not really sure what you're taking issue with here.
> 
> Is your argument that you don't like the design of web browsers where
> CA trust is an all-or-nothing proposition?  If so I agree with you,
> but that isn't an issue with encryption - it is an issue with how it
> is implemented in a specific context.  Browser encryption is pretty
> terrible - about the only thing that is worse is not using it at all,
> which seems to be what you're advocating for.
> 

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.

Attachment: signature.asc
Description: OpenPGP digital signature

___________________________________________________________________________
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