Thanks to all for the details. @lleachii now, I better understand the certificate can not be signed / I'll install this specific one on my browser. And I'll still have warning on other devices. @arjuniet I'll install this certificate on my browser and understand where this one is coming from (router create his own). But should not be done on unknown website @mk24 my intention is not to access from internet only from intranet (connected to wifi or LAN), Thanks for warning and remind to the users
I really appreciate your help to understand the OpenWrt
great . my concern was just this SSH , HTTPS both are serving same purpose. that is
HTTP (plain text) >>> ssl engine >>HTTPs
Telnet (plain text) >>> ssl engine >> SSH ( can be assumed)
The privacy that they provide to this communication is only worth when we as a client know that we are connecting to correct server that we wanted to , if we keep bypassing the warning than it means we are ready to believe any website saying that its twitter,com
The reason for the error @mac_low is receiving is two-fold
The SSL cert is self-signed
The SSL cert is likely using an IP for CN, which should instead be placed in the SAN as IP.1
The RFC has implied IPs/Hostnames should not be contained in the CN for ~2 decades, and Chrome distrusted all certs with the IP/hostname not stored in the SAN around a year or two ago.
Unfortunately, I don't believe there's a way around this if utilizing the self-signed cert that's auto-created by uhttpd, as it's not using an openssl.cnf to specify a SAN profile
A WAN connection to a WAN hosted website
In this case, if receiving any error regarding the SSL cert, the site should not be entered.
The solution to 1.1 and/or 1.2 is to utilize the OpenSSL PKI wiki to create a self-signed CA and utilize that CA to sign a new cert for uhttpd.
I tried to refrain. Please try to stop playing into the chicken-or-the-egg theories.
A person gets a router
Installs Official firmware
The person manages to get Internet
The person installs an SSL package
Someone suggests a Public cert
The person now doesn't trust his/her own router.
At some point, there's a "root of trust..." Your router is this root (as its configurations are concerned, and the console you trusted to configure it)...otherwise, make a local [wired] management interface; and block port 80 and 22 to all other networks.
Actually, you miss-assumed, the traffic would not be telnet, it would be 80(or 443)/tcp SSH tunneled.
it was an analogy telnet is not preferred for remote method of shell access because its plain text exchange all visible if you just tap the communication media ? agree ?
ssh is prefered ? because it gives you an encrypted session .. that is data exchane happends only after a session with an encryption key is established ? agree ?
bydefault this is the ssh implementation . during first time communicaction when you enter command on your terminal
ssh lleachii@myserver.in
and on prompt you give password . and you are hacked dude ? i thing you know why
password based vs key based
In ssh either you do key based authentication or password based it equally safe or equally vulnerable ( this is for you @lleachii)
It just an analogy like authentication is check ether by checking by something you have or by something you know
and even in VPN i dont know why you feel secure ? explain plz
HTTPS or SSH
In present scenario if you keep you eyes open its only HTTPS that can save you how ?
TLS on its default implementation get implemented by server authentication ? how ?
if you are not in a habbit of bypassing ssl invalid CA error your cliet ( you browser) is giving you warning that i dont think you are getting connected to abc.com ? why it warns ?
because site abc.com is sending a non trusted CA signed certificate ( which is the proof of it being a genuine server on which abc.com is hosted ) bypassing it is inviting a attack on yourself
are you even aware of how may routers have generated the same private key at present ?
If you are use crypo method for trying to make your communication safe i admit the privacy is importation which we all can achieve with default ssh as well as self-signed certificate bypass trick is giving you
but ask your self what are you missing . do you guarantee tthe server authenticity ? are you really having a private encrypted communication with the real server ? NO you can never
that is why trusted CA certificate comes in scene
I even saw you saying that you will suggest to check the certificate serial key . LOL you should know any cerificate number can be choosed
And what does this mean that user is on lan ?? no risk zone ? why are you not promoting the use of split dns dude ?
get a domain name router-1.in or what ever
have certificate for that
now you have router in you hand you can do whatever you want to enhance the clients security
you can very well use router-1.in on your lan too ? i can show if you want
I understand the point you're trying to make, but this is too much of an over-simplification, as there are numerous reasons why a browser may barf an invalid cert error.
Please recognize you're still correlating two entirely different things that are not alike: certificates for LAN web servers and certificates for WAN websites.
No public/commercial CA or ICA can issue a cert for a LAN side web server, as these must utilize RFC1918 addresses, and as such, thousands of devices utilize the same IPs (i.e. there's no chain of trust).
I could be wrong, but I believe all commercial CAs/ICAs (incl. LetsEncrypt) will refuse to issue a cert for a RFC1918 address
Why would one do this for a WAN site, as most, if not all, commercial CA/ICAs are included in the OS' certificate trust bundle, of which should be updated by the OS itself as needed.
Why would one do this for a LAN site with a self-signed cert, as there's no way to verify chain of trust (as it has no chain of trust), therefor it should never be installed as a trusted cert.
