Re: [saag] Ubiquitous Encryption: content filtering

[Natasha Rooney <[e-mail]>]

Hi all!

Thanks for the comments on this. I rewrote some items given some feedback I received (Joe: I am worried that I didn’t expand on your points enough, please let me know if I should add something!):


2.3.X Content Filtering
Service Providers may, from time to time, be requested by law agencies to block access to particular sites such as online betting and gambling, sites promoting anorexia, or access to dating sites.*1 Content Filtering can also happen at the endpoints.

Content filtering in the mobile network usually occurs in the core network. A proxy is installed which analyses the transport metadata of the content users are viewing and either filters content based on a blacklist of sites or based on the user’s pre-defined profile (e.g. for age sensitive content). Although filtering can be done by many methods one common method occurs when a DNS lookup reveals a URL which appears on a government or recognised block-list. The subsequent requests to that domain will be re-routed to a proxy which checks whether the full url matches a blocked url on the list, and will return a 404 if a match is found. All other requests should complete.

Even in encrypted connections transport and lower layer metadata is able to be viewed so for many systems content filtering should be able to continue. Cases when they may not work is when TLS proxies are being used which obscure metadata with the proxy metadata, and future versions in HTTP and TCP may encrypt metadata again stopping content filtering software from working (this is currently not the case and has not been standardised). *2

Some sites involve a mixture of universal and age-sensitive content and filtering software in these cases may use more granular (application layer) metadata to analyse and block; this will not work on encrypted content.


I wanted to add two more sentences, but an IETFer gave me some advice today to say that I should only state facts, and not any leading or presumptive items, in such a submission. In which case I removed these two sentences, but you may find it benefit to include them:


  *   "Some mobile operators utilising licenced spectrum must adhere to regulations set by the government licensor, which include content filtering, or risk fines/licence suspension" at *1
  *   "Regulators that impose these censorship rules may look for other means if current methods stop working." at *2.

Also, I am happy in knowing that IETF won’t work on mitigating any sort of censorship, just that this exists as a reference. I also liked the idea of returning information to the user about what is happening so they can make decisions about their browser, provider, or who they’re voting for! Comments always welcome - thanks for the responses so far!

Natasha


Natasha Rooney | Web Technologist | GSMA | [e-mail]<mailto:[e-mail]> | [phone] | @thisNatasha | Skype: [e-mail]<mailto:[e-mail]>
Tokyo, Japan


On Jun 23, 2015, at 11:48 AM, Kathleen Moriarty <[e-mail]<mailto:[e-mail]>> wrote:



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

> On Jun 23, 2015, at 11:59 AM, Kathleen Moriarty <[e-mail]<mailto:[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


This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call [phone] and highlight the error.