Hacker News new | comments | show | ask | jobs | submit | kingkilr's comments login

Super happy that the OpenSSL team decided to be proactive and just enable `SSL_OP_SINGLE_DH_USE` for all users, as well as bump the minimum DH key size. Better defaults for everyone!

-----


Yeah, and it looks like BoringSSL did that about a year ago :)

https://boringssl.googlesource.com/boringssl/+/9f226a5f5183e...

-----


David's the best :-)

-----


Interesting that the corresponding ECDH option is still disabled by default and ephemeral keys are cached.

-----


It's about time they did. I always wondered why this was disabled by default.

-----


It launched yesterday :-) https://alexgaynor.net/2016/jan/20/announcing-letsencrypt-aw... is some tooling I wrote for use on AWS.

-----


Very cool, I was working on basically the same thing[1]. What do you think will happen to your project now that this exists from Amazon?

[1] https://github.com/ubergeek42/lambda-letsencrypt/

-----


Please be careful using urllib2, unless you are on Python 2.7.10+ or 3.5+ it does not do HTTPS certificate validation.

-----


Indeed. However, it's important to note that even if someone does MITM letsencrypt.org, they only see your public key and CSR. The private keys never get sent over the wire, so you don't risk leaking your private keys. However, a MITM could issue you a fake certificate that doesn't chain back to the Let's Encrypt root. This risk isn't any more than the way most CAs do it now (they email you the signed certificate).

-----


I don't see the point in verifying that I'm connecting to Let's Encrypt. If I am not connecting to Let's Encrypt then the cert I get back won't show as being issued by them.

-----


So you'll display a challenge on your website issued to someone else. This certifies an attacker's key for your domain.

An authentic connection to LE is literally fundamental.

-----


> An authentic connection to LE is literally fundamental.

Unless you validate the certificate that you get using a pre-installed LE root certificate.

-----


Can you articulate a _specific_ threat model under which this extension fails to protect against mass data collection by Google?

Or is this idle speculation.

-----


The threat is that Google (perhaps forced by the NSA, perhaps only for some users) modifies Chrome to include code that logs all keystrokes or specifically detects the Signal extension (or standalone app if Chrome is also installed) and uploads the plaintext of all messages to Google or to the NSA.

In other words, you have to trust Google to not insert such a trojan by itself and to not bow down to the U.S. government should it try to secretly force Google to do so.

You also have to trust that their security is good enough to prevent third parties from covertly performing such a feat.

That's not say that Google should not be trusted or should be trusted less than other parties, but that's the threat.

-----


Google adds Google Analytics to their browser, to automatically report what a user does in Chrome apps, and "accidentally" your whole chat history ends up on Google’s servers?

This is not an unrealistic example.

-----


last time I checked Google Analytics doesn't record anything like that kind of data.

-----


It records where you click, and when.

"Accidentally" logging keys is possible, as Google can modify the content of the JS on request – for example, in case of being served an NSL, Google can be forced to modify the JS to log that.

-----


Run Chromium, problem solved.

-----


> Google adds Google Analytics to their browser

Source?

-----


Someone asked for a hypothetical way Google could, in the future, get the data.

As you are doing automated updates, Google can just add Analytics to the browser, and even publish it as something "good".

-----


https://github.com/department-of-veterans-affairs/vets-websi... :-)

-----


Awesome. Thank you!

-----


Is there any way those of us who are more experienced on the backend can help out?

-----


hmmm, one thing we could really use is some tests. Maybe you could write some simple capybara/rspec or equivalent integration tests for the site, just to make sure that its parts are functioning correctly?

-----


Since this is a Jekyll site, I'm not sure what we could wrap tests around. The beauty of the static site generator is that it just always works -- at least as far as the html content is concerned.

Is there a specific javascript feature or interactive feature that you'd like help with testing?

-----


It does work great! We've gotten this far without them. But it makes me nervous.

I'd like to have a few smoke tests to guard against things like:

* accidental deletion of pages

* accidental removal of header/footer/important elements

* proper 508 compliance

* valid HTML/JS/CSS (and probably lint all those things too)

Also the facility locator is a fair-sized hunk of JS I wrote that needs tests.

edit: also, in the future there will surely be more dynamic parts to the site, so getting a framework in place for tests will both save work and raise the expectation of quality

-----


It's more like you want a linter with custom rules for how you think a page should look. Actually, it's impressive to create the entire site with only content and simple layout. It's interesting there isn't a better way to manage and edit all that content...

508 Compliance is another interesting point. Open source scanner to assess if a page complies? It's another linter, it has to look at the html. I don't know much about 508 but I'm going to say from a quick look at your <html> that it's as clean as you could possibly hope for, and I would expect that latest screen reading tools would be able to navigate it. If that's not the case it says more about the particular reading tool than the website.

The facility locator! That was interesting, the default state is everything selected, please flip it to everything deselected. I haven't tried it out more because it overloaded ;-)

Benefits comparison tool also looks like it has a pretty big data set behind it, that was probably cool to develop.

-----


(I work at USDS@VA)

I wouldn't say it's a philosophical difference. We're definitely tackling the problem in two different ways, but that's not because either group thinks the other is wrong, it's because this is a big problem that requires attacking it from many angles.

-----


<3

-----


Wearing my python core dev hat: a litany of security fixes, python3 compatibility stuff, useful stdlib modules, dict and set comprehensions, probably more stuff I can't remember.

-----


I'm not an expert (by any stretch of the imagination) on federal hiring policy, but my appointment is 2 years, with the opportunity to extend another 2 years. No clue what happens after that.

-----


Salary range is $116,021 to $158,700.

(From va.gov/ds/, where I work, I believe this is the same for all the other Digital Service teams though)

-----


So basically it's more "mercenary" than performing a "tour of duty" to serve your country.

-----


Why do you put it that way? Everyone serving in military takes home a paycheck, but that doesn't make them mercinaries.

The top tech talent that we aim to attract to USDS often can make far more than these salaries staying in the private sector, so appealing to a sense of civic duty and offering short-term engagements is what we have to do to recruit.

-----


> appealing to a sense of civic duty and offering short-term engagements

Which is why everybody loves getting a letter asking them to turn up for jury duty, right?!

-----


I think lots of people would enjoy serving on a jury if two things were fixed:

* You don't have to spend a full day in a courthouse doing nothing during the selection process

* The government guarantees you will continue receiving your normal income during the trial

-----


Please add "Having Jury Nullification Explained in Detail" to your list.

-----


Of course, if you're a student, they have no problem pulling you out of the classes that you might be paying several hundred a day to attend, without comp...

-----


Market for the people USDS is hiring generally is higher than that in cash, plus better benefits, plus 50-100k/yr in equity. There is some sacrifice, but not an insurmountable one.

-----


The army is all volunteers. But they still get paid.

-----


Wouldn't it be difficult to attract top talent (or even mediocre talent) in that range?

-----


Honestly, that's much better than I was expecting. Two years working to improve our shitty government systems in exchange for a quarter of a million? Sounds like a fair short-term deal, even if higher comp is available elsewhere...

-----


Bottom of 116 is pretty huge. Even for the Bay Area thats not a bad start

-----


The actually-doing-tech-work GS levels (GS-10 to GS-13), by comparison, are 50-60k. That is where government pay is still the big impediment.

$116k/yr for your entire mid/late career would also suck (compared to 200-400k in industry), but for <2 years, I can't see that alone being a huge issue, unless you have kids in college, are paying for a mortgage elsewhere, etc.

-----


Small note: the $200 million dollar figure wasn't for all of healthcare.gov, it was for the _authentication system_.

-----

More

Applications are open for YC Summer 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: