TL;DR When a connection is refused when accessing a .mil website over HTTPS repeatedly in Internet Explorer, first logging into the site in Chrome will enable IE to connect every single time. Why is this?
I do IT servicing at a university for American ROTC cadre. So active duty military service members on a non-military network, we often have to come up with some workarounds due to this. One that has come up often for the Army is when attempting to access AKO(https://www.ako1.us.army.mil/) in Internet Explorer and Windows 7(untested in win10) it will sometimes throw an error and not connect, unfortunately I don't remember what the specific error says but I think it's an IE connection refused error. In any case, consistently the fix for this is to go to AKO on Google Chrome, login to the site that way, then with Chrome still open, access AKO in IE and it works.
More recently a single user on Windows 10(newly imaged, happening since the start) in the Air Force was repeatedly but intermittently(maybe 80%+ of requests) getting the error,
Can’t connect securely to this page. This might be because the site uses outdated or unsafe TLS security settings.
On a whim(and after attempting every variation of SSL3.0/TLS1.0/TLS1.1/TLS1.2 options) I tried the chrome workaround and it again worked consistently. My notes from this incident:
Launch google chrome
Go to https://www.my.af.mil/
- Login with the users CAC
- Launch Internet Explorer
- Now all *.af.mil sites will be accessible as Chrome has created the TLS connection required and IE can piggyback off of this.
I've been using this for a long time but it's never occurred to me why/how this works. I made the assumption that the TLS session was essentially generated by Chrome and then IE piggy backed off of it. I found this answer: Is encryption in HTTPS done by the browser or by the system? which mentions that IE uses an OS API for it, which in my mind kind of supports this theory:
If you specify https://, then the browser is taking responsibility for encryption. Some browsers use OS-provided APIs (looking at IE here)
This post on the other hand seems to indicate the exact opposite: Are SSL browser sessions kept alive across requests?
HTTP sessions and SSL sessions are different entities and there is no mapping from one to the other.
Again, I might be completely incorrect about this theory, I'm just hoping someone can explain what the true cause of this is so I can better understand what I'm implementing.