Google Chrome Encryption

[timbo343]

Let's hope this doesn't get passed [emoji30]

 

https://www.thedrum.com/news/2019/04/21/broadband-companies-and-government-hold-talks-over-new-google-chrome

[Arthur]

What does 'encrypted' mean in this context? The article doesn't provide any technical details.

 

Google's encrypted version of its Chrome browser has sparked concern among a number of internet safety watchdogs and intelligence agencies who fear the move could endanger children's safety online.

 

But with the encrypted version, users are able to bypass the filters and connect to its server instead.

 

Is Google doing what Mozilla have done with the nightly version of Firefox and enabling DNS-over-HTTPS by default or something else entirely?

[free780]

They might prevent MITM https inspection as Android no longer supports this. There were rumours of Apple doing the same for IOS.

[Arthur]

Encrypted version of Chrome = Chrome + DoH.

 

DNS over HTTPS is coming whether ISPs and governments like it or not

 

The penny has finally dropped inside ISPs and governments that a privacy technology called DNS over HTTPS (DoH), backed by Google, Mozilla and Cloudflare, is about to make web surveillance a lot more difficult.

 

In the UK, this matters because under the 2016 Investigatory Powers Act (IPA), ISPs are required to store a record of which websites citizens visit for the previous 12 months, which is done by noticing Domain Name System (DNS) requests, e.g. to xyz.com.

 

DNS over HTTPS (and its close relative DNS over TLS, or DoT) makes this impossible because it encrypts these requests – normally sent in the clear – hence the panic reported in a recent Sunday Times article (paywall).

 

Big ISPs also worry it will interfere with complex Content Delivery Network (CDN) traffic caching, make customer management through support and captive portals difficult, and leave them fielding calls from unhappy customers when the third-party DNS servers offering DoH fall over.

 

Confusingly, the Sunday Times story also says DoH will stymie the UK’s controversial porn block, which enforces age checks before adults can visit big porn sites, although it’s not clear how – encrypting DNS hides the domains people visit but not inherently the fact web requests are being made from UK ISPs (although it would stop ISPs from implementing their own domain filters).

 

DoH’s sudden rise

Filter the hysteria and what you’re left with is a technological conflict between ISPs which have traditionally controlled the first leg of every internet connection and companies that control the software that sits on devices – this is primarily Google but also companies such as Cloudflare and partner Mozilla which promote privacy.

 

Today, users connect to the internet by paying an ISP for a connection. In effect, under DNS over HTTPS, they will then establish a second DNS connection to servers run by companies such as Google and Cloudflare to make web browsing private.

 

It’s come to a head now because Google is in the process of implementing DoH as part of its public DNS system (8.8.8.8/8.8.4.4), which will be supported at some point in the world’s most popular browser, Chrome, and is already supported in Android 9 (this has been possible for some time on older Android versions by using Google’s Intra app).

 

Mozilla, meanwhile, has identical plans for Firefox implemented via Cloudflare’s 1.1.1.1 service, which the company is still testing, while Cloudflare released a dedicated Android/iOS app last year.

 

Currently, if a government agency wants to know which sites you’ve been visiting they can ask an ISP. In theory, under DoH they could do the same by asking Google, Cloudflare or Mozilla.

 

Unfortunately, the problem isn’t simply whether those companies would agree to comply, but whether they could even if they wanted to.

 

For example, Cloudflare has previously said it only logs DNS requests for 24 hours and plans to prove that with a public audit of its behaviour run by KPMG. Compare that to ISPs which in many countries now collect domain data for up to a year.

 

Here to stay?

It should have been obvious that something like DoH was coming, since a slew of proposed technologies for encrypting DNS requests started gathering momentum in 2017. Last October, the IETF formally adopted DoH (aka RFC 8484) as the simplest route for this to happen quickly.

 

Not everyone was happy with this for architectural reasons, not least because it places a lot of trust in the resolver, principally Google, Cloudflare and anyone else who adopts it.

 

Hitherto, the internet has been built as a compromise between what the user could do and what the service provider would let them do. DoH, some claim, upsets this balance.

 

The counter-argument is that too many ISPs and governments have lazily used DNS as a quick surveillance fix, for legal, political but also commercial reasons.

[jthompson]

has sparked concern among a number of internet safety watchdogs and intelligence agencies who fear the move could endanger children's safety online.

 

It could (and should) be argued the other way, too.

[Opendium_Steve]

It could (and should) be argued the other way, too.

I think what's often missed is that there's a big difference between policing what adults do on the internet, and what minors do. What is right for one group is not necessarily right for another.

 

As adults, society expects us to look after ourselves and take responsibility for our own actions - the same is not true of children, who are largely not considered responsible for their actions and are expected to be safeguarded by a responsible adult.

[ibpalle]

Encryption certainly makes life more interesting in the web filter space. Shameless plug here - the new client from Smoothwall (currently Chrome extension only) does not perform MiTM attacks - not needed. It sits as a client extension and sees what the browsers shows, before it show this to the user. The filtering process has moved from sitting on a proxy between client and server, to a local instance on the client, reading browser output and adjusting/blocking before showing end result to the user.

[timbo343]

Encryption certainly makes life more interesting in the web filter space. Shameless plug here - the new client from Smoothwall (currently Chrome extension only) does not perform MiTM attacks - not needed. It sits as a client extension and sees what the browsers shows, before it show this to the user. The filtering process has moved from sitting on a proxy between client and server, to a local instance on the client, reading browser output and adjusting/blocking before showing end result to the user.

 

Any chance you can tell us more about this extension please? Is it available now?

[ibpalle]

The extension is part of the new product range - the unified client is the internal name for it and if all goes according to plan, we should start seeing release to testing internal in a weeks time. I's being rolled out to select customers as well. So not long now.

 

This is one client for Windows, MacOSX and ChromeOS. Currently the filter client is only available as a chrome extension so windows and mac clients enforce that extension installation. We will be working on supporting other browsers. Your account manager will know more about specific release dates.

[timbo343]

The extension is part of the new product range - the unified client is the internal name for it and if all goes according to plan, we should start seeing release to testing internal in a weeks time. I's being rolled out to select customers as well. So not long now.

 

This is one client for Windows, MacOSX and ChromeOS. Currently the filter client is only available as a chrome extension so windows and mac clients enforce that extension installation. We will be working on supporting other browsers. Your account manager will know more about specific release dates.

 

Cheers - there isn't going to be an additional charge for this option is there?

[ibpalle]

Not certain about pricing but unless you need additional infrastructure, like a cloud Smoothwall gui for policy control (If you have an on-prem already, that can be used instead) I believe the cost of the UC is included in the filtering license, but don't hold me to that

[free780]

Interesting. Do you know something certain about Chrome's future we don't?

I'm assuming the extension will work with the new Edge eventually.

 

This won't help with the android situation of blocking https interception.

[Arthur]

Interesting. Do you know something certain about Chrome's future we don't?

I imagine Smoothwall's extension simply makes use of Chrome's webRequest API to intercept and block HTTP/S requests before the browser renders the webpage (like uBlock Origin and many other extensions).

Edited April 29, 2019 by Arthur

[Arthur]

(Firefox + DoH + pfSense + port 53 blocked - HTTPS interception)

 

 

The about:config settings mentioned in the video are:

 

[b]network.trr.mode[/b] = 2
[b]network.trr.uri[/b] (this is the default) = https://mozilla.cloudflare-dns.com/dns-query

 

To enable encrypted SNI you also need to change the following setting...

 

[b]network.security.esni.enabled[/b] = true

 

If Firefox has been setup correctly you should get four ticks on Cloudflare's Browsing Experience Security Check page.

 

[ibpalle]

I am not a dev so not sure about specifics - what Arthur states seem right to me Android obviously won't be affected by this client obviously. Android does not seem to have a lot of use on School devices so it's not on the priority list at the moment. I don't think an iOS client is expected either as iPads are being phased out in most US Schools it seems.

[caffrey]

