Re: [PLUG] news

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

On 8/10/20 4:55 PM, Rich Freeman wrote:
> On Mon, Aug 10, 2020 at 4:14 PM brent timothy saner via plug
> <plug@lists.phillylinux.org> wrote:
>>
>> "Encrypt everything all the time" is generally not a good stance to take.
>>
>> Encrypt things that should be, like sensitive data? Absolutely. But
>> unquestioned enforced encryption is a generally bad idea because
>> encryption requires trust, which leads to either needing to verify every
>> single site or trusting a central authority. Which can then be a single
>> point of failure, technologically or politically.
> 
> There is no attack that works on an "untrusted" (ie unauthenticated)
> encrypted connection that doesn't also work on an unencrypted
> connection.  There are plenty of attacks that do work against
> unencrypted connections that fail against an unauthenticated encrypted
> connection.

You interestingly leave out authenticated encrypted connections, which
is convenient.

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.

> 
> It makes zero sense to send stuff unencrypted.  Even if you don't
> trust every certificate out there, you're more secure using encryption
> with an untrusted certificate, than you are not using encryption.

Tell that to reverse proxies to localhost, or debugging body payloads on
the wire, or VLAN'd load-balancing targets who want a single point of
TLS termination.

> 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.

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