pixelserv pixelserv - A Better One-pixel Webserver for Adblock

[Xentrk]

If I recall correctly, I had to restart Firefox after importing the certificate before the padlock was shown. I don't know how other browsers handle this though.

I was missing the step of first importing ca.cert into the browser using the instructions on the wiki before running the install script below.

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

All working now.

 

[joe scian]

Use below to figure out what processes occupy port 443.
And kindly ask the author not to bind to all interfaces. That's not good practice...

$ opkg install lsof
$ /opt/bin/lsof -nPT|grep :443

Hi Kvic - this is what I get after command
lighttpd 515 joescian 6u IPv4 2088 0t0 TCP *:443

OK thanks - I had ASUS AICloud enabled for Samba on port 443. I originally had it on port 9443 so it defaulted back to port 443 when i installed alpha 2 firmware. Anyway i disabled AICloud completely since I can use OVPN and all good now. Pixelserv now listening on Ports 80 and 443 as per normal. Thanks Kvic - very much appreciated.

I also have my OVPN Server Port set back to 443 and it happily shares it with Pixelserv.

 

[kvic]

All working now.

Good to hear..

Hi Kvic - this is what I get after command
lighttpd 515 joescian 6u IPv4 2088 0t0 TCP *:443

OK thanks - I had ASUS AICloud enabled for Samba on port 443. I originally had it on port 9443 so it defaulted back to port 443 when i installed alpha 2 firmware. Anyway i disabled AICloud completely since I can use OVPN and all good now. Pixelserv now listening on Ports 80 and 443 as per normal. Thanks Kvic - very much appreciated.

I also have my OVPN Server Port set back to 443 and it happily shares it with Pixelserv.

Seems like OpenVPN and AiCloud (also used to include WebGUI) are common sources..

 

[truglodite]

Quick question, is open ssl library version 1.0.2o-1 OK to use with pixelserv-tls_beta, or is there a benefit to downgrading to 1.0.2n-1c ? How about the opposite of benefits... is downgrading less secure?

 

[kvic]

Quick question, is open ssl library version 1.0.2o-1 OK to use with pixelserv-tls_beta,

OK to use. At the expense of using up to 6 times more RAM.

or is there a benefit to downgrading to 1.0.2n-1c ? How about the opposite of benefits... is downgrading less secure?

The "test" version of 1.0.2n-1c from Entware respository uses 6 times less RAM.
I'm still using 1.0.2n-1c.

Check back previous discussion if you want to read my assessment why it's okay to continue using 1.0.2n-1c security wise.

 

[jrmwvu04]

Smooth sailing on 2.2 so far.

 

[kvic]

2.2.0-rc.1 is available

Relatively minor update for router users. Major update for PC/SBC users with the new TLSv1.3 support.

For details, pls see https://kazoo.ga/pixelserv-tls/

 

[Raphie]

ThnX, installed let’s see how it goes!

 

[truglodite]

I noticed since yesterday an increase in tav, and a noticeable slow down in chrome with 2.1.3test4. I suppose it is from recent updates to chrome. Reading the kazoo.ga site it looks like it may be an issue with tls1.3 not being supported by Entware due to a crusty openssl lib.

I'm guessing upgrading to ps 2.2 won't fix that, correct? Is there a way to gently encourage Entware adoption of openssl 1.1, to maybe get better speed from router pixelserv sooner than later?

I wish I knew enough coding to actually help that along, but for now begging is the most I can offer... or maybe I can figure out how to do rpi with pixelserv tls, but I have no time to do that soon.

 

[kvic]

I noticed since yesterday an increase in tav, and a noticeable slow down in chrome with 2.1.3test4. I suppose it is from recent updates to chrome. Reading the kazoo.ga site it looks like it may be an issue with tls1.3 not being supported by Entware due to a crusty openssl lib.

As mentioned on my blog, I believe this is a regression in Google Chrome where they're trying to support TLS 1.3 but end up breaking TLS 1.2 a bit. They'll fix it soon in a near future release. Then you'll get your performance back. This is not related to pixelserv-tls nor Entware. If you can't wait, switch to Firefox as a temporary workaround.

I'm guessing upgrading to ps 2.2 won't fix that, correct? Is there a way to gently encourage Entware adoption of openssl 1.1, to maybe get better speed from router pixelserv sooner than later?

Entware is outside my control. My influence perhaps is next to my gravity on Earth. See the libopenssl optimization bit - easy enough to integrate but still outstanding.

I wish I knew enough coding to actually help that along, but for now begging is the most I can offer... or maybe I can figure out how to do rpi with pixelserv tls, but I have no time to do that soon.

Personally I'm against any advocacy/influence/explicit restrictions/implied limitations on my freedom of choices. Hence, my latest recommendation would be inclined to a low-power PC or single-board computer if you want to stay on the forefront of Linux and pixelserv-tls.

Installing pixelserv-tls from source on Rasp Pi is easy and automatic. No requirement to understand the code. Recently, I also filled in the 2nd half of the puzzle. I've seen more people trying. That's a good sign. So a ELI5 guide might not be far away.

Given that said TLS 1.3 is big and the world has anxiously been waiting for years, the rate of adoption shall be pretty fast.

 

[regae]

where can i get source code of 2.2.0-rc.1 ?
tried to compile from github, it says 2.1.2
or is it not public yet?

thank you

 

[kvic]

where can i get source code of 2.2.0-rc.1 ?
tried to compile from github, it says 2.1.2
or is it not public yet?

thank you

I changed my workflow after 2.1.2. Tentative plan is to push changes to GitHub when a release is done. Small releases will be one lump sum commit. Larger releases will try to break down into logical units of commits.

I'm also pondering if I should migrate the repo to GitLab. Still can't make up my mind. If I decide to do, I would think 2.2 release will make some noise that catch developers attention.

Lastly, I'm exactly expecting someone like you popping up to say hello to me. Looks like a handsome young man, huh? If you're interested in enabling TLS 1.3, a good resource would be OpenSSL's app directory under its tarball. Also OpenSSL promises TLS 1.3 automagically just works. They mostly live up to their promise.

 

[RMerlin]

I'm also pondering if I should migrate the repo to GitLab. Still can't make up my mind. If I decide to do, I would think 2.2 release will make some noise that catch developers attention.

Self-hosting + gogs is another option: https://gogs.io/ As long you don't need a highly social git (with public issue tracker and the likes).

 

[kvic]

Self-hosting + gogs is another option: https://gogs.io/ As long you don't need a highly social git (with public issue tracker and the likes).

I'm quite comfortable with git the CLI for local repo's. If Gogs can work on existing repo's (can it?), even just for browsing the codes, it'll be hugely useful sometimes. For pixelserv-tls, it needs to stay sociable. At the moment, choices seem limited to GitHub or GitLab.

 

[kvic]

OpenSSL 1.1.1 is released.

After 9 pre-releases, 1.1.1 was released today...Interestingly they don't call it 2.0 or 1.2 even though the change is non-trivial and the significance of TLS 1.3 is huge and perhaps revolutionary. The main reason is to indicate it's compatible with 1.1.0 at both API and binary levels. 1.1.1 also immediately becomes the new long-term supported version, dethroning 1.0.2 which will stop being supported by the end of 2019. So expect all apps busy testing in the coming year. If all goes well, most ppl shall be on 1.1.1 in a year's time. Here is the announcement.

For pixelserv-tls users, v2.2.0 will be released as soon as after I can get the official version of OpenSSL from Arch Linux to test.

 

[RMerlin]

If all goes well, most ppl shall be on 1.1.1 in a year's time.

I wouldn't hold my breath with router manufacturers. Some were still on 0.9.8 last time I checked...

 

[RMerlin]

If Gogs can work on existing repo's (can it?), even just for browsing the codes, it'll be hugely useful sometimes.

Might be worth checking. I know the venerable gitweb does - I have a VPS doing nightly git pulls from Github (for backup purposes, in case something happened to Github), and got gitweb sitting right on top of it.

 

[penguin22]

@kvic and @RMerlin, I have an interesting challenge that I'm hoping one of you may be able to shed light on. With my network setup as follows:

AC86U Router <--> AC68P MB <--> AC3200 AP

I experience well reported DHCP issues where clients are frequently and intermittently unable to obtain an IP address, seemingly stemming from the issues with the router operating in MB mode. When clients are connected; however, they show up individually in the client list on the router and the pixelserv stats page shows more slh than slu.

With the continued DHCP issues through 384.5, 384.6, and 384.7 Alpha, I finally had to revert the MB back to my old EA-N66R setup as follows:​

AC86U Router <--> EA-N66R MB <--> AC3200 AP

After a day of use, the DHCP issues do not occur with the actual MB in the middle and I have had no client connectivity issues. The unique challenge and reason for me soliciting your input is that, in this configuration, clients show on the router network map page as "## clients are connecting to RT-AC86U through this device." I haven't seen any specific limitations yet and custom DHCP assignment appears to still be working along with policy routes defined in the OpenVPN settings. What I have seen impacted with this configuration is pixelserv. Ad blocking with Diversion and pixelserv still appear to work on connected clients, but the servstats doesn't appear to accurately capture that fact:

pixelserv-tls 2.2.0-rc.1 (compiled: Sep 9 2018 02:47:54 flags: tfo) options: 192.168.50.2 -c 100

uts    0d 23:05    process uptime
log    1    critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc    2    number of active service threads
kmx    22    maximum number of service threads
kvg    1.16    average number of requests per service thread
krq    39    max number of requests by one service thread
req    471571    total # of requests (HTTP, HTTPS, success, failure etc)
avg    1536 bytes    average size of requests
rmx    39906 bytes    largest size of request(s)
tav    33 ms    average processing time (per request)
tmx    5434 ms    longest processing time (per request)
slh    1887    # of accepted HTTPS requests
slm    65    # of rejected HTTPS requests (missing certificate)
sle    0    # of rejected HTTPS requests (certificate available but bad)
slc    1603    # of dropped HTTPS requests (client disconnect without sending any request)
slu    467008    # of dropped HTTPS requests (other TLS handshake errors)
uca    543    slu break-down: # of unknown CA reported by clients
uce    464743    slu break-down: # of unknown cert reported by clients
ush    1339    slu break-down: # of shutdown by clients after ServerHello

 

[kvic]

I have an interesting challenge that I'm hoping one of you may be able to shed light on.

I'm having enough challenge from TLS 1.3 at the moment. But thanks for the offer and sharing your problem.

MB=media bridge? I never used media bridge mode in ASUSWRT. Not sure what's under the hood and difference from repeater mode. Regardless, I would think you should capture some frames/packets to see what's going on and open up the problem. pixelserv-tls might show you some phenomenon but it's really not the tool for tackling this sort of problem. Perhaps you should try tcpdump from Entware instead..

 

[truglodite]

A quick noob question...

My pixelserv generated certs have my pixelserv ip as the CN, and just the blocked website wildcard as the SAN (ie *.googleanalytics.com). I get a green padlock visiting https://pixelservip/servstats. The generated certs also seem to (partially) work based on stats numbers, but not always. 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).

When I created self signed certs for merlin webui, I had to use the ip as the CN, and put both router.asus.com and the IP in the san. Without the IP in the san, red padlock. Could the unknown cert errors come from the fact that the pixelserv generated certs are missing the IP in the san? If so, could that be added to ps on a future release?