# Network threat model

As the client's features build heavily on networking the security of the connections must be examined.

## Threats categorized

1. Malicious party tries to DoS attack the machine running Nano.
1. Malicious party tries to access restricted content though Nano.
1. Malicious party tries to publish content though Nano without permission.
1. Malicious party tries to attack by uploading malicious content though Nano.
1. Malicious party tries to gain access to the machine through Nano. (exploiting vulnerability)

## Possible impact of exploiting the threats

1. Denial of service attack.

    As with any service/server software, it is possible to overwhelm a Nano even with a sheer amount of requests.

1. Forged or illicit data retrieval requests.

    If an attacker has the necessary information, they can forge requests that shall not be served by Nano. If the
    system fails to adhere to the policies set up by the Nano's owner the attacker may gain access to restricted
    content.

1. Forged or illicit data publishing requests.

    If an attacker has the necessary information, they can forge requests that shall not be served by Nano. If the
    system fails to adhere to the policies set up by the Nano's owner the attacker may upload or change already
    existing content hosted by the Nano.

1. Abusing the legitimate permissions.

    A legitimate user that has been granted "write" access to a Nano could abuse their privilege to publish illicit
    content or malicious software. The simplest and most directly destructive action they could take is mass-deleting
    content from the Nano's storage. In a more sophisticated case they may use this to attack the Nano machine or
    other users that access the particular Nano.

1. Nano as an attack vector.

    If an attacker manages to mislead the Nano client to accept forged requests, they can do anything the configuration
    allows. Maybe even change the configuration.

## Threat mitigations

1. The machine running Nano is somewhat protected from DoS attacks by design. All requests are routed through the
Clarabot servers. They act as specialized proxies and hide the IPs of machine running Nano. The servers (provided
there are enough of them) will be able to fend off DDoS attacks even. They will become a CDN network of sorts, with
private server solutions behind them.

    The machine running Nano can also implement rate limiting for specific users or IPs as necessary.

1. Attackers cannot send requests to a Nano directly, so they have to deceive or exploit the Clarabot servers to get
an illicit request sent to a Nano at all. When a request is received the Nano will check the permissions of the assigned
resource and if desired check the digital signature of the request to be legitimately from a member of the group. Then
the request server process will also validate the request by the local configuration and policy of the Nano.

    By design an attacker will need to impersonate a member of the group to gain access through the system. This is only
    possible if the attacker steals the device or identity of a member (by XSS for example). Nobody at Clarabot could do
    it as all user credentials are encrypted. Even if the attacker manages to steal the whole database, they would not
    be able to use it to facilitate such an attack.

1. This point is very similar to (2). The attacker will need to impersonate a valid user.

1. In this case the attacker is already a seemingly valid member and they are also granted "write" permission to the
Nano. The system cannot differentiate between a user request of good or malicious intent. The system will give granular
permission settings and options for Nano owners to set up their groups and who they trust. A deterring factor for abuse
by users is that their actions will be logged on the Nano and will be available to the owner if they need it.

1. The architecture of Nano makes it very difficult for an attacker to exploit it, because Nano never accepts
incoming connections.

    Nano works as a hybrid client application that connects to well-known servers. After it joins the network of servers
    as a user-controlled extension it will listen for remote requests on the established connection. There is no public
    interface which any process in a Nano instance is listening on by default. An attacker would have to manipulate
    the victim's network, poison their DNS, forge server certificates that seem valid to the client, spoof the server's
    API and steal the database from the server to be able to present the client with a seemingly valid but illegitimate
    login-challenge to then exploit Nano as an attack vector.

## Mitigation evaluation

The architecture gives a good baseline to mitigate denial of service attacks (1). These can be improved further later.

The threats of (2) and (3) are very similar in that they involve an attack making illicit requests. Since (unless
anonymously shared public) all requests are going to be encrypted or digitally signed by requesting members they
cannot be forged, unless the member's account is compromised.

Abusing the trust in a group (4) is an issue that cannot be prevented automatically. The best solution to deter
malicious actions is to carefully manage the permissions, but in case of abuse the Nano instance will provide logs
of who did what that may be used by the owner.

We consider (5) mitigated by design, but there are still caveats such as the user must get the Nano software from a
reputable source or it could be infected with malicious code.

## Conclusion

The architecture makes many direct attack vectors ineffective by design. That's why most security threats are
dependant on stealing or compromising a user's account.
