Re: Force response to send HTTP/2 GOAWAY?
On Sun, Sep 2, 2018 at 5:29 AM Lukas Tribus wrote: > You might be able to do with a dedicated backend and a 503 errorfile. > > backend generate_421 > errorfile 503 /etc/haproxy/421misdirect.http > > With appropriate content in /etc/haproxy/421misdirect.http I'll give this a try and see if browsers respond the way I need them to. > Would you mind elaborating why you want to close the TLS connection, > for a better understanding of the use-case? My use-case is for TLS client certificate authentication. In my configuration, client certificates are optional for the site as a whole, but required to perform certain actions on it. If a user visits the site without the client certificate, inserts their smart card, and then tries to perform an action that requires a certificate, the browser will reuse the TLS connection without it, so the action will fail. I need the browser to establish a new TLS connection so that it will use the client certificate that is now present. Joseph C. Sible
[RFC] Changing server port via Lua
A question was recently asked on Stack Overflow about how to change a
server's port via Lua [1]. The Lua function Server.set_addr currently
says "See the management socket documentation for more information
about the format of the string." However, this is misleading: the
management socket's "set server addr" supports changing the port
with syntax like "192.0.2.1 port ", but that doesn't work in the
Lua function. It seems like it would be simple enough to change Lua to
use update_server_addr_port instead of update_server_addr, which would
let this work. I can think of two reasonable options for the Lua
interface:
1. Add a new optional argument to the function, so calls would look
like "server:set_addr("192.0.2.1", )
2. Parse the existing argument like the management socket does, so
calls would look like "server:set_addr("192.0.2.1 port ")
Is this something that would be accepted if I wrote a patch for it? If
so, which option should I go with for the Lua interface?
[1]: https://stackoverflow.com/q/61568148/7509065
Joseph C. Sible
[PATCH] MINOR: lua: allow changing port with set_addr
Add an optional port parameter, which can be either a number or a
string (to support '+' and '-' for port mapping).
This fixes issue #586.
---
doc/lua-api/index.rst | 2 +-
src/hlua_fcn.c| 7 ++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/doc/lua-api/index.rst b/doc/lua-api/index.rst
index 9a578ee29..f3e5cb786 100644
--- a/doc/lua-api/index.rst
+++ b/doc/lua-api/index.rst
@@ -976,7 +976,7 @@ Server class
server.
:returns: an integer.
-.. js:function:: Server.set_addr(sv, addr)
+.. js:function:: Server.set_addr(sv, addr[, port])
Dynamically change the address of the server. See the management socket
documentation for more information about the format of the string.
diff --git a/src/hlua_fcn.c b/src/hlua_fcn.c
index a9c7fe507..e6f4d7379 100644
--- a/src/hlua_fcn.c
+++ b/src/hlua_fcn.c
@@ -1034,13 +1034,18 @@ int hlua_server_set_addr(lua_State *L)
{
struct server *srv;
const char *addr;
+ const char *port;
const char *err;
srv = hlua_check_server(L, 1);
addr = luaL_checkstring(L, 2);
+ if (lua_gettop(L) >= 3)
+ port = luaL_checkstring(L, 3);
+ else
+ port = NULL;
HA_SPIN_LOCK(SERVER_LOCK, >lock);
- err = server_parse_addr_change_request(srv, addr, "Lua script");
+ err = update_server_addr_port(srv, addr, port, "Lua script");
HA_SPIN_UNLOCK(SERVER_LOCK, >lock);
if (!err)
lua_pushnil(L);
--
2.25.1
Re: RFC: set minimum default TLS version to 1.2 for HAProxy 2.2
On Fri, May 29, 2020 at 3:09 AM William Lallemand wrote: > > On Wed, May 27, 2020 at 12:40:54PM +0200, William Lallemand wrote: > > Hello List, > > > > Since HAProxy 1.8, the minimum default TLS version for bind lines is > > TLSv10. I was thinking to increase this minimum default to TLSv11 before > > the 2.2 release. But when we discussed the other day about the DH > > param set to 2048 by default, I read that RHEL 8 was also disabling > > TLSv11 by default. TLSv12 now exists for 12 years, it is widely-spread > > nowadays. > > > > So in my opinion we should do the same, and set the minimum version to > > TLSv12 by default on bind lines. It's still configurable with > > min-ssl-ver if you want the support for prior TLS versions. > > > > Does anybody have any objections? > > > > Thanks for the feedbacks, I made the change and pushed it in the master. > > -- > William Lallemand > I'm happy about this change, but I notice a flaw in its implementation: it looks like servers that specify "ssl-max-ver TLSv1.0" or "ssl-max-ver TLSv1.1" without specifying ssl-min-ver would previously have disallowed SSLv3, but will now allow it. (I hope this case doesn't actually exist anywhere in practice, but if it does for some reason, we probably don't want to make them even less secure.) Joseph C. Sible
Re: RFC: set minimum default TLS version to 1.2 for HAProxy 2.2
On Sat, May 30, 2020 at 3:22 PM William Lallemand wrote: > > On Sat, May 30, 2020 at 08:41:04PM +0200, William Lallemand wrote: > > On Sat, May 30, 2020 at 02:04:56PM -0400, Joseph C. Sible wrote: > > > > > > I'm happy about this change, but I notice a flaw in its > > > implementation: it looks like servers that specify "ssl-max-ver > > > TLSv1.0" or "ssl-max-ver TLSv1.1" without specifying ssl-min-ver would > > > previously have disallowed SSLv3, but will now allow it. (I hope this > > > case doesn't actually exist anywhere in practice, but if it does for > > > some reason, we probably don't want to make them even less secure.) > > > > > > Joseph C. Sible > > > > Hello Joseph, > > > > No change were made for server lines, we were only talking about bind > > lines here. There was never a default minimum on server lines. > > > > On bind lines, indeed, if you set a maximum which is lower than the > > default min, the default min won't be used. This was already the case > > previously in fact, but the default was TLSv1.0 so it was less a > > problem. > > > > What I suggest is to display a warning if it happens, so people don't have > > any surprise. > > > > What do you think? > > Actually I think in this case it's safer to fallback on min = max and to > display the warning. Ah, I was being a bit imprecise. I was using "servers" in the sense of "HAProxy load balancer servers" in general, not "server lines". Anyway, when max < TLSv1.2, I think we should make min default to max. I think this is what you mean by "fallback on min = max", but I'm not 100% sure. I don't mind the warning (since servers shouldn't ever have the max below TLSv1.2 today), but at the same time, I don't really see much value in it either. Joseph C. Sible
Re: RFC: set minimum default TLS version to 1.2 for HAProxy 2.2
On Sat, May 30, 2020 at 4:15 PM William Lallemand wrote: > > On Sat, May 30, 2020 at 03:41:51PM -0400, Joseph C. Sible wrote: > > Anyway, when max < TLSv1.2, I think we should make min default to max. > > I think this is what you mean by "fallback on min = max", but I'm not > > 100% sure. > > That's exactly what I meant! > > > I don't mind the warning (since servers shouldn't ever have > > the max below TLSv1.2 today), but at the same time, I don't really see > > much value in it either. > > In my opinion the warning is important because the configuration > will behave differently depending on the HAProxy version you use. > > For example, in 2.1 with "ssl-max-ver TLSv1.1" alone, HAProxy will > accept both TLSv1.0 and TLSv1.1. If we do this change in 2.2, the same > configuration will only accept TLSv1.1. I think this kind of > configurations is ambiguous so it's better to emit a warning if the max > if lower thant the default min. Ah, the loss of TLSv1.0 with just "ssl-max-ver TLSv1.1" is a good point. I agree that that is worth a warning. Joseph C. Sible
