Investigating and Resolving the "net::ERR_ABORTED 401 (Unauthorized)" error
Article ID: 232246
Updated On:
Products
Issue/Introduction
Investigating and Resolving the "net::ERR_ABORTED 401 (Unauthorized)" Server Authentication error
Environment
Release : 1.13.952 +871
Component :
Cause
We see that the server authentication failed in step 6, with the required redirection not happening.
Resolution
Having investigated the uploaded logs, we see the below.
"method": "GET",
"url": "https://XXXXXXXXXXXXXXXXXX?RelayState=https%3A%2F%2Fproxy.ch.world.socgen%2Fthirdparty%2Fdiagnostics%2Fdiagnostics.js%3Fver%3D1.13.952%2520871%26fg-said%3D0a7e86f0-4923-11ec-aba4-edcb691daf2e",
"httpVersion": "HTTP/1.1",
"headers": [
{
"name": "Host",
"value": "XXXXXXXXXXXXXX"
},
{
"name": "Connection",
"value": "keep-alive"
},
{
"name": "sec-ch-ua",
"value": "\"Chromium\";v=\"92\", \" Not A;Brand\";v=\"99\", \"Google Chrome\";v=\"92\""
},
{
"name": "sec-ch-ua-mobile",
"value": "?0"
},
{
"name": "User-Agent",
"value": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36"
},
{
"name": "Accept",
"value": "*/*"
},
{
"name": "Sec-Fetch-Site",
"value": "cross-site"
},
{
"name": "Sec-Fetch-Mode",
"value": "no-cors"
},
{
"name": "Sec-Fetch-Dest",
"value": "script"
},
{
"name": "Referer",
"value": "https://google.com/"
},
{
"name": "Accept-Encoding",
"value": "gzip, deflate, br"
},
{
"name": "Accept-Language",
"value": "en-US,en;q=0.9"
},
{
"name": "Cookie",
"value": "connect.sid=s%3AlciKq2luo9UqAFw4fYRDkuEEZ_jfV2b3.EYc%2B0KpNIPVmRCtRWOg4fGSUq%2F2E6n4p927JI58xd5E"
}
],
"queryString": [
{
"name": "RelayState",
"value": "https%3A%2F%2Fproxy.ch.world.socgen%2Fthirdparty%2Fdiagnostics%2Fdiagnostics.js%3Fver%3D1.13.952%2520871%26fg-said%3D0a7e86f0-4923-11ec-aba4-edcb691daf2e"
}
],
"cookies": [
{
"name": "connect.sid",
"value": "s%3AlciKq2luo9UqAFw4fYRDkuEEZ_jfV2b3.EYc%2B0KpNIPVmRCtRWOg4fGSUq%2F2E6n4p927JI58xd5E",
"path": "/",
"domain": "XXXXXXXXXXXXX",
"expires": "1969-12-31T23:59:59.000Z",
"httpOnly": true,
"secure": true
}
],
"headersSize": 762,
"bodySize": 0
},
"response": {
"status": 401,
"statusText": "Unauthorized",
"httpVersion": "HTTP/1.1",
"headers": [
{
"name": "Server",
"value": "nginx"
},
This highlighted server response, above, matches the console error already reported console log, shown in the snippet below.
The "net::ERR_ABORTED 401 (Unauthorized)" error is a server authentication error. To help provide better context, please refer to the details below, for how the server-side works.
In Server authentication mode, the Threat Isolation Gateway issues an Authentication challenge (HTTP 401) for every new connection. The following flow chart illustrates the initial browsing flow in Server authentication mode. Each leg is explained below.
- The client (browser) surfs to a website on the Internet.
- The Threat Isolation Proxy configured with the Server authentication mode returns a 302 Redirect to Service Provider (SP) rather than the standard 407 response. (The Service Provider (SP) is the Threat Isolation Proxy.)
- The browser browses to the Service Provider (SP).
- Since the Service Provider (SP) does not know the user’s identity, it returns 401 Authentication required.
- The browser gets the identity information from the user or from the OS, then sends the authentication information to Threat Isolation Proxy.
- The Service Provider (SP) returns a 302 Redirect to the original URL, with a Symantec Threat Isolation query-param that contains a token. It also sets a cookie for persistency. This cookie makes steps 4 and 5 redundant in future requests. We see this redirection in the HAR log investigated. Se the excerpt below.
},
{
"name": "Referer",
"value": "http://google.com/"
},
{
"name": "Accept-Encoding",
"value": "gzip, deflate, br"
},
{
"name": "Accept-Language",
"value": "en-US,en;q=0.9"
},
{
"name": "Cookie",
"value": "connect.sid=s%3AlciKq2luo9UqAFw4fYRDkuEEZ_jfV2b3.EYc%2B0KpNIPVmRCtRWOg4fGSUq%2F2E6n4p927JI58xd5E"
}
],
"queryString": [
{
"name": "ver",
"value": "1.13.952+871"
}
],
"cookies": [
{
"name": "connect.sid",
"value": "s%3AlciKq2luo9UqAFw4fYRDkuEEZ_jfV2b3.EYc%2B0KpNIPVmRCtRWOg4fGSUq%2F2E6n4p927JI58xd5E",
"path": "/",
"domain": "XXXXXXXXXXXXX",
"expires": "1969-12-31T23:59:59.000Z",
"httpOnly": true,
"secure": true
}
],
"headersSize": 625,
"bodySize": 0
},
"response": {
"status": 302,
"statusText": "Found",
"httpVersion": "HTTP/1.1",
"headers": [
{
"name": "Server",
"value": "nginx"
},
{
"name": "Date",
"value": "Fri, 19 Nov 2021 10:25:44 GMT"
},
{
"name": "Transfer-Encoding",
"value": "chunked"
},
- The browser asks for the URL provided in step 6, and attaches the token.
- The Threat Isolation Proxy redirects the browser to the original URL of the requested website. It also sets a cookie for persistency. This cookie makes steps 1-8 redundant in future requests.
- The browser asks for the original URL of the requested website with a cookie.
- The Threat Isolation Proxy verifies with the identity provider that the user is authenticated. It then returns the 200 OK status that concludes authentication, together with the HTML content. The HTML content depends on the matched rule. For more information, see section 2.2 "Returned HTML Content".
Resolution
We recommend to skip authentication, as the source egress IP address would have been authenticated, previously.
When a proxy resides in the cloud, it cannot communicate directly with an authentication server that resides in the LAN. If redirect cannot be done in this case, authentication is likely to fail, resulting in connectivity issues for Bypass and Inspect actions. (This is not relevant for isolated web traffic.) Connectivity issues can also be experienced by websites that apply Content-Security-Policy. To address the connectivity issues, Symantec Threat Isolation allows authentication to be skipped when the source egress IP address (the source IP address that the traffic comes from) has already been authenticated within the configured authentication caching timeout. The policy can be edited to include criteria for skipping authentication. When these criteria are matched and the source egress IP address was authenticated previously, the user is considered trusted and authentication will be skipped. The activity log displays “Generic User” instead of the user name when user authentication was skipped for unauthenticated requests. In that case, rules with a specific Access Role were skipped during matching.
Feedback
