my squid is a transparent proxy.
the cache.log shows that
2017/12/07 15:42:53 kid1| Error negotiating SSL connection on FD 175: Closed by
client
2017/12/07 15:42:54 kid1| Error negotiating SSL on FD 95: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (1/-1/0)
2
On 07/12/17 03:59, aismel.valle wrote:
Hi guys,
well i implement the auth digest and work's fine only with the browser,
when i config the internet download manager for download files have
problems always show me the form authentication and don't accept the
credentials i know the data is fine bec
https://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery
07.12.2017 5:40, Hugo Saavedra пишет:
> ooops!, we have another problem here, anyone knows what is this?
>
> 2017/12/06 19:30:23 kid1| SECURITY ALERT: on URL: login.live.com:443
> 2017/12/06 19:30:23 kid1| SECURITY ALERT: Host header fo
ooops!, we have another problem here, anyone knows what is this?
2017/12/06 19:30:23 kid1| SECURITY ALERT: on URL: login.live.com:443
2017/12/06 19:30:23 kid1| SECURITY ALERT: Host header forgery detected
on local=131.253.61.100:443 remote=192.168.10.2:59041 FD 126 flags=33
(local IP does not matc
RC4, may be.
In practice, too restrictive security usually leads various issues, ever
for big vendor site, like MS (some of this sites AFAIK still using RC4).
To be related to your questions - yes, in theory it is possible to get
security issue in this case. But it is require deep investigation.
solution finded: we commented the sslproxy_cipher line and it works!
is there any security issues if we left the default options for this variable?
thanks
Hugo
2017-12-06 16:21 GMT-03:00 Alex Rousskov :
> On 12/06/2017 12:06 PM, Hugo Saavedra wrote:
>> 2017/12/06 16:02:37 kid1| Error negotiating
Not necessarily certificates. Exactly the same code gives the SSL pinning.
07.12.2017 1:21, Alex Rousskov пишет:
> On 12/06/2017 12:06 PM, Hugo Saavedra wrote:
>> 2017/12/06 16:02:37 kid1| Error negotiating SSL connection on FD 61:
>> error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknow
On 12/06/2017 12:06 PM, Hugo Saavedra wrote:
> 2017/12/06 16:02:37 kid1| Error negotiating SSL connection on FD 61:
> error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
> (1/0)
You may be able to fix this problem by updating your collection of
public CA certificates. Squid uses CA
ok,
Alex, this are the errors on cache.log (for 2 different tests)
2017/12/06 16:01:52 kid1| Error negotiating SSL on FD 18:
error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert
handshake failure (1/-1/0)
2017/12/06 16:01:52 kid1| Error negotiating SSL on FD 25:
error:14077410:SSL routin
On 12/06/2017 11:45 AM, Hugo Saavedra wrote:
> Currently we have cache.log disabled for performance.
With default debug_options, cache.log should not affect performance. If
it does in your setup, then there is probably a problem that you should
solve (without disabling cache.log).
> any clues?
Hi,
yes, squid is able to resolve those domains. Currently we have
cache.log disabled for performance. any clues?
Regards,
Hugo
2017-12-06 14:51 GMT-03:00 Enrico Heine :
> Hi,
>
> Can you confirm that squid is able to resolve these hostnames? If not try
> browsing to them without https and check
Hi,
Can you confirm that squid is able to resolve these hostnames? If not try
browsing to them without https and check if squid gives you an error message.
Did you check the cache.log as well?
Br Enrico
Am 6. Dezember 2017 17:38:24 MEZ schrieb Hugo Saavedra
:
>Hi All,
>
>We have the following
Hi All,
We have the following setup of a transparent squid box:
OS: CentOS release 6.9 (Final)
Squid Cache: Version 3.5.26-20170625-r14174
Compile options:
'--with-included-ltdl' '--enable-icap-client'
'--enable-delay-pools' '--with-openssl' '--enable-ssl-crtd'
'--enable-icmp' '--enable-snmp' '
Hi guys,
well i implement the auth digest and work's fine only with the browser,
when i config the internet download manager for download files have
problems always show me the form authentication and don't accept the
credentials i know the data is fine because when i use the seem
credentials in t
06.12.2017 16:57, Matus UHLAR - fantomas пишет:
>>> On Wed, Dec 6, 2017 at 7:01 AM, Jason Haar wrote:
To reiterate Alex, "yes you can".
Squid supports "proxy over TLS" as well as the old/default "proxy
over TCP"
- you use the https_port option
...but getting bro
On Wed, Dec 6, 2017 at 7:01 AM, Jason Haar wrote:
To reiterate Alex, "yes you can".
Squid supports "proxy over TLS" as well as the old/default "proxy over TCP"
- you use the https_port option
...but getting browsers to support it is challenging. The best way would be
to create a WPAD file that
On 06/12/17 21:07, G~D~Lunatic wrote:
my squid is a transparent proxy. and the problem is that i can't access
the svn server.
the access.log shows that
1512545348.844 380 192.168.51.15 TAG_NONE/200 0 CONNECT
192.168.52.6:443 - ORIGINAL_DST/192.168.52.6 -
1512545348.920 0 192.168.51.15 T
On 06/12/17 21:32, Mathieu Peltier wrote:
On Wed, Dec 6, 2017 at 7:01 AM, Jason Haar wrote:
To reiterate Alex, "yes you can".
Squid supports "proxy over TLS" as well as the old/default "proxy over TCP"
- you use the https_port option
...but getting browsers to support it is challenging. The be
On Wed, Dec 6, 2017 at 7:01 AM, Jason Haar wrote:
> To reiterate Alex, "yes you can".
>
> Squid supports "proxy over TLS" as well as the old/default "proxy over TCP"
> - you use the https_port option
>
> ...but getting browsers to support it is challenging. The best way would be
> to create a WPAD
my squid is a transparent proxy. and the problem is that i can't access the svn
server.
the access.log shows that
1512545348.844380 192.168.51.15 TAG_NONE/200 0 CONNECT 192.168.52.6:443 -
ORIGINAL_DST/192.168.52.6 -
1512545348.920 0 192.168.51.15 TAG_NONE/503 4324 OPTIONS
https://192.1
20 matches
Mail list logo
