Nginx sucks at SSL, here's what to do instead

Re:Nginx sucks at SSL, here's what to do instead by tptacek on Monday July 11, 2011 @04:20PM (#2752338)

I don't know what the limits are in the nginx HTTP parser Matt's using, so this is probably moot, but code that does things like "realloc(ptr, size + newsz)" or "malloc(size + 1)" expecting things to be fine gives me the howling fantods.

[ Parent | on HN ]

Re:Nginx sucks at SSL, here's what to do instead by seiji on Monday July 11, 2011 @06:21PM (#2752732)

I don't know what the limits are in the nginx HTTP parser

You're correct in assuming the library enforces its own size limitations. It operates on length of received SSL data which is capped by the static receive buffer at 32k. Nice and tiny.

(Also, you are, of course, painfully correct about lack of bounds checking and lack of return value checking on the malloc/realloc calls. If I ever graduate the branch to production status, the six malloc calls and three realloc calls will be wrapped in proper checks.)

[ Parent | on HN ]

Re:Nginx sucks at SSL, here's what to do instead by tptacek on Monday July 11, 2011 @07:00PM (#2752831)

For what it's worth, don't check the retval of malloc/realloc/strdup; instead, rig them so they blow up if the allocation fails.

[ Parent | on HN ]

Re:Nginx sucks at SSL, here's what to do instead by oconnore on Monday July 11, 2011 @08:22PM (#2753047)

Why? Can't you just bail on whatever you are currently doing? How is the entire process compromised by a failed malloc? Resources are limited, sort of by definition, shouldn't good code be able to handle this possibility?

[ Parent | on HN ]

Re:Nginx sucks at SSL, here's what to do instead by tptacek on Monday July 11, 2011 @10:01PM (#2753239)

If malloc is rigged to explode when it fails, you can't accidentally forget to check; sometimes, malloc failures can end up being exploitable. It's not like most code does anything particularly smart when memory runs out.

[ Parent | on HN ]

Re:Nginx sucks at SSL, here's what to do instead by neilc on Tuesday July 12, 2011 @02:14AM (#2753744)

An exception to this is library code, which should typically check for malloc failures and return an error to the client code.

[ Parent | on HN ]

Re:Nginx sucks at SSL, here's what to do instead by EdiX on Tuesday July 12, 2011 @05:10AM (#2754096)

Handling an out of memory error in any way other than terminating the entire process is very very hard, because the effects of memory exhaustion are felt by all your threads at the same time usually preceded by massive slowdown due to swapping (which will cause other symptoms if there is any real time constraints put on the process).

I'm not saying there are no cases where recovering from allocation errors would be possible but it's not the general case. It's usually easier to treat any allocation error as a fatal error and insure your programs so they don't run out of memory through other means.

[ Parent | on HN ]

Re:Nginx sucks at SSL, here's what to do instead by __rkaup__ on Monday July 11, 2011 @04:29PM (#2752378)

I'm quite new to C programming. What's wrong with doing those things?

[ Parent | on HN ]

Re:Nginx sucks at SSL, here's what to do instead by tptacek on Monday July 11, 2011 @04:32PM (#2752394)

Numbers can't grow indefinitely; they wrap (usually at the size of the register).

[ Parent | on HN ]

Re:Nginx sucks at SSL, here's what to do instead by fleitz on Monday July 11, 2011 @04:35PM (#2752410)

"malloc(size+1)" is a sign you may have one off errors in your code. If you need to store a string of size s you need s+1 bytes allocated. The plus one is for null termination. If you want an array of t you can either pass the size around with the array or null terminate the array like strings, but then you can't store any null values in the array.

Also, there's no bounds checking on size so in certain conditions such as a 2GB/4GB allocation you may allocate zero bytes or -2GB bytes.

[ Parent | on HN ]