JNIOR Corner

[Bruce Cloutier]

In following Steve's lead in creating a focused product thread...

I want to announce that we have released JANOS v2.0. This is the operating system behind all of the Series 4 JNIOR devices.The UPD update file can be obtained from the website at integpg.com (same website reached also by jnior.com). You need only update the OS using the UPD. You can run the Core update project which will do that for you and update the WebUI. You do not need to perform the All-In-One although there are likely other updates that may benefit you.

I want to reassure those of us who are paranoid over updates. Don't let the '2.0' moniker spook you. This update is based 100% on the stable operating system that you all have come to rely upon. We spent a great deal of time over the past year stressing JNIORs and chasing every hint of a bug or gremlin. Consequently this release is the most stable and robust that we have ever put together. Nothing has changed that will alter your application of the product and lead to any regret over the update. Instead, if you do apply the update we can all sleep better at night.

By the way, Gremlin is the term that we use to describe a bug that manifests itself with random and infrequent symptoms. It is the kind of beast that lies dormant until the situation is just right and then finds some way to cause trouble careful not to leave evidence that could lead to its discovery. Generally bugs are reproducible and can be dealt with forcefully. A gremlin haunts us. It is the terrorist. Well, lets just say, we've had a good hunting season this past year.

We have tagged this release of JANOS with '2.0' mostly because we have significantly enhanced capabilities targeted to assist developers and improve product support. We can get into some of that in this thread if it is of interest. But also, "2.0" kind of logically follows "1.9" in our decimal world and "1.10" just doesn't seem right. It was just time.

But generally, v2.0 supports current communications security in regards to SSL/TLS with Elliptic Curves and all of that. Some browsers refuse to connect without it. There is a command line text editor so you can make changes to text files without having to move them to your PC. We've added a unique scripting capability to batch (BAT) files opening the door to new utilities and services. And there is even experimental support of file sharing (initially disabled).

You can use the unit's serial number (prefixed with "jr") to access the unit instead of its IP address in addition to its hostname. New units are being shipped with DHCP enabled making initial connection simple on most networks. The unit will correctly configure for the network and you can immediately reach the WebUI with the serial number in the URL (for example http://jr615010258). No Support Tool or serial port connection required.

The default WebUI is the same but has been relocated internally to better support those of you wishing to create custom web pages for the unit. We've improved compatibility with Linux terminal emulators. And, well, just a lot more.

[Bruce Cloutier]

If you are starting back up and are concerned about batteries, do not worry about the JNIOR. If you have a Series 4 (410, 412, 414 or 412DMX) the battery is replaceable. You could pop the lid (4 screws) and check the battery with a voltmeter. If it is under 3V then you could do well to replace it. There is no special procedure. There is no issue if you remove it. Everything will be fine. We rely on the battery to maintain the clock (which should get synchronized through the network) and to keep log files through a power outage. You will appreciate the logging should support be needed. It is a standard 3V CR2032 coin cell available everywhere (20mm).

If you have Series 3 don't worry about the dead battery. It is soldered in and a pain to replace. You might seriously consider replacing the unit with a Series 4. There is a huge difference in performance and reliability. And while we support the Series 3, it has gotten to the point that we often cannot help you with issues and can only recommend the upgrade. It has been several years easily since we have shipped those.

[Steve Guttag]

Ah Bruce...it's all in the naming. JNIOR JNCTION or JNIOR JOINT would have been my names if I were starting this thread.

[Carsten Kurz]

JNIOR JNCTION, that sounds a bit too decisive for me...

[Bruce Cloutier]

The product name JNIOR was created before my time at INTEG and I am not all that sure that it would have been my choice. It is pronounced "junior" although the French have said "J-Noir" and we do have sort of a dark side. ;-) But when Rick once suggested a following CNIOR ("senior") product, well, I had to stop that! JNIOR kind of has grown on us though. The JNCTION is a creative thought... good job!

Maybe we'll hand out JNIOR Mints again at CinemaCon in August? We're generally sick of them by the end of the week when we do that.

[Carsten Kurz]

J-Noir, made my day...

[Randy Stankey]

Oh, those French people have a different word for everything!

[Marcel Birgelen]

@Bruce

You should check the SSL certificates on your webserver. They're only valid for integpg.com and jnior.com. If I happen to surf to https://www.integpg.com or https://www.jnior.com (yeah, I know, I'm old-school), I get a big-fat warning from my browser's SSL-police that the domain doesn't match and that I should get the heck outa there.

Since you're using Let's Encrypt, the solution should be cheap. Make sure you add www.integpg.com and www.jnior.com to your requests.

[Bruce Cloutier]

Marcel, thanks. I bet that also depends on the browser that you are using but it is something that we can easily take care of.

[Bruce Cloutier]

The certificate for our sites should now be valid for the old-school WWW prefix as well. Since you mention certificates, I have yet t o figure out a way to get trusted certificates for JNIORs. The Series 4 JNIORs support SSL/TLS v1.2 and you can go to the unit using HTTPS. This is not at all important for those of you within the cinema complex but we do have many units out in other applications that are even on the open Internet.

We have honeypot.integpg.com directly on the net and... it survives. I suspect that it will be breached some day but not yet. On this unit the Telnet port is open. When a login failure occurs, there is an entry in the access.log file. I have a little application running there that processes the access.log.bak file when it is updated. It maps the location of the IP addresses attempting to login. That is what you see when you go to the unit. It is just interesting. If you try to log into the Telnet port after a few hours you will appear on the map. Try it. The access.log ages to the BAK file about every 5 hours on that unit. That is all failed logins. Isn't the Internet a wonderful place? The WebUI is accessible at honeypot.integpg.com/config and when we go there we want to use HTTPS. But the certificate is not trusted and so you get the aforementioned ugly warning.

There is a way to get your PC to trust your JNIOR. I cover the procedure for Windows in a couple of places. One I think is jnior.com/trusted-secure-access/. I have not yet figured out this procedure for Linux (we use Ubuntu). If anyone knows how to do that it would be helpful. I just haven't gotten to it.

But what would be better is if INTEG issued one certificate that you could install and then ALL of the JNIORs would be trusted. The problem with this is that the JNIOR needs to re-sign a new certificate every time you change its IP address or hostname. After that certificate change, INTEG would have to sign the new certificate with our trusted certificate in order to make your PC all happy. That second signing takes a private key that as a CA we are bound to protect. So it is not safe to store this private key in the JNIOR. I think we are all sensitive to this certificate craziness for other reasons.

We could do the Let's Encrypt thing for JNIORs that are accessible through the Internet. We cannot use Let's Encrypt per se as we would have to implement their API and what they supply is not applicable (no third-party code allowed). But if your certificate changes, the JNIOR could contact us securely and we could sign the new certificate in some automated fashion. This would work for JNIORs with Internet access. In cinema's how many JNIORs have Internet access? Not that secure certificates are any concern there. So it is not necessarily a viable approach.

[Harold Hallikainen]

Interesting! I use Let's Encrypt for certificates for several web sites running on my server. I have a script that runs each month to renew them (they expire pretty quickly). Since the certificates are for a specific domain name and JNIORs are unlikely to have domain name registration, it seems that a self generated certificate is about all that can be done.

On the wild west nature of the Internet, a quick review of yesterday's server log shows:

About 50 SSH login failures like this:

sshd: Authentication Failures:
root (120.48.25.100): 31 Time(s)
root (162.244.24.122): 16 Time(s)
root (1.234.58.216): 15 Time(s)
root (111.198.66.50): 14 Time(s)
unknown (165.232.151.116): 11 Time(s)
...

After a number of failed logins, I block an IP address for something like 6 months (using sshblack). About 100 addresses were blocked yesterday, like this:

Refused incoming connections:
1.179.137.10 (1.179.137.10): 1 Time(s)
1.234.58.216 (1.234.58.216): 24 Time(s)
103.27.4.161 (103.27.4.161): 35 Time(s)
103.76.175.130 (103.76.175.130): 1 Time(s)
...

I don't run Word Press, but get requests like this:
/wp-config.php_new: 1 Time(s)
/wp-config.php_orig: 1 Time(s)

Then there are those trying to access files outside the web pages:
/home/harold/BhWikiData/page_data/%2Fetc%2Fpasswd

or run scripts
/home/harold/BhWikiData/page_data/script+alert%28String.fromCharCode%2888%2C83%2C83% 29%29%2Fscript

It IS the wild west!

Harold

[Marcel Birgelen]

Marcel, thanks. I bet that also depends on the browser that you are using but it is something that we can easily take care of.

Yeah, the SSL police let's me connect to the "www" version without any warning now. No problem, it's an often overseen little thing. Those SNI certificates can get a little confusing. Usually, if you request certificates at a commercial SSL provider, they automatically add the "www.yourdomain.com" aliases to the certificate, but Let's Encrypt, which is 100% robotic, is a bit more specific.

It shouldn't be a browser thing though, SSL certificates should always be strictly checked and should exactly conform to the hostname you're pointing your browser at. It wouldn't really make sense otherwise and it could be abused. You could, for whatever reason, run another site at www.somedomain.com than on somedomain.com for example, those sites could even be run by different entities, not that I can come up with an example in which it would make sense, but yeah... Some browsers tended to automatically add www. in front of a domain if it doesn't resolve without. I don't know if the current iteration of browsers still does this. Anyways, I think you should always make your site available via www.whatever.domain too, simply because that's what a lot of people are still used to. I guess that the more recent generations don't even type any URLs anymore and just go there via Google...

The certificate for our sites should now be valid for the old-school WWW prefix as well. Since you mention certificates, I have yet t o figure out a way to get trusted certificates for JNIORs. The Series 4 JNIORs support SSL/TLS v1.2 and you can go to the unit using HTTPS. This is not at all important for those of you within the cinema complex but we do have many units out in other applications that are even on the open Internet.

It should be no problem to get publicly trusted certificates on your JNIOR, as long as you allow people to install their own certificates for the individual services that use SSL/TLS, including a possible intermediate certificate chain and private key. Commercial SSL certificate providers only ask for a CSR (a certificate signing request) and a way to validate you own the domain. For cheaper certificates, this usually happens either via a control e-mail to an address like hostmaster@ssldomain.com or by adding a specific DNS entry for the domain being validated (e.g. a TXT record with a certain string).

If you don't want to provide the tools to generate a CSR on the JNIOR itself, you could provide an easy wrapper around the OpenSSL binary for Windows, Linux, MacOS X that does the same on another machine.

People could also possibly be using an existing certificate, like a wildcard certificate: *.ssldomain.com. Such a wildcard certificate will be valid for any subdomain of "ssldomain.com". It won't be valid for any sub-sub-domain though. So tree.ssldomain.com would be valid, but banana.tree.ssldomain.com would not be valid. A wildcard domain really is one of the best tools to put SSL on all kinds of stuff that would otherwise not see a publicly validated certificate. There is no reason why "private.ssldomain.com" can't resolve to internal IPs like 10.99.1.251 too. In any case, people using those services won't be confronted with any SSL warnings anymore.

Lastly, you could possibly also try to implement Let's Encrypt on the JNIOR itself, although this would require a working Certbot, which is written in Python, so you need a working Python interpreter on your JNIOR for this.

[Bruce Cloutier]

Really a constraint is that 99% of the JNIORs are accessed by IP address alone. It would be a rare situation where a JNIOR would deserve its own domain. A unit like our Honeypot that is directly on the Internet could actually be handled by Let's Encrypt if I were to implement their API. The percentage of JNIORs that could take advantage of such things is extremely small. The motivation to get it done is even smaller I'd bet.

The CERTMGR on the JNIOR can create a CSR and you can load externally signed certificates.

bruce_dev /> help certmgr
CERTMGR

-V Verify installed keys and certificate
-C [file] Regenerate Certificate [Install file]
-A file Add intermediate certificate
-S file Verify signature on certificate
-K file Install RSA Key Pair
-D [file] Decode and dump certificate [file]
-E file Export certificate to file
-P file Export public key to file
-B Export in binary
-G [len] Generate key pair [bit length]
-x file Create Certificate Signing Request
-R Restore default credentials

SSL Certificate Management.

bruce_dev />

The self-signed certificate when it is generated includes the unit's IP address (in two formats because, well, IE), the units birthname ("jr" + serial number), and the hostname (default is birthname).

So JANOS v2.0 now supports NetBIOS Name Resolution. The unit previously would handle LLMNR for name resolution but that proved unreliable. Everyone generally opens the WebUI using the unit's IP address but now if you don't know the IP address you can use the birthname ("jr" + serial number) or the hostname (JR_AUD2 or something). We're shipping units with v2.0 having DHCP enabled (as opposed to the default 10.0.0.201 address) so you don't need the Support Tool to initially find the unit and configure it. But when any of those identifying characteristics change a new certificate is generated (unless you've uploaded one).

The browsers insist that anything over a secure channel must also be Trusted as if you are going to use the JNIOR to manage your 8-figure portfolio. It would be better if there were 3 separate HTTP protocols: HTTP, HTTPS and HTTPT with ports 80, 443 and something else. The browser could be happy with HTTPS and not put up the awful scary warnings. Your bank, insurance provider, and anything on that level should support only the HTTPT (or whatever) and that can complain, force you to confirm and otherwise request your first born before proceeding.

[Bruce Cloutier]

Now SSL/TLS does work really well on the outgoing side in sending email for example. You would appreciate that your email username and password are not passed around in the clear.

03/05/21 12:40:08.190, -- JANOS 410 v2.0 initialized (POR: 1125)
03/05/21 12:40:08.217, Running: jaccess (pid 3)
03/05/21 12:40:08.225, Running: JBakup (pid 4)
03/05/21 12:40:13.678, Requesting time sync from pool.ntp.org (44.190.40.123)
03/05/21 12:40:13.694, jAccess restarted email successful (Encrypted)
03/05/21 12:40:19.303, [HoneyPot] Boot Notification email successful (Encrypted)
03/05/21 12:40:22.000, Clock synchronized via NTP (-78)

This copied from Honeypot's jniosys.log file.

JAccess is the program processing the login failures and providing the data that shows up on the map when you open the honeypot.integpg.com site. JBakup is a little utility we have that uses the new scripting capability in JANOS v2.0. It processes BAK files creating a cumulative log of activity compressed and stored in a ZIP library. We think it might be helpful sometime to have a lot of history. You know, to be able to look way back to see when something first happened or how often something occurs. You could add things like that on top of the CINEMA program that many are running.

A little routine could manage a ventilation fan based on booth temperature for example.

This Honeypot unit is in our IT rack on the UPS. We have a 12VDC wall supply wired directly to one of the inputs. So when house power drops out we get an email (assuming the external portions of the network remain up). The JNIOR retries the email of course.

[Bruce Cloutier]

The scripting is kind of unique. Consider what you might be able to do if you could use PHP to render a BAT batch file? Basically we have a compiled PHP-like preprocessor for JNIOR web content. We employed the same preprocessor to generate batch files and you can also just RUN scripted programs from the command line. Was a lot easier than trying to implement any of the myriad of scripting languages that have come about over the years. Pretty powerful and doesn't dramatically increase the OS footprint.