mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-20 11:45:50 +00:00
Secure signing: dedicated hardware, LAN requirement tweaks, etc.
This commit is contained in:
@@ -51,7 +51,7 @@ In this configuration, you run `rippled` on the machine that generates the trans
|
||||
|
||||
In this configuration, you run a `rippled` server on a dedicated machine in the same private local area network (LAN) as the machine that generates the transactions to be signed. This configuration lets you assemble transaction instructions on one or more machines with very modest system specs, while using a single dedicated machine for running `rippled`. This may appeal to you if you run your own datacenter or server room.
|
||||
|
||||
To use this configuration, set the `rippled` server to accept `wss` and `https` connections within your LAN. You can use a self-signed certificate if you use [certificate pinning](https://en.wikipedia.org/wiki/Transport_Layer_Security#Certificate_pinning), or you can use a certificate signed by an in-house or well-known Certificate Authority.
|
||||
To use this configuration, set the `rippled` server to accept `wss` and `https` connections within your LAN. You can use a self-signed certificate if you use [certificate pinning](https://en.wikipedia.org/wiki/Transport_Layer_Security#Certificate_pinning), or you can use a certificate signed by an in-house or well-known Certificate Authority. Some certificate authorities, such as [Let's Encrypt](https://letsencrypt.org/) issue certificates automatically for free.
|
||||
|
||||
<!--{# TODO: link api-over-lan.html with the detailed instructions when those are ready #}-->
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
<!-- DRAFT / INCOMPLETE PAGE. THESE INSTRUCTIONS MAY NOT WORK AS DESCRIBED. DO NOT TRUST THEM UNTIL THIS HAS BEEN MORE THOROUGHLY REVIEWED. -->
|
||||
|
||||
***TODO: Describe how to set up a self-signed cert and use certificate-pinning on the client side to protect against MITM attacks.***
|
||||
***TODO: Describe how to generate a self-signed cert and use certificate-pinning on the client side to protect against MITM attacks AND/OR describe how to use Let's Encrypt to get and renew a ceritificate automatically. In either case, instruct how to configure the server w/ the cert.***
|
||||
|
||||
**Warning:** This configuration comes with the additional downside that anyone on the LAN can sniff traffic between your machines, potentially gaining access to your secret keys. Do not use this configuration on a network that may have strangers on it. For example, on the LAN at a colocation facility or cloud host, other customers may be able to get access to the traffic between your machines. If you employ several developers sending test transactions, you could run one `rippled` machine for your whole office, while the developers use cheaper hardware, but any user on your office network could potentially use a packet sniffer to get access to developers' secret keys. ***TODO: with proper certs set up this mostly doesn't apply***
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 72 KiB After Width: | Height: | Size: 75 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 97 KiB After Width: | Height: | Size: 144 KiB |
Reference in New Issue
Block a user