OpenSSL update possibly breaks transparent proxy to Gmail?

NS comes from CentOS that is 99,99% RHEL

if you know RH a bit you’d know that version numbering is not important… for example, kernel version is not comparable with vanilla kernel

on production servers, no manual compilation, no rpms from “exotical” repositories, (possibily) no downgrade

I won’t start a distro war, but I think you miss something (for example % of servers running gentoo out there compared to RH/centos ones) :wink:

it is only words of mind ! LETS help our Friend to resolve the issue at first !
I have no possibility to check it right now, have U @zamboni ?
I have installed clean version of server , redy for fight :smile:

Yes, squid.conf contains acl Safe_ports port 443. I built a new server from a scratch install, downloaded patches and installed the proxy and filter with the same results. With the proxy enabled, both Chrome and IE time out when trying to load an SSL site. Firefox always loads. One difference is that Firefox does a certificate query to an ocsp database that looks like this:

1434761527.182 82 10.3.0.x TCP_MISS/200 955 POST http://clients1.google.com/ocsp - HIER_DIRECT/74.125.239.131 application/ocsp-response

But turning off that option in Firefox doesn’t stop it from displaying https sites.

For now, I’ll run with the proxy disabled. I may try to build a new system without loading the openssl patch just to confirm that is actually connected to the problem.

Do U install Squid cert on your devices ? or U could regenerate Squid keys by NEW openssl !

@AZChas could U reenable Proxy service or even reinstall it , coz i have made clean Nethserver installation , upgrade all system and then enable proxy , everything work fine !
in Chrome settings make Proxy port 3128 for all protocols!

1434785473.499 322347 91.209.1.12 TCP_MISS/200 15451 CONNECT accounts.youtube.com:443 - HIER_DIRECT/173.194.112.37 -
1434785473.553 349006 91.209.1.12 TCP_MISS/200 80800 CONNECT fonts.gstatic.com:443 - HIER_DIRECT/173.194.112.55 -
1434785473.627 350078 91.209.1.12 TCP_MISS/200 123868 CONNECT accounts.google.com:443 - HIER_DIRECT/216.58.211.13 -
1434785507.169 383843 91.209.1.12 TCP_MISS/200 2106491 CONNECT mail.google.com:443 - HIER_DIRECT/173.194.112.54 -

Thanks, Artem. I will try that. You used manual proxy and set Chrome to go to 3128, yes? Did you try using transparent proxy with no settings change in Chrome?

Use manual config , not all windows could recognize proxy :smile: plus i have not oppotunity to create vlan + test windows from home :frowning:

I have determined that the proxy problem has nothing to do with OpenSSL, so the answer to the question in my subject is No. However, I do have a problem still where transparent proxy has stopped working with both IE and Chrome, but Firefox works fine. All three rely on Windows to automatically detect the proxy setting. I need to find a Mac to see how that works, and should test a few Linux machines as well. But if this was a problem in Windows, I would think there would be lots of chatter about it. I really think it’s most likely something about my specific NethServer configuration that is at the root of the problem.

@AZChas re enable proxy feature ! All work fine , or could help u send PM

Google use HSTS so Chrome block connection coz selfsigned proxy cert!
When you setup in chrome directly proxy Ip and port , all works fine !

I’ve gotten to the bottom of the problem, or close to the bottom. If a Windows computer has “automatically detect settings” checked in the internet connection lan settings, Chrome and IE fail – time out – when trying to get web pages through the NS transparent proxy.

All browsers start working when automatic detection is turned off. The way Windows browsers discover the proxy settings is either through DHCP and a file called wpad.dat, or through DNS. What I don’t know is what changed a week ago to cause working clients to fail. But at this point I at least know that I can turn off auto-detection on a client and the proxy comes back to life.

wpad file goes through DHCP and NS add it by the DNS name of a server , maybe it is better to add it by Ip of the server , it is only thoughts :slight_smile: so @alefattorini close the topic pls

We could probably improve wpad.dat / proxy.pac.
@AZChas, could you show the content of /var/www/html/wpad.dat ?

Probably your network doesn’t resolve the host proxy.yourdomain (last line of wpad.dat).

1 Like

and it maybe the base of the problem with Transparent proxy! so @filippo_carletti @giacomo could u change this walue in other releases?

Here is wpad.dat:

function FindProxyForURL(url, host)
{
if (isPlainHostName(host))
return “DIRECT”;
if (isInNet(host, “10.3.0.1”, “255.255.255.0”))
return “DIRECT”;

if (isInNet(host, "127.0.0.1", "255.255.255.255"))
    return "DIRECT";
return "PROXY proxy.lan:3128";

}

I’m sure “proxy.lan:3128” doesn’t resolve in a meaningful way on my network. I suppose that could be changed to “myhostname.lan:3128” or “10.3.0.1:3128”?

1 Like