Re: [squid-users] failing https requests

2020-04-27 Thread Adam Weremczuk

Thanks Amos for the hint.

Tcpdump in source reveals the following:

HTTP/1.1 400 Bad Request
Server: squid/3.5.27
Mime-Version: 1.0
Date: Mon, 27 Apr 2020 13:34:47 GMT
Content-Type: text/html;charset=utf-8
Content-Length: 4000
X-Squid-Error: ERR_INVALID_REQ 0
Vary: Accept-Language
Content-Language: en
X-Cache: MISS from PROXY
X-Cache-Lookup: NONE from PROXY:3128
Via: 1.1 PROXY (squid/3.5.27)
Connection: close

It also produces:

Some possible problems are:
- Missing or unknown request method.
- Missing URL.
- Missing HTTP Identifier (HTTP/1.0).
- Request is too large.
- Content-Length missing for POST or PUT requests.
- Illegal character in hostname; underscores are not allowed.
- HTTP/1.1 feature is being asked from an HTTP/1.0 software.

Can I determine which of the above is actually causing failures?

Increasing debug level to 9 in squid config hasn't resulted in any more 
info being logged :(


Cheers,
Adam

On 24/04/2020 16:57, Amos Jeffries wrote:

On 25/04/20 3:46 am, Adam Weremczuk wrote:

Hi all,

I run squid-3.5.27_3 on pfSense 2.4.4 as well as in house Sugar CRM server.

Recently Sugar license validation and updates checks made to
https://updates.sugarcrm.com/heartbeat/soap.php started failing (no
changes made at our end).

In squid logs requests only produce 2 lines:

1587737506.670  0 192.168.5.30 TAG_NONE/400 4360 NONE
error:invalid-request - HIER_NONE/- text/html
1587737506.978    301 192.168.5.30 TCP_MISS/301 464 POST
http://updates.sugarcrm.com/heartbeat/soap.php -
HIER_DIRECT/54.177.58.238 text/html

It looks like client error followed by a redirection to http.

Direct requests (no web proxy) as well as telnet, wget and curl work fine.

Could somebody explain what exactly the errors mean and why the requests
fail?


It means the client delivered some bytes which do not in any way conform
to HTTP request syntax. Not even similar.

The best thing to do is to get a full-packet capture and investigate
with wireshark what is going on.


Amos
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


[squid-users] failing https requests

2020-04-24 Thread Adam Weremczuk

Hi all,

I run squid-3.5.27_3 on pfSense 2.4.4 as well as in house Sugar CRM server.

Recently Sugar license validation and updates checks made to 
https://updates.sugarcrm.com/heartbeat/soap.php started failing (no 
changes made at our end).


In squid logs requests only produce 2 lines:

1587737506.670  0 192.168.5.30 TAG_NONE/400 4360 NONE 
error:invalid-request - HIER_NONE/- text/html
1587737506.978    301 192.168.5.30 TCP_MISS/301 464 POST 
http://updates.sugarcrm.com/heartbeat/soap.php - 
HIER_DIRECT/54.177.58.238 text/html


It looks like client error followed by a redirection to http.

Direct requests (no web proxy) as well as telnet, wget and curl work fine.

Could somebody explain what exactly the errors mean and why the requests 
fail?


Thanks,
Adam


___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] https proxy authentication

2018-04-10 Thread Adam Weremczuk

Hi Amos,


On 30/03/18 02:44, Amos Jeffries wrote:

So, the big question is why you have this setup of Apache being a
reverse-proxy for a Squid forward-proxy?

Forward-proxy are supposed to be between clients and reverse-proxies or
origins. Not the other way around.

This is a set up I inherited with not much being documented.
I think the purpose was to split the functionality as below:
- direct unauthenticated proxy for every day usage ("proxy")
- hopping through Apache which provides http authentication for sporadic 
testing use only ("aproxy")

What are you actually trying to achieve here?
The big picture is we need to test some code against various proxy 
scenarios (http, https, authenticated, unauthenticated).

ATM we only have http authentication.
I would imagine real live proxy setups use encrypted https for 
authentication more often than plain text http.

Am I correct with my assumption?

If that's the case then my goal is to get https authentication working 
as well.
If there is no way I can easily get it to work with the existing config 
I guess I can set up a new Apache hop.

Authenticating over https only and called e.g. "bproxy".
Would that make most sense?

Thanks
Adam
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


[squid-users] https proxy authentication

2018-03-29 Thread Adam Weremczuk

Hi all,

I have a solution in place with a dedicated squid LXC container (v 
3.1.20-2.2).

Both http and https proxy run on default port 3128.
Https in tunneled in http using CONNECT.
There is no authentication in place and both are working fine.

For testing purposes we also use an Apache (v 2.2.22-13) proxy forwarder 
running on a different machine on port 80 as "aproxy".


Config below:

/# Authenticated proxy for testing purposes//
//# We forward http/s requests to the local proxy server//
//ProxyRequests On//
//ProxyVia On//
//ProxyRemote http http://proxy.example.internal:3128//
//ProxyRemote https http://proxy.example.internal:3128//
//ProxyDomain .example.internal//
//NoProxy .example.internal 192.168.x.x/22//

//   Order Deny,Allow//
//   Deny from all//
//   Allow from 192.168.x.x/22//
//   AuthType Basic//
//   AuthName ProxyAuth//
//   AuthUserFile /etc/apache2/proxypasswd//
//   Require valid-user//
///

This is working as expected for http requests:

1. Unauthenticated (failure):

/$ http_proxy=http://aproxy:80//
//$ wget http://example.com 2>&1 | grep response//
//Proxy request sent, awaiting response... 407 Proxy Authentication 
Required/


2. Username with password (success):

/$ http_proxy=http://username1:password@aproxy:80//
//$ wget http://example.com 2>&1 | grep response//
//Proxy request sent, awaiting response... 200 OK/

3. Username without password (success):
/
//$ http_proxy=http://username2:@aproxy:80//
//$ wget http://example.com 2>&1 | grep response//
//Proxy request sent, awaiting response... 200 OK/

My *PROBLEM* is I can't find a way to use authentication for proxied 
https requests.


From a LAN client trying to establish connection:

/$ echo $http_proxy//
//http://username1:password@aproxy:80//
/

/$ echo $https_proxy//
//http://username1:password@aproxy:80//
/

/$ wget --server-response https://example.com 2>&1//
//--2018-03-29 15:20:44--  https://example.com///
//Resolving aproxy (aproxy)... 192.168.x.x//
//Connecting to aproxy (aproxy)|192.168.x.x|:80... connected.//
//Proxy tunneling failed: Service Temporarily UnavailableUnable to 
establish SSL connection./


On "aproxy" only one line in apache error log (even in debug mode):

/[Thu Mar 29 15:21:59 2018] [error] (111)Connection refused: proxy: 
CONNECT: attempt to connect to 93.184.216.34:443 (example.com) failed/


Nothing is logged on squid "proxy" which is the next hop.

What's the easiest way to enable authenticated https proxying?
I don't want to enable it for our main production proxy:3128
Or maybe it's already supposed to work but I'm missing something?

Please advise.

Thanks
Adam

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users