2

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.

Improve this question
2
  • Why do you think that's contradictory? The fact that HTTP sessions and SSL sessions are different things doesn't prevent browsers from using the same SSL session (not confirming your explanation, I don't really know, I just don't see anything there that contradicts it).
    – AndrolGenhald
    May 18, 2018 at 13:43
  • Might be a misconfigured firewall somewhere between you and the target server? I can imagine there being a bizarre case where a stateful firewall is somehow blocking particular types of connections until a connection from that IP that it doesn't block gets added to the state table. Just a theory though.
    – Ajedi32
    May 18, 2018 at 14:57

1 Answer 1

Reset to default
1

I have no access to this infrastructure so I have no way to reproduce your problem. Therefore I can only guess: If I understand you correctly you need to login into a specific website (www.my.af.mil) to get access to all the other *.af.mil sites. My guess is that this is done by white-listing your specific system (maybe by IP address, maybe by NTLM token) on successful login. This would explain why you can access the sites with Internet Explorer too after successful login with Chrome since you are still connecting from the same system. It definitely does not share the SSL session between browsers - it does not even share the SSL session between the different *.af.mil sites.

As for the failure to access the login site with Internet Explorer: there is probably some incompatibility of the login site or some middlebox which is in the path to the login site. There are not enough details to find out what exactly this is.

In any case I'm wondering why you ask about the problem here. I would imagine that the proper way would be to report the problem to the system administration responsible for this access instead of trying to work around the issue. Given that you did not include any statements from the system administration I can only guess that you not even tried to let them handle the problem.

Improve this answer
2
  • I think that makes total sense and helps me clear up my own misunderstanding thank you. In regards to the proper way part, I'm assuming you would mean the system administration of the af.mil site? I am currently working with my own departments sys admins on this and they're aware of the workaround. I got the workaround originally from a call with the AKO helpdesk a long time ago and the users accept it as par for the course for dealing with .mil sites on a non-military domain. I would absolutely like to do this the right way though if you could elaborate more. I really appreciate it.
    – William
    May 18, 2018 at 15:15
  • @William: The proper contact is probably the one who gave you the access in the first place, or at least this is the one who should know what the proper contact is. It might well be that this is a known issue which is too costly too fix or that they are working on it and that this is the officially recommended workaround in the mean time. But of this is the case cannot be seen from your question.
    – Steffen Ullrich
    May 18, 2018 at 15:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .