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.They all move towards djb nacl/libsodium crypto with pluggable authentication.Ī telnet client may be used in different ways: Secure Unix shell could have been built over TLS. HTTPS could have been built over ssh protocol. That's just different optimizations and implementations. Of course, since the http client in not aware of the tunnel in this scenario, you won't get a green lock icon.īecause the three groups had different use cases in mind, the way the protocols are used most often varies. 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.
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). IPSec was meant as a secure tunnel for network equipment, invisible to applications. TLS was meant as a secure tunnel for applications. SSH was meant only for secure Unix terminal over a network. They all have issues but all can be made secure if you use the latest versions and configure them right. In the 90s, three different groups of people were inventing secure network connections at the same time. When you use a telnet client as a way to type into a socket, you don't use any feature of telnet.Īnyone who sees the raw network traffic can see everything you do and also to change what you send and receive. There is no actual connection between telnet and http. So you can use a telnet client to work with text based protocols like http and some databases (and many other things). This could look something like this: $ ssh -L 8080:localhost:80 telnet client just lets you type into a raw tcpip socket. 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. These are two different protocols which don't work together. 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. ssh is a secure replacement for telnet, why can't i issue http requests using ssh? This of course requires a proper SSH client and SSH server to work. With SSH you can establish an authenticated and encrypted connection.
Is also of my understanding that ssh came up as a secure replacementįor telnet, given that it authenticates users and provides a secure Note that the better choice would be to use a tool like netcat because this actually uses raw TCP. 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. This is the reason you can use telnet to issue http requests.Ī Telnet client doesn't care if it is connecting to a real Telnet server or any arbitrary TCP socket. Which allows to connect to a remote host and send/receive packets. Is of my understanding that telnet is an unauthenticated protocol