Hacker News new | comments | show | ask | jobs | submit login

Hidden amongst the frothing rant are some good considerations. Unfortunately most of the article is FUD. A couple points I'll mention,


The author states that distributing keys to a "farm" of servers (10 apparently) is hard. Presumably if you have 10 servers running your website you've figured out how to distribute code to them all without injuring yourself. Distributing certs is not much different.


The author states that SSL keys are sensitive. Indeed, and so is your source code. The paragraph contains some excellent FUD in the form of, a key on your "commodity hardware" server is immediately at risk of theft and will lead to "further breaches."


The author argues that SSL to the server introduces "unacceptable amounts of latency." This is just patently false. Many of the top 100 websites on the internet operate under this model.

The same paragraph says that not decrypting traffic at every hop will open up your service to "compromise." Even if parsing all the traffic is part of your threat mitigation strategy, out-of-band or port-mirroring can give you this ability without adding latency to the request or response.

Ah and I think the author should remove the bolded article that says Virtual Hosts can not be used with SSL certs. This is what the SNI extension is for.

Remember, security is hard and always a compromise.

There is a cost to installing security, particularly at the higher levels of FIPS certification. Let no one dispute that.

But I consider the idea of allowing your passwords to flow over the wire in plaintext and allowing other information to flow in plaintext to be quite ridiculous.

The author suggests a false dichotomy: 2048bit encryption (which algorithm? he doesn't say) or none.

There are a lot of complexities here that can be tuned for your business and its requirements. At least, if you can hire a competent security guy.

"There is a cost to installing security, particularly at the higher levels of FIPS certification. Let no one dispute that."

Completely agree. Which is why I say at the end of my original comment that security is "always a compromise." Put another way, you weigh the day-to-day cost of more hardware and man hours against the potential future cost of a serious security exposure.

Unfortunately most people are bad at calculating potential future costs. Which leads us to your second point about needing a good security guy. =]

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact