pixelserv pixelserv - A Better One-pixel Webserver for Adblock

[kvic]

You talking about these entries?

 handshake failed: client 192.168.1.10:59653 server stats.appsflyer.com. Lib(20) Func(138) Reason(227)

Aren't they logged in "slu" ?

Right, all "handshake failed.." will increment slu by one, and log the detail to LEVEL 2 in syslog.

 

[Asad Ali]

Right, all "handshake failed.." will increment slu by one, and log the detail to LEVEL 2 in syslog.

Yup so my original question still stands then lol
Is "slc" shows in logs and if yes then how will it show can you give me an example? Or they look same as "slu" entries?

P.s Sorry for bombarding you with questions.

 

[kvic]

Yup so my original question still stands then lol
Is "slc" shows in logs and if yes then how will it show can you give me an example? Or they look same as "slu" entries?

P.s Sorry for bombarding you with questions.

I thought I answered your original question already..twice. lol

One slu event is logged on LEVEL 2 as one "handshake failed..." entry. If you grep and wc count, the two numbers shall be equal.

 

[Asad Ali]

I thought I answered your original question already..twice. lol

One slu event is logged on LEVEL 2 as one "handshake failed..." entry. If you grep and wc count, the two numbers shall be equal.

I'll apologies in advance but my original doubt is still unanswered at least in my understanding.

I'm not talking about "slU" but I'm talking about "slC"

I know "slu" are counted as "handshake failed" but how "slc" is counted? What log entry will it show and how can I grep them out?

 

[kvic]

I'll apologies in advance but my original doubt is still unanswered at least in my understanding.

I'm not talking about "slU" but I'm talking about "slC"

I know "slu" are counted as "handshake failed" but how "slc" is counted? What log entry will it show and how can I grep them out?

GOSH. Apparently you're right! Time for me to go bed indeed.

slc is not logged.

 

[Asad Ali]

GOSH. Apparently you're right! Time for me to go bed indeed.

slc is not logged.

Ahh perfect that's all I wanted to know.
Case closed lol
Thanks and have a good night sleep [emoji4]

 

[kvic]

2.1.3-test.1 is available

This version enhances the uniqueness of serial numbers created for generated certificates. This is an essential update for Firefox users, especially running pixelserv-tls on a "fast" router such as 86U or a PC.

The issue

With a fast processor, previous versions will very likely generate two certificates with the same serial number. Firefox has historically treated such certificates as invalid. Hence, TLS handshake will fail, and boost your slu count (significantly if the problematic certificates are frequently used).

Install

Use the same one-liner script to install.

Then delete all existing generated certificates with the following commands or otherwise:

cd /opt/var/cache/pixelserv
mv ca.* ..
rm *
mv ../ca.* .

@Asad Ali contributed to the discovering of this issue

 

[jrmwvu04]

Running for a couple of weeks on a hastily updated entware installation before I went on hiatus:

libopenssl - 1.0.2o-1
pixelserv-tls - 2.1.1-1

15 days up with the usual looking statistics, but memory usage has bloomed to 30 MB. I haven't messed with it and probably won't because if it ain't broke.. just thought I'd toss a mention. I don't particularly feel like downgrading the libopenssl package as of now, but there's definitely a difference.

 

[Makaveli]

2.1.3-test.1 is available

nice will update to this shortly.

pixelserv-tls 2.1.1 (compiled: Apr 15 2018 13:47:59) options: 192.168.1.3 -l 2

uts    42d 02:36    process uptime
log    2    critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc    13    number of active service threads
kmx    41    maximum number of service threads
kvg    1.16    average number of requests per service thread
krq    163    max number of requests by one service thread
req    213974    total # of requests (HTTP, HTTPS, success, failure etc)
avg    889 bytes    average size of requests
rmx    58359 bytes    largest size of request(s)
tav    5 ms    average processing time (per request)
tmx    5338 ms    longest processing time (per request)
slh    15473    # of accepted HTTPS requests
slm    152    # of rejected HTTPS requests (missing certificate)
sle    0    # of rejected HTTPS requests (certificate available but bad)
slc    124268    # of dropped HTTPS requests (client disconnect without sending any request)
slu    41137    # of dropped HTTPS requests (other TLS handshake errors)
uca    604    slu break-down: # of unknown CA reported by clients
uce    14495    slu break-down: # of unknown cert reported by clients
sct    50    cert cache: # of certs in cache
sch    150571    cert cache: # of reuses of cached certs
scm    838    cert cache: # of misses to find a cert in cache
scp    825    cert cache: # of purges to give room for a new cert
sst    4    sess cache: # of cached TLS sessions (for older non-RFC5077 clients)
ssh    39710    sess cache: # of reuses of cached TLS sessions
ssm    7245    sess cache: # of misses to find a TLS session in cache
ssp    0    sess cache: # of purges to give room for a new TLS session

 

