Live data from Hacker News

Nginx doesn't suck at SSL after all

matt.io

81–90 of 112 posts

Re: Nginx doesn't suck at SSL after all

#81
post #68

From the article, to find out what your website is doing: openssl s_client -host HOSTNAME -port 443 I ran this for my own website and a few bigger websites openssl s_client -host www.gusta.com -port 443 (My site, hosted on Heroku) Cipher : DHE-RSA-AES256-SHA openssl s_client -host www.google.com -port 443 Cipher : RC4-SHA openssl s_client -host www.airbnb.com -port 443 Cipher : AES256-SHA openssl s_client -host www.f…

Presumably Amazon, Facebook and Google are using RC4 for speed reasons, though it's not really thought to be secure anymore.

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 .

Re: Nginx doesn't suck at SSL after all

#82
post #68

Earlier quoted context omitted.

Presumably Amazon, Facebook and Google are using RC4 for speed reasons, though it's not really thought to be secure anymore.

Is that so? openssl s_client -host online.citibank.com -port 443 Cipher : RC4-MD5 openssl s_client -host www.bankofamerica.com -port 443 Cipher : RC4-MD5

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.

Re: Nginx doesn't suck at SSL after all

#83
I use a similar directive in my apache2 configuration. Would I see an performance improvement in removing the DH option from the cipher suite? Or is this only directly related to ngix and how it implements its ssl protocol?

Secondly, by removing the DH method do I restrict any browsers from connecting my site? Ie, are their any browsers, or security settings on browsers that prevent the site from being trusted if DH isn't available?

Re: Nginx doesn't suck at SSL after all

#84

I use a similar directive in my apache2 configuration. Would I see an performance improvement in removing the DH option from the cipher suite? Or is this only directly related to ngix and how it implements its ssl protocol? Secondly, by removing the DH method do I restrict any browsers from connecting my site? Ie, are their any browsers, or security settings on browsers that prevent the site from being trusted if DH…

It's an openssl configuration option, so it does affect performance for Apache with mod_ssl. It's not specific to nginx.

If you do not allow DH ciphers, you'll probably just lose users who deliberately configure their software to use only strong ciphers.

What you can do is put DH ciphers at the end of the list. That way, weaker ciphers are preferred but you're still supporting strong ciphers.

Re: Nginx doesn't suck at SSL after all

#85
post #63

Earlier quoted context omitted.

Oh. You're forum trolling. You know what though, it's always great to see you Ben. Thanks for taking the time.

Correct, disagreeing with you implies trolling. You are one astute dude, Tom. Keep up the good work!

I think that grasping at straws imply you're trolling, not disagreeing with someone else, although more than disagreeing with Tom it just seems like you're complaining...

I agree that both articles have different degrees of technical completeness, but really getting snarky because you believe that someone doesn't have the 'stripes' to write an article that ultimately agrees with the former article you're comparing it to seems to me like a waste of time. Specially since both articles basically come to the same conclusion. It gets worse when you pull two quotes from tptacek that ultimately don't change neither what he said in the beginning nor the reason he's responding to your posts.

Re: Nginx doesn't suck at SSL after all

#86
post #40
post #35

Earlier quoted context omitted.

I'm not calling you wrong (I readily admit my knowledge on this topic doesn't even compare to yours), but are you really saying that these banks hire security experts to set requirements for SSL configurations on their load balancers and then don't use these security experts to set requirements for password security? That seems borderline malicious on their part.

The security team at a bank is lucky if they even have a list of all the applications in use across the enterprise. There are bound to be hundreds. When those apps have ridiculous password policies, it's not because a developer simply decided "this is the right kind of password policy for our app", so that a security person could just say "uh, no". No, the restrictions are set up that way because the app is build bad…

[deleted]

Re: Nginx doesn't suck at SSL after all

#87
post #48
post #40

Earlier quoted context omitted.

The security team at a bank is lucky if they even have a list of all the applications in use across the enterprise. There are bound to be hundreds. When those apps have ridiculous password policies, it's not because a developer simply decided "this is the right kind of password policy for our app", so that a security person could just say "uh, no". No, the restrictions are set up that way because the app is build bad…

Interesting. If financial institutions routinely succeed at operational security but catastrophically fail at having a secure development life-cycle, is that a startup opportunity?

[deleted]

Re: Nginx doesn't suck at SSL after all

#88
post #40
post #35

Earlier quoted context omitted.

I'm not calling you wrong (I readily admit my knowledge on this topic doesn't even compare to yours), but are you really saying that these banks hire security experts to set requirements for SSL configurations on their load balancers and then don't use these security experts to set requirements for password security? That seems borderline malicious on their part.

The security team at a bank is lucky if they even have a list of all the applications in use across the enterprise. There are bound to be hundreds. When those apps have ridiculous password policies, it's not because a developer simply decided "this is the right kind of password policy for our app", so that a security person could just say "uh, no". No, the restrictions are set up that way because the app is build bad…

Anecdote in support of your point: I was a developer who sinned in the creation of a terrible password storage system on an internal web-app that had about 50 users (why didn't I just use LDAP???). It was at a Fortune 500 financial. I was fresh out of college. The company had a large security organization in-house and very clearly documented software best-practices but I was cowboy coding on an Infrastructure team. I was the stereotypically bad programmer at a large company who makes grievous security errors. I'm not even very comfortable making this confession but I believe I've learned a lot since then.

Re: Nginx doesn't suck at SSL after all

#90
post #71

Earlier quoted context omitted.

> "My initial testing, which needs to be investigated > further, is showing Nginx SSL performance lower than > other alternatives." You keep using that word ('headline'), but I do not think it means what you think it means.

Okay, I'll bite. Here you go: "Initial Tests Show Slow Nginx SSL Performance" Wasn't that hard, was it?

My point was that you seemed to have purposely made that 'headline' that you thought he should have used needlessly verbose, to the point where it couldn't be considered a headline.
Post reply on HN