#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: Sensitive: no

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)

Subtickets

Change History (11)

comment:1 Changed 21 months ago by Reportage

Description: modified (diff)

comment:2 Changed 21 months ago by zzz

Status: newinfoneeded_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 21 months ago by Reportage

Status: infoneeded_newnew

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 21 months ago by Reportage (previous) (diff)

comment:4 Changed 21 months ago by zzz

Component: api/cryptoapps/console
Milestone: undecided0.9.33
Owner: set to zzz
Status: newaccepted

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 21 months ago by zzz

Resolution: fixed
Status: acceptedclosed

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 21 months ago by Reportage

Resolution: fixed
Status: closedreopened

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

comment:7 Changed 20 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 20 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 20 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 20 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 20 months ago by zzz

Resolution: fixed
Status: reopenedclosed

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.