3. Install the certificate in the web browser (Firefox does it
automatically)

4. Surf the web

Now I wonder if there is a way to configure this page as a "proxy home
page" of some sorts. User who don't have the certificate installed
normally get a big fat HTTPS error as soon as they connect to a secure
site. So what I'd like to do is redirect "new" traffic to
http://nestor.microlinux.lan, which also explains what is happening.

I don't really know how to go about that, or if it is even possible.
Maybe some basic form of authentication ?

Re: How to configure a "proxy home" page ?

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.

Sadly, however I have no full solution for this logic (we're simple
install proxy certificate manually), but idea exists ;)

16.03.2018 16:37, Nicolas Kovacs пишет:

> Hi,
>
> I have Squid + SquidGuard + SquidAnalyzer running on my LAN server as a
> transparent cache + filtering proxy, and it's working real nicely.
>
> When a client in my company wants to connect to the wifi, all he or she
> has to do is this:
>
> 1. Connect to http://nestor.microlinux.lan>
> 2. Download the nestor.microlinux.lan.der certificate
>
> 3. Install the certificate in the web browser (Firefox does it
> automatically)
>
> 4. Surf the web
>
> Now I wonder if there is a way to configure this page as a "proxy home
> page" of some sorts. User who don't have the certificate installed
> normally get a big fat HTTPS error as soon as they connect to a secure
> site. So what I'd like to do is redirect "new" traffic to
> http://nestor.microlinux.lan, which also explains what is happening.
>
> I don't really know how to go about that, or if it is even possible.
> Maybe some basic form of authentication ?
>
> Any suggestion ?
>
> Cheers,
>
> Niki

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

Re: How to configure a "proxy home" page ?

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

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 ?

BTW, this would be the last piece in my puzzle, and my installation
would be perfect if I got this to work.

Re: How to configure a "proxy home" page ?

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."

Re: How to configure a "proxy home" page ?

You can use a "splash page" concept which will contain a test page that will try to verify if the client has the root ca certificate installed.
I have created and published an example at:
https://github.com/elico/ca-cert-test-page

If the client will first try to access an http site it will work but if the client will try https site it will not work but once the client will get pass the error page he will be able to get instructions on how and what to install.

3. Install the certificate in the web browser (Firefox does it
automatically)

4. Surf the web

Now I wonder if there is a way to configure this page as a "proxy home
page" of some sorts. User who don't have the certificate installed
normally get a big fat HTTPS error as soon as they connect to a secure
site. So what I'd like to do is redirect "new" traffic to
http://nestor.microlinux.lan, which also explains what is happening.

I don't really know how to go about that, or if it is even possible.
Maybe some basic form of authentication ?

Re: How to configure a "proxy home" page ?

PC browsers non-required automated installers for CA. In it all simple
do by JS directly from page.

Can you do automated installer for mobile clients? iPhones, Android? For
both - mobile browsers and apps as well?

The problem is not install proxy CA. The problem is identify client has
no proxy CA and redirect, and do it only one time.

Splash is perfect idea, but it will execute too often.

So, require more elegant solution.

25.03.2018 15:29, Eliezer Croitoru пишет:

> Hey Nicolas,
>
> You can use a "splash page" concept which will contain a test page that will try to verify if the client has the root ca certificate installed.
> I have created and published an example at:
> https://github.com/elico/ca-cert-test-page>
> And a real usage at:
> https://cert.rimon.net.il/>
> If the client will first try to access an http site it will work but if the client will try https site it will not work but once the client will get pass the error page he will be able to get instructions on how and what to install.
>
> Will it work for your environment?
>
> Eliezer
>
> ----
> Eliezer Croitoru
> Linux System Administrator
> Mobile: +972-5-28704261
> Email: [hidden email]>
>
> -----Original Message-----
> From: squid-users <[hidden email]> On Behalf Of Nicolas Kovacs
> Sent: Friday, March 16, 2018 12:37
> To: [hidden email]> Subject: [squid-users] How to configure a "proxy home" page ?
>
> Hi,
>
> I have Squid + SquidGuard + SquidAnalyzer running on my LAN server as a
> transparent cache + filtering proxy, and it's working real nicely.
>
> When a client in my company wants to connect to the wifi, all he or she
> has to do is this:
>
> 1. Connect to http://nestor.microlinux.lan>
> 2. Download the nestor.microlinux.lan.der certificate
>
> 3. Install the certificate in the web browser (Firefox does it
> automatically)
>
> 4. Surf the web
>
> Now I wonder if there is a way to configure this page as a "proxy home
> page" of some sorts. User who don't have the certificate installed
> normally get a big fat HTTPS error as soon as they connect to a secure
> site. So what I'd like to do is redirect "new" traffic to
> http://nestor.microlinux.lan, which also explains what is happening.
>
> I don't really know how to go about that, or if it is even possible.
> Maybe some basic form of authentication ?
>
> Any suggestion ?
>
> Cheers,
>
> Niki

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

Re: How to configure a "proxy home" page ?

Le 25/03/2018 à 13:08, Yuri a écrit :
> The problem is not install proxy CA. The problem is identify client
> has no proxy CA and redirect, and do it only one time.

That is exactly the problem. And I have yet to find a solution for that.

Current method is instruct everyone - with a printed paper in the office
- to connect to proxy.company-name.lan and then get further instructions
from the page. This works, but an automatic splash page would be more
elegant.

Re: How to configure a "proxy home" page ?

25.03.2018 17:46, Nicolas Kovacs пишет:
> Le 25/03/2018 à 13:08, Yuri a écrit :
>> The problem is not install proxy CA. The problem is identify client
>> has no proxy CA and redirect, and do it only one time.
> That is exactly the problem. And I have yet to find a solution for that.
>
> Current method is instruct everyone - with a printed paper in the office
> - to connect to proxy.company-name.lan and then get further instructions
> from the page. This works, but an automatic splash page would be more
> elegant.
Splash

Re: How to configure a "proxy home" page ?

>Le 25/03/2018 à 13:08, Yuri a écrit :
>> The problem is not install proxy CA. The problem is identify client
>> has no proxy CA and redirect, and do it only one time.

On 25.03.18 13:46, Nicolas Kovacs wrote:
>That is exactly the problem. And I have yet to find a solution for that.
>
>Current method is instruct everyone - with a printed paper in the office
>- to connect to proxy.company-name.lan and then get further instructions
>from the page. This works, but an automatic splash page would be more
>elegant.

impossible and unsafe. The CA must be installed before such splash page shows
up and in such case the splash page is irelevant.

Re: How to configure a "proxy home" page ?

25.03.2018 18:42, Matus UHLAR - fantomas пишет:

>> Le 25/03/2018 à 13:08, Yuri a écrit :
>>> The problem is not install proxy CA. The problem is identify client
>>> has no proxy CA and redirect, and do it only one time.
>
> On 25.03.18 13:46, Nicolas Kovacs wrote:
>> That is exactly the problem. And I have yet to find a solution for that.
>>
>> Current method is instruct everyone - with a printed paper in the office
>> - to connect to proxy.company-name.lan and then get further instructions
>> from the page. This works, but an automatic splash page would be more
>> elegant.
>
> impossible and unsafe. The CA must be installed before such splash
> page shows

Possible. "Safe/Unsafe" should not be discussion when SSL Bump

implemented already.
> up and in such case the splash page is irelevant.
>
> If you have windows domain, you can force security policy through it.
In enterprise environment with AD, yes. But hardly in service provider's
scenarious.

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

Re: How to configure a "proxy home" page ?

>>> Le 25/03/2018 à 13:08, Yuri a écrit :
>>>> The problem is not install proxy CA. The problem is identify client
>>>> has no proxy CA and redirect, and do it only one time.
>>
>> On 25.03.18 13:46, Nicolas Kovacs wrote:
>>> That is exactly the problem. And I have yet to find a solution for that.
>>>
>>> Current method is instruct everyone - with a printed paper in the office
>>> - to connect to proxy.company-name.lan and then get further instructions
>>> from the page. This works, but an automatic splash page would be more
>>> elegant.

Re: How to configure a "proxy home" page ?

The problem is not install proxy CA.
The problem is identify client
has no proxy CA and redirect, and do it only one time.

On 25.03.18 13:46, Nicolas Kovacs wrote:

That is exactly the problem. And I
have yet to find a solution for that.

Current method is instruct everyone - with a printed paper
in the office
- to connect to proxy.company-name.lan and then get further
instructions
from the page. This works, but an automatic splash page
would be more
elegant.

25.03.2018 18:42, Matus UHLAR - fantomas
пишет:

impossible and unsafe. The CA must be
installed before such splash
page shows

On 25.03.18 18:44, Yuri wrote:

Possible. "Safe/Unsafe" should not be
discussion when SSL Bump
implemented already.

it's possible to install splash page, but not install trusted
authority
certificate. Using such authority on a proxy is the MITM attack
and whole
SSL has been designed to prevent this.

Heh. If SSL designed - why SSL Bump itself possible? ;):-P

without certificate, the browser complains which is a security
measure
against this.

Sure. It should.

up and in such case the splash page is
irelevant.

If you have windows domain, you can force security policy
through it.

In enterprise environment with AD, yes.
But hardly in service provider's
scenarious.

service providers should not do this without users' permission.
at least not in countries where the privacy is guaranteed by law.

Thank you, Captain Obvious. :-)
Enterprises also should get user agreement before do that.
Especially in BYOD scenarious.

All these things are
well known here.The question was about
technical implementation, and not about the well-known truisms
in the field of security and privacy (in most cases of
ephemeral).

Re: How to configure a "proxy home" page ?

In principle, I do not consider as secure the technology that
allows MiTM (even in theory) - anyway, for what purpose.

Since this is so - HTTPS is nothing more than a security theater
with a green lock for calming users.

This does not mean that I do not care about the security and
privacy of users. But I provide it somewhat differently, carefully
protecting the proxy itself, its infrastructure and its cache.

25.03.2018 21:41, Yuri пишет:

25.03.2018 20:32, Matus UHLAR -
fantomas пишет:

Le 25/03/2018 à 13:08, Yuri a écrit
:

The problem is not install proxy
CA. The problem is identify client
has no proxy CA and redirect, and do it only one time.

On 25.03.18 13:46, Nicolas Kovacs wrote:

That is exactly the problem. And I
have yet to find a solution for that.

Current method is instruct everyone - with a printed paper
in the office
- to connect to proxy.company-name.lan and then get
further instructions
from the page. This works, but an automatic splash page
would be more
elegant.

25.03.2018 18:42, Matus UHLAR - fantomas
пишет:

impossible and unsafe. The CA must be
installed before such splash
page shows

On 25.03.18 18:44, Yuri wrote:

Possible. "Safe/Unsafe" should not be
discussion when SSL Bump
implemented already.

it's possible to install splash page, but not install trusted
authority
certificate. Using such authority on a proxy is the MITM attack
and whole
SSL has been designed to prevent this.

Heh. If SSL designed - why SSL Bump itself possible? ;):-P

without certificate, the browser complains which is a security
measure
against this.

Sure. It should.

up and in such case the splash page is
irelevant.

If you have windows domain, you can force security policy
through it.

In enterprise environment with AD, yes.
But hardly in service provider's
scenarious.

service providers should not do this without users' permission.
at least not in countries where the privacy is guaranteed by
law.

Thank you, Captain Obvious. :-)
Enterprises also should get user agreement before do that.
Especially in BYOD scenarious.

All these things
are well known here.The question was
about technical implementation, and not about the well-known
truisms in the field of security and privacy (in most cases of
ephemeral).

Re: How to configure a "proxy home" page ?

Therefore,
please, PLEASE, never mention SSL Bump and security/privacy in
one letter.O:-)

These
are mutually exclusive concepts.

Just like HTTPS and security.

25.03.2018 22:00, Yuri пишет:

In principle, I do not consider as secure the technology that
allows MiTM (even in theory) - anyway, for what purpose.

Since this is so - HTTPS is nothing more than a security
theater with a green lock for calming users.

This does not mean that I do not care about the security and
privacy of users. But I provide it somewhat differently,
carefully protecting the proxy itself, its infrastructure and
its cache.

25.03.2018 21:41, Yuri пишет:

25.03.2018 20:32, Matus UHLAR -
fantomas пишет:

Le 25/03/2018 à 13:08, Yuri a
écrit :

The problem is not install proxy
CA. The problem is identify client
has no proxy CA and redirect, and do it only one time.

On 25.03.18 13:46, Nicolas Kovacs wrote:

That is exactly the problem. And I
have yet to find a solution for that.

Current method is instruct everyone - with a printed
paper in the office
- to connect to proxy.company-name.lan and then get
further instructions
from the page. This works, but an automatic splash page
would be more
elegant.

25.03.2018 18:42, Matus UHLAR -
fantomas пишет:

impossible and unsafe. The CA must
be installed before such splash
page shows

On 25.03.18 18:44, Yuri wrote:

Possible. "Safe/Unsafe" should not be
discussion when SSL Bump
implemented already.

it's possible to install splash page, but not install trusted
authority
certificate. Using such authority on a proxy is the MITM
attack and whole
SSL has been designed to prevent this.

Heh. If SSL designed - why SSL Bump itself possible? ;):-P

without certificate, the browser complains which is a security
measure
against this.

Sure. It should.

up and in such case the splash page
is irelevant.

If you have windows domain, you can force security policy
through it.

In enterprise environment with AD,
yes. But hardly in service provider's
scenarious.

service providers should not do this without users'
permission.
at least not in countries where the privacy is guaranteed by
law.

Thank you, Captain Obvious. :-)
Enterprises also should get user agreement before do that.
Especially in BYOD scenarious.

All these things
are well known here.The question was
about technical implementation, and not about the well-known
truisms in the field of security and privacy (in most cases
of ephemeral).

Re: How to configure a "proxy home" page ?

>
>
> 25.03.2018 20:32, Matus UHLAR - fantomas пишет:
>>>>> Le 25/03/2018 à 13:08, Yuri a écrit :
>>>>>> The problem is not install proxy CA. The problem is identify client
>>>>>> has no proxy CA and redirect, and do it only one time.
>>>>
>>>> On 25.03.18 13:46, Nicolas Kovacs wrote:
>>>>> That is exactly the problem. And I have yet to find a solution for
>>>>> that.
>>>>>
>>>>> Current method is instruct everyone - with a printed paper in the
>>>>> office
>>>>> - to connect to proxy.company-name.lan and then get further
>>>>> instructions
>>>>> from the page. This works, but an automatic splash page would be more
>>>>> elegant.
>>
>>> 25.03.2018 18:42, Matus UHLAR - fantomas пишет:
>>>> impossible and unsafe. The CA must be installed before such splash
>>>> page shows
>>
>> On 25.03.18 18:44, Yuri wrote:
>>> Possible. "Safe/Unsafe" should not be discussion when SSL Bump
>>> implemented already.
>>
>> it's possible to install splash page, but not install trusted authority
>> certificate. Using such authority on a proxy is the MITM attack and
>> whole
>> SSL has been designed to prevent this.
> Heh. If SSL designed - why SSL Bump itself possible? ;):-P

As all our SSL-Bump documentation should be saying:

when TLS is used properly SSL-Bump *does not work*.

A client checking the cert validity and producing _its own_ error page
about missing/unknown/untrusted CA is one of those cases. Since the
client is producing the "page" itself there is no possibility of Squid
replacing that with something else.

Re: How to configure a "proxy home" page ?

I do not know your level of JS or other thing but... a splash page is mearly a transition step.
Since you can check using JS if the certificate is installed you can design it in such a way that it will be almost transparent for the user.
If the JS find's that you can access the test subject site\page then you can just pass the user using java script into the "LOGIN" page and let it move on from it.
The other case is if the user doesn't have the ROOT CA certificate installed on the browser or device.
The splash page is better then any other solution and it's very elegant.
What is required for mobile phones is a set of instructions or a tech support phone...

was merely an example that demonstrated the potential of the detection function.
In production we have a another system based on the source code I introduced before that "clears" a client\user from having the certificate installed on his main device\machine\browser.

Le 25/03/2018 à 13:08, Yuri a écrit :
> The problem is not install proxy CA. The problem is identify client
> has no proxy CA and redirect, and do it only one time.

That is exactly the problem. And I have yet to find a solution for that.

Current method is instruct everyone - with a printed paper in the office
- to connect to proxy.company-name.lan and then get further instructions
from the page. This works, but an automatic splash page would be more
elegant.

Re: How to configure a "proxy home" page ?

The problem is not install proxy CA. The problem is identify client
has no proxy CA and redirect, and do it only one time.

On 25.03.18 13:46, Nicolas Kovacs wrote:

That is exactly the problem. And I have yet to find a solution for
that.
Current method is instruct everyone - with a printed paper in the
office
- to connect to proxy.company-name.lan and then get further
instructions
from the page. This works, but an automatic splash page would be more
elegant.

25.03.2018 18:42, Matus UHLAR - fantomas пишет:

impossible and unsafe. The CA must be installed before such splash
page shows

On 25.03.18 18:44, Yuri wrote:

Possible. "Safe/Unsafe" should not be discussion when SSL Bump
implemented already.

it's possible to install splash page, but not install trusted authority
certificate. Using such authority on a proxy is the MITM attack and
whole
SSL has been designed to prevent this.

Heh. If SSL designed - why SSL Bump itself possible? ;):-P

As all our SSL-Bump documentation should be saying:
when TLS is used properly SSL-Bump *does not work*.
A client checking the cert validity and producing _its own_ error page
about missing/unknown/untrusted CA is one of those cases. Since the
client is producing the "page" itself there is no possibility of Squid
replacing that with something else.

Re: How to configure a "proxy home" page ?

Administrator

On 26/03/18 09:49, Yuri wrote:

>
>
> 26.03.2018 02:45, Amos Jeffries пишет:
>> On 26/03/18 04:41, Yuri wrote:
>>>
>>> 25.03.2018 20:32, Matus UHLAR - fantomas пишет:
>>>>>>> Le 25/03/2018 à 13:08, Yuri a écrit :
>>>>>>>> The problem is not install proxy CA. The problem is identify client
>>>>>>>> has no proxy CA and redirect, and do it only one time.
>>>>>> On 25.03.18 13:46, Nicolas Kovacs wrote:
>>>>>>> That is exactly the problem. And I have yet to find a solution for
>>>>>>> that.
>>>>>>>
>>>>>>> Current method is instruct everyone - with a printed paper in the
>>>>>>> office
>>>>>>> - to connect to proxy.company-name.lan and then get further
>>>>>>> instructions
>>>>>>> from the page. This works, but an automatic splash page would be more
>>>>>>> elegant.
>>>>> 25.03.2018 18:42, Matus UHLAR - fantomas пишет:
>>>>>> impossible and unsafe. The CA must be installed before such splash
>>>>>> page shows
>>>> On 25.03.18 18:44, Yuri wrote:
>>>>> Possible. "Safe/Unsafe" should not be discussion when SSL Bump
>>>>> implemented already.
>>>> it's possible to install splash page, but not install trusted authority
>>>> certificate. Using such authority on a proxy is the MITM attack and
>>>> whole
>>>> SSL has been designed to prevent this.
>>> Heh. If SSL designed - why SSL Bump itself possible? ;):-P
>> As all our SSL-Bump documentation should be saying:
>>
>> when TLS is used properly SSL-Bump *does not work*.
>>
>> A client checking the cert validity and producing _its own_ error page
>> about missing/unknown/untrusted CA is one of those cases. Since the
>> client is producing the "page" itself there is no possibility of Squid
>> replacing that with something else.
> Amos,
>
> squid is irrelevant here. "Used properly" and "Implemented properly",
> and, especially, "Designed properly" - which means "Secure by design",
> like SSH or The Onion Router.
>
> HTTPS is *NOT*.
>

You are missing the point. Sometimes TLS *is* implemented properly.

Squid is very relevant here because it is the agent producing the
un-verifiable certificate. The certificate is un-verifiable exactly
because Squids own CA is being used and the client does not trust that CA.

The problem is not install proxy CA. The problem is identify client
has no proxy CA and redirect, and do it only one time.

On 25.03.18 13:46, Nicolas Kovacs wrote:

That is exactly the problem. And I have yet to find a solution for
that.
Current method is instruct everyone - with a printed paper in the
office
- to connect to proxy.company-name.lan and then get further
instructions
from the page. This works, but an automatic splash page would be more
elegant.

25.03.2018 18:42, Matus UHLAR - fantomas пишет:

impossible and unsafe. The CA must be installed before such splash
page shows

On 25.03.18 18:44, Yuri wrote:

Possible. "Safe/Unsafe" should not be discussion when SSL Bump
implemented already.

it's possible to install splash page, but not install trusted authority
certificate. Using such authority on a proxy is the MITM attack and
whole
SSL has been designed to prevent this.

Heh. If SSL designed - why SSL Bump itself possible? ;):-P

As all our SSL-Bump documentation should be saying:
when TLS is used properly SSL-Bump *does not work*.
A client checking the cert validity and producing _its own_ error page
about missing/unknown/untrusted CA is one of those cases. Since the
client is producing the "page" itself there is no possibility of Squid
replacing that with something else.

You are missing the point. Sometimes TLS *is* implemented properly.
Squid is very relevant here because it is the agent producing the
un-verifiable certificate. The certificate is un-verifiable exactly
because Squids own CA is being used and the client does not trust that CA.

Waaaaaaaa, Amos, why you say "unverifiable"? You can show CA to
users, they can see your PKI by eyes, check fingerprint, read your
CPS ;) Users, in this case, trust not NSA or any abstract CA issuer,
but your personally. Client can trust or do not trust you. But in
case of far far away What-due-call-am-CA client trust them by
default. Why?

Can you do the same checks against, for example, Comodo, or
DigiCert? I think no. You forced to trust them in absentia. "We
swear by my mother, everything is safe with us!"

Do your remember Trustico story?

So, what is more secure? I am here or What-due-call-am-CA there?

The point is not technical. It is rather a matter
of faith.

The Onion Router uses only self-signed in they infrastructure.
We're should not trust'em due to it CA's not signed by global
"trusted" CA? It makes TOR less secure?

The same case here. Security/insecurity is not a matter of
technique. This is a question of man. The car can carry, and can
kill.

However, there is secure by design things. And there is insecure
by design things.

Re: How to configure a "proxy home" page ?

Administrator

On 26/03/18 10:16, Yuri wrote:

>
>
> 26.03.2018 03:02, Amos Jeffries пишет:
>> On 26/03/18 09:49, Yuri wrote:
>>>
>>> 26.03.2018 02:45, Amos Jeffries пишет:
>>>> On 26/03/18 04:41, Yuri wrote:
>>>>> 25.03.2018 20:32, Matus UHLAR - fantomas пишет:
>>>>>>>>> Le 25/03/2018 à 13:08, Yuri a écrit :
>>>>>>>>>> The problem is not install proxy CA. The problem is identify client
>>>>>>>>>> has no proxy CA and redirect, and do it only one time.
>>>>>>>> On 25.03.18 13:46, Nicolas Kovacs wrote:
>>>>>>>>> That is exactly the problem. And I have yet to find a solution for
>>>>>>>>> that.
>>>>>>>>>
>>>>>>>>> Current method is instruct everyone - with a printed paper in the
>>>>>>>>> office
>>>>>>>>> - to connect to proxy.company-name.lan and then get further
>>>>>>>>> instructions
>>>>>>>>> from the page. This works, but an automatic splash page would be more
>>>>>>>>> elegant.
>>>>>>> 25.03.2018 18:42, Matus UHLAR - fantomas пишет:
>>>>>>>> impossible and unsafe. The CA must be installed before such splash
>>>>>>>> page shows
>>>>>> On 25.03.18 18:44, Yuri wrote:
>>>>>>> Possible. "Safe/Unsafe" should not be discussion when SSL Bump
>>>>>>> implemented already.
>>>>>> it's possible to install splash page, but not install trusted authority
>>>>>> certificate. Using such authority on a proxy is the MITM attack and
>>>>>> whole
>>>>>> SSL has been designed to prevent this.
>>>>> Heh. If SSL designed - why SSL Bump itself possible? ;):-P
>>>> As all our SSL-Bump documentation should be saying:
>>>>
>>>> when TLS is used properly SSL-Bump *does not work*.
>>>>
>>>> A client checking the cert validity and producing _its own_ error page
>>>> about missing/unknown/untrusted CA is one of those cases. Since the
>>>> client is producing the "page" itself there is no possibility of Squid
>>>> replacing that with something else.
>>> Amos,
>>>
>>> squid is irrelevant here. "Used properly" and "Implemented properly",
>>> and, especially, "Designed properly" - which means "Secure by design",
>>> like SSH or The Onion Router.
>>>
>>> HTTPS is *NOT*.
>>>
>> You are missing the point. Sometimes TLS *is* implemented properly.
>>
>> Squid is very relevant here because it is the agent producing the
>> un-verifiable certificate. The certificate is un-verifiable exactly
>> because Squids own CA is being used and the client does not trust that CA.
> Waaaaaaaa, Amos, why you say "unverifiable"?

Because that is the situation. The client software cannot silently
verify the certificate nor automatically install the not-trusted CA to
cause that *previous* verification attempt to succeed.

> You can show CA to users,

Er, you are now going in circles.

The initial problem was that it is not possible to verify the cert
automatically *without* showing the user things. Requiring the user to
see something to get around that problem ...