8 ms·

If you're stuck on a OpenSSL version without ALPN, and don't want to deal with upgrading OpenSSL (or rather statically linking your web server to a newer releas

by pfg 10y ago

If you're stuck on a OpenSSL version without ALPN, and don't want to deal with upgrading OpenSSL (or rather statically linking your web server to a newer release), consider using caddy[1]. It's a HTTP/2 web server written in Go, which comes with its own TLS library (crypto/tls) and thus doesn't have any dependency on OpenSSL. It even supports automatic deployment of a publicly-trusted certificate through Let's Encrypt. [1]: https://caddyserver.com/ https://caddyserver.com/

jmiserez 10y ago
So instead of upgrading a library or the webserver you'd rather replace the webserver completely with a relatively new [1] webserver and redo all the configuration? (edit: more positive wording) [1] https://news.ycombinator.com/item?id=9452606 https://news.ycombinator.com/item?id=9452606
- chris_wot 10y ago
  Am I reading the same post? When I read it, he seemed to say "might consider"...
  - deleted 10y ago
    [deleted]
- pfg 10y ago
  That post is more than a year old. Caddy has since had more than 70 contributors and > 1K commits. Based on my experience, replacing nginx (in my case acting as a fairly simple reverse proxy for rails) with Caddy wasn't significantly harder than compiling a custom nginx. If you have a complex configuration, YMMV. I'm definitely not suggesting using Caddy as a drop-in replacement for your existing production web server without further testing. That being said, getting rid of a OpenSSL dependency isn't a bad thing.
  - jmiserez 10y ago
    > Caddy has since had more than 70 contributors and > 1K commits. That is impressive, will definitely try it. Is there a list of companies using Caddy somewhere?
    - pfg 10y ago
      I haven't seen a list yet. A couple of Go community sites have started using it (for obvious reasons). Without having any particular insight, I'd guess the user base consists mostly of early adopters, Go developers and some side-projects right now.
deleted 10y ago
[deleted]
pfooti 10y ago
I'm not a golang user, but I am curious, how hardened is the crypto/tls library? One of the reasons I use openssl is because I don't want a DIY crypto layer, I want something a lot of people have banged on. I'd hate to move to a new server, just to find out it is susceptible to a whole new set of Ye Olde Underrun Bugges that openssl patched ages ago.
- pfg 10y ago
  This was discussed on HN a couple of months ago[1] when Go fixed a carry propagation bug that affected crypto/tls. [1]: https://news.ycombinator.com/item?id=10897511 https://news.ycombinator.com/item?id=10897511
- Matt3o12_ 10y ago
  It is maintained by Google and the whole go community since it is in the standard library. So, I think it is fairly secure (probably not as well tested as OpenSSL but the attack surface is smaller, bugs and security risks are still there, though). What is important is that the library is not hardware accelerated and it thus uses a software accelerated AES cipher. So, I think it is a bit slower, but you would really have to measure it yourself. Upgrading your Load balancer should not be that hard, though.
  - vetinari 10y ago
    It supports AES-NI on x64 architecture, if available.
- tagrun 10y ago
  https://news.ycombinator.com/item?id=10901895 https://news.ycombinator.com/item?id=10901895
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
tagrun 10y ago
> [...] consider using caddy[1]. It's a HTTP/2 web server written in Go To be fair, it's not. It simply wraps Go's HTTP/2 server which is mostly developed by Brad Fitzpatrick, which in turn relies on Go's crypto libraries (written in Go and assembly). As a Go user, I personally don't see any point in using Caddy, as I prefer writing a few hundred lines of Go to serve static pages with all the features I need, with the additional ability of serving more than static pages (you can do fastcgi with Go's stdlib if you need it, I personally prefer writing server code in Go). This is especially true considering that they called their non-paying users dishonest, for not "honestly paying back the value it provides you" while at the same time not sharing a single cent of their revenues with Google who develops the actual HTTP server they wrap (or with any other third party libraries that "provide value" to them). (old discussion: https://news.ycombinator.com/item?id=11264041 https://news.ycombinator.com/item?id=11264041)
- pfg 10y ago
  > To be fair, it's not. It simply wraps Go's HTTP/2 server which is mostly developed by Brad Fitzpatrick, which in turn relies on Go's crypto libraries (written in Go and assembly). I don't think that's a fair description of Caddy. Of course they're going to use the existing packages in Go, why would they reinvent the wheel? Caddy provides useful things like a config syntax, middleware, automatic certificate deployment, etc. which you'd have to reimplement or take from somewhere else. > As a Go user, I personally don't see any point in using Caddy, as I prefer writing a few hundred lines of Go to serve static pages with all the features I need, with the additional ability of serving more than static pages (you can do fastcgi with Go's stdlib if you need it, I personally prefer writing server code in Go). Caddy allows you to write your own extensions/middleware, which should cover all that. In turn, you get to re-use all the existing extensions and other things Caddy takes care of (which, in my experience, you'd inadvertently end up reinventing at some point anyway). > This is especially true considering that they called their non-paying users dishonest, for not "honestly paying back the value it provides you" while at the same time not sharing a single cent of their revenues with Google who develops the actual HTTP server they wrap (or with any other third party libraries that "provide value" to them). I don't parse that sentence as "you're dishonest if you don't pay for Caddy", but rather "be honest about the value it provided." It's still a free project, and I don't see the problem here at all.

by pfg 10y ago

jmiserez 10y ago

So instead of upgrading a library or the webserver you'd rather replace the webserver completely with a relatively new [1] webserver and redo all the configuration? (edit: more positive wording) [1] https://news.ycombinator.com/item?id=9452606 https://news.ycombinator.com/item?id=9452606

chris_wot 10y ago
Am I reading the same post? When I read it, he seemed to say "might consider"...
- deleted 10y ago
  [deleted]
pfg 10y ago
That post is more than a year old. Caddy has since had more than 70 contributors and > 1K commits. Based on my experience, replacing nginx (in my case acting as a fairly simple reverse proxy for rails) with Caddy wasn't significantly harder than compiling a custom nginx. If you have a complex configuration, YMMV. I'm definitely not suggesting using Caddy as a drop-in replacement for your existing production web server without further testing. That being said, getting rid of a OpenSSL dependency isn't a bad thing.
- jmiserez 10y ago
  > Caddy has since had more than 70 contributors and > 1K commits. That is impressive, will definitely try it. Is there a list of companies using Caddy somewhere?
  - pfg 10y ago
    I haven't seen a list yet. A couple of Go community sites have started using it (for obvious reasons). Without having any particular insight, I'd guess the user base consists mostly of early adopters, Go developers and some side-projects right now.

deleted 10y ago

[deleted]

pfooti 10y ago

I'm not a golang user, but I am curious, how hardened is the crypto/tls library? One of the reasons I use openssl is because I don't want a DIY crypto layer, I want something a lot of people have banged on. I'd hate to move to a new server, just to find out it is susceptible to a whole new set of Ye Olde Underrun Bugges that openssl patched ages ago.

pfg 10y ago
This was discussed on HN a couple of months ago[1] when Go fixed a carry propagation bug that affected crypto/tls. [1]: https://news.ycombinator.com/item?id=10897511 https://news.ycombinator.com/item?id=10897511
Matt3o12_ 10y ago
It is maintained by Google and the whole go community since it is in the standard library. So, I think it is fairly secure (probably not as well tested as OpenSSL but the attack surface is smaller, bugs and security risks are still there, though). What is important is that the library is not hardware accelerated and it thus uses a software accelerated AES cipher. So, I think it is a bit slower, but you would really have to measure it yourself. Upgrading your Load balancer should not be that hard, though.
- vetinari 10y ago
  It supports AES-NI on x64 architecture, if available.
tagrun 10y ago
https://news.ycombinator.com/item?id=10901895 https://news.ycombinator.com/item?id=10901895

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]

tagrun 10y ago

> [...] consider using caddy[1]. It's a HTTP/2 web server written in Go To be fair, it's not. It simply wraps Go's HTTP/2 server which is mostly developed by Brad Fitzpatrick, which in turn relies on Go's crypto libraries (written in Go and assembly). As a Go user, I personally don't see any point in using Caddy, as I prefer writing a few hundred lines of Go to serve static pages with all the features I need, with the additional ability of serving more than static pages (you can do fastcgi with Go's stdlib if you need it, I personally prefer writing server code in Go). This is especially true considering that they called their non-paying users dishonest, for not "honestly paying back the value it provides you" while at the same time not sharing a single cent of their revenues with Google who develops the actual HTTP server they wrap (or with any other third party libraries that "provide value" to them). (old discussion: https://news.ycombinator.com/item?id=11264041 https://news.ycombinator.com/item?id=11264041)

pfg 10y ago
> To be fair, it's not. It simply wraps Go's HTTP/2 server which is mostly developed by Brad Fitzpatrick, which in turn relies on Go's crypto libraries (written in Go and assembly). I don't think that's a fair description of Caddy. Of course they're going to use the existing packages in Go, why would they reinvent the wheel? Caddy provides useful things like a config syntax, middleware, automatic certificate deployment, etc. which you'd have to reimplement or take from somewhere else. > As a Go user, I personally don't see any point in using Caddy, as I prefer writing a few hundred lines of Go to serve static pages with all the features I need, with the additional ability of serving more than static pages (you can do fastcgi with Go's stdlib if you need it, I personally prefer writing server code in Go). Caddy allows you to write your own extensions/middleware, which should cover all that. In turn, you get to re-use all the existing extensions and other things Caddy takes care of (which, in my experience, you'd inadvertently end up reinventing at some point anyway). > This is especially true considering that they called their non-paying users dishonest, for not "honestly paying back the value it provides you" while at the same time not sharing a single cent of their revenues with Google who develops the actual HTTP server they wrap (or with any other third party libraries that "provide value" to them). I don't parse that sentence as "you're dishonest if you don't pay for Caddy", but rather "be honest about the value it provided." It's still a free project, and I don't see the problem here at all.