I wonder if it is a good idea to use only HTTPS providers?
I can't comment much on specific security risks of using non-TLS providers for this purpose (querying external IP), other than the general well-known risks of plaintext communications.
I think the consensus system used in go-external-ip can greatly mitigate MITM attacks, and maybe prevent them completely if at least one provider is using TLS (especially the way go-external-ip is designed to give more weight to TLS providers).
However, on the other hand, is there any real reason to use non-TLS providers when we can change to only HTTPS providers? Is it faster to use HTTP-only providers? (I have not tested, can't see it being that big a difference, especially if we are waiting for multiple providers to get consensus anyway).
All current HTTP-only providers now support HTTPS except:
Problem statement
I wonder if it is a good idea to use only HTTPS providers? I can't comment much on specific security risks of using non-TLS providers for this purpose (querying external IP), other than the general well-known risks of plaintext communications. I think the consensus system used in go-external-ip can greatly mitigate MITM attacks, and maybe prevent them completely if at least one provider is using TLS (especially the way go-external-ip is designed to give more weight to TLS providers).
However, on the other hand, is there any real reason to use non-TLS providers when we can change to only HTTPS providers? Is it faster to use HTTP-only providers? (I have not tested, can't see it being that big a difference, especially if we are waiting for multiple providers to get consensus anyway).
All current HTTP-only providers now support HTTPS except:
{"message":"Not Found"}
on HTTPS)To make up for removing Akamai, there are others that could be added such as:
(all of these URLs return plain text when requested from non-browser useragent)
Steps to reproduce
N/A
Environment
N/A