403 Forbidden error when attempting to log into stackexchange.com

Question

I'm trying to log into the StackExchange network and I receive a 403 Forbidden error after entering my credentials.

I am using Chrome Version 46.0.2490.71 m (completely up-to-date, as of this writing), on Windows 7 x64.

I notice that there appear to be two different avenues by which to log-in, and only one of them seems to be subject to this issue.

Steps to reproduce:

1. Browse to http://stackexchange.com and click the log in link (in thin black bar at top of page).

2. One is then presented with a view that asks him to choose which sign-in method to use. Choose "log in with StackExchange".

3. Enter login credentials when prompted and click Sign In button.

4. Receive 403 Forbidden response from server.

Oddly enough, if I browse to another StackExchange property, such as http://stackoverflow.com, and click the login link that is in the same place (in the thin black bar at top of page), I see a different login page, which looks like this:

When I attempt to authenticate on this page, everything functions as expected and I'm logged-in.

Is this a bona fide bug on the StackExchange side? Or am I "doing it wrong"?

At a minimum, the unsightly 403 error and attendant message should be made a bit more... "user friendly".

UPDATE: I disabled all extensions in Chrome (notice that the ad-blocking icons are gone, next to the URL field), but the behavior is the same:

UPDATE 2: The behavior is the same in Waterfox v40.0.2 (which is 64-bit Firefox, essentially). Again, the session ID can be seen in the URL, so perhaps an engineer is able to investigate further as to whether this behavior is specific to my public IP address (which is a corporate gateway IP, for what that's worth) or a larger issue.

I'm happy to share the full URL with a qualified individual. (I hesitate to post it here, as it may contain sensitive information regarding my identity or account.)

UPDATE 3: An Adaptive Security Appliance appears to be involved. The only headers that are present in the HTTP response (per Chrome Developer Tools) are:

HTTP/1.1 403 Forbidden Server: Adaptive Security Appliance HTTP/1.1 Content-type: text/html Connection: close

How might I troubleshoot this further? Should I reach-out to net-ops on my end?

Answer 1

I finally determined the root-cause: the Cisco Adaptive Security Appliance that filters our HTTP traffic is configured to prevent access to URLs whose length exceeds a certain threshold. On older ASA models, this length is 1159 characters (presumably single-byte), by default.

Credit to Poonguzhali Sankar for highlighting the root-cause in her 6-year-old post at https://supportforums.cisco.com/discussion/10827126/long-url-not-allowed-asa .

From the legacy documentation:

Enable Filtering of Long URLs

By default, the security appliance considers an HTTP URL to be a long URL if it is greater than 1159 characters. You can increase the maximum length allowed for a single URL with this command:

hostname(config)#url-block url-size long-url-size

Unfortunately, this solution did not apply, directly, because our appliance is much newer.

The appliance technician said the following of the solution that he employed:

The post above is from 6 years ago, and the command is no longer the same; it has you reference the URL length in size, from 2-4KB, now. That being said, the output below reports that there are no blocks due to a long URL.

# sh url-block block statistics 

URL Pending Packet Buffer Stats with max block  0
-----------------------------------------------------
Cumulative number of packets held:              0
Maximum number of packets held (per URL):       0
Current number of packets held (global):        0
Packets dropped due to
       exceeding url-block buffer limit:        0 <--- (somewhat surprisingly)
       HTTP server retransmission:              0
Number of packets released back to client:      0

What I've done instead is told the ASA to truncate long URLs for HTTP sessions, which effectively sends only the host information, rather than the entire 1200+ character URL, on to WebSense. This was already in place for the HTTPS sessions, just not HTTP.

As noted in the terminal output, I'm a bit surprised that the event count is zero (0) for exceeding url-block buffer limit, but the technician's adjustment did indeed resolve the issue.

Thanks again for all the helpful comments!