cscott

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.

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.

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

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.

Case in point: http://www.seattlepi.com/local/418746_video.html

Unless the state has a "stop and identify" statute on the books, you cannot be arrested for refusing to identify yourself.

24 states have such a statute. My new home state, California, has none.

Thanks for the feedback!

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?

Right you are, sir.

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).

Talk about contributing to the public health problem in our ERs.

Emergency medicine in the US is in a horrible state. Overcrowding is one of the primary reasons. See: http://www.ama-assn.org/amednews/2009/01/19/prsb0119.htm

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.

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.

Great story, and my favorite part was the link to the Slashdot iPod release story: "No wireless. Less space than a nomad. Lame."

Agreed. I don't think there was any intentional deception either.

However, don't forget the influence of the lobbyists hired by the security industry. Additionally, "non-profit" organizations involved with information security that see a potential cybersecurity boom as beneficial to their membership and influence in the field.

Executive orders to impacted entities would involve a much more formal chain of command and control than a direct kill switch from White House.

There is a significant momentum building for stronger executive control over Internet connectivity to private-sector networks that are designated as "critical infrastructure."

The proposed CyberSecurity Act of 2009 would allow the president to designate a private network (such as a SCADA system) as critical, and in the case of a declared emergency, shut it off from the Internet.

As you can imagine, there is resistance to this from multiple parties, including those industries who fear additional government regulation and also privacy and anti-censorship advocates who fear "scope creep" in the legislation.

The key point of the article:

"What's much more likely is that the Web, through its links, and Google, through its search algorithms, have inadvertently set into motion a very strong feedback loop that amplifies popularity and, in the end, leads us all, lemminglike, down the same well-trod path - the path of least resistance."

I couldn't agree more. I hope that a good number of HN readers are working on the next disruptive force rather than continuing to prop up the status quo.

Here's the info on the compromised support tools:

http://blog.twitter.com/2009/01/monday-morning-madness.html

Yes, they're taking a page out of Microsoft's playbook by using a blog post to respond in more detail to a security vulnerability. When executed well, it mollifies critics much better than the press release style of communication due to its appearance of informality.

That being said, I would have liked for them to say that they've reviewed their logs and saw no other issuance activity that followed the same pattern as the researchers, and that they will improve their operational monitoring and serial number sequencing to help protect against future potential attacks.

If you accept credit card payment without SSL protecting the entry of the card and CVV2, you are in violation of PCI DSS standard 4.1. Depending on your relationship with your acquiring bank or payment processor, that will result in a passthrough of fines and any fraudulent charges that are incurred, along with possible termination of your account.

Now, for the research on SSL and UI, there is good research on this. My favorite is The Emperor's New Security Indicators - http://www.usablesecurity.org/emperor/

"We confirm prior findings that users ignore HTTPS indicators: no participants withheld their passwords when these indicators were removed. We present the first empirical investigation of site-authentication images, and we find them to be ineffective: even when we removed them, 92% participants who used their own accounts entered their passwords. We also contribute the first empirical evidence that role playing affects participants' security behavior: role-playing participants behaved significantly less securely than those using their own passwords."

What's slightly ironic is trust doesn't matter for the buyer.

As long as you purchase your certificate from a CA well placed in the major browser vendors, you're good to go.

Edit: Here's a list of Mozilla's included certificates: http://www.mozilla.org/projects/security/certs/included/

I'm surprised and a bit skeptical that every CA (except for one) randomizes serial numbers without it being published in a standard or guidance document somewhere. Best practice usually has something worse than a (n - 1) distribution.

RapidSSL is owned by GeoTrust, which is owned by Verisign.

You can read all about GeoTrust's certificate practices here: http://www.geotrust.com/resources/cps/pdfs/GeoTrustCPS-Versi...

The results of their KPMG audit here: https://cert.webtrust.org/SealFile?seal=650&file=pdf

And their entry into Mozilla here: https://bugzilla.mozilla.org/show_bug.cgi?id=409236

If you want to be a CA, you need to get Microsoft and Mozilla (among others) to include you in their list. I can't find Microsoft's policy, but Mozilla's CA Certificate Policy is here: http://www.mozilla.org/projects/security/certs/policy/

There are operational requirements and management attestations that must be made such as "WebTrust Principles and Criteria for Certification Authorities".

And this isn't even the first blog post to mention the fact that a CA gave out a cert to unauthorized person...

Mike Zusman tested a group of CA issuers and received a cert for Microsoft's live.com and talked about it at Blackhat this year: http://schmoil.blogspot.com/2008/08/domain-validated-ssl-cer...

Additional information at: http://www.law.com/jsp/legaltechnology/pubArticleLT.jsp?id=1...

Agreed. However, wouldn't an operational review of certificate issuance activity of the impacted CAs provide another level of assurance that the researchers were the only ones who successfully exploited this vulnerability? I would imagine their activity (when inspected as a series of requests) would look rather anomalous.

If all 6 impacted CAs stop signing MD5 signed certs today and no new CAs started, is the risk reduced to the possibility of prior discovery?

There's an excellent article in the Harvard Business Review that breaks down the relationship between IT and the business depending on two factors: the reliability of IT and the need for IT innovation in the line of business.

The result is that you can lump the relationship of IT and the business into 4 categories:

Defensive: Factory Mode (High Reliability Need, Low Innovation Need) Defensive: Support Mode (Low Reliability Need, Low Innovation Need) Offensive: Strategic Mode (High Reliability Need, High Innovation Need) Offensive: Turnaround Mode (Low Reliability Need, High Innovation Need)

If the blog poster worked for a company in the defensive mode categories, his approach would definitely not be welcome in most cases, unless he had a major reliability argument.

Hopefully, he found a position in a company aligned with the Offensive side of the quadrants.

The article I mentioned is Nolan & McFarlen, "Information Technology and the Board of Directors", Harvard Business Review, Oct 2005.

We've implemented plain old MediaWiki in our division. It serves as a document and guidance distribution point to the wider corporate public, as well as an scratch pad for internal procedures and process. Due to the general lack of fine-grained access control and segmentation, we stood up two instances: one for the "public" site without authentication for read-only access (and mediawiki accounts for division members only to edit content) and another one for the "private" site with HTTP authentication for the wiki root.

The framework is nice, but the two recipes I tried from the site turned out horribly. Willing to accept that I'm an average cook - but the results from similar "standard" recipes were much better.