Hacker News new | past | comments | ask | show | jobs | submit login

I was a dev contractor for the US Army for a few years. None of this surprises me.

They had some goofballs policies that made it seem like vulnerabilities were the goal. I could bitch at length. Their TSA style security theater practices were the order of the day. The IA training was an embarrassing joke and they made you do it often enough to make you a little crazy.

I just checked the certificate of networthiness page and they don't have a valid SSL certificate. I recall that being the case years ago too. I wonder if it's been that way for the last 7 years? That's a cute little terrarium of the whole biome I remember.

Off topic a bit, but that all aside... I am more proud of the work I did there than at any other place in my career. I got a lot of excitement and engaged feedback about the interactive learning materials I created.

I'll never know if it made any difference, but the mere fact that someone's son or daughter COULD have noticed an IED threat they wouldn't have otherwise because of my work gives me all sorts of proud fuzzies.

That work had way more meaning than all the other CRUD/ML/Advertainment schlock I'll get to do for the rest of my life :)




> I just checked the certificate of networthiness page and they don't have a valid SSL certificate. I recall that being the case years ago too. I wonder if it's been that way for the last 7 years? That's a cute little terrarium of the whole biome I remember.

That's not quite true. Internal use sites don't have a valid cart issued by a "default" external vendor.

Public sites use existing CAs that are in use by the public. E.g., the Marines public facing site[0] is signed by DigiCert. If you go to a site that's public facing but for internal use like MoL[1], you'll see that the cert is issue by an internal DoD CA. This is intentional.

The DoD has an internal CA already set up. These internal use sites are a gateway to sensitive information, so the DoD doesn't want to rely on an external CA for HTTPS. What I never understood was why these internal CAs weren't marked as trusted on the internal machines. That would avoid the browser warnings when accessing one of these site from DoD hardware, and it would (in theory) force the user to double check when accessing the site from an external device.

[0]: https://www.marines.com/ [1]: https://mol.tfs.usmc.mil/mol


They are trusted by internal machines -- since a lot of internal authentication relies on these certificates. The DOD long ago moved away from password-based authentication mechanisms to certificate-based authentication (GSC-IS initially (CAC), now NIST SP 800-73 (PIV; CAC II)) and so the system will have the correct certificates or the user generally won't be able to login.

What I find as the most common error is that users setup an alternate browser (such as Firefox) that does not use the system certificate store and then lack the system's local certificate authorities.

Additionally, DOD PKI is now cross-signed with Federal PKI (FPKI), so it's larger than the DOD now and other agencies also use the same smartcards (PIV).


This bit is curious. I was issued a CAC while I was in, and as you said, it eliminated the need for passwords. But the internal sites (no matter if it was a laptop from the comm section, a hardwired desktop in a unit's building, or a desktop in a base facility) always failed the check for the certificate store. I always got the security warning (or insecure message) regardless of browser.


Slightly off-topic - but its semi-relevant here as this conversation involves the requirement of knowing (1) the state of the system security store (2) the state of an application's security store ... and maybe in some cases (3) understanding how an application modifies any trusted stores.

It seems we end up with a lot of possibilities for the states of these stores to diverge from our expectations ... I've been wondering how to verify a sane state for all these stores for even a use as simple as my own personally owned/controlled notebook ...

I'd really like a way to audit the system trust store in macOS and enforce that is in alignment with whatever the current 'blessed by apple' certificate trust relationships are and that any trust relationships I ever manually added by mistake/debugging have been removed...

I asked a question about this on stackoverflow but no one has responded ...

https://stackoverflow.com/questions/52527886/revert-all-cert...


I don't know the answer to your StackOverflow question as I don't use macOS/Mac OS X.

What I ended up doing to help this process along is including the relevant certificates inside my DOD Smartcard PKCS#11 module as certificate objects (with, of course, no corresponding private key objects).

For applications that use PKCS#11 (such as Firefox, via NSS), this means that when the module is loaded the appropriate certificates are also made available automatically. This was also (I believe) supported by the "TokenD" driver used to support macOS/Mac OS X so that enabling this driver made those certificates available and provided by the token, so no modifications to the local macOS system trust store were needed.


What happens in some cases is that new intermediate CAs are introduced and older client's certificate stores are not updated. In this case it is a TLS server error as the TLS server should be sending you all the intermediate certs to chain you to "DoD Root CA 2" (the root of DOD PKI -- which is also where smartcards are issued from, via different intermediate certificate authorities, prior to FPKI).


That's my recollection as well.


Ah thanks for educating me. My island at TRADOC didn't have anyone who knew those details. :P


Thank you for your work and for this comment. Regarding the last line: if you can work in the US and are not hamstrung by personal circumstances, there is no way, given the skills you imply having, that you can't find meaningful work: health care, education, energy all have dozens of good companies straining to find additional competent technical staff.


Thank you for the kindness. I'm in a bit of a slump right now so my cynicism is leaking.

Job offers are trivial to get. Meaning.. proper autonomy / feedback balance.. impact.. Life must be too easy for me to be such a snob. Neural fatigue is real.


I'm not sure what specific training you're talking about regarding DIACAP (which it would likely have been when you were working there; now replaced with RMF), but over all the goal of certification and accreditation is about assuming risk, and the DAA (Designated Approving Authority) assumes the risk so they need to be informed about the risk. More information can be found in DoD Directive 8500 (DoD Instruction 8500.02 specifically).

As far as the SSL certificate, I assume you mean: https://www.atsc.army.mil/ ? That site seems like it has a valid certificate, if you validate against the DOD PKI (now cross-signed with FPKI) root CAs:

    $ openssl s_client -CApath ./dod -connect www.atsc.army.mil:443 -servername www.atsc.army.mil
    ...
    SSL-Session:
        Protocol  : TLSv1.2
        Cipher    : ECDHE-RSA-AES256-SHA
        Start Time: 1539109915
        Verify return code: 0 (ok)


Looks like I was remembering the wrong acronyms. It was information assurance training. We had to do it every 6 months, and like twice in a month when Snowden did his thing.

My first year there it was a goofy flash game with uncanny valley cartoon characters awkwardly telling you not to share secrets at the bar to get laid. Every year I stayed it seemed to get longer and more awkward. At some point they added a boxing minigame that didn't have any training value. Nothing was optional.

It became a goal of mine that they'd let me remake it in a way that was... not patronizing... I never found anyone who knew who to talk to get me the project though. :(


The increased training around the time of the Snowden-based leaks was largely focused around informing people who hold a national security clearance about the fact that information remains classified even if it has been published on the Internet. There was concern that people holding a national security clearance may use their unclassified information systems to process this (still classified) material, causing those machines to need to be treated at the highest classification of information on which they process (as they are not "periods processing" machines). Additionally the "need to know" principles still apply, and looking at classified information without satisfying that criteria could cause revocation of sponsorship for holding a national security clearance.

The training likely stressed that just the source of the classified information was somewhere "outside" DoD it did not change the classification. This is because changing the classification requires an Declassification Authority to act on it, which is generally the Original Classification Authority -- of which there are very few.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: