Tunnel To xxx.com:443 when the traffic should be http

[Ross]

Greetings,

I am trying to figure out an issue that I was given. There are two apps A and B. 

A is used to authenticate users and passes a token to B and B adds a cookie. Something strange happens when the cookie expires or after a hard browser reset. 

 

WITHOUT FIDDLER: 

User hits app A enters credentials and gets forwarded to app B. However, for about 5 seconds the browsers black "xxx took too long to respond" error screen shows but then magically the default page is rendered soon afterward. This only seems to occur when the cookie has expired or after an extended amount of time.

 

WITH FIDDLER: (SEE SESSIONS 61, 71 and 83)

When I perform the same scenario in fiddler, where I would expect the black "xxx took too long to respond" screen, I get the certificate error screen attached with the open lock icon. I have to dismiss that three time. While I am dismissing the ssl tunnel errors the default user page is rendering.

The correlation is about the same time I get the lock dialog(s) in fiddle is the same place I get the black browser error screen and the app seems to be loading in the background and the refreshes once fully loaded.

My thought is there is a https-->http request being "partially" blocked from A-->B as B is http only with no certs. The devs tell me they can't find a request being made that is https. So, I can't figure out where the ssl tunnel is coming from (see screen capture). My thoughts are.

1. The devs missed something and one of the calls is http.

2. Some network appliance is attempting to convert the call to https, though there are no url rewrites on the IIS server. 

 

Any input would be helpful. Can anyone see what would cause a black "xxx took too long to respond"  to render while the default page is loading. It feels like one of those weird scenarios where the request was changed before it was fully read or something else arcane like that.

 

[Nick Iliev]

Hello Ross,

 

Note that most modern-day browsers automatically "upgrade" non-secure HTTP connections to HTTPS (known as HSTS or HTTP Strict Transport Security). As discussed here, the feature can be explicitly stopped in Chromium-based browsers through explicit configuration. If you believe you should only see an HTTP connection (instead of HTTPS and the resulting CONNECT Tunnels), you can check if an application is not using the HSTS technique.

Instead of manually dismissing the cert error, you can use "Ignore server certificate errors (unsafe)" from the Options > HTTPS menu in Fiddler Classic. Note that Fiddler only proxies the HTTP/HTTPS traffic. Fiddler won't try to change an HTTP request to HTTPS - that said, it looks like the client is trying to establish an HTTPS connection, but the handshake fails. 

Fiddler uses the so-called blind tunnels to establish a secure connection between a client and a server. In your case, it looks like the TLS handshake fails due to the received certificate error (when Fiddler is in the middle). The error indicates the certificate is rejected for some reason (e.g., invalid certificate, certificate using forbidden ciphers, certificate that does not match entries in a trusted list, etc.).

As a side note, Avaya can have complex options for checking certificates, including remote checking and cert pinning (see here). While I can only speculate what caused the original "took too long to respond" it could be that a remote certificate check is failing or delayed.

 

 

Regards,
Nick Iliev
Progress Telerik

[Ross]

This most certainly is helpful, following the "Delete domain security policies" in chrome, mentioned in a link you posted seemed to have made the black "xxx.com took too long to load" page go away. I still get the dialog with the unlocked lock in Fiddler; however, the reported issue was the brief display of the error page. I think this is also an internal site issue and would not happen in prod environments where everything is https with valid certs.