pixelserv pixelserv - A Better One-pixel Webserver for Adblock

[Asad Ali]

What are you talking about? Just use the client browser and go
YourPixelservIP/ca.crt . Eg 192.168.1.3/ca.crt
Add it as your trusted CA. As simple as ABC.

Did you even try importing the certificate WITHOUT setting any type of lock screen protection on the phone? ( i.e just with swipe enabled )

 

[Butterfly Bones]

That does not change the directory owner, not sure why. (SNB still have me blocked for code replies.)

 

[DonnyJohnny]

Did you even try importing the certificate WITHOUT setting any type of lock screen protection on the phone? ( i.e just with swipe enabled )

Oh.. I did some search and see can’t install without password..

Saw an article that maybe could work .. u can try and see . The tester is on android 4.1.2
https://android.stackexchange.com/questions/28689/install-ca-without-having-to-activate-screen-lock

“There is a way. Just install your certificate the usual way and set "Patterns" as lock screen to do so. Lock the screen. Fail on the patterns 5 times, then click on "forgot pattern" in the lower right corner, login with your Google account and voilà ... the lock screen is reset to "none" and certificates are still there.”

 

[Butterfly Bones]

If you run the above command line, it should work now...give it a try. I suspect not the files but the directory itself lost permission to 'nobody'.

edit:

@thelonelycoder Perhaps worth double check if AB-S is overriding the directory from time to time..

That does not change the directory owner, not sure why. (SNB still have me blocked for code replies.)

 

[Asad Ali]

Oh.. I did some search and see can’t install without password..

Saw an article that maybe could work .. u can try and see . The tester is on android 4.1.2
https://android.stackexchange.com/questions/28689/install-ca-without-having-to-activate-screen-lock

“There is a way. Just install your certificate the usual way and set "Patterns" as lock screen to do so. Lock the screen. Fail on the patterns 5 times, then click on "forgot pattern" in the lower right corner, login with your Google account and voilà ... the lock screen is reset to "none" and certificates are still there.”

I've done my research already and seen this post too but unfortunately that approach no longer works on versions later than 4.1.2

Edit: I just remove the pattern after installing the certificate and it seems that its still intact and the statistics of Pixelserv-tls shows that so that's one device more with the certificate installed.

 

[kvic]

@Butterfly Bones I'm going to leave the directory permission issue to yourself. 'chown' the command...man page is of great help..

On the other hand, I can break a good news to you and other RT-86U users.

From the pastebin logs, I saw you guys get the special flag TFO. It's expected but still a surprise (!!) to me (as I didn't realise ..perhaps I've forgotten to highlight the feature).

This is TCP Fast Open supported by newer kernels. So on a typical LAN, every request will be ~0.5ms faster than people without it.

Fire up Wireshark. See it in action and enjoy.

 

[Asad Ali]

On the other hand, I can break a good news to you and other RT-86U users.

From the pastebin logs, I saw you guys get the special flag TFO. It's expected but still a surprise (!!) to me (as I didn't realise ..perhaps I've forgotten to highlight the feature).

This is TCP Fast Open supported by newer kernels. So on a typical LAN, every request will be ~0.5ms faster than people without it.

Fire up Wireshark. See it in action and enjoy.

Do we have to do anything to enable it or its by default?

 

[DonnyJohnny]

I've done my research already and seen this post too but unfortunately that approach no longer works on versions later than 4.1.2

Edit: I just remove the pattern after installing the certificate and it seems that its still intact and the statistics of Pixelserv-tls shows that so that's one device more with the certificate installed.

Never try, never know.. good for you.

 

[kvic]

Do we have to do anything to enable it or its by default?

All automatic. Both client and server have to support it.

Server side is ready..you've to check your client (and its OS) for support.

 

[penguin22]

I've done my research already and seen this post too but unfortunately that approach no longer works on versions later than 4.1.2

Edit: I just remove the pattern after installing the certificate and it seems that its still intact and the statistics of Pixelserv-tls shows that so that's one device more with the certificate installed.

Where are you seeing the devices with certificate installed in the Pixelserv-tls servstats page?

 

[Asad Ali]

Where are you seeing the devices with certificate installed in the Pixelserv-tls servstats page?

I don't see the devices with pixelserv-tls installed on the statistics page but I checked the slh increments when you see the stats page with the proper certificate device.

 

[Butterfly Bones]

@Butterfly Bones I'm going to leave the directory permission issue to yourself. 'chown' the command...man page is of great help..

Looks like Asuswrt-Merlin only has limited chown commands.

# chown -Rv nobody:root /opt/var/cache/pixelserv
chown: invalid option -- 'v'
BusyBox v1.24.1 (2018-03-24 13:05:03 EDT) multi-call binary.
Usage: chown [-Rh]... OWNER[<.|:>[GROUP]] FILE...
Change the owner and/or group of each FILE to OWNER and/or GROUP
-R Recurse
-h Affect symlinks instead of symlink targets

 

[penguin22]

I don't see the devices with pixelserv-tls installed on the statistics page but I checked the slh increments when you see the stats page with the proper certificate device.

I believe slh will increment even without the CA installed to the device through the cert being generated for the site requested and client device using it for consecutive requests. This is my believe at least as I only recently started putting the CA cert on devices, but have had slh increment prior to doing so.

 

[Butterfly Bones]

@kvic Any idea on this I posted in the pastebin reply?

"Then I start getting the ssl errors from one of my Android phones (only one on now). It appears that pixelserv will not generate or use existing certs for Android, but I probably misunderstand something here. For example the _.appsflyer.com cert exist, but I keep seeing the errors.
Apr 5 08:13:41 pixelserv-tls[26258]: t.appsflyer.com _.appsflyer.com missing
Apr 5 08:13:41 pixelserv-tls[26258]: t.appsflyer.com _.appsflyer.com missing
Apr 5 08:13:42 pixelserv-tls[26258]: handshake failed: unknown cert. client 192.168.1.12:44929 server t.appsflyer.com
Apr 5 08:13:44 pixelserv-tls[26258]: handshake failed: unknown cert. client 192.168.1.12:44933 server t.appsflyer.com"

 

[Asad Ali]

I believe slh will increment even without the CA installed to the device through the cert being generated for the site requested and client device using it for consecutive requests. This is my believe at least as I only recently started putting the CA cert on devices, but have had slh increment prior to doing so.

Oh yeah you're right, my understanding of that was flawed then, I will research on it further.

 

[penguin22]

Oh yeah you're right, my understanding of that was flawed then, I will research on it further.

Actually, I was hoping that you were right as it would have been a good indicator that the CA cert published to devices/browsers is working as intended and also help identify if devices have been missed.

Having recently formatted JFFS and set things up again, which required a re-import of the CA cert (done through DDNS section of the router GUI), I wasn't sure if Pixelserv-tls would automatically use the CA cert and was a bit unsure how to check. I ended up attempting to reload by browsing to the PS/ca.cert page and it said the cert was already loaded, then loaded on a new device and confirmed it was the same. A check on the servstats page for devices with CA cert used would have simplified the process.

 

[kvic]

@kvic Any idea on this I posted in the pastebin reply?

"Then I start getting the ssl errors from one of my Android phones (only one on now). It appears that pixelserv will not generate or use existing certs for Android, but I probably misunderstand something here. For example the _.appsflyer.com cert exist, but I keep seeing the errors.
Apr 5 08:13:41 pixelserv-tls[26258]: t.appsflyer.com _.appsflyer.com missing
Apr 5 08:13:41 pixelserv-tls[26258]: t.appsflyer.com _.appsflyer.com missing
Apr 5 08:13:42 pixelserv-tls[26258]: handshake failed: unknown cert. client 192.168.1.12:44929 server t.appsflyer.com
Apr 5 08:13:44 pixelserv-tls[26258]: handshake failed: unknown cert. client 192.168.1.12:44933 server t.appsflyer.com"

Sequence of events + analysis

missing cert

Initially server "t.appsflyer.com" doesn't have a certificate in CERT_PATH i.e. /opt/var/cache/pixelserv on Entware. Hence, you get one or more "missing" lines in sort of avalanche.

This is because requests come in fast (in a few ms) but auto cert generation takes time (600ms on 1.2GHz Cortex-A9). You can use "pixelserv-tls -B" to run the benchmark and get the average generation time on RT-AC86 btw.

after cert auto generated

Once the cert generated, successive requests pass the initial check and enter TLS handshake. However, it fails because the client doesn't want to recognise the server certificate. This is a bit dubious.

We went through such debious behavior in rc.2/rc.3 cycles. And now we have the new counter "uca" and "uce" to register the stats. For the detailed usage and interpretation, I would recommend the "TLS Handshake" section on the pixelserv-tls MAN page.

In a nutshell, I suspect one app on this particular client (192.168.1.12 ) has hard coded fingerprint and refused to send content if the server certificate does not match. Why do they want to do that?...very likely they don't want other to see what's inside.

 

[kvic]

Actually, I was hoping that you were right as it would have been a good indicator that the CA cert published to devices/browsers is working as intended and also help identify if devices have been missed.

slh is only incremented if a HTTPS request is processed that imples the client passes TLS handshake and that implies CA is imported on the given client.

In 2.1.0-rc.4, we have two new counters (pls check Changes list & MAN page for details).

One of them is uca - requests from clients without CA imported will register in this counter + logging in syslog..something similar to below:

Apr  5 08:13:47 pixelserv-tls[262]: handshake failed: unknown CA. client 192.168.1.12:44961 server abc.def.com

The log will tell you the client ip without CA imported.

I recommend you to read the MAN page 'cos a client with CA imported could also possibly give such errors, and you shall be grateful that pixelserv-tls catches and exposes them to you in this scenario.

 

[Butterfly Bones]

Sequence of events + analysis

missing cert

Initially server "t.appsflyer.com" doesn't have a certificate in CERT_PATH i.e. /opt/var/cache/pixelserv on Entware. Hence, you get one or more "missing" lines in sort of avalanche.

This is because requests come in fast (in a few ms) but auto cert generation takes time (600ms on 1.2GHz Cortex-A9). You can use "pixelserv-tls -B" to run the benchmark and get the average generation time on RT-AC86 btw.

after cert auto generated

Once the cert generated, successive requests pass the initial check and enter TLS handshake. However, it fails because the client doesn't want to recognise the server certificate. This is a bit dubious.

We went through such debious behavior in rc.2/rc.3 cycles. And now we have the new counter "uca" and "uce" to register the stats. For the detailed usage and interpretation, I would recommend the "TLS Handshake" section on the pixelserv-tls MAN page.

In a nutshell, I suspect one app on this particular client (192.168.1.12 ) has hard coded fingerprint and refused to send content if the server certificate does not match. Why do they want to do that?...very likely they don't want other to see what's inside.

Bingo!
https://www.abine.com/blog/2013/mixpanel/
https://www.appsflyer.com/
https://www.trustradius.com/compare-products/appsflyer-vs-mixpanel

I'll experiment with blocking this in AB-Solution and see what app stops working. I cannot tell since many of these keep coming up while the phone is on my desk, on, but idle.

appsflyer.com and mixpanel.com are the most frequent.

 

[Asad Ali]

@kvic Either I understand it differently or its actually not working as it should be.

I just tested by opening https://mypixelservsip/servstats page from a device without the certificate installed and it's still incrementing slh on every page refresh and not doing anything to uca and uce counters.