Thanks. So the IllegalStateExceptions? are just flakiness at shutdown, the real problem is the consensus. But I'll change the excption so it doesn't spam the log

I do need to update the hardcoded dirauths and do a new release, hopefully that will fix it. The max consensus age is still way too high, I already lowered it in the code but haven't released that either. See #1220

The plugin is not in good shape right now, it's still really flaky, nobody is maintaining it upstream, and we aren't Tor experts. At one point bitcoinj was maintaining a fork but I think they abandoned it. Some recent discussion is at ​http://zzz.i2p/topics/2031-proposal-bundle-orchid?page=2

I'll try to get a new version out before the .33 release so it will get picked up when the routers upgrade.

I locally updated the consensus list from Tor 0.3.1.8 and it didn't help, can't get a consensus from any of the 9. The furthest any of them get is "Finishing handshake with directory server 10%". Not sure what's going on. For further research.

@mhatta we need to discuss this on IRC, where I gave you some info but haven't heard back.

orchid here != orchid plugin. I will need to release it as a different signer for an existing plugin isn't allowed. I gave you some info on the early 2016 changes and release. You may wish to buy some of those changes as back as I don't believe they are anywhere on github. I also have some changes pending for the next release, some checked-in in late 2017, some not, addressing the issues in this ticket. If you have additional changes please provide a patch. The plugin source is in mtn only right now, but we can get it bridged to github if we can find the right guy to talk to do it. I can also help you with building the plugin.

@zzz, I'm a bit confused by your comment, so try to write my understanding down (sorry for verbosity).

1) I think orchid here == orchid plugin, right? There is Orchid the library/standalone client, and the I2P Orchid plugin. The I2P Orchid plugin contains the source code of the Orchid library under src/java/com/subgraph/orchid, on par with src/main/java/subgraph/orchid in the source code of Orchid library.

2) The latest source code of the Orchid library is available at github repo: ​https://github.com/mhatta/Orchid. The upstream development of Orchid seems ended long ago, so I guess I'm the maintainer for now.

3) The latest source code of the I2P Orchid plugin is available at monotone repo (i2p.plugins.orchid). @zzz is the maintainer who solely can sign the plugin binary (su3) by using scripts/makeplugin.sh. I understand there are your not-committed-yet fixes for the I2P Orchid plugin outside this repo.

4) Until recently, the Orchid library couldn't build the circuit at all (reported at ​https://github.com/subgraph/Orchid/issues/33). It was caused by the upstream introduction of new cert types. This is already fixed in my Orchid library repo, I can provide patches. The code in the current i2p.plugins.orchid doesn't have this kind of fix, but your not-committed-yet patches might have the similar fix.

5) Bug #2079 (of I2P Orchid plugin) might be caused by the aforementioned bug of the Orchid library code included in the current I2P Orchid plugin.

6) I'm not really familiar with monotone, but can use and okay with it now. I obtained i2p.plugins.orchid already.

7) However, I can't build the plugin now. The target "precompilejsp" failed. I'm still investigating.

1-3) true
4-5) Indeed, the pending fixes in my workspace included the certificate change from issue 33. I just checked them in, untested. I'll try to test it soon, please take a look.
6-7) happy to help on IRC

On further research, looks like I was working on this in November and either was having trouble testing, or just got distracted and forgot about it. Hopefully with your help I can get it finished and released.

After not running Orchid for a while, after the previous fix, it has now stopped working. Running for several hours, or restarting the plugin, does not fix the issue.. it steadfastly refuses to connect to the network. Nothing much in the logs save the probable indication that the directory info is stale. INFO […er worker-0] …cuitCreationTask: Cannot build circuits because we don't have enough directory information

Update: Uninstalling Orchid and then reinstalling has the same problem, so probably another directory server update upstream?

Insufficient MANDATORY_CIPHERS causes the failure of the first TLS handshake with Directory Authorities. That's why Orchid now hang up before establishing a circuit

My comments:

We have something similar in i2p, in core/java/src/net/i2p/util/I2PSSLSocketFactory.java, but we use a blacklist to get rid of the weak ciphers. Orchid uses a whitelist for the good ciphers, and what's apparently happened is that the whitelist was so short that there was nothing left.

When you do the socket.setEnabledCipherSuites() call, the list you give it has to match something that the JVM supports, and the far-end of the SSL connection supports. AND it has to be secure. It does NOT have to be a list of everything the JVM supports. Where did you get the list of ciphers to add? From JVM documentation? You included a LOT of insecure ciphers - 3DES, DH_anon, KRB5, NULL (!) - that's not the way to do it.

We want to add ONLY the newer and secure ciphers. The problem is that some new more secure ones got added, and all the ones in the orchid list probably got removed - either disabled by default or removed in the JVM, or removed in Tor. See src/common/tortls.c in the tor source. So we have to figure out which are the good ones, and get rid of the bad ones. That's why we only use a blacklist in java i2p - so we don't prevent the newer ciphers from being used.

I think the orchid code is flawed. According to javadocs ​https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLSocket.html the setEnabledCipherSuites() call must contain only items from the getSupportedCipherSuites() all. That's why the I2P version of this class is a lot more complex than the Orchid version. Orchid never calls getSupportedCipherSuites(). So a huge list of enabled ciphers is problematic not just for security but because if any one of those is not in the JVM the call will fail, according to the javadocs.

Is there a Tor doc that defines the ciphers they use?

I think I'll just use the I2PSSLSocketFactory in the orchid plugin, but needs more research. Haven't tested yet, but will soon.

I've done some preliminary research and read the tor spec talking about behavior with the various TLS versions. I do plan to update the plugin, using the blacklist strategy, but I need to make sure I understand how the fallbacks work and that the spec is followed. I haven't done any code changes or testing yet.

My plan is to finish the work in January, after CCC, and before we release 0.9.38. That way users will pick up the new plugin version when they update their routers.