[dns-operations] need recommendation for filtering outbound HTTPS

[Grant Taylor]

On 5/15/19 11:44 PM, Paul Vixie wrote:
> right. specifically, if the client is talking to a proxy, it knows it 
> is talking to a proxy, and i have to give it a proxy. i can't make a 
> routing decision based on where it's trying to go without a proxy (some 
> external tcp/ 443 listener) and say, i don't like that destination, 
> please talk to my proxy instead.

I'm not aware of a proxy being able to cause a client to connect to a 
different proxy.  The best that I can think of is for the first proxy to 
return an artificial 302 (et al.) and have the client go through it's 
proxy selection algorithm again and end up on a different proxy server.

> note also, the client can connect to a dotted quad or hexed quadquad, 
> if it knows what address it wants. or it might just connect to a domain 
> name, if it knows it has to use a proxy and doesn't bother to look up 
> the address. this means my proxy has to be prepared to recognize a DOH 
> endpoint by address or by name, in order to decide what to do next.
> 
> that's where it gets truly harsh:

ACK

The various possibilities of IPv4 address representation can get 
interesting.  I wonder if Squid (et al.) can normalize IPv4 addresses to 
traditional decimal dotted quad before applying destination rules.  I 
assume that name resolution would be performed to utilize the same 
destination rules.

> terminologically i've been calling that a downgrade rather than BITW, 
> because the only way i'm going to learn the SNI is if i act like i only 
> understand TLS 1.2 (and not 1.3) after intercepting the CONNECT and 
> forcing it to make its long-distance TLS connection to me instead of to 
> the real (remote) endpoint.  this is what GFW has to do, and it is known 
> to break clients who "know" that their server can speak 1.3. GFW does 
> not care about this breakage, but then, GFW is also blackholing all of 
> google. i do care, and i can't.

ACK

I still don't understand why someone can't emulate the TLS 1.3 endpoint, 
presuming that they have the necessary information.

> i can only get the leak i need if i force the explicit use of a proxy,

Why is that?

It seems to me like you can easily filter all traffic from the client to 
the Internet (be it a single choke point or multiple distributed control 
points) and glean information that way.

> intercept CONNECT toward known DOH names or addresses, and then force a 
> downgrade to TLS 1.2. that is, for me at this time, a bridge too far.

Are you wanting to downgrade TLS 1.3 to 1.2 so that you can avoid the 
eSNI complication?

Note: There is a reasonable chance that my limited understanding of eSNI 
is wrong.

It seems to me like the aforementioned Internet access control point(s) 
can scrape the information necessary from eSNI from traditional DNS and 
provide it to the proxy server.  Especially if said Internet access 
control point(s) explicitly block non-allowed traffic.  Think along the 
lines of SPI, but for egress.

1)  Monitor traditional DNS queries from clients.
2)  Check the QNAME / A / AAAA (chase CNAMEs as necessary) against a 
list.  (IMHO RPZ would be great for this.)
3)  If the name is not black listed, add a temporary rule (state) to the 
firewall to allow the client to connect to the destination.
4)  If the name is black listed don't add a temporary rule.

I think this is going to make it considerably difficult to get to known 
DoT / DoH endpoints.

Yes, I realize that "known" is the Achilles Heal.  But I think it's a 
start and has room for refinement to make it better.

If you can learn the eSNI information from the traditional DNS query, I 
would think that a sufficiently advanced proxy could perform the TLS 1.3 
with eSNI.  (I think.  See above note about eSNI.)

> as far as i can work out from the theory, it's what Palo Alto Networks 
> NGFW has to be doing. jacques from CIRA says this causes him no 
> (enterprise) trouble. i fear it may cause me some (home network) trouble.
> 
> say more? i know it can say "don't use a proxy" but i don't know that 
> it can say "use a proxy if your destination is on the following list of 
> suspicious places".

302
Location:  https://en.wikipedia.org/wiki/Proxy_auto-config

I could try regurgitating here, or I can refer you to more than I can type.

TL;DR:  Clients actively call the FindProxyForURL(…) function to 
identify what they are supposed to connect to.  You can tell some URLs 
to go DIRECTly to the endpoint and others to go a proxy, and everything 
else to go to a different proxy.

Turn your client into an active component of your overall solution. 
Allow traffic to IPs that are told to go DIRECT, and do something else 
with all other HTTP(S) traffic.

> splicing only works if you have an out of band path to the far end to 
> tell it, here's your connection and encryption state, take over for 
> me. that works inside a private or public cloud. it won't work across 
> the WAN internet.

True.

> ...starting a new thread on the last point you've made here.

ACK



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190516/5f3fb920/attachment.bin>