¿Es posible hackear un cliente WCF para pasar las credenciales de mensajes sin SSL?

Question

escribió una costumbre WCF unión hace un tiempo para permitir que mi carga equilibrada granja para albergar los servicios a través de IIS. La razón de la unión era costumbre que cada servidor no tenía SSL, pero se necesita la capacidad de aceptar una credencial de cliente de nombre de usuario + contraseña. El proxy delante de esta finca cuenta con SSL por lo que el tráfico se encripta fuera del firewall. Esta unión personalizada funciona bien, pero ahora estoy en el punto en que necesito para ver el tráfico de mi máquina local y quería hacer esto w / SSL a cabo en la mezcla.

La cuestión es la siguiente - en el cliente .NET si fijo mi modo de seguridad = "TransportWithMessageCredential" Me debe tener SSL otra cosa me sale el error divertido "esquema no válida, que se espera https"

¿Es posible escribir algo personalizado para el cliente a "ignorar" que SSL no se encuentra, pero aún dejarme pasar el nombre de usuario + contraseña a través del encabezado SOAP?

Answer 1

Sí, escribí un post sobre esto hace un tiempo llamado "Cómo: SSL Paso de credenciales con WCF O bien, TransportWithMessageCredential más sencillo HTTP".

El corto de él es que se necesita para crear su propia subclase HttpTransportBindingElement que "mentiras" sobre el abastecimiento de seguridad.

Answer 2

Hay una de revisión para .NET 3.5 SP1 que añade una propiedad AllowInsecureTransport a la SecurityBindingElement . Esto también será en .NET 4 beta 2.

Answer 3

Asumo que, en su enlace personalizado, que también se obtiene un error si sólo se utiliza el modo de seguridad = "Mensaje"? Una unión de costumbre no era realmente necesario, ya que (si no me equivoco) se puede utilizar el modo de seguridad con wsHttpBinding = "mensaje" (que no requiere SSL).

Otra alternativa es simplemente generar un certificado SSL a sí mismo, instalarlo en IIS, e implementar un fideicomiso toda política de certificados en su código de llamada, pero esto es generalmente mal visto (como es el envío de nombres de usuario y contraseñas a través de un canal no seguro) .

Una tercera opción es cambiar las operaciones de su contrato para aceptar los nombres de usuario y contraseñas (o algún tipo de token) como un parámetro o cambie sus contratos de datos para que pueda enviar la información junto con cualquier objeto que ya esté enviando.