pixelserv pixelserv - A Better One-pixel Webserver for Adblock

[Protik]

I've updated downgrade instructions in #1669. Remove & install in one-go..no need for separate typing.

For downgrade, going forward we can either refer to #1669 or #2053.

Perhaps we shall clean up the latest posts a bit on the downgrade process. It's quite confusing

Sure it is. Coming back after 2 months, it took me a while to find out the commands. By any chance, can you please refer to the post with instruction in the first post? That will make it much simpler.

 

[kvic]

Sure it is. Coming back after 2 months, it took me a while to find out the commands. By any chance, can you please refer to the post with instruction in the first post? That will make it much simpler.

Okay, done

I never thought I would update the first post. Perhaps today is the moment. lol

 

[kvic]

non pixelserv-tls issue but nonetheless related...

I haven't tinkered my network for a very long time. Something exciting happened in the past weekend that I want to share with the audience in this thread.

Finally I migrated to Unbound as my main DNS server that regrettably I haven't done so earlier in retrospect.

Also did a quick & dirty (but effective & convincing) comparison between Cloudflare and Google DNS. In a nutshell, Cloudflare is doing much better at my point of presence.

A picture worth thousand words, and visit my latest blog post for explanation.

View attachment 13606

Increased level of shades in "smoke" graphs. Amazing way to visualise how poorly Google DNS performs when compared to Cloudflare.

Google:

Cloudflare: graph Quad9: graph

Quad9 DNS is 40ms away from my test machine. The other two 4ms. Nevertheless, even deducting 40ms from Quad9, it is sometimes faster but generally worse (huge swings) than Google.

Moral of the experiment?

Trim DNS latency in your network. Get your commonly accessed domains cached e.g. in Unbound. Combined with a DNS-based adblock with pixelserv-tls gives a very pleasant web experience.

 

[kvic]

2.1.3-test.3 is available

Changes

New slu break-down, ush that accounts a newly identified handshake failure - shutdown by clients after ServerHello sent and corresponding logging "shutdown after ServerHello" on LEVEL 2.

Shutdown by clients after ServerHello

A client initiates a handshake, receives a response from server and then shuts down the connection unilaterally. The most likely reason is a client finds out the certificate in the server's response not matching its hard-coded fingerprint. Instead of notifying the server of unknown cert or CA, the client shuts down the connection silently. It's considered suspicious activity worth more attention.

Install

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

 

[kvic]

2.1.3-test.3 is available

Changes

New slu break-down, ush that accounts a newly identified handshake failure - shutdown by clients after ServerHello sent and corresponding logging "shutdown after ServerHello" on LEVEL 2.

Shutdown by clients after ServerHello

A client initiates a handshake, receives a response from server and then shuts down the connection unilaterally. The most likely reason is a client finds out the certificate in the server's response not matching its hard-coded fingerprint. Instead of notifying the server of unknown cert or CA, the client shuts down the connection silently. It's considered suspicious activity worth more attention.

Install

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

A real world example:

I've known Apple has been secretly doing things on my back. Today pixelserv-tls captures such one example. In this example, one iOS device (192.168.1.104) is trying to send some metrics to its server (metrics.icloud.com). But realise the server cert presented is not theirs, drop the connection silently (smart ppl..?).

This handshake error happens a few times everyday. Once I'm comfortable, I put into the suppression list in my script and won't get highlighted in daily reports.

 

[Asad Ali]

@kvic Now since we have three different slu break-down categories in servstats page don't you think it's redundant to still count (uce/uca/ush) errors in "slu" as well? Isn't it better to keep the "slu" counter for all the " other TLS handshake errors" which don't fall in those three subcategories we now have.

 

[kvic]

@kvic Now since we have three different slu break-down categories in servstats page don't you think it's redundant to still count (uce/uca/ush) errors in "slu" as well? Isn't it better to keep the "slu" counter for all the " other TLS handshake errors" which don't fall in those three subcategories we now have.

From what I've seen so far, I would tend to agree with you:

uca+uce+ush=1416
The remaining 358 (i.e. 1774-1416) are "reached max retries" that I've been thinking of as an additional counter.

So seems we've identified most if not all "unknown errors". It's probably a good time to restore slu back to its original meaning.

But before that I would ask the thread: do you observe the same in your environment?

 

[joe scian]

From what I've seen so far, I would tend to agree with you:

uca+uce+ush=1416
The remaining 358 (i.e. 1774-1416) are "reached max retries" that I've been thinking of as an additional counter.

So seems we've identified most if not all "unknown errors". It's probably a good time to restore slu back to its original meaning.

But before that I would ask the thread: do you observe the same in your environment?

my output follows
slh 5648 # of accepted HTTPS requests
slm 60 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slc 331 # of dropped HTTPS requests (client disconnect without sending any request)
slu 829 # of dropped HTTPS requests (other TLS handshake errors)
uca 2 slu break-down: # of unknown CA reported by clients
uce 649 slu break-down: # of unknown cert reported by clients
ush 113 slu break-down: # of shutdown by clients after ServerHello

 

[Protik]

slh    2649    # of accepted HTTPS requests
slm    120    # of rejected HTTPS requests (missing certificate)
sle    0    # of rejected HTTPS requests (certificate available but bad)
slc    2053    # of dropped HTTPS requests (client disconnect without sending any request)
slu    3924    # of dropped HTTPS requests (other TLS handshake errors)
uca    79    slu break-down: # of unknown CA reported by clients
uce    1438    slu break-down: # of unknown cert reported by clients
ush    1605    slu break-down: # of shutdown by clients after ServerHello

 

