It's better to accept the risk so you get the integrity check of HTTPS.

The issue this warning is calling out is that someone who controls the certificate could modify the data, but that's just one person, so if we know it's a misconfiguration not fraud, it's better to click "accept the risk", get an integrity check, and ensure the files are not modified between the server and your client.

Look into the NSA's Quantum insert or China's Great Cannon to understand why these integrity checks are important.

https://en.wikipedia.org/wiki/Tailored_Access_Operations#QUA...

https://en.wikipedia.org/wiki/Great_Cannon#Known_uses

> The issue this warning is calling out is that someone who controls the certificate could modify the data

No, the issue the warning is calling out is that the server your browser is communicating with can't prove that it's yamanote.style.

There's no way to determine whether this is misconfiguration or fraud (though you can apply logic and usually come to the conclusion that it's misconfiguration in this case).

Example attack:

1. I host a fraudulent site on GitHub Pages, so it gets served up with the *.github.com cert.

2. I intercept your request to yamanote.style (let's say you're on my network [let's say I'm China]) and send you my GitHub pages content, signed by GitHub with their *.github.com cert.

This would look just like what's happening to yamanote.style right now, except that I would be controlling the content of yamanote.style.

Getting a valid certificate is really not difficult anymore these days. Github Pages even does it for you, as do many other hosters and web servers.

Given that, it seems like a very bad idea to encourage people to override any encryption-related warnings in the browser.

> it seems like a very bad idea to encourage people to override any encryption-related warnings in the browser.

I have no idea how you arrived at that conclusion.

I literally just explained, point by point, why going to the site without the integrity check is more dangerous and am providing additional citations[1,2].

Please immediately cease your disagreement, as it is actively dangerous and might confuse vulnerable people.

If you have specific feedback on why I am wrong (other than a toddlerlike desire to disagree) please feel free to reply below, after making sure to read the cited material provided and ensure you understand the concept of data integrity.

[1] https://en.wikipedia.org/wiki/Data_integrity

[2] https://en.wikipedia.org/wiki/Transport_Layer_Security#Data_...

I think you're talking at cross purposes. The person you're responding to isn't saying that http:// is better than an invalid certificate. They're saying that encouraging people to ignore browser warnings is a bad idea.

Bypassing the warning by clicking "proceed anyway" and bypassing it by visiting the http endpoint are both dangerous, the former is simply less dangerous. A technical user can evaluate the risk, which many times are very low, but most users can't.

If your threat model includes the Great Cannon (which you cited), ignoring a browser warning is actively dangerous. So in fact it is you that's confusing vulnerable people.

Ok I think I get what you're saying.

To be clear, my definition "ignoring" a warning is just blindly clicking, not deciding to proceed after careful thought.

As for the Great Cannon and/or Quantum Insert, since packets can be routed in strange ways due to the speed of light making some routes you would not expect the quickest, I'd stand by my assertion that clicking through a warning to achieve integrity after examining it and seeing it is from Github, a place it is common to stand up a website then add a custom domain name, is reasonably secure especially on a technical discussion site like HN.

> can be routed in strange ways due to the speed of light making some routes

Correct, although the speed of light doesn't have anything to do with it (and the speed of the signal never reaches the theoretical speed of light, it's more like the speed of signals through a combination of copper, fiber, whatever else). It'd be the same if we were performing IP over Avian Carriers. The routing is at the mercy of all the IPS hardware and IXes between source and destination, which make their decisions of where to route your packets based on several factors (including possibly NSA/Chinese/whatever intervention)

> after examining it and seeing it is from Github, a place it is common to stand up a website then add a custom domain name, is reasonably secure

I mentioned this in a different reply, but I don't think this is the case. The government of China is just as capable of creating a GitHub Pages as anyone else.

Well if we think the site is a honeypot then I don't know what to tell you at a certain point you need to decide if you're gonna click an unknown link or not, and if you do, engage in harm reduction. I assume many people have used it with no issue if it's on the front page, hence my suggestion to view it with an integrity check.

> I assume many people have used it with no issue

This is also a dangerous assumption. If 95% of HN is outside of China, they'll have no issue with the website, but that validation is meaningless for the 5% behind the Great Firewall (percentages invented).

> Well if we think the site is a honeypot

That's not the logical assumption to make. A honeypot would have a valid certificate.

A broken certificate simply means either a) the website you are visiting is misconfigured, or b) a third party has intercepted your (possibly you, *personally*, and no-one else) communication with that website. You are not communicating with the website, you are communicating with the 3rd party. This might mean something as stupid as your ISP injecting ads into websites (a thing that happened before https was so prevalent), or it could mean a government-level actor with a more nefarious agenda.