Hi Nicolas,
On Sunday 11 March 2018 05:35 PM, Nicolas Kovacs wrote:
Le 11/03/2018 à 12:31, Amos Jeffries a écrit :
OK, I got something that's starting to work.
# Exceptions
EXCEPTIONS=$(egrep -v '(^\#)|(^\s+$)' /usr/local/sbin/no-proxy.txt)
for EXCEPTION in $EXCEPTIONS; do
$IPT -A PREROUTING
Hey Nicolas,
If you are running a squid which doesn't have a mandatory rule of "Block first
and then allow" or what in the security industry will be named "up-tight" then
Yuri solution is the right path.
But... as a rule of thumb, if you don't need to pass the traffic into the proxy
software do
You're welcome ;)
This config works several years on my servers :)
12.03.2018 02:17, Nicolas Kovacs пишет:
> Le 11/03/2018 à 19:44, Yuri a écrit :
>> It's trivial to implement. Here is my config snippet:
>>
>> # SSL bump rules
>> acl DiscoverSNIHost at_step SslBump1
>> acl NoSSLIntercept ssl::se
Le 11/03/2018 à 19:44, Yuri a écrit :
> It's trivial to implement. Here is my config snippet:
>
> # SSL bump rules
> acl DiscoverSNIHost at_step SslBump1
> acl NoSSLIntercept ssl::server_name_regex
> "/usr/local/squid/etc/acl.url.nobump"
> ssl_bump peek DiscoverSNIHost
> ssl_bump splice NoSSLInter
Also,
feel free to read our config examples here:
https://wiki.squid-cache.org/ConfigExamples
12.03.2018 00:39, Nicolas Kovacs пишет:
> Le 11/03/2018 à 16:48, Alex Crow a écrit :
>> It would be a lot easier to just create exceptions on the squid device
>> for sites where bumping doesn't work wh
Alex would like to say, splice, when implemented, more easy to
maintenance than iptables/firewall rules.
It's trivial to implement. Here is my config snippet:
# SSL bump rules
acl DiscoverSNIHost at_step SslBump1
acl NoSSLIntercept ssl::server_name_regex
"/usr/local/squid/etc/acl.url.nobump"
ssl_
Le 11/03/2018 à 16:48, Alex Crow a écrit :
>
> It would be a lot easier to just create exceptions on the squid device
> for sites where bumping doesn't work which cause then to be tunnelled or
> spliced rather then bumped. You can then at least use dstdomain or
> ssl:servername rules. dstdomain wi
.
The alternative for ssl-bump is the splice action. For that you only
need to know the server names each company uses.
OP,
It would be a lot easier to just create exceptions on the squid device
for sites where bumping doesn't work which cause then to be tunnelled or
spliced rather then
Le 11/03/2018 à 12:31, Amos Jeffries a écrit :
> The whois system can provide info on the IP ranges owned by the
> companies like Google which own their own ranges.
>
>
> The alternative for ssl-bump is the splice action. For that you only
> need to know the server names each company uses.
I'd s
Le 11/03/2018 à 12:31, Amos Jeffries a écrit :
> The whois system can provide info on the IP ranges owned by the
> companies like Google which own their own ranges.
>
>
> The alternative for ssl-bump is the splice action. For that you only
> need to know the server names each company uses.
OK, I
On 11/03/18 23:54, Nicolas Kovacs wrote:
> Le 11/03/2018 à 11:17, Amos Jeffries a écrit :
>> The process is not getting anywhere close to caching being relevant. The
>> error you mentioned earlier is in the TLS handshake part of the process.
>
> I've experimented some more, and I have a partial su
Le 11/03/2018 à 11:17, Amos Jeffries a écrit :
> The process is not getting anywhere close to caching being relevant. The
> error you mentioned earlier is in the TLS handshake part of the process.
I've experimented some more, and I have a partial success. Here, I'm
redirecting all HTTPS traffic *e
On 11/03/18 21:33, Nicolas Kovacs wrote:
> Le 11/03/2018 à 09:24, Amos Jeffries a écrit :
>> What you need to start with is switch your thinking from "domains" to
>> considering things in terms of connections and individual servers. Since
>> "domain" is a URL concept, and URLs are all hidden inside
Le 11/03/2018 à 09:24, Amos Jeffries a écrit :
> What you need to start with is switch your thinking from "domains" to
> considering things in terms of connections and individual servers. Since
> "domain" is a URL concept, and URLs are all hidden inside the encrypted
> part of the traffic there is
Le 11/03/2018 à 10:17, Amos Jeffries a écrit :
> In your config you changed your 3128 to receiving port-80 (origin-form)
> syntax with "intercept". So port 3130 was necessary to takeover
> receiving of the normal proxy traffic.
>
> The TLS wrappers on HTTPS need special handling to decrypt so that
On 11/03/18 20:51, Nicolas Kovacs wrote:
>
> This configuration works perfectly and gives me no errors or whatsoever,
> though I don't quite understand why I need all these ports. When I used
> only HTTP, I had this configuration
>
> http_port 3128 transparent
Which receives port-80 syntax traff
Le 11/03/2018 à 09:24, Amos Jeffries a écrit :
> What you need to start with is switch your thinking from "domains" to
> considering things in terms of connections and individual servers. Since
> "domain" is a URL concept, and URLs are all hidden inside the encrypted
> part of the traffic there is
On 11/03/18 21:07, Nicolas Kovacs wrote:
> Hi,
>
> I have Squid setup as a transparent HTTP+HTTPS proxy in my local
> network, using SSL-Bump.
>
> The configuration works quite nicely, according to
> /var/log/squid/cache.log and /var/log/squid/access.log.
>
> This being said, I am having trouble
Hi,
I have Squid setup as a transparent HTTP+HTTPS proxy in my local
network, using SSL-Bump.
The configuration works quite nicely, according to
/var/log/squid/cache.log and /var/log/squid/access.log.
This being said, I am having trouble with a handful of domains like
Github, or my OwnCloud inst
19 matches
Mail list logo
