The Inner Circle

I figured I would post this here, although I apologize as this might not be the right place.  As we are all familiar with Zero Trust (ZT) and ZTA what and how does everyone feel about SSL encryption when it comes to certificate pinning?  NIST 800-53 also calls this out under AC-4(4) and SI -4(10).  At a technical level most if not all major vendors be that Microsoft or not, have fully enabled certificate pinning to ensure that no MITM attacks can occur.  The data between you and them is encrypted and only decrypted or terminated on the host making the request.  From a perimeter perspective, no firewall can decrypt this traffic because if one was to try the pinning would fail.  The only solution is to ensure the host making the request has the proper AV or malware scanners, the system is patched, etc.  This screams supply-chain-attack because when you look at Solar Winds and others, validating the certificate would be useless as the bad actor changed the code to the application.  However, I do understand with Solarwinds, that even end-point controls would not be effective unless you whitelist outbound requests at the perimeter or from the local host.  Curious what others' thoughts are? To fully trust Microsoft or any vendor today seems like a bad idea, regardless of what the agreement is between the parties, as it will only cost money to seek a legal path to gain back lost revenue or funds.  Maybe someone created a new mouse trap for this and I am not aware, but very excited to see what people bring up about this.

Hey Ross,

Personally, I think strong E2EE based on certificates/crypto is a fundamental premise of treating the network as compromised and hostile.I think, correct me if I am wrong, you are suggesting doing decryption on all packets to ensure no vulnerability is getting through. While zero trust has many varied interpretations, one point it is explicit on is that there is no single perimeter for us to decrypt packets and the development of protocols such as TLS1.3 make decryption super hard anyway. 

Is my interpretation of you comment correct? If it is, the question becomes (I think), how can we ensure system security and zero trust while using E2EE between source and destination... would you agree???

Regards

Philip

I figured I would post this here, although I apologize as this might not be the right place.  As we are all familiar with Zero Trust (ZT) and ZTA what and how does everyone feel about SSL encryption when it comes to certificate pinning?  NIST 800-53 also calls this out under AC-4(4) and SI -4(10).  At a technical level most if not all major vendors be that Microsoft or not, have fully enabled certificate pinning to ensure that no MITM attacks can occur.  The data between you and them is encrypted and only decrypted or terminated on the host making the request.  From a perimeter perspective, no firewall can decrypt this traffic because if one was to try the pinning would fail.  The only solution is to ensure the host making the request has the proper AV or malware scanners, the system is patched, etc.  This screams supply-chain-attack because when you look at Solar Winds and others, validating the certificate would be useless as the bad actor changed the code to the application.  However, I do understand with Solarwinds, that even end-point controls would not be effective unless you whitelist outbound requests at the perimeter or from the local host.  Curious what others' thoughts are? To fully trust Microsoft or any vendor today seems like a bad idea, regardless of what the agreement is between the parties, as it will only cost money to seek a legal path to gain back lost revenue or funds.  Maybe someone created a new mouse trap for this and I am not aware, but very excited to see what people bring up about this.

Hi Philip, Cert pinning and E2EE are one and the same, so apologize there. So you are correct in your post throughout.  Curious what you are thinking 🤔.

Hey Ross,

Personally, I think strong E2EE based on certificates/crypto is a fundamental premise of treating the network as compromised and hostile.I think, correct me if I am wrong, you are suggesting doing decryption on all packets to ensure no vulnerability is getting through. While zero trust has many varied interpretations, one point it is explicit on is that there is no single perimeter for us to decrypt packets and the development of protocols such as TLS1.3 make decryption super hard anyway. 

Is my interpretation of you comment correct? If it is, the question becomes (I think), how can we ensure system security and zero trust while using E2EE between source and destination... would you agree???

Regards

Philip

I figured I would post this here, although I apologize as this might not be the right place.  As we are all familiar with Zero Trust (ZT) and ZTA what and how does everyone feel about SSL encryption when it comes to certificate pinning?  NIST 800-53 also calls this out under AC-4(4) and SI -4(10).  At a technical level most if not all major vendors be that Microsoft or not, have fully enabled certificate pinning to ensure that no MITM attacks can occur.  The data between you and them is encrypted and only decrypted or terminated on the host making the request.  From a perimeter perspective, no firewall can decrypt this traffic because if one was to try the pinning would fail.  The only solution is to ensure the host making the request has the proper AV or malware scanners, the system is patched, etc.  This screams supply-chain-attack because when you look at Solar Winds and others, validating the certificate would be useless as the bad actor changed the code to the application.  However, I do understand with Solarwinds, that even end-point controls would not be effective unless you whitelist outbound requests at the perimeter or from the local host.  Curious what others' thoughts are? To fully trust Microsoft or any vendor today seems like a bad idea, regardless of what the agreement is between the parties, as it will only cost money to seek a legal path to gain back lost revenue or funds.  Maybe someone created a new mouse trap for this and I am not aware, but very excited to see what people bring up about this.

Hey Ross,

Right, then this is where is gets interesting. I should caveat, I am biased as what I am about to explain is our approach we deliver at the company I work. We have open sourced the tech though so you don't have to 'buy it'.

In my opinion, we should not inherently trust the device or the server making E2EE connections. I believe anyone implementing ZT would say the same. Proper AV, scanners, patching etc. allows us increase device security, BUT we need to ensure that the E2EE is checking for these requirements are met. This can be done through an overlay network which implements E2EE (and more) combined with 'posture checks'. As the ZTN overlay utilises authenticate-before-connect, we can ensure that before E2EE connections are established between client and host, the device has rigorous security in place. 

If this is not good enough for you, then stop thinking about zero trust networking as something that must stop at the network or host. Take it to its logical conclusion and embed it into your applications. This embeds ZTN, E2EE, mTLS (and more) directly into the app running in memory. The application has no listening ports on the underlay network. It's literally unattackable via conventional IP-based tooling. Seriously, stop and consider that for just a moment. By embedding ZTN, all conventional network threats are immediately useless. Lets play that out with the scenario. With app embedded zero trust, if your device is infected with malware, the malware cannot laterally move across the ZTN as the ZTN is not accessible from the host OS network. The malware would have to break into the application (not impossible but WAY harder). Even if the malware got inside the app, it cannot laterally move in the same way as this is not an OP network, they can only making application calls which are built into the application.

You may then say, ahh, but Philip, I have some web apps which are only accessible via the browser, they do not have thick client apps which can embed a ZTN SDK and run on client side. No problem, we built a 'clientless' zero trust endpoint which can be embedded into your client browser with the user only authenticating to the chosen IdP. This provides a 'public SaaS' type experience while bringing E2EE, mTLS, posture checks and more into your single browser tab, with no inherent trust in the host OS or host OS network, while the application actually sits in a private network with no inbound ports and unaddressable on the internet.

Thus we shouldn't inherently trust E2EE. Organisations and ISVs should utilise a mixture of techniques, incl. ZTN to reduce any inherent trust in client/server hosts as well as all underlay networks (WAN, LAN, host os). I liken this to providing our apps with an 'invisibility cloak' and 'port key' by borrowing Harry Potter analogies in this blog I wrote - https://netfoundry.io/demystifying-the-magic-of-zero-trust-with-my-daughter-and-opensource/. TL:DR, the app is invisible to silly muggles (malicious actors) so that they cannot find and attack it while packets magically flow from source to destination without needing to configure the networks in between.

Curious to have your thoughts on that approach...

P.S., if you want to learn more on the FOSS ZTN, here is our Github - https://github.com/openziti. For the 'clientless' endpoint - https://blog.openziti.io/introducing-openziti-browzer.

Hi Philip, Cert pinning and E2EE are one and the same, so apologize there. So you are correct in your post throughout.  Curious what you are thinking 🤔.

Hey Ross,

Personally, I think strong E2EE based on certificates/crypto is a fundamental premise of treating the network as compromised and hostile.I think, correct me if I am wrong, you are suggesting doing decryption on all packets to ensure no vulnerability is getting through. While zero trust has many varied interpretations, one point it is explicit on is that there is no single perimeter for us to decrypt packets and the development of protocols such as TLS1.3 make decryption super hard anyway. 

Is my interpretation of you comment correct? If it is, the question becomes (I think), how can we ensure system security and zero trust while using E2EE between source and destination... would you agree???

Regards

Philip

I figured I would post this here, although I apologize as this might not be the right place.  As we are all familiar with Zero Trust (ZT) and ZTA what and how does everyone feel about SSL encryption when it comes to certificate pinning?  NIST 800-53 also calls this out under AC-4(4) and SI -4(10).  At a technical level most if not all major vendors be that Microsoft or not, have fully enabled certificate pinning to ensure that no MITM attacks can occur.  The data between you and them is encrypted and only decrypted or terminated on the host making the request.  From a perimeter perspective, no firewall can decrypt this traffic because if one was to try the pinning would fail.  The only solution is to ensure the host making the request has the proper AV or malware scanners, the system is patched, etc.  This screams supply-chain-attack because when you look at Solar Winds and others, validating the certificate would be useless as the bad actor changed the code to the application.  However, I do understand with Solarwinds, that even end-point controls would not be effective unless you whitelist outbound requests at the perimeter or from the local host.  Curious what others' thoughts are? To fully trust Microsoft or any vendor today seems like a bad idea, regardless of what the agreement is between the parties, as it will only cost money to seek a legal path to gain back lost revenue or funds.  Maybe someone created a new mouse trap for this and I am not aware, but very excited to see what people bring up about this.

Thank you for all that information.  What you describe and what is in the link for Ziti is very close if not the same as something like Zscaler and others offer, but more of an all in one package.obviously Zscaler and others are in the business to make money so each component comes at a cost.  I guess my question or statement is that with EE2E that originates outside your network, be that an overlay or not, those end point that start the communication with that external party, need to be secured more than ever.  Unless I am missing how that traffic is filtered before reaching the end user?  If that is true, and I've been wrong many times, if this is in a container environment, this can be a disaster.  For example some container or laptop calls out to some vendor and that vendor uses EE2E with the communication.  The only visibility that's available is on the endpoint reaching out as it has the decryption abilities.   Microsoft, Apple, etc. all use EE2E for sending patches to machines.  That is all an inherit trust, or risk depending how you look at it.

Hey Ross,

Right, then this is where is gets interesting. I should caveat, I am biased as what I am about to explain is our approach we deliver at the company I work. We have open sourced the tech though so you don't have to 'buy it'.

In my opinion, we should not inherently trust the device or the server making E2EE connections. I believe anyone implementing ZT would say the same. Proper AV, scanners, patching etc. allows us increase device security, BUT we need to ensure that the E2EE is checking for these requirements are met. This can be done through an overlay network which implements E2EE (and more) combined with 'posture checks'. As the ZTN overlay utilises authenticate-before-connect, we can ensure that before E2EE connections are established between client and host, the device has rigorous security in place. 

If this is not good enough for you, then stop thinking about zero trust networking as something that must stop at the network or host. Take it to its logical conclusion and embed it into your applications. This embeds ZTN, E2EE, mTLS (and more) directly into the app running in memory. The application has no listening ports on the underlay network. It's literally unattackable via conventional IP-based tooling. Seriously, stop and consider that for just a moment. By embedding ZTN, all conventional network threats are immediately useless. Lets play that out with the scenario. With app embedded zero trust, if your device is infected with malware, the malware cannot laterally move across the ZTN as the ZTN is not accessible from the host OS network. The malware would have to break into the application (not impossible but WAY harder). Even if the malware got inside the app, it cannot laterally move in the same way as this is not an OP network, they can only making application calls which are built into the application.

You may then say, ahh, but Philip, I have some web apps which are only accessible via the browser, they do not have thick client apps which can embed a ZTN SDK and run on client side. No problem, we built a 'clientless' zero trust endpoint which can be embedded into your client browser with the user only authenticating to the chosen IdP. This provides a 'public SaaS' type experience while bringing E2EE, mTLS, posture checks and more into your single browser tab, with no inherent trust in the host OS or host OS network, while the application actually sits in a private network with no inbound ports and unaddressable on the internet.

Thus we shouldn't inherently trust E2EE. Organisations and ISVs should utilise a mixture of techniques, incl. ZTN to reduce any inherent trust in client/server hosts as well as all underlay networks (WAN, LAN, host os). I liken this to providing our apps with an 'invisibility cloak' and 'port key' by borrowing Harry Potter analogies in this blog I wrote - https://netfoundry.io/demystifying-the-magic-of-zero-trust-with-my-daughter-and-opensource/. TL:DR, the app is invisible to silly muggles (malicious actors) so that they cannot find and attack it while packets magically flow from source to destination without needing to configure the networks in between.

Curious to have your thoughts on that approach...

P.S., if you want to learn more on the FOSS ZTN, here is our Github - https://github.com/openziti. For the 'clientless' endpoint - https://blog.openziti.io/introducing-openziti-browzer.

Hi Philip, Cert pinning and E2EE are one and the same, so apologize there. So you are correct in your post throughout.  Curious what you are thinking 🤔.

Hey Ross,

Personally, I think strong E2EE based on certificates/crypto is a fundamental premise of treating the network as compromised and hostile.I think, correct me if I am wrong, you are suggesting doing decryption on all packets to ensure no vulnerability is getting through. While zero trust has many varied interpretations, one point it is explicit on is that there is no single perimeter for us to decrypt packets and the development of protocols such as TLS1.3 make decryption super hard anyway. 

Is my interpretation of you comment correct? If it is, the question becomes (I think), how can we ensure system security and zero trust while using E2EE between source and destination... would you agree???

Regards

Philip

I figured I would post this here, although I apologize as this might not be the right place.  As we are all familiar with Zero Trust (ZT) and ZTA what and how does everyone feel about SSL encryption when it comes to certificate pinning?  NIST 800-53 also calls this out under AC-4(4) and SI -4(10).  At a technical level most if not all major vendors be that Microsoft or not, have fully enabled certificate pinning to ensure that no MITM attacks can occur.  The data between you and them is encrypted and only decrypted or terminated on the host making the request.  From a perimeter perspective, no firewall can decrypt this traffic because if one was to try the pinning would fail.  The only solution is to ensure the host making the request has the proper AV or malware scanners, the system is patched, etc.  This screams supply-chain-attack because when you look at Solar Winds and others, validating the certificate would be useless as the bad actor changed the code to the application.  However, I do understand with Solarwinds, that even end-point controls would not be effective unless you whitelist outbound requests at the perimeter or from the local host.  Curious what others' thoughts are? To fully trust Microsoft or any vendor today seems like a bad idea, regardless of what the agreement is between the parties, as it will only cost money to seek a legal path to gain back lost revenue or funds.  Maybe someone created a new mouse trap for this and I am not aware, but very excited to see what people bring up about this.

Hey Ross,

There are similarities in some functionality between Zscaler Private Access and Ziti. A quick comparison shows Ziti being able to:

• support any use case incl. server-initiated, dynamic ports, and exotic protocols
• having a much richer amount of endpoints, incl. embed in apps, serverless, clientless, constrained edge/IoT (e.g., OpenWRT)
• Ziti has its own PKI/CA with ability to use external IdP , with explicitly authenticate-before-connect and mTLS everywhere while being able to change the ciphers if you wish
• deployable/hosted anywhere including into airgapped networks
• fully programmable, API/IaC driven (if you wish)

You are correct that giving 3rd parties the ability to update and patch their products using E2EE is inherent trust and a risk. I would argue not updating and patching would be a bigger risk. That said, we can allow 3rd parties to update/patch their infra while using ZT principles to reduce the inherent trust and risk. We should be demanding companies like Microsoft, Apple, etc, to utilise application-embedded zero trust overlays. This reduces the risk of malware and malicious injection through the supply-chain. If this is still too much of a risk, as a consumer you could demand that Microsoft, Apple et al send their traffic through an inspection point which you own, which has E2EE at ingress and egress of the inspection point. 

Regards

Philip

Thank you for all that information.  What you describe and what is in the link for Ziti is very close if not the same as something like Zscaler and others offer, but more of an all in one package.obviously Zscaler and others are in the business to make money so each component comes at a cost.  I guess my question or statement is that with EE2E that originates outside your network, be that an overlay or not, those end point that start the communication with that external party, need to be secured more than ever.  Unless I am missing how that traffic is filtered before reaching the end user?  If that is true, and I've been wrong many times, if this is in a container environment, this can be a disaster.  For example some container or laptop calls out to some vendor and that vendor uses EE2E with the communication.  The only visibility that's available is on the endpoint reaching out as it has the decryption abilities.   Microsoft, Apple, etc. all use EE2E for sending patches to machines.  That is all an inherit trust, or risk depending how you look at it.

Hey Ross,

Right, then this is where is gets interesting. I should caveat, I am biased as what I am about to explain is our approach we deliver at the company I work. We have open sourced the tech though so you don't have to 'buy it'.

In my opinion, we should not inherently trust the device or the server making E2EE connections. I believe anyone implementing ZT would say the same. Proper AV, scanners, patching etc. allows us increase device security, BUT we need to ensure that the E2EE is checking for these requirements are met. This can be done through an overlay network which implements E2EE (and more) combined with 'posture checks'. As the ZTN overlay utilises authenticate-before-connect, we can ensure that before E2EE connections are established between client and host, the device has rigorous security in place. 

If this is not good enough for you, then stop thinking about zero trust networking as something that must stop at the network or host. Take it to its logical conclusion and embed it into your applications. This embeds ZTN, E2EE, mTLS (and more) directly into the app running in memory. The application has no listening ports on the underlay network. It's literally unattackable via conventional IP-based tooling. Seriously, stop and consider that for just a moment. By embedding ZTN, all conventional network threats are immediately useless. Lets play that out with the scenario. With app embedded zero trust, if your device is infected with malware, the malware cannot laterally move across the ZTN as the ZTN is not accessible from the host OS network. The malware would have to break into the application (not impossible but WAY harder). Even if the malware got inside the app, it cannot laterally move in the same way as this is not an OP network, they can only making application calls which are built into the application.

You may then say, ahh, but Philip, I have some web apps which are only accessible via the browser, they do not have thick client apps which can embed a ZTN SDK and run on client side. No problem, we built a 'clientless' zero trust endpoint which can be embedded into your client browser with the user only authenticating to the chosen IdP. This provides a 'public SaaS' type experience while bringing E2EE, mTLS, posture checks and more into your single browser tab, with no inherent trust in the host OS or host OS network, while the application actually sits in a private network with no inbound ports and unaddressable on the internet.

Thus we shouldn't inherently trust E2EE. Organisations and ISVs should utilise a mixture of techniques, incl. ZTN to reduce any inherent trust in client/server hosts as well as all underlay networks (WAN, LAN, host os). I liken this to providing our apps with an 'invisibility cloak' and 'port key' by borrowing Harry Potter analogies in this blog I wrote - https://netfoundry.io/demystifying-the-magic-of-zero-trust-with-my-daughter-and-opensource/. TL:DR, the app is invisible to silly muggles (malicious actors) so that they cannot find and attack it while packets magically flow from source to destination without needing to configure the networks in between.

Curious to have your thoughts on that approach...

P.S., if you want to learn more on the FOSS ZTN, here is our Github - https://github.com/openziti. For the 'clientless' endpoint - https://blog.openziti.io/introducing-openziti-browzer.

Hi Philip, Cert pinning and E2EE are one and the same, so apologize there. So you are correct in your post throughout.  Curious what you are thinking 🤔.

Hey Ross,

Personally, I think strong E2EE based on certificates/crypto is a fundamental premise of treating the network as compromised and hostile.I think, correct me if I am wrong, you are suggesting doing decryption on all packets to ensure no vulnerability is getting through. While zero trust has many varied interpretations, one point it is explicit on is that there is no single perimeter for us to decrypt packets and the development of protocols such as TLS1.3 make decryption super hard anyway. 