I'm guessing anything BYOD except Chromebooks will be a no no very soon and maybe even BYOD entirely - wonder what impact this is going to have

[ibpalle]

BYOD filtering is still an option - there will be issues with some apps but most apps have a webpage as well that could be used instead. Whatsapp, facebook for example both will work fine in the browser, just not in the app. Monitoring what users do on BYOD is important but even if HTTPS decrypt is not universally possible on BYOD the information learned can still be useful.

[timbo343]

I have pretty much come the conclusion that BYOD is only just an option on depending on what device you have. Android is getting harder to manage. Windows devices are possibly the easiest at the moment with apple being in the middle.

 

Users will almost favour the Apps on their devices apposed to webpages, that's jsut the nature of what they are used to unfortunately.

[ibpalle]

HTTPS inspection on BYOD can still be performed though and if users wan't access to app functionality and will have to use the web page to get it, then they will, rather than be without. Not without any gripes though, as usual

[Opendium_Steve]

HTTPS inspection on BYOD can still be performed though and if users wan't access to app functionality and will have to use the web page to get it, then they will, rather than be without. Not without any gripes though, as usual

Nope, if users want app functionality and the app doesn't work on the school network, they'll just switch to 4G instead. And once they've switched to 4G you lose the ability to inspect *any* of their traffic.

[free780]

So for BYOD I guess interception is a no go.

[ibpalle]

No, interception is perfectly doable. If the app workaround doesn't suit users first, turn https decrypt off for the app. You can still see they are using it and for how long, just not see content. This keeps them on the BYOD instead of them switching to 4G and you will still get filter log data for their other web access - on 4G you don't get anything at all.

 

As always, there's no 100% here. One or the other is not always the only option. One and the other and the third too even sometimes - that's the way normally in IT

[Opendium_Steve]

So for BYOD I guess interception is a no go.

No, I disagree - its important to intercept web traffic. If your filter does real time content inspection you'll get much more accurate filtering with interception turned on, and the system can profile users based on their web browsing and report on safeguarding risks. This side of things still works under Android too.

 

But most apps can't be intercepted, so your filter has to make an exception for them. That's usually done by examining things like the server name indication (SNI) that the client sends to the web server, which is unencrypted. The filter looks at the SNI and decides whether it should intercept or not. The school has to make a decision about whether they are going to allow unfilterable apps, of course - I've talked about this before, but essentially it boils down to:

 

1. Allow the app, students use the school network for everything, and whilst you can't see that specific app's traffic, you can still see normal web traffic, etc. and can safeguard based on that. But if the student gets up to no good in the app you've allowed, the school may be held liable (even if you're not held legally liable, your name could be dragged through the mud because you "allowed" the students to do bad things on your network).

or

2. Block the app, students drop off onto 4G for everything. Now you can't see any traffic - not even their normal web traffic, and you lose whatever safeguarding abilities you ever had. But if the student gets up to no good, the school can wash their hands of the liability because it's now clearly the parents' fault for giving the kids unfiltered 4G devices, rather than the school's fault.

 

You'll notice that the school's decision doesn't really affect whether or not they use the app in question, it only affects your ability to safeguard and your liability when things go wrong.

 

 

Now, things are going to get a lot harder if TLS 1.3 and DNS-over-HTTPS become mandatory protocols. None of these things will stop interception from working, but they will probably make it much much harder to exclude apps from being intercepted, which in turn means that the apps will probably break. We're not there yet though, and this is why filtering suppliers such as ourselves are really pushing hard to discuss the problem with the likes of Google, Apple, etc. before it becomes an issue. Unfortunately this takes willing people on both sides, and on the Google et-al side they just keep pushing in whatever direction they like with little interest in engaging with anyone who points out the problems with it.

[ibpalle]

Thanks SteveHill

 

Much more elegant and descriptive than what I put down.

[Slum90]

Google have been doing this for many years by using 'QUIC' protocol. Many web filters etc wont inspect some web traffic when this is turned on. We had issues earlier this year meaning a user could access a certain website through our filtering. After further investigation, we turned off this setting and we could see the logs going through and being blocked. Hope this helps