Follow @Openwall on Twitter for new release announcements and other news
[<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.