netstat dice 443 es abierta, pero no puede conectarse a él con telnet .. ¿por qué?

StackOverflow https://stackoverflow.com/questions/542178

Pregunta

He construido un servidor WCF auto organizada, utilizando wsHttpBinding. Estoy corriendo Win 2003 Server R2 SP2.

Si lo configuro para que escuche en http://localhost:443/MyService, todo funciona bien. Puedo conectar con http://localhost:443/MyService con Internet Explorer, y me sale el mensaje estándar "Solicitud incorrecta"

Ahora, si trato de cambiar a HTTPS, estoy asistiendo a un fenómeno extraño.

Esto es lo que he hecho:

  1. he cambiado el archivo de configuración de WCF http://localhost a https://localhost y desde Security=None a Security=Transport (como se explica en numerosos tutoriales WCF)

  2. Me he registrado mi puerto HTTP como esto: 

    httpcfg delete ssl -i 0.0.0.0:443

httpcfg set ssl -i 0.0.0.0:443 -h ea2e450ef9d4...

Tenga en cuenta que el certificado que he usado es un "certificado verdadero" (es decir, emitido por una CA de confianza, es decir, Comodo). El servidor responde a un ping en el NS mencionados en el certificado.

Ahora, lo siguiente será tiempo de espera: 

Microsoft Telnet> open localhost 443

Aquí está la salida de netstat (El Pid '4' es el 'Sistema' proceso): 

netstat -nao

  Proto  Local Adress         Remote Adress          State           Pid
  TCP    0.0.0.0:443          0.0.0.0:0              Listening       4

Y aquí está una captura de pantalla de TCPView capturado cuando emití la comando de apertura en telnet:

texto alternativo http://img26.imageshack.us/img26/3376/tcpview2si6 .jpg

Estoy un poco desconcertado. Para mí, si netstat indica que el servidor está escuchando en 443, la conexión telnet a 443 no debe tiempo de espera, y yo debería tener al menos un indicador en blanco, esperando que yo escriba algunas cosas cifrado:)

Hasta ahora he tratado de:

  1. rehacer todos los pasos siguientes a partir de cero exactamente el tutorial MSDN
  2. 10443 puerto que se utiliza en lugar de 443
  3. Desactivar el cortafuegos
  4. Utilizar un certificado firmado auto

No sé qué probar la próxima .. alguna idea?

¿Fue útil?

Solución

El cliente Telnet no va a saber para enviar una solicitud de una buena construcción para iniciar un protocolo de enlace https, así que imaginar el servidor de seguridad SSL está a la espera de más datos.

El cliente telnet es, sin duda no va a saber qué hacer con la respuesta de un servidor seguro SSL (desde luego, no va a provocar que los datos a enviar a lo largo). La comunicación sólo puede ocurrir una vez que el apretón de manos https ha completado.

Es necesario utilizar un cliente que sabe cómo hacer un apretón de manos. El binario openssl puede hacer esto fuera de la caja.

Otros consejos

Como dijo FerrariB, telnet no lleva a cabo las negociaciones necesarias para abrir una conexión SSL. Telnet no sabe nada acerca de los certificados, ni cifrado. De este modo, se garantiza a no ser capaz de comunicarse con el puerto HTTPS 443 a través de telnet. Usted tendrá que encontrar otra manera de hacer lo que está tratando de hacer.

Visita la página de Wikipedia sobre TLS por ejemplo, donde dice directamente:

  

Si cualquiera de los pasos anteriores falla, el apretón de manos TLS   falla, y la conexión no se crea.

Esto es precisamente lo que está viendo, tratando de utilizar telnet para comunicarse con un punto final SSL.

  1. en el símbolo del sistema: netstat -nao |find "443" las últimas columnas muestran un número: pic no.1

  2. tarea número del resultado manager.find Ahora abierta en primera sección en la columna PID (PID si no se ha habilitado, la escojan de vista de la ficha) nombre del programa mostrará el programa que utiliza el puerto.

  3. desactivar el programa que utiliza el puerto / en mi caso lo paré de los servicios

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top