[kvic]

@joe scian @Protik Thanks for your feedback. Appreciate it!

In other news, as some of you having followed this thread long enough could guess.. I'm always excited about new ideas or improvements in fundamental components.

I was made aware of a piece of exciting optimization in libc - one of the fundamental libraries in Entware that could speed up pixelserv-tls and other applications built for Entware. Average speed-up by 20%. Details of benchmark can be found here.

I'm porting the optimization to Entware armv7 (i.e. RT56U/68U). I can't wait to share with my pixelserv-tls supporters.

If you're interested, pls raise your hand. When it's ready, I'll let you know. It'll be a simple upgrade as part of standard Entware upgrade process.

 

[JaimeZX]

Looking forward to it!

Meanwhile, my latest stats:
Uptime: 16d 17h

req 1791485 total # of requests (HTTP, HTTPS, success, failure etc)
avg 2324 bytes average size of requests
rmx 660063 bytes largest size of request(s)
tav 13 ms average processing time (per request)
tmx 8762 ms longest processing time (per request)

slh 10526 # of accepted HTTPS requests
slm 53 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slc 9019 # of dropped HTTPS requests (client disconnect without sending any request)
slu 1758912 # of dropped HTTPS requests (other TLS handshake errors)
uca 79251 slu break-down: # of unknown CA reported by clients
uce 1672312 slu break-down: # of unknown cert reported by clients

htop shows 6x instances @ 0.4% memory each = 2.4% of 512MB.
----------------------------------

Seems like I might have some clients without the cert. LOL
Edit: is there a way to view which IP(s) dropped requests? I have too many devices around here. Would make it easier to track down the most egregious offenders.

 

[Asad Ali]

@joe scian @Protik Thanks for your feedback. Appreciate it!

In other news, as some of you having followed this thread long enough could guess.. I'm always excited about new ideas or improvements in fundamental components.

I was made aware of a piece of exciting optimization in libc - one of the fundamental libraries in Entware that could speed up pixelserv-tls and other applications built for Entware. Average speed-up by 20%. Details of benchmark can be found here.

I'm porting the optimization to Entware armv7 (i.e. RT56U/68U). I can't wait to share with my pixelserv-tls supporters.

If you're interested, pls raise your hand. When it's ready, I'll let you know. It'll be a simple upgrade as part of standard Entware upgrade process.

I'm so much interested but I'm on armv8 (86U) so any chance for that?

 

[Asad Ali]

Seems like I might have some clients without the cert. LOL
Edit: is there a way to view which IP(s) dropped requests? I have too many devices around here. Would make it easier to track down the most egregious offenders.

Change to log level 2 and you'll see all the handshake failed entities in syslog.

BTW you look like a perfect candidate for @kvic's TLS reporting script.

 

[jrmwvu04]

If you're interested, pls raise your hand.

I think I’m ready to start tinkering again.

 

[Twiglets]

@joe scian @Protik Thanks for your feedback. Appreciate it!

In other news, as some of you having followed this thread long enough could guess.. I'm always excited about new ideas or improvements in fundamental components.

I was made aware of a piece of exciting optimization in libc - one of the fundamental libraries in Entware that could speed up pixelserv-tls and other applications built for Entware. Average speed-up by 20%. Details of benchmark can be found here.

I'm porting the optimization to Entware armv7 (i.e. RT56U/68U). I can't wait to share with my pixelserv-tls supporters.

If you're interested, pls raise your hand. When it's ready, I'll let you know. It'll be a simple upgrade as part of standard Entware upgrade process.

As I have a RT56U ..... yes please !!!
Every little helps

 

[Protik]

@joe scian @Protik Thanks for your feedback. Appreciate it!

In other news, as some of you having followed this thread long enough could guess.. I'm always excited about new ideas or improvements in fundamental components.

I was made aware of a piece of exciting optimization in libc - one of the fundamental libraries in Entware that could speed up pixelserv-tls and other applications built for Entware. Average speed-up by 20%. Details of benchmark can be found here.

I'm porting the optimization to Entware armv7 (i.e. RT56U/68U). I can't wait to share with my pixelserv-tls supporters.

If you're interested, pls raise your hand. When it's ready, I'll let you know. It'll be a simple upgrade as part of standard Entware upgrade process.

Count me in!

 

[joe scian]

Count me in!

me too!

 

[kvic]

Edit: is there a way to view which IP(s) dropped requests? I have too many devices around here. Would make it easier to track down the most egregious offenders.

Seems like the TLS report script in #2067 fits your need! The script is under tests. It requires you edit a few lines to complete config. Good news is help should be available from a few ppl. We could add you the the testing group.

 

[kvic]

I'm so much interested but I'm on armv8 (86U) so any chance for that?

86U as always has newer stuff. If Openwrt/Entware doesn't change the default, I believe the feature is already available! I can check later to see if that's the case.

 

[kvic]

Thanks for all your interest! I kind of get it working on my 56U. Really have to observe longer if it's stable. If it's unstable, it could cause lots of crashes.

BTW, the libc library will be usable on 56U/68U/87U/3100/88U/etc. All Asus routers that share the ARMv7-softfloat with kernel v2.6.x Entware environment. Basically all these devices share the same Entware build/repository.

I'll invite all ppl expressed interest with replies/likes. Let's expect something to test before next weekend.

I took the chance to re-think some of the optimizations done in v2.1. Perhaps we can relax a bit (as the main memory hog is proven to be the ssl library). So expect more little changes coming in next pixelserv-tls beta. Will have better performance under medium to heavy workload.