If I'm communicating security and trust over a network, I might simply note trusted and untrusted nodes. For example, when making an HTTPS connection over some kind proxy node that I own and operate, I trust the protocol and the entire node:

Simple trust relationship

But some connections are more nuanced. I can trust HTTPS to secure the content of my message and the identity of the destination, but activity logs depend on my relationship with the operator and owner of the node. I might operate the node but not own it. Or own it but not operate it. Or neither.

Failed attempt 1

Attempt to show layers of trust in a node

Failed attempt 2

Another attempt to show layers of trust

How can I diagram this? (A general notation for layered trust on a single node is welcome. In other words, not specific to HTTPS and proxying.)

3 Answers 3


You may want to look into EFF's diagram of comparison between Tor and HTTPS for some inspiration: https://www.eff.org/pages/tor-and-https

enter image description here

Note the actual diagram in the EFF site is interactive, which is neat but not strictly necessary as you can illustrate the same using multiple images as well.

The basic idea is that you need to identify each piece of information that has different security domains and label which domain are privy to which piece of information.

  • I'll add this as a link for interested readers, thanks!
    – lofidevops
    Mar 22, 2018 at 13:15

I feel like there is substantially more technical items omitted from the diagram and even the question.

On a long enough timeline the trust from your TLS implementation decreases due to computing resources available to an attacker, the probability of the TLS implemented algorithms or more generally the libraries containing side channel, cipher downgrade, flaws in the PRNG for key generation etc.

In addition to protocols you must also take into account the overall security posture of the paths involved, network devices as well as other nodes fall into the same linear determination of security when not properly maintained and/or configured.

Trying to isolate the diagram to only own or operate fails to address the need to illustrate the complexities of those resources involved.

While saying own and operate will provide the necessary trust, this is not always the case when flaws are not disclosed or known prior to a successful compromise.

  • I am deliberately assuming perfect user, operators and protocol designers, so that I can get into these details as required (i.e. that you are assigning trust to these roles, that you are assumed to be using the protocol appropriately...)
    – lofidevops
    Mar 22, 2018 at 13:20

I realised that I was getting confused by my informal notation of striking through an untrusted, intermediary node and terminating at the edge of a trusted, terminal node. The proxy node is intermediary, but has four possible trust configurations.

So I decided that all intermediary nodes must be struck through, regardless of trust status, indicating that the message remains protected by the protocol.

Thus I can diagram the non-trivial scenarios as follows, and discuss the implications in each case:

Trustworthy owner, untrusted operator

Untrusted proxy operator

Untrusted owner, trustworthy operator

Untrusted proxy owner

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .