No you don't. At least not even on old IE 11, and I can't imagine any other browser doing it worse (and I know Firefox). The browser is supposed to allow you to access the site my just confirming that you want. No root certificates.
I used mobile Safari both on iOS 11 and iOS 10 with no problem on that site. Also on mac OS, at least according to this picture, it's not the CA that's accepted, just the exact site certificate and only for the given site:
The certificate is not trusted because the issuer certificate is unknown.
The server might not be sending the appropriate intermediate certificates.
An additional root certificate may need to be imported.
Folks, the reason you get a certificate error is because this .mil site uses a certificate signed by the DoD CAs and none of the major OS/browsers ship with them pre-installed (for what should be obvious reasons).
Out of curiosity, what are those obvious reasons? Is it because the US military is less trustworthy than other US government institutions or, say, Chinese and Turkish government CAs?
Edit: To make this clear, I'm not interested in a spurious political debate, I'm really just interested in the reasons / who decided this e.g. for my browser Firefox on the basis of what reasons.
I have ranted to co-workers for years now about the DoD with their third party root CA cert. I never know if the link I'm accessing is actually for the DoD or not.
I personaly cannot think of a good reason they do this. Maybe they argue that they don't trust any CA Authorities other than themselves due to issues in the past like with symantec https://searchsecurity.techtarget.com/podcast/Risk-Repeat-Ba... or entrust
> I personaly cannot think of a good reason they do this. Maybe they argue that they don't trust any CA Authorities other than themselves
They do it precisely because they cannot trust any other CAs. You cannot trust any CAs — and yet you do. Go into your browser: odds are you have CAs controlled by the Russian, Chinese & Turkish governments. You're not just trusting those CAs to issue certificates for .cn, .ru or .tr: you're trusting them for every TLD in the world, to include .com, .gov & .mil. Yes, if you're using XPKI (the standard PKI basically everything on the Internet uses), you're trusting that the Chinese government will never man-in-the-middle your sessions with the IRS. The DoD (rather wisely) chooses to trust only itself to certify itself.
My own opinion is that what we should have done was adopt a system which leveraged DNS to delegate trust (note that this is what Let's Encrypt does), and that we should have rooted DNS in a multinational board: if the U.S., China, Russia, Iran, the United Kingdom, the Ukraine, France & Mexico all agree on something, it's really very likely to be true.
We should also have leveraged IP assignments. Imagine if when you talked to a system it produced proof that it really is allowed to have its IP address and that it really is allowed to speak for a particular domain. That's really what people want, not some sort of nebulous tie to a real-world identity. What we care about is that facebook.com is facebook.com, not that it's Facebook, Inc., headquartered in Menlo Park.
Until that time we have a multinational board controlled CA, is there a list somewhere of the "sensible subset" of browser certs, for various types of users?
Fair point, I didn't really consider the issue with the other CAs that are currently trusted.
Isn't it a double edge sword though with what they chose to do instead? By the DoD using their own CA people accessing their sites externally or on non-DoD devices cannot reliably know if they're being ease dropped on either. It has it's benefits for DoD employees using DoD devices but anyone outside the DoD needs to roll the dice or first request the CA root cert from a DoD employee?
99%+ of DoD traffic will be from DoD-managed endpoints, which will be managed and have the DoD CA certificates installed. The DoD use case doesn't typically require them to cater to outside users, with possible exceptions for things like recruiting, which can be handled on separate networks.
I've personally been on support screen sharing conferences with the DoD before as a third-party consultant/contractor. They do not provide all contractors, especially third party, with DoD managed devices and in those cases I always thought that it was a bad practice. I asked for the people on the conference to e-mail me the root CA cert to validate the thumbprint was the same as the site but I'm not sure everyone would do that and instead blindly choose the 'proceed anyways' option.
/edit.
That was a very long time ago though so I'm not sure if they're even using that same screen sharing site anymore or if they've since changed it to use a public CA root cert.
To add onto what eadmund wrote, militaries need to control their own CAs, lest critical systems become disrupted due to the revocation of their certificates by civilian CAs who were hacked (including physical or employment infiltration) by a foreign military. In order to secure military systems, the military would then have to take over the civilian CA, either formally or informally (by defining standards and dictating employment), which is a non-starter. Militaries further do have the resources to manage their own CAs internally, so the cost of running their own CA is a non-issue.
Public companies don't typically have "our CA getting hacked by a foreign power in a war affecting all our traffic" as a part of their threat model, which is why public companies can use public CAs without worry.
> I personaly cannot think of a good reason they do this.
They cannot trust anyone else but themselves, they have to be fully in control of the whole chain of certificates.
Other than reasons like others mentioned: security and/or not following public CA guidelines, there are also other government sites with invalid TLS certificates due to incompetence. I.E. https://www.12306.cn, the TLS cert is valid and signed by DigiCert but the common name field was not matching the domain the site is serving. ¯\_(ツ)_/¯ Also, I recalled they would asked you to download their own root cert to during the checkout process. This is a high-speed rail ticketing site being used by billions of people every year. Go figure.
I would like to add some constructive conversation instead of banter about the cert...how does this get around malware/rootkit software that is embedded in the mobo or bios. How is this really any different than a LiveCD of Kali Linux or something?
I see that it is read-only media so I suppose that helps, but in the end its still only as secure as the machine that you run it from.
They have a DoD accreditation for their software (EW) but not their bootable media. Therefore, if you govvies run this on your government systems, you'll get your hand slapped and theres no guarantee it won't flag your system.
Its a partial fact. Unless you put principal in picture, appreciation figure along is of no use. And in case of sanjose housing, the ratio is not that impressive
"TENS differs from traditional operating systems in that it isn't continually patched"
Uh-oh. They argue that this is not an issue since the drive is read only, preventing any persistence of malware between sessions. However, this still means that there are known and fixable holes in the system which are exposed in using TENS; just because the malware goes away when you reboot, doesn't make it ok to allow malware in in the first place.
Also, what about literally any hardware security threats, like physical keyloggers or any evil low level software (bios, eufi, etc)
30 comments
[ 2.8 ms ] story [ 22.1 ms ] threadhttps://i.stack.imgur.com/vqOBP.png
https://i.imgur.com/spJHOdE.png
It's not the worst option out there, but it's far from a "general purpose" Linux LiveCD.
The certificate is not trusted because the issuer certificate is unknown. The server might not be sending the appropriate intermediate certificates. An additional root certificate may need to be imported.
Error code: SEC_ERROR_UNKNOWN_ISSUER
----
Neat
Edit: To make this clear, I'm not interested in a spurious political debate, I'm really just interested in the reasons / who decided this e.g. for my browser Firefox on the basis of what reasons.
I personaly cannot think of a good reason they do this. Maybe they argue that they don't trust any CA Authorities other than themselves due to issues in the past like with symantec https://searchsecurity.techtarget.com/podcast/Risk-Repeat-Ba... or entrust
They do it precisely because they cannot trust any other CAs. You cannot trust any CAs — and yet you do. Go into your browser: odds are you have CAs controlled by the Russian, Chinese & Turkish governments. You're not just trusting those CAs to issue certificates for .cn, .ru or .tr: you're trusting them for every TLD in the world, to include .com, .gov & .mil. Yes, if you're using XPKI (the standard PKI basically everything on the Internet uses), you're trusting that the Chinese government will never man-in-the-middle your sessions with the IRS. The DoD (rather wisely) chooses to trust only itself to certify itself.
My own opinion is that what we should have done was adopt a system which leveraged DNS to delegate trust (note that this is what Let's Encrypt does), and that we should have rooted DNS in a multinational board: if the U.S., China, Russia, Iran, the United Kingdom, the Ukraine, France & Mexico all agree on something, it's really very likely to be true.
We should also have leveraged IP assignments. Imagine if when you talked to a system it produced proof that it really is allowed to have its IP address and that it really is allowed to speak for a particular domain. That's really what people want, not some sort of nebulous tie to a real-world identity. What we care about is that facebook.com is facebook.com, not that it's Facebook, Inc., headquartered in Menlo Park.
Isn't it a double edge sword though with what they chose to do instead? By the DoD using their own CA people accessing their sites externally or on non-DoD devices cannot reliably know if they're being ease dropped on either. It has it's benefits for DoD employees using DoD devices but anyone outside the DoD needs to roll the dice or first request the CA root cert from a DoD employee?
/edit. That was a very long time ago though so I'm not sure if they're even using that same screen sharing site anymore or if they've since changed it to use a public CA root cert.
Public companies don't typically have "our CA getting hacked by a foreign power in a war affecting all our traffic" as a part of their threat model, which is why public companies can use public CAs without worry.
They are in a kind of unique position.
https://iase.disa.mil/pki-pke/Pages/tools.aspx
*under Trust Store
I see that it is read-only media so I suppose that helps, but in the end its still only as secure as the machine that you run it from.
Uh-oh. They argue that this is not an issue since the drive is read only, preventing any persistence of malware between sessions. However, this still means that there are known and fixable holes in the system which are exposed in using TENS; just because the malware goes away when you reboot, doesn't make it ok to allow malware in in the first place.
Also, what about literally any hardware security threats, like physical keyloggers or any evil low level software (bios, eufi, etc)