[zemnmez]

this approach tends to be a self-own. Bug bounty and responsible disclosure folks don’t usually have expertise in it, so you’re just making the real attack surface less visible until someone with the expertise comes a long and owns you deeper than you could have imagined. This, ironically was also the case for steam: https://steamdb.info/blog/breaking-steam-client-cryptography... (I helped make this bug)

There is a misconception that the responsible disclosure system reflects real security threats, but it unfortunately doesn’t. The areas of expertise in the real world are different, and sticking a bunch of crypto in like that tends to be a case of making your eventual problems more complex, bigger, and harder to find.

[TimTheTinker]

True, but for those reading: this is a knock on roll-your-own crypto, not on application-level crypto or the defense-in-depth benefits it can provide.

[saagarjha]

SSL pinning and other MITM obfuscations are frequently not very useful from a security perspective.

[zemnmez]

This is a knock on application-level crypto.

[TimTheTinker]

I humbly disagree - there are times when application-level crypto makes sense. E2EE in particular relies on application-level crypto, and any password manager or "secret server" that relies only on TLS is highly suspect, in my opinion.

I attended a talk at QCon SF 2019 where the speaker advocated use of application-level encryption (even in web apps) by default as a form of defense-in-depth. I was skeptical, especially since client code itself has to be delivered using TLS only (and thus a successful TLS attack renders further defenses worthless).

But it does seem that application-level crypto allows a lot of networked devices (besides the application servers themselves) to be rendered zero-knowledge concerning most application and user data. This allows us to trust those devices less.

[zemnmez]

I never made the argument that no application should ever encrypt anything at the application level. Password managers are very niche uses.

"secret servers" or key-management systems are just fine using TLS imo. I helped draw up the design for what is now the aws secrets manager. At the point you're reasoning about TLS being broken you might as well be focusing on detection, monitoring and key rotation because the whole internet is coming down with you.

> I attended a talk at QCon SF 2019 where the speaker advocated use of application-level encryption (even in web apps) by default as a form of defense-in-depth. I was skeptical, especially since client code itself has to be delivered using TLS only (and thus a successful TLS attack renders further defenses worthless).

defense-in-depth is a weasel word. security isnt a bunch of layers that can be reinforced as such; often things that are referred to as 'defense-in-depth' cover specific characteristics of one protocol over another.

For example, in password managers as you mention you end up with application level encryption. But this is because TLS doesn't provide the guarantees they want of server blindness, and some resistance to bad TLS certs installed at the OS level (a dubious security boundary, but regardless...).

> But it does seem that application-level crypto allows a lot of networked devices (besides the application servers themselves) to be rendered zero-knowledge concerning most application and user data. This allows us to trust those devices less.

This may well be true in niche cases. In reality, there's not a lot of businesses out there who will overengineer their systems to know less about their users. zero-knowledge applications are unbelievably subtle to make really work, and it's very easy to fool even experts in adjacent security fields that an application is zero-knowledge in some respect when it isn't.

I'm digressing. Application-level encryption in 2021 is very rarely what's wanted, and the existence of niche security cases in entirely security-focussed products doesn't discount that.

[TimTheTinker]

Great points and discussion, thanks.

One thing I still want to say — when I speak of secret servers that only use TLS, I was thinking primarily of products like Thycotic Secret Server, where deployment is left to on-prem IT staff, no E2EE exists at all, authorization uses code branching not security primitives, and where “vaults” are databases with DBMS-implemented encryption at rest. Security-wise, a hand rolled solution actually could be better if written by an experienced non-security engineer.

I’m not familiar with AWS secret server, but I assume it’s deployed such that it inherits a lot of guarantees by virtue of being part of the AWS ecosystem.