1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
Dismiss Notice

Welcome To SNBForums

SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.

If you'd like to post a question, simply register and have at it!

While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!

pixelserv - Jarmka's thread

Discussion in 'Asuswrt-Merlin' started by jarmka, Jun 4, 2018.

  1. jarmka

    jarmka Occasional Visitor

    Joined:
    May 5, 2018
    Messages:
    36
    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.

    #1 ssllabs/ssllabs-scan#367

    As explained in the second link below,
    #2 https://timtaubert.de/blog/2014/11/...-side-tls-session-resumption-implementations/

    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.
     
    Last edited: Jun 4, 2018
  2. Please support SNBForums! Just click on this link before you buy something from Amazon and we'll get a small commission on anything you buy. Thanks!
  3. jarmka

    jarmka Occasional Visitor

    Joined:
    May 5, 2018
    Messages:
    36
    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/

     
    Last edited: Jun 4, 2018
  4. jarmka

    jarmka Occasional Visitor

    Joined:
    May 5, 2018
    Messages:
    36
    Does Pixselserv-tls keep its own TLS session tickets or does it strictly use open connections of a given application?
     
  5. kvic

    kvic Part of the Furniture

    Joined:
    Aug 11, 2014
    Messages:
    2,319
    Location:
    22.4399N 114.2222E
    @jarmka

    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.
     
  6. jarmka

    jarmka Occasional Visitor

    Joined:
    May 5, 2018
    Messages:
    36
    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.
     
    Last edited: Jun 5, 2018
  7. kvic

    kvic Part of the Furniture

    Joined:
    Aug 11, 2014
    Messages:
    2,319
    Location:
    22.4399N 114.2222E
    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.
     
    visortgw likes this.
  8. jarmka

    jarmka Occasional Visitor

    Joined:
    May 5, 2018
    Messages:
    36
    @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.

     
    Last edited: Jun 6, 2018
  9. DonnyJohnny

    DonnyJohnny Very Senior Member

    Joined:
    Dec 17, 2017
    Messages:
    608
    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.
     
  10. kvic

    kvic Part of the Furniture

    Joined:
    Aug 11, 2014
    Messages:
    2,319
    Location:
    22.4399N 114.2222E
    No, that's not true.

    "Non ad requests" are colloquial use. More precisely any domains that do not exist in your DNS-based adblock list will not have their requests to such domains being redirected to pixelserv-tls.

    You shall run pixelserv-tls with log LEVEL 4, and see first hand what sorts of domains and requests reaching pixelserv-tls.
     
  11. jarmka

    jarmka Occasional Visitor

    Joined:
    May 5, 2018
    Messages:
    36
    @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.
    Code:
    Jun  6 08:19:25 pixelserv-tls[13913]: 192.168.50.2 rgom10-en.url.trendmicro.com:80 GET /T/88/s4lP0xpMJNJ37bWI-poXwM82KxYcTiMp5aToJ0dkdOt8ZhlY-D8TBsI_fNdAdo8X8Ap00HKmGzBKz8z1jQ7eVQ== HTTP/1.1
    Jun  6 08:19:26 pixelserv-tls[13913]: 192.168.50.2 rgom10-en.url.trendmicro.com:80 GET /T/88/88ag54SqhI4cLLSxuvhedkLT5yHjG0Kj0KO-fermCl5MUngtPrLlU3_gHevW-zpDvNK3emDKHL56UIVZb9Tiyw== HTTP/1.1
    Jun  6 08:19:26 pixelserv-tls[13913]: 192.168.50.2 rgom10-en.url.trendmicro.com:80 GET /T/88/K3Fj_R_ThIKDUnsc33Efd9rFzqk_x7g6iP1pZs9UtF8-pzkAVo3MDcSdaTB9zVkyWoo6_0O7OiFCEoRwuuAupg== HTTP/1.1
    Jun  6 08:19:27 pixelserv-tls[13913]: 192.168.50.2 rgom10-en.url.trendmicro.com:80 GET /T/108/SzdtnQEMxiDD6aFrA2Lyht1ru0SlzdMceIBpMj8jwVsd69ahL0BebEsThQ33529D6OltpDVBhhr5idNr9eWuJ701DUL_o7IHblbDIvKj9cg= HTTP/1.1
    Jun  6 08:19:31 pixelserv-tls[13913]: 192.168.50.2 rgom10-en.url.trendmicro.com:80 GET /T/108/-CQeiAUqKPl-jjEYboyR0FAQTarOyDTWvCLMA0BfFy6pVMC8tjmOZYnUi9QQUdMTInKbeNINVaEmmJgWnn8cxVuLodKIGNroeg4NSTH7vr8= HTTP/1.1
    Jun  6 08:19:32 pixelserv-tls[13913]: 192.168.50.2 rgom10-en.url.trendmicro.com:80 GET /T/88/c1Ior4qBFSx14ThXfRtvF6MPYWycBPE3NABUcKQeSK5wIhfTdg_LtiT2q4jWeA4lxSqol_hBnPUNJmiHnBTPyA== HTTP/1.1
    Jun  6 08:19:33 pixelserv-tls[13913]: 192.168.50.2 rgom10-en.url.trendmicro.com:80 GET /T/88/vbvVDVsL32vmKdpyjAPMyUCnrlIbkM4Tl9ryfclmhY5jAnCi0nMpB7cmOxjRPcc9hlfod4eJSBvmHU6h7XU4Wg== HTTP/1.1
    Jun  6 08:19:34 pixelserv-tls[13913]: 192.168.50.2 rgom10-en.url.trendmicro.com:80 GET /T/108/zZvF7dBiaNYQJHRro6vjMM9ijysPnXPIG716VmAfHSlRTqB7pLpJSCu09Uc7e_mU-ahnkRNKz0mzG6v5Z-MEkp9ieIfd0k9Dq_eot_6Nsgo= HTTP/1.1
    
     
    Last edited by a moderator: Jun 6, 2018
  12. kvic

    kvic Part of the Furniture

    Joined:
    Aug 11, 2014
    Messages:
    2,319
    Location:
    22.4399N 114.2222E
    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).
     
  13. jarmka

    jarmka Occasional Visitor

    Joined:
    May 5, 2018
    Messages:
    36
    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.

    Create/Add to bottom of /jffs/scripts/dnsmasq.postconf
    Code:
    ################################################
    ####   Block PTR on localhost, allow PTR for Clients
    ################################################
    
    CONFIG=$1
    source /usr/sbin/helper.sh
    sed -i '$a\ ' $CONFIG
    sed -i '$a\###############################################' $CONFIG
    sed -i '$a\#Block PTR on localhost, allow PTR for clients#' $CONFIG
    sed -i '$a\###############################################' $CONFIG
    sed -i '$a\ ' $CONFIG
    sed -i '$a\####################################' $CONFIG
    sed -i '$a\#May Speed up Browsing Considerably#' $CONFIG
    sed -i '$a\####################################' $CONFIG
    sed -i '$a\ ' $CONFIG
    pc_append "server=/0.168.192.in-addr.arpa/#" $CONFIG
    pc_append "server=/in-addr.arpa/" $CONFIG
    pc_append "#Or block all arpa for added security (may break QoS! I use this, and disable QoS)" $CONFIG
    pc_append "#bogus-priv" $CONFIG
    pc_append "#server=/arpa/" $CONFIG
    
    To confirm this worked, simply type dnsmasq, and hit 'enter' while watching your dnsmasq logs in ab-solution for the following:
    Block AsusWRT built in signaling to Trendmicro, Google & other entities:
    Create/Add to bottom of /jffs/scripts/hosts.postconf
    Code:
    #!/bin/sh
    
    #################################################
    #### Block Trendmicro / Asus / Google / Other Entities
    #################################################
    
    ######################################################
    #### Block redundant NXDOMAIN dnsmasq querys and logs
    ######################################################
    
    # Blocks most 10-14 second reoccurring querys to google
    # Blocks all reoccurring querys to Asus / Trend Micro / Google.com
    # Stops redundant logging for cleaner logs if blocking trendmicro, and google
    
    ####################################################################################
    # 1. Note, repeated querys to google safe browsing servers become apparent if:
    # (A) The items listed below have been blocked by dnscrypt or dnsmasq
    # (B) You've compiled and blocked whatever unique suspicious entries appear for you in dnscrypt.
    # (C) You disable in-addr.arpa (PTR/Reverse DNS altogether for localhost) (recommended)
    # This will break DNS name resolutions in AsusWRT apps like itfop; And possibly some websites
    # Alternatively you may selectively block IP's collected from dnscrypt suspicious.log via dnsmasq hosts
    # Rebooting the router with suspicious entry logs enabled will give you the list.
    #
    # 2. Note, repeated AsusWRT probes to google.com become apparent only when blocking AsusWRT querys to google
    # safe browsing; the only solution for this without breaking google.com is a custom host entry in dnsmasq
    # as provided here.
    #
    # Exact order of reoccurring query's found in dnscrypt blocked.log after compiling hundreds of entries from
    # suspicious.log and importing them to blacklist.txt
    #
    # 144.159.185.198.in-addr.arpa AT&T Services, Inc https://otx.alienvault.com/indicator/ip/144.159.185.198
    # 145.159.185.198.in-addr.arpa RIPE Network Coordination Centre
    # 145.23.49.198.in-addr.arpa   RIPE Network Coordination Centre
    # 217.197.79.204.in-addr.arpa  RIPE Network Coordination Centre
    # 91.149.5.103.in-addr.arpa    RIPE Network Coordination Centre
    # 134.84.85.88.in-addr.arpa    University of Minnesota, Office of Information Technology
    # 144.23.49.198.in-addr.arpa   Latin American and Caribbean IP address Regional Registry
    # 133.36.101.151.in-addr.arpa  JAPAN-INET Asia Pacific Network Information Centre
    # 84.36.101.151.in-addr.arpa   RIPE Network Coordination Centre
    # 42.40.189.107.in-addr.arpa   JAPAN-INET Asia Pacific Network Information Centre
    # rgom10-en.url.trendmicro.com
    #####################################################################################
    
    #Ensure AB-Solution is Installed:
    #Code /usr/sbin/curl -Os https://raw.githubusercontent.com/decoderman/amtm/master/amtm && sh amtm
    #Make sure to ping google.com and replace IP with local version under the first pc_append line
    
    CONFIG=$1
    source /usr/sbin/helper.sh
    sed -i '$a\#' $CONFIG
    sed -i '$a\## begin of silently block all redundant querys to Google, TrendMicro, and Asus ##' $CONFIG
    pc_append "74.125.205.147 google.com" $CONFIG
    pc_append "192.168.50.2 rgom10-en.url.trendmicro.com" $CONFIG
    pc_append "192.168.50.2 fbsv1.trendmicro.com" $CONFIG
    pc_append "192.168.50.2 fbsv2.trendmicro.com" $CONFIG
    pc_append "192.168.50.2 ntd-asus-2014b-en.fbs20.trendmicro.com" $CONFIG
    pc_append "192.168.50.2 gslb1.fbs.trendmicro.com.akadns.net" $CONFIG
    pc_append "192.168.50.2 rgom10-en.url.trendmicro.com" $CONFIG
    pc_append "192.168.50.2 trendmicro.com.edgesuite.net" $CONFIG
    pc_append "192.168.50.2 slb1.fbs.trendmicro.com.akadns.net" $CONFIG
    pc_append "192.168.50.2 activeupdate.trendmicro.co.jp" $CONFIG
    pc_append "192.168.50.2 backup21.url.trendmicro.com" $CONFIG
    pc_append "192.168.50.2 wrs.trendmicro.com" $CONFIG
    pc_append "192.168.50.2 e5110.dscd.akamaiedge.net" $CONFIG
    pc_append "192.168.50.2 wideip-dlcdnets.isoi.asia" $CONFIG
    pc_append "192.168.50.2 dlcdnets.asus.com" $CONFIG
    pc_append "192.168.50.2 dlcdnets-ds.asus.com.edgekey.net" $CONFIG
    sed -i '$a\## end of Silently Block All Redundant Querys to Google, TrendMicro, and Asus ##' $CONFIG
    sed -i '$a\#' $CONFIG
    
    These first two "codes" have reportedly attended massive speed improvements.
     
    Last edited: Jun 10, 2018
  14. Adamm

    Adamm Very Senior Member

    Joined:
    Mar 26, 2013
    Messages:
    1,634
    Please don’t hijack others threads with a copy and paste of your own, common courtesy.
     
  15. Beherit

    Beherit Regular Contributor

    Joined:
    Sep 19, 2016
    Messages:
    87
    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.
     
    mrchow likes this.
  16. jarmka

    jarmka Occasional Visitor

    Joined:
    May 5, 2018
    Messages:
    36
    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
     
    Last edited: Jun 10, 2018
  17. Beherit

    Beherit Regular Contributor

    Joined:
    Sep 19, 2016
    Messages:
    87
    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.
     
    Last edited: Jun 10, 2018
  18. joe scian

    joe scian Regular Contributor

    Joined:
    Apr 22, 2018
    Messages:
    79
    yes I will report too - what a load of BS - no changes in speed whatsoever - if anything there is a speed decrease
     
    Last edited: Jun 16, 2018
  19. jarmka

    jarmka Occasional Visitor

    Joined:
    May 5, 2018
    Messages:
    36
    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.
     
    Last edited: Jun 14, 2018
  20. kfp

    kfp Very Senior Member

    Joined:
    Jun 26, 2014
    Messages:
    708
    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
     
    Last edited: Jun 14, 2018
  21. thiggins

    thiggins Mr. Easy Staff Member

    Joined:
    May 18, 2008
    Messages:
    13,538
    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?
     
    Beherit likes this.
Please support SNBForums! Just click on this link before you buy something from Amazon and we'll get a small commission on anything you buy. Thanks!