A neat feature of the modern web is that Adobe Flash Player is (finally) starting to be replaced by HTML5 apps, and that includes video playback such as YouTube.
During this change I have, among allot of other people on the Internet, noticed that our favorite browser is not yet optimized for this future proof technology. And enabling (now default) HTML5 playback can lead to audio/video stutter and high CPU-usage.
Until support for hardware acceleration is more widespread in Firefox Quantum, I’ve found a work-around on the Mozilla Support page. Which is:
Simply go to Settings > General > Performance and bump up the Content process limit (Uncheck Use recommended performance settings).
It seems, at least for me, help with the CPU utilization when playing HD/4k video on YouTube.
Read more at the support article:
Using Squid or any other proxy for transparent caching/filtering of HTTP traffic has many benefits, being for logging purposes or the aforementioned use-cases, keeping every client configured can be a nuance. Networking equipment from Cisco and Juniper has the ability to redirect all passing HTTP traffic, in IOS and JunOS respectively, to the desired proxy.
A more cost-effective solution is to use a Linux box inline the client network and the “Internet”, redirecting HTTP traffic to a separate transparent proxy box, before it reaches the Internet.
Another, more realistic (…), use case. Is to use the transparent caching proxy server inline the VPN Server, VPN Client and the Internet. Example below.
VPN Client --> VPN Server --> Caching Transparent Proxy --> Internet
The benefit being that the VPN Server can resend cached content to the VPN Client, reducing latency for the server and the connection as a whole.
Using the example above, traffic redirection using iptables most efficiently takes place on the VPN Server.
Below is the required configuration:
~# iptables -t nat -A PREROUTING -i [TUNNELIFACE] -p tcp -m tcp --dport 80 -j DNAT --to-destination [PROXYIP]:[PROXYPORT]
~# iptables -t nat -A PREROUTING -i tun0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 172.17.13.37:3128
As an end note. For best results and lowest possible latency, the VPN Server and Caching Transparent Proxy should be on the same network, preferably on the same network switch.
When troubleshooting a network integration or any other connection issue in Linux, step one is usually a matter of checking to see if the network port on the other side is even responding.
Netcat -The network Swiss Army knife (Hobbit, not nmap)- is the right tool for the job.
Before we begin, NetCat needs to be installed.
# RHEL / CentOS
~$ yum install nc
# Debian / Ubuntu
~$ apt-get install nc
Once installed, you can invoke Netcat like so:
~$ nc [REMOTE_SERVER] [PORT]
[REMOTE_SERVER] – The server to be checked
[PORT] – The service/port to be checked
Connection to google.com 443 port [tcp/https] succeeded!
Find the Procs
After upgrading an important package in Linux -or other Unix variant- that provides a library used by many other processes. Instead of restarting the server for the new lib to take effect, the procs can be restarted -or HUPed- individually.
Before we begin, lsof needs to be installed.
# RHEL / CentOS
~$ yum install lsof
# Debian / Ubuntu
~$ apt-get install lsof
In the following example, we list what processes are using the libcrypto library in Raspbian.
~$ lsof /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sshd 551 root mem REG 179,2 1418532 10074 /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
ntpd 2321 ntp mem REG 179,2 1418532 10074 /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
sshd 6643 root mem REG 179,2 1418532 10074 /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
sshd 6649 meow mem REG 179,2 1418532 10074 /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
openvpn 30044 nobody mem REG 179,2 1418532 10074 /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
Next, the affected processes can be restarted:
~$ service [SERVICENAME] restart
~$ systemctl restart [SERVICENAME]
~$ kill -HUP 31337
When security and integrity of a file is critical, such as with x509 certificates or other important documents, OpenSSL or other variant can be used to secure the file. With strong encryption and -hopefully- a strong password.
OpenSSL is generally available on all UNIX variants, downloadable as an executable for Windows and is also used with many other applications through the LibCrypto library.
If you need help picking a strong password, I’d recommend StrongPasswordGenerator.Com. Never share the password with the receiving party over the same medium as the file transmission. Send it Out-Of-Band over a SMS or Telephone Call or similar.
In the following example, we take a file and encrypt it using AES-256-CBC, protecting it using a password and adding a salt for extra randomness. The output is added to a newly created file.
~$ openssl enc -salt -aes-256-cbc -in TuxPics.tgz -out TuxPics.tgz.enc
enter aes-256-cbc encryption password: q55Tc9Hp68-Ry4d
Verifying - enter aes-256-cbc encryption password: q55Tc9Hp68-Ry4d
The content of TuxFiles.tgz.enc is perceived as a random binary string to EVE when in transit on the open network.
In the next example, we do the reverse action. Decrypting the file using the same password and appending the output to a new file.
~$ openssl enc -aes-256-cbc -d -in TuxFiles.tgz.enc > TuxFiles.tgz
enter aes-256-cbc decryption password: q55Tc9Hp68-Ry4d
In case the file type is not known from the decrytion result (stdout), the “file” command can be used when running Linux.
~$ file TuxPics
TuxPics: gzip compressed data