Comment by IgorPartola

11 years ago

Wow, of all the arguments I could think of against the current CA/TLS/HTTPS situation, a hobbyist deciding to write their own web server would not be one of them... Yes, you should just conform and stop doing this. Or at the very least you could let another process to TLS termination and just handle HTTP if you really want to create your own off-by-one remote code execution errors instead of using the ones supplied by apache et al.

> a hobbyist deciding to write their own web server would not be one of them

nginx started out as a hobby project by Igor Sysoev. Maybe he should have just used Apache too?

> Or at the very least you could let another process to TLS termination and just handle HTTP

A well-designed HTTPS->HTTP proxy package could work. Install proxy, and requests to it on 443 fetch localhost:80 (which you could firewall off externally if you wanted) and feed it back as HTTPS. Definitely not optimal, especially if it ends up eating a lot of RAM or limiting active connections, but it would be a quick-and-dirty method that would work for smaller sites.

But it won't handle other uses of TLS, such as if you wanted to use smtp.gmail.com, which requires STARTTLS. Or maybe you want to write an application that uses a new custom protocol, and want to encrypt that.

If you put this stuff into libc, and get it ISO standardized and simplified, and have it present out of the box with your compilers on each OS, then you'll open the door for developers to more easily take advantage of TLS encryption everywhere.

Look at the core API for GnuTLS: http://www.gnutls.org/manual/html_node/Core-TLS-API.html

This is just insane. It would take an average developer months to fully understand that API.

  • FWIW, Igor did code up nginx to support HTTPS, despite terrible SSL libraries :)

    I don't really understand the problem you are having. If your sites are small personal/side projects, why worry about things like your web server? That stuff is so trivial, it's boring. If your sites are so large that the overhead that HTTPS has over HTTP makes that much of a difference (pretty sure that'd be Google, Facebook, Twitter, and nobody else), then why use your own server implementation which you must know contains more bugs than something like nginx which is already blazing fast. All of these things are a solved problem, there is no reason to solve them again unless you are explicitly developing a web server, an email relay, etc. If so, that's awesome, but in 2014 if you develop a web server that doesn't work with HTTPS, it's pretty much dead on arrival.

    Having said that, check out http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/.... This sounds like exactly what you need.

    • > why worry about things like your web server?

      I want to do different things that haven't really been done before.

      I want to write my site in C++ instead of PHP. In my own case, it's not as much about speed (that's a free benefit), it's more about the language: I favor the strong typing, compile-time checking and stronger inheritance model. What I envision is that I have C++ source files. I upload one, the server sees there is no binary for that page, and invokes Clang to build it when the page is accessed, and caches the binary for future use. Once I upload the source again, and the modified timestamp is newer than the binary, it rebuilds the cached binary.

      I also have a lot of parsing built-in to the server itself to do things like Markdown/Stylus, but optimized for what I need (my syntax generates automatic anchors and TOCs for sections, great for documentation.)

      I also plan to code up a forum so that I don't have to run phpBB, and thus don't have to run PHP and Apache.

      I can also test my server on my local desktop without having to install PHP+Apache. I just open my server binary, and go to localhost in my browser.

      > in 2014 if you develop a web server that doesn't work with HTTPS, it's pretty much dead on arrival.

      Exactly! That's why I want to support TLS. Yet they've made that as difficult as is humanly possible, it seems.

      > This sounds like exactly what you need.

      Yes, libtls is exactly what I need, and mentioned before. Its limitations are that it's not available in my package manager, and hasn't had a lot of real-world testing yet (though I trust the OpenBSD team.)

      In 6-12 months once this is easily usable on Windows, OS X, Linux and FreeBSD, I'll definitely be giving it a shot.

      But isn't it sad that it's 2014 and a library with this level of simplicity only just came out 2-3 weeks ago?

      1 reply →