I would advice against using Proxifier on Java programs. My experience is that it causes high CPU usage, stops working after a while, or simply doesn't work at all. You can instead set a proxy by passing the appropriate command line parameters to the Java VM, for example:
Code:
javaw.exe -DsocksProxyHost=127.0.0.1 -DsocksProxyPort=8080 -DsocksProxyVersion=5 -Dsocks.nonProxyHosts="127.0.0.1|localhost" -jar YourProgram.jar
HTTP, HTTPS and even FTP proxies can also be set by editing "socks" accordingly and removing the socksProxyVersion, but may get ignored depending on how requests are done, whereas SOCKS are always used for all TCP connections. Therefore I recommend running your interceptor proxy in SOCKS mode (don't know if Fiddler can do that). DNS lookups are always performed locally in this case and there is no flag to control that, which is not a problem here since the proxy is running on the same computer, but could be in other usage scenarios. Workarounds exist.
Code:
# In Java 9 and above you can add this to make local lookups always fail and "fall back" to remote ones...
-Djdk.net.hosts.file="nul"
# For Java 8 and below this may work, but I haven't tested it.
-Dsun.net.spi.nameservice.nameservers=0.0.0.0 -Dsun.net.spi.nameservice.provider.1="dns,sun"
Now you have to deal with the fact Java doesn't use the system's certificate store, so it won't trust the Fiddler root CA even if it's installed there. In the past, the -Dtrust_all_cert=true parameter was a quick and dirty way to solve this by always accepting any certificate, but it doesn't seem to exist anymore, so you must use keytool to create a custom key store, then tell Java to use it instead of the default one. Edit paths accordingly.
Code:
"%JAVA_HOME%\bin\keytool.exe" -importcert -noprompt -file "C:\Fiddler\FiddlerRoot.cer" -keystore "%CD%\fiddler-keystore" -storepass "123456"
javaw.exe -DsocksProxyHost=127.0.0.1 -DsocksProxyPort=8080 -DsocksProxyVersion=5 -Dsocks.nonProxyHosts="127.0.0.1|localhost" -Djdk.net.hosts.file="nul" -Djavax.net.ssl.trustStore="fiddler-keystore" -Djavax.net.ssl.trustStorePassword="123456" -Dcom.sun.net.ssl.checkRevocation=false -Docsp.enable=false -jar YourProgram.jar
However, there are two important facts that should be mentioned.
- Normally, you'll be running one program able to "talk" HTTPS directly to the intercepting proxy. But in this situation, we have two (a BitTorrent client, then ProxyFake, then said proxy) and ProxyFake cannot or does not use secure protocols in any way. The only way to work around this is editing all tracker announce URLs in your client to use HTTP, then having Fiddler or whatever rewrite them back to HTTPS as necessary, deciding that necessity through some criteria defined in advance (e.g. Host header, destination port if not 80), and always returning plaintext responses. The idea is making both client and ProxyFake only deal with nonsecure HTTP, the one supported protocol both have in common, whereas your interceptor is the one actually communicating with trackers using HTTPS.
- Because of the previous point, you wouldn't actually need to install the root certificate into Java's store like I mentioned before, as it won't be used for anything.
As you can see, this setup takes a lot of work and has plenty of room for error. I recommend forgetting about it and using BiglyBT Extreme Mod or RatioMaster Plus, both of which have full TLS support. mRatio only supports version 1.0, and my fix for that involves automating something (almost) as crazy as what I said above, in addition to working around a couple of bugs in mRatio itself.
Reply With Quote
Bookmarks