An Introduction to HTTPS, by 18F and DigitalGov University(18f.gsa.gov)
18f.gsa.gov
An Introduction to HTTPS, by 18F and DigitalGov University
https://18f.gsa.gov/2015/07/16/introduction-to-https-webinar/
14 comments
Full disclosure: I'm the submitter and the creator of these videos. Happy to answer questions or take feedback for future educational work we could be doing.
I watched all of this and was thrilled to see this kind of content from the federal government. THANK YOU very much!
I have been on a personal crusade of sorts insisting on encryption everywhere. When I come across large sites that don't support any encryption (I am looking at you, Squarespace), I struggle with content to send them to prove my point but this will do nicely.
I have been on a personal crusade of sorts insisting on encryption everywhere. When I come across large sites that don't support any encryption (I am looking at you, Squarespace), I struggle with content to send them to prove my point but this will do nicely.
Really curious if you can speak to any internal politics around advocating for encrypting more communications while much of the executive branch is advocating against that.
Is 18F sufficiently independent, or this project sufficiently below the radar that it just isn't an issue?
Is 18F sufficiently independent, or this project sufficiently below the radar that it just isn't an issue?
Entirely different worlds.
People think "The Federal Government" is a monolith, and they could not be more mistaken. It is a collection of individual entities, operating largely independently and often at odds with one another. 18F is a different entity with a different set of goals from the law enforcement (FBI/DEA/etc.) and intelligence (NSA/CIA/GeoInt) agencies.
In any case, it's also different parts of the tech stack - encrypting everything over the wire with HTTPS is fine so long as the underlying encryption is weak and/or the NSA have a set of keys. The FBI can always just issue a national security letter to the party with whom you are communicating.
People think "The Federal Government" is a monolith, and they could not be more mistaken. It is a collection of individual entities, operating largely independently and often at odds with one another. 18F is a different entity with a different set of goals from the law enforcement (FBI/DEA/etc.) and intelligence (NSA/CIA/GeoInt) agencies.
In any case, it's also different parts of the tech stack - encrypting everything over the wire with HTTPS is fine so long as the underlying encryption is weak and/or the NSA have a set of keys. The FBI can always just issue a national security letter to the party with whom you are communicating.
> People think "The Federal Government" is a monolith, and they could not be more mistaken. It is a collection of individual entities, operating largely independently and often at odds with one another.
That's definitely an accurate description of the US federal government.
That's definitely an accurate description of the US federal government.
> Is 18F sufficiently independent, or this project sufficiently below the radar that it just isn't an issue?
Nothing below the radar about it:
https://www.whitehouse.gov/blog/2015/06/08/https-everywhere-...
Nothing below the radar about it:
https://www.whitehouse.gov/blog/2015/06/08/https-everywhere-...
What sort of experience is 18F looking for? Mostly senior devs or a range?
Very useful content. But fwiw, the speaker in the video has a very funny pronunciation of panacea :)
Haven't had a chance to look at the content itself yet, but do you cover FIPS at all? Our company is wanting to sell product to the U.S. Federal govt and it turns out we need to improve our TLS (data-in-transport) implementation to use FIPS-validated crypto providers. It'd be nice to understand why simply using strong TLS v1.2 cipher suites is not enough and we need to also plugin a special crypto provider.
The reason for requiring a FIPS-validated crypto provider is that means the crypto provider been audited by a vetted auditor. In order to carry sensitive information, the crypto needs to be audited by a vetted auditor. "The CIO's nephew totally coded up the crypto last Summer, just trust us that it's good" doesn't cut it when handling sensitive government data. In particular, it means that random values are generated by a FIPS-certified generator, not just srandom(time()^getpid()); int x = random(); int y = random(); int z = random(); The government needs some kind of auditing standard and practice for systems that handle sensitive information. FIPS is far from perfect, but it gives a good lower bound on what the government is buying.
FIPS is bureaucratic government red tape, and nothing else. It gives the "US Department of Whatever" and their contractors someone to blame when there's a fuck up.
No one respected in cryptography that I've met, or read papers from, would stand behind it as a seal that'd mean anything in actual security (please, someone, prove me wrong: I want to see SOME light in this tunnel). There are private entities with much more sensitive information than the U.S. Government, and the ones that take it seriously easily surpass FIPS (in purpose, not paper) with good engineering, because they can't hide behind a rubber stamp.
Not too long ago, I was on a team that was required to keep a FIPS-certified (FIPS 140-2) binary blob in production for months while there were known exploits against it. If you actually care about keeping amateur algorithms and implementations out of sensitive situations (vs. "Proving You Care via Paperwork"), you'd do better to follow Google or Facebook's security blogs than FIPS, because they react faster.
No one respected in cryptography that I've met, or read papers from, would stand behind it as a seal that'd mean anything in actual security (please, someone, prove me wrong: I want to see SOME light in this tunnel). There are private entities with much more sensitive information than the U.S. Government, and the ones that take it seriously easily surpass FIPS (in purpose, not paper) with good engineering, because they can't hide behind a rubber stamp.
Not too long ago, I was on a team that was required to keep a FIPS-certified (FIPS 140-2) binary blob in production for months while there were known exploits against it. If you actually care about keeping amateur algorithms and implementations out of sensitive situations (vs. "Proving You Care via Paperwork"), you'd do better to follow Google or Facebook's security blogs than FIPS, because they react faster.
I'm on a roll tonight so I'll ask the dumb, easy question. What cipher/key size are you using?
https://wiki.openssl.org/index.php/FIPS_mode_and_TLS#TLS_1.2 isn't exactly a restrictive sets.
https://wiki.openssl.org/index.php/FIPS_mode_and_TLS#TLS_1.2 isn't exactly a restrictive sets.
I worked as a government contractor for quite a while (SAIC) and I applaud this effort. I imagine the hurdles will be immense, so I wish you the best. We need more of this.