
U.S. Homeland Security employees locked out of computer networks - prostoalex
http://www.reuters.com/article/us-usa-cyber-dhs-idUSKBN160240?utm_campaign=trueAnthem:+Trending+Content&utm_content=58ac9d7304d30158a0ec7ad1&utm_medium=trueAnthem&utm_source=facebook
======
thinkmassive
Part of me was hoping to see some sign of hacktivisim, not for any particular
political stance, but because most of us probably agree the federal government
has been slacking off as far as security goes. An eye-opening event might be
beneficial.

"it appeared the domain controller credentials had expired on Monday when
offices were closed for the federal Presidents Day holiday"

Oh, well that's not nearly as exciting. Still a dismal sign of the state of
"cyber security" though.

~~~
smsm42
One would think in 2017 there would be some kind of solution that allows to
track all certs in the org and raise alert well before the cert actually
expired (of course, nothing can prevent admins from ignoring the alerts). But
given how many cert screwups happen around, looks like it's not happening.
Maybe somebody should create a startup doing this? ;)

~~~
kefka
Yeah. It's called Acmetool, LetsEncrypt, Cron, and Nagios.

Problem solved. Free certs, automated, cronned, and externally monitored. What
else do you need?

Oh thats right. The feds forbid LE. Alright boys and girls, go back to your
$499 Comodo certs.

~~~
hyperman1
Maybe you can clear up something for me: I am in CC for an email discussion
between 2 parties exchanging sensitive personal information.

Party A uses LetsEncrypt to protect the https site storing the information
(And needs a username/password or something to grant access to Party B)

Party B does certificate pinning, and complains that Party A's cert changes
every three months without warning and without being sure the new cert still
points to Party A.

Party A says Party B should stop the pinning and just accept everything signed
by LetsEncrypt.

Party B says they want a way to be 100% sure they are talking with Party A and
need a better (EV?) cert.

The discussion is going back and forth for a few months now (and re-ignites
every three months when communication goes down _again_ and pissing everyone
off). Who do you think is right here?

~~~
jerf
1\. Certificate pinning is not a solution to the problem. Certificates change
without warning anyhow, because they may be compromised and revoked at any
time.

2\. Let's Encrypt certificates are indeed the lowest grade of SSL certificate.
That's not a criticism of Let's Encrypt, it's just the nature of the
situation. There are legitimate reasons to consider it too low a level of
assurance. I have no idea whether your parties have that level of need or not.
But I can point out that if you want a better grade of cert than Let's
Encrypt, you do need to go for the fairly expensive ones that require a lot of
real, human validation. There's not much point in just getting another cheap-
but-not-free cert that has roughly the same level of validation.

3\. There's another solution to this problem entirely, if you're communicating
between two parties and that's all this cert is doing (i.e., you're not
speaking to the general public with this cert). Make your own certificate
authority, sign your own certs, have the public key of that CA inserted into
the Java cert authority.

Creating your own certificate authority is very simple. To give you a sense of
how simple, here's some scripts I bashed together to set up nodes that speak
to each other over SSL: Set up the CA [1] Build a new cert signed by that CA
for the node [2].

I am _NOT_ saying you can just use those or that you should even crib from
them. These are generally intended for quick reference and testing only even
in the context of this project ("real" users are expected to do their own cert
management with real certs), and the needs of this project are significantly
different from an HTTPS website. My intent in linking those is merely to
demonstrate the rough complexity of setting up a CA is only a few lines in
bash, not a monstrous impossibly-large undertaking, and you can Google this
stuff up in a day or two, tops. The hard part is all around how careful you
are with the private keys and revocation, and the fact you must set up and
implement your own security policies around the certs. (My suggested
revocation policy would be "we'll call you", and that if a cert is ever
compromised, just re-roll the whole process from start to finish and create a
new CA. "Real" revocation is somewhat complicated, and somewhat unsatisfactory
anyhow. Take advantage of the smallness of the problem and the pre-existing
personal connections. A lot of the at-scale SSL issues arise because we don't
have those.)

[1]:
[https://github.com/thejerf/reign/blob/master/create_signing_...](https://github.com/thejerf/reign/blob/master/create_signing_cert)

[2]:
[https://github.com/thejerf/reign/blob/master/create_node_cer...](https://github.com/thejerf/reign/blob/master/create_node_cert)

~~~
jlgaddis
I take slight issue with "Let's Encrypt certificates are indeed the lowest
grade of SSL certificates".

Other issuers perform domain validation in the same ways (specific content at
a specific URL, DNS records, e-mail validation, etc.) as LetsEncrypt. LE just
makes it easier.

And, from a technical perspective, certificate X from issuer A is no different
than certificate Y from issuer B (assuming both A and B are trusted root CAs,
same key length, etc.).

If your issue is with DV vs. EV, yes, I agree that LE certs aren't on the same
level as EV certs, but that's not the problem LE is trying to solve.

~~~
jerf
The existence of other vendors of the lowest grade of certificate does not
mean that LE doesn't produce the lowest grade of certificate.

As I said, it is not a criticism of LE. It is simply what they are. It doesn't
matter how we "feel" about that. It's not like the LE project set out to
produce the highest grade of cert but failed; they accomplished exactly what
they intended, and it is good.

------
notspanishflu
Link to the article without the tracking BS.

[http://www.reuters.com/article/us-usa-cyber-dhs-
idUSKBN16024...](http://www.reuters.com/article/us-usa-cyber-dhs-
idUSKBN160240)

~~~
raverbashing
Removing such information automatically is something HN could think about

------
mxuribe
"...The source characterized the issue as one stemming from relatively benign
information technology missteps and a failure to ensure network redundancy.
There was no evidence of foul play..."

Yeah, right! That's just what they want you to believe! Come on everyone,
adjust your tinfoil hats now!

lol ;-)

