TL; DR Quando una connessione viene rifiutata quando si accede a un sito Web .mil su HTTPS ripetutamente in Internet Explorer, il primo accesso al sito in Chrome consentirà a IE di connettersi ogni volta. Perché è questo?
Faccio servizio di IT presso un'università per i quadri ROTC americani. Quindi i membri del servizio militare in servizio attivo su una rete non militare, spesso dobbiamo venire con alcune soluzioni alternative a causa di questo. Uno che è venuto spesso per l'esercito è quando si tenta di accedere a AKO ( link ) in Internet Explorer e Windows 7 ( non testato in win10) a volte genera un errore e non si connette, sfortunatamente non ricordo cosa dice l'errore specifico ma penso è un errore di connessione IE rifiutato. In ogni caso, costantemente la soluzione per questo è andare su AKO su Google Chrome, accedere al sito in questo modo, quindi con Chrome ancora aperto, accedere a AKO in IE e funziona.
Più di recente un singolo utente su Windows 10 (appena ripreso, che si è verificato dall'inizio) nell'Aeronautica è stato ripetutamente ma a intermittenza (forse l'80% + delle richieste) ottenendo l'errore,
Can’t connect securely to this page. This might be because the site uses outdated or unsafe TLS security settings.
Per un capriccio (e dopo aver provato ogni variante delle opzioni SSL3.0 / TLS1.0 / TLS1.1 / TLS1.2) ho provato la soluzione alternativa e ha funzionato di nuovo in modo coerente. Le mie note di questo incidente:
-
Avvia google chrome
-
Vai al link
- Accedi con il CAC degli utenti
- Avvia Internet Explorer
- Ora tutti i siti * .af.mil saranno accessibili in quanto Chrome ha creato la connessione TLS richiesta e IE può portarlo fuori da questo.
Lo uso da molto tempo ma non mi è mai venuto in mente perché / come funziona. Ho ipotizzato che la sessione TLS fosse essenzialmente generata da Chrome e quindi IE piggy ne è stata esclusa. Ho trovato questa risposta: La crittografia in HTTPS è eseguita dal browser o dal sistema? che menziona che IE utilizza un'API del sistema operativo per esso, che nella mia mente supporta questa teoria:
If you specify https://, then the browser is taking responsibility for encryption. Some browsers use OS-provided APIs (looking at IE here)
Questo post sembra indicare l'esatto opposto: Sono SSL sessioni del browser mantenute attive tra le richieste?
HTTP sessions and SSL sessions are different entities and there is no mapping from one to the other.
Ancora una volta, potrei essere completamente non corretto su questa teoria, spero solo che qualcuno possa spiegare qual è la vera causa di questo, così posso capire meglio cosa sto implementando.