HN user
Lattice is a more minimalist approach, for those who desire the production hardened core of Cloud Foundry but prefer to bring their own PaaS components or simply experiment.
I make complete AMIs with packer, configure them entirely using environment variables in userdata, configuration data in etcd, and shell scripts, and run all services in docker containers, which I also build using packer. With all services in containers, AMIs are almost never rebuilt and there is no need for configuration management/mutating infrastructure.
Building containers with packer is easier than switching to Dockerfiles for existing builds, but does not support fast, incremental build and deploy or tagging. Even without those features, I see no advantages in traditional CM other than the convenience of familiarity and legacy.
Another possible explanation is that she is intelligent and motivated and you are an asshole.
I made a shirt for all you guys who think the rape, erm, PICK UP ARTISTE, book is totes cool and nbd http://www.cafepress.com/mf/79293678/i-am-rape-culture_tshir...
NIST has weighed in on how to use TLS: http://tools.ietf.org/html/rfc6460
I am not aware of any proposed attacks on the approved cipher suites that are anywhere near feasible. TLS deployment is far behind known best practice. We should do something about that.
They've known for some time http://dictionary.reference.com/browse/ism .
That you are unable to distinguish between an instance of sexual discrimination (called sexual discrimination) and systemic sexual discrimination (called sexism) does not mean anything political or Orwellian is afoot. Words have meanings. Ignorance of the meanings of words is easily solved. Stubborn refusal to recognize your own errors is rather less so.
Asserting all members of a group of people are subhuman sure does sound like something that happened in Europe in the 30s and 40s. What point were you trying to make?
Immanentize your personal eschaton,
Lil 'B
Seems like a lot of folks missed the section of the post explaining their implementation and use of _ECDHE_ not _EDH_. The performance impact of ECDHE is surprisingly small.
Correct!
More great work from Google legitimizing and advocating for strong HTTPS defaults. I'm looking forward to this being broadly adopted.
Securely Yours,
Lil' B
We have no plans to support Thrift.
Much like our engineers, our software is extremely opinionated. Ordasity, Scalang, and Overlock are all small, extremely focused libraries to solve a single problem in a single way. This is quite similar to the Unix philosophy and we have found it to be similarly successful. Projects like Akka take a more maximalist, all-encompassing approach that doesn't work well for the way we build and operate services.
One love,
Lil' B
Well said, sir.
What does he charge to just shut up already?
The formatting tool in question defaults to _not_ doing this, specifically to comply with the Scala Style Guide which does _not_ do this. The tool had to be explicitly configured to make this unfortunate change.
You've got it backwards: I haven't seen anyone, including Chas, argue for disallowing Unicode. As you say, replacing a simple, common, 2 character operator with the unusual Unicode version is an odd and inconvenient decision. At present, this is Akka-specific, though the line between Scala and Akka seems to be blurring like Erlang and OTP.
Ask and ye shall receive: https://github.com/bumptech/stud/pull/6
stunnel DH code inserted into stud.
Banks are unfortunately poster children for what not to do in this space, generally. The default cipher for google.com is RC4-SHA, and I can, if so inclined, force negotiation of AES-based ciphers by client config. Not so with Citibank (RC4-MD5, DES-CBC3-SHA, or DES-CBC-SHA) & BofA is only marginally better (RC4-MD5, RC4-SHA, AES128-SHA). To their credit, they are using 2048 bit RSA keys with short lifetimes and they have significantly improved their configurations from a couple of years ago when single DES defaults and 40-bit RC4 were all too common.
While I would certainly prefer to see the major players leading the way in adoption of AES by default, RC4-MD5 persists for at least 2 reasons:
1) Habit
2) As implemented/deployed in SSL, it still provides some security
RC4 has gotten a bad reputation in large part because of its poor application in WEP that resulted in keys being rapidly recovered by sniffing traffic. The Wikipedia entry is a good place to start http://en.wikipedia.org/wiki/RC4#Security (& numerous references for the original papers/pubs cracking various bits of RC4). The RSA response to RC4 concerns (from WEP) is worth reading, as well http://www.rsa.com/rsalabs/node.asp?id=2009 .
I am recommending that people who do not understand the trade-offs and do not have the traffic for it to matter should probably leave those safe defaults alone. What the banks choose to do is unfortunate, but should not dictate behavior. If all the banks chose to jump off a bridge, etc.
Recommending people unfamiliar with configuring SSL leave defaults alone is only incompatible with our having non-default config if you are implying I don't understand configuring SSL. I doubt that is what you mean, as I am ever the optimist.
Yay!,
Lil' B
Correct, disagreeing with you implies trolling. You are one astute dude, Tom. Keep up the good work!
On a related topic, these are both your comments on this post:
"The win here is that losing the RSA key now only allows you to MITM future SSL/TLS connections. This is still a disaster, but it does not allow you to retroactively unwind previous DH exchanges and decrypt earlier captured sessions."
"If you've lost your RSA key, you are well and truly fucked."
Thanks for clearing that up!
Make love not war,
Lil' B
Adam's post is rather more thorough and nuanced, which makes sense since he actually understands SSL and benchmarking. While you might summarize them both as "DHE is expensive", I don't know why you would. Here is each post on DHE:
Adam - "However, with a pure RSA ciphersuite, an attacker can record traffic, crack (or steal) your private key at will and decrypt the traffic retrospectively, so consider your needs."
Matt - "Unfortunately, it also includes a very computationally intensive cipher using an ephemeral Diffie-Hellman exchange for PFS. Sounds scary already, doesn't it? ... The problem cipher is DHE-RSA-AES256-SHA [b]."
The first is factual and straightforward. The second is muddled and clearly skewed towards blindly disabling DHE. I believe we are in agreement that it is irrelevant to almost everyone building on nginx: their connection rates are so low they will not notice the overhead introduced by DHE.
I am sniping at enthusiastic ignorance and encouraging others to behave similarly. I hope that is all quite clear now.
Hugs and kisses, Lil' B
An article about configuring SSL that doesn't 1) discuss trade-offs of security vs. resource consumption, 2) how to figure out your performance requirements, and 3) indicate the author really understands implications of decisions about crypto is an article you should probably disregard. Modern CPUs are so ridiculously good at crypto, and most sites have such ridiculously low connection rates, that optimizing for maximum performance at the expense of security is a fool's game in most cases. Instead, focus on measuring your real performance requirements first, and things like sane configuration of SSL, for example by explicitly listing ciphers instead of using the impenetrable +aNULL:-yourMom syntax.
Here's my vintage code for scanning SSL configs: https://github.com/b/tlscollect
Here are a couple of must read posts from someone who really knows his SSL business:
http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht...
http://www.imperialviolet.org/2011/02/06/stillinexpensive.ht...
It's great to learn.
Lil' B
POST to /add to create a resource? Strange, redundant, and the sort of thing I thought died with old versions of Rails. Riak/Webmachine and CouchDB get this right. Because knowledge is power, here is the section on methods in the HTTP 1.1 spec http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1... . Sorry to inject facts into an otherwise opinion-based situation. If I've bummed you out, I apologize. Here's a laughing penguin to cheer you up http://www.youtube.com/watch?v=2Fbt1fVfi-g .
Worshipping at the altar of HATEOAS,
Lil' B
I am apparently in that foolish minority that believes language runtimes should not segfault/corrupt themselves while running correct code. That this problem requires significant effort just to hack around, while actually fixing it would take a major architectural change, is what elevates this from mere "lolwut?" to fatally flawed. There are good alternative runtimes for Ruby, such as the JVM and the CLR, that do not suffer from this problem. Y'all should use them.
Funktacularly yours,
Lil' B
I am running this code in production, hence it cannot have bugs. QED.
Yours in perpetual bogglement,
Lil' B
San Francisco, CA
Boundary is building a platform for real-time network operations, visualization, and exploration. We have exciting challenges in high-speed data collection, large-scale data processing, user experience, and interface design. We work with a variety of languages, including Scala, Erlang, C/C++, and Javascript. We're venture-backed and our small, talented team is growing fast. Our jobs page is at https://boundary.com/jobs or you can email us at jobs@boundary.com. If you are great at what you do and want to make a real impact, we'd love to hear from you!
Well, yes. Exactly.
Big ups to the Homo Sapiens posse.
- Lil' B