4 ms·
AFAIK, the point of the DoD Root CA is to avoid trusting an external entity not to intercept military traffic. Most .mil HTTPS sites that are intended to be acc
by ihattendorf 8y ago
AFAIK, the point of the DoD Root CA is to avoid trusting an external entity not to intercept military traffic. Most .mil HTTPS sites that are intended to be accessed by the public (like https://www.army.mil/ https://www.army.mil/) are signed by a regular Root CA, while internal sites use the DoD Root CA.
- sigzero 8y agoThat is pretty much how it is.
- netheril96 8y agoBut any CA can issue certificates for any domain in our current system. Sure, you can always manually inspect the certificate and see if the root CA is expected. But does anyone do that at all?
- ploxiln 8y agoI guess you could have an "internal network" browser config with _only_ the DoD CA root.
- zjs 8y agoAny CA can issue certificates for any domain, but they may not be permitted to do so. Certification Authority Authorization (CAA) DNS records can be used to indicate which CA is authorized to issue certificates for a domain. The CA/Browser Forum requires all certificate authorities to check CAA records prior to issuance.
- netheril96 8y ago> The CA/Browser Forum requires all certificate authorities to check CAA records prior to issuance. And what if a CA fails to check CAA records? Revoke their status as an authority? By then attackers may have already obtained highly confidential information from DoD sites.
- move-on-by 8y agoIsn't that what the DNS Certification Authority Authorization (CAA) DNS record [1] is supposed to solve? Combine that with certificate transparency enforced with the `Expect-CT` header [2] and its pretty locked down. If a CA does not respect the CAA record and issues anyways, the cert will be logged to a public log. Tools like CertSpotter [3] can be setup to give notifications when certs are created. If a cert is created that should not have, then you can get an alert about it and can begin the reporting and revocation process. If a cert is created without being written to a certificate transparency log, then browsers that support `Expect-CT` header should reject it with a big error message. This works in chrome, but not yet in firefox or safari [4]. [1] https://tools.ietf.org/html/rfc6844 https://tools.ietf.org/html/rfc6844 [2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expect-CT https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ex... [3] https://sslmate.com/signup?for=certspotter https://sslmate.com/signup?for=certspotter [4] https://invalid-expected-sct.badssl.com/ https://invalid-expected-sct.badssl.com/
- angelsl 8y agoBut only the owner of the private key associated with the certificate can intercept traffic. The keys used to sign the certificate have no impact on the actual encryption whatsoever...
- Someone1234 8y agoAll true/correct. It is worth considering that some DoD systems only have whitelisted CAs installed to limit the ability for an adversary to MitM. For example a DoD laptop used in a foreign country, you don't want the foreign government to be able to issue a certificate for a DoD property using their CA (or pressure/steal a commercial CA's signing certificate).
- Jedi72 8y agoI opened this link in Melbourne, Australia, never been to this page before in my life, and it downloaded almost instantly. Do .mil domains get some kind of special preference, or is my brain just glitching out?
- discreditable 8y agoTheir page is pretty light. It's served over http2 and about 1MB of mostly images. There's only 60K/200K (compressed/uncompressed) of Javascript.