[PATCH] DOC: http-request cache-use / http-response cache-store expects cache name
Hi,
Small patch for doc/configuration.txt that adds missing cache name
option to http-request cache-use / http-response cache-store.
Also adds optional if/unless condition doc to
10.2.2. Proxy section: http-request cache-use / http-response cache-store
-Jarno
--
Jarno Huuskonen
>From b130a0676a621b6008333c97b56485d6ca23064b Mon Sep 17 00:00:00 2001
From: Jarno Huuskonen
Date: Fri, 4 Jan 2019 14:05:02 +0200
Subject: [PATCH] DOC: http-request cache-use / http-response cache-store
expects cache name
Adds missing cache name option to http-request cache-use and
http-response cache-store documentation.
Also adds optional if/unless condition to
10.2.2. Proxy section: http-request cache-use / http-response cache-store
---
doc/configuration.txt | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index 6ca63d6..855c0b1 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -4109,7 +4109,7 @@ http-request auth [realm ] [ { if | unless }
]
acl auth_ok http_auth_group(L1) G1
http-request auth unless auth_ok
-http-request cache-use [ { if | unless } ]
+http-request cache-use [ { if | unless } ]
See section 10.2 about cache setup.
@@ -4658,7 +4658,7 @@ http-response allow [ { if | unless } ]
This stops the evaluation of the rules and lets the response pass the check.
No further "http-response" rules are evaluated for the current section.
-http-response cache-store [ { if | unless } ]
+http-response cache-store [ { if | unless } ]
See section 10.2 about cache setup.
@@ -17868,13 +17868,13 @@ max-age
10.2.2. Proxy section
-
-http-request cache-use
+http-request cache-use [ { if | unless } ]
Try to deliver a cached object from the cache . This directive is also
mandatory to store the cache as it calculates the cache hash. If you want to
use a condition for both storage and delivering that's a good idea to put it
after this one.
-http-response cache-store
+http-response cache-store [ { if | unless } ]
Store an http-response within the cache. The storage of the response headers
is done at this step, which means you can use others http-response actions
to modify headers before or after the storage of the response. This action
--
1.8.3.1
Re: State of 0-RTT TLS resumption with OpenSSL
Hi Janusz, On Fri, Jan 04, 2019 at 10:53:51AM +0100, Janusz Dziemidowicz wrote: > czw., 3 sty 2019 o 17:52 Olivier Houchard napisa??(a): > > Ah I think I figured it out. > > OpenSSL added anti-replay protection when using early data, and it messes up > > with the session handling. > > With the updated attached patch, I get early data to work again. Is it > > better > > for you ? > > Now it works. > However, I am a bit concerned about disabling something that sounds > like an important safeguard. > Reading this > https://www.openssl.org/docs/man1.1.1/man3/SSL_SESSION_get_max_early_data.html#REPLAY-PROTECTION > suggests that it is really not a wise thing to do. > > And again, s_server works differently. It does not use > SSL_OP_NO_ANTI_REPLAY but the resumption, with early data, works, > once. Then you get new session that you can resume again if you wish, > but also once. You cannot resume the same session twice. With your > patch I can resume single session as many times as I wish. Coupled > with early data this is exactly something that TLS 1.3 RFC warns > against. This probably is due to haproxy using external session > management. > > I'll try to dig more into this on weekend, now that I know where to look. > I understand the concern. I checked and both nghttp2 and nginx disable the replay protection. The idea is you're supposed to allow early data only on harmless requests anyway, ie ones that could be replayed with no consequence. Regards, Olivier
Re: State of 0-RTT TLS resumption with OpenSSL
czw., 3 sty 2019 o 17:52 Olivier Houchard napisał(a): > Ah I think I figured it out. > OpenSSL added anti-replay protection when using early data, and it messes up > with the session handling. > With the updated attached patch, I get early data to work again. Is it better > for you ? Now it works. However, I am a bit concerned about disabling something that sounds like an important safeguard. Reading this https://www.openssl.org/docs/man1.1.1/man3/SSL_SESSION_get_max_early_data.html#REPLAY-PROTECTION suggests that it is really not a wise thing to do. And again, s_server works differently. It does not use SSL_OP_NO_ANTI_REPLAY but the resumption, with early data, works, once. Then you get new session that you can resume again if you wish, but also once. You cannot resume the same session twice. With your patch I can resume single session as many times as I wish. Coupled with early data this is exactly something that TLS 1.3 RFC warns against. This probably is due to haproxy using external session management. I'll try to dig more into this on weekend, now that I know where to look. -- Janusz Dziemidowicz
