[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <520CBD99.2090208@redhat.com>
Date: Thu, 15 Aug 2013 13:38:01 +0200
From: Florian Weimer <fweimer@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: HTTPS
On 08/15/2013 12:40 PM, Donald Stufft wrote:
> On Aug 15, 2013, at 6:31 AM, gremlin@...mlin.ru 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).
>
> 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.)
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—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.
--
Florian Weimer / Red Hat Product Security Team
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
