Thanks for the heads up. In principle it sounds like a good idea but there isn't a single bit of data that needs to be secure coming from the website. There are no logins, all data is readily available to anyone, and there are no accounts and all statistics are relatively anonymised being tied only with a bitcoin address. Intercepting to read the data which is readily available anyway, and spoofing that data to change something won't achieve anything at all that I can think of?
While data confidentiality may not be a primary concern here (given the public nature of the information that's available), there remain issues concerning server authentication and data integrity.
Regarding server authentication, without HTTPS, there can be no confidence that users visiting the ckpool.org website would be talking to the true ckpool.org web server. This opens the door for malicious third parties to redirect users to malicious web servers of their choice, which in turn may leave users open to malicious drive-by downloads, cryptojacking, zero-day browser exploits, etc.
Regarding data integrity, the absence of HTTPS opens the door for malicious third parties to conduct certain man-in-the-middle attacks, e.g., injecting advertisements, unsolicited content, or malicious code into the ckpool.org web server's responses to users.
Given that
Let's Encrypt provides free TLS wildcard certificates (which would cover ckpool.org and all of its subdomains with one certificate), I see no reason to not deploy HTTPS-by-default sitewide, not just on ckpool.org but also on solo.ckpool.org. Having some privacy and security
is far better than having none at all.
On that note, I'm also of the opinion that the stratum protocol should be extended to include support for
TLS 1.3 — not so much for data confidentiality, but more for server authentication and data integrity, to ensure that miners would be talking to the true stratum servers and that their communications with the servers would not be tampered with.