Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #4362 > unrolled thread

Selective HTTPS blocking

Back to article view | Back to comp.os.linux.networking

Contents

  Selective HTTPS blocking Clark Smith <noaddress@nowhere.net> - 2019-04-15 15:21 +0000
    Re: Selective HTTPS blocking Dan Purgert <dan@djph.net> - 2019-04-15 15:26 +0000
      Re: Selective HTTPS blocking Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-04-15 20:32 +0000
        Re: Selective HTTPS blocking Grant Taylor <gtaylor@tnetconsulting.net> - 2019-04-15 14:55 -0600
          Re: Selective HTTPS blocking William Unruh <unruh@invalid.ca> - 2019-04-15 21:18 +0000
            Re: Selective HTTPS blocking Grant Taylor <gtaylor@tnetconsulting.net> - 2019-04-15 21:39 -0600
          Re: Selective HTTPS blocking Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-04-20 12:02 +0200
            Re: Selective HTTPS blocking Grant Taylor <gtaylor@tnetconsulting.net> - 2019-04-20 10:40 -0600
    Re: Selective HTTPS blocking Grant Taylor <gtaylor@tnetconsulting.net> - 2019-04-15 10:26 -0600
      Re: Selective HTTPS blocking Grant Taylor <gtaylor@tnetconsulting.net> - 2019-04-15 14:57 -0600
    Re: Selective HTTPS blocking andywhycare@gmail.com - 2019-05-02 02:48 -0700

#4362 — Selective HTTPS blocking

	Let's say that I am in charge of managing an organization where 
users have outgoing Internet access. The organization has strict policies 
concerning what it is that the users can and cannot access in the 
Internet. In particular, the organization has the following requirement:

	Users are free to access https://www.somesite.com, but NOT 
https://www.somesite.com/rogue-page. Any attempts to access this specific 
page MUST be blocked, whereas attempts to load any other pages from the 
site above must be allowed unimpeded. 

	Question: Can this policy be implemented WITHOUT TLS packet 
inspection?

[toc] | [next] | [standalone]

#4363

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Clark Smith wrote:
> [...]
> 	Users are free to access https://www.somesite.com, but NOT 
> https://www.somesite.com/rogue-page. Any attempts to access this specific 
> page MUST be blocked, whereas attempts to load any other pages from the 
> site above must be allowed unimpeded. 
>
> 	Question: Can this policy be implemented WITHOUT TLS packet 
> inspection?

Nope.


-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAly0oqYACgkQjhHd8xJ5
ooG0NAf/R7zum2wYdxqMR7HCac5qi5gSLmNZPCl+5Tzv7MRxX1gv2Thi9KZa+5bO
ygTNe5q+4MqMvb9phz79GX5HtXS8V73Y2rDQWxJNeIoHD9HlNqSnBpNpztK5ZCLP
/l3XdLsUq+E33pSPwARwtJfFF7I7GM45tZvLMXQSAPQ78D0D5J9KSnXVlYBVcKYY
JxmCrsxdRB1UQ4oNhkIrGv9oxIvWCU19jiL060+qOYDR3Zi0C185xd5F2BxAe4SC
D67cat/2zsW0tBXkjPT3SGNUdwj/r0EhWSZzqB0J0Dm3z+XONMzzVPDhxMrRWJ/H
00BOUDi3/ylO8fu5dIfkaGZWc0RJEQ==
=x2LC
-----END PGP SIGNATURE-----

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#4365

On Mon, 2019-04-15, Dan Purgert wrote:
>
> Clark Smith wrote:
>> [...]
>> 	Users are free to access https://www.somesite.com, but NOT 
>> https://www.somesite.com/rogue-page. Any attempts to access this specific 
>> page MUST be blocked, whereas attempts to load any other pages from the 
>> site above must be allowed unimpeded. 
>>
>> 	Question: Can this policy be implemented WITHOUT TLS packet 
>> inspection?
>
> Nope.

I don't know a lot about TLS, but it seems to me it would be pretty
worthless if it allowed someone in the middle to read and filter the
URLs.

Isn't this kind of thing normally done by forcing everyone to go
through a proxy (explaining first that their https sessions aren't
secure after all)?

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#4366

On 4/15/19 2:32 PM, Jorgen Grahn wrote:
> I don't know a lot about TLS, but it seems to me it would be pretty 
> worthless if it allowed someone in the middle to read and filter the URLs.

Agreed.

SSL / TLS makes it extremely difficult for someone not at either of the 
SSL / TLS endpoints to know anything about the connection other than the 
fact that it exists and what the (outer) URL hostname is.

Remember, until Encrypted SNI becomes a thing, that it's possible to 
tell what the certificate ≈ hostname being connected to is.

I say "outer" above, because there's nothing that prevents connecting to 
one certificate ≈ hostname and then using that server as a standard 
HTTP(S) proxy server to connect to another hostname.  This is HTTPS 
protected HTTP(S) proxy service, commonly called "Domain Fronting".

> Isn't this kind of thing normally done by forcing everyone to go through 
> a proxy (explaining first that their https sessions aren't secure 
> after all)?

Usually.

It looks like it may be possible to use Proxy Auto Configuration to 
filter on the path in the URL /if/ the client browser is complicit. 
Read:  If someone doesn't mess with what enterprise IT configured the 
browser to do.



-- 
Grant. . . .
unix || die

[toc] | [prev] | [next] | [standalone]

#4368

On 2019-04-15, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
> On 4/15/19 2:32 PM, Jorgen Grahn wrote:
>> I don't know a lot about TLS, but it seems to me it would be pretty 
>> worthless if it allowed someone in the middle to read and filter the URLs.
>
> Agreed.
>
> SSL / TLS makes it extremely difficult for someone not at either of the 
> SSL / TLS endpoints to know anything about the connection other than the 
> fact that it exists and what the (outer) URL hostname is.

But you said that you wanted to filter by the web page that was being
looked up at the host. So, just because the packets were going to that
host, it does not mean anything, since you have no idea which web page
is being looked up. And this also does nothing if the user uses a VPN to
get to that host and its web pages. 

>
> Remember, until Encrypted SNI becomes a thing, that it's possible to 
> tell what the certificate ≈ hostname being connected to is.
>
> I say "outer" above, because there's nothing that prevents connecting to 
> one certificate ≈ hostname and then using that server as a standard 
> HTTP(S) proxy server to connect to another hostname.  This is HTTPS 
> protected HTTP(S) proxy service, commonly called "Domain Fronting".
>
>> Isn't this kind of thing normally done by forcing everyone to go through 
>> a proxy (explaining first that their https sessions aren't secure 
>> after all)?
>
> Usually.
>
> It looks like it may be possible to use Proxy Auto Configuration to 
> filter on the path in the URL /if/ the client browser is complicit. 
> Read:  If someone doesn't mess with what enterprise IT configured the 
> browser to do.
>
>
>

[toc] | [prev] | [next] | [standalone]

#4369

On 4/15/19 3:18 PM, William Unruh wrote:
> But you said that you wanted to filter by the web page that was being 
> looked up at the host.

No, /I/ did not.  The /OP/ did.  I'm not the OP.  ;-)

> So, just because the packets were going to that host, it does not mean 
> anything, since you have no idea which web page is being looked up.

I agree that a MitM can do little with encrypted traffic.  The only 
thing that doesn't break crypto is to watch the SNI information.

> And this also does nothing if the user uses a VPN to get to that host 
> and its web pages.

I don't know how a VPN would integrate with something like the Proxy 
Auto Configuration choosing proxies based on the path in the URL.  Nor 
do I know how it would interact with something like uBlockOrigin.

Seeing as how the PAC and uBO are in the browser, before the VPN would 
take effect, I suspect they might have some useful effect.



-- 
Grant. . . .
unix || die

[toc] | [prev] | [next] | [standalone]

#4370

Le 15/04/2019 à 22:55, Grant Taylor a écrit :
> 
> Remember, until Encrypted SNI becomes a thing, that it's possible to 
> tell what the certificate ≈ hostname being connected to is.

Even if the server disables SNI ?

[toc] | [prev] | [next] | [standalone]

#4371

On 4/20/19 4:02 AM, Pascal Hambourg wrote:
> Even if the server disables SNI ?

In some ways, disabling SNI makes it easier and harder to identify the 
traffic.  Easier in that there will likely be one certificate per IP. 
Harder in that you need to know what name is resolving to said IP.

The latter might not be as problematic if you have DNS data to associate.



-- 
Grant. . . .
unix || die

[toc] | [prev] | [next] | [standalone]

#4364

On 4/15/19 9:21 AM, Clark Smith wrote:
> Let's say that I am in charge of managing an organization where users 
> have outgoing Internet access. The organization has strict policies 
> concerning what it is that the users can and cannot access in the 
> Internet. In particular, the organization has the following requirement:

I'm sorry.

> Users are free to access https://www.somesite.com, but NOT 
> https://www.somesite.com/rogue-page. Any attempts to access this specific 
> page MUST be blocked, whereas attempts to load any other pages from the 
> site above must be allowed unimpeded.

Oy vey.

> Question: Can this policy be implemented WITHOUT TLS packet inspection?

/Without/ TLS MitM is going to be difficult.

In fact, the only thing that I can think of to even remotely try would 
be something like Proxy Auto Configuration (PAC).  I'm not even aware if 
that can work on a per page basis, or if it's only per site / hostname.

You /might/ be able to leverage something like uBlockOrigin with some 
sort of custom list.  But I've never looked at doing anything like that, 
much less have any confidence.

In short, you're going to need client cooperation.  Or at least 
reasonable trust that client's won't modify what you install / configure 
from a organizational level.



-- 
Grant. . . .
unix || die

[toc] | [prev] | [next] | [standalone]

#4367

On 4/15/19 10:26 AM, Grant Taylor wrote:
> In fact, the only thing that I can think of to even remotely try would 
> be something like Proxy Auto Configuration (PAC).  I'm not even aware if 
> that can work on a per page basis, or if it's only per site / hostname.

The following page makes me think that Chrome and Firefox do have the 
capability to choose proxies via the Proxy Auto-Configuration (PAC) 
file.  Said capability may be disabled by default.

Link - Proxy Auto-Configuration (PAC) file
  - Proxy Auto-Configuration (PAC) file



-- 
Grant. . . .
unix || die

[toc] | [prev] | [next] | [standalone]

#4378

All places I worked in, did MitM inspection on upstream HTTPS.
Someone mentioned client cooperation here. Good idea. 
Lets me think about black/white listing right on the browser.
Theoretically possible, if endpoint security can be enforced up to using a certified browser and config only.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.networking

csiph-web