Self Signing Certificate

[Michael Patrick]

Is there a way that we can create a self sign certificate so when the page is secure and blocked it won't show an invalid certificate error? 

[Dime I]

I haven't figured out a way to do that because if you hit a blocked website with https, the certificate is invalid due to the nxfilter block page redirect.

[Michael Patrick]

Yep and I was hoping it could be bypassed with a self signed cert that way people do not put tickets in because they don't understand the page.

[Dime I]

Even if nxfilter had a self sign it wouldn't help because once you hit a blocked https website, the web browser is looking for that site's certificate off nxfilter block page due to the redirect.

Because note that the only time they would get a cert problem is when it is a blocked https site, not http.

Hope im making sense.

[Jinhee]

To have your own SSL certificate read this,

  http://www.nxfilter.org/tutorial.html#custom_ssl

But it's not easy to hide the SSL warning. I didn't do it myself but some people saying that they can do that by having a local certificate server and install your own certificate on every client system. You want to try that much complicated process? Actually I am not so sure if this is possible even. But there are some documents in the Internet talking about this.

[Craig Duff]

IF there was a block page by domain instead of IP option, this issue wouldnt occur.

[Jinhee]

We use cname for domain to domain redirection. On my testing we still get SSL warning for this kind of redirection. How do you think it's possible?

[jeroen...@gmail.com]

I had those issues on machines that have time settings wrong.

With current nxfilter you can have port 443 enabled in the settings, but this still sometimes gives ssl warnings.

Changing the port to 4433 (or whatever) will stop all ssl warnings, but this slows down browsing a little as the browser is waiting for the timeout requesting the redicrected blocked paged (not served on 443 anymore)

But this definitly stops all ssl warnings on the client.

Self signed ssl will never help as there is no valid root or trusted certificate.

With self signed cert you also need a trused root certificate.

On all clients you need to import both.

Only way of setting this up centraly without having to manualy go to all machines is requesting a real ssl certificate

Move nxfilter cfg to port 4433 (or whatever)

Install apache and have it serve ssl pages on 443. Copy the pages from the NXfilter webapp folder into your apache folder.

Request a "real "ssl certificate. There is free services that supply a real ssl.

You need a real domain name.

Search google for ssl for free

[Tim Young]

While this is a slightly older thread, I thought I would post what I did to make this work in Ubuntu.

I used a real certificate for a real machine.

I needed to enable a number of modules:

sudo a2enmod proxy_http

sudo a2enmod ssl

sudo a2enmod proxy

sudo a2enmod proxy_balancer

sudo a2enmod proxy_http

And then I needed to change my default-ssl.conf file (/etc/apache2/sites-available/default-ssl.conf)

<IfModule mod_ssl.c>

        <VirtualHost _default_:443>

                ServerAdmin webmaster@localhost

                ServerName put.your.domain.here

                DocumentRoot /var/www/

            # List of application servers:

            # Usage:

            # ProxyPass / http://[IP Addr.]:[port]/

            # ProxyPassReverse / http://[IP Addr.]:[port]/

            # Example:

            ProxyPreserveHost On

            ProxyPass / http://10.1.2.17:80/block,proxy.jsp

            ProxyPassReverse / http://10.1.2.17:80/block,proxy.jsp

                ErrorLog ${APACHE_LOG_DIR}/error.log

                CustomLog ${APACHE_LOG_DIR}/access.log combined

                SSLEngine on

                SSLCertificateFile      /path/to/your/cert/file

                SSLCertificateKeyFile /path/to/your/private/ssl/key

        </VirtualHost>

</IfModule>

You need to change the /etc/apache2/ports file:

#Listen 80

<IfModule ssl_module>

        Listen 443

</IfModule>

and you need to enable the site:

a2ensite default-ssl

And change the nxfilter to listen on port 8443 (/nxfilter/conf/cfg.properties)

listen_ip = 0.0.0.0

http_port = 80

https_port = 8443

...

I needed to enable apache to start by default:

systemctl enable apache2

I believe that was it.  Hope this helps someone set this up.  NXfilter rocks.

[Jinhee]

Thanks for the sharing. We will keep this post until someone can verify it. I will also try to implement it.

[sup...@kernel.inf.br]

Hi, i tested and doesn't works.

[Jinhee]

When I tested it, it's not working. I was using a self-signed certificate though. But with your proxy based approach, I could think of another one,

  http://wiki.squid-cache.org/Features/DynamicSslCert

We could generate this certificate dynamically using Squid proxy. But according to the document, it says it still has a problem with a self-signed certificate as it can't be trusted by a browser. So not 100% sure about this as well.

[Jinhee]

Another explain on Squid and dynamic certification,

  http://wiki.squid-cache.org/ConfigExamples/Intercept/SslBumpExplicit#Alternative_trust_roots

But even if it's working, if it's this much complicated is it any worth to implement? I am not sure if it's working though. Just giving you an idea.

We have a way of hiding SSL warning using Chrome extension.

  http://nxfilter.org/tutorial.html#agent-nxforward

Though it works only on Chrome, it's a lot simple. Anyway if anyone interested in solving SSL warning problem try Apache + proxy or Squid + dynamic certificate solution.

[Tim Young]

I probably should have explained what the result was.  Instead of an error saying that the webpage is totally dangerous, I get an SSL Certificate error.  With the proxy method, it allows you to click "advanced" and "proceed to this page anyway."  And then, you get to see the blocked page showing the site you were trying to go to and the reason it was blocked.

The second thing I noticed was that, if you do not restart your browser, the certificate is temporarily accepted and it goes straight to the blocked page from there on out.  At least that is what we have been experiencing the last day and a half we had it set up this way.

My target was probably lower than what people were wanting.  I just wanted people to have an option of seeing the blocked error message so they get an explanation of why it is not working at that moment.  (we have a lot of time-based rules)

Hope that helps.  And thanks for all your work on this.

[Jinhee]

OK. Thanks for the explanation. Your suggestion will be helpful to someone anyway.

[sup...@kernel.inf.br]

Oh, fine. Thanks

[jeroen...@gmail.com]

Unless you have a real valid certificate all clients will display the invalid cert error on any NX redirected https blocked page.

But this still gives a faster browser experience then serving no page at all (then you get timeouts.)

The best thing to do I think, as out of the box we will probably be not be able to serve any https redirection page, is implement an option found in IIS:

"require server name indication" and bind that server name to bogus.com with a local self signed certificate.

What does this do on my config (windows 2012): I have set redirection of NXfilter to my windows server ip, and this server gives the blocked pages to the client on http without any problem.

As soon as the client requests a https blocked page, my windows server just denies the request immidiatly. (as it only is allowed to serve bogus.com) So the client does not timeout or give ssl warning page, but just page not found. Without any annoying warning or timeout.

I have been looking to make this "server name identication" working in appache, but so far no luck.
Also I do not know what webserver is behind NXfilter itself and how to config it.
Perhaps Jinhee can comment on this?

[Jinhee]

We use an embedded tomcat. Your solution could be an option. Not for everyone, but for someone.

[jeroen...@gmail.com]

Ok thanks Jinhee,

In my opinion (read mine) I would prefer if you could somehow enable the "server name identication" in your embedded tomcat with a fake ssl certificate.

Perhaps with a tickbox on the gui.

This way all requests to a https blocked page will result in an immidate access denied instead of cert error, and speeds up a lot of browsing.

You can do a test with youtube in Chrome. Having the access denied removes (in my environment) delays of 5 seconds before the movies start.

See it as a feature request.

Thanks for your responses,

Jeroen

[Jinhee]

OK. I will see if we can do that with an embedded tomcat first.

[Jinhee]

Server name indication option is available with Tomcat. However we need to update Tomcat module for that and I don't know if it's configurable on GUI side.

And I found that NxForward has more than 500 users. It means it's working.

  https://chrome.google.com/webstore/detail/nxforward/ohhmhnionmgplhblinhpijfbaelmaojd

Not an option to you?

[jeroen...@gmail.com]

Hi Jinhee,

Could be an option but not all clients are pc based (tablets/iphones) and I would prefer not to touch the clients in any way.

Goal is to centralize.

Thanks for the suggestion.

Jeroen

[Jinhee]

So what you need is to close socket connection immediately when your client tries to connect NxFilter webserver through HTTPS? We may be able to accomplish it without SNI. We can directly modify Tomcat source code. But the problem is how we can exclude th requests to admin GUI. Actually you will have the same problem with SNI though.

[Jinhee]

What did you block when your Youtube video was delayed to start?

[jeroen...@gmail.com]

Hi Jinhee,

I do not remember actualy. As far as I know I do not block anything special regarding domains. I have enabled the ads filter in standard policy.

When I setup NXfilter to serve the "blocked" pages from my windows 2012 server with IIS and HTTPS server name indication enabled, the delay is gone.

If I set the blocked page back to NXfilter itself, the delay is back.

As a reply to your "question" above (close socket immediately)....Yes. as long as you only do this for https and not for http there would be no issue for the gui. I only use http to login to the gui.

Or do I not understand your concern correctly?

Perhaps it is possible to create a setting on the gui that allows the user to serve https blocked pages from a different IP.

Currently there is only one choice (all blocked pages are served from another server)

This way you do not have to rewrite all code in tomcat?

[Tim Young]

Could you have the admin GUI be on port 880, 8443 or something like that?  Then you have port 443 be simply something that gets blocked.  That way default ssl gets rejected, but you can have encrypted admin connections.  I think it should still be an optional setting.  That way people can still go through certificate hoops and get a bit of a blocked message if they desire.  But it gives a very simple option to have it dropped without the ugly error.

[Jinhee]

I think Tim almost got it. Yesterday, I was reading Tomcat source to modify it directly. But I found an easier way. Just listen on 443 for HTTP protocol then we get protocol error instead of getting certificate error. And I also made its timeout value to be extremely small so that we get timeout error before the protocol error. On my testing, the result was that we get a protocol error at first but after on, we get timeout.

I made it to be on option on '/nxfilter/conf/cfg.properties'. You need to add,

  hide_ssl_warning = 1

And good thing is that if you change 'https_port' on cfg.properties file, you still can access admin GUI and login-page with that port specified. If you change it to 9443.

  https_port = 9443

You can access NxFilter login-page like this,

  https://login.example.com:9443

I uploaded v4.1.2-p2 for testing.

  http://www.nxfilter.org/imsi/nxfilter-4.1.2-p2.zip

[jeroen...@gmail.com]

mmmm?

Not sure if I understand this correctly:

I need to change the default http port (80) to port 443 and https to 9443 in cfg.properties ?

How are http blocked pages then served to the client?... Or am I missing something?

Normally I never use https for the gui login, but basic port 80

With servername indication there is no timeout or protocol error. Webserver just denies the request and send a page not found to the client in < ms.

So the client "knows" the server is up but will not try again.

In the past I already tried the https "trick" and changed the https port in the cfg.properties. As the client does not see the server it will retry a couple of times.

There is not much you can do about this I think as this is a browser programmed behaviour, that results in timeouts. Not sure what those timeouts are, but those are someting around 10-15 seconds.

[Jinhee]

You only need to change the value of https_port when you use GUI on HTTPS. And we can close the client socket immediately on server side. Anyway try it.

[Jinhee]

HTTP block page will be working as normal.

[jeroen...@gmail.com]

OK,

So I set http on 80, https on 9443, hide_ssl_warning = 1 in cfg.properties,

Install the 4.2.1-p2

Set the block page back to NXfilter ip instead of the remote server with servername indication

And that's it?..:)

Will give it a try

[Tim Young]

It worked for me.  It did not pop up terribly and ugly SSL error messages.  It simply says that the site cannot be reached after a brief pause.  Nice.

From the technical perspective, I prefer my redirection system that ends up giving a "blocked" message.  But this current solution is very simple to set up.  Great job.

[jeroen...@gmail.com]

Hi Jinhee,

I have updated to 4.2.1-p2, made the needed settings in cfg.properies and can 100% verify all is working exactly as if I had done the setup with a seperate webserver with server name indication.

Very good!!!!!!!

No delays on youtube and I do no longer need to use a diffrent server for the blocked pages.

I am very happy with this easy solution. Many thanks.

Jeroen

[Jinhee]

OK. Thanks for the reports. Both of you. I will add it on v4.1.3.

[Richard Cutts]

I've edited the cfg.properties file to the below, but https pages are still very slow to timeout with a can't be reached message. Any ideas why?

hide_ssl_warning = 1

https_port = 4443

With more and more websites using https, do you think there will ever be a way for the block page to show on blocked https sites?

Thanks

[jeroen...@gmail.com]

Here is my config:

listen_ip = 192.168.1.4 (adapt to your ip!!!)

# ,[2002:c0a8:102::4] (this does not work yet!!!!)

# listen_ip = 2002:c0a8:102::4 (this does not work yet!!!!)

http_port = 80

https_port = 9443

start_tomcat = 1

cluster_mode = 0

master_ip =

slave_ip =

blacklist_type = 5

rh_num = 16

hide_ssl_warning = 1

Plus you need the latest nxfilter to get the hide_ssl_warning activated.

Give it a try.?

You say: all https pages are slow?....Or just the ones that are blocked? Is there perhaps some other process running (apache or lighttpd or IIS or whatever webserver) on port 443 on the nxfilter device?

nxconfig:=>setup=> Block Redirection IP: check if this is correct.and is the same as the nxfilter box.

What and os and what browser are having the slow issue?, using ipv6?, on what os is nxfilter running?

If my config does not do the trick ...what happens if you change dns (back) to isp provided or 8.8.8.8 on the client ...still slow?

NXfilter build in https blockpage: very difficult as https needs valid certificates.

Current solution with hide_ssl_warning works perfect for me.

Yes: there is no blocked "page", but who cares.

[Richard Cutts]

I'm not sure if it makes a difference, but i'm using NxCloud, not NxFilter.

I've changed my config to the same as yours apart from 'listen_ip = <MyIP>' which stops NxCloud from working if configured

The slow HTTPS is only slow when the page is blocked. Happens on all browsers I've tested with. If the page is unblocked it works fine.

I am using the latest NxCloud version

The block IP Redirection is configured to my NxCloud public IP address

Thanks

[Jahastech]

On NxCloud, we don't have hide_ssl_warning as your client still need to see something in most cases even if it's slow. But maybe we need to have it.

listen_ip should be working on NxCloud. But it's not related to SSL warning.

[Jahastech]

'listen_ip' works fine on NxCloud. And we added 'hide_ssl_warning' option on NxCloud v4.1.5-p1.

  http://www.nxfilter.org/download/nxcloud-4.1.5-p1.zip