netstat says 443 is open, but I cannot connect to it with telnet .. why?

Question

I've built a self hosted wcf server, using wsHttpBinding. I'm running Win 2003 server R2 SP2.

If I configure it to listen on http://localhost:443/MyService, everything works fine. I can connect to http://localhost:443/MyService with Internet Explorer, and I get the standard "Bad Request" message

Now, if I try to switch to HTTPS, I'm witnessing a strange phenomenon.

Here's what I've done :

1. I've changed my wcf config file from http://localhost to https://localhost and from Security=None to Security=Transport (as explained in numerous wcf tutorials)

2. I've registered my HTTP port like this :

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

Note that the certificate I've used is a "real certificate" (i.e. issued by a trusted CA, namely Comodo). The server responds to ping on the NS mentioned in the certificate.

Now, the following will timeout :

Microsoft Telnet> open localhost 443

Here's the output from netstat (The Pid '4' is the 'System' process):

netstat -nao

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

And here's a screenshot from TCPView captured when I issued the open command in telnet :

alt text http://img26.imageshack.us/img26/3376/tcpview2si6.jpg

I'm a bit puzzled. To me, if netstat says the server is listening on 443, the telnet connection to 443 shouldn't timeout, and I should have at least a blank prompt, expecting me to type some encrypted stuff :)

So far I've tried to :

1. Redo all the steps from scratch following exactly the MSDN tutorial
2. Used port 10443 instead of 443
3. Disable the firewall
4. Use a self signed certificate

I don't know what to try next .. any ideas?

Answer 1

The telnet client is not going to know to send a properly constructed request to initiate an https handshake, so I imagine the ssl secured server is just waiting for more data.

The telnet client is certainly not going to know what to do with the response from a ssl secured server (it's certainly not going to prompt you for data to send along). Communication can only happen once the https handshake has completed.

You need to use a client that knows how to do a handshake. The openssl binary can do this out of the box.

Answer 2

Telnet cannot be used to comunicate with encrited webs.

Checkout this microsfot note. It says "NOTE: This example assumes that the Web server is configured to use the default HTTP port (TCP 80). If the Web server is listening on a different port, substitute that port number in the first line of the example. Also, this example does not work properly over an HTTPS/SSL connection (TCP 443, by default), because the telnet client cannot negotiate the necessary encryption commands to establish the SSL session. Although an initial connection is possible over the HTTPS/SSL port, no data is returned when you issue a GET request."

Update: Checkout this other note HOW TO: Determine If SSL Connectivity Is Not Working on the Web Server or on an Intermediate Device

Answer 3

As FerrariB said, telnet does not perform the negotiations necessary to open an SSL connection. Telnet knows nothing about certificates, nor encryption. Thus, you are guaranteed to not be able to communicate with HTTPS port 443 via telnet. You will have to find another way to do whatever you are trying to do.

Check out the Wikipedia page on TLS for example, where it says directly:

If any one of the above steps fails, the TLS handshake fails, and the connection is not created.

This is precisely what you are seeing by trying to use telnet to communicate with an SSL endpoint.