Hacker News Reader

Comment by eastdakota | Hacker News Reader

You can read more about the CloudFlare Challenge and our own tests on obtaining SSL Private Key material here:

http://blog.cloudflare.com/answering-the-critical-question-c...

Matthew Prince Co-founder & CEO, CloudFlare

Thanks. This makes a lot of sense, and matches what I saw myself. I never got anything out of nginx, but I found apache quite easy. I never built more than a POC, and left it at that.

I didn't think about it at the time, but it was only on a newly started apache instance.

Coupled with the fact the apache as a frontend tls server is pretty rare on big sites nowadays, I'm feeling pretty good about what did happen, vs what could have happened.

It seems like a "feature" that you'd want your process to store the private key material as low as possible in the address space so that arbitrary read overruns don't run the risk of hitting it. It seems to just accidentally be this way in nginx, but I wonder if it should just be another (tiny) layer in the overall security design.

Shouldn't they be at the top of the address space then overruns would never hit them as they'd start below or does it not work like that.

Or you can put in a memory area with unmapped sections on both sides if you are paranoid.

IIRC openbsd's malloc does something like that by default, so every bit of data gets its own protected address space... and then the openssl guys built their own malloc without that feature, to get better performance :(

True.. I wonder if any specs/certifications actually require something like that. Typically I mostly use tricks like that to track down bugs, but there's nothing wrong with using it in production for something like a single key/cert alloc. It becomes a bit unwieldy if you have lots of things to protect. (Especially on machines with 64k pages :))

Well it seems like Akamai were doing exactly that. If you have lots I would go multi process though.

Someone else who uses Powerpc?

The bug is reading 64k from x -> x+64k. You'd want the key as low as possible in memory so the chance of the heap implementation allocating a request below it (thus allowing the +64k to overlap into the key) is next to nil.

So if your key was at an address less than x the bug would never read it, was my point. So I guess that means you'd have to force the UDP datagram payload to be stored high as that dictates what x is?

nice write up. we saw similar results in that the keying material never made it into the memory leaked.

i've never felt so thankful for a memory allocation pattern.

What is the format of the private key?

I.e., is it a 8192-bit AES256 key?

It's using RSA with key length of 2048 bits [1], and one can assume that both prime factors have equal bit length [2] i.e. 1024 bits each, and so the size of all the other private components can be derived from that. I don't know what OpenSSL's in-memory format is for this data, I suppose therein lies a good part of the challenge!

[1] https://www.ssllabs.com/ssltest/analyze.html?d=cloudflarecha...

[2] https://github.com/openssl/openssl/blob/master/crypto/rsa/rs...

Deleted comment

The don't sign comments rule is designed to stop pointless posting of company URLs when there is no need to. In this case it is clearly appropriate for Matthew to disclose who he is as it is important to the context of the post.

Reply on news.ycombinator.com