Transparent proxy channels revisited

[mike1813]

At present, if a client accesses a service via transparent proxies, we get two sets of client channels representing client-service relationships:

• an end-to-end client channel, representing the end-to-end authentication and trust relationship.
• a channel per direct connection to/from a proxy, representing the relationships of proxies to their clients/services.

When attributes are affected in one of these, it may propagate to the other. This is discussed extensively in #68, but only for threats causing or caused loss of authenticity or trustworthiness in the client channel, i.e., threats relating to service access.

There are other TW attributes and behaviours that affect these relationship assets:

Being Out of Service is not a behaviour but a TW attribute (it represents a safer, albeit usually undesirable state). The behaviour affecting it is InService. If present in a complete chain of direct channels via transparent proxies, then it should propagate to the indirect end-to-end channel.

Comms Snoopable is a behaviour which should propagate to the indirect channel if any direct channel via a transparent proxy is affected and in service, but not vice versa.

Loss of Accessibility is a behaviour which should propagate to the indirect channel if there is no complete and unaffected chain of direct channels from client to service.

Loss of Accessibility could also propagate to direct channels, but a direct channel should only be affected if all the associated indirect channels are inaccessible. This is of academic interest only, as any loss of availability caused by an inaccessible channel should only ever be caused by an end-to-end channel.

The propagation of these behaviours between direct and indirect channels is achieved either by threat causing them (affecting both channels if present), or by a privilege exploitation or secondary threat caused in one and affecting the other.

The threat models used to do this don't currently implement the above propagation principles. They fail to accommodate the possibility that an end-to-end client-service connection might be able to use distinct chains of transparent proxies. In fact, at present:

• An indirect channel would be In Service only if all associated direct channels were In Service, but if there are multiple distinct end-to-end paths it would be OK if some (but not all) paths contained a direct channel that was not In Service.
• Loss of Accessibility is similar - one would need all end-to-end paths to contain at least one direct channel with the behaviour before the end-to-end channel was affected.

Comms Snoopable is handled correctly, because an indirect end-to-end channel would be snoopable if any (non-disabled) direct channel it uses was snoopable, even if only one of many possible proxy chains were affected. If the snoopable direct channel was disabled, it would have no effect on the snoopability of the end-to-end channel so that is handled correctly. (Unlike the effect of disablement on accessibility).

Loss of Anon User TW is also OK because it uses a step-wise propagation mechanism via transparent proxies, which reaches the back-end service unless all paths are blocked. This means intrusion and snooping attacks are modelled sufficiently well.

The problem is with threats that model DoS attacks, or the effects (including side effects) of defences based on disablement of client-service communications. In both cases, the effects on client-service communication availability may be overestimated. In some cases, a defence based on disablement that is viable may appear non-viable due to the predicted loss of availability.

It is unclear how best to fix this. Creating an asset per end-to-end proxy chain, with indirect client channels being linked with one or more of these is the simplest solution to implement. However, the number of such chains may be very large, so this approach may lead to drastic increases in the computational cost for system model validation and risk analysis.

[mike1813]

To be honest, it is unlikely that a client would be able to access and authenticate with a service via transparent proxies using more than one distinct chain of proxies.

Transparent proxies are normally used to provide a service endpoint on a network from which it cannot be addressed directly, e.g., making a service running in a data centre accessible on the Internet. The proxy is located at a gateway which normally provides the only connection between the external and internal networks. One could run multiple proxy instances, e.g., for increased availability, but these would be instances of a non-singleton proxy class, which could be handled by the existing logic.

On that basis, this issue should not be seen as a high priority at this time.

[mike1813]

This issue has been overtaken by events. The changes needed for OIDC authorization code flow force a distinction to be made between being able to send messages to a service, and having direct access. This leads to a slight rethink as follows.

A Client Channel is either:

1. Direct and end-to-end: means the client connects directly with the service, and the client is authenticated by the service or by redirection to an OIDC-style authenticator
2. Indirect and end-to-end: means the client does not connect directly with the service, but the client's credentials are validated by the service by either
   • authenticating a client credential forwarded via intermediaries
   • exchanging a client credential for an access token via the OIDC Auth Code flow
3. Direct but to/from an intermediary that does not authenticate the client itself or via redirection, but instead forwards the client credentials.

Channels of type (1) and (3) are simple, and have a domain#channelVia property referring to one or more Service Channels (i.e., network communication paths). In channels of type (2), this property refers to client channels of type (3) related to intermediaries. The interpretation of Client Channel TWA depends on whether it is type (1), (2) or (3).

Connections from a client to a reverse proxy are treated the same as any other connections. What matters is whether the service authenticates the client, not what type of service it is. Access via a reverse proxy isn't quite the same as direct access, as one can't control all parts of the request message sent to the back-end service, but one can specify the request content and endpoint.

The term 'transparent proxy' was previously used to describe an intermediary in the sense defined by case (3). This term has been deprecated. It should be removed from all entity descriptions, although it may take some time to do this.

The reason is that an intermediary does not in general forward a request to a back-end service. In many cases, the intermediary is responsible for an application workflow, using back-end services as resources. Unless the intermediary is also a reverse proxy, it is responsible for creating as well as composing workflows over back-end service requests.

The interpretation of client channel attributes is therefore as follows:

• Anon User TW: relates to who can send messages directly to a service, hence who can attack or attempt to access the service. It has meaning only for channels of type (1) and type (3). For type (2) connections, an attacker can attempt access if at least one of the related type (3) channels has low Anon User TW. The attacker injects a message directly or via an intermediary.
• Client Authenticity: relates to who has access to client credentials, hence who could authenticate to the service should they have the ability to send it a request. It doesn't mean they can access the service, however.
• Client TW: relates to who has authenticated access to the service as the client. For type (2) this refers to the 'end-to-end' client. Low Client TW may mean the client has been impersonated. It doesn't mean the real client is untrustworthy or compromised but where that is the case, Client TW will be low.
• Proxy User TW: relates to channels from a reverse proxy, signifying who has the ability to send requests to a service via the proxy. As discussed above, this includes formulating the request, but not making the connection. It allows access to the back-end service, and where the service is a remote access service, to the back-end service host.
• Deputy User TW: relates to channels from a service to other services, indicating who can use the first service to potentially access the second by indirect means. Low Deputy User TW means someone can attempt a confused deputy attack on the first service to gain unauthorized access without authenticating to the second. The service is an intermediary, but not in the sense of type (3).
• Service Authenticity: relates to whether the client can avoid connecting to an imposter service. Low Service Authenticity means there is an imposter service with which the client conducts an extended interaction - not just a one-off exchange.
• Service TW: relates to who controls the service.

In due course, it would make sense to define distinct Client Channel subclasses for direct and indirect connections, so they can have different sets of TWAs. For now this has not been done because controls are often applied to Client Channels, and introducing new subclasses would break references to them in system models.