Multiple/dynamic SSL certificates? about bandit HOT 4 CLOSED

Hi @carterbryden ,

The problem you describe is actually one (or two..) layers deeper, which means in the case of bandit in thousand_island.

thousand_island is using the default Erlang/OTP :ssl.
:ssl allows you to define either a sni_hosts keyword list with a static hostname => server_options mapping or a sni_fun which is called on every call containing a SNI, which is probably what you want.

The server_options returned by the sni_fun are merged into the server_options defined in the listen function (overriding the cert / key defined there), which means you can set your dynamic cert / certfile + key / keyfile there.

You can define your custom sni_fun in the transport_options of bandit, like this:

bandit_options = [
  port: 4000,
  transport_options: [
    sni_fun: &YourCustom.sni/1,
    certfile: "priv/certs/cert.pem",
    keyfile: "priv/certs/key.pem"
  ]
]

children = [
  {Bandit, plug: Some.Plug, scheme: :https, options: bandit_options}
]

and then handle it based on the received name:

defmodule YourCustom do
  def sni(name) do
    if name == 'foo.bar' do # SNI is a charlist
      # Return cert / key for `foo.bar`
      [certfile: "priv/certs/foo.pem", keyfile: "priv/certs/foo.key"]
    else
      # Use the default cert / key
      []
    end
  end
end

from bandit.

@moogle19 exactly! I've never done this as such, but this is exactly why I chose to not be clever about option parsing and instead just expose everything that OTP's :gen_tcp and :ssl applications provide (see mtrudel/thousand_island#13 for prior discussion). Being able to stand on the shoulders of the OTP giants who implemented sni_fun should 'just work' for you here.

Would love to hear about success stories with this!

from bandit.

To zoom out a bit, your idea of a proxy server should map really well onto Bandit. The sni_fun escape hatch @moogle19 describes would work just fine with an acme backend (I use Caddy for a couple of non-production things and it's been a real boon; the whole acme pattern is just fantastic).

I've never done any work to support it, but I'd expect Bandit to 'just work' with HTP/1 proxy requests (insofar as your plug should see the original connection, CONNECT verb and all). This is one place where the underspecification of HTTP/1 works in your favour :).

The one thing I'd mention is that Bandit's HTTP/2 implementation was developed without account for proxy concerns. I can recall a few places in RFC7540 where I said 'well, I'll never need to worry about CONNECT, so I can take a shortcut here'.

At a first glance, it looks like RFC7540§8.3 will probably fail, since bandit enforces the presence of :scheme and :path. Other than that, I would think that HTTP/2 CONNECT requests would probably also 'just work' in the same manner at HTTP/1 described above. If you'd like to undertake the work to add CONNECT support to HTTP/2 in the context of §8.3, I'd happily take the PR. By design, Bandit doesn't express any policy other than that required for protocol correctness, so the workup here would be modest and focused on supporting the slight variation in pseudo headers in the case of CONNECT verbs.

from bandit.

Closing as there's nothing actionable left here for Bandit. Thanks for the issue!

from bandit.