I guess it depends on the use-case. We're used to implement internal DNS, either as split-DNS or with a separate domain that does exist. A domain-name will set you back a few bucks a year, wildcard certificates from Let's Encrypt can be had for free, but commercial ones are now also available for sub $50 a year. This really beats running your own little CA and importing the CA root certificate into all client machines as it often needs to happen on many levels: OS itself, browser level, Java also has its own certificate store, etc...
Going this route, at least solves the problem of browsers screaming hell to end-users. Also, there are some applications that outright refuse to work, if the SSL chain can't be verified. Stuff like Outlook won't even connect to the Exchange server if the SSL certificate is not trusted. It's nice to be able to include all those other IP connected gadgets into the process. The only thing is, since SSL certificates can't be valid longer than a year anymore, is that you have to update certificates on all those devices every year, or after a certain date, everything starts to break down... This is obviously were stuff like Certbot/Let's Encrypt can help automate stuff.
But in general, it looks like you have all the tools on-board on JNIOR/JANOS, at least for now, to run "public" trusted certificates. So if people want to implement them, they can.
I consider everything but some real local nameservers a futile attempt at name resolution.
Both NetBIOS and LLMNR are protocols which almost exclusively reside in the Windows domain, all or most other devices won't participate in it. Most stuff won't resolve to a fully qualified domain too, which renders any trusted certificates useless. Maybe important to know: The Internet was designed with proper name resolution in mind. Connecting to IP addresses directly should actually be considered a hack.
If you design a network properly and you do implement DNS for local stuff, a lot of stuff is going to be easier, like moving your network to new IP addresses. As long as everything connects to hostnames instead of IP addresses, you shouldn't have to worry about all those little settings on local devices...
Well, in the end, if you're honest, you can't have it both ways... You can't have "real" security and "fake" security and be done with it. The reason this alert system was implemented across al browsers, is because the previous pop-up, where you just needed to hit "Yes" for any non-trusted certificate, simply didn't work and was often abused by hackers, scammers and the like. If you open the door just a little bit and allow those folks to use a "lesser version of HTTPS" that doesn't throw warnings if things don't check out, those people will be abusing this in no-time. In the end, it works a lot like SSH does. The first time you connect to a new host, it also comes up with a message that this host isn't known. If you then choose to accept the certificate, it won't complain the second time you connect. The same is true for most browsers too. If you go through the little hoops and accept the certificate, despite the warning, then you'll be able to connect afterwards, without being hit by in-your-face warnings.
Going this route, at least solves the problem of browsers screaming hell to end-users. Also, there are some applications that outright refuse to work, if the SSL chain can't be verified. Stuff like Outlook won't even connect to the Exchange server if the SSL certificate is not trusted. It's nice to be able to include all those other IP connected gadgets into the process. The only thing is, since SSL certificates can't be valid longer than a year anymore, is that you have to update certificates on all those devices every year, or after a certain date, everything starts to break down... This is obviously were stuff like Certbot/Let's Encrypt can help automate stuff.
But in general, it looks like you have all the tools on-board on JNIOR/JANOS, at least for now, to run "public" trusted certificates. So if people want to implement them, they can.
I consider everything but some real local nameservers a futile attempt at name resolution.
Both NetBIOS and LLMNR are protocols which almost exclusively reside in the Windows domain, all or most other devices won't participate in it. Most stuff won't resolve to a fully qualified domain too, which renders any trusted certificates useless. Maybe important to know: The Internet was designed with proper name resolution in mind. Connecting to IP addresses directly should actually be considered a hack.If you design a network properly and you do implement DNS for local stuff, a lot of stuff is going to be easier, like moving your network to new IP addresses. As long as everything connects to hostnames instead of IP addresses, you shouldn't have to worry about all those little settings on local devices...
Well, in the end, if you're honest, you can't have it both ways... You can't have "real" security and "fake" security and be done with it. The reason this alert system was implemented across al browsers, is because the previous pop-up, where you just needed to hit "Yes" for any non-trusted certificate, simply didn't work and was often abused by hackers, scammers and the like. If you open the door just a little bit and allow those folks to use a "lesser version of HTTPS" that doesn't throw warnings if things don't check out, those people will be abusing this in no-time. In the end, it works a lot like SSH does. The first time you connect to a new host, it also comes up with a message that this host isn't known. If you then choose to accept the certificate, it won't complain the second time you connect. The same is true for most browsers too. If you go through the little hoops and accept the certificate, despite the warning, then you'll be able to connect afterwards, without being hit by in-your-face warnings.

Comment