Help troubleshooting proxy<-->client https

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Help troubleshooting proxy<-->client https

Masha Lifshin
Hello Dear Squid Users,

I am trying to configure my Squid 4.0.17 to use an https connection between the client and the proxy.  I have added an https_port directive to squid.conf, but it must be misconfigured. When I test with a dev version of curl that supports https proxies, I am getting ERR_PROTOCOL_UNKNOWN errors.  Below is the curl output, my squid.conf, and access.log and cache.log snippets.

I appreciate any insights that you can offer.  Thank you very much,
-Masha


----------------------------------------
curl output
----------------------------------------
* Rebuilt URL to: https://github.com/
*   Trying 54.210.69.61...
* TCP_NODELAY set
* Connected to proxy.somwhere.com (54.210.69.61) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
* Closing connection 0
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

----------------------------------------
squid.conf
----------------------------------------
acl localnet src 10.0.0.0/8     # RFC1918 possible internal network
acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl localnet src fc00::/7   # RFC 4193 local private network range
acl localnet src fe80::/10  # RFC 4291 link-local (directly plugged) machines

acl SSL_ports port 443
acl Safe_ports port 80          # http
acl Safe_ports port 81          # http
acl Safe_ports port 800         # http
acl Safe_ports port 8000        # http
acl Safe_ports port 8080        # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl SSL method CONNECT
acl CONNECT method CONNECT

# Only allow cachemgr access from localhost
http_access allow manager to_localhost
http_access deny manager

# Deny requests to certain unsafe ports
http_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

http_access deny to_localhost

# ICAP CONFIG
icp_access deny all
htcp_access deny all

http_port 172.30.0.67:443 ssl-bump cert=/path/to/some.cert.pem generate-host-certificates=on dynamic_cert_mem_cache_size=4MB tls-dh=/usr/local/squid/etc/dhparam.pem
https_port 172.30.0.67:443 cert=/path/to/other.cert.pem cipher=EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
tls_outgoing_options options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE cipher=EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS

acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump bump all

access_log stdio:/usr/local/squid/var/log/access.log custom
cache_store_log stdio:/usr/local/squid/var/log/store.log custom
log_mime_hdrs on

pid_filename /usr/local/squid/var/run/custom-squid.pid

# Leave coredumps in the first cache dir
coredump_dir /usr/local/squid/var/cache

# Add any of your own refresh_pattern entries above these.
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
refresh_pattern .               0       20%     4320

request_header_access Proxy-Authenticate deny all
request_header_access Proxy-Authentication-Info deny all
request_header_access Proxy-Authorization deny all
request_header_access Proxy-Connection deny all
request_header_access Proxy-support deny all
request_header_access custom-version deny all
request_header_access custom-watermark deny all
request_header_access custom-token deny all
request_header_access custom-parent-host deny all
request_header_access Via deny all
request_header_access X-Cache deny all
request_header_access X-Cache-Lookup deny all
request_header_access X-Forwarded-For deny all
reply_header_access X-XSS-Protection deny all
request_header_access Other allow all

cache_mgr [hidden email]
mail_from [hidden email]
icap_enable on
icap_preview_enable on
icap_preview_size 1024
icap_default_options_ttl 60
icap_persistent_connections on
icap_send_client_ip on
icap_send_client_username on
icap_client_username_header X-Client-Username
icap_client_username_encode off

ecap_enable on
loadable_modules /usr/local/squid/modules/libcustom_ecap.so
ecap_service custom_validate_req reqmod_precache ecap://somewhere.com/ecap/services/validate routing=on bypass=off
ecap_service custom_validate_resp respmod_precache ecap://somewhere.com/ecap/services/validate routing=on bypass=off
#adaptation_access custom_validate allow all

icap_service custom_req reqmod_precache routing=on icap://127.0.0.1:1344/custom_req
icap_service custom_resp respmod_precache routing=on icap://127.0.0.1:1344/custom_resp
forwarded_for delete

# Define a service set for requests. The first service (eCAP) will
# process the request if the API token is in the local cache, and the
# user has the "Access Only" preference set. Otherwise eCAP will abort,
# causing Squid to fail over to ICAP to handle the request.
adaptation_service_set custom_req_set custom_validate_req custom_req
adaptation_service_set custom_resp_set custom_validate_resp custom_resp

adaptation_access custom_req_set allow all
adaptation_access custom_resp_set allow all

# Never stop trying to talk to the ICAP server, no matter how many times it fails.
icap_service_failure_limit -1

# Squid uses numeric categories to control logging.
# Interesting categories:
#   93        ICAP
# debug_options ALL,3 44,0 23,0 40,0 73,0 93,3
debug_options  ALL,1 11,2 74,9,93,3
(END)



----------------------------------------
access.log
----------------------------------------
 [26/May/2017:05:35:50 +0000] "NONE error:invalid-request HTTP/1.1" 400 3824



----------------------------------------
cache.log
----------------------------------------
2017/05/26 05:35:50.115 kid1| 74,9| RequestParser.cc(359) doParse: Parse buf={length=517, data='
2017/05/26 05:35:50.115 kid1| 74,5| RequestParser.cc(284) parseRequestFirstLine: parsing possible request: buf.length=517
2017/05/26 05:35:50.115 kid1| 74,9| RequestParser.cc(285) parseRequestFirstLine:
2017/05/26 05:35:50.115 kid1| 74,5| RequestParser.cc(382) doParse: request-line: retval -1: line={517, data='
2017/05/26 05:35:50.115 kid1| 74,5| RequestParser.cc(383) doParse: request-line: method: NONE
2017/05/26 05:35:50.115 kid1| 74,5| RequestParser.cc(384) doParse: request-line: url:
2017/05/26 05:35:50.115 kid1| 74,5| RequestParser.cc(385) doParse: request-line: proto: NONE/0.0
2017/05/26 05:35:50.115 kid1| 74,5| RequestParser.cc(386) doParse: Parser: bytes processed=0
2017/05/26 05:35:50.115 kid1| 11,2| Stream.cc(266) sendStartOfMessage: HTTP Client local=172.30.0.67:443 remote=75.147.129.242:64540 FD 11 flags=1
2017/05/26 05:35:50.115 kid1| 11,2| Stream.cc(267) sendStartOfMessage: HTTP Client REPLY:
---------
HTTP/1.1 400 Bad Request
Server: squid/4.0.17
Mime-Version: 1.0
Date: Fri, 26 May 2017 05:35:50 GMT
Content-Type: text/html;charset=utf-8
Content-Length: 3394
X-Squid-Error: ERR_PROTOCOL_UNKNOWN 0
Vary: Accept-Language
Content-Language: en
X-Cache: MISS from ip-172-30-0-67.ec2.internal
X-Cache-Lookup: NONE from ip-172-30-0-67.ec2.internal:443
Via: 1.1 ip-172-30-0-67.ec2.internal (squid/4.0.17)
Connection: close


----------


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help troubleshooting proxy<-->client https

Alex Rousskov
On 05/26/2017 12:00 AM, Masha Lifshin wrote:
> I have added an https_port directive
> to squid.conf, but it must be misconfigured.

> http_port 172.30.0.67:443 ...
> https_port 172.30.0.67:443 ...

You are right -- your Squid is misconfigured. You cannot use the same
address for two ports. Unfortunately, Squid thinks that port binding
errors are a minor inconvenience and continues running after logging an
error message (that looks like many other benign error messages).

Changing one of the ports will solve the "same address" problem
described above.

Do not use port 443 for http_port. It makes triage extremely confusing
because port 443 usually implies SSL. Consider using port 3128 instead.


HTH,

Alex.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help troubleshooting proxy<-->client https

Masha Lifshin
In reply to this post by Masha Lifshin
Dear Alex,

Thank you very much for your helpful reply.

I have a follow up question.  What I am trying to achieve is an https connection between the client and squid proxy, as well as listen on port 80 for http traffic, on port 443 for ssl traffic, and apply ssl-bump to the ssl traffic.  I am having trouble expressing this in my config. Would the http_port and https_port directives need to look like this?

http_port <ip_address>:80 ssl-bump cert=/path/to/some.cert.pem generate-host-certificates=on dynamic_cert_mem_cache_size=4MB tls-dh=/usr/local/squid/etc/dhparam.pem
https_port <ip_address>:443 cert=/path/to/other.cert.pem cipher=EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS

Also wondering what, if any, are the security issues with using port 80 for the http traffic?

Thank you,
-Masha

On Fri, May 26, 2017 at 7:19 AM, Alex Rousskov <[hidden email]> wrote:
On 05/26/2017 12:00 AM, Masha Lifshin wrote:
> I have added an https_port directive
> to squid.conf, but it must be misconfigured.

> http_port 172.30.0.67:443 ...
> https_port 172.30.0.67:443 ...

You are right -- your Squid is misconfigured. You cannot use the same
address for two ports. Unfortunately, Squid thinks that port binding
errors are a minor inconvenience and continues running after logging an
error message (that looks like many other benign error messages).

Changing one of the ports will solve the "same address" problem
described above.

Do not use port 443 for http_port. It makes triage extremely confusing
because port 443 usually implies SSL. Consider using port 3128 instead.


HTH,

Alex.




_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help troubleshooting proxy<-->client https

Alex Rousskov
On 05/31/2017 02:42 PM, Masha Lifshin wrote:

> What I am trying to achieve is


> 1. an https connection between the client and squid proxy, as well as

> 2. listen on port 80 for http traffic,

> 3. on port 443 for ssl traffic, and

> 4. apply ssl-bump to the ssl traffic.


If I parsed your query correctly, and by "listen" you mean "intercept",
and you want to apply SslBump to proxied SSL traffic on all ports, then
it looks like you will need three ports, each doing ssl-bump. In other
words, instead of

> http_port 80 ssl-bump cert=some.cert.pem ...
> https_port 443 cert=other.cert.pem ...

You will need something like this:

# HTTPS proxy; clients establish TLS connections to 31443 (your item #1)
https_port 31443 ssl-bump ...

# HTTP-intercepting proxy (your item #2)
http_port 80 intercept ssl-bump ...

# SSL-intercepting proxy (your item #3)
https_port 443 intercept ssl-bump ...

You may need "tproxy" instead of "intercept", depending on how you are
intercepting/forwarding traffic.

The actual port numbers do no matter.


> Also wondering what, if any, are the security issues with using port 80
> for the http traffic?

Anybody with access to that traffic will be able to easily see
everything and, with a monumental effort, potentially occasionally
modify unencrypted traffic, including plain CONNECT requests that
establish secure channels.


HTH,

Alex.


> On Fri, May 26, 2017 at 7:19 AM, Alex Rousskov wrote:
>
>     On 05/26/2017 12:00 AM, Masha Lifshin wrote:
>     > I have added an https_port directive
>     > to squid.conf, but it must be misconfigured.
>
>     > http_port 172.30.0.67:443 <http://172.30.0.67:443> ...
>     > https_port 172.30.0.67:443 <http://172.30.0.67:443> ...
>
>     You are right -- your Squid is misconfigured. You cannot use the same
>     address for two ports. Unfortunately, Squid thinks that port binding
>     errors are a minor inconvenience and continues running after logging an
>     error message (that looks like many other benign error messages).
>
>     Changing one of the ports will solve the "same address" problem
>     described above.
>
>     Do not use port 443 for http_port. It makes triage extremely confusing
>     because port 443 usually implies SSL. Consider using port 3128 instead.
>
>
>     HTH,
>
>     Alex.
>
>
>

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help troubleshooting proxy<-->client https

Masha Lifshin
Thank you, very helpful.  Some more clarifying questions for you.

Sorry for the imprecise language, I mean not interception but rather accepting connections to that port.  Our browsers will be explicitly configured to connect our proxy, so I believe that is not interception?

If we want to only allow encrypted traffic between the browser and proxy, does that mean we'd only want to use the following line from your example?

# HTTPS proxy; clients establish TLS connections to 31443 (your item #1)
https_port 31443 ssl-bump ...

Once a handshake is done and tls connection is established here, would it be possible to have all http and https traffic from the browser go through 31443?  So squid would not need to have ports 80 and 443 open?

Thank you,
-Masha


On Wed, May 31, 2017 at 5:10 PM, Alex Rousskov <[hidden email]> wrote:
On 05/31/2017 02:42 PM, Masha Lifshin wrote:

> What I am trying to achieve is


> 1. an https connection between the client and squid proxy, as well as

> 2. listen on port 80 for http traffic,

> 3. on port 443 for ssl traffic, and

> 4. apply ssl-bump to the ssl traffic.


If I parsed your query correctly, and by "listen" you mean "intercept",
and you want to apply SslBump to proxied SSL traffic on all ports, then
it looks like you will need three ports, each doing ssl-bump. In other
words, instead of

> http_port 80 ssl-bump cert=some.cert.pem ...
> https_port 443 cert=other.cert.pem ...

You will need something like this:

# HTTPS proxy; clients establish TLS connections to 31443 (your item #1)
https_port 31443 ssl-bump ...

# HTTP-intercepting proxy (your item #2)
http_port 80 intercept ssl-bump ...

# SSL-intercepting proxy (your item #3)
https_port 443 intercept ssl-bump ...

You may need "tproxy" instead of "intercept", depending on how you are
intercepting/forwarding traffic.

The actual port numbers do no matter.


> Also wondering what, if any, are the security issues with using port 80
> for the http traffic?

Anybody with access to that traffic will be able to easily see
everything and, with a monumental effort, potentially occasionally
modify unencrypted traffic, including plain CONNECT requests that
establish secure channels.


HTH,

Alex.


> On Fri, May 26, 2017 at 7:19 AM, Alex Rousskov wrote:
>
>     On 05/26/2017 12:00 AM, Masha Lifshin wrote:
>     > I have added an https_port directive
>     > to squid.conf, but it must be misconfigured.
>
>     > http_port 172.30.0.67:443 <http://172.30.0.67:443> ...
>     > https_port 172.30.0.67:443 <http://172.30.0.67:443> ...
>
>     You are right -- your Squid is misconfigured. You cannot use the same
>     address for two ports. Unfortunately, Squid thinks that port binding
>     errors are a minor inconvenience and continues running after logging an
>     error message (that looks like many other benign error messages).
>
>     Changing one of the ports will solve the "same address" problem
>     described above.
>
>     Do not use port 443 for http_port. It makes triage extremely confusing
>     because port 443 usually implies SSL. Consider using port 3128 instead.
>
>
>     HTH,
>
>     Alex.
>
>
>




_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help troubleshooting proxy<-->client https

Amos Jeffries
Administrator
On 01/06/17 14:15, Masha Lifshin wrote:
> Thank you, very helpful.  Some more clarifying questions for you.
>
> Sorry for the imprecise language, I mean not interception but rather
> accepting connections to that port.  Our browsers will be explicitly
> configured to connect our proxy, so I believe that is not interception?

Yes, however for HTTP/1.x it is also not the same traffic syntax as port
80 or 443. It is a proxy specific syntax which port 3128 is registered for.


>
> If we want to only allow encrypted traffic between the browser and
> proxy, does that mean we'd only want to use the following line from
> your example?

Depends on what you mean by encrypted in context of the proxy syntax.


>
> # HTTPS proxy; clients establish TLS connections to 31443 (your item #1)
> https_port 31443 ssl-bump ...
>
> Once a handshake is done and tls connection is established here, would
> it be possible to have all http and https traffic from the browser go
> through 31443?  So squid would not need to have ports 80 and 443 open?
>

Think about it as two separate things.

  1) the transport used to get HTTP(S) to the proxy.
   That can be TCP (http_port) or TLS (https_port).

  2) the protocol the browser is talking to some origin on the other
side of the proxy.
  That can be HTTP or HTTPS (aka HTTP-over-TLS).

These layers stack. So Squid supports:

http_port 3128
# HTTP-over-TCP
# HTTPS-over-TCP (aka HTTP-over-TLS-over-TCP)

https_port 3129
# HTTP-over-TLS   (aka HTTP-over-TLS-over-TCP)
# HTTPS-over-TLS (aka HTTP-over-TLS-over-TLS-over-TCP)


SSL-Bump is about decrypting the HTTPS traffic destined to some origin
(not the proxy itself), it has effectively no relation to the transport
(TCP or TLS) used to send that traffic to the proxy. ie. It peeks down
to get the HTTP message layer in those 'aka' stacks.


Amos

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help troubleshooting proxy<-->client https

Alex Rousskov
In reply to this post by Masha Lifshin
On 05/31/2017 08:15 PM, Masha Lifshin wrote:
>
> Sorry for the imprecise language, I mean not interception but rather
> accepting connections to that port.  Our browsers will be explicitly
> configured to connect our proxy, so I believe that is not interception?

You are correct. It is explicit proxying, not interception.


> If we want to only allow encrypted traffic between the browser and
> proxy, does that mean we'd only want to use the following line from your
> example?
>
> # HTTPS proxy; clients establish TLS connections to 31443 (your item #1)
> https_port 31443 ssl-bump ...

Yes.

Again, the actual port number does not matter here as long as the
browser is configured to use the same port. I would not use 3128, 80, or
443 because, to many people, those numbers mean something different than
an "HTTPS proxy" port. My 31443 suggestion is based on an
unregistered(?) port that "looks like" a combination of registered or
well-known ports 3128 and 443. FWIW, many products use ports ending with
443 for similar purposes AFAICT.


> Once a handshake is done and tls connection is established here, would
> it be possible to have all http and https traffic from the browser go
> through 31443?  So squid would not need to have ports 80 and 443 open?

Yes, provided the browser supports HTTPS proxies, of course. Several
popular browsers do, but not all HTTP clients support HTTPS proxies.
Also, it is difficult to configure the popular browsers to do what you
want; the required configuration changes are _not_ available through the
regular browser configuration interface. After you figure browser
configuration out, please consider writing a Squid wiki entry to
document your findings.


Thank you,

Alex.



> On Wed, May 31, 2017 at 5:10 PM, Alex Rousskov wrote:
>
>     On 05/31/2017 02:42 PM, Masha Lifshin wrote:
>
>     > What I am trying to achieve is
>
>
>     > 1. an https connection between the client and squid proxy, as well as
>
>     > 2. listen on port 80 for http traffic,
>
>     > 3. on port 443 for ssl traffic, and
>
>     > 4. apply ssl-bump to the ssl traffic.
>
>
>     If I parsed your query correctly, and by "listen" you mean "intercept",
>     and you want to apply SslBump to proxied SSL traffic on all ports, then
>     it looks like you will need three ports, each doing ssl-bump. In other
>     words, instead of
>
>     > http_port 80 ssl-bump cert=some.cert.pem ...
>     > https_port 443 cert=other.cert.pem ...
>
>     You will need something like this:
>
>     # HTTPS proxy; clients establish TLS connections to 31443 (your item #1)
>     https_port 31443 ssl-bump ...
>
>     # HTTP-intercepting proxy (your item #2)
>     http_port 80 intercept ssl-bump ...
>
>     # SSL-intercepting proxy (your item #3)
>     https_port 443 intercept ssl-bump ...
>
>     You may need "tproxy" instead of "intercept", depending on how you are
>     intercepting/forwarding traffic.
>
>     The actual port numbers do no matter.
>
>
>     > Also wondering what, if any, are the security issues with using port 80
>     > for the http traffic?
>
>     Anybody with access to that traffic will be able to easily see
>     everything and, with a monumental effort, potentially occasionally
>     modify unencrypted traffic, including plain CONNECT requests that
>     establish secure channels.
>
>
>     HTH,
>
>     Alex.
>
>
>     > On Fri, May 26, 2017 at 7:19 AM, Alex Rousskov wrote:
>     >
>     >     On 05/26/2017 12:00 AM, Masha Lifshin wrote:
>     >     > I have added an https_port directive
>     >     > to squid.conf, but it must be misconfigured.
>     >
>     >     > http_port 172.30.0.67:443 <http://172.30.0.67:443>
>     <http://172.30.0.67:443> ...
>     >     > https_port 172.30.0.67:443 <http://172.30.0.67:443>
>     <http://172.30.0.67:443> ...
>     >
>     >     You are right -- your Squid is misconfigured. You cannot use
>     the same
>     >     address for two ports. Unfortunately, Squid thinks that port
>     binding
>     >     errors are a minor inconvenience and continues running after
>     logging an
>     >     error message (that looks like many other benign error messages).
>     >
>     >     Changing one of the ports will solve the "same address" problem
>     >     described above.
>     >
>     >     Do not use port 443 for http_port. It makes triage extremely
>     confusing
>     >     because port 443 usually implies SSL. Consider using port 3128
>     instead.
>     >
>     >
>     >     HTH,
>     >
>     >     Alex.
>     >
>     >
>     >
>
>
>

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help troubleshooting proxy<-->client https

Alex Rousskov
On 06/01/2017 11:29 AM, Alex Rousskov wrote:
> On 05/31/2017 08:15 PM, Masha Lifshin wrote:
>> If we want to only allow encrypted traffic between the browser and
>> proxy, does that mean we'd only want to use the following line from your
>> example?

>> # HTTPS proxy; clients establish TLS connections to 31443 (your item #1)
>> https_port 31443 ssl-bump ...

> Yes.


* HTTPS proxy is a rarely used feature that works well for some.
* SslBump is a frequently used feature that works well enough for some.

Disclaimer: I do not know of anybody using the _combination_ of the
above two features, and I do not recall whether such a combination is
already supported. Please post once you figure it out.

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help troubleshooting proxy<-->client https

Alex Rousskov
On 06/01/2017 01:26 PM, Alex Rousskov wrote:
> On 06/01/2017 11:29 AM, Alex Rousskov wrote:

> * HTTPS proxy is a rarely used feature that works well for some.
> * SslBump is a frequently used feature that works well enough for some.

> Disclaimer: I do not know of anybody using the _combination_ of the
> above two features, and I do not recall whether such a combination is
> already supported. Please post once you figure it out.

I just confirmed that Squid does _not_ support the above combination. An
https_port with an ssl-bump option requires either "tproxy" or
"intercept" mode, which are both incompatible with HTTPS proxy mode.
Until the above combination is supported, you have to pick between using
HTTPS proxy and using SslBump.

http://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help troubleshooting proxy<-->client https

Masha Lifshin
Thank you very much Amos and Alex for the helpful explanations, high level of detail, and for tracking down that this combo is not possible at this time.

We're going to evaluate what to do next with this info.  I'll probably be following up with more questions soon.
-M

On Fri, Jun 2, 2017 at 9:05 AM, Alex Rousskov <[hidden email]> wrote:
On 06/01/2017 01:26 PM, Alex Rousskov wrote:
> On 06/01/2017 11:29 AM, Alex Rousskov wrote:

> * HTTPS proxy is a rarely used feature that works well for some.
> * SslBump is a frequently used feature that works well enough for some.

> Disclaimer: I do not know of anybody using the _combination_ of the
> above two features, and I do not recall whether such a combination is
> already supported. Please post once you figure it out.

I just confirmed that Squid does _not_ support the above combination. An
https_port with an ssl-bump option requires either "tproxy" or
"intercept" mode, which are both incompatible with HTTPS proxy mode.
Until the above combination is supported, you have to pick between using
HTTPS proxy and using SslBump.

http://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F

Alex.



_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Loading...