> Session cookies serve the same purpose in web apps as access tokens for APIs
> but there are much more web apps than APIs. I use the analogy to illustrate
> that either there are security issues with cloud deployments of web apps or
> the techniques used to secure web apps are ok for APIs as well.
"Security issues" is a loaded term, but if you mean that there are practical
risks that are not addressed by bearer tokens (whether they be session cookies
or access tokens) then yes, I think we both agree that there are. Otherwise we
wouldn't be discussing PoP, sender-constrained tokens, etc. TLS-based solutions
mitigate some risks, while leaving others unmitigated. Depending on your use
case and threat model, these risks may or may not present practical threats.
For my use cases, they do.
Ultimately I'd like to mitigate these risks for both service APIs and web
applications. My focus is on service APIs for a couple reasons:
1. Interoperability is more important when the sender and recipient aren't
necessarily owned by a single entity. I can do proprietary things in JavaScript
if I want to just as I can in client SDKs, but this breaks down if my API
implements a standard protocol and is expected to work with off-the-shelf
clients and/or implementations from other vendors.
2. Web applications are just a special subset of service APIs that happens to
be accessed via a browser. A solution for service APIs ought to be reusable for
web applications, or at least serve as a foundation for their solution.
>- Have you seen this kind of proxies intercepting the connection from
> on-prem service deployments to service provider? I’m asking because I thought
> the main use case was to intercept employees PC internet traffic.
I'm working from second-hand knowledge here, but like most things in the
enterprise world, it depends. Separating employee device outbound traffic from
internal service outbound traffic requires some level of sophistication, be it
in network topology, routing rules, or configuration rules on the TLIS
appliance.
>- Are you saying this kind of proxy does not support mutual TLS at all?
From what I understand, at the very least mTLS is not universally supported.
There may be some vendors that support it, but it's not guaranteed. The
documentation for Symantec's SSL Visibility product [1] indicates that sessions
using client certificates will be rejected unless they are exempted based on
destination whitelisting (which is problematic when the destination may be a
general-purpose cloud service provider).
> On the other hand, I would expect these kind of proxy to understand a lot
> about the protocols running through it, otherwise they cannot fulfil their
> task of inspecting this traffic.
Maybe, maybe not. In any case there's a difference between understanding HTTP
or SMTP or P2P-protocol-du-jour and understanding the application-level
protocol running on top of HTTP. There hasn't been any need for these proxies
to understand OAuth 2.0 thus far.
[1]:
https://origin-symwisedownload.symantec.com/resources/webguides/sslv/45/Content/Topics/troubleshooting/Support_for_Client_Cert.htm
–
Annabelle Richard Backman
AWS Identity
On 12/1/19, 7:41 AM, "Torsten Lodderstedt"
wrote:
Annabelle,
> Am 27.11.2019 um 02:46 schrieb Richard Backman, Annabelle
:
>
> Torsten,
>
> I'm not tracking how cookies are relevant to the discussion.
I’m still trying to understand why you and others argue mTLS cannot be used
in public cloud deployments (and thus focus on application level PoP).
Session cookies serve the same purpose in web apps as access tokens for
APIs but there are much more web apps than APIs. I use the analogy to
illustrate that either there are security issues with cloud deployments of web
apps or the techniques used to secure web apps are ok for APIs as well.
Here are the two main arguments and my conclusions/questions:
1) mTLS it’s not end 2 end: although that’s true from a connection
perspective, there are solutions employed to secure the last hop(s) between TLS
terminating proxy and service (private net, VPN, TLS). That works and is
considered secure enough for (session) cookies, it should be the same for
access tokens.
2) TLS terminating proxies do not forward cert data: if the service itself
terminates TLS this is feasible, we do it for our public-cloud-hosted
mTLS-protected APIs. If TLS termination is provided by a component run by the
cloud provider, the question is: is this component able to forward the client
certificate to the service? If not, web apps using certs for authentication
cannot be supported straightway by the cloud provider. Any insights?
> I'm guessing that's because we're not on the same page regarding use
cases, so allow me to clearly state mine:
I think we are, we are just focusing on different ends of the TLS tunnel.
