Perché a volte devo "bypassare" l'intercettazione SSL?

2

Uso il filtro BlueCoat ProxyClient in una piccola rete aziendale (< 50 computer). Abbiamo impostato il filtro per categorie e funziona perfettamente su quasi tutti i siti. Tuttavia, a volte, abbiamo un sito che

  1. Anche se è in una categoria consentita
  2. Anche se lo aggiungiamo esplicitamente a una lista bianca
  3. Anche se possiamo navigare in un browser,
  4. Ancora non funziona correttamente a meno che non lo aggiungiamo all'elenco "Ignora intercetta SSL".

Che cosa fa realmente questo "bypass" e perché è necessario?

Esempio

  1. Abbiamo installato la community di Visual Studio 2015 su uno dei nostri computer
  2. Quando abbiamo provato ad aggiornare la nostra licenza utilizzando il nostro account MS, abbiamo ricevuto il messaggio "Impossibile aggiornare la licenza".
  3. Usando Fiddler abbiamo scoperto che VS stava cercando di accedere a https://app.vssps.visualstudio.com . È contrassegnato come Tecnologia / Internet da BlueCoat, che è nella nostra categoria consentita lista.
  4. L'abbiamo aggiunto alla nostra whitelist esplicita e non è stato ancora di aiuto.
  5. Abbiamo abilitato l'impostazione di decrittografia HTTPS in Fiddler e abbiamo riscontrato che stava inviando un sacco di richieste a https://app.vssps.visualstudio.com/_api con un'intestazione Authenticate che sembrava valida, ma la risposta tornava come 401 Not Authenticated .
  6. Abbiamo infine aggiunto app.vssps.visualstudio.com all'elenco di esclusione SSL e all'improvviso ha iniziato a funzionare.
posta just.another.programmer 14.03.2016 - 19:08
fonte

1 risposta

3

La mia ipotesi è che il tuo Proxy stia rimuovendo l'intestazione Authenticate dalla richiesta. Ho effettuato una rapida ricerca su Google sul problema e ho trovato questa pagina del forum . Dalla stessa pagina:

It is by design if the proxy sees an Authorization header and the proxy have authentication enabled or used in the policy, the proxy will consumed the Authorization header, thus the Authorization header will not be forwarded to the upstream device.

In this case, the Authorization header was generated from the client and NOT due to the proxy's authentication challenge, this is why it failed. So in order to 'tell' the proxy not to suppress the Authorization header, we would need to disable authentication for this URL and forward the Authorization header to the upstream as what the CPL suggested will be doing"

Credo che il problema che stai riscontrando sia simile. La soluzione proposta sul forum:

Solution at present would be to have "security force-credential-forwarding" enabled or use the CPL to bypass Auth for the domain. Since the command will affect the "Proxy-Authorization" headers too.

Spero che questo aiuti.

    
risposta data 14.03.2016 - 20:17
fonte

Leggi altre domande sui tag