Re: HTTPS

[gremlin () gremlin ru]

On 15-Aug-2013 13:38:01 +0200, Florian Weimer wrote:

> > > 1. Not all interceptions and modifications are evil.
> > > 2. Some sites are much more evil than interceptors.

> > #1 is technically true but because there's no way
> > to programmatically determine if a interception or
> > modification is "evil" systems should default to
> > disallow and allow the user to allow it (by trusting
> > another CA for instance for the interceptor).

Quite simple: I am permitted to intercept my traffic, others
are not. Creating own CA is as easy as several invocations of
/usr/bin/openssl, but I don't see any good reasons for that.

> > I don't understand how #2 relates to HTTPS at all,
> > TLS doesn't state anything about the safety of the
> > server you're connecting to only the safety of the
> > transport.

> If you can't intercept, you don't know what's going on inside
> the TLS channel. A malicious peer might successfully attack
> your user, and you could have thwarted the attack if you had
> access to plaintext communications. (Yes, I understand what
> that sounds like.)

/me too. But I consider that normal for my own network.

> It used to be the case that little malicious content was hosted
> on major (HTTPS) sites, so analysis based on IP addresses and
> domain names was quite effective. This might have changed, though?

It looks like it did... :-/

> all that is needed is one single, large HTTPS-enabled service
> provider that doesn't have adequate abuse mitigation. But I still
> don't think that this is a valid reason not to use HTTPS.

Using the HTTPS is normal. Forcing others to use it is not.

And once again, just to get back on topic: if you get the data with
valid digital signature over the unsafe communication channel, you
can be sure the data wasn't modified in transit, but if you get the
data without digital signature over the trusted communication channel,
you can't be sure at all.

Protect the data, not the communications.


-- 
Alexey V. Vissarionov aka Gremlin from Kremlin <gremlin ПРИ gremlin ТЧК ru>
GPG key ID: 0xEF3B1FA8, keyserver: hkp://subkeys.pgp.net
GPG key fingerprint: 8832 FE9F A791 F796 8AC9 6E4E 909D AC45 EF3B 1FA8