HTTPS login to your local router will not make anything safer, IMHO. These ideas are just for starters, not to start a big network security talk, there are other good resources and podcasts for that. Also minimize use of publicly open UPnP ports and DMZ zones.Īlso change your root user name to something other than admin, make your admin password a non dictionary word, bare minimum 8+ characters in length, and include some non-English symbols in it (and do the same thing for your WPA key, or better yet get a super strong random p/w generated by crypto guru Steve Gibson's free service) if you really want to fortify your LAN & WLAN. To protect your router from the outside turn off "admin by WAN" and turn on your firewall, and only enable the minimum amount of services (SSH, telnet, etc) that you need to, and maybe turn them off when you don't. And the first two reasons to use HTTPS (CA verification and man in the middle attacks) are irrelevant on a LAN. If I'm connecting via WPA the communication is encrypted, if I'm connecting via LAN, chances are that I'll know if my network is being physically hacked. Reasons that you'd normally want to use HTTPS (public key CA verification, avoiding man in the middle attacks, and wanting the whole communication encrypted) are moot on a LAN. Really there is no benefit to use HTTPS locally to login to your own router. However in HTTPS it gets rather confused and didn't let me back in until I deleted the cookie for 192.168.1.1 (it might have been an old cookie, I wasn't having it save the HTTPS login credentials), exited the browser, then reopened the browser, browsed to another page, or whatever, then tried to login again, whereupon I turned off the HTTPS force. It might have something to do with when you logout it leaves you on 192.168.1.1/lougout.asp, and if your browser is like mine it will save state between sessions, then next time I open it I'm brought to 192.168.1.1/logout.asp, which doesn't present a problem when using HTTP, I just highlight and erase everything from the /logout.asp part, and hit enter and it brings me to a login screen. Yes I can replicate it with HTTPS only login enabled. One of possible causes might be Safari itself, because it also has been updated more than once after that previous encounter. However other browsers not clear their caches automatically and still don't have this problem. It looks like problem lies in caching, because problem is gone after clearing Safari's cache. Now I got one of these for myself and 372 and 374 builds are both behaving in the same way. It is quite possible, that firmwares from 2xx series did not have this problem, as I have been fiddling with other RT-N66U some time ago using the same Macbook with Safari and did not see this problem back then. It might wery easily be something browser-specific, because this is always happening with Safari on OS X - other browsers do not seem to cause this behaviour. One workaround is to try to access the router with IP address instead of hostname or vice versa, but even this does not always work. Start the browser again and try to log in. I have to "join the choir", as I am able to reproduce this thing quite well, although I have RT-N66U.ģ.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |