Re: [saag] Ubiquitous Encryption: content filtering

[Kathleen Moriarty <[e-mail]>]

On Tue, Jun 23, 2015 at 5:20 AM, Yoav Nir <[e-mail]> wrote:

>
> > On Jun 23, 2015, at 11:59 AM, Kathleen Moriarty <
> [e-mail]> wrote:
> >
> > Thanks for the discussion on this, it's helpful to get this right for
> documentation purposes.  I'd split out MiTM activities of this sort for
> enterprises vs. the same done at the service provider level because of
> employee agreements.  I also choose not to go to many sites from behind a
> firewall and hope others do too when signaled that there is a certificate
> mismatch.
>
> I’m not sure if that distinction is meaningful. The technology for
> interception is the same whether it is used to scan downloaded files for
> malware or to scan Facebook posts for insufficient appreciation of our Dear
> Leader.
>

Sure, I'm aware the same technique is sometimes used for both scenarios,
but not always.  It's easy for a company with an agreement to set up a
proxy that has 2 TLS sessions, one between the user and proxy and the other
from the proxy to the destination site.  Other techniques have been used
(see UTA's TLS attack RFC - 7457) at the service provider level, including
stopping the STARTTLS negotiation.

Some have used techniques that are less visible to the user.  As problems
are fixed in the protocol, what is done shifts of course.



> Employees in a corporate environment are supposedly informed, but
> corporate computers and devices may come pre-installed with the
> interception certificate. Even as a conscientious vendor, there is no way I
> can enforce that corporate IT properly informs the employees.
>

I'm sure this varies between regions.  I just think enterprises can be more
deliberate about it with user agreements and not worry about error
messages.  Sure, the sam thing can be done in a pre-installed way, but a
user can check the certs if they know enough.


>
> Similarly, we’ve seen interception used at service providers at the behest
> of governments. In some countries devices come pre-installed with the
> government interception certificate. This makes it transparent to the
> citizens. Again, it would be nice if citizens at least knew this was
> happening, but those governments tend to not be “nice”.  At least ISPs
> don’t have the power to manipulate the endpoints (though in the early days
> of broadband they would ask you to install a “dialer” - if I were a more
> suspicious person…), but they do when they work for the government.
>

Yes and that's scary.  I think the distinction is acceptability of the
approach in environments like work, since your time is paid for.
Documenting this in two stages would be good as approaches to resolve may
be different.  The TLS 1.3 work to use pre-shared keys negotiated via DNS
should certainly help on this angle.  Enterprises may choose to block
access to some sites, where other options might be used by governments or
others trying to MiTM traffic.


>
> Ideally a solution would reveal the presence of a MITM to both client and
> server.


That would be good.

> All solutions discussed thus far can reveal things to the client, but do
> nothing for the server. I would like to have servers such as financial
> institutions and medical services be able to enforce a policy where they
> don’t provide a service through a middlebox. Doing it now requires
> installing their own client on the user’s machine, which seems to be a
> trend in mobile, but is not something we should require.
>
> Yoav


Thanks,
Katheen



-- 

Best regards,
Kathleen