18

I am trying to understand the security problems when working with a game that needs an account for its players.

What is the problem of using a self-signed certificate?

If I understand the problem correctly, it's just that if the server private key is compromised, the users will still trust the certificate and the guy that stole the key could steal their passwords. (Until the game updates with the new certificate.)

But is that the only problem? And if it is, is it really possible for an attacker to steal the private key from a server with intensive firewalls (just open as few ports as possible?).

Here is what I have in mind for my game when a client wants to authenticate:

  • The client encrypts it's username and password with RSA using the public key of the self signed-certificate.
  • The client sends this encrypted message to the server.
  • (So here technically only the master server could read the messages, except if the self-signed certificate is compromised)
  • The server reads the message using it's private key from the self-signed certificate
  • Then here the server do classic things, checks in the database if the username exists then hashes the password with something like bcrypt and checks if the password is correct, then he set the client in the authenticated state and now have access to other features like joining game servers, accessing the servers list etc...

And basically I need to make the clients trust the public key! Because if the master server send it's public key to the client then a man in the middle could take it, generate itself a public/private key and send it's public key. So now the client could think he talks to the server but instead he talks to the man in the middle. Am I thinking wrong?

NaolShow
  • 191
  • 1
  • 6
  • 15
    I don't understand ... Your game is an executable, or a browser game? The certificate you're talking about is a code signing certificate or a HTTP certificate? Why does the user need to trust anything, don't the computers trust each other? – Thomas Weller Jul 22 '21 at 06:15
  • 4
    Can you provide some more context? E.g., what is the self-signed certificate going to be used for, specifically? Is it for [TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security)? Or something else? Some extra [tags](https://security.stackexchange.com/tags) may also be able to narrow it down. Please respond by [editing (changing) your question](https://security.stackexchange.com/posts/252554/edit), not here in comments (***without*** "Edit:", "Update:", or similar - the question should appear as if it was written today). – Peter Mortensen Jul 22 '21 at 15:14
  • Why are you trying to reinvent the wheel? Manually encrypting and decrypting something... why? HTTPS is a well understood, universally supported technology. Both on your server and your client, there will be standard libraries that can do it, and it will take all the worries of security off your shoulders. They have thought about various hacking scenarios you haven't even dreamed off. And you can get a free, trusted certificate from [Let's Encrypt](https://letsencrypt.org/) without any of the problems that come with self-signed certificates. This is easier AND safer. – Vilx- Jul 24 '21 at 11:03

3 Answers3

49

You don't seem to understand the issue with self-signed certificates, so allow me to explain.

Generally, when people say "Don't use self-signed certificates!", they mean in the context of a web-server, in which you expect the general public to connect via a web browser. In such a situation, if a self-signed certificate is used, this will lead to an error message:

Self-Signed Certificate Warning

Users will naturally want to ignore the warning and proceed - after all, that's the only way for them to use your website. So if an attacker intercepts the connection and presents his own self-signed certificate, the user would not be able to see that. After all, the error message is seen as a natural part of the process.

Self-Signed Certificates in other settings

Companies usually have a self-signed certificate as a root-certificate for internal services. This certificate is distributed internally (usually via Active Directory) and thus trusted by all clients.

This is a normal setup and works as intended. If an attacker would attempt to intercept the connection, an error would occur, as his certificate would not be trusted.

Self-Signed Certificates for your game

I assume that you have a server, which manages the game state, and a game client (likely a native client). In this situation, there is nothing wrong with using a self-signed certificate. Simply distribute the certificate with the client and keep the private key on the server.

Can the attacker just steal the private key?

Only if your server has a vulnerability, which would allow the attacker to do so. But that risk would also exist with a certificate signed by an external certificate authority.

nobody
  • 11,251
  • 1
  • 41
  • 60
  • I'm commenting on your misleading and incorrect answer not answering the question. @Steffen Ullrich already gave an answer. If you want to generalize, it would be more correct to say all the root CA's are selfsigned. – nethero Jul 21 '21 at 13:51
  • 25
    @nethero Please explain why exactly it is incorrect or misleading. –  Jul 21 '21 at 13:52
  • It is based on assumptions and generalizing. The generalizing part is done in a very bad direction and is completely unnecessary. This is why I think it is misleading. Only the last bit is answering the actual question and the screenshot part is irrelevant. – nethero Jul 21 '21 at 13:59
  • 27
    @nethero Both answers are correct, and present a different point of view to the question. Both are incomplete, because the question is imprecise, and only a full course on the subject could answer it fully. However, they answer to the most common cases. If the OP wants more details on a specific point, he can still comment or ask another question. Some amount of generalization is unavoidable while vulgarizing a topic. – A. Hersean Jul 21 '21 at 14:01
  • 2
    @nethero "Mutual authentication in TLS, API's, email encryption. Any scenario where non-repudiation is a requirement renders self-signed certificate useless. It is not limited to the webservers." When using pinned erts for APIs, for example, it doesn't really matter who signed the cert. For mTLS, a self-signed cert definitely works on the server. Using one for the client might be a little tricky but I think it's possible, depending on your stack, perhaps. – JimmyJames Jul 22 '21 at 18:52
21

What is the problem of using a self-signed certificate?

Scalability of trust. With a self-signed certificate every client must explicitly trust the servers certificate and whenever the certificate changes the clients must be updated. With a publicly signed certificate the trust in the certificate is derived from the pre-existing trust into the issuing certificate authority (i.e. the root CA).

But, if the client is just an app and the certificate can be directly included in the app, then all of this is not that much of a problem. Normal (secure) update processes for the app can be used for updating the trusted server certificate(s) too. It is not as smooth though as with a trusted root CA since there might always be some client which are not updated and which thus have not the latest certificate(s). But if an always up-to-date client is a requirement for a different reason then this problem is implicitly dealt with too.

In all other means except the trust a self-signed certificate can be as strong as a publicly issued certificate. This includes the cryptographic properties, like key and signature algorithms and sizes.

... it is, is it really possible for an attacker to steal the private key from a server with intensive firewalls (just open less ports as possible?)

If the only security measure is relying on a firewall then the security is probably not that high and stealing a private key might be possible. There is much more to securing an application than putting a firewall in front of it.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Can you expand your reply by talking about the common issues of self-signed certificates which are things like weak generation algorithms, use of common modulus, etc. I feel like this would make this answer even more complete. – nethero Jul 21 '21 at 13:16
  • 26
    @nethero: There are no such issues. The only difference between a self-signed certificate and a publicly issued certificate is the issuer. Self-signed certificates can use the same algorithms as publicly issued certificates. – Steffen Ullrich Jul 21 '21 at 13:17
  • There is such a problem, you can use correct crypto, but the research shows that even in the case of many publicly signed server certificates this is a common problem. I'm not a researcher, but I had my fair share of the self-signed certs to ebserve this. – nethero Jul 21 '21 at 13:21
  • 27
    @nethero: As I said, there is no such problem __inherent__ to self-signed certificates. And if you refer to *"research shows"* then please point to the relevant research. Also, current TLS libraries typically don't even accept too weak cryptography any longer. – Steffen Ullrich Jul 21 '21 at 13:22
  • 1
    I do understand your point of it not being inherent problem. I feel like talking about weak crypto is important. I'm looking for the paper as we speak, it was mentioned in one of the episodes of "Security Now", I'll query the transcripts. – nethero Jul 21 '21 at 13:48
  • 3
    @nethero It's common for the process of generating a key-pair to be identical for both self-signed and publicly signed certificates. The only difference being an additional step to create a CSR. That process provides an opportunity for governance which could explain what you are claiming here. One thing that is a source of confusion though is that weak signature algorithms e.g. SHA-1 for self-signed certs (including roots) isn't really an issue because trust is not based on the signature. – JimmyJames Jul 22 '21 at 19:02
0

If you commit to self-signed and/or pinned TLS certificates, you lose out on two potential benefits of using CA-signed certificates:

1. Handling networks that man-in-the-middle TLS connections

Some users connect to the Internet through computer networks that man-in-the-middle (MITM) TLS traffic for the purposes of traffic analysis. These users' computers trust a self-signed certificate created by the MITM software.

A group of researchers estimate that roughly 1 in 250 TLS connections are being MITMed by firewall software. Many schools and employers MITM the TLS traffic on their networks. If your client pins a specific server certificate, then students trying to play your game on their school networks might encounter TLS errors. Authoritarian governments frequently try to MITM the TLS traffic across their entire country. Notably, the Government of Kazakhstan tried and failed to MITM their TLS traffic.

If you want to favor availability, your clients should accept certificate trusted by the client's computer. On the other hand, you might want to intentionally make it difficult to MITM your game--either to protect players' privacy or as an anti-cheating mechanism.

2. Certificate Transparency logging

There are other security benefits to using a CA-signed certificate, like logging the certificate's creation to public Certificate Transparency logs. Certificate Transparency makes it harder for malicious actors to issue certificates that would be trusted by your clients without anybody else noticing.

James Mishra
  • 1,124
  • 6
  • 12