pixelserv pixelserv - A Better One-pixel Webserver for Adblock

[kvic]

Occasionally when I need to debug a malfunction website and suspect adblock is the culprit, I need to SSH into the router, turn on access log by editing the init.d script, re-launch pixelserv and 'tail -f' the log file. I feel tired of the cumbersome steps...

So here is the new version: V35.H12.Kh:

• Allow access log to be switched on/off through HTTP
• Add status code of processing result to access log for better diagnosis

To turn on access log, now people can do it from your PC

• wget -q http://doubleclick.net/log=1

To turn off access log,

• wget -q http://doubleclick.net/log=0

To check status of access log,

• http://doubleclick.net/servstats (or "/servstats.txt")

And here is my recent favourite idiom to debug malfunction website due to adblock:

• alias pixlog='wget -q http://doubleclick.net/log=1;ssh -t admin@RT-AC56U tail -f /opt/var/log/pixelserv.log;wget -q http://doubleclick.net/log=0'

The idiom creates an alias that first enable access log, then 'tail -f' the log file, and turn off access log when you quit checking the log file.

This alias works for me on a PC running Linux or OS X with SSH certificate based authentication enabled. I think people can easily adapt it to work on Windows with PuTTY.

 

[bayern1975]

very interesing....i wish to try this many times but still to difficulty to understand for me.....

 

[ryzhov_al]

Somebody asked to add it to Entware repo. I'm going to take start script from the first post if you don't mind.

 

[kvic]

Not at all but glad to see it on Entware. I'm feeling a bit flattered actually as one of the many contributors to pixelserv.

 

[BaudelaireNG]

Hello, wish to experiment with pixelserv-tls but stuck with Firefox 44.0 saying:
abc.li uses an invalid security certificate.
The certificate is not trusted because the issuer certificate is unknown.
The server might not be sending the appropriate intermediate certificates.
An additional root certificate may need to be imported.
(Error code: sec_error_unknown_issuer)

While Firefox 30.0 says:
abc.li uses an invalid security certificate.
The certificate is not trusted because no issuer chain was provided.
(Error code: sec_error_unknown_issuer)

There having medium to high understanding of PKI i tried:
1) importing self-signed ca.crt into Firefox -- this generates above Firefox errors.
2)constructed chain of MyRoot.crt-->Intermediate.crt (which became ca.crt on pixelserv-tls configuration); imported both to Firefox -- there we have no go aswell.

At the trie number 2 leaf certificate says it's signed by MyRoot.crt, where I mostly expect it to be issued by Intermediate.crt; as like pixelserv-tls is taking Issuer field from topmost certificate which is MyRoot.crt

TL;DR we can read here and there that Firefox have stricter policy as to certificates -- needs server to provide full chain + expects to have these chains imported.
Will Firefox browser be supported by pixelserv-tls or I'm making mistake somewhere ?

Cheers!

EDIT to issue certs i used openssl, and wish to keep it that way

 

[kvic]

Hi @BaudelaireNG

1) importing self-signed ca.crt into Firefox -- this generates above Firefox errors.

You don't have to self sign the CA cert. A root CA need not be self-signed as far as I remember. Also, ensure you have specified "Common Name" in "Subject Name" and "Issuer Name" fields if you use openssl command line. IMO it's easier and less error-prone to use EasyRSA and follow the steps here (I attached a screenshot of my Root CA cert generated this way).

Also see an attached screenshot of a working firefox.

2)constructed chain of MyRoot.crt-->Intermediate.crt (which became ca.crt on pixelserv-tls configuration); imported both to Firefox -- there we have no go aswell.

I haven't tried this way though I had thought of trying it for a long time. I heard we need to lock up MyRoot.crt in a safe as a good practice

I think it shall work too as long as Intermediate.crt has Issuer Name and Subject name set accordingly. Note that pixelserv-tls takes Issuer Name from the CA cert supplied to it and stamps on subsequent certs it generates automatically.

Let us know how it goes for you adventure...

Firefox:


Root CA for pixelserv-tls by EasyRSA:

 

[Goobi]

@kvic what does "cls: # of client shutdown" mean? Along those lines is there any doc that states what the servstats are? Some are obvious but others not so much. Thanks in advance.

 

[kvic]

@Goobi you can find a longer description of all counters on GitHub: https://github.com/kvic-z/pixelserv-tls#stats

"cls" means "number of connections that were closed by the client while reading or replying to the request" I won't read too much into the detail of that.

Personally I find the following counters informative:

uts: Uptime                       2 days 12:07
req: Total # of requests          11402
avg: Avg size of reqs             759 bytes
rmx: Max size of reqs             33181 bytes
tav: Avg process time             503 ms
tmx: Max process time             10000 ms
slh: # of HTTPS /w a good cert    907
slm: # of HTTPS w/o a cert        1
log: access log enabled (0=no 1=yes) 0

 

[Goobi]

@Goobi you can find a longer description of all counters on GitHub: https://github.com/kvic-z/pixelserv-tls#stats

"cls" means "number of connections that were closed by the client while reading or replying to the request" I won't read too much into the detail of that.

Personally I find the following counters informative:

uts: Uptime                       2 days 12:07
req: Total # of requests          11402
avg: Avg size of reqs             759 bytes
rmx: Max size of reqs             33181 bytes
tav: Avg process time             503 ms
tmx: Max process time             10000 ms
slh: # of HTTPS /w a good cert    907
slm: # of HTTPS w/o a cert        1
log: access log enabled (0=no 1=yes) 0

Thanks @kvic. I noted that sometimes I get the following error for a handful of domains:

Mar 29 23:05:01 pixelserv[24063]: Cannot use /opt/var/cache/pixelserv/_.pintere
st.com

This along with the others are self generated so not sure why pixelserv is having a problem with them. Could they have perhaps expired? I delete the ones that generate these errors but at some point, I'll get the messages again for a few different domains. Is this anything to worry about? How does pixelserv handle expired certs? Are they deleted and regenerated or does that have to be done manually? Thanks in advance.

 

[kvic]

Mar 29 23:05:01 pixelserv[24063]: Cannot use /opt/var/cache/pixelserv/_.pinterest.com

I've seen this error at the very early days of the code development. Hence, a new counter was added specifically to see how frequent it happens:

sle: # of HTTPS /w a bad cert 0

But I haven't seen another occurrence on my router for a very long time. The error means that openssl crypto library runs into issues in loading that particular certificate to initialise an encrypted session.

The cert file (/opt/var/cache/pixelserv/_.pinterest.com in your example) stores both the public cert and its private key of an adserver. Any modification to its content may damage the integrity and invalidate the cert.

Auto generated certs are set to be valid for a period of 10 years. So expiry is a less likely cause.

Worth checking the timestamp of the cert file (or even better its content) when this happens again. See if the file content changed after its initial creation.

Is this anything to worry about?

The interaction between browsers and pixelserv is only on your home LAN. I won't worry too much. I would use sle counter mentioned above to monitor how frequent this happens. Then grep syslog to see how many certs having issues.

When pixelserv cannot load a cert, it will close the connection of that particular advert request. Browsers will receive and display connection error (if it's not a hidden advert request). You'll see the error if adblock plugin is not enabled in your browser. So the end result is still blocked ad...together with possible error message on display.

Since it's a recurring issue, I would like to understand why. Pls keep us updated if possible...

 

[kvic]

How does pixelserv handle expired certs? Are they deleted and regenerated or does that have to be done manually?

All auto generated certs are valid for 10 years. The Root CA cert is recommended to be generated for a valid period of 10 years. So the whole setup can run for a good decade.

When a cert expires, it needs to be re-generated. At the moment pixelserv don't have capability to do that automatically. The reason is auto re-generation of all certs cost little to nothing. So, by the 9th year (since people first setup pixelserv), create a new Root CA cert, delete all existing auto certs, we'll be ready for another run of 10 years...

 

[bayern1975]

is possible to goes normaly to the router over https? i get everytime this screen and then have to go to advanced and add rule.....

 

[kvic]

is possible to goes normaly to the router over https? i get everytime this screen and then have to go to advanced and add rule.....

Your question is about HTTPS access to router's WebUI. The problem is how to suppress browser warnings of self signed certificate used by Asuswrt's httpd.

Here are some ways to solve this for Firefox: https://support.mozilla.org/en-US/questions/1055526

Please search the forum or google next time...

 

[BaudelaireNG]

Hello, as for my post #125 where Firefox 35.0 and 44.0 reported "issuer certificate is unknown" and taking Your advises @kvic You gave in #126 using EasyRSA 2.2 generated following:

# openssl x509 -in ca.crt -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            a6:88:f6:38:e0:48:a8:f5
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=Pixelserv CA
        Validity
            Not Before: Apr  2 16:36:06 2016 GMT
            Not After : Mar 31 16:36:06 2026 GMT
        Subject: CN=Pixelserv CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
               <long modulus>
  Exponent: 65537 (0x10001)
  X509v3 extensions:
  X509v3 Subject Key Identifier:
  A5:19:AC:2C:BC:9A:31:2D:54:A8:4E:5A:D6:91:B9:45:D5:30:EF:BD
  X509v3 Authority Key Identifier:
  keyid:A5:19:AC:2C:BC:9A:31:2D:54:A8:4E:5A:D6:91:B9:45:D5:30:EF:BD
  DirName:/CN=Pixelserv CA
  serial:A6:88:F6:38:E0:48:A8:F5

  X509v3 Basic Constraints:
  CA:TRUE
  Signature Algorithm: sha256WithRSAEncryption
   <logn signature>

(.. this is self-signed cert, all root certs must self-signed)
Latest pixelserv-tls from optware rep generated following cert for domain "abc.li":

#pixelserv.mips.performance.static  192.168.1.2 -p 99 -k 443 -u admin -f
# openssl x509 -in abc.li  -text
Certificate:
  Data:
  Version: 3 (0x2)
  Serial Number: 1459615385 (0x56fff699)
  Signature Algorithm: sha256WithRSAEncryption
  Issuer: CN=Pixelserv CA
  Validity
  Not Before: Apr  2 16:43:05 2016 GMT
  Not After : Mar 31 16:43:05 2026 GMT
  Subject: CN=abc.li
  Subject Public Key Info:
  Public Key Algorithm: rsaEncryption
  Public-Key: (1024 bit)
  Modulus:
  <rest of the cert>

.. which is valid..

#openssl verify -CAfile ca.crt abc.li
abc.li: OK

I imported ca.crt into Windows 7 certificate storage into Trusted Root Certs sectione, where for Firefox imported it from Firefox prefs into .. Authorities secteone, giving it power to "identify web sites", "identifi e-mail senders", "identifi software developers".
Whenever "Subject:" field from ca.crt match "Issuer:" from abc.li i believed it makes them chained.
However in my situation browsers dont pick that chain, reporting:
Google Chrome latest (this one uses Windows certificate storage):

NET::ERR_CERT_AUTHORITY_INVALID
Subject:abc.li
Issuer:Pixelserv CA
Expires on:Mar 31, 2026
Current date:Apr 2, 2016

Firefox 44.0/35.0:

abc.li uses an invalid security certificate. The certificate is not trusted because no issuer chain was provided. (Error code: sec_error_unknown_issuer)

Runt it also on Iceweasel (FF based browser) frome on GNU/linux, same error as FF.
And Internet Explorer 9 giving general error too.
I made sure I imported those certs. Made all involved files on router world readable. Pointed domain "abc.li" from both "hosts" file and dnsmasq interchangely. Used URL "https://abc.li". Secure sites from WEB connects normally.
So thats it for the status. I thought long time ago such software should exists for placing content-type aware substitutions + ssl, but it looks like my setup is somewhere fundamentally broken for this to work Or I just plainly missing something =[
Mhmm what looks abnormal to me is FF doesnt pick root chain for "abc.li" thus doesnt make chain -- most working chains form WEB are displayed as tree in it's GUI for viewing target domain certificate (Details-->Certificate Hierarhy). In my case I have no Tree structure but a leaf certificate only.
And the other thing is when i #cat abc.li to view ascii of pixelserv-tls generated certificate beside cert data i find

---BEGINS PRIVATE KEY---

section in it. Which is disturbing After removing it, it still validates, but pixelserv-tls cant serve this certificate.
So thats for the status for this hopefully minor case.
Cheers!

 

[kvic]

I imported ca.crt into Windows 7 certificate storage into Trusted Root Certs sectione, where for Firefox imported it from Firefox prefs into .. Authorities secteone, giving it power to "identify web sites", "identifi e-mail senders", "identifi software developers".

For importing Root CA certs in Windows, worth going through the steps here: https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/636/17/

In particular, pick "Computer account" and "Local Computer". Chrome and IE pick up system wide CAs.

I'm not a daily Firefox user. Look at my FF installation again and you're right that FF manages its own Root CAs. I had to import ca.crt by following a guide such as this one: https://wiki.wmtransfer.com/projects/webmoney/wiki/Installing_root_certificate_in_Mozilla_Firefox

I only pick "identify web sites".

Mhmm what looks abnormal to me is FF doesnt pick root chain for "abc.li" thus doesnt make chain -- most working chains form WEB are displayed as tree in it's GUI for viewing target domain certificate (Details-->Certificate Hierarhy). In my case I have no Tree structure but a leaf certificate only.

That's weird...I could see something like "Pixelserv CA > abc.li" there. Run out of ideas. I assume you use the same ca.crt for both Pixelserv and Firefox..

And the other thing is when i #cat abc.li to view ascii of pixelserv-tls generated certificate beside cert data i find ---BEGINS PRIVATE KEY--- section in it. Which is disturbing After removing it, it still validates, but pixelserv-tls cant serve this certificate.

The private key to each generated certificate is stored together with the cert itself. The private key is necessary for pixelserv to work when serve on behalf of that adserver domain. Perhaps the cert and its private key shall be stored in a secure storage.

But hey..pixelserv is a toy project and intend to work on a home LAN. Touch wood... if my router is hacked and the certs stolen, I only have to generate a new Root CA cert and delete the old Root CA and all auto certs. So that I start from clean again...

So thats for the status for this hopefully minor case.
Cheers!

Thanks for your detailed feedback. I picked up a few things I've almost forgotten

 

[bayern1975]

i have realy big problems with my router over https with pixelserv-tls.....kaspersky and firefox browser everytime stop me to get in.....i know that is not problem with pixelserv but with http protocol i do not have any problems.....

 

[kvic]

i have realy big problems with my router over https with pixelserv-tls.....kaspersky and firefox browser everytime stop me to get in.....i know that is not problem with pixelserv but with http protocol i do not have any problems.....

Can you describe the bold in a bit more detail what problem are you exactly facing?

 

[bayern1975]

Can you describe the bold in a bit more detail what problem are you exactly facing?

this is problem...

 

[kvic]

LOL @bayern1975 I had no clue at the first glimpse of your screenshot.

You're lucky. Here might be a workaround for your Kaspersky issue. I wish Kaspersky would have offered users a 'whitelist' facility to allow good-known self-signed certs. But the below seems the best they could offer you:

http://i.stack.imgur.com/TxItR.png
http://support.kaspersky.com/us/12489#block1

Worth a try...

EDIT:

Actually forget the above.... worth trying adding the HTTPD self-signed cert into Windows just like how you did for ca.crt. I bet security applications such as Kaspersky honour all certs in system-wide Windows vault.

 

[bayern1975]

how can i create or get this HTTPD self-signed cert?