TP-Link's Idea of Security

My wired network finally got too big for a single router so I decided to get myself a switch.

I realistically needed the dumbest switch there is - just 4 gigabit ports and I would be happy. Thus my eyes were immediately drawn to TP-Link SG105 at $20 on Amazon. However, for only $10 more I noted one could get SG105E. The exactly same switch but with a basic manageability features.

Both switches look exactly the same in their steel shell. They are well built and my impression is they can take a beating. You can get inside the chassis by simply undoing two screws and you will see a really simple board. Based on the components, I don’t think you can get much over 1 Gbps on its bus and thus forget about actually reaching maximum speed when all ports are in use - acceptable compromise for home I guess. I would say 9V power supply is the only thing that actually looks cheap. Fortunately, switch works without any noticeable issues on much more common 12V too (albeit you probably forfeit warranty if you do that).

So, what do you get for extra money? Well, you get DSCP, a QoS priority system nobody seems to use in general and definitely not intended for home network. There is also rate limiting with a storm control. Probably not often needed at home but can be quite useful for troubleshooting naughty device.

Further more you get support for up to 32 VLANs - quite nice if your home network needs a bit of separation. Lastly you will also find more “enterprisey” features like port mirroring and link aggregation. Never figured why you need something like this on 5-port switch but I guess it doesn’t hurt to have them.

The most useful feature, and the reason I decided to give extra tenner was the GUI. From GUI you can easily see if your cable is connected, whether packets are flowing, and are there any transmission errors. Usually home switches and routers have ugly interface so I was ready for that. What I wasn’t ready for is abysmal security.

Let’s start with a good thing - you can change user name. Security-wise, that is probably the best thing you can do in your network to escape 95% automated attacks. Yes, this won’t help much if someone is “out to get you” but most script kiddies will be thwarted. And that’s as far as security goes for this device.

To start with, your password is restricted to English alphabet, digits, and underscore (_) sign. Restricting the length and character set is not significant just because it lowers number of combinations your password can take. I am sure you are using password manager and even these weak rules should give you years of good sleep if password is hashed.

But, if they used hashed passwords in the first place, they wouldn’t need character set restrictions. These restrictions are almost always a signal your password is saved in a clear-text. Combined with the login screen allowing for infinite number of guesses at unthrottled speed, and you have the whole security tumbling down.

But don’t worry anybody will brute force this device. Nope - there is no need as you can simply snoop all communication as there is no support for HTTPS. Everything you do on its web interface is for everybody to see. They didn’t even bother to do a simple digest authentication. Nope, all is sent in clear text.

For $20 it is hard not to recommend base model of this switch. It is sturdy, cheap, and reasonably performant. Unfortunately, for only $10 more you can get a device performing the same base function but with a woefully insecure user interface.

I would stick with unmanaged model.

NAS4Free Serial Console on Supermicro A1SRi

Having Supermicro A1SRi motherboard is awesome - especially when it comes to remote management over IPMI. However, as I have NAS4Free on it, one thing annoyed me all the time - why I don’t see anything in IPMI Text Console tab? It’s not that I really need it as iKVM works for me, but I find inactive things annoying. So I went to correct this grave omission.

Albeit it took me a while to configure it, the final setup is easy. Utter lack of documentation is what caused the drag.

First step is to enable console redirection in Supermicro’s BIOS. While COM1 is best left to the BIOS itself, COM2/SOL is ours for taking. The only thing needed is to enable second serial console.

For the next (and final) step we must visit NAS4Free’s GUI under System, Advanced, loader.conf in order to setup four variables controlling the boot process:

Using boot_multicons essentially tells FreeBSD to allow boot output to multiple consoles. Without this, only one console would be supported for boot messages.

That is crucial for the next console variable where we set console output to both video console (vidconsole) and to serial console (comconsole). And the order is important. While most messages will be mirrored on both outputs, some “userland” (e.g., application, rc.d, and script) messages will be displayed only on the first. I personally like to have that on the video console as it allows for color and looks nicer but your mileage (and needs) might vary.

Last two settings control which address the port is located at (COM2 is traditionally at 0x2F8) and the serial port speed has to match Supermicro’s default of 115200 bauds.

PS: Yes, these steps work on FreeNAS too.

[2018-07-22: NAS4Free has been renamed to XigmaNAS as of July 2018]

About Time

As we approach yet another biyearly daylight savings time change, there came a news about politicians actually doing something smart for a change. European Parliament voted to keep the same UTC offset the whole year round. If this decision is followed through, gone are the days of hunt for every clock to update it an hour back or forward before the next change comes.

And yes, of course it is not as simple as turning the daylight change off. First it needs to get to the European Commission that traditionally likes to avoid implementing anything. Then all member states need to agree when to do it. Then decision needs to be postponed multiple times. Then everybody will try to implement the decision at the very last moment. You know, the usual.

However, for the first time in forever there is some hope. I can already see myself talking to my grandchildren about the dark times when people all around the world changed their time by hour (or less - damn you Lord Howe Island), for reasons long forgotten, and at the time every country decided upon themselves.

Grandchildren will probably just say that grandpa is crazy and that this could have never been. And then they will go out to play in the UTC world…

Fix NAS4Free's Non-Working Google SMTP After Upgrade

A few days after I updated NAS4Free to 11.1.0.4 (revision 5109), I noticed my e-mail reports were not arriving any longer. After making sure my script was working, I went onto checking my e-mail settings - first by sending a test e-mail.

There I received not really helpful message: “Failed to send test email. Please check the log files.” Further check in log showed equaly useless “root: Failed to send test email to: mail@example.com.” I guess it was time for the command line.

The easiest way to test e-mail is probably running msmtp directly from SSH and see what its issue is:

echo "Subject: Test" |& msmtp mail@example.com
 msmtp: account default from /usr/local/etc/msmtprc: cannot use tls_trust_file with tls_certcheck turned off

If you check that file, the offending line is indeed there:

cat /usr/local/etc/msmtprc
 account default
 domain example.com
 host smtp.gmail.com
 port 587
 protocol smtp
 from mail@example.com
 auth login
 user mail@example.com
 password 123
 tls on
 tls_starttls on
 tls_certcheck off
 !!tls_trust_file!! /usr/local/etc/ssl/cert.pem
 syslog LOG_MAIL

The easiest fix for this issue is to enable TLS Server Certificate Check in GUI. This will actually add a bit of security and there are no real downsides if you use Google’s SNMP as I do.

If you are using a custom e-mail server with self-signed certificate, removing offending line in post-startup script is your best bet:

sed -i -- '/^tls_trust_file/d' /usr/local/etc/msmtprc

Of course, proper solution would be for GUI to omit TLS trust file configuration when certificate check if off. Due to unrelated changes this seems to be already fixed in msmtp.in source file. Next version will have it all sorted out. :)

[2018-02-16: Issue is fixed in version 11.1.0.4.5127.]

[2018-07-22: NAS4Free has been renamed to XigmaNAS as of July 2018]

GELI With XTS-AES or AES-CBC?

If you are using GELI to encrypt disks on FreeNAS or NAS4Free, there are multiple algorithms you can use. However, in practice, for me this always becomes a choice between AES-XTS and AES-CBC. Since every modern processor had AES primitives supported in hardware, these two offer performance other algorithms cannot reach.

The current industry standard for disk encryption is XTS-AES and that is mode I usually default to. It has been made specifically to facilitate full-disk encryption and has no known attacks (other than malleability attack common to practically all such algorithms).

Using AES-CBC is not as crazy as it seems. While there is a known “watermark” attack, GELI is not vulnerable at it uses CBC-ESSIV. And, while it is still vulnerable against malleability attack, it’s more resilient than XTS to some (albeit rather unrealistic) attacks while sharing CBC’s “friendliness” to altering bits on per-block level.

In the absence of any new attack, you are probably fractionally more secure with XTS but realistically both XTS-AES and AES-CBC with ESSIV can be considered equivalent and well-suited for full-disk encryption. That said, as security is not concern, are there performance differences between those two?

And there are. At least on NAS4Free albeit I believe the same applies across the BSD family - including FreeNAS.

My ZFS mirror on i3-4010U used XTS-AES-128 for encryption and its median write speed was 197 MB/s. The same mirror had its write speed increased to 389 MB/s once both disks were set to use AES-CBC-128. Interestingly, changing the encryption mode on a single disk to CBC while the other was still using XTS also improved performance - all the way to 384 MB/s. Mind you there are no security benefits running two disks in different encryption modes. I just did it for fun. :)

My Atom C2558 server using software encryption with XTS-AES only wrote at 110 MB/s. Once both physical drives used AES-CBC, speed jumped to 162 MB/s. Again, changing only a single drive in mirror to CBC increased write speed to 157 MB/s.

The same server using hardware encryption could write 160 MB/s when both drives encrypted using XTS-AES. Both drives using AES-CBC achieved again 160 MB/s. Once more, the curiosity was half/half situation with write speed at 162 MB/s.

Based on these results it is obvious that AES-CBC performs much better than XTS-AES in some cases or both have the same speed at worst. The fact changing a single drive to CBC already brought 95% of improvement tells me that CPU was really straining with XTS despite hardware AES-NI support. On the slower CPU difference was non-existent albeit this was more related to its general slowness of AES-NI on Atom than to anything algorithm specific.

Intel’s own tests on the same generation (albeit vastly more powerful processors) shows that XTS implementation can actually be faster than CBC - especially when multiple cores can “exploit” XTS’ inherent parallelism.

This just shows that performance is highly dependent on everything in the pipeline - especially software support - and not just hardware. And one should be careful to occasionally retest if old assumptions are still valid. For example, the next version of BSD crypto library could improve performance of XTS to surpass CBC.

I personally will still stick with XTS-AES. Encryption and decryption speeds, while not exhilarating, are more than adequate for sharing files over Samba connections. While AES-CBC will surely enjoy support in the future, XTS is the one standardized for full-disk encryption. Unless a security issue is discovered, support for it will only get better with time.

PS: Malleability attack on AES-XTS and AES-CBC is actually not that problematic for my setup as ZFS includes data checksum. To be completely sure, for sensitive applications, one should think about using SHA-256 instead of default Fletcher-16 checksum.

PPS: GELI actually doesn’t use ESSIV as you would find it on Linux. However, its implementation is pretty much equivalent to it in both security and performance.

PPPS: For curious, I used the following command to test write speed, repeating the measurement 5 times:

dd if=/dev/zero of=/mnt/Temp/Test.tmp bs=4096 count=1048576

PPPPS: You can also get rough idea which encryption method is faster by running OpenSSL speed test:

openssl speed -evp aes-128-xts
openssl speed -evp aes-128-cbc

[2018-07-22: NAS4Free has been renamed to XigmaNAS as of July 2018]