pixelserv pixelserv - A Better One-pixel Webserver for Adblock

[penguin22]

MB=media bridge?

Yes, MB refers to Media Bridge mode. For reference, I have used both an AC-66R, AC-68P running both ASUS stock and Merlin firmware with the DHCP issues. For whatever reason the dedicated EA-N66R doesn't have the issue at all, but is a security risk, not supporting HTTPS for the management page and susceptible to any vulnerability since the last firmware came out in 2016.

 

[kvic]

My pixelserv generated certs have my pixelserv ip as the CN, and just the blocked website wildcard as the SAN (ie *.googleanalytics.com).

1st case normal. 2nd case normal.

Not only your pixelserv certs. Everyone's pixelserv certs are generated according to well predefined rules.

No issue in there.

The generated certs also seem to (partially) work based on stats numbers, but not always.

I don't think your observation and conclusion are causal and correct. If you believe there is an issue, I need details and you may only give me one counter example.

When I visit ad rich sites the log shows certs being generated and slh increases. However sometimes I get spikes in uce (client reports unknown cert). Investigating the logs shows this happens to clients with the trusted root cert (win10+chrome, ios+safari, and android+chrome clients).

They aren't related to the auto-generated certs. It's your client devices. Quite a lots of discussion a few months back. In a nutshell, you'd better off digging into one or two examples than trying to generalise..

Could the unknown cert errors come from the fact that the pixelserv generated certs are missing the IP in the san?

Nope.

For whatever reason the dedicated EA-N66R doesn't have the issue at all

To be honest, whatever reason it's..it won't be due to pixelserv-tls

 

[penguin22]

To be honest, whatever reason it's..it won't be due to pixelserv-tls

Yeah, I know it isn't related to pixelserv-tls, however thought you might find it interesting that slu increases though functionality appears intact. I think it has to do with the dedicated MB showing all clients as one to the router. It's as if the clients still get the block or perhaps just no data for the place that the 1x1 pixel would be served.

 

[kvic]

thought you might find it interesting that slu increases though functionality appears intact.

I still see very few users can interpret the numbers with their first hand observations. It should be interesting when you observe the stats and check out what's going on your network. When the numbers are simply passed to me without a narrative, the charisma of the stats reduces by a few orders.

Recently though I have some interesting findings on slu. For those with good memory will recall months ago I mentioned in this thread some huge slu counts that I couldn't explain. They look like TLS 1.2 but with ciphers not supported by TLS 1.2 and hence ended up in slu.

Now it's crystal clear to me these are TLS 1.3 traffics! So firms like Instagram (remember graph.instagram.com that I sent to another sink hole?) & co have migrated to draft version of TLS 1.3 very early on..maybe since 2nd half of last year.

Good news is that with pixelserv-tls v2.2 + OpenSSL 1.1.1, a good chunk of slu should end up as slh. Will see how much in practice when it's available. So I encourage hardcore users to prepare a low-power PC or a SBC that can run some of the full Linux distrubiton preferably based on a rolling release model.

I think it has to do with the dedicated MB showing all clients as one to the router. It's as if the clients still get the block or perhaps just no data for the place that the 1x1 pixel would be served.

You've to educate me how MB works...

 

[penguin22]

I still see very few users can interpret the numbers with their first hand observations. It should be interesting when you observe the stats and check out what's going on your network. When the numbers are simply passed to me without a narrative, the charisma of the stats reduces by a few orders.

Recently though I have some interesting findings on slu. For those with good memory will recall months ago I mentioned in this thread some huge slu counts that I couldn't explain. They look like TLS 1.2 but with ciphers not supported by TLS 1.2 and hence ended up in slu.

Now it's crystal clear to me these are TLS 1.3 traffics! So firms like Instagram (remember graph.instagram.com that I sent to another sink hole?) & co have migrated to draft version of TLS 1.3 very early on..maybe since 2nd half of last year.

Good news is that with pixelserv-tls v2.2 + OpenSSL 1.1.1, a good chunk of slu should end up as slh. Will see how much in practice when it's available. So I encourage hardcore users to prepare a low-power PC or a SBC that can run some of the full Linux distrubiton preferably based on a rolling release model.



You've to educate me how MB works...

I just bit the bullet and purchased the RP-AC68U to see if it works without the DHCP issue and possibly restoring the functionality with pixelserv-tls that I had running the RT-AC68P in MB mode. If it doesn't work, at least I'll know and be able to add input here on functionality with more complicated network setup.

 

[dugaduga]

Just updated entware, and pixelserv tls to 2.1.2

Sep 14 05:08:57 pixelserv-tls[32340]: pixelserv-tls 2.1.2 (compiled: Sep 8 2018 20:33:38) options: <none>
Sep 14 05:08:57 pixelserv-tls[32340]: Abort: Address already in use - :*:443
if i change 443 to 442 I get this:

Sep 14 05:08:57 pixelserv-tls[32340]: Abort: Address already in use - :*:80

httpd 30727 asus 10u IPv4 491040 0t0 TCP 127.0.0.1:80
httpds 30726 asus 10u IPv4 491112 0t0 TCP 192.168.50.1:443

So the router GUI & something on 80 is interfering with it. never had this problem before.

Also getting tonnes of ERR_SSL_VERSION_INTERFERENCE in my browsers, connecting to TLS 1.2 pages including to the router itself.

 

[kvic]

Just updated entware, and pixelserv tls to 2.1.2

Sep 14 05:08:57 pixelserv-tls[32340]: pixelserv-tls 2.1.2 (compiled: Sep 8 2018 20:33:38) options: <none>
Sep 14 05:08:57 pixelserv-tls[32340]: Abort: Address already in use - :*:443
if i change 443 to 442 I get this:

Sep 14 05:08:57 pixelserv-tls[32340]: Abort: Address already in use - :*:80

httpd 30727 asus 10u IPv4 491040 0t0 TCP 127.0.0.1:80
httpds 30726 asus 10u IPv4 491112 0t0 TCP 192.168.50.1:443

I believe you're a Diversion user. Unfortunately Entware and Diversion hate each other and fight along. Both sides could do better and naturally Diversion should take an extra step..

Joking aside. I think you shall drop by Diversion's thread for best course of action.

 

[kvic]

openssl 1.0.2p

Judging from openssl changelog, everyone probably should move forward with the upgrade to version P in Entware.

Only for people know what you're doing, feel free to stay on the "test" version n-1c. Or compile your own version P with the flag that ditches openssl clutter.

Pls don't ask for alternative library from me.

Entware also answered your call. Officially refused to integrate the optimization flag. My comment: a technical coward but a good & bossy conservative in management. Nevertheless, if you're a Entware user, you should respect their decision.

Also to be forefront on pixelserv-tls, we need OpenSSL 1.1.1 very soon. As suggested before if you want to stay coolest, get a low-power PC or SBC...

 

[SMS786]

openssl 1.0.2p

Judging from openssl changelog, everyone probably should move forward with the upgrade to version P in Entware.

Thanks @kvic. If the process is relatively simple, could you provide instructions for the upgrade or point us in the right direction?

 

[kvic]

Thanks @kvic. If the process is relatively simple, could you provide instructions for the upgrade or point us in the right direction?

If you're a Diversion user, I believe there is a sub-menu there that does the pixelserv-tls upgrade (that additionally will upgrade the openssl library to version P as well).

If people want to manually upgrade any package (its dependent packages are automatically upgraded), issue

opkg upgrade <package_name>

e.g. pixelserv-tls will be

opkg upgrade pixelserv-tls

that will upgrade both pixelserv-tls and openssl library (if upgrade available).

Entware users generally perform upgrade by

opkg upgrade

the above command will upgrade all packages with update available.

CAUTION

If you're only using Entware installed by Diversion, you probably don't want to do manual upgrade. Do it from within Diversion instead.

Unless you know what you're doing. Then you're also on your own.

 

[SMS786]

If you're a Diversion user, I believe there is a sub-menu there that does the pixelserv-tls upgrade (that additionally will upgrade the openssl library to version P as well).

If people want to manually upgrade any package (its dependent packages are automatically upgraded), issue

opkg upgrade <package_name>

e.g. pixelserv-tls will be

opkg upgrade pixelserv-tls

that will upgrade both pixelserv-tls and openssl library (if upgrade available).

Entware users generally perform upgrade by

opkg upgrade

the above command will upgrade all packages with update available.

CAUTION

If you're only using Entware installed by Diversion, you probably don't want to do manual upgrade. Do it from within Diversion instead.

Unless you know what you're doing. Then you're also on your own.

Got it. I'm already on pixelserv-tls 2.2.0-rc.1, should I force upgrade again to make sure I'm on openssl 1.0.2p?

 

[kvic]

Got it. I'm already on pixelserv-tls 2.2.0-rc.1, should I force upgrade again on make sure I'm on openssl 1.0.2p?

You can inspect installed packages and version number with

opkg list-installed

or

opkg list-installed | grep openssl

For only upgrading openssl library from Entware for pixelserv-tls BETA users, issue

opkg upgrade libopenssl
opkg upgrade openssl-util

 

[SMS786]

You can inspect installed packages and version number with

opkg list-installed

or

opkg list-installed | grep openssl

For only upgrading openssl library from Entware for pixelserv-tls BETA users, issue

opkg upgrade libopenssl
opkg upgrade openssl-util

Thanks. I just upgraded all my Entware packages through amtm and it all went without a hitch!

libopenssl - 1.0.2p-1

 

[thelonelycoder]

I believe you're a Diversion user. Unfortunately Entware and Diversion hate each other and fight along. Both sides could do better and naturally Diversion should take an extra step..

I believe Diversion and Entware get along just fine

 

[Makaveli]

Thanks. I just upgraded all my Entware packages through amtm and it all went without a hitch!

libopenssl - 1.0.2p-1

I also just upgraded to libopenssl - 1.0.2p-1 via amtm thanks.

 

[quant88]

I had similar issues after updating entware packages via Diversion. Was on pixelserv-tls beta. Reinstalling Diversion works for me. Also noticed there were some changes in S80 pixelserv-tls.

Just updated entware, and pixelserv tls to 2.1.2

Sep 14 05:08:57 pixelserv-tls[32340]: pixelserv-tls 2.1.2 (compiled: Sep 8 2018 20:33:38) options: <none>
Sep 14 05:08:57 pixelserv-tls[32340]: Abort: Address already in use - :*:443
if i change 443 to 442 I get this:

Sep 14 05:08:57 pixelserv-tls[32340]: Abort: Address already in use - :*:80

httpd 30727 asus 10u IPv4 491040 0t0 TCP 127.0.0.1:80
httpds 30726 asus 10u IPv4 491112 0t0 TCP 192.168.50.1:443

So the router GUI & something on 80 is interfering with it. never had this problem before.

Also getting tonnes of ERR_SSL_VERSION_INTERFERENCE in my browsers, connecting to TLS 1.2 pages including to the router itself.

 

[truglodite]

Kvic, you were right earlier I was assuming too much and no supporting data. I narrowed down a specific situation that I am curious to understand. I have a client with the trusted root cert, and after a while I see in the pixelserv log a cert generated for "_google-adservices.com". I test this cert and it works fine (green padlock in chrome when I visit https://google-adservices.com). Good... but then later the router logs show pixelserv errors from the client due to "unknown ca" for "ssl.google-adservices.com". The error repeats itself often, and the stats page reflects with high uce.

This is actually happening with several clients and with an assortment of pages. For my given example, I am guessing pixelserv is either unsuccessfully using the _google-adservices.com cert, or for some reason it is unsuccessfully generating an _ssl.google-adservices.com cert. But really I don't know... any knowledge is appreciated.

Btw, I do have a crusty old pentium4 box collecting dust. It already has linux... would that be adequate for a pixelserv-tls openssl1.1.1 rig? Can I still use diversion on my router and somehow forward the hits to the pixelserv box IP?...or something like that, lol? I'm a newb so if you have some links to read on this subject I would be very grateful.

Thanks,
Kev

 

[kvic]

but then later the router logs show pixelserv errors from the client due to "unknown ca" for "ssl.google-adservices.com". The error repeats itself often, and the stats page reflects with high uce.

All those websites basically feed on Google ads revenue. The site is of less interest here. The culprit lies on the client side. If it's an android system, basically it's only one client i.e. Google's system component in Android (which is different from Google Chrome the browser slightly).

What I suspect Google is doing in their system component is checking the cert signature against some predefined/known/hardcoded data, if it finds mismatch, it stops handshakes and send no data. This on the bright side is to protect end-users privacy. On the dark side, it prevents end-users or curious "security researchers" from seeing what actually being sent to Google servers.

UCA is one type of such tactics that simply refuses to recognise user installed Root CA. UCE is another type of such tactics that refuses to recognise individual server certs.

Btw, I do have a crusty old pentium4 box collecting dust. It already has linux... would that be adequate for a pixelserv-tls openssl1.1.1 rig?

lol. My hunch is that Pentium4 will be more powerful than enough at the expense of wasted power consumption. Lately I found my little SBC can crunch crypto data multiple times faster than Intel Sandy Bridge...

 

[kvic]

With stormy weather, I'm having some fun with TLS 1.3 in pixelserv-tls. For a very long time, I've abandoned Firefox until recently. Looks like Firefox has a very strong comeback in recent years. One notch ahead of Google on TLS 1.3 support.

Firefox v63 beta6 + pixelserv-tls beta

Chrome v70 dev version + pixelserv-tls beta

https://i.imgur.com/4CXapuI.png

Screenshots can't tell but show both are equally good.

 

[kvic]

2.2.0-rc.2 is available

We have support for a new and exciting feature in TLS 1.3. The impact to existing flow isn't small. Hence, would appreciate everyone's test on any regression bug.

For details, pls be sure to read release notes at https://kazoo.ga/pixelserv-tls/

Understandably now only I could test TLS 1.3, I'm actively thinking how I could enable more users to try TLS 1.3 earlier and without imposing a support burden on myself.