Hacker News Reader

Comment by yuvipanda | Hacker News Reader

Awesome! I've used https://www.gnu.org/software/libmicrohttpd/ in the past (for fun stuff I was building to learn C), will try this out instead. But..

> Only HTTPS connections allowed

Seems a bit painful. HTTPS on the webserver itself is a fair bit more painful to setup and administer than HTTPS in your reverse proxy / loadbalancer (I prefer nginx). Web servers should support plain HTTP.

View on HN

You can turn off TLS on Kore.

$ make BENCHMARK=1

It is not a run time option by design, but it is there.

I want Kore to have sane defaults for getting up and running. That means TLS (1.2 default by only), no RSA based key exchanges, AEAD ciphers preferred and the likes.

edit: spelling

RSA with DHE or ECDHE is a sane handshake. I would avoid DSA and ECDSA based key exchanges because they fail catastrophically with bad random number generators. For most APIs session caching is more important than a faster initial handshake.

The HTTPS only choice would annoy me a lot because I run most HTTPS services in behind a reverse proxy in a FreeBSD jail on the same host. HA proxy and nginx are still superior to most applications in regard to reliable TLS termination.

Using HTTPS by default a the right choice for a new project but offering no HTTP support (outside of a benchmark) patronizes the user.

All in all this looks like a nice way to export C APIs through HTTPS.

Thanks.

I agree the BENCHMARK build option is a bit confusing. I might end up renaming it altogether.

For sanity sake, this build option is now NOTLS.

Everytime something like this comes out, I think the following : Wouldn't it be great if I could develop and debug this under Windows with VS and deploy my release with Linux. The network libraries are always Linux(and family) only.

I don't see a reason why you can't make it cross-platform, with a bit of effort: https://github.com/jorisvink/kore

I'm not trying to antagonize here, but what do you find so bad? I would call it a little bit more painful; three lines to add to an nginx config, along with generating the cert. Maybe 10 minutes of work? Thirty if you're getting a CA to sign your cert for you. I could see pain if you need to wait for finance to approve, or if you're trying to get domains validated on behalf of a customer. And I suppose it adds another setup step to wireshark (if you need to debug neat bugs), but that's a set-it-up-once-and-forget-about-it thing.

It's a scalability problem.

If you have many web servers behind a reverse proxy that takes care of TLS it's often pointless to waste processing power on encryption in between.

Yep. And on top of that a reverse proxy is unable to inspect the requests to route them smartly (based on path, cookies, etc.).

Well, the reverse proxy would have made the backend request itself, so it's free to inspect or modify anything.

Reply on news.ycombinator.com