Is your feature request related to a problem? Please describe.
A virus on a computer can listen to unencrypted RPC traffic and an attacker can steal Bitcoins even from an encrypted wallet
Describe the solution you'd like
It is necessary to implement support for encrypted public key RPC calls in Bitcoin Core as it done in the https protocol
IIRC RPC requests are over http (correct me if I am wrong). Bit I agree that we need SSL support
A virus on the computer can replace the bitcoind binary with one that steals your coins regardless. There is no way around running Bitcoin on trusted hardware.
If you really need SSL encrypted RPCs, use stunnel or something similar. Bitcoin Core used to actually support SSL encrypted RPC, but support was removed because (1) it sets up incorrect expectations (against many attack scenarios it does not help) and (2) it was a pain to setup and maintain.
We can easily authenticate bitcoind with hash or other checksum, but it’s much harder to learn about listening RPC traffic and to recognize the authenticity of RPC requests
How stunnel can help to prevent from sniffing RPC on localhost?
Again, if the attacker has that kind access to the machine that runs bitcoind, he can do lots of other things too. Overwriting the binary is just one. Another is just reading the decrypted keys from RAM, or adding his own keys to the keypool in wallet.dat, making sure change gets sent to him at some point in the future long after he left the machine.
I think that readig specific region of RAM from another process is too complicated operation by comparison with traffic listenig. Sniffing is the most common functionality of trojans, but RAM listenig should by designed for one specific process with one specific binary version
And I do not known about possibility of changing encrypted wallet.dat. Is it possible?
Sorry, that's nonsensical. All it needs is one smart guy to write a tool for hijacking wallets by running in a place with sufficient access to bitcoind. The threat model cannot possibly protect against that. Trying to use encrypted traffic to circumvent that will only contribute to a false sense of security.
Here is the discussion around removing it: #5677 (comment) and here: https://bitcoin.stackexchange.com/a/39118/208
That discussion is about "expose bitcoind RPC to a public accessible area" But using encrypted RPC on localhost was not discussed. I think encrypting RPC on localhost will really increase security.
I think encrypting RPC on localhost will really increasy security.
I've shown that it cannot. At best it makes attacks a bit more complex, but the security assumptions remain the same: if you have local access to the server process, you cannot hope to have any security.