On 07/24/2015 05:26 AM, Amos Jeffries wrote:
I think you still misunderstand the OppSec RFC meanings.
Ditto.
Since SSL support first went into Squid back in 1998 we have allowed
cache_peer to connect to a remote https_port and sent http:// traffic
over it.
Using the above as a sub-case of
On 25/07/2015 3:28 a.m., Alex Rousskov wrote:
On 07/24/2015 05:26 AM, Amos Jeffries wrote:
I think you still misunderstand the OppSec RFC meanings.
Ditto.
Since SSL support first went into Squid back in 1998 we have allowed
cache_peer to connect to a remote https_port and sent http://
On 23/07/2015 3:32 a.m., Alex Rousskov wrote:
On 07/21/2015 04:25 AM, Amos Jeffries wrote:
On 21/07/2015 9:42 a.m., Alex Rousskov wrote:
adaptation_access icapS aclIcap
adaptation_access icapN !aclIcap
aclIcap can be a received_encrypted ACL. What ACL expression would you
suggest for
On 07/23/2015 01:41 PM, Tsantilas Christos wrote:
On 07/23/2015 07:21 PM, Alex Rousskov wrote:
Furthermore, the values of unsafe srcX enum constants should be
increased to actually match the srcUnsafe mask (16 is still smaller than
0x).
This is should be OK.
The safe flags are from:
On 07/23/2015 07:41 AM, Amos Jeffries wrote:
On 23/07/2015 3:32 a.m., Alex Rousskov wrote:
On 07/21/2015 04:25 AM, Amos Jeffries wrote:
On 21/07/2015 9:42 a.m., Alex Rousskov wrote:
adaptation_access icapS aclIcap
adaptation_access icapN !aclIcap
aclIcap can be a received_encrypted ACL.
On 07/21/2015 01:25 PM, Amos Jeffries wrote:
No. Christos wrote this:
NOTE: Currently there is not any mechanism to indicate if a cached
object came from secure source or not, so we assume that all hits for
secure requests are secure too.
The cache hits rely on the request markings to
On 21/07/2015 9:42 a.m., Alex Rousskov wrote:
On 07/20/2015 01:45 PM, Amos Jeffries wrote:
On 21/07/2015 6:48 a.m., Alex Rousskov wrote:
On 07/20/2015 09:27 AM, Kinkie wrote:
So in my opinion the easiest way to move the discussion forward is to:
1. find one use-case which cannot be covered
Hi,
sorry for butting in but I am a bit confused by this discussion, as it
seems to be straying from the technical merit; this is my attempt at
getting back to the core of the topic.
Amos claims that its stated objective can be achieved by other,
already-existing, features, and that it this
On 18/07/2015 7:08 a.m., Alex Rousskov wrote:
On 07/17/2015 11:48 AM, Amos Jeffries wrote:
On 18/07/2015 3:13 a.m., Tsantilas Christos wrote:
This patch adds received_encrypted ACL
The new received_encrypted ACL matches transactions where all HTTP
messages were received over TLS or SSL
On 07/19/2015 05:35 AM, Amos Jeffries wrote:
On 18/07/2015 7:08 a.m., Alex Rousskov wrote:
On 07/17/2015 11:48 AM, Amos Jeffries wrote:
On 18/07/2015 3:13 a.m., Tsantilas Christos wrote:
This patch adds received_encrypted ACL
The new received_encrypted ACL matches transactions where all HTTP
This patch adds received_encrypted ACL
The new received_encrypted ACL matches transactions where all HTTP
messages were received over TLS or SSL transport connections, including
messages received from ICAP servers.
Some eCAP services receive data from unencrypted sources. Some eCAP
services
11 matches
Mail list logo
