transport v0.1.0 Transport.Tls View Source

implements a two-way TLS transport strategy.

this transport is useful when you have trusted clients and servers that are authenticated against each other and must have an encrypted channel over WAN.

Link to this section Summary

Server Functions

Callback implementation for Transport.accept/2.

(server) a specialized function that generates a match function option used to verify that the incoming client is bound to a single ip address.

Callback implementation for Transport.listen/2.

Client Functions

(client) responds to a server TLS handshake/2 request, by upgrading to an encrypted connection. Verifies the identity of the server CA, and reject if it's not a valid peer.

Functions

Callback implementation for Transport.recv/2, via :ssl.recv/2.

Callback implementation for Transport.recv/3, via :ssl.recv/3.

Callback implementation for Transport.send/2, via :ssl.send/2.

Link to this section Types

Link to this section Server Functions

Link to this function

accept(sock, timeout)

View Source
accept(socket(), timeout()) :: {:ok, socket()} | {:error, term()}

Callback implementation for Transport.accept/2.

Link to this function

handshake(socket, handshake_opts)

View Source
handshake(:inet.socket(), keyword()) :: {:ok, Api.socket()} | {:error, any()}

(server) a specialized function that generates a match function option used to verify that the incoming client is bound to a single ip address.

This is also the place where you should set post-connection options, such as setting active: true.

NB: in many point-to-point trusted TLS operations you will want to perform a symmetric check against the identity of the inbound client. Normally you wouldn't do this for web (e.g. HTTPS) TLS because public clients typically don't have a static DNS-assigned address. Users of Transport should strongly consider using this feature. To perform a check against the client, Transport has implemented :customize_hostname_check for servers as you would in the normal client SSL case.

You should use the options verify_peer: true and customize_hostname_check: <check> See: http://erlang.org/doc/man/ssl.html#type-customize_hostname_check and :public_key.pkix_verify_hostname/3 to understand this feature.

Link to this function

listen(port, options \\ [])

View Source

Callback implementation for Transport.listen/2.

NB: Transport.Tls defaults to using a binary tcp port.

Link to this section Client Functions

Link to this function

connect(host, port, options \\ [])

View Source
connect(term(), :inet.port_number(), keyword()) ::
  {:ok, socket()} | {:error, term()}

Callback implementation for Transport.connect/3.

Link to this function

upgrade(socket, options!)

View Source
upgrade(socket :: socket(), options :: keyword()) ::
  {:ok, :ssl.socket()} | {:error, term()}

(client) responds to a server TLS handshake/2 request, by upgrading to an encrypted connection. Verifies the identity of the server CA, and reject if it's not a valid peer.

This is also where you should set post-connection options (such as setting active: true)

If you would like to timeout on the ssl upgrade process, pass the timeout value to the keyword :timeout in options

Callback implementation for Transport.upgrade/2.

Link to this section Functions

Link to this function

recv(sock, length)

View Source
recv(socket(), non_neg_integer()) :: {:ok, binary()} | {:error, term()}

Callback implementation for Transport.recv/2, via :ssl.recv/2.

Link to this function

recv(sock, length, timeout)

View Source
recv(socket(), non_neg_integer(), timeout()) ::
  {:ok, binary()} | {:error, term()}

Callback implementation for Transport.recv/3, via :ssl.recv/3.

Link to this function

send(sock, content)

View Source
send(socket(), iodata()) :: :ok | {:error, term()}

Callback implementation for Transport.send/2, via :ssl.send/2.