Is my interpretation of you comment correct? If it is, the question becomes (I think), how can we ensure system security and zero trust while using E2EE between source and destination... would you agree???

Regards

Philip

I figured I would post this here, although I apologize as this might not be the right place.  As we are all familiar with Zero Trust (ZT) and ZTA what and how does everyone feel about SSL encryption when it comes to certificate pinning?  NIST 800-53 also calls this out under AC-4(4) and SI -4(10).  At a technical level most if not all major vendors be that Microsoft or not, have fully enabled certificate pinning to ensure that no MITM attacks can occur.  The data between you and them is encrypted and only decrypted or terminated on the host making the request.  From a perimeter perspective, no firewall can decrypt this traffic because if one was to try the pinning would fail.  The only solution is to ensure the host making the request has the proper AV or malware scanners, the system is patched, etc.  This screams supply-chain-attack because when you look at Solar Winds and others, validating the certificate would be useless as the bad actor changed the code to the application.  However, I do understand with Solarwinds, that even end-point controls would not be effective unless you whitelist outbound requests at the perimeter or from the local host.  Curious what others' thoughts are? To fully trust Microsoft or any vendor today seems like a bad idea, regardless of what the agreement is between the parties, as it will only cost money to seek a legal path to gain back lost revenue or funds.  Maybe someone created a new mouse trap for this and I am not aware, but very excited to see what people bring up about this.

Hi Philip, What you state "E2EE is inherent trust and a risk" is exactly what I want to focus on, but I agree with "not updating and patching would be a bigger risk".  I do not want to get into ranking this from a risk perspective but rather the guidance from NIST, ZT, and ZTA.  And while I could demand or ask Apple, Microsoft, etc. as can others, we all sign off on a document when we use their OS after installation.  So my question goes back to, how is someone compliant with the ask from these frameworks when it appears that it is not possible with E2EE in play?  You have to "trust" that these vendors are going to protect their customers and we saw what happened with Solarwinds and the trust, even at the federal level.  One could take a page from that and implicitly deny all outbound traffic with only approved destinations after vetting, however, that would be a disaster for a business and government.  Maybe there is no answer here for what I am after, and that is okay.  However, it just shows that a gap exists and an opening for technology to improve to allow customers to trust but verify before use.  There can be good MiTM and bad MiTM.

Hey Ross,

There are similarities in some functionality between Zscaler Private Access and Ziti. A quick comparison shows Ziti being able to:

• support any use case incl. server-initiated, dynamic ports, and exotic protocols
• having a much richer amount of endpoints, incl. embed in apps, serverless, clientless, constrained edge/IoT (e.g., OpenWRT)
• Ziti has its own PKI/CA with ability to use external IdP , with explicitly authenticate-before-connect and mTLS everywhere while being able to change the ciphers if you wish
• deployable/hosted anywhere including into airgapped networks
• fully programmable, API/IaC driven (if you wish)

You are correct that giving 3rd parties the ability to update and patch their products using E2EE is inherent trust and a risk. I would argue not updating and patching would be a bigger risk. That said, we can allow 3rd parties to update/patch their infra while using ZT principles to reduce the inherent trust and risk. We should be demanding companies like Microsoft, Apple, etc, to utilise application-embedded zero trust overlays. This reduces the risk of malware and malicious injection through the supply-chain. If this is still too much of a risk, as a consumer you could demand that Microsoft, Apple et al send their traffic through an inspection point which you own, which has E2EE at ingress and egress of the inspection point. 

Regards

Philip

Thank you for all that information.  What you describe and what is in the link for Ziti is very close if not the same as something like Zscaler and others offer, but more of an all in one package.obviously Zscaler and others are in the business to make money so each component comes at a cost.  I guess my question or statement is that with EE2E that originates outside your network, be that an overlay or not, those end point that start the communication with that external party, need to be secured more than ever.  Unless I am missing how that traffic is filtered before reaching the end user?  If that is true, and I've been wrong many times, if this is in a container environment, this can be a disaster.  For example some container or laptop calls out to some vendor and that vendor uses EE2E with the communication.  The only visibility that's available is on the endpoint reaching out as it has the decryption abilities.   Microsoft, Apple, etc. all use EE2E for sending patches to machines.  That is all an inherit trust, or risk depending how you look at it.

Hey Ross,

Right, then this is where is gets interesting. I should caveat, I am biased as what I am about to explain is our approach we deliver at the company I work. We have open sourced the tech though so you don't have to 'buy it'.

In my opinion, we should not inherently trust the device or the server making E2EE connections. I believe anyone implementing ZT would say the same. Proper AV, scanners, patching etc. allows us increase device security, BUT we need to ensure that the E2EE is checking for these requirements are met. This can be done through an overlay network which implements E2EE (and more) combined with 'posture checks'. As the ZTN overlay utilises authenticate-before-connect, we can ensure that before E2EE connections are established between client and host, the device has rigorous security in place. 

If this is not good enough for you, then stop thinking about zero trust networking as something that must stop at the network or host. Take it to its logical conclusion and embed it into your applications. This embeds ZTN, E2EE, mTLS (and more) directly into the app running in memory. The application has no listening ports on the underlay network. It's literally unattackable via conventional IP-based tooling. Seriously, stop and consider that for just a moment. By embedding ZTN, all conventional network threats are immediately useless. Lets play that out with the scenario. With app embedded zero trust, if your device is infected with malware, the malware cannot laterally move across the ZTN as the ZTN is not accessible from the host OS network. The malware would have to break into the application (not impossible but WAY harder). Even if the malware got inside the app, it cannot laterally move in the same way as this is not an OP network, they can only making application calls which are built into the application.

You may then say, ahh, but Philip, I have some web apps which are only accessible via the browser, they do not have thick client apps which can embed a ZTN SDK and run on client side. No problem, we built a 'clientless' zero trust endpoint which can be embedded into your client browser with the user only authenticating to the chosen IdP. This provides a 'public SaaS' type experience while bringing E2EE, mTLS, posture checks and more into your single browser tab, with no inherent trust in the host OS or host OS network, while the application actually sits in a private network with no inbound ports and unaddressable on the internet.

Thus we shouldn't inherently trust E2EE. Organisations and ISVs should utilise a mixture of techniques, incl. ZTN to reduce any inherent trust in client/server hosts as well as all underlay networks (WAN, LAN, host os). I liken this to providing our apps with an 'invisibility cloak' and 'port key' by borrowing Harry Potter analogies in this blog I wrote - https://netfoundry.io/demystifying-the-magic-of-zero-trust-with-my-daughter-and-opensource/. TL:DR, the app is invisible to silly muggles (malicious actors) so that they cannot find and attack it while packets magically flow from source to destination without needing to configure the networks in between.

Curious to have your thoughts on that approach...

P.S., if you want to learn more on the FOSS ZTN, here is our Github - https://github.com/openziti. For the 'clientless' endpoint - https://blog.openziti.io/introducing-openziti-browzer.

Hi Philip, Cert pinning and E2EE are one and the same, so apologize there. So you are correct in your post throughout.  Curious what you are thinking 🤔.

Hey Ross,

Personally, I think strong E2EE based on certificates/crypto is a fundamental premise of treating the network as compromised and hostile.I think, correct me if I am wrong, you are suggesting doing decryption on all packets to ensure no vulnerability is getting through. While zero trust has many varied interpretations, one point it is explicit on is that there is no single perimeter for us to decrypt packets and the development of protocols such as TLS1.3 make decryption super hard anyway. 

Is my interpretation of you comment correct? If it is, the question becomes (I think), how can we ensure system security and zero trust while using E2EE between source and destination... would you agree???

Regards

Philip

I figured I would post this here, although I apologize as this might not be the right place.  As we are all familiar with Zero Trust (ZT) and ZTA what and how does everyone feel about SSL encryption when it comes to certificate pinning?  NIST 800-53 also calls this out under AC-4(4) and SI -4(10).  At a technical level most if not all major vendors be that Microsoft or not, have fully enabled certificate pinning to ensure that no MITM attacks can occur.  The data between you and them is encrypted and only decrypted or terminated on the host making the request.  From a perimeter perspective, no firewall can decrypt this traffic because if one was to try the pinning would fail.  The only solution is to ensure the host making the request has the proper AV or malware scanners, the system is patched, etc.  This screams supply-chain-attack because when you look at Solar Winds and others, validating the certificate would be useless as the bad actor changed the code to the application.  However, I do understand with Solarwinds, that even end-point controls would not be effective unless you whitelist outbound requests at the perimeter or from the local host.  Curious what others' thoughts are? To fully trust Microsoft or any vendor today seems like a bad idea, regardless of what the agreement is between the parties, as it will only cost money to seek a legal path to gain back lost revenue or funds.  Maybe someone created a new mouse trap for this and I am not aware, but very excited to see what people bring up about this.

I dont disagree with what you are saying. I think about other industries though, if my car company pushed a SOTA update which caused a car crash, they are liable. Thus they have a focus on safety and not pushing compromised updates - for example, Uptane was developed explicitly with this in mind https://uptane.org/. 

When I look at the SW industry, I think the biggest problem is not good vs bad MiTM, its that SW vendors have no liability for insecure software. My opinion is that we should solve the root cause, not the symptom.

Hi Philip, What you state "E2EE is inherent trust and a risk" is exactly what I want to focus on, but I agree with "not updating and patching would be a bigger risk".  I do not want to get into ranking this from a risk perspective but rather the guidance from NIST, ZT, and ZTA.  And while I could demand or ask Apple, Microsoft, etc. as can others, we all sign off on a document when we use their OS after installation.  So my question goes back to, how is someone compliant with the ask from these frameworks when it appears that it is not possible with E2EE in play?  You have to "trust" that these vendors are going to protect their customers and we saw what happened with Solarwinds and the trust, even at the federal level.  One could take a page from that and implicitly deny all outbound traffic with only approved destinations after vetting, however, that would be a disaster for a business and government.  Maybe there is no answer here for what I am after, and that is okay.  However, it just shows that a gap exists and an opening for technology to improve to allow customers to trust but verify before use.  There can be good MiTM and bad MiTM.

Hey Ross,

There are similarities in some functionality between Zscaler Private Access and Ziti. A quick comparison shows Ziti being able to:

• support any use case incl. server-initiated, dynamic ports, and exotic protocols
• having a much richer amount of endpoints, incl. embed in apps, serverless, clientless, constrained edge/IoT (e.g., OpenWRT)
• Ziti has its own PKI/CA with ability to use external IdP , with explicitly authenticate-before-connect and mTLS everywhere while being able to change the ciphers if you wish
• deployable/hosted anywhere including into airgapped networks
• fully programmable, API/IaC driven (if you wish)

You are correct that giving 3rd parties the ability to update and patch their products using E2EE is inherent trust and a risk. I would argue not updating and patching would be a bigger risk. That said, we can allow 3rd parties to update/patch their infra while using ZT principles to reduce the inherent trust and risk. We should be demanding companies like Microsoft, Apple, etc, to utilise application-embedded zero trust overlays. This reduces the risk of malware and malicious injection through the supply-chain. If this is still too much of a risk, as a consumer you could demand that Microsoft, Apple et al send their traffic through an inspection point which you own, which has E2EE at ingress and egress of the inspection point. 

Regards

Philip

Thank you for all that information.  What you describe and what is in the link for Ziti is very close if not the same as something like Zscaler and others offer, but more of an all in one package.obviously Zscaler and others are in the business to make money so each component comes at a cost.  I guess my question or statement is that with EE2E that originates outside your network, be that an overlay or not, those end point that start the communication with that external party, need to be secured more than ever.  Unless I am missing how that traffic is filtered before reaching the end user?  If that is true, and I've been wrong many times, if this is in a container environment, this can be a disaster.  For example some container or laptop calls out to some vendor and that vendor uses EE2E with the communication.  The only visibility that's available is on the endpoint reaching out as it has the decryption abilities.   Microsoft, Apple, etc. all use EE2E for sending patches to machines.  That is all an inherit trust, or risk depending how you look at it.

Hey Ross,

Right, then this is where is gets interesting. I should caveat, I am biased as what I am about to explain is our approach we deliver at the company I work. We have open sourced the tech though so you don't have to 'buy it'.

In my opinion, we should not inherently trust the device or the server making E2EE connections. I believe anyone implementing ZT would say the same. Proper AV, scanners, patching etc. allows us increase device security, BUT we need to ensure that the E2EE is checking for these requirements are met. This can be done through an overlay network which implements E2EE (and more) combined with 'posture checks'. As the ZTN overlay utilises authenticate-before-connect, we can ensure that before E2EE connections are established between client and host, the device has rigorous security in place. 

If this is not good enough for you, then stop thinking about zero trust networking as something that must stop at the network or host. Take it to its logical conclusion and embed it into your applications. This embeds ZTN, E2EE, mTLS (and more) directly into the app running in memory. The application has no listening ports on the underlay network. It's literally unattackable via conventional IP-based tooling. Seriously, stop and consider that for just a moment. By embedding ZTN, all conventional network threats are immediately useless. Lets play that out with the scenario. With app embedded zero trust, if your device is infected with malware, the malware cannot laterally move across the ZTN as the ZTN is not accessible from the host OS network. The malware would have to break into the application (not impossible but WAY harder). Even if the malware got inside the app, it cannot laterally move in the same way as this is not an OP network, they can only making application calls which are built into the application.

You may then say, ahh, but Philip, I have some web apps which are only accessible via the browser, they do not have thick client apps which can embed a ZTN SDK and run on client side. No problem, we built a 'clientless' zero trust endpoint which can be embedded into your client browser with the user only authenticating to the chosen IdP. This provides a 'public SaaS' type experience while bringing E2EE, mTLS, posture checks and more into your single browser tab, with no inherent trust in the host OS or host OS network, while the application actually sits in a private network with no inbound ports and unaddressable on the internet.

Thus we shouldn't inherently trust E2EE. Organisations and ISVs should utilise a mixture of techniques, incl. ZTN to reduce any inherent trust in client/server hosts as well as all underlay networks (WAN, LAN, host os). I liken this to providing our apps with an 'invisibility cloak' and 'port key' by borrowing Harry Potter analogies in this blog I wrote - https://netfoundry.io/demystifying-the-magic-of-zero-trust-with-my-daughter-and-opensource/. TL:DR, the app is invisible to silly muggles (malicious actors) so that they cannot find and attack it while packets magically flow from source to destination without needing to configure the networks in between.

Curious to have your thoughts on that approach...

P.S., if you want to learn more on the FOSS ZTN, here is our Github - https://github.com/openziti. For the 'clientless' endpoint - https://blog.openziti.io/introducing-openziti-browzer.

Hi Philip, Cert pinning and E2EE are one and the same, so apologize there. So you are correct in your post throughout.  Curious what you are thinking 🤔.

Hey Ross,

Personally, I think strong E2EE based on certificates/crypto is a fundamental premise of treating the network as compromised and hostile.I think, correct me if I am wrong, you are suggesting doing decryption on all packets to ensure no vulnerability is getting through. While zero trust has many varied interpretations, one point it is explicit on is that there is no single perimeter for us to decrypt packets and the development of protocols such as TLS1.3 make decryption super hard anyway. 

Is my interpretation of you comment correct? If it is, the question becomes (I think), how can we ensure system security and zero trust while using E2EE between source and destination... would you agree???

Regards

Philip

I figured I would post this here, although I apologize as this might not be the right place.  As we are all familiar with Zero Trust (ZT) and ZTA what and how does everyone feel about SSL encryption when it comes to certificate pinning?  NIST 800-53 also calls this out under AC-4(4) and SI -4(10).  At a technical level most if not all major vendors be that Microsoft or not, have fully enabled certificate pinning to ensure that no MITM attacks can occur.  The data between you and them is encrypted and only decrypted or terminated on the host making the request.  From a perimeter perspective, no firewall can decrypt this traffic because if one was to try the pinning would fail.  The only solution is to ensure the host making the request has the proper AV or malware scanners, the system is patched, etc.  This screams supply-chain-attack because when you look at Solar Winds and others, validating the certificate would be useless as the bad actor changed the code to the application.  However, I do understand with Solarwinds, that even end-point controls would not be effective unless you whitelist outbound requests at the perimeter or from the local host.  Curious what others' thoughts are? To fully trust Microsoft or any vendor today seems like a bad idea, regardless of what the agreement is between the parties, as it will only cost money to seek a legal path to gain back lost revenue or funds.  Maybe someone created a new mouse trap for this and I am not aware, but very excited to see what people bring up about this.

I figured I would post this here, although I apologize as this might not be the right place.  As we are all familiar with Zero Trust (ZT) and ZTA what and how does everyone feel about SSL encryption when it comes to certificate pinning?  NIST 800-53 also calls this out under AC-4(4) and SI -4(10).  At a technical level most if not all major vendors be that Microsoft or not, have fully enabled certificate pinning to ensure that no MITM attacks can occur.  The data between you and them is encrypted and only decrypted or terminated on the host making the request.  From a perimeter perspective, no firewall can decrypt this traffic because if one was to try the pinning would fail.  The only solution is to ensure the host making the request has the proper AV or malware scanners, the system is patched, etc.  This screams supply-chain-attack because when you look at Solar Winds and others, validating the certificate would be useless as the bad actor changed the code to the application.  However, I do understand with Solarwinds, that even end-point controls would not be effective unless you whitelist outbound requests at the perimeter or from the local host.  Curious what others' thoughts are? To fully trust Microsoft or any vendor today seems like a bad idea, regardless of what the agreement is between the parties, as it will only cost money to seek a legal path to gain back lost revenue or funds.  Maybe someone created a new mouse trap for this and I am not aware, but very excited to see what people bring up about this.

Hi Ross,

Most ZTNA vendors implement protocol downgrades for enterprise networks. This works despite certificate pinning and TLS 1.3, when clients have installed and trust the corporate certificate that has been pushed. This is just about the same as what happens on non-ZTNA, old-approach "castle and moat" networks with proxies.

The additional benefit of ZTNA is that we can enforce a client check, so that a client that does not load and trust this certificate, is not allowed in the main intranet but quarantined – a bit like it used to happen on 802.1x networks, but this is done at higher (and much more reliable) network levels (applications at OSI Layer-2 have always been problematic, e.g., macOS breaks your implementation at every minor version…). Furthermore, thanks to ZTNA, this is implemented in the Cloud, and does not require expensive equipment to be procured. However, encryption downgrade works technically in the same way (and it is not really a problem; I think, even old-fashioned technologies like McAfee proxies do that for a decade).

I hope this helps.

I figured I would post this here, although I apologize as this might not be the right place.  As we are all familiar with Zero Trust (ZT) and ZTA what and how does everyone feel about SSL encryption when it comes to certificate pinning?  NIST 800-53 also calls this out under AC-4(4) and SI -4(10).  At a technical level most if not all major vendors be that Microsoft or not, have fully enabled certificate pinning to ensure that no MITM attacks can occur.  The data between you and them is encrypted and only decrypted or terminated on the host making the request.  From a perimeter perspective, no firewall can decrypt this traffic because if one was to try the pinning would fail.  The only solution is to ensure the host making the request has the proper AV or malware scanners, the system is patched, etc.  This screams supply-chain-attack because when you look at Solar Winds and others, validating the certificate would be useless as the bad actor changed the code to the application.  However, I do understand with Solarwinds, that even end-point controls would not be effective unless you whitelist outbound requests at the perimeter or from the local host.  Curious what others' thoughts are? To fully trust Microsoft or any vendor today seems like a bad idea, regardless of what the agreement is between the parties, as it will only cost money to seek a legal path to gain back lost revenue or funds.  Maybe someone created a new mouse trap for this and I am not aware, but very excited to see what people bring up about this.