pixelserv pixelserv - A Better One-pixel Webserver for Adblock

[Makaveli]

pixelserv-tls 2.1.0-rc.1 (compiled: Mar 17 2018 21:02:50) options: 192.168.1.3

uts    0d 05:34    process uptime
log    1    critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc    1    number of active service threads
kmx    9    maximum number of service threads
kvg    1.01    average number of requests per service thread
krq    5    max number of requests by one service thread
req    1950    total # of requests (HTTP, HTTPS, success, failure etc)
avg    708 bytes    average size of requests
rmx    1793 bytes    largest size of request(s)
tav    4 ms    average processing time (per request)
tmx    25 ms    longest processing time (per request)
slh    54    # of accepted HTTPS requests
slm    2    # of rejected HTTPS requests (missing certificate)
sle    0    # of rejected HTTPS requests (certificate available but bad)
slc    1793    # of dropped HTTPS requests (client disconnect without sending any request)
slu    88    # of dropped HTTPS requests (other TLS handshake errors)
sct    48    cert cache: # of certs in cache
sch    1910    cert cache: # of reuses of cached certs
scm    2    cert cache: # of misses to find a cert in cache
scp    0    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    54    sess cache: # of reuses of cached TLS sessions
ssm    7    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

 

[kvic]

OK! So I tried this. Didn't need to do the certificate generation since the installer performed that automatically.

Note that the wiki on GitHub is written for a wider audience. More towards users who install pixelserv-tls themselves and manage block lists separately. Also written for authors who are able to see the value in pixelserv-tls and intend to integrate into their solutions (such as AB-Solution) and platforms (such as Arch Linux & its adblocker).

Unfortunately just going in my browser to 192.168.x.3/ca.crt didn't do anything for me (just delivered a blank screen)

Android and iOS clients will prompt you. Simply follow the on-screen instructions.

 

[Protik]

After 12 hours on rc1,

pixelserv-tls 2.1.0-rc.1 (compiled: Mar 17 2018 21:02:50) options: 192.168.2.2 -c 150

uts    0d 12:19    process uptime
log    1    critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc    1    number of active service threads
kmx    35    maximum number of service threads
kvg    1.27    average number of requests per service thread
krq    26    max number of requests by one service thread
req    2544    total # of requests (HTTP, HTTPS, success, failure etc)
avg    869 bytes    average size of requests
rmx    16095 bytes    largest size of request(s)
tav    22 ms    average processing time (per request)
tmx    1935 ms    longest processing time (per request)
slh    787    # of accepted HTTPS requests
slm    1    # of rejected HTTPS requests (missing certificate)
sle    0    # of rejected HTTPS requests (certificate available but bad)
slc    874    # of dropped HTTPS requests (client disconnect without sending any request)
slu    865    # of dropped HTTPS requests (other TLS handshake errors)
sct    135    cert cache: # of certs in cache
sch    2063    cert cache: # of reuses of cached certs
scm    23    cert cache: # of misses to find a cert in cache
scp    0    cert cache: # of purges to give room for a new cert
sst    0    sess cache: # of cached TLS sessions (for older non-RFC5077 clients)
ssh    128    sess cache: # of reuses of cached TLS sessions
ssm    326    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

 

[kvic]

kvic
Ladies and gentlemen... I have resolve the slu issue for IOS!!

Refers to https://stackoverflow.com/questions...ficates-not-trusted-automatically-self-signed

You need to set it to trusted in the General, About, Certificate Trust setting!!

Have fun!

Kvic, can please add this into to the wiki on importing to IOS 11 and above

@jrmwvu04 faced with a cert problem many months ago, and figured that out. Hence, I added it to the Wiki already. Nevertheless, thanks for sharing your finding

 

[kvic]

@kvic maybe you can use this website for testing

What happened should be that one or more domains commonly exist in people's block list upsets fivethirtyeight.com. The website simply goes crazy and in desperate attempt to retrieve what it wants.

Without any domains blocked, the website doesn't look that crazy. Since in this case repeated attempts not hurting people's browsing experience, just let it be, rather than spending time to figure out and whitelist the 'wrongly blocked' domain(s).

If people wonder, how I figure out. You have this ability too. All built-in pixelserv-tls. (*grin*)

Mini How-To

1. temporarily turn on logging LEVEL to 4 (by using URI '/log=4'
2. watch your /tmp/syslog.log. You'll see which URL(s) go crazy.
3. reset logging LEVEL back to 1 (with URI '/log=1')

The logging facility in pixelserv-tls allows you to inspect 'wrongly blocked' domains as well as any privacy data a 'rogue' domain intend to upload.

 

[kvic]

@vesalius @Makaveli @Protik thank you for sharing the servstats.

Your slu seems okay to me. However, if anyone suspect you've done everything properly but still observe a large percentage (slu/req), then I have a build for armv7 that include traces to figure out what are the underlying reason.

 

[Protik]

@vesalius @Makaveli @Protik thank you for sharing the servstats.

Your slu seems okay to me. However, if anyone suspect you've done everything properly but still observe a large percentage (slu/req), then I have a build for armv7 that include traces to figure out what are the underlying reason.

Usually my slu was lower compared to slh after a while for v2.0.1. Let me observe one more day to see if slh catches up with slu or not. If not, I may try the version with traces.

 

[esco]

No crash so far with 2.1.0-rc.1 on 86U, unfortunately it seems to be "non-resposive" again, only the "slu" counter grows.

uts    0d 16:09    process uptime
log    1    critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc    3    number of active service threads
kmx    74    maximum number of service threads
kvg    1.54    average number of requests per service thread
krq    95    max number of requests by one service thread
req    6802    total # of requests (HTTP, HTTPS, success, failure etc)
avg    748 bytes    average size of requests
rmx    5443 bytes    largest size of request(s)
tav    35 ms    average processing time (per request)
tmx    3952 ms    longest processing time (per request)
slh    878    # of accepted HTTPS requests
slm    87    # of rejected HTTPS requests (missing certificate)
sle    0    # of rejected HTTPS requests (certificate available but bad)
slc    1781    # of dropped HTTPS requests (client disconnect without sending any request)
slu    3383    # of dropped HTTPS requests (other TLS handshake errors)
sct    100    cert cache: # of certs in cache
sch    2016    cert cache: # of reuses of cached certs

 

[kvic]

No crash so far with 2.1.0-rc.1 on 86U, unfortunately it seems to be "non-resposive" again, only the "slu" counter grows.

Try to access "https://<your ip>/servstats" If you see req and slh increment by one on every of your access, then pixelserv-tls is responsive.

slu discussed in this thread is a separate issue. Maybe applicable to your case or maybe not. Pls don't get too hung on slu or an explanation to all other observations..

edit:

Also worth noting that to isolate any suspicion of slu issue. Make sure your test client with CA cert imported. Then restart pixelserv-tls. Access from the client a test page e.g. cnn.com. Check the slu number. Restart pixelserv to clear out the counters for every test.

Then report here your client/OS, tested page and req, slh and slu. This will help me to do a preliminary assessment of the underlying cause.

 

[kvic]

Use your Pixelserv CA cert for WebGUI

I'm far falling behind on asuswrt and/or merlin variants. I've heard that AC88/AC5300 and its variants include support for Let's Encrypt in FW. In case, your models do not include this feature, as a pixelserv-tls user, you have a similar feature for free, and debatably in a more elegant way.

You could make use of Pixelserv CA cert that is generated by yourself with this instruction (or in AB-Solution upon installation of pixelserv-tls). We could use this CA cert to issue a certificate for WebGUI access. Simply SSH into your router, and run the following one-liner script (and a running pixelserv-tls):

sh -c "$(wget -qO - https://kazoo.ga/pixelserv-tls/config-webgui.sh)"

The script will guide you through the process. Use your Pixelserv CA to issue a certificate to a domain for WebGUI access. You have a choice of using your DDNS domain or router.asus.com.

Sample output of a successful run: https://pastebin.com/AyF9Q7Km

The benefit: no more invalid certs or adding exceptions to invalid certs in every browser after every FW upgrade. Simply re-run the above one-liner.

All clients with your Pixelserv CA imported will recognise the WebGUI connection as valid HTTPS. Better yet your Pixelserv CA is good for a very long time - import once good for ten years!

(This script was developed out of discussion in this thread: https://www.snbforums.com/threads/firefox-https-connection.44787/page-2#post-389381)

edit:
adding a screenshot


edit 2:

Latest content of this post is available on GitHub's wiki: [ASUSWRT] Use Pixelserv CA to issue a certificate for WebGUI

 

[Raphie]

i get below?

your Pixelserv CA to issue a new certificate to ASUSWRT WebGUI.

As a pixelserv-tls user, you already have generated your own
root CA certificate during installation and have your Pixelserv CA certificate
imported on client devices and browsers.

Hence, using your Pixelserv CA to issue a new certificate for WebGUI saves you
hassle to import a newly self-signed certificate upon every firmware upgrade.

Simply re-run this script to issue and config WebGUI after every firmware
upgrade. No more invalid certs and imports.

*****

Before you proceed, pls have pixelserv-tls installed and running. You shall also                                       
have your Pixelserv CA cert imported on a test client.

*****

Get to know more about pixelserv-tls, please go to https://kazoo.ga/pixelserv-tl                                       s/


  1. Issue and configure a certificate for ASUSWRT WebGUI

Type 1 to proceed or anything else to quit: 1

[: : unknown operand

Use your Pixelserv CA to issue a certificate to domain:

[: : unknown operand
  b. router.asus.com

[: : unknown operand

You should have your Pixelserv CA imported in a test client.
Or else your client will not treat the newly issued cert as valid.

Type [: : unknown operand
b to proceed or anything else to quit: b

Failed to issue a cert to router.asus.com.
You may re-run this script to try again or contact me for assistance.
Admin@RT-AC5300-7380:/tmp/home/root#

 

[kvic]

i get below?

your Pixelserv CA to issue a new certificate to ASUSWRT WebGUI.

As a pixelserv-tls user, you already have generated your own
root CA certificate during installation and have your Pixelserv CA certificate
imported on client devices and browsers.

Hence, using your Pixelserv CA to issue a new certificate for WebGUI saves you
hassle to import a newly self-signed certificate upon every firmware upgrade.

Simply re-run this script to issue and config WebGUI after every firmware
upgrade. No more invalid certs and imports.

*****

Before you proceed, pls have pixelserv-tls installed and running. You shall also                                      
have your Pixelserv CA cert imported on a test client.

*****

Get to know more about pixelserv-tls, please go to https://kazoo.ga/pixelserv-tl                                       s/


  1. Issue and configure a certificate for ASUSWRT WebGUI

Type 1 to proceed or anything else to quit: 1

[: : unknown operand

Use your Pixelserv CA to issue a certificate to domain:

[: : unknown operand
  b. router.asus.com

[: : unknown operand

You should have your Pixelserv CA imported in a test client.
Or else your client will not treat the newly issued cert as valid.

Type [: : unknown operand
b to proceed or anything else to quit: b

Failed to issue a cert to router.asus.com.
You may re-run this script to try again or contact me for assistance.
Admin@RT-AC5300-7380:/tmp/home/root#

Fixed. please try again..

 

[Raphie]

generation now worked.
however just typing router.asus.com just takes you to the http version, you need to add the portnbr (in my case the default 8443) for the https version, if you do that, you get below

 

[kvic]

generation now worked.
however just typing router.asus.com just takes you to the http version, you need to add the portnbr (in my case the default 8443) for the https version, if you do that, you get below

View attachment 12351

A couple of different things here...I won't digress into. The simplest way out for you is to clear your browser history. Then it'll remember you used router.asus.com (and the port) for HTTPS access to the WebGUI.

Nice screenshot btw.

 

[esco]

Chrome 65.0.3325.162, 64bit, Windows 10

edition.cnn.com:

slh 16 # of accepted HTTPS requests
slm 0 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slc 0 # of dropped HTTPS requests (client disconnect without sending any request)
slu 0 # of dropped HTTPS requests (other TLS handshake errors)

dailymail.co.uk

slh 2 # of accepted HTTPS requests
slm 0 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slc 0 # of dropped HTTPS requests (client disconnect without sending any request)
slu 0 # of dropped HTTPS requests (other TLS handshake errors)

boston.com

slh 14 # of accepted HTTPS requests
slm 0 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slc 0 # of dropped HTTPS requests (client disconnect without sending any request)
slu 0 # of dropped HTTPS requests (other TLS handshake errors)

Absolutely perfect.

Edit: typo

 

[Raphie]

after one hour

pixelserv-tls 2.1.0-rc.1 (compiled: Mar 17 2018 21:02:50) options: 192.168.1.2
4203 uts, 1 log, 7 kcc, 40 kmx, 2.52 kvg, 938 krq, 2477 req, 1872 avg, 86936 rmx, 31 tav, 3779 tmx, 1648 slh, 12 slm, 0 sle, 701 slc, 42 slu, 83 sct, 1045 sch, 8 scm, 0 scp, 719 sst, 169 ssh, 0 ssm, 0 ssp, 166 nfe, 0 gif, 0 ico, 175 txt, 0 jpg, 0 png, 0 swf, 9 sta, 1 stt, 3 ufe, 3 opt, 1193 pst, 0 hed, 57 rdr, 0 nou, 0 pth, 0 204, 6 bad, 6 tmo, 701 cls, 104 cly, 0 clt, 0 err

 

[kvic]

after one hour

pixelserv-tls 2.1.0-rc.1 (compiled: Mar 17 2018 21:02:50) options: 192.168.1.2
4203 uts, 1 log, 7 kcc, 40 kmx, 2.52 kvg, 938 krq, 2477 req, 1872 avg, 86936 rmx, 31 tav, 3779 tmx, 1648 slh, 12 slm, 0 sle, 701 slc, 42 slu, 83 sct, 1045 sch, 8 scm, 0 scp, 719 sst, 169 ssh, 0 ssm, 0 ssp, 166 nfe, 0 gif, 0 ico, 175 txt, 0 jpg, 0 png, 0 swf, 9 sta, 1 stt, 3 ufe, 3 opt, 1193 pst, 0 hed, 57 rdr, 0 nou, 0 pth, 0 204, 6 bad, 6 tmo, 701 cls, 104 cly, 0 clt, 0 err

719 sst

A lot! The highest I've seen so far. RAM usage okay?

Happy pixelserv'ing

 

[Raphie]

ram and cpu seem ok:

 

[quant88]

Slu ratio still looking high after 22 hours
https://prnt.sc/issyui

 

[eclp]

Thank you for your great work!

Also no problems with Opera (51.0.2830.55; x64)