Bill Frantz wrote:
> At 10:55 PM 11/8/1999 +0000, Ben Laurie wrote:
> >Bill Frantz wrote:
> >> In the E protocol, you start with the hash of the public key of the vat you
> >> want to connect to. The handshake passes the public key, and the receipent
> >> checks the hash to ensure that it is talking to the right vat.
> >> What I couldn't see at the time was how to perform this validation,
> >> particularly with a commercial SSL. (See below)
> >OK, but it is, in fact, trivial, since the whole purpose of a cert is to
> >convey the public key. I presume you now do see that?
> What I couldn't see was how to fish the key out thru the SSL APIs. :)
Ah, well, I haven't tried that but I'm sure it is entirely possible with OpenSSL. And if it isn't, I'll make it possible. :-)
> >> >"Client Server vs. Peer to Peer" - it seems to me this is meaningless.
> >> >Each peer acts as a client when it initiates a connection and a server
> >> >what it receives one. SSL is used in the obvious way in each case.
> >> In the EC Habitats beta, which used the immediate predesesor to the E
> >> datacomm protocol, we had major problems with both sides trying to connect
> >> at the same time. To ensure the correct ordering of messages, we need to
> >> end up with only one connection. While I am far from an SSL expert, I
> >> don't know anything in SSL that deals with this situation. There is a fair
> >> amount of hair in the E connection setup protocol to handle just this
> >> situation.
> >There's nothing in SSL to deal with this situation, since its out of
> >scope. I don't see why higher layers couldn't deal with it, though.
> >BTW, what about "highest hash is the server" as a simple way to ensure
> >the connections are one-way?
> That is what the datacomm connection protocol ends up doing. Before the
> connection is completed, and therefor used, it detects that an incoming
> connection is from a vat it is trying to connect to. In some cases it is
> obvious which connection to flush. In others, the hash is used to delegate
> one of the vats as the one to select the connection to keep. I still get a
> headache thinking about the problem.
Not sure I see why. But...
> I think in SSL, the receiving (server) end, needs to decide to keep or
> reject a connection before the creating (client) end sends any Pluribus
> messages over it.
OK, so are there any remaining reasons that SSL isn't a good fit for the problem?
-- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi