On Thu, Feb 13, 2020 at 11:40:08AM +0500, ???? ??????? wrote:
> hello,
> while playing with dataplane api (I copy-pasted code), accidentally I
> created the following config
> frontend git_example_com_https_frontend
>   mode http
>   bind name http
>   bind name https crt /etc/haproxy/bundle.pem ssl alpn
> h2,http/1.1
>   default_backend git_example_com_https_backend
>   redirect scheme https code 301 if !{ ssl_fc }
> both bind lines include the same 7080 port. haproxy does not complain. is
> that configuration correct ? should haproxy complain on such config ?

Theorically it's not valid. But it's hard to make it complain on this
as the IP and ports are just some elements, you can also have other
differentiators like the interface, the namespace etc.

For example this config wouldn't probably make much sense:

  bind ssl crt /etc/haproxy/bundle1.pem
  bind ssl crt /etc/haproxy/bundle2.pem

But what if someone is purposely trying to progressively deploy a new
certificate (4096bit or ECDSA) and observe the performance impacts ?

Similarly, this one doesn't seem to make much sense at first glance:

  bind ssl crt /etc/haproxy/bundle.pem alpn h2,http/1.1
  bind ssl crt /etc/haproxy/bundle.pem alpn http/1.1

But someone might want to enforce H1 on some clients to collect various
metrics or to experiment a bit.

Thus I'd tend to agree that having both SSL and non-SSL on the same
IP+port+interface+namespace doesn't seem to make much sense, but it's
just *one* very likely wrong combination in the middle of a lot of
other suspicious ones.

In fact that's exactly the type of things I'd like a diag utility to
detect. For me it's very similar to the case where two servers have
the same cookie value in a farm. Very often it's a copy-paste mistake
but sometimes it's on purpose and you don't want to emit warnings or
even less errors when seeing this. And with such a tool, I'd be happy
to remove some of the warnings we have.

I initially thought we'd have haproxy itself run advanced self-checks
on a config, but given that such diags would require more complex logic
and more relations between config elements, it would needlessly complicate
what is already complicated, so better delegate that to external tools.


Reply via email to