What's the actual TELNET specification? I found RFC 854 which is very old.
It looks like RFC 5198 is probably current. IF you look at the top of the RFC you referenced, there is a reference to RFC 5198 with a note that 5198 updates 854.
854 is the last RFC for the protocol itself. NIC 15373 and IETF STD 8 are normative.
Several RFCs have proposed extensions eg RFC 1123, telnet over TCP. The most recent to specifically extend telnet was 4777, in 2006.
The basic TELNET protocol has not changed significantly since RFC 854 was published (it was already a refinement of the TELNET protocol that was used in the Arpanet, prior to TCP/IP, so there were many years of experience with it). It was designed to allow for extensions using the OPTION mechanism, rather than changes to the protocol itself. There are many RFCs that describe options for the protocol, and RFC 1123 contains a number of clarifications and refinements to this (and other) protocols.
These days, TELNET is mostly an obsolete protocol. SSH has largely supplanted it, as it has built-in encryption and authentication (these are available as options in TELNET, but adoption is spotty).
Related
From where does the client fetches the list of cipher suites that it is going to propose to server?
For example, it looks like that on same machine, clients of two different applications can propose the different list of cipher suits.
To limit the scope of question, I want to understand it for RabbitMQ Client and TLS1.2.
More clarification
So I have RabbitMQ service installed on my machine and then in C# code I try to connect (Ex. var connection = factory.CreateConnection()) to it without any cipher suits configuration.
So here my C# application could be considered as Client.
please note that I am asking about the ciphers that client sends in 'Client Hello' message.
P.S. somewhere I read that rabbitmq internally uses openssl, so when I ran the command 'openssl ciphers -s -tls1_2' I got a list that is different when I see rabbitmq client hello's cipher suits in wireshark. Also I don't have any group policy on machine that overrides the ciphers.
See https://tls13.ulfheim.net/ for a nice graphical representation of a TLS 1.3 exchange.
In the second message, ClientHello, the client gives among other things a list of ciphers it supports. Where it gets it? Either hard-coded in the application or computed dynamically once decided to connect, etc. this all depends on the application, so you need to investigate its code source/its configuration.
If you take for example openssl s_client as TLS client, you have -cipher and -ciphersuites configuration options to specify which specific ciphers to announce when connecting.
If you look later in the exchange, there is a ServerHello where the server announces which cipher suite will be used.
How that happens? Typically, the server has its own list of preferred ciphers ordered by "quality" (cryptographic strength like preferring 256bits over 128bits and/or other properties like preferring PFS over non PFS), and based on what it got from the client, it tries to select the "best" one that is supported on both side, which is not necessarily always possible.
Now as you put in comments a specific application (Google Chrome), you can see at https://source.chromium.org/chromium/chromium/src/+/main:third_party/boringssl/src/ssl/ssl_cipher.cc;l=1152?q=cipher&ss=chromium%2Fchromium%2Fsrc the definition of a function called "ssl_create_cipher_list" whose goal is to build the cipher list, starting from all compiled ones, and then applying various rules to enable/disable some and sorting them in an order that makes sense. This is of course highly dependent on the application for how it is done, but you can certainly find similar operations in other toolkits.
Finally, do note that there is a big difference between TLS 1.2 (ciphers) and TLS 1.3 (ciphersuites). They are disjoint sets, and when TLS 1.2 has "myriad" of ciphers in the wild (see for example https://www.openssl.org/docs/man1.1.1/man1/ciphers.html for lots of them), TLS 1.3 defines only 5 ciphersuites (see https://datatracker.ietf.org/doc/html/rfc8446#appendix-B.4) with one being mandatory to implement, so the whole question of auto-negotiation between client and server becomes almost moot.
As you mention explicitly tls1.2 as tag, do note there is no real reason today not to use 1.3 instead (which is why my first link is on purpose specially for 1.3 - the handshake routine is different in 1.2 but identical for things related to your question of ciphers), you will gain a lot of benefits, from simplified operations, better cryptography all around, and fewer holes.
We are planning to use Apache Mina SSHd - ssh client in our product. I need to identify if it supports ssh2 protocol.
I checked various resources thoroughly but couldn't able to find information around it. Could you please confirm if it supports ssh2 and how to use/ configure it.
Apache MINA SSHD implements version 2 of the SSH protocol. Version 1 is obsolete and no longer considered secure, and almost nobody uses it anymore. The RFCs it links to in the README on GitHub all cover version 2 of the protocol.
Note that because the library supports a large number of cryptographic algorithms, many of which are no longer secure, you should be careful if you are using settings other than the defaults (which, except for the use of the ssh-rsa signature algorithm, should be secure).
If you're looking for some basic setup documentation for a simple client, the README has a link to some documentation for that as well.
SSH is the recommended protocol for remote configurations. Still, telnet is being used in many devices. Are there any advantages of telnet over SSH?
Hmm, let's see:
Telnet is simpler (as others have noted already);
Telnet is obviously faster, as the protocol is much more trivial and there is no key exchange and no encryption involved;
Telnet is less vulnerable
Wait, stop, WHAT !?
Well, yes, telnet protocol is plain-text, so you can just sniff the connection and now you know the password and everything else.
And that is a well known fact indeed.
How hard would it be to actually sniff the particular telnet session,
depends on the network setup and a bunch of other things, and might range from being completely trivial to extremely hard to do.
But aside the (obvious) lack of encryption, when it comes to protocol and the service implementation(s) itself, which one is less vulnerable in overall ?
Let's take a look in the CVE database:
Telnet: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=telnet
There were 5 vulnerabilities, registered in 2016,
3 of them are just "hardcoded credentials", which is more of a vendor error than a real service implementation or protocol flaw.
Now, SSH: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ssh
25 (!) vulnerabilities (year 2016), ranging from the "hard-coded" credentials to allowing the selection of low-security encryption algorithms, issues which allow for denial-of-service attacks or reading the private keys from the remote process memory and so on.
So there were obviously many more SSH related vulnerabilities than Telnet vulnerabilities detected in 2016, and Telnet is a winner here.
That is actually pretty logical, taking that SSH is a much more complex protocol, and a typical SSH implementation will have many more features, like X11 forwarding, file transfer, tunnels e.t.c.,requiring a more complex code, and making a much wider "attack surface"
Please take the above with a grain of salt, Telnet is still plain-text
and it is widely regarded as an outdated protocol, so you definitely have to use a decent SSH implementation instead.
Just make sure that it is configured properly (e.g. switch off features you are not going to use), and keep it up to date at all times.
At the same time, you have to remember that sometimes "obvious things" are not always that "obvious", when you look at them at a bit different angle,
and that is the point of this post.
Probably telnet is simpler but it might be historical reasons as well.
I want to enable compression method on my TLS server developed using JSSE. I know it is not advisable to use compression method in server due to CRIME attacks, but for study(Analysis) purpose I need it. Please help!
You can't. There is no indication of any support for TLS compression in the JSSE reference documentation, and the compression portion of the Wikipedia entry for TLS implementations specifically states that JSSE does not support compression.
The one reference to compression in the JSSE documentation does state you can provide your own compression implementation:
The sockets returned to the application can be subclasses of
java.net.Socket (or javax.net.ssl.SSLSocket), so that they can
directly expose new APIs for features such as compression, security,
record marking, statistics collection, or firewall tunneling.
No out-of-the-box SSL/TLS implementation supports compression. You will have to compile your own. With OpenSSL, compression can be enabled with configure options [enable-]comp and [enable-]zlib[-dynamic]. For example:
./configure enable-comp enable-zlib --prefix=/usr/local/openssl-1.0.2h ...
For OpenSSL, see https://wiki.openssl.org/index.php/Compilation_and_Installation
I would like to configure the server to refuse negotation of DES, RC4, MD5, etc. The mono 3.4 release notes say "Network Stack Now allows developers to control which cipher suites to use with TLS/SSL." ... But how?
(Thanks to Sebastien Pouliot for this answer)
You can set a callback for either ClientCipherSuitesCallback or ServerCipherSuitesCallback SSL/TLS. That will allow you to control which ciphers can be used and the selection order (in general most server select the first cipher suites they support).
Sample code is part of the documentation.
And also, since it will likely be difficult for some people to find the valid enumerations, see CipherSuiteFactory.cs