[Asad Ali]

Running for a couple of weeks on a hastily updated entware installation before I went on hiatus:

libopenssl - 1.0.2o-1
pixelserv-tls - 2.1.1-1

15 days up with the usual looking statistics, but memory usage has bloomed to 30 MB. I haven't messed with it and probably won't because if it ain't broke.. just thought I'd toss a mention. I don't particularly feel like downgrading the libopenssl package as of now, but there's definitely a difference.

You need to install @kvic's version of libopenssl as he mentioned that the newer version from Entware doesn't have the required flag enabled.

 

[jrmwvu04]

You need to install @kvic's version of libopenssl as he mentioned that the newer version from Entware doesn't have the required flag enabled.

Yeah. As I said, I don’t feel like jumping through those hoops. Hopefully that change gets put through at some point. It’s not worth the hassle to undo the changes at every entware update.

 

[SMS786]

2.1.3-test.1 is available

This version enhances the uniqueness of serial numbers created for generated certificates. This is an essential update for Firefox users, especially running pixelserv-tls on a "fast" router such as 86U or a PC.

The issue

With a fast processor, previous versions will very likely generate two certificates with the same serial number. Firefox has historically treated such certificates as invalid. Hence, TLS handshake will fail, and boost your slu count (significantly if the problematic certificates are frequently used).

Install

Use the same one-liner script to install.

Then delete all existing generated certificates with the following commands or otherwise:

cd /opt/var/cache/pixelserv
mv ca.* ..
rm *
mv ../ca.* .

@Asad Ali contributed to the discovering of this issue

Looks great @kvic! Awesome to see the innovation continue..

Just updated on my 68U. Not sure if this is a bug or not, but when I update the servstats page on the web, the stats don't update for a good 4-5 min, then afterwards I see a massive update including all of the web activity till then. On previous versions, the updates reflected the recent data everytime I reloaded the stats page. Tried clearing browser cache but the issue persists.Using Firefox 60 fyi.

Update: Reinstalled and now all is fine.

 

[Asad Ali]

Just updated on my 68U. Not sure if this is a bug or not, but when I update the servstats page on the web, the stats don't update for a good 4-5 min, then afterwards I see a massive update including all of the web activity till then. On previous versions, the updates reflected the recent data everytime I reloaded the stats page. Tried clearing browser cache but the issue persists.Using Firefox 60 fyi.

No such issue on my setup but I'm running it on 86U.

 

[kvic]

Running for a couple of weeks on a hastily updated entware installation before I went on hiatus:

libopenssl - 1.0.2o-1
pixelserv-tls - 2.1.1-1

15 days up with the usual looking statistics, but memory usage has bloomed to 30 MB. I haven't messed with it and probably won't because if it ain't broke.. just thought I'd toss a mention. I don't particularly feel like downgrading the libopenssl package as of now, but there's definitely a difference.

1.0.2o fixed one CVE as seen on the changelog. The description seems to imply it's safe. So more like a defensive fix. Not a big deal to live without it.

 

[kvic]

nice will update to this shortly.

pixelserv-tls 2.1.1 (compiled: Apr 15 2018 13:47:59) options: 192.168.1.3 -l 2

uts    42d 02:36    process uptime
log    2    critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc    13    number of active service threads
kmx    41    maximum number of service threads
kvg    1.16    average number of requests per service thread
krq    163    max number of requests by one service thread
req    213974    total # of requests (HTTP, HTTPS, success, failure etc)
avg    889 bytes    average size of requests
rmx    58359 bytes    largest size of request(s)
tav    5 ms    average processing time (per request)
tmx    5338 ms    longest processing time (per request)
slh    15473    # of accepted HTTPS requests
slm    152    # of rejected HTTPS requests (missing certificate)
sle    0    # of rejected HTTPS requests (certificate available but bad)
slc    124268    # of dropped HTTPS requests (client disconnect without sending any request)
slu    41137    # of dropped HTTPS requests (other TLS handshake errors)
uca    604    slu break-down: # of unknown CA reported by clients
uce    14495    slu break-down: # of unknown cert reported by clients
sct    50    cert cache: # of certs in cache
sch    150571    cert cache: # of reuses of cached certs
scm    838    cert cache: # of misses to find a cert in cache
scp    825    cert cache: # of purges to give room for a new cert
sst    4    sess cache: # of cached TLS sessions (for older non-RFC5077 clients)
ssh    39710    sess cache: # of reuses of cached TLS sessions
ssm    7245    sess cache: # of misses to find a TLS session in cache
ssp    0    sess cache: # of purges to give room for a new TLS session

This is a good data point for future comparison. Currently you have a ratio: (slu - uca - uce)/(slu + slc + slm + slh) = 14.38%

We'll see how do you fare with 2.1.3-test.1 in a couple of weeks.

 

[kvic]

Looks great @kvic! Awesome to see the innovation continue..

Just updated on my 68U. Not sure if this is a bug or not, but when I update the servstats page on the web, the stats don't update for a good 4-5 min, then afterwards I see a massive update including all of the web activity till then. On previous versions, the updates reflected the recent data everytime I reloaded the stats page. Tried clearing browser cache but the issue persists.Using Firefox 60 fyi.

I can't reproduce this issue either. pixelserv-tls on 56U. FF 61.

If your 68U uptime is long enough, perhaps the firmware goes "bad". A reboot should fix it I think..

 

[SMS786]

I can't reproduce this issue either. pixelserv-tls on 56U. FF 61.

If your 68U uptime is long enough, perhaps the firmware goes "bad". A reboot should fix it I think..

The issue seems to persist. Will continue to keep an eye on it and report back..

Edit: Reinstalled test1 and now issue is gone thankfully.

 

[kvic]

The issue seems to persist. Will continue to keep an eye on it and report back..

More details would help to diagnose the issue..

1. Does it only happen to Firefox?
2. Does the servstats page finish loading immediately but counters don't change?
3. Or does the page loading stall for 4-5mins and then counters updated?

I'm guessing you meant the latter. A couple of things you could do to diagnose the issue:

1) enable log LEVEL 5 to see what's happening inside pixelserv-tls
2) "killall -SIGUSR1 pixelserv-tls" to dump statistics to syslog and check if counters change during the "stall" period in Firefox
3) use Wireshark to capture the test duration and we can check what's going on at packet level
4) revert back to 2.1.1 and see if the issue is reproducible. You can use:

$ opkg --force-reinstall install pixelserv-tls

 

[kvic]

The issue

With a fast processor, previous versions will very likely generate two certificates with the same serial number. Firefox has historically treated such certificates as invalid. Hence, TLS handshake will fail, and boost your slu count (significantly if the problematic certificates are frequently used).

One interesting tidbit...

Without checking each certificate, you could easily assess by yourself whether you could possibly have certificates with duplicated serial numbers. Run "pixelserv-tls -B" on your router/server:

$ pixelserv-tls -B
CERT_PATH: /opt/var/cache/pixelserv
CERT_FILE: _.bing.com
 1. generate cert to disk: 694.013 ms    load from disk: 9.856 ms
 2. generate cert to disk: 281.175 ms    load from disk: 10.093 ms
 3. generate cert to disk: 434.943 ms    load from disk: 9.928 ms
 4. generate cert to disk: 490.977 ms    load from disk: 9.963 ms
 5. generate cert to disk: 444.670 ms    load from disk: 10.506 ms
 6. generate cert to disk: 414.943 ms    load from disk: 10.118 ms
 7. generate cert to disk: 538.423 ms    load from disk: 10.213 ms
 8. generate cert to disk: 855.620 ms    load from disk: 10.018 ms
 9. generate cert to disk: 1001.284 ms    load from disk: 9.946 ms
10. generate cert to disk: 758.863 ms    load from disk: 10.077 ms
generate to disk average: 591.491 ms
  load from disk average: 10.072 ms

If your "generate to disk average" time < 500ms, you're very likely to have certificates with duplicated serial numbers.

If it's above 500ms, you're very unlikely to have such certs.

 

[Asad Ali]

@kvic Every 86U owner should definitely upgrade to 2.1.3-test.1 since it's insanely fast in generating certificates lol

 admin@RT-AC86U:/tmp/home/root# pixelserv-tls -B
CERT_PATH: /opt/var/cache/pixelserv
CERT_FILE: _.bing.com
 1. generate cert to disk: 90.745 ms    load from disk: 4.813 ms
 2. generate cert to disk: 75.919 ms    load from disk: 4.798 ms
 3. generate cert to disk: 33.692 ms    load from disk: 4.784 ms
 4. generate cert to disk: 50.369 ms    load from disk: 4.753 ms
 5. generate cert to disk: 74.446 ms    load from disk: 4.820 ms
 6. generate cert to disk: 45.083 ms    load from disk: 4.766 ms
 7. generate cert to disk: 27.466 ms    load from disk: 4.793 ms
 8. generate cert to disk: 67.827 ms    load from disk: 4.773 ms
 9. generate cert to disk: 50.782 ms    load from disk: 4.806 ms
10. generate cert to disk: 63.992 ms    load from disk: 4.776 ms
generate to disk average: 58.032 ms
load from disk average: 4.788 ms