The upcoming pixelserv-tls 2.1.0 brings a few exciting new features. They speed up browsing as well as enhancing a user's capability to inspect potential privacy breach. While this blog post highlights the features, supplemental details are also available as usual in the MAN page.
Cache SSL certificates in Memory
To speed up rapid switch of server identity, we cache most frequently used certificates in memory. To speed up connections from same clients, we enable SSL session resumption.
With both features, recurring HTTPS requests will require significantly less time to process. A session resumption takes < 1ms on a 1.2GHz Cortex-A9 CPU. That's near HTTP speed. While compare this number to 40ms on the same CPU without certificate cache and session resumptions, the improvement in speed is huge.
We default cache size to 50 certificates. Once full, least recently used certificates will be purged from cache. The cache size can be modified by the new command line option
Prefetch/Save SSL Cache
On normal exit (signal
SIGTERM), pixelserv-tls saves the top 3/4 of most frequently used certificates to a file named '
prefetch' in CERT_PATH (
/var/cache/pixelserv on standard systems or
/opt/var/cache/pixelserv on Entware). The saved entries will be prefetched and initialise SSL cache on next startup.
New SSL cache related counters
sct- number of SSL certs in cache
sch- number of reuses of cached SSL certs
scm- number of misses to find a cert in cache. Hence, a SSL cert has to be loaded from disk into cache.
scp- number of purges to give room for a new SSL cert. If this number is high compared to
sch, you may want to increase cache size.
sst- number of TLS sessions in cache.
ssh- number of reuses of cached TLS sessions.
ssm- number of misses to find a TLS session in cache. Hence, a new TLS session has to be created that requires going through a full handshake.
ssp- number of purges to give room for a new TLS session
New sub-types of Handshake Failures
We break down and place some of slu errors into two sub-types, uca (unknown CA reported by clients) and uce (unknown certificate reported by clients). These two sub-types help you better monitor 'dubious' connectivities from clients. See the MAN page for how to make best use of them.
Easier to Import your Pixelserv CA certificate
Every serious pixelserv-tls user should get yourself a Pixelserv CA certificate and import this CA cert to your main browsers and client devices. In v2.1, we have introduced a new URI
/ca.crt to make life easier for you to retrieve and import the CA cert.
On client devices, simply go to '
http://<pixelserv ip>/ca.crt' to download the CA cert and follow the prompts and instructions to finish the import. More details can be found on this wiki.
pixelserv-tls has advanced in speed to a state that latency in loading certificates from disk and generating certificates to disk become two of the major bottlenecks. Hence, a benchmark that runs the same crypto and disk access subroutines as pixelserv-tls normal does is added through a new command line option '
-B'. The measured timings are good indications that pixelserv-tls will experience in its daily operation. Sample output:
$ pixelserv-tls -B CERT_PATH: /opt/var/cache/pixelserv CERT_FILE: _.bing.com 1. generate cert to disk: 496.893 ms load from disk: 9.976 ms 2. generate cert to disk: 697.799 ms load from disk: 9.926 ms 3. generate cert to disk: 640.280 ms load from disk: 10.210 ms 4. generate cert to disk: 389.483 ms load from disk: 10.122 ms 5. generate cert to disk: 435.186 ms load from disk: 9.925 ms 6. generate cert to disk: 393.154 ms load from disk: 9.971 ms 7. generate cert to disk: 638.674 ms load from disk: 9.934 ms 8. generate cert to disk: 461.701 ms load from disk: 9.930 ms 9. generate cert to disk: 653.679 ms load from disk: 10.105 ms 10. generate cert to disk: 580.715 ms load from disk: 10.001 ms generate to disk average: 538.756 ms load from disk average: 10.010 ms
Optional CERT_FILE and CERT_PATH can be specified as command line arguments.
Note that majority of the time is spent within crypto routines and this is not a disk benchmark.
An admin port restricts access to URIs that are considered as for administrative purposes. These URIs are '
/servstats.txt', and '
An admin port is specified with the new option '
-A'. Once enabled, access to the URIs are restricted to the given port and over HTTPS only. For example, with '
-A 344', you then can only access
- through '
- but not '
- nor '
Default is no admin port. pixelserv-tls answers these URIs on all ports and over both HTTP and HTTPS. You could use an admin port with additional firewall rules to impose better control over who could administer pixelserv-tls.
Ability to Run without CA certificate
In this mode of operations, pixelserv-tls does not attempt to load
CERT_PATH. Hence, no automatic certificate generation. In this mode, pixelserv-tls acts as a web server with SNI capability and service on behalf of as many servers as the number of certificates placed in
CERT_PATH. These certificates can be from Let's Encrypt or other commercial CAs as well as self-signed.