New Features in pixelserv-tls v2.1

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 -c.

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.

Crypto Benchmark

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.

Admin Port

An admin port restricts access to URIs that are considered as for administrative purposes. These URIs are '/servstats', '/servstats.txt', and '/log=LEVEL'.

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 'https://pixelserv_ip:344/servstats'
  • but not 'http://pixelserv_ip:344/servstats'
  • nor 'https://pixelserv_ip/servstats'.

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 ca.crt and ca.key in 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.

comments powered by Disqus