pixelserv - Jarmka's thread

Is ssl caching anything like tls session ticketing in pixelserv-tls? What is the difference? Enabling session tickets we effectively lose forward secrecy; an integral part of securing TLS. This leaves me curious as to how pixelserv uses tls certs and session tickets. Does pixelserv use and cache the exact same certs issued to a specific application like a web browser? How does it affect all the clients on a network using pixelserv-tls, and if the router is compromised, can this cache can be used to decipher users encrypted sessions? If so this could potentially make routers using pixelsrv-tls targets for ransom. These are potential issues that should be emphasized if they are offered these features, and it would be useful to have options to disable TLS session tickets, allow cert storage only in volatile memory, as well as purge rotation periods. Personally I prefer security over speed.

"To support session resumption via session IDs the server must maintain a cache that maps past session IDs to those sessions’ secret states. The cache itself is the main weak spot, stealing the cache contents allows to decrypt all sessions whose session IDs are contained in it."

"The forward secrecy of a connection is thus bounded by how long the session information is retained on the server. Ideally, your server would use a medium-sized cache that is purged daily. Purging your cache might however not help if the cache itself lives on a persistent storage as it might be feasible to restore deleted data from it. An in-memory storage should be more resistant to these kind of attacks if it turns over about once a day and ensures old data is overridden properly."

Is it possible to disable ssl cache & tls session ticketing in pixelsrv-tls?

and

Is it possible to implement a feature in pixelsrv-tls to disable tls-session tickets globally; that would benefit an entire network enforcing strict forward secrecy globally? I'm searching for a solution for chrome but I cannot find any means of disabling them; as https://www.ssllabs.com/ssltest/viewMyClient.html demonstrates.

It is possible to disable TLS tickets for example in IIS within windows Schannel, ASP.NET at the application and or page level, and Firefox, (There I notice minimal performance impact) but I do not see an option for this in Chrome. OpenSSL contexts support the SSL_OP_NO_TICKET option as of OpenSSL 1.0.0 that disables the use of TLS Session Tickets (RRC 4507) in order to protect perfect forward secrecy. I believe it is not possible in java applets and many other pieces of software. Such an option would benefit client security tremendously; including but not limited to highly secure environments like banks and institutions. Pixelsrv-tls is largely used to improve security by blocking malware-domains and potentially dangerous ads. To argue in favor to make it less so and less extensible is rather counter intuitive. There are many scenarios where this could be potentially extremely useful and beneficial for clients and users. https://timtaubert.de/blog/2014/11/...-side-tls-session-resumption-implementations/

Although disabling session tickets will undoubtedly have a negative performance impact, for the moment being you will need to do that in order to provide forward secrecy"

Click to expand...

The best you can do to provide forward secrecy to visitors is thus again switch off session ticket support until a proper solution is available.

are you the same person cross posting on Github, my blog and here literally like within one hour? If you have such urgency and worries, the best approach is to stop using it, and then wait for responses.

TLS connections between pixelserv-tls and your client (browser/apps etc) are only limited between the two. It won't affect your browser's other TLS connections in any way.

OH thank you kvic, I'm beginning to understand this a bit better now. You are saying pixelserv is only using TLS connections and certs strictly to interface between pixelserv-tls and the given connection from an app/browser (etc)..., NOT as a proxy through which the outside web is tunneled? Thus the app/browsers TLS connection is unaffected. But is Pixselserv-tls somewhat of an HTTPS proxy of sorts? I don't yet understand how it can insert a pixel into encrypted traffic otherwise. I am curious if it has the potential to evolve to block/modify individual parameters within a hello/handshake https packet; this would be a great way to ensure forward secrecy and blocking depreciated ciphers globally.

OH thank you kvic, I'm beginning to understand this a bit better now. You are saying pixelserv is only using TLS connections and certs strictly to interface between pixelserv-tls and the given connection from an app/browser (etc)..., NOT as a proxy through which the outside web is tunneled? Thus the app/browsers TLS connection is unaffected. But is Pixselserv-tls somewhat of an HTTPS proxy of sorts? I don't yet understand how it can insert a pixel into encrypted traffic otherwise. I am curious if it has the potential to evolve to block/modify individual parameters within a hello/handshake https packet; this would be a great way to ensure forward secrecy and blocking depreciated ciphers globally.

Click to expand...

pixelserv-tls is a server in which ad requests are terminated there. It's _not_ a proxy. Non ad requests will not even reach pixelserv-tls.

Regarding forward secrecy, you've better started checking with your banks and other external servers of critical importance. You don't have to worry about pixelserv-tls sitting on your LAN that only serves empty ads.

@kvic, thank you for your response! non ad requests are not reached by pixselserv but pixselserv still must be able to modify content within an encrypted https connection, which includes all resources not just ads, that means it must be able to have access to the keys of a given https session in order to decrypt and inject pixels, hence, why it caches and saves copies of the certs to disk. Please correct me if I am wrong. So if the router is compromised and pixelserv certs are stolen, can this pose a risk for a mitm, and endanger in anyway other connections? If so, does pixselserv rotate certs regularly to avoid such a potential security risk?

In part, forward secrecy simply means rotating keys, either on client or server side, or both, to avoid these kind of scenarios.

Enabling session resumption is an important tool for speeding up HTTPS websites, especially in a pre-HTTP/2 world where a client may have to open concurrent connections to the same host to quickly render a page. Subresource requests would ideally resume the session that for example a GET / HTTP/1.1 request started.

DID WEB SERVERS REACT?
No, not as far as I’m aware. None of the three web servers mentioned above has taken steps to make it easier to properly configure session resumption. But to be fair, OpenSSL didn’t add any new APIs or options to help them either.

All popular TLS 1.2 web servers still don’t evict cache entries when they expire, keeping them around until a client tries to resume — for performance or ease of implementation. They generate a session ticket key at startup and will never automatically rotate it so that admins have to manually reload server configs and provide new keys.

THE CADDY WEB SERVER
I want to seize the chance and positively highlight the Caddy web server, a relative newcomer with the advantage of not having any historical baggage, that enables and configures HTTPS by default, including automatically acquiring and renewing certificates.

@kvic, thank you for your response! non ad requests are not reached by pixselserv but pixselserv still must be able to modify content within an encrypted https connection, which includes all resources not just ads, that means it must be able to have access to the keys of a given https session in order to decrypt and inject pixels, hence, why it caches and saves copies of the certs to disk. Please correct me if I am wrong. So if the router is compromised and pixelserv certs are stolen, can this pose a risk for a mitm, and endanger in anyway other connections? If so, does pixselserv rotate certs regularly to avoid such a potential security risk?

In part, forward secrecy simply means rotating keys, either on client or server side, or both, to avoid these kind of scenarios.

Click to expand...

If ever the router has been compromised. Do you think it is pixelserv fault? The invader probably will just do anything they like since the router is root mode. What talking you? So whose fault is it when router is compromised? Maybe you should complain to manufacturer and ask how come their router can be compromised.

Using RT-AC68U
Running on RT-AC68U_384.7_alpha1-g43c4482aa with SkyNet 6.3.2! AB-Solution 3.11.2 with pixelserv-tls v2.1.3.test4, amtm 1.2, DNScrypt-proxy 2.0.16 Final by Frank with Haveged.

@kvic thank you brother I appreciate your support. This is all I am seeing, not sure exactly what any of it means or why it says rgom10-en.url.trendmicro.com:80; It is a 'local' address; Malicious site blocking is disabled. I had originally assumed it was a sign it was at the top of the host file/blocklist, but that does not appear to be the case.

This is all I am seeing, not sure exactly what any of it means or why it says rgom10-en.url.trendmicro.com:80; It is a 'local' address; Malicious site blocking is disabled. I had originally assumed it was a sign it was at the top of the host file/blocklist, but that does not appear to be the case.

Click to expand...

It simply means two things:
1. the domain is included by your adblock script or other means in the blocking list and is pointed to your "pixelserv ip"
2. by dnsmasq's internal arrangement this domain is the first one. Hence, when you do reverse DNS lookup on your "pixelserv ip", it's resolved to this domain.

It's not necessary the "first" domain in your host files that might be a misunderstanding.

With respect to why this domain is included, ask yourself. Check what adblock script you're using, and why it's included.

Nevertheless, there is nothing harmful. I guess it's included to prevent your router calling home (i.e. TrendMicro's home).

It simply means two things:
1. the domain is included by your adblock script or other means in the blocking list and is pointed to your "pixelserv ip"
2. by dnsmasq's internal arrangement this domain is the first one. Hence, when you do reverse DNS lookup on your "pixelserv ip", it's resolved to this domain.
Nevertheless, there is nothing harmful. I guess it's included to prevent your router calling home (i.e. TrendMicro's home).

Click to expand...

You were correct! I had thought I missed something, and in fact it is on the top of dnsmasq hosts list. Just fyi this was part of some code I had experimented with, some users had reported a 10x increase in pixelserv's tav and tmax with the following FIRST TWO codes; I found browsing sped up by an average of 20-40% or so. The primary benefit came from blocking PTR (reverse dns) and arpa.

Speed up browsing by 25-40%, block nearly all querys flagged by DNSCRYPT suspicious.log, and block AsusWRT signaling to Google Safe Browsing and google.com. This is accomplished by blocking PTR or reverse DNS querys. This will stop DNS name resolutions in some AsusWRT apps like itfop; Other than that it should not be a problem for except those using custom scripts for automated logging with host resolution. Alternatively you can selectively block in-addr.arpa IPs collected from dnscrypt suspicious.log directly in dnsmaq hosts.

To confirm this worked, simply type dnsmasq, and hit 'enter' while watching your dnsmasq logs in ab-solution for the following:

May 5 15:53:27 dnsmasq[10947]: using local addresses only for domain in-addr.arpa
May 5 15:53:27 dnsmasq[10947]: using standard nameservers for domain 0.168.192.in-addr.arpa
May 5 15:53:17 dnsmasq[10793]: using nameserver 127.0.0.1#65053

Click to expand...

Block AsusWRT built in signaling to Trendmicro, Google & other entities:
Create/Add to bottom of /jffs/scripts/hosts.postconf

You were correct! I had thought I missed something, and in fact it is on the top of dnsmasq hosts list. Just fyi this was part of some code I had experimented with, some users had reported a 10x increase in pixelserv's tav and tmax with the following FIRST TWO codes; I found browsing sped up by an average of 20-40% or so. The primary benefit came from blocking PTR (reverse dns) and arpa.

Speed up browsing by 25-40%, block nearly all querys flagged by DNSCRYPT suspicious.log, and block AsusWRT signaling to Google Safe Browsing and google.com. This is accomplished by blocking PTR or reverse DNS querys. This will stop DNS name resolutions in some AsusWRT apps like itfop; Other than that it should not be a problem for except those using custom scripts for automated logging with host resolution. Alternatively you can selectively block in-addr.arpa IPs collected from dnscrypt suspicious.log directly in dnsmaq hosts.

nvram show | grep dns_probe
dns_probe_host=dns.msftncsi.com
dns_probe_content=131.107.255.255 fd3e:4f5a:5b81::1
nvram set dns_probe_content=127.0.0.1 (or 0.0.0.0 as I prefer actually just leave it bank turns it off, but turning it off breaks dual wan)

These first two "codes" have reportedly attended massive speed improvements.

Click to expand...

Reportedly? *cough* According to which reports? Haven't we been through this already? I tried out the recommendations in a now deleted thread on this forum, and the wild promises of "massive speed improvements" were nothing but a hoax.

I hope you @kvic find this information incredibly useful and helpful. @Beherit, well to be more accurate, I could have said "one user's report, including my own..." though everything including what he and I posted was deleted, so I only have the backup info provided here. I personally noticed a 25%-40% increase of browsing speed on the majority of sites I had visited; The other user from the snbform reported a 10x improvement in pixelserv's tav or tmax. If you genuinely tested this and followed instructions properly, I guess all you got was better security, but it certainly improved our browsing speeds. What will be necessary for scientific purposes is to have as many people report their results as possible. Also reporting their Router and firmware versions may suggest it benefits specific hardware / firmware combinations. Only one user reported their results, and his results were surprising. @kvic if you would report any noted speed improvements, or lack thereof, that would be appreciated.

OH here it is:

Updated 5/10/2018

Jarmka,

This is so useful !!!
Using all the latest changes I am getting 10 times the speed during browsing.
Pages now refresh instantly.

I tested it alright, by putting it through a series of tests using both pings and a stop watch to measure throughput, loading times and latency. Emailing, page loading in web browsers, gaming, torrents, file transfers, dns hostname resolving and what else I forgot... there was absolutely no change at all in any way. It's just as much of a hoax as your claim of "better security".

The thread you mention was deleted for several, all very, good reasons. Yet you keep up your not-so-subtle attempts to hijack other threads to pursue your agenda.

I won't comment any further on this, as it just derails this thread further into off-topic territory.

I hope you @kvic find this information incredibly useful and helpful. @Beherit, well to be more accurate, I could have said "one user's report, including my own..." though everything including what he and I posted was deleted, so I only have the backup info provided here. I personally noticed a 25%-40% increase of browsing speed on the majority of sites I had visited; The other user from the snbform reported a 10x improvement in pixelserv's tav or tmax. If you genuinely tested this and followed instructions properly, I guess all you got was better security, but it certainly improved our browsing speeds. What will be necessary for scientific purposes is to have as many people report their results as possible. Also reporting their Router and firmware versions may suggest it benefits specific hardware / firmware combinations. Only one user reported their results, and his results were surprising. @kvic if you would report any noted speed improvements, or lack thereof, that would be appreciated.

OH here it is:

Updated 5/10/2018

Click to expand...

yes I will report too - what a load of BS - no changes in speed whatsoever - if anything there is a speed decrease

I tested it alright, by putting it through a series of tests using both pings and a stop watch to measure throughput, loading times and latency. Emailing, page loading in web browsers, gaming, torrents, file transfers, dns hostname resolving and what else I forgot... there was absolutely no change at all in any way. It's just as much of a hoax as your claim of "better security".

Click to expand...

If what you say is true [regarding your speeds] it is good to know it doesn't effect all systems equally. I certainly have, and twigglets reported faster browsing speeds. In terms of security what the first two codes do is eliminate up to a dozen arpa protocols including ipv6 PTR [and link #2] [important], blocks Trendmicro & inbuilt Asus probes from calling home, [increasing privacy & possibly security] and blocks the vast majority of "suspicious" entries detected and logged by dnscrypt. If there are any potential backdoors or security bugs within any of these protocols, the router software itself, or suspicious PTR entries, disabling them will decrease attack surface. Also given Asus routers are plagued with reoccurring security flaws, blocking the home calling is not a bad idea. The reason is that the more features you enable, or are accessible to the internet, the larger your attack surface is. It means you have more to defend. And one vulnerable feature is all it takes to get hacked. Now attackers know a lot about the security bugs in the system – that’s how they attack. If you go live on the internet with all features turned on, the attacker could have a lot of choices. If you disable unused features, then they'd have less to play with. After more than a month of testing, I have had zero issues, not to mention speed improvements.

It’s cool that you’re interested in security and trying new things, but please don’t use a thread as your diary.

I bet you will see the same speed increase if you turn off all the DPI related stuff, otherwise those processes are just waiting for the response for the PTR lookups you disabled and just wasting CPU cycles. Your scripts look redundant.

It’s cool that you’re interested in security and trying new things, but please don’t use a thread as your diary.

I bet you will see the same speed increase if you turn off all the DPI related stuff, otherwise those processes are just waiting for the response for the PTR lookups you disabled and just wasting CPU cycles. Your scripts look redundant.

Also, title of thread is extremely misleading.

Edit: a letter

Click to expand...

He is free to post as long as he sticks to the topic. You are free to read or ignore. What is misleading about the thread title?