http/https splitting for monolithic

[MK-42]

Describe the issue you are having

I'm currently investigating to switch to /monolithic from a /docker-compose like setup with multiple /generic instances

DNS Configuration

self-written powershell scripts to preload windows-server dns with the required dns redirects

As I'm in a windows-domain environment, I'm easily able to roll out trusted https certificates fof effective mitm caching of ssl content.
Currently I'm running the caching services on two different IPs, one for http only content, no ssl-certificates in nginx, and sni-proxy (just in case), and another IP that is running the nginx vhosts equipped with ssl certs, for origin and the likes.

I'm wondering how to adapt this setup to /monolithic. Are there any experiences regarding simply caching all the http/https traffic on the cdns listed by uklans/cache-domains, or should I explicitly whiltelist some of the services to ssl caching and route the rest through sni-proxy? I think I could achieve the latter by enrolling two IPs to the /monolithic container, listening in 80/443 on one, and listening on 80 with a running sni-proxy on the other IP.
Then binding these to different sets of host ips and using the according dns records for proper selection of ssl vs non-ssl caching for each cdn.

Are there any best-practices or known problems regarding such setups?

[Lepidopterist]

Hey @MK-42 ,

I'm not aware of any instances where this has been done. We like to try to steer away from MITM on SSL because the most common use-case for this does not lend itself to interception. (LAN parties with no end-user device control).

That being said, I can't see a glaring reason it wouldn't work. Feedback would most likely be appreciated by others who have a similar use case, if you do manage to get it working!.

Hopefully, Origin will be resolved soon - there have been whispers in the wind that may bear positive news :)

[MK-42]

Hopefully, Origin will be resolved soon - there have been whispers in the wind that may bear positive news :)

That sounds really promising. I was in a mixed happy/sad state when ssl caching was working back in spring and I realized that epic switched to non-ssl traffic making the effort obsolete right away. But as long as Origin is ssl, we will need a solution for that anyway.

Thanks alot for your effort here, this project is amazing!

[unspec]

Closing this issue, as no specific issue outstanding. Feel free to reopen with any specific questions / issues per advice from Lepidopterist.

The Origin issue specifically is being tracked here: uklans/cache-domains#98 if you want to follow that for updates.