Roberto
We all need to have a deep think about what https *really* *really*
means.
* The aim of SSL/TLS is to ensure confidentiality from one point to
another
* In a browser, there is a trust store of Certification Authorities and
a SSL/TLS certificate that is signed by a CA is trusted if signed by a
trusted CA
At this point, you could substitute a certificate from another CA,
using splice.
* There are standards such as HPKP - https://developer.mozilla.org/en-U
S/docs/Web/HTTP/Public_Key_Pinning .
This is why you cannot subvert Google and other sites that take
additional steps to ensure that no one is attempting to break the
promise that SSL/TLS is designed for.
If I put up a website and I want to guarantee that the connection
between my website and the end user is secure then I would not be happy
if I found out that someone was breaking that link. Using splice is an
attempt to break that link.
Have a deep think about what you are trying to do - whatever it is.
Cheers
Jon
On Fri, 2017-11-03 at 10:47 -0400, Yaroslav Samoylenko wrote:
> Public or private CA, the issue will persist.
>
> On Nov 3, 2017 8:39 AM, "Roberto Carna"
> wrote:
>
> > OK Jon, thanks for your time and explanation.
> >
> > So a last qustion please: now I put in Squid of pfSense a private
> > CA
> > certificate...is it the same if I put a public CA certificate? Will
> > I
> > experience the same HTTPS behaviour related to Chrome and Firefox?
> >
> > Thanks a lot again.
> >
> > ROBERTO
> >
> > 2017-11-02 20:47 GMT-03:00 Jon Gerdes :
> > > Roberto
> > >
> > > NFF: Product working as designed
> > >
> > > When you use splice, you are doing a Man In The Middle (MitM)
> > > attack on
> > > your own users. Chrome is a Google product and they have enabled
> > > https
> > > ://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning and other things
> > > to
> > > detect this sort of thing.
> > >
> > > This could be seen as an abuse by Google https://www.troyhunt.com
> > > /bypas
> > > sing-browser-security-warnings-with-pseudo-password-fields/ or
> > > you
> > > could consider that end users should have an expectation of
> > > privacy by
> > > default. For example, what if your users do on line banking
> > > through
> > > your proxy? You could easily grab usernames and passwords and
> > > other
> > > personal details or worse if you abuse the trust that SSL/TLS
> > > should
> > > allow.
> > >
> > > Think very hard about the implications of attempting to break the
> > > contract that SSL/TLS is designed to provide - end to end
> > > encryption
> > > with no tampering and guaranteed privacy.
> > >
> > > Cheers
> > > Jon
> > >
> > >
> > >
> > >
> > > On Thu, 2017-11-02 at 12:00 -0300, Roberto Carna wrote:
> > > > People, I have pfSEnse 2.4 with Squid and Squidguard.
> > > >
> > > > I enable HTTP transparent proxy and SSL filtering with Splice
> > > > All.
> > > >
> > > > From our Android cell phones, if we use Firefox TO NAVIGATE
> > > > everything
> > > > is OK, but if we use Chrome we can't go to Google and some
> > > > other
> > > > HTTPS
> > > > sites.
> > > >
> > > > We reviewed firewall rules, NAT and denied target categories
> > > > and
> > > > everything seems OK.
> > > >
> > > > What can be the problem with Chrome ???
> > > >
> > > > Thanks a lot,
> > > >
> > > > ROBERTO
> > > > ___
> > > > pfSense mailing list
> > > > https://lists.pfsense.org/mailman/listinfo/list
> > > > Support the project with Gold! https://pfsense.org/gold
> > >
> > > ___
> > > pfSense mailing list
> > > https://lists.pfsense.org/mailman/listinfo/list
> > > Support the project with Gold! https://pfsense.org/gold
> >
> > ___
> > pfSense mailing list
> > https://lists.pfsense.org/mailman/listinfo/list
> > Support the project with Gold! https://pfsense.org/gold
> >
>
> ___
> pfSense mailing list
> https://lists.pfsense.org/mailman/listinfo/list
> Support the project with Gold! https://pfsense.org/gold
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold