Make buffer limits configurable about s2n-tls HOT 5 CLOSED

@BigBoneDaddy I have to admit, that I wouldn't generate such a big key again. But one of my servers has such a key (was just starting with SSL and I thought a larger-than-default key couldn't harm anyone) and I don't want to pay for a new certificate. So yes, in my case it was an accident cause by not knowing better.

I always dislike static buffers like these, since I ran into hard-to-debug problems on Apple-platforms (which won't even give you a meaningful error message, so I debugged this some days ...). I think a #define would be good, and a default of 4096bit is fine. Just give the users a way to simply change it.

I didn't mean to dynamically configure it, but to determine the size of the key from the actual key data:

Something else: I may had a brainfart. The source-line I linked to in the first comment isn't used to store the key, right? m(

from s2n-tls.

unsigned char intermediate[4096];

Correct me if I'm wrong but a char is 1 Byte. There are 8 Bits in 1 Byte so this buffer is 4096*8. Which is 32768 Bit. Meaning this supports 32768 Bit keys which is much larger than 4096 and 8192 Bit keys.

if (s2n_rsa_private_encrypted_size(key) > sizeof(intermediate)) {

s2n_rsa_private_encrypted_size() just calls RSA_size() which is documented to return the modulus size in Bytes not Bits ... so the check is right.

Could the author have been trying to limit to 4096 Bit key maximum? I hope not.

Also, this buffer really should be malloc'd (and configurable) because using large stack buffers like that could lead to other problems on embedded systems.

from s2n-tls.

I had a lot of brainfarts when I wrote this ticket ... I would suggest to just close it and forget about it ... anyone against it?

from s2n-tls.

It would be nice to not have such a large stack buffer. It would also be
nice to determine if the intention was to limit to 4096 bit keys.

On Wednesday, July 1, 2015, Moritz Grosch (LittleFox) <
[email protected]> wrote:

I had a lot of brainfarts when I wrote this ticket ... I would suggest to
just close it and forget about it ... anyone against it?

—
Reply to this email directly or view it on GitHub
#105 (comment).

from s2n-tls.

Closing. 4096 bytes allows up to 32768 bit RSA Keys. We may be wasting some memory, but we still allow very large size keys.

from s2n-tls.