Un client qui attend d'abord un défi attend que le proxy le demande. Un client Basic préventif connaît déjà le point de terminaison choisi et envoie l'identifiant dès sa première requête applicable. Supprimer cet échange peut être utile. Cela reste une décision sur la destination d'un mot de passe.

Connaître le point de terminaison avant l'optimisation

Un proxy privé fixe doté d'une politique d'authentification connue est un cas plus clair qu'une couche de routage susceptible de choisir un intermédiaire inconnu. Liez le compte à l'identité et au protocole attendus du proxy. Ne construisez pas de callback générique qui répond à chaque défi avec un seul mot de passe d'entreprise.

Basic transporte une représentation base64 du compte, pas une preuve chiffrée. TLS vers l'écouteur du proxy est un choix de connexion distinct de la session HTTPS du site. Le tunnel HTTPS du site ne protège pas rétroactivement un identifiant Basic envoyé sur une connexion client-proxy non chiffrée. Un LAN privé est un emplacement, pas une propriété de chiffrement.

Garder le mécanisme spécifique

Le Basic préventif n'est pas un raccourci universel pour Digest, NTLM ou Negotiate. Ces mécanismes ont leurs propres exigences d'échange. Un client qui découvre les schémas pris en charge peut légitimement effectuer des transactions supplémentaires.

Utilisez l'interface d'authentification proxy de la bibliothèque choisie, puis inspectez le schéma et la portée effectifs. Un réglage de préauthentification de destination peut ne pas contrôler la poignée de main du proxy. Une connexion authentifiée existante peut aussi masquer si une nouvelle connexion effectuerait un défi.

Comparez l'opération complète : nombre d'échanges, temps d'achèvement, protection de transport requise et comportement lorsque le proxy change. Un journal plus propre n'est utile que si l'application s'authentifie toujours auprès de l'intermédiaire prévu et s'arrête lorsque cet arrangement ne peut être établi.

Articles similaires