Titanous

Is there a reason why you're using RSA over Curve25519? RSA is old and rusty at this point and there's no good reason that I know of to be using it in new cryptosystems. To a much lesser extent I also have the same question about using AES-GCM over Poly1305/ChaCha20.

Mozilla runs a root program that regularly enforces similar requirements on CAs. For example, they are currently discussing whether they will require the same of Symantec as Google or even more: https://groups.google.com/forum/#!topic/mozilla.dev.security...

And here is a thread about a Chinese government CA that mis-issued certificates for Google domains: https://groups.google.com/forum/#!topic/mozilla.dev.security...

This is how the public certificate authority system is set up. The client vendors (Google, Microsoft, Apple, Mozilla) choose what the rules are for trusting a Certificate Authority and which ones meet the requirements. These "root programs" are the only thing that prevents rogue/incompetent CAs from mis-issuing certificates on a regular basis.

Since the CA business model is based on selling digital signatures that meet specific requirements, the threat of those certificates not working as advertised is compelling.

On the other hand, the client vendors can't go overboard with requirements on existing "too big too fail" CAs because the alternative is having large portions of the Internet stop working in their products due to untrusted certificates.

Edited to add: Google doesn't run its own root program, they use the OS root store, which will be from Apple, Microsoft, or Mozilla (most Linux distros use the Mozilla list). This means that the requirements from Google are in addition to those of the OS that is being used.

Flynn is a high-level platform that doesn't require you to think about low-level components like schedulers, overlay networking, service discovery, consensus, etc. Flynn does of course include a built-in scheduler and other components that accomplish many of the goals mentioned in the article.

(disclosure: I am a cofounder of Flynn)

The article says they got the AOL address from Verizon via pretexting.

Here's the actual filing from Apple: https://s3.amazonaws.com/f.cl.ly/items/2G372p3E1D0m3806001A/...

An offline signing key was proposed as TACK: http://tack.io

Unfortunately HPKP was adopted by the browsers and TACK has gotten no traction with the vendors, despite being a more flexible system.

The Lessig 2016 campaign also has a tech volunteer program[1], but it is officially endorsed (unlike Coders for Sanders), and all of the software developed for the campaign (including software developed by the paid folks) is open source, developed on GitHub, and discussed openly on Slack.

[1] https://github.com/Lessig2016/Lessig2016.github.io

I have not personally asked, but I think the Archive Team has. I don't know the reasons behind the policy.

It's totally possible, they already have the infrastructure in place and 14PB of data available for download. Unfortunately the Wayback Machine data is not currently exposed publicly.

I really wish that the Internet Archive would provide bulk access to the Wayback Machine dataset. It would allow for a lot of interesting experimentation and research.

Yeah, I realize that depending on your toolchain it's not easily accessible. Ideally there would be a first-class implementation for each platform, but it looks like app stores are where we are headed. Though, that still leaves *nix package distribution, container images, language/framework and packaging as areas that can be helped by TUF.

We (Flynn) actually have a Go[0] implementation that you could use to either make a separate updater binary or even compile it into your app using the new alternative build modes coming in Go 1.5[1]. Our implementation also includes some tools to manage the metadata and signing so that you don't have to manually build it.

[0] https://github.com/flynn/go-tuf

[1] https://tip.golang.org/doc/go1.5#link

If you are implementing a software updater, you should use The Update Framework[0]. In this case, the compromise happened because a file server was hacked. A simple offline cryptographic signature (with proper verification) would have prevented this incident, but it would not allow key rotation and revocation or prevent rollback, freeze, mix-and-match, etc. attacks.[1]

[0] http://theupdateframework.com

[1] https://github.com/theupdateframework/tuf/blob/620fa6e95375c...

Note that without a separate Linux privilege escalation exploit, running QEMU in a least-privilege "container" for each VM should help stem the bleeding.

It is normal, but not desirable. You should feel free to exercise full disclosure if the vendor is not being responsible.

> [W]ithout the threat of full disclosure, responsible disclosure would not work, and vendors would go back to ignoring security vulnerabilities.

https://www.schneier.com/blog/archives/2012/06/on_securing_p...

Shellshock and Heartbleed both provide good examples of why public exploit code is a net good thing.

Researchers put Shellshock proof of concept exploit code into fuzzers[0] and managed to find five more bugs subsequently[1].

Heartbleed required a patch to OpenSSL, which is typically a dynamic library. I'd wager that without publicly available exploit code to test with many admins would have just installed the patch and failed to restart the server processes, leaving their systems vulnerable.

The solution to improving patch deployment timelines is automated updates, not having admins always online. Admittedly this is still an area that is underdeveloped.

[0] http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-...

[1] https://en.wikipedia.org/wiki/Shellshock_%28software_bug%29

No PoC was released with the Heartbleed disclosure, but many were published within hours by others (including myself). And this was a good thing, without them admins would be unable to verify that their servers were patched successfully.

1) It helps admins verify that the patch was successfully applied.

2) It gives security researchers more surface area to evaluate when looking for similar bugs or bugs in the patch.

3) A PoC not existing provides a false sense of security. Just because one is not published does not prevent attackers from creating and using an exploit (in many cases before the vulnerability is disclosed).

Yes, and my argument is that providing a working PoC along with a patch has at least these immediate benefits:

1) It helps admins verify that the patch was successfully applied.

2) It gives security researchers more surface area to evaluate when looking for similar bugs or bugs in the patch.

I'm not asserting that there are not negative aspects, but in the majority of cases waiting for some indeterminate time before releasing a PoC or not releasing one at all is net negative.

Working exploits are useful to test and iterate on to ensure that everything is patched correctly (both for admins and researchers).

/r/netsec has some good discussion: https://www.reddit.com/r/netsec/comments/3ed4fu/cve20153245_...

Here's the actual paper: http://dspace.mit.edu/bitstream/handle/1721.1/97690/MIT-CSAI...

GoGo is quite aggressive about variable pricing. An all-day pass is $16 if you buy it ahead of time, but if you buy it on the plane it can cost up to $50. They also do split testing of their prices and discriminate based on the user agent.

The cryptosystem behind it is called The Update Framework[0], and provides a lot more flexibility and protection than PGP (on top of using modern crypto).

[0] http://theupdateframework.com/

I've also seen iMessage talk to services hosted on Azure at various points.

The fingerprints are included in the bugzilla ticket and the CRLs are signed with the certificates, so TLS doesn't technically add anything as long as you confirm the fingerprints (though it doesn't hurt anything either).

OneRNG is basically the same thing, except it's open hardware: http://onerng.info/

Yeah, that's generally what "vendoring" means.

We currently use godep, and it breaks very easily due to tags and differing architectures and OSes (among other things). In addition to being unreliable, it's pretty slow. I'm not aware of any other tools that do import rewriting+vendoring and work better than godep.

Vendoring works great for us, we keep everything in one big repo and it's open source. The problem is that the current tooling for managing this is horrible.

They explain use cases for testing without HTTPS, but make it clear that TLS is required for production use.