<p>It probably doesn't help much.</p>

<p>If the wallet (server) and the script (client) are running on the same computer, and you're connecting to it directly (e.g. on 127.0.0.1), then the data being sent should never reach any external network, and could only be intercepted by the user(s) running those programs, or a system administrator with higher privileges.  In most cases, those people would also be able to recover the SSL key, so encryption would not help very much.  For that matter, they would also probably be able to recover private keys and other sensitive data directly from the files or memory being used by the programs. </p>

<p>On the other hand, in most cases, RPC has so little traffic that the overhead of encryption is negligible, so it costs you almost nothing to turn it on, and it might make an attacker's job somewhat more difficult.</p>

<p>If your system uses more advanced separation of privileges (e.g. Linux admin capabilities and securelevels) then there might be more situations where someone might have access to local network traffic but not the keys or other sensitive data.  In such cases, encryption could make more of a difference.  </p>

CC BY-SA 3.0
2017-07-31T17:55:33.950Z
2017-07-31T17:55:33.950Z
Nate Eldredge
<p>Dears,
If the PHP script and the Bitcoin wallet are on the same computer, does encrypting the link is necessary? like turn ssl on:rpcssl=1</p>

<wallet><security><exchanges><json-rpc>
If the PHP script and the Bitcoin wallet are on the same computer, does encrypting the link is necessary?
jiejie
# If the PHP script and the Bitcoin wallet are on the same computer, does encrypting the link is necessary?

(Asked by: username_0 on 2017-07-31)

Dears,
If the PHP script and the Bitcoin wallet are on the same computer, does encrypting the link is necessary? like turn ssl on:rpcssl=1

**Tags:** wallet, security, exchanges, json-rpc


---

## 1 answers

### Answer by username_1 on 2017-07-31. Score: 2 | Accepted answer

It probably doesn't help much.

If the wallet (server) and the script (client) are running on the same computer, and you're connecting to it directly (e.g. on 127.0.0.1), then the data being sent should never reach any external network, and could only be intercepted by the user(s) running those programs, or a system administrator with higher privileges. In most cases, those people would also be able to recover the SSL key, so encryption would not help very much. For that matter, they would also probably be able to recover private keys and other sensitive data directly from the files or memory being used by the programs.

On the other hand, in most cases, RPC has so little traffic that the overhead of encryption is negligible, so it costs you almost nothing to turn it on, and it might make an attacker's job somewhat more difficult.

If your system uses more advanced separation of privileges (e.g. Linux admin capabilities and securelevels) then there might be more situations where someone might have access to local network traffic but not the keys or other sensitive data. In such cases, encryption could make more of a difference.


---

