Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

poc: add embedded proxy to grab external cookies #7643

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ngosang
Copy link
Member

@ngosang ngosang commented Mar 14, 2020

First of all, the code is s**t I know. I want to get some feedback before spending my time on this.

This PR embedded a proxy server into Jackett with the goal of grabbing the cookies directly from the web browser.

Configuration:

  1. Start Jackett as usual (Jackett port 9117, Proxy port 8000)
  2. Add Jackett CA jackattCA.pem into the trusted CAs in the web browser. In Firefox:
    image
  3. Configure the web browser to use Jackett as proxy. In Firefox:
    image
  4. Open one tracker in the web browser. You will see the cookies in Jackett console.
Now listening on: http://[::]:9117
Application started. Press Ctrl+C to shut down.
host: iptorrents.com cookie: __cfduid=dbdbc6c1bdcb ...
host: www.torrentleech.org cookie: member_id=59 ...
host: alpharatio.cc cookie: session=qYt27wijCpGNpdl ...
  1. You can use these cookies to configure the trackers in Jackett.

Pros:

  • It's lightweight and doesn't have external dependencies. Selenium or other approaches requires a full browser to do the same
  • Should work for all sites HTTP / HTTPS. You can use it to navigate in non torrent sites, but that's not the goal
  • Can be configured to use the same Proxy/VPN that Jackett uses
  • Only grab the cookies for the sites supported by Jackett (this could be improved)
  • I remember some users complaining about they copied the cookie from the browser but it's not working in Jackett because they are running in different machines with different IPs. The proxy solves this problem because all connections are routed by Jackett (proxy requests and torrent searches)

Cons:

  • The user has to configure the proxy and import the CA in the browser. This feature can be disabled, so most users don't have to do anything.

Notes:

  • I know, I know, you are wondering about the CA... In simple words, we need the CA to decrypt HTTPs traffic. When you use a regular proxy, the proxy is not able to see the content of the HTTPs traffic. If it tries to decrypt or modify the traffic, the browser will notice and you will see a security error in the page. Importing our own CA, the browser will trust us and we can sniff the traffic.
  • This is just a POC, but we can automate all the process. Eg, the user configures the proxy and navigate through several torrent pages. We can detect the torrent sites, get the cookies and configure the trackers automatically in Jackett. The cookie is all we need for all the trackers. This will require several changes in the code.
  • The proxy could be disabled in the Web UI,

@Jackett/maintainers What do you think?

@cadatoiva
Copy link
Collaborator

The private key is included in our public source? Haven't looked at the whole PR yet, but that seems like a huge red flag.

@cadatoiva
Copy link
Collaborator

I've looked at it some more, and there's also a .pfx file added? These are usually huge security no-no's. If we decide to add this, it would probably be better for Jackett to generate these from scratch for the local installation instead of having a global cert.

The rest of the implementation looks fine, but I don't know if this is the best way to implement this fix. Most of these people needing this will be running non-windows servers/seedboxes/etc. which means that there's likely some version of SSH on the box for administration/tool installation, which can be used to generate a socks proxy for the same purpose. https://www.systutorials.com/proxy-using-ssh-tunnel/

@JeffCarpenter
Copy link

Very interesting proof of concept.. I wonder if a decoupled implementation might work well, ie. with a cookie jar that Jackett reads from and the proxy writes to

@ngosang
Copy link
Member Author

ngosang commented Mar 14, 2020

The private key is included in our public source? Haven't looked at the whole PR yet, but that seems like a huge red flag.

I've looked at it some more, and there's also a .pfx file added? These are usually huge security no-no's. If we decide to add this, it would probably be better for Jackett to generate these from scratch for the local installation instead of having a global cert.

This is just a POC. In the real implementation the pfx (private + public key) will be generated in the client machine, the same as the apikey. And the pem (public key) will be downloaded from the WebUI so it can be installed in the web browser. This implementation can be safe, I have a lot of experience in security. The code to generate the certificates is already in the PR => https://github.com/Jackett/Jackett/pull/7643/files#diff-85a043c4864ef296e6b4a81909451893R43

Most of these people needing this will be running non-windows servers/seedboxes/etc. which means that there's likely some version of SSH on the box for administration/tool installation, which can be used to generate a socks proxy for the same purpose.

There are several ways of grabbing the cookies but I think this is easier for the average user. This feature will include 3 things: Installing a proxy + auto copy the cookies + auto configure the trackers.

Revert "poc: add embedded proxy to grab external cookies"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants