OpenWrt Forum Archive

Topic: Chaos Calmer -> Luci -> Privacy Error when connecting

The content of this topic has been archived on 22 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi all!

I've been getting a Privacy Error when connecting to Lucy ( 192.168.1.1) using Chrome. It's showing me the following:

Your connection is not private

Attackers might be trying to steal your information from 192.168.1.1 (for example, passwords, messages, or credit cards). NET::ERR_CERT_AUTHORITY_INVALID
Subject: OpenWrt
Issuer: OpenWrt
Expires on: Oct 13, 2018
Current date: Mar 7, 2017
PEM encoded chain:
-----BEGIN CERTIFICATE-----
MIICUzCCAbygAwIBAgIJAOxiU11sn0OCMA0GCSqGSIb3DQEBBQUAMEQxCzAJBgNV
BAYTAlpaMRIwEAYDVQQIEwlTb21ld2hlcmUxDzANBgNVBAcTBlVrbm93bjEQMA4G
Blah....blah...blah
-----END CERTIFICATE-----


Also Internet Explorer reports this:
- The security certificate presented by this website was issued for a different website's address.
- The security certificate presented by this website was not issued by a trusted certificate authority.

Any ideas what this could be? My router is a Linksys ACS1900 v2, has Shelby installed on it (Powered by LuCI for-15.05 branch (git-16.206.66468-6f5c466) / OpenWrt Chaos Calmer 15.05.1 r49389)

Regards,
Mariano

Are you using luci-ssl? If so i think that's what's causing this, i believe you have to generate a self-signed certificate when using https, unfortunately i don't use it myself and haven't really looked into it so i can't be of much help, but maybe this will point you in the right direction -

http://fabianlee.org/2016/09/19/openwrt … interface/

The browser will throw this error when it finds a self-signed certificate.  You can either disable https mode in uhttpd or tell the browser to allow an exception.

Having an authority sign a real certificate for your router would almost certainly cost money.

(Last edited by mk24 on 8 Mar 2017, 14:52)

Thanks guys! I just disabled ( put a # in front of the 443 lines ) and that fixed the issue, now I'm connecting through HTTP only.


----

Now that I'm ok for managing Luci from my Lan ... which are the steps to be able to manage it from the WAN ( i.e. my cellphone when abroad?) ... I've tried several guides, but was not able to allow the traffic through the firewall ...

I've created a Firewall => Port forward from the WAN for port 8080 into the DEVICE 192.168.1.1 for port 8080
I've also created a Firewall =>Traffic Rule to ´Accept Input' like this: 'IPv4-TCP From any host in wan To IP 192.168.1.1 at port 8080 on this device' ...

Regards,
Mariano

You need to set up the forward so it also translates the port to local port 80.  Or configure uhttpd to listen on port 8080.

Opening luci to the internet isn't very secure.  SSH tunnel would be much better.

Thanks! It worked now ... but i'm sending clear text (including router password! ) over the internet now... so, any guides on how to configure a SSH tunnel ?

SSH to the router with the -L option to open a tunneled port forward.

ssh root@router -L 8080:localhost:80

Leave this connection open, and go to your browser.  The running ssh link makes port 8080 on your machine a tunnel to port 80 on the router.  So when you open your browser to localhost:8080 you have LuCI from the other side.  But the connection is fully encrypted.

You do not need to configure anything on the router other than to accept ssh from the wan.  Do not open port 80, that would defeat the whole purpose.

I'm getting a "Connection refused" when trying to connect to the router from the internet on port 22 using putty

You have to open port 22 like you did port 80.  But close port 80 now.

Also you should use public private key files and disable password login.

Disabling SSL is not the right move to avoid warning, it didn't solve the issue, instead, it make a big security risk because all your information/password are sending by plain html, it's a suicide when transfer over internet.

What you should do:
1. Re-enable SSL.
2. Make sure there's no untrusted clients in your Lan, then visit Luci https through Lan.
3. When you get the warning again, click "view certificate", and take a screenshot of the fingerprint.
4. Add a permanent exception in the browser, so the warning won't show again aslong as the certificate do not change.

Also, always connect Luci by https through Wan.

(Last edited by sam1275 on 8 Mar 2017, 21:50)

mk24 wrote:

SSH to the router with the -L option to open a tunneled port forward.

ssh root@router -L 8080:localhost:80

Leave this connection open, and go to your browser.  The running ssh link makes port 8080 on your machine a tunnel to port 80 on the router.  So when you open your browser to localhost:8080 you have LuCI from the other side.  But the connection is fully encrypted.

You do not need to configure anything on the router other than to accept ssh from the wan.  Do not open port 80, that would defeat the whole purpose.

I am unable to connect with the above method. Not even if I changed the line to

ssh root@aa.bb.cc.dd -L 8080:aa.bb.cc.dd:80

and then in the browser,

aa.bb.cc.dd:8080

where aa.bb.cc.dd is the IP address of the router.

Though it connects when I give without 8080, i.e.

aa.bb.cc.dd

I am trying this on LEDE.

(Last edited by inamu on 8 Nov 2017, 12:15)

The tunnel makes port 8080 on your PC link through SSH to internally port 80 on the router.

So on your PC's browser, do not specify the router IP, use localhost.  The ssh session already open as another process knows the router's IP and makes the connection. 

Internally, this is what is happening:
browser -> PC OS port 8080 -> ssh client on PC ~> ...Internet... ~> router OS port 22 ~> ssh server on router -> router OS port 80 -> LuCI

->  = unencrypted http link
~> = encrypted ssh link

If from a remote location, <public router IP>:80 (or simply <public router IP>, since the browser defaults to port 80) gets you the LUCI web interface, that means that the router's port 80 is still open to the Internet, which is a severe security risk.  Take that out of the firewall rules.

(Last edited by mk24 on 8 Nov 2017, 13:34)

The discussion might have continued from here.