It comes down to intent. There are two distinct ways to evaluate Akamai's patch:
1. Did Akamai release the PoC patch to start a discussion about how to protect private keys and share their work as a starting point for changing the code? If so, their efforts here should be considered in that vein and any criticism should be used simply to guide the development of a usable and functional patch.
2. On the other hand, if they are supplying this code as assurance that customer keys were properly protected against exposure by the Heartbleed bug and that certificate replacement is not needed, the patch and the subsequent criticism should give Akamai customers pause.
It was released as both: we thought that our old protection against swap protected us against Heartbleed. What a stroke of luck. We did check for key values visible in the heap, and on our implementation, in our lab, didn't find them on any version of our software used since we took OpenSSL 1.0.1.
We weren't looking for the CRT values.
As one part of our response, we decided to publish the code we thought was keeping us safe. If we were right, sure, there's good PR from that. If we were wrong, it's a chance to find out and get right. Less wrong, anyway.
Decisions were made about certificate revocation based on assumptions about this code and Akamai customers ended up being exposed.
Perhaps third-party security validation of such a critical piece of code should be a prerequisite before asserting that no further countermeasures such as key rotation were necessary. Such an action would demonstrate significant diligence as compared to a public release days after you've told customers there was nothing to worry about.
Additionally, that public release didn't directly encourage security review, the deprecating comments on the post were primarily around portability and design.
Even if their intent was just to start a discussion, they are not being helpful by "submitting" such bogus code. It would be easier for an expert to rewrite this patch from scratch than try to figure out all of their flaws and unfinished sections.
In one of the email responses, someone pointed out a problem with their code and they responded, "Oops we posted the wrong version" ( http://article.gmane.org/gmane.comp.encryption.openssl.user/... ). They aren't exactly being respectful of other people's time with stuff like that.
In secure coding the phrase "the devil is in the details" applies very strongly. So if you don't have the details figured out, you don't have much of anything.
> Even if their intent was just to start a discussion, they are not being helpful by "submitting" such bogus code.
All code is bogus code until reviewed. That is absolutely central to understand. Linus's Law only works _if_ people are looking at the code. Implicitly thumbs-upping it doesn't solve problems.
Akamai submitted the code, people reviewed it and found flaws. They're taking action to fix their own code, and the community is coming up with various fixes of their own. That's how Open Source Software Development should work.
While I agree with you that it'd probably be better to rewrite the code with a similar approach, it's also important to note that nobody in the OpenSSL community even considered this approach publicly until Akamai published their code.
Any claims they're being disrespectful of people's time is specious - they said from the beginning that this code needed review and shouldn't be merged. This is just one of those issues that comes out in the wash of code review.
TL;DR: Akamai should be lauded on their intentions but like noted by everyone, the code wasn't good enough. Now, with proper review and rewrites, they will be able to protect their customers into the future, and maybe OpenSSL will become a slightly better product for it too.
It's a smokescreen. If you were running a version of OpenSSL that supported the HEARTBEAT extension (patched or not) it's easy enough to determine whether or not it was vulnerable, simply by running the exploit code. Any theoretical discussion of how your patch made it invulnerable is pure speculation. They can release packet captures that prove they were invulnerable without releasing any code at all. At this stage, it's all PR.
No doubt. Those who do not follow police officer instructions to produce identification, even in states without "stop and identify" statutes, will find themselves risking an obstruction charge. It may be dropped at the state/city attorney's discretion later, but it will create a very unpleasant period of time.
I was a Canadian living in Seattle for a while, and I was asked to produce ID by a cop in my apartment complex. I politely asked if I was required to, he said no and asked politely again but that was the end of it.
I find if you clearly & politely ask what you are legally required to do, most cops will honestly tell you.
The assumption is that you should consider your source code open and exposed to inspection by an attacker, not that it has been compromised. As a result, if any security control is dependent on "secret" functions or embedded keys in your source, the threat actor is going to know about them and will attempt to use them against you.
As a result, the test plan will need to take that into account.
I'm concerned about the lack of revocation that comes with bundling a key in source. Shouldn't you warn people in your note that if the key is compromised, you're going to have a difficult time?
You should already have a mechanism in place for alerting people to vulnerabilities in your client code -- for all practical purposes, a compromised server key is just a vulnerability in the client code which needs to be corrected by upgrading to a newer version of the client.
This is simply a re-application of device fingerprinting and voice verification that many banks are using to secure online banking.
There are many things that can go wrong here, based on my previous experience dealing with these systems, but most require client-side subversion, whether it is malware, cross-site scripting, or cross-site request forgery. (For example, finding a CSRF vuln that allows you to update the phone number to your own and compelling your victim to visit the link through a variety of techniques.)
As a hiring manager, my experience has been the opposite.
When hiring staff members that need to be able to write documents as part of the job and explain things clearly, the cover letter can make a significant difference. Most good candidates do write ones specific to your company. A generic cover letter is an extension of the resume (at best) and often an indicator of a lack of interest (at worst).
One of the primary reasons for the large influx of patients is the diversion of primary care visits into the ER for non-urgent matters. A booking system that encourages non-urgent care visits to the ER as opposed to other urgent care options does nothing to help this.
As other commenters have mentioned, the problem with overcrowded ERs from a patient perspective where they have a potentially emergent case is NOT in the middle of the night - it's during the day, where other options (including primary care and urgent care facilities) are available.
Emergency medicine should not be treated in the same convenience form-factor as other consumable goods, and applying this approach is socially irresponsible in the big picture.
Your argument is that on-site ER wait times are an effective deterrant for frivolous ER visits. They aren't: they impose costs on both legitimate and illegitimate visits. That cost is also imposed randomly: currently, your ER wait is luck-of-the-draw.
If you want to solve the ER overcrowding problem, you should do it directly, by adding a surcharge (over and above the one that already exists) for nonessential ER visits. There's no rational reason to force people to sit in a crowded ER waiting room.
Meanwhile, a retail interface to the ER scheduling systems that already exist is more likely to help than hurt overcrowding, because it will route patients to the least crowded ER in their area.
The problem with the surcharge idea (and lots of other market-oriented solutions to health care problems) is that, under our current system, market forces don't really apply in the same way that they apply to, say, items in the grocery store. Very few people going to an ER are paying out of pocket: many don't have insurance[1], and will either not pay for their visit or will negotiate some sort of payment plan at a reduced rate with the hospital. And, of course, those visitors with insurance don't care what the hospital ends up charging their insurance company- that's the whole point of insurance. This is, of course, especially true during emergency or urgent care situations.
[1] To the extent that emergency room overcrowding is due to people without other health care options (i.e., the un- and under-insured) using ERs as their primary care facilities, surcharges really won't help: by definition, these are people who can't pay for medical care... so adding additional surcharges probably won't have much effect on their ER utilization.
The people who are using the ER because they have no other option and who cannot pay out-of-pocket are not at all germane to this startup idea, which is part of my point.
There is no reason at all that our respective agendas about how US healthcare should be run should require me to wait on-site in the hospital, as opposed to in my home at 1AM, or in my hotel room when I get violently ill on a trip.
There will always be cases when people need to use the ER, and there will never be a good reason they shouldn't be able to call ahead for a soft appointment. Everything about the system, from patient routing to triage to hospital staffing, works better with a system like InQuickER in place.
Oh, I absolutely agree with the usefulness of InQuickER!
My argument was only with the idea of using surcharges to deal with overcrowding. The reason that ERs are chronically overcrowded is not (generally speaking) because of people getting ill on trips, being in car accidents, or having ear-infected kids. The reason that ERs are overcrowded is the large number of people for whom ERs serve as primary care facilities.
As you (correctly) pointed out, these people probably wouldn't be using InQuickER-like services anyway, so they're not relevant to the question of whether scheduling systems are helpful or not. I think that scheduling systems lke InQuickER definitely could be helpful to patients that use them, and maybe to the ERs themselves... but also that, depending on the specifics of a given ER's catchment area, they won't have much impact on overall crowded-ness, since that's largely due to a segment of the population that won't be using the scheduling system anyway.
Now, if one could find a way to make these people more likely to use the scheduling system, you might see more of an effect.
Of course, I could be completely wrong- IANDNAIHEOHQE (I am not a doctor nor am I a health economist or healthcare quality expert), and when it comes to health care quality interventions (which is what InQuickER basically is) it is not at all uncommon for things to behave in a counter-intuitive manner. That's why solid evaluation of system outcomes is so important. Hopefully the participating hospitals are keeping a close eye on their utilization statistics... for their sake, I hope that the InQuickER people are insisting on it- being able to show a significant change in in-ER waiting time due to their system would be the single best marketing tool that they could possibly hope for.
Adding to the list of things that I could be completely wrong about, my sense of who InQuickER's users are could be dead wrong. Tyler, what are your user demographics like? Do they mirror those of the hospitals that are using the system?
Employee performance reviews that enforce an arbitrary curve-based ranking or grading system often to do more harm than good.
I have seen employees who have performed well all year get demolished by a performance review where they were rated a "3" or "4" out of "5" because HR required only one "5" per department and two or three "4"s, and expect the majority of employees to be a "3". (Thankfully, they didn't require that each department designate a "1" goat.)
That being said, I have found that performance reviews that focus on how the employee has improved the business and seized opportunities (or not) and focus less on artificial competition are extremely beneficial.
+1 for mentioning the arbitrary curve-based ranking common in big companies.
Tightly coupling salary/bonuses to performance reviews with this type of system is a disaster.
Unfortunately, my experience is that most managers in such a system lack the insight to minimize the effect on employees. Maybe when you're talking about minimizing the effect of telling an employee they are (non-deservedly) one of the "3" performers, you've already lost the battle . . . Add in the inevitable weird corporate culture stuff "you are a '3' because you got promoted this year, it's just your turn in the box" and you have a perfect recipe for draining motivation away from employees.
1. Did Akamai release the PoC patch to start a discussion about how to protect private keys and share their work as a starting point for changing the code? If so, their efforts here should be considered in that vein and any criticism should be used simply to guide the development of a usable and functional patch.
2. On the other hand, if they are supplying this code as assurance that customer keys were properly protected against exposure by the Heartbleed bug and that certificate replacement is not needed, the patch and the subsequent criticism should give Akamai customers pause.
edit: Akamai acknowledges the bug, and has started rotating all customer SSL keys/certificates, per https://blogs.akamai.com/2014/04/heartbleed-update-v3.html