mtchang / rt-n56u

Automatically exported from code.google.com/p/rt-n56u
0 stars 0 forks source link

Unclear purpose of new HTTPS functionality #1013

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Goto Administration/System, select HTTP Protocol "HTTP & HTTPS"
2. Built the certificate /etc/storage/https/server.crt via https-cert.sh 
script, as advised in the logfile.
3. Add key and crt to the appropriate input fields
4. Open a browser from WAN, enter https://<DDNS_of_Router>

What is the expected output? What do you see instead?

I would expect to get a secure session for router administration. Instead, I 
get a timeout or the message that the website is not available.

What version of the product are you using? On what operating system?

RT-N65U_3.0.3.6-069

Please describe the problem as detailed as it's possible.

From LAN, the "secure" connection to https://my.router works (with a browser 
warning, however, because there is no root certificate). But I don't need a 
secure https session from home to my RT-N65U - my LAN is secured good enough 
anyway. But it would be helpful for remote administration if I could open a 
https:// - connection to my router from remote, i.e. over WAN. Why didn't you 
provide this in the actual release?

And is there a cheap possibility to build a full certificate chain for the 
router, getting rid of the browser warning?

Original issue reported on code.google.com by ulysses....@gmail.com on 1 Oct 2013 at 7:24

GoogleCodeExporter commented 9 years ago
GoTo Firewall - General

Enable HTTPS Web Access from WAN? YES
Port of HTTPS Web Access from WAN: Set port which not blocked by your ISP

Original comment by andy.pad...@gmail.com on 3 Oct 2013 at 12:04

GoogleCodeExporter commented 9 years ago
Okay - this works.

Google chrome however doesn't like the certificate that I built internally on 
the router. It is regarded as "weak" because it was generated using an md5 
digest (option -des3 in the https-cert.sh). I changed the option to -aes256 but 
that didn't work on the router. So, I built the certificate with OpenSSL on a 
Debian machine and imported the keys. Now, everything is fine. 

You might implement aes256 or another "safer" digest to the next firmware.

Original comment by ulysses....@gmail.com on 10 Oct 2013 at 2:48

GoogleCodeExporter commented 9 years ago
You can also use root certificate CA (and chains). 

https-cert.sh generated self-signed certificate without CA. 

-des3 is a TripleDES 192bit encryption, this is not md5 ;)

Original comment by andy.pad...@gmail.com on 17 Oct 2013 at 2:45

GoogleCodeExporter commented 9 years ago
The script has implemented the -des3 option, but the certificate that I built 
with it on the router shows up a md5 digest. May be my /opt/bin/openssl on the 
router is outdated (historically, I'm still using optware because I avoided the 
effort to move to entware); the timestamp of my openssl is from April 30, 2012.

Did you check the certificate generated on your router (e.g. by importing it 
from Windows), is it really des3?

Original comment by ulysses....@gmail.com on 17 Oct 2013 at 9:50

GoogleCodeExporter commented 9 years ago
The certificate is generated with TripleDES encryption. But it is signed with 
md5 alg.
So, if you'd like to improve your cert specially for Google, shouldn't change 
-des3 value (this won't make sense). You should add -sha1 option to signing 
command: 
# openssl x509 -sha1 -req -days  ....

Original comment by d...@soulblader.com on 24 Nov 2013 at 11:43