We get the issue when enable https scanning, even with the default policy.
It's random happened. When it happened it might look like this. And in the first told just bypass them. After insist said no, he told it's website issue. It's tired to talk with the support.
Does anyone can help this issue?
have you noticed any pattern? Maybe based on daytime or on browser, user etc.?
Further, it sounds like you had a SR open? If yes, can you please PM me the SR number that I can have a look at the data?
I did a quick test and refreshed both sites multiple times over last 30 minutes but did not face any issue. Tomorrow, I can begin my testing in the morning and try it out over the whole day with different browsers.
If it can be reproduced, I will create a browser network trace (HAR file), rule trace, tcpdump and connections trace at the same time and look in it to see if I can find something or not.
If you have an open SR with same data, so much the better.
thanks for the info, I try to check this SR later and see if I can find anything and let's see if I can reproduce it too.
Regarding the data, please await further response from my side. Want to check SR and in my lab before we gather new data on your end. Also a new SR would be needed which I could take over then. Sensitive data should not be uploaded here in the community.
I could reproduce the issue and think it is related to HTTP2 somehow (but not 100% sure).
I only tested with following URL so far:
When HTTPS scanner is enabled and we do content inspection, we also do HTTP2 if available. In this case I could few times (1 from 50 attempts) reproduce the issue (left side bar shows weird content, main/right side stays blank).
I created a har file in the browser and could see that my client got improper HTML content back. The beginning lines (do not know how many) seem to look the same between a good and bad example but the end of my HTML response looked like:
At the end you can see this weird o/body etc. sometimes it was 0/ or s/body.
The good/working example looks normal:
" </script> </body>
I also created connection traces but could not read the external traffic because it seems to be decoded.
I am trying to reproduce this again and also create a tcpdump this time where I can decode the HTTPS traffic with SSL keys from connection traces.
So we should be able to find out, whether this improper HTML is received from webserver and simply forwarded to client or if MWG is misbehaving here.
If you want and are interested in testing, you can create a rule which only deactivates HTTP2 support for given URL host and then observe it.
URL.Host equals developer.android.com, Event: Enable Proxy Control
Within this proxy control setting, scroll to HTTP2 support action, enable the option and select "No" HTTP2 support.
I will update here again once I have the proper data and can read the external traffic to see where this is coming from. I hope I am on the correct direction 😊
I have opened a new SR and will contact you from there. I have gathered the information but I am not able to decode the HTTP2 gzipped response. So I have created this new SR, and escalate this to engineering soon.
I will update this community thread later with final answer/solution if available for documentation purpose.