Re: breaking TLS (Was: Re: multiplexing -- don't do it)

I'd imagine that Stephen has some knowledge in the area as well :)

On Fri, Apr 6, 2012 at 12:54 PM, Willy Tarreau <w@1wt.eu> wrote:

> On Fri, Apr 06, 2012 at 05:39:43PM +0100, Stephen Farrell wrote:
> > Detecting/blocking inbound malware is a real requirement. I was asking
> > for evidence that such detection/blocking is happening because of
> > MITMing TLS.
>
> We do have customers asking for this. Their reasoning is simple :
>  - either I can ensure they don't bring malware in ;
>  - or I block the site.
>
> Some sites are generally slightly more trusted than other ones. For
> instance, https to gmail, yahoo, amazon, paypal or banks is trusted
> because they're expected to clean their contents. So you end up with
> the classical 3-level filtering :
>
>  - white-list a bunch of trusted sites
>  - black-list a bunch of other sites
>  - block all other ones or apply MITM if you can
>
> Contrary to a common belief, large corporations don't care a dime what
> you're saying via your webmails, simply because there is far too much
> traffic to have anyone analyze it. What would you expect them to see
> at 1000 req/s ~ 30-50 million req/day ?
>

That is a blanket statement that seems likely to be false given that I'd
guess that none of us has a comprehensive survey of all reasons that people
deploy these controls.



>
> They care about keeping their employees efficient at work, which means
> ensuring they don't break their tool with malware, and they don't waste
> their time on online games and social networks. Of course legal stuff
> is applied too (block access to hate & porn sites).
>

I can think of other motivations off the top of my head.
I believe it is sufficient to note that there is demand for proxies which
can do these things, and to provide each party in the communications chain
the ability to do what is necessary so long as it doesn't breach the user's
trust without the user's knowledge.

-=R


>
> Regards,
> Willy
>
>
>

Received on Friday, 6 April 2012 20:29:36 UTC