Next: libp2p, Previous: Tor Onion Services, Up: Netlayers [Contents][Index]
The TCP + TLS netlayer is available as a simpler option than Tor or
other peer-to-peer networks. Direct connections are made over
standard TCP sockets and all traffic is encrypted with self-signed TLS
keys. A new netlayer instance can be spawned with the
^tcp-tls-netlayer object from the (goblins ocapn
netlayer tcp-tls) module. The TCP + TLS netlayer is often used in
conjunction with, and as a foundation for, the Prelay (Unencrypted, v0) netlayer.
> (define netlayer (spawn ^tcp-tls-netlayer "example.com")) > (define mycapn (spawn-mycapn netlayer))
Users of this netlayer can either bring their own X.509 key and
certificate by importing them from the file system, or let Goblins
automatically generate them. The ^tcp-tls-netlayer is
persistence aware meaning that it can be persisted and restored using
Goblins’ persistence system. Here’s an example of this:
(define-values (ocapn-vat tcp-tls-netlayer tcp-tls-mycapn) (spawn-persistent-vat (make-persistence-env #:extends (list tcp-tls-netlayer-env)) (lambda () (define netlayer (spawn ^tcp-tls-netlayer "example.com")) (values netlayer (spawn-mycapn netlayer))) (make-syrup-store "ocapn.syrup")))
The current major limitation of this netlayer is the lack of both “store and forward” and NAT hole punching support. Most machines that are not dedicated servers are not accessible from the public Internet due to the presence of a NAT gateway between the local network and the Internet. For this reason the most common way to use the TCP + TLS netlayer is as an underlying foundation for the Prelay (Unencrypted, v0) netlayer.
Without using the Prelay (Unencrypted, v0) netlayer, the only way to reach peers behind NAT gateways is if those peers have setup the necessary port forwarding configuration on their local network’s firewall and have configured the netlayer to use their public IP as the host name. If your application would benefit from a more peer-to-peer netlayer, consider using the Tor Onion Services netlayer instead, which is more peer-to-peer at the cost of high latency.
Sturdyrefs for this netlayer use a SHA-256D hash of the TLS certificate as the node identifier. The address and port where the node can be found on the network are encoded as hints.
Also, note that the current version of this netlayer is robust against man-in-the-middle attacks in the sense that an attacker cannot manipulate or decode communication occurring over the TLS encrypted stream. However, no attempt has been made to prevent network monitoring attacks where an attacker provides a sturdyref with hints pointing at an intermediary server where the attacker can observe when and how much traffic is occurring, even though they cannot interpret the contents. In addition, the attacker could choose to sever the connection when it is convenient for them. This is generally the case already on nation-state level attacks against TLS, but is more readily available as a possible avenue of attack here. In the future, hints might be signed in order to prevent this.
Construct an TCP-TLS netlayer actor. host specifies the hostname that appears in the OCapN sturdyrefs that use this netlayer.
If port is specified, the netlayer will listen for incoming connections on that port or throw an error if the port is already in use. If port is not specified, an open port will be chosen automatically.
max-connections specifies the number of peers that may be connected to the netlayer at any given time.
key and cert specify the X.509 private key and certificate to use for encrypting connections. If one or both are unspecified, they will be automatically generated provided that the version of Guile-GnuTLS is new enough to do so.
Return a freshly generated X.509 private key.
Return a freshly generated X.509 certificate for key.
Next: libp2p, Previous: Tor Onion Services, Up: Netlayers [Contents][Index]