4 ms·

> Getting a cert error on FF/Android That is because the SSL certificate name only matches *.github.com You need to access the website over HTTP → http://yama

> Getting a cert error on FF/Android That is because the SSL certificate name only matches *.github.com You need to access the website over HTTP → http://yamanote.style/ http://yamanote.style/

dontbenebby 4y ago
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#QUANTUM_attacks https://en.wikipedia.org/wiki/Tailored_Access_Operations#QUA... https://en.wikipedia.org/wiki/Great_Cannon#Known_uses https://en.wikipedia.org/wiki/Great_Cannon#Known_uses
- lxgr 4y ago
  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.
  - dontbenebby 4y ago
    > 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 https://en.wikipedia.org/wiki/Data_integrity [2] https://en.wikipedia.org/wiki/Transport_Layer_Security#Data_integrity https://en.wikipedia.org/wiki/Transport_Layer_Security#Data_...
    - Cpoll 4y ago
      I think you're talking at cross purposes. The person you're responding to isn't saying that http:// 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.
      - dontbenebby 4y ago
        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.
        Cpoll 4y ago
        > 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.
- Cpoll 4y ago
  > 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 cert error on FF/Android That is because the SSL certificate name only matches *.github.com You need to access the website over HTTP → http://yamanote.style/ http://yamanote.style/

dontbenebby 4y ago

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#QUANTUM_attacks https://en.wikipedia.org/wiki/Tailored_Access_Operations#QUA... https://en.wikipedia.org/wiki/Great_Cannon#Known_uses https://en.wikipedia.org/wiki/Great_Cannon#Known_uses

lxgr 4y ago
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.
- dontbenebby 4y ago
  > 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 https://en.wikipedia.org/wiki/Data_integrity [2] https://en.wikipedia.org/wiki/Transport_Layer_Security#Data_integrity https://en.wikipedia.org/wiki/Transport_Layer_Security#Data_...
  - Cpoll 4y ago
    I think you're talking at cross purposes. The person you're responding to isn't saying that http:// 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.
    - dontbenebby 4y ago
      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.
      - Cpoll 4y ago
        > 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.
Cpoll 4y ago
> 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.