#2108 closed defect (fixed)

Regular error in router logs: Error decrypting lease

Reported by: Reportage Owned by: zzz
Priority: minor Milestone: 0.9.33
Component: apps/console Version: 0.9.32
Keywords: leaseset decryption Cc:
Parent Tickets:

Description (last modified by Reportage)

Same hash every time, error appears in logs without fail for any given session:

0.9.32 / Linux 4.13 / Oracle Corporation 1.8.0_151 / Jbigi: v3

11/17 ERROR [leTimer2 4/4] net.i2p.data.LeaseSet : Error decrypting lease: [Hash: xxxxxxxx]
     net.i2p.data.DataFormatException: Bad number of leases for decryption
     at net.i2p.data.LeaseSet.decrypt(LeaseSet.java:493)
     at net.i2p.data.LeaseSet.isEncrypted(LeaseSet.java:538)
     at net.i2p.data.LeaseSet.getLeaseCount(LeaseSet.java:207)
     at net.i2p.router.client.ClientConnectionRunner.requestLeaseSet(ClientConnectionRunner.java:820)
     at net.i2p.router.client.ClientConnectionRunner$Rerequest.timeReached(ClientConnectionRunner.java:914)
     at net.i2p.util.SimpleTimer2$1.timeReached(SimpleTimer2.java:147)
     at net.i2p.util.SimpleTimer2$TimedEvent.run2(SimpleTimer2.java:473)
     at net.i2p.util.SimpleTimer2$TimedEvent.run(SimpleTimer2.java:412)
     at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
     at java.util.concurrent.FutureTask.run(FutureTask.java:266)
     at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
     at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
     at java.lang.Thread.run(Thread.java:748)


Change History (11)

comment:1 Changed 16 months ago by Reportage

  • Description modified (diff)

comment:2 Changed 16 months ago by zzz

  • Status changed from new to infoneeded_new

You've probably been playing with 'encrypted leasesets', and you previously entered the hash listed on /configkeyring. But the far-end destination isn't actually encrypting its leasesets, so you can't decode them.

Either remove the entry from the keyring, or configure the far-end to start encrypting (if it's under your control).

If I'm wrong, please provide more info; if I'm right, please close the ticket.

comment:3 Changed 16 months ago by Reportage

  • Status changed from infoneeded_new to new

You're right. The error message threw me. An encryption key was set and then removed for a service, but remained in the keyring. Perhaps the error message can be improved to better reflect the nature of the problem.

This raises another issue, namely easy removal of the offending entry. Elsewhere in the console, a checkbox is provided to remove entries, but here the removal is not as easy as it could be. The hash is truncated which means it can't be cut and pasted into the hash field for removal, requiring a trip to the tunnel manager to identify it. Adding a "mark for deletion" column + checkbox in the keyring table would enhance UX.

No "close ticket" permission, so I'll leave as is.

Last edited 16 months ago by Reportage (previous) (diff)

comment:4 Changed 16 months ago by zzz

  • Component changed from api/crypto to apps/console
  • Milestone changed from undecided to 0.9.33
  • Owner set to zzz
  • Status changed from new to accepted

Agreed that page needs work and I noted those problems also. It also isn't translated. I have another conflicting patch pending, as soon as I get that in I'll work on this one. Reclassifying as console. Will also tweak the log message.

comment:5 Changed 16 months ago by zzz

  • Resolution set to fixed
  • Status changed from accepted to closed

Deletion was broken, it would delete in-memory but not from the config, so it would come back after restart. So probably wasn't a user error.
Also display dests as b32, not hash. Better error messages. Don't truncate. Remove trailing spaces which caused errors after copy/paste. Reverse lookup to name in more cases. Tag table headers for translation. Parameterize messages for better translations.
In 3912b44f417d9e44bbdc12ff276653d2fa3975c1 0.9.32-10.
Better log messages in 5db058582969e35d3ef5b2605c64830b92c5d62b 0.9.32-10.

comment:6 Changed 16 months ago by Reportage

  • Resolution fixed deleted
  • Status changed from closed to reopened

Looks like removing by name doesn't work, from a cursory check.

comment:7 Changed 14 months ago by zzz

Added 'encrypted' note on encrypted leasesets on the netdb leaseset tab in bbd4dfddd810a41e165410e75526e2e4f53cd2e3 to be 0.9.32-20

comment:8 Changed 14 months ago by zzz

Removing by name claimed fixed in 0.9.32-10, works for me on 0.9.32-19. Please retest and provide version.

comment:9 Changed 14 months ago by Reportage

Version: 0.9.32-20

Steps to reproduce:

  • Enable encrypted leaseset for eg. default web server tunnel
  • Start tunnel, verify that encryption key is present for destination on /configkeyring
  • Attempt to delete key by a) supplying name of service (copy and paste from keyring) -> Invalid destination b) supplying name of service + encryption key (copy and paste from keyring) -> Invalid destination

This process would be much simpler if the keyring table had a delete column and would also allow for deleting multiple keys at the same time, as well as conforming to the informal UI style guide for deletion of entries in the console. It would also clarify the stated purpose of the "Manual Keyring Addition" section.

comment:10 Changed 14 months ago by zzz

Ok thanks for that.
There's a few things going on here.
The /configkeyring page says:
Enter keys for encrypted remote destinations here. Keys for local destinations must be entered on the I2PTunnel page.

You apparently did that by setting encryption for a local destination over in the hidden services manager, aka i2ptunnel.
Then you tried to delete it on /configkeyring, not by disabling it over in i2ptunnel.

That's not the right way to do it, it's implied you would remove it where you add it, but we don't exactly say that.

We also don't show on /configkeyring what's local and what isn't.
Even worse, even if you do disable it over in i2ptunnel (or just stop the tunnel), it isn't removed from the keyring.

Fix for all this in progress.

Your suggestions for a delete column are reasonable, but the whole encrypted leaseset feature is cryptographically insecure and best avoided. Until it's completely redesigned we probably won't put a lot more effort into it.

comment:11 Changed 14 months ago by zzz

  • Resolution set to fixed
  • Status changed from reopened to closed

Separate local and remote dests on /configkeyring
Prohibit local changes on /configkeyring
Remove local keys from keyring on tunnel shutdown or encryption disable
Ensure subsession encryption setting matches primary session
In 649e37e94d7bcbfae38d625f41a3f1b190f8be02 0.9.32-21

Note: See TracTickets for help on using tickets.