[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2861: SSL handshake failure with 1.12 storage nodes over I2P

[Tahoe-LAFS]

#2861: SSL handshake failure with 1.12 storage nodes over I2P
--------------------------+--------------------
     Reporter:  str4d     |      Owner:
         Type:  defect    |     Status:  new
     Priority:  critical  |  Milestone:  1.12.1
    Component:  unknown   |    Version:  1.12.0
   Resolution:            |   Keywords:
Launchpad Bug:            |
--------------------------+--------------------

Comment (by warner):

 Huh, I don't know what that could be. My hunch is that the I2P connection
 is not really established, and the negotiation messages are getting
 dropped or corrupted somehow.

 Let's try to extract more information from foolscap:

 * shut everything down
 * start your Introducer
 * start your client node
 * `flogtool tail -s out.flog CLIENTNODEDIR/private/logport.furl`
 * start a 1.12.0 storage node

 When the storage node's announcement arrives (via the Introducer), the
 client will attempt to connect, and will record some of the negotiation
 process into `out.flog`. We're looking for deviations from the usual
 negotiation process, maybe something about an expected message not being
 seen.

 If that doesn't yield anything immediately useful, the next step will be
 to modify the foolscap code on both sides and have them log everything
 they get over the connection. It'd be interesting to know whether they
 make it far enough to switch to TLS (and it's really the TLS handshake
 that's getting broken), or if something goes awry before that point (when
 they're still speaking HTTP-ish).

 For background, Foolscap starts by making a plain TCP connection, then
 exchanges a very HTTP-like request and response, then both sides are
 supposed to do `.start_tls()`. So the connecting host will send `GET
 /id/$tubid HTTP/1.1` and some headers (including `Upgrade: TLS/1.0`) and a
 double-newline and then the very next byte will be the TLS negotiation
 (maybe CLIENTHELLO?). The receiving host will send `HTTP/1.1 101 Switching
 Protocols` and some headers and a double-newline and then start on the TLS
 bytes.

 Foolscap is expecting the connection it gets to be 8bit-clean and
 transparent. Can you think of any reason why the I2P proxy might be
 interpreting HTTP-like data inside the connection and maybe modifying the
 data or its behavior in response to what it sees?

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2861#comment:1>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage