How much easier would it be to break into a system if you knew the following information?
I'd like to know how much easier and which components are most sensitive in this regard (subjective answers OK). Assume that, other than this information, reasonable effort was made to make the system secure, e.g. secure protocols and keys would be used where appropriate.
This information is not sensitive.
An attacker would gain very little by knowing these facts beforehand. Many of them are either not relevant to their campaign, or trivial to detect remotely, even if the configuration is not published. In order to answer adequately, you may want to elaborate on what you mean by "break in". Is the attacker attempting to bypass authorization remotely? Do they have a local process running on the system and are attempting to elevate privileges? Are they trying to root a commercial embedded system that they have purchased and have physical access to? Hiding this information may slow down someone who is trying to jailbreak a commercial system for a short amount of time by forcing them to spend time reverse engineering it, but it will do nothing against an attacker with a local shell trying to get root.
There is only one situation where hiding certain information is beneficial, and that is when an attacker is attempting mass-exploitation of a remote vulnerability. Having your application withhold its exact version can decrease the chance that an army of bots scanning the entire internet will attempt to exploit you. This will not protect against anyone who is looking to exploit you specifically, however.
Processor family
The processor family itself tends not to matter. The overwhelming majority of exploits, of all kinds, will work equally well on Skylake as on Kabylake. If you're talking about processor architectures, then it starts to matter, as MIPS shellcode will not work on an ARM system, and vice versa. However, this is not something that should be obscured, as the majority of servers and systems in general are running x86, mobile systems tend to run ARM, and embedded systems often run MIPS.
Operating system
Whether or not the operating system even needs to be known depends on what is being exploited. If a web app is being attacked, the operating system may not even be relevant. A SQLi vulnerability in a popular web platform will work equally well on Windows, Linux, FreeBSD, Solaris, or any other operating system that can run the vulnerable application. If the attacker is trying to attack the system itself to elevate privileges, it may be necessary to know the operating system. This information can be obtained remotely through a technique known as OS detection, or OS fingerprinting.
Libraries used
There are some libraries that will generally always be used. You will practically never find something that does not link against libc. A program doing math will likely use libm. A program that accepts user input via CLI will likely use libreadline. There are not many exceptions. If an attacker is trying to exploit a program, they only need to know the libraries in use if they are exploiting a particular vulnerability in the library. It's easy to check which libraries a program needs, as the list is encoded into the executable itself. Various scripts like ldd can gather this information from an executable.
Application programming language
The programming language for a vulnerable program may matter, depending on the type of exploit that is being used. A language like PHP which does its own memory management (is memory-safe) tells you that you will not need to attempt a stack overflow, as memory is managed. A C program on the other hand may be vulnerable to such a bug, as it is lower level. Knowing the language itself is neither necessary, nor sufficient for exploitation. The overlap in knowledge between a person who knows enough about a program to exploit it, and a person who does not know the language it uses, is zero.
Standardised protocols used
Some protocols are more vulnerable than others. DCCP for example has a history of nasty vulnerabilities. Rather than attempting to hide the protocols you are using, it would be far better to disable the unnecessary ones, as an attacker can simply attempt a connection with said protocol to see if it is supported. If the connection fails, it is either unsupported, or the port is closed. Either way, attacking the protocol itself will not be possible if it is not open and supported.
There are different types of attackers. For this answer, let's split up the types of attackers into local, remote, and physical, and see what position they are in to gather the information they need.
A local attacker is running a process on your system. They want to elevate their privileges, or move laterally to other users. They may or may not be sandboxed. A local attacker is one of the most dangerous, as they have access to any information the operating system willingly gives out.
/proc/cpuinfo.ldd or readelf on it.socket() syscall can allow testing if a given protocol is supported.A remote attacker is trying to compromise a server. Their only interaction with the target is over the network, subject to any firewall rules that may be in play. They want to gain unauthorized access to the system by exploiting vulnerabilities in remotely running services.
A physical attacker has your device in their hands. They may be trying to reverse engineer it and jailbreak it to expand its functionality or access secrets it is storing. They can open the device, look at the labels on the components, dump firmware, and possibly even attach the CPU to a debugger. This is the most powerful class of attacks. There is generally no way to prevent a physical attacker from gaining detailed information about your system, given enough time.
In general, this information is either easy to find out, not necessary to know, or difficult to hide. There are far better ways to improve your security. Now, what you should do, rather than hiding the following:
While there is no reason to reveal all this information (assuming you are not expecting collaboration, where revealing information can help people point out bugs for you to fix), some of the details you mention are either so irrelevant or so easy to detect that you would have to go to excessive lengths to hide that information. Simply disabling version information is one thing. Wasting effort trying to prevent someone from knowing if you are on an x86 system or a SPARC system is just unnecessary.
Some resources you might be interested in:
