Users accessing internet via Cloud SWG using WSS Agents.
One application, hosted in Azure, handles inbound requests from users and generates corresponding requests to upstream services through Cloud SWG proxies using Explicit access method.
Certain requests to the upstream service are failing, and triggering 400 invalid_request errors, visible from the Portal reporting.
End users on WSS Agent host do not see these 400 errors but simply an application error.
Error was not seen prior to April 18 '24 - the date a maintenance upgrade to GGBLO1 was performed.
Explicit access method into Cloud SWG sending POST requests to secure web servers.
End user application generating requests that go through two separate Cloud SWG environments, from two separate tenants.
Azure microservices.
Microservice application, using Axios library, generating explicit Post requests to HTTPS backend but sent in clear text which are being blocked as part of security updates in April 18 maintenance event.
All POST request from User-Agents, to a HTTPS site, should come through as CONNECT requests to establish an encrypted channel to transmit the application payload.
Modify the Application so that explicit POST request to a HTTPS back end are sent encrypted over to Cloud SWG proxy.
An optional policy change on latest SGOS can be used to disable the Cloud Proxy check that returns the 400 error:
#if release.version=7.4.3.10..
<proxy>
http.allow_https_post_over_http(yes)
#endif
PCAPs taken at the User-Agent show the POST parameters sent to Cloud SWG in clear text, without any establishment of an encrypted tunnel.