1

If I Google for inurl:http+keyserver, on the first 10 pages of hits I can find these:

And these are only the www based keyservers. Do they have zero clue about IT Security? HTTPS isn't a holy grail, but it is much better than plaintext! Correct setup of HTTPS requires that HTTP isn't enabled (at least a redir!) and a valid HTTPS cert...

Question: Why isn't its mandatory for the keyservers to be only available via HTTPS? Todays Let's Encrypt is free and requires no maintenance. Is there any good argument for not using a secure (encrypted and authentical) connection?

UPDATE: during a MiTM, the keys that are not sent via HTTPS can be altered, thus it doesn't matter that anybody can upload keys to keyservers, the whole thing is already lost! HTTPS would need to be mandatory! At least a better chance!

pepite
  • 215
  • 1
  • 2
  • 6
  • 1
    Instead of just complaining why they are not using https you should explain in your question why they should use https in your opinion. And there are actually reasons for not using HTTPS, see [Why do some websites enforce lack of SSL](http://security.stackexchange.com/questions/53250/why-do-some-websites-enforce-lack-of-ssl). – Steffen Ullrich Dec 08 '16 at 15:41
  • "public keys" are called ---> PUBLIC <--- keys for a reason ! – Little Code Dec 08 '16 at 22:34
  • Regarding your update, the point is it doesn't matter if the keys are altered. They won't be accepted by gpg as valid anyway unless they can be verified through the web of trust. And even if they are delivered through HTTPS, they _still_ need to be verified through the web of trust regardless. So whether or not HTTPS is used has no effect on an attacker's ability to make you accept a fake key. – Ajedi32 Dec 16 '16 at 16:27

2 Answers2

7

Need for HTTPS for PGP keys?

For PGP, we already have a PKI mechanism build in, called the web of trust, so we don't necessarily need HTTPS keyserver.

Even if the key servers did serve their keys over HTTPS, you couldn't be sure of the correctness of the keys, as anyone can submit arbitrary keys to the server. Serving the untrusted keys over HTTPS wouldn't make them trusted all of a sudden.

Need for HTTPS in general?

So there is no reason why PGP keys specifically should be served over HTTPS.

There are still valid arguments for HTTPS though, mainly privacy and integrity related. See for example Let's Encrypt Everything.

Why don't the keyservers force HTTPS?

Most of those pages either do not support HTTPS or do not have a valid certificate, so forcing all traffic over HTTPS would not be a good idea, as it would make them less accessable.

But why don't they support HTTPS? Probably because it is too much trouble for them to set up. Sure, Let's Encrypt provides free certificates, but somebody still has to set them up.

tim
  • 29,018
  • 7
  • 95
  • 119
  • I think the biggest attack vector I can think of for an active MITM is that they could prevent you from detecting when a key is revoked. – Ajedi32 Dec 16 '16 at 16:30
0

You have a fair argument, about HTTPS. Although, PGP make use of public-key cryptography. One key (a public key) you can distribute to your friends to encrypt and send encrypted data back to you. The other key (private key), only you have access.

That's one of the reasons why people have to generate a new key pair when they lose their private key.

When you send the key to the PGP public key servers and they are not called "public key servers" by chance. The only thing that an eavesdropper can do in possession of your public key is: encrypt data. But they can't decrypt or guess the private key.

That's why I believe that these servers don't bother about HTTPS. It's because the only information to be eavesdropped is public.

Community
  • 1
abstractj
  • 29
  • 1
  • 3
    I strongly disagree - by MITMing an http served public key, they can substitute it. If that substitute key for A is accepted as genuine by user B, the attacker E can then impersonate A to B. This is discoverable (if E ever stops MITMing B, B could potentially reverify that public key), but could cause significant issues – crovers Dec 08 '16 at 16:18
  • 4
    @crovers If you're just accepting random keys from a keyserver as genuine without performing any additional validation you've already lost. Anyone can upload an arbitrary key to a public key server, claiming to be anyone. Key servers do nothing to verify who any particular key belongs to. – Ajedi32 Dec 08 '16 at 17:01
  • 3
    @crovers The legitimate owner of that keyserver is/should be just as untrusted as any other possible MITM attacker. Even if HTTPS was enabled and you verified the certificate, you should still expect that all of those keyservers can and will serve you malicious data. The only validation that you can rely on must happen *after* you've downloaded the keys, and https transit doesn't change anything at all on how you should do that. Keyservers by definition are just providing a convenience, a service of distributing unverified unconfidential information, enabling https can't change that. – Peteris Dec 08 '16 at 17:22
  • @crovers "the attacker E can then impersonate A to B" - I think this is wrong, because you'd not only need to intercept between keyserver and B but also between A and B. But between A and B there is transport encryption which would trigger certificate alerts. So the only harm is A saying to B "I can't decrypt your message, please check my public key is correct". – Daniel W. Jun 11 '20 at 14:41