¿Por qué es mucho más difícil habilitar SSL (seguridad de transporte) sobre net.tcp que HTTP?

La implementación de un servicio web que utiliza la seguridad de transporte a nivel con WCF a través de HTTP es bastante fácil: Enable SSL for my WCF service ¿Por qué es mucho más difícil habilitar SSL (seguridad de transporte) sobre net.tcp que HTTP?

La implementación de un servicio web que utiliza la seguridad de transporte a nivel con WCF sobre net.tcp es bastante difícil: WCF with netTcpBinding and Certificate transport security

... y la solución net.tcp implica generalmente algo como esto tanto en el lado del servidor y del lado del cliente:

<serviceCertificate 
     findValue="MyServiceCertificate" 
     storeLocation="LocalMachine" 
     storeName="My" 
     x509FindType="FindBySubjectName" />

en el caso de HTTP, no es necesario mencionar siquiera un certificado en el cliente o el servidor. En el caso de NET.TCP, debe almacenar, localizar y especificar un certificado tanto en el cliente como en el servidor en la mayoría de las fuentes que he leído.

¿Qué hace la magia que hace que no tenga que preocuparse por los certificados en modo HTTP? Y, ¿por qué esta magia no está disponible para ti cuando usas net.tcp?

Fuente

2011-06-22 Greg Smalter

¿Hay alguna razón específica por la que no puede usar la seguridad del nivel de mensajes? –

No hay un motivo específico por el que no podamos usar la seguridad a nivel de mensaje. Sin embargo, no estoy al tanto de por qué eso sería más fácil de implementar. –

Porque al usar WCF sobre HTTPS; IIS gestiona la negociación con los certificados (al igual que SSL simple). Como no hay un servidor IIS integrado para TCP, debe hacerlo usted mismo. Todavía está haciendo cosas con certificados + WCF para HTTPS, pero la configuración se realiza en IIS.

EDITAR:

Por el lado del cliente, todavía tiene otra pieza de software. Cuando navega por un sitio web a través de SSL, el navegador maneja todo eso por usted. SSL sobre HTTP tiene un patrón de negociación estándar porque es parte del protocolo HTTPS. Para TCP, eso no forma parte del protocolo, por lo que el cliente debe encargarse de eso.

Fuente

2011-06-22 18:55:50 vcsjones

Esta fue mi hipótesis en el lado del servidor, pero solo explica el lado del servidor. No explica por qué las cosas son más difíciles en el lado del cliente. ¿Por qué todos los ejemplos que leo implican almacenar un certificado en la tienda del cliente y llamar a SetCertificate [(como aquí)] (http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/050bc8a9-a9a2 -41dd-89ef-dbacbcc5b111 /)? –

@Greg: ver ediciones. – vcsjones

Casi tiene sentido, excepto por dos puntos. En primer lugar, es cierto que el navegador maneja todo esto por usted, pero incluso si no está usando un navegador (solo una aplicación de Windows Forms con código de cliente WCF), de todos modos se ocupará de ello. Entonces, Microsoft debe manejarlo por nosotros. ¿Simplemente eligieron no manejarlo en el caso de net.tcp? Finalmente, si acepta todo esto, parece que el trabajo adicional para TCP sería implementar su propio manejo de certificados. En cambio, lo que vemos es personas que tienen un certificado nuevo instalado en el cliente que ni siquiera aparece en el caso HTTP. –

He luchado como el infierno con esto también y ahora finalmente me siento como un idiota. Lo cual es bueno porque significa que realmente entiendo algo que antes estaba pirateando.

Al implementar su servicio, su objetivo es proteger las comunicaciones con SSL. También debe poder generar su archivo reference.cs en Visual Studio. El problema que tiene es cuando coloca su intercambio de metadatos bajo el enlace SSL también. Las herramientas de generación de código no le permiten configurar las secciones de configuración de netTcpBinding necesarias para las llamadas que se realizan para obtener los metadatos cuando se utiliza para generar el archivo reference.cs.

Debe crear dos configuraciones de unión separados bajo netTcpBinding, uno para su servicio con la:

<security mode="TransportWithMessageCredential"> 
    <message clientCredentialType="Certificate"/> 
</security>

config en el interior y otro con:

<security mode="None" />

lugar. Asegúrese de que todas las otras configuraciones coincidan y el punto final de sus puntos de servicio en ssl bindingConfig, mientras que el punto final de los metadatos apunte al enlace sin SSL. Luego podrá leer los metadatos y actualizar nuevamente la referencia del servicio.

Una cosa a tener en cuenta es que debe tomar el enlace de metadatos para cualquier publicación de producto. Esto garantiza que no está exponiendo nada que no sea a través de SSL.

Fuente

2014-11-12 10:32:54 steve

¿Por qué es mucho más difícil habilitar SSL (seguridad de transporte) sobre net.tcp que HTTP?

Respuesta

Cuestiones relacionadas