ignores invalid ssl certs with CERT_NONE, allowing MITM

[joeyh]

Electrum falls back to using CERT_NONE when making an initial connection to a server, if the CERT_REQUIRED connection fails.

In get_socket, the abridged code is:

s = ssl.wrap_socket(s, ssl_version=ssl.PROTOCOL_SSLv23, cert_reqs=ssl.CERT_REQUIRED, ca_certs=ca_path, do_handshake_on_connect=True)

if s and self.check_host_name(s.getpeercert(), self.host):
    return s

s = ssl.wrap_socket(s, ssl_version=ssl.PROTOCOL_SSLv23, cert_reqs=ssl.CERT_NONE, ca_certs=None)

This seems to leave electrum open to MITM attacks.

Since electrum caches certs on first use, the MITM potential is probably limited to the initial uses of electrum, or when a new server is added to the list.

[ecdsa]

Electrum allows both self-signed and CA signed certificates.

Self-signed certificates are saved on first use, and used for later validation. It is indeed possible to MITM a server on the first with this model, but that is the best we can do without CA validation.

CA signed certificates are a newer feature in Electrum. I understand your comment as follows: it would be possible to MITM a CA signed server, by creating a self-signed certificate with the same name. That certificate would be saved and used later. I guess we can mitigate that by saving the names of already encountered CA signed servers.

[ecdsa]

Electrum allows both self-signed and CA signed certificates.

Self-signed certificates are saved on first use, and used for later validation. It is indeed possible to MITM a server on the first with this model, but that is the best we can do without CA validation.

CA signed certificates are a newer feature in Electrum. I understand your comment as follows: it would be possible to MITM a CA signed server, by creating a self-signed certificate with the same name. That certificate would be saved and used later. I guess we can mitigate that by saving the names of already encountered CA signed servers.

[joeyh]

ThomasV wrote:

CA signed certificates are a newer feature in Electrum. I understand your
comment as folows: it would be possible to MITM a CA signed server, by creating
a self-signed certificate with the same name. That certificate would be saved
and used later.

Correct. (But see my other bug about certificate handling too; it's
worse than this.)

The right way to handle self-signed certificates is probably to get the
user to verify the certificate, and then trust it thereafter. If
that's even worth doing given how easy it is to get a LetsEncrtypt cert.

see shy jo

[joeyh]

ThomasV wrote:

CA signed certificates are a newer feature in Electrum. I understand your
comment as folows: it would be possible to MITM a CA signed server, by creating
a self-signed certificate with the same name. That certificate would be saved
and used later.

Correct. (But see my other bug about certificate handling too; it's
worse than this.)

The right way to handle self-signed certificates is probably to get the
user to verify the certificate, and then trust it thereafter. If
that's even worth doing given how easy it is to get a LetsEncrtypt cert.

see shy jo

[bauerj]

Maybe we should make server operators switch to CA-signed certificates by a future Electrum version. Any thoughts on that?

[bauerj]

Maybe we should make server operators switch to CA-signed certificates by a future Electrum version. Any thoughts on that?

[ecdsa]

@bauerj I believe this issue is being fixed by @ysangkok in the asyncio branch

[ecdsa]

@bauerj I believe this issue is being fixed by @ysangkok in the asyncio branch

[bauerj]

If that's the case, we should inform server operators to switch to CA-signed certs ASAP.

[bauerj]

If that's the case, we should inform server operators to switch to CA-signed certs ASAP.

[ecdsa]

@bauerj that does not make sense. the issue discussed here is that it is possible to create a self-signed cert for the same name as a CA signed cert, and that certificate would be pinned. There is no need to switch to mandatory CA signed certificates to mitigate that. We just need to store the names of servers that have a CA signed cert, so that they do not get later replaced by a pinned certificate

[ecdsa]

@bauerj that does not make sense. the issue discussed here is that it is possible to create a self-signed cert for the same name as a CA signed cert, and that certificate would be pinned. There is no need to switch to mandatory CA signed certificates to mitigate that. We just need to store the names of servers that have a CA signed cert, so that they do not get later replaced by a pinned certificate

[bauerj]

Yes, that's true. However, switching to mandatory CA-signed certificates would not only solve the issue you outlined but also the potential MITM attack when first connecting to a server.

[bauerj]

Yes, that's true. However, switching to mandatory CA-signed certificates would not only solve the issue you outlined but also the potential MITM attack when first connecting to a server.