5

Is of my understanding that telnet is an unauthenticated protocol which allows to connect to a remote host and send/receive packets. This is the reason you can use telnet to issue http requests.

Is also of my understanding that ssh came up as a secure replacement for telnet, given that it authenticates users and provides a secure channel over an insecure network.

If both of above statements are true: 1. telnet allows http requests, 2. ssh is a secure replacement for telnet, why can't i issue http requests using ssh?

Or is a better statement that ssh suited a very specific need (authentication/security/shell) and not a secure replacement for telnet?

Andras Gyomrey
  • 821
  • 3
  • 9
  • 17

4 Answers4

10

Is of my understanding that telnet is an unauthenticated protocol which allows to connect to a remote host and send/receive packets. This is the reason you can use telnet to issue http requests.

A Telnet client doesn't care if it is connecting to a real Telnet server or any arbitrary TCP socket. Because Telnet transmits all data (besides some Telnet control codes) unaltered, you can conveniently (ab)use the client to create a raw socket connection to a TCP-based service running HTTP, FTP, IMAP, etc. Note that the better choice would be to use a tool like netcat because this actually uses raw TCP.

Is also of my understanding that ssh came up as a secure replacement for telnet, given that it authenticates users and provides a secure channel over an insecure network.

That's true. With SSH you can establish an authenticated and encrypted connection. This of course requires a proper SSH client and SSH server to work.

If both of above statements are true: 1. telnet allows http requests, 2. ssh is a secure replacement for telnet, why can't i issue http requests using ssh?

That's because your SSH client tries to negotiate a secure connection with a HTTP server that doesn't know what any of this means. These are two different protocols which don't work together.

That said, if you have SSH access to the web server you can create an SSH tunnel and forward port 80 to use the web application securely over HTTP. This could look something like this: 

$ ssh -L 8080:localhost:80 user@webserver
Arminius
  • 43,922
  • 13
  • 140
  • 136
4

A telnet client just lets you type into a raw tcpip socket. So you can use a telnet client to work with text based protocols like http and some databases (and many other things). There is no actual connection between telnet and http. When you use a telnet client as a way to type into a socket, you don't use any feature of telnet.

Anyone who sees the raw network traffic can see everything you do and also to change what you send and receive. So people use crypto. In the 90s, three different groups of people were inventing secure network connections at the same time. We got ssl/tls, ssh and ipsec. They all have issues but all can be made secure if you use the latest versions and configure them right.

SSH was meant only for secure Unix terminal over a network. But it can be used as a secure tunnel. TLS was meant as a secure tunnel for applications. IPSec was meant as a secure tunnel for network equipment, invisible to applications.

In the most basic form, you can use all three to create a secure tunnel between two computers and let unmodified client-server software communicate through that tunnel unaware that it's now secure (encryption, integrity, authentication, forward secrecy, etc).

So if you use ssh port forwarding or tls stunnel or ipsec vpn and then make http requests so that traffic passes inside an ssh or tls or ipsec tunnel, you're using http over ssh or tls or ipsec. Of course, since the http client in not aware of the tunnel in this scenario, you won't get a green lock icon.

Because the three groups had different use cases in mind, the way the protocols are used most often varies. That's just different optimizations and implementations. HTTPS could have been built over ssh protocol. Secure Unix shell could have been built over TLS. They all move towards djb nacl/libsodium crypto with pluggable authentication.

Z.T.
  • 7,768
  • 1
  • 20
  • 35
2

Your understanding is not accurate. Telnet sessions may be authenticated, and the authentication generally happened in the clear (there was a Kerberized telnet). SSH adds confidentiality and integrity protection.

A better statement is that the SSH protocol is designed to always use a security layer that's not compatible with plaintext protocols.

Adam Shostack
  • 2,659
  • 1
  • 10
  • 12
0

A telnet client may be used in different ways:

  • if the peer is not a telnetd daemon, if works more or less like a mere netcat and transfers its standard input and output to/from the socket
  • if it acknowledges the peer as a telnet daemon, it uses the telnet protocol. In that mode, it can perform secure authentication through Kerberos, and the data stream is normally encrypted (on recent versions) - at least this is what man telnet says

You should also remember that if you use IPSEC (on IP V6), the application may not use encryption because it is ensured at a lower level.

That being said, when ssh is presented as a more secure replacement for telnet, it only refers to the classic usage, that means to simulate a local terminal on a remote machine. And it makes sense, because in heterogeneous environment, telnet often downgrade to a an unencrypted flow with credentials passed in clear text.

But it would not make sense to try to use a ssh in place of telnet when the latter is used in netcat mode.

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84