pixelserv pixelserv - A Better One-pixel Webserver for Adblock

[DonnyJohnny]

Oh that makes sense, as pixelserv is using its own webserver. Though I see the same TLS1.2 in both firefox & chrome. I only see TLS 1.3 on TLS 1.3 enabled websites. I cleared all ca's. Using ab-solution... any thoughts?

You may not have done the correct installation command.
Use this

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

Restart the pixelserv and check again.

 

[Asad Ali]

I only see TLS 1.3 on TLS 1.3 enabled websites. I cleared all ca's.

And as per my understanding that's the correct behavior. How can you expect TLS 1.3 on websites which doesn't have it implemented yet on thier server side?

 

[DonnyJohnny]

And as per my understanding that's the correct behavior. How can you expect TLS 1.3 on websites which doesn't have it implemented yet on thier server side?

He is referring to this particular pixelserv site.
https://pixelserv-tls’s_IP/servstats
Suppose to see tls 1.3

 

[Makaveli]

on FF 62.0.2 I see this

 

[Asad Ali]

He is referring to this particular pixelserv site.
https://pixelserv-tls’s_IP/servstats
Suppose to see tls 1.3

Did he upgrade his browser version to the TLS 1.3 supported BETA's since stock version doesn't support it yet?

 

[Asad Ali]

on FF 62.0.2 I see this

You need to upgrade to the BETA version of FF.

 

[Makaveli]

You need to upgrade to the BETA version of FF.

I'm aware but won't be doing so on my primary desktop. Maybe on my laptop I will.

 

[Asad Ali]

I'm aware but won't be doing so on my primary desktop. Maybe on my laptop I will.

Then you won't see TLS 1.3 on servstats page.

 

[Twiglets]

Quote from https://kazoo.ga/pixelserv-tls :

"The TLS 1.3 experience

To experience pixelserv-tls with TLS 1.3, you'll need a supported browser. Currently Firefox v63 beta and Chrome v70 DEV edition both support the final standard of TLS 1.3. You can get them from the previous links."

You only get TLS 1.3 [Final] with these browser versions !!!

 

[DonnyJohnny]

You need to upgrade to the BETA version of FF.

I'm aware but won't be doing so on my primary desktop. Maybe on my laptop I will.

No you don’t have to install beta version.

Enable TLS 1.3 in Firefox

• Search for about:config in the address bar and press enter
• In the search space, search for tls.version.max
• Now change the value from 3 to 4
• Restart your Firefox
• Go to https://istlsfastyet.com/
• Click on the padlock in the URL bar
• Now you should see a small pop-up citing the connection to be secure. Click on the > that you see and then click on More Information
• A window with certificate details will open up. See the technical details at the bottom of it, you’ll see TLS 1.3 being the security protocol.

Taken from https://www.thesslstore.com/blog/tls-1-3-approved/

EDIT: Sorry. Realised Firefox 61 only have tls 1.3 draft 28 NOT the final version.

Did he upgrade his browser version to the TLS 1.3 supported BETA's since stock version doesn't support it yet?

He already mentioned he is able to see tls 1.3 in other tls 1.3 sites.

 

[Asad Ali]

He already mentioned he is able to see tls 1.3 in other tls 1.3 sites.

Ah ok that's strange.

 

[DonnyJohnny]

Ah ok that's strange.

Sorry. Need to final version of tls 1.3 to see the tls 1.3 in the pixelserv sites.
And yes, need the beta version of Firefox 63 which include the final version. Firefox 63 beta will be coming out of beta in Oct 2018.

I tested on my chrome and chrome beta. One is draft 28, one is final. Only the one with tls 1.3 final can see the tls 1.3 in pixelserv servstats site.

 

[Asad Ali]

Sorry. Need to final version of tls 1.3 to see the tls 1.3 in the pixelserv sites.
And yes, need the beta version of Firefox 63 which include the final version. Firefox 63 beta will be coming out of beta in Oct 2018.

Oh okay now it's all clear.
Pixelserv-tls is using final version of TLS v1.3 and non beta browser version might be using a draft version of TLS v1.3 hence the incompatibility.

 

[kvic]

2.2.0-rc.4 is available

• NEW indicator of TLS 1.3 support status on servstats page.
• FIXED failed to log server name on unsuccessful handshakes. Garbage may be captured instead. When it happens it may lead to crash or a hung process. (issue reported from @Asad Ali @Protik @jrmwvu04)

For details, pls read the release page as usual.

Looks like my best time in this thread. I have ppl handling the frontline in the thread and have other ppl working hard in silos on tests! thank you. Time for me to hit the sac now.

 

[dugaduga]

I used amtm 1.3 to install pixelserv beta, which detected the latest 2.2.0 rc3, I've been enforcing min tls1.2-tls1.3 in all browsers. Purged all certs, assumed it had restarted on its own due to the fact it had to be installed first ok tried and no luck still, maybe I have to reinstall it again. ok latest rc4 by terminal cmd, says flags: no_tls1_3; hmm, does ps need a flag? perhaps it has to do with the tls version; I'm using the latest firefox 63 beta 8 & chrome stable, weak ciphers disabled & security.ssl.disable_session_identifiers;true in FF. (Disable sending session IDs and sending session tickets). Enabling them both makes no difference. Chromium 71 set to 1.3 final didn't work either. Will figure it out eventually. Thank you so much for all the great work kvic!

 

[DonnyJohnny]

I used amtm 1.3 to install pixelserv beta, which detected the latest 2.2.0 rc3, I've been enforcing min tls1.2-tls1.3 in all browsers. Purged all certs, assumed it had restarted on its own due to the fact it had to be installed first ok tried and no luck still, maybe I have to reinstall it again. ok latest rc4, says flags: no_tls1_3; hmm, does it need a ps flag? perhaps it has to do with the tls version; I'm using the latest firefox 63 beta 8 & chrome stable, weak ciphers disabled & security.ssl.disable_session_identifiers;true in FF. (Disable sending session IDs and sending session tickets). Enabling makes no difference. Thank you so much kvic!

Already said in my previous post. Don’t use amtm to install. Use the command on my previous post.

 

[dugaduga]

I tried that as well with no difference. (update) you're right, I used the tls link 1.2 version, not the tls 1.3... Chrome & Firefox are good now. Iridium, a hardened version of chromium 66.0.3359.130 using tls 1.3 draft 23 is detected just fine as well

 

[dugaduga]

2.2.0-rc.4 is available

FIXED failed to log server name on unsuccessful handshakes. Garbage may be captured instead. When it happens it may lead to crash or a hung process. (issue reported from @Asad Ali @Protik @jrmwvu04)

I noticed a reoccurring crash as well; Blocking rgom10-en.url.trendmicro.com sometimes 100x every few seconds, perhaps this had something to do with the rapid frequency of its crashing; diversion sometimes reported it as disabled, othertimes not, but l -5 logging stopped; and /servstats wouldn't load. Happened daily, often multiple times. Hopefully this will be the end of that.

 

[SMS786]

Upgraded to rc4 per @DonnyJohnny's instructions. Also running FF 62.0.2. I am seeing TLS 1.3 on some sites, but unfort not on the servstats' page..which was expected. Can't wait for Mozilla to add the final draft of TLS 1.3 to their stable builds..

Thanks for the great work, as always, @kvic!

 

[truglodite]

kvic, my friend, thank you again for updating pixelserv. I'm running 2.2.0-rc.4 and getting expected results (TLS 1.3 in chrome beta).

I'm still having trouble with android 'system clients', but I understand this is out of the scope of router scripts. Add to that, since my son started playing rainbow 6 siege on our xbox, I have one more source of random annoying traffic (high uce stats... pings up to ~50/sec... watson.telemetry.microsoft.com... gah!). At least this behavior hasn't crippled my network. The most common app seems to come in a pattern that pings at roughly 5hz for 5min. These are almost imperceptible other than logs. The occasional 50hz ping has mostly downed my network for a couple of minutes while active. This behavior seems unacceptable to me. Is this how companies punish those who refuse to comply with data mining practices?

Regardless, my son's games are working fine, as is my phone and the other clients that exhibit this behavior (pretty much all devices, but the apple phones are much less aggressive). As long as this is true, I've got no reason to whitelist watson.telemetry or other known spywares. I've seen some other webpages where folks suggest whitelisting these urls for 'full functionality' of games... also to allow window's updates to work, LOL! If my son gets games that require telemetry to register achievements, I'll have to tell him too bad... but I guess if microsoft requires it to download updates, that would really suck. I hope game makers & os designers don't go down this road, without significant public backlash that stops it cold.