[squid-users] How to configure a "proxy home" page ?

Yuri yvoinov at gmail.com
Fri Mar 16 13:15:22 UTC 2018


I think, you should dig in this direction:

#    acl aclname ssl_error errorname
#      # match against SSL certificate validation error [fast]
#      #
#      # For valid error names see in
/usr/local/squid/share/errors/templates/error-details.txt
#      # template file.
#      #
#      # The following can be used as shortcuts for certificate properties:
#      #  [ssl::]certHasExpired: the "not after" field is in the past
#      #  [ssl::]certNotYetValid: the "not before" field is in the future
#      #  [ssl::]certUntrusted: The certificate issuer is not to be trusted.
#      #  [ssl::]certSelfSigned: The certificate is self signed.
#      #  [ssl::]certDomainMismatch: The certificate CN domain does not
#      #         match the name the name of the host we are connecting to.
#      #
#      # The ssl::certHasExpired, ssl::certNotYetValid,
ssl::certDomainMismatch,
#      # ssl::certUntrusted, and ssl::certSelfSigned can also be used as
#      # predefined ACLs, just like the 'all' ACL.
#      #
#      # NOTE: The ssl_error ACL is only supported with sslproxy_cert_error,
#      # sslproxy_cert_sign, and sslproxy_cert_adapt options.
#

...

#  TAG: sslproxy_cert_error
#    Use this ACL to bypass server certificate validation errors.
#
#    For example, the following lines will bypass all validation errors
#    when talking to servers for example.com. All other
#    validation errors will result in ERR_SECURE_CONNECT_FAIL error.
#
#        acl BrokenButTrustedServers dstdomain example.com
#        sslproxy_cert_error allow BrokenButTrustedServers
#        sslproxy_cert_error deny all
#
#    This clause only supports fast acl types.
#    See http://wiki.squid-cache.org/SquidFaq/SquidAcl for details.
#    Using slow acl types may result in server crashes
#
#    Without this option, all server certificate validation errors
#    terminate the transaction to protect Squid and the client.
#
#    SQUID_X509_V_ERR_INFINITE_VALIDATION error cannot be bypassed
#    but should not happen unless your OpenSSL library is buggy.
#
#    SECURITY WARNING:
#        Bypassing validation errors is dangerous because an
#        error usually implies that the server cannot be trusted
#        and the connection may be insecure.
#
#    See also: sslproxy_flags and DONT_VERIFY_PEER.
#Default:
# Server certificate errors terminate the transaction.

#  TAG: sslproxy_cert_sign
#
#        sslproxy_cert_sign <signing algorithm> acl ...
#
#        The following certificate signing algorithms are supported:
#
#       signTrusted
#        Sign using the configured CA certificate which is usually
#        placed in and trusted by end-user browsers. This is the
#        default for trusted origin server certificates.
#
#       signUntrusted
#        Sign to guarantee an X509_V_ERR_CERT_UNTRUSTED browser error.
#        This is the default for untrusted origin server certificates
#        that are not self-signed (see ssl::certUntrusted).
#
#       signSelf
#        Sign using a self-signed certificate with the right CN to
#        generate a X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT error in the
#        browser. This is the default for self-signed origin server
#        certificates (see ssl::certSelfSigned).
#
#    This clause only supports fast acl types.
#
#    When sslproxy_cert_sign acl(s) match, Squid uses the corresponding
#    signing algorithm to generate the certificate and ignores all
#    subsequent sslproxy_cert_sign options (the first match wins). If no
#    acl(s) match, the default signing algorithm is determined by errors
#    detected when obtaining and validating the origin server certificate.
#
#    WARNING: SQUID_X509_V_ERR_DOMAIN_MISMATCH and
ssl:certDomainMismatch can
#    be used with sslproxy_cert_adapt, but if and only if Squid is bumping a
#    CONNECT request that carries a domain name. In all other cases (CONNECT
#    to an IP address or an intercepted SSL connection), Squid cannot detect
#    the domain mismatch at certificate generation time when
#    bump-server-first is used.
#Default:
# none

and, may be, this:

#  TAG: sslproxy_cert_adapt
#   
#    sslproxy_cert_adapt <adaptation algorithm> acl ...
#
#    The following certificate adaptation algorithms are supported:
#
#       setValidAfter
#        Sets the "Not After" property to the "Not After" property of
#        the CA certificate used to sign generated certificates.
#
#       setValidBefore
#        Sets the "Not Before" property to the "Not Before" property of
#        the CA certificate used to sign generated certificates.
#
#       setCommonName or setCommonName{CN}
#        Sets Subject.CN property to the host name specified as a
#        CN parameter or, if no explicit CN parameter was specified,
#        extracted from the CONNECT request. It is a misconfiguration
#        to use setCommonName without an explicit parameter for
#        intercepted or tproxied SSL connections.
#       
#    This clause only supports fast acl types.
#
#    Squid first groups sslproxy_cert_adapt options by adaptation algorithm.
#    Within a group, when sslproxy_cert_adapt acl(s) match, Squid uses the
#    corresponding adaptation algorithm to generate the certificate and
#    ignores all subsequent sslproxy_cert_adapt options in that algorithm's
#    group (i.e., the first match wins within each algorithm group). If no
#    acl(s) match, the default mimicking action takes place.
#
#    WARNING: SQUID_X509_V_ERR_DOMAIN_MISMATCH and
ssl:certDomainMismatch can
#    be used with sslproxy_cert_adapt, but if and only if Squid is bumping a
#    CONNECT request that carries a domain name. In all other cases (CONNECT
#    to an IP address or an intercepted SSL connection), Squid cannot detect
#    the domain mismatch at certificate generation time when
#    bump-server-first is used.
#Default:
# none




16.03.2018 19:09, Nicolas Kovacs пишет:
> Le 16/03/2018 à 13:43, Yuri a écrit :
>> I guess better way to do this is create special ACL to catch exactly 
>> certificate error and then redirect by 302 using deny_info to proxy
>> page with explanation and certificate.
> This sounds like the way to go.
>
> I just removed the root certificate from one of the clients and then
> tried to open a few HTTPS sites. Invariably, I get the follwoing error
> code :
>
> SEC_ERROR_UNKNOWN_ISSUER
Keep in mind: this is significantly wide SSL error. It can occurs also
on some sites with self-signed certs, or, in case of site's root CA is
not in your proxy certificate bundle.
>
> So how would I tell Squid in its own syntax to go to
> http://nestor.microlinux.lan when it encounters such an error ? Is this
> a trivial task, or more complicated to put in practice ?
Mmmmmmmmm. It seems not too complicated, however, AFAIK, nobody done
this yet.
>
> BTW, this would be the last piece in my puzzle, and my installation
> would be perfect if I got this to work.
>
> Cheers,
>
> Niki
>

-- 
"C++ seems like a language suitable for firing other people's legs."

*****************************
* C++20 : Bug to the future *
*****************************

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: OpenPGP digital signature
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20180316/7e23fb95/attachment.sig>


More information about the squid-users mailing list