Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question. Does rustls have something to hide cert (as it is sensitive data ) in binary and memory #1917

Closed
incker opened this issue Apr 23, 2024 · 3 comments

Comments

@incker
Copy link

incker commented Apr 23, 2024

Hello!

It is not more a feature request, but a question.

I have to hide a certificat in binary/memory so it will be maximum problematic to replace it in binary.
Maybe you have some implementations/solutions with libsodium

Thank you for your answer!

@cpu
Copy link
Member

cpu commented Apr 23, 2024

Hi @incker,

I'm afraid your question is not very clear to me. Are you talking about a server or a client? The server certificate or a client certificate? Are you sure you don't want to protect a private key and not the certificate? A certificate is normally public data and not at all sensitive. What is your threat model?

@incker
Copy link
Author

incker commented Apr 23, 2024

Ok. The case is, I have a url and a client certificate for this url. But it is possible that someone can change in client binary url and client certificate. And make requests to own server..
Unfortunately, it is not possible to solve my case in another way (for example move calculation to server)
I know that can not hide everything on client with 100% grantee. But at least i want to make it harder, to receive data from memory/binary
And to make it hard to replace data in binary

@cpu
Copy link
Member

cpu commented Apr 23, 2024

Hi there,

In that case what I think what you're looking for is outside of the scope of what rustls can provide, or what we can assist with. You're entering into the space of DRM and anti-reverse-engineering where the threat model considers the user holding the client certificate private key (embedded/distributed with your software) as adversarial. That's not a common model and in almost every case I think you're better off redesigning your system to avoid it. If you truly can't, you could try asking your question in a general support form for cryptography/security. Good luck!

@cpu cpu closed this as not planned Won't fix, can't repro, duplicate, stale Apr 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants