Managing HTTPS Traffic from Browser Based Tools Like indown.mobi

[Rashad Higgins]

A discussion point I wanted to raise with the network architecture community around how enterprise network designs should account for browser based social media utility tools that marketing and content teams use regularly as part of their workflow. Tools like indown.mobi that retrieve original quality media from public social media post URLs operate entirely through standard HTTPS requests in the browser without requiring any software installation or agent on the endpoint. From a network architecture perspective this creates an interesting challenge because their traffic is functionally indistinguishable from regular HTTPS web browsing at the packet level and therefore difficult to classify, monitor, or apply QoS policies to without deep packet inspection. In environments where marketing teams use these tools frequently for legitimate content management work, has anyone designed a network architecture that cleanly separates and classifies this type of browser based utility traffic from general internet browsing without broadly restricting web access for non-technical users.

[Torbjørn]

Hello @Rashad Higgins, welcome to the community!

You can do this on firewalls using deep packet inspection or on routers using NBAR. This allows you to match the SNI of the certificates for the HTTPS traffic, and should be sufficient for most application classification.

[Joseph W. Doherty]

Unsure there's any common Enterprise QoS approaches for such a situation because Enterprise QoS seldom uses QoS effectively beyond prioritizing real-time traffic and throwing bandwidth at everything else.

For example, even if the traffic wasn't encrypted, how often do most Enterprises use something like NBAR to dissect ordinary HTTP?

Of course, occasionally, you do find Enterprise QoS trying to do "interesting" things, because "on-high" has determined particular network usage, like your "marketing and content teams" need special QoS treatment to effectively do their jobs.  (If the network isn't well supporting any network users doing their job effectively, why is that?)

The above may appear to not be directly relevant to your desire to handle your particular issue, which is correct, but IMO, 1) most don't appreciate how useful QoS can be; 2) much typical book QoS recommendations are less than ideal, and 3) many network device architectures focus on bandwidth, not intelligence.

Not withstanding the above, there can be various approaches to single out particular network application traffic, even if encrypted, but "your mileage may vary".

Probably, the ideal approach would be Enterprise managed client policies that would set a trusted DSCP tag on the client (i.e. transit network devices wouldn't need to analyze the client's traffic).

Assuming we cannot trust the client, for encrypted traffic what do we do?

What about IPs (src and/or dst)?

@Torbjørn suggested using NBAR to match SNI.  An excellent suggestion, although if the latest ESNI or ECH are being used, we're blocked by encryption, again.

There are some Enterprise devices designed to decrypt traffic to/from outside the Enterprise.  (Basically they are using a man-in-middle approach, effective if only server side certificates are being used.). What they allow you to do with the decrypted client traffic, likely varies per product.

Another approach is QoS based on per flow volume.  (Unfortunately, I believe, not widely supported across Cisco platforms.)

To recap for QoS analysis, encryption (unless broken) conceals contents.  What's not concealed are IPs and volume.

[Torbjørn]

That is a very thoughtful and thorough answer @Joseph W. Doherty. Thank you!