Hi Sage, Haomai, I think we should put the encrytion request into the handshake, for this will make sure all the data will be encrypted after the request. AFAIK, openssl negotiate the cipher-suit(like ECDHE-ECDSA-AES256-SHA) and the private key during the handshake stage before it sends real data, and the handshake is protected by the certificate. So what you said make sense to me, and seems that we use AES-128 to encrypt the real data, we don't need the openssl crypto library, forgive me my stupid question about openssl :). I need to spend some time to get familiar with cephx and other code in src/auth, and try to write a proposal when the student application peroid opens. If you have anything suggestion, I'd appreciated if you told me :) On Fri, Mar 11, 2016 at 10:20 PM, Sage Weil <sage@xxxxxxxxxxxx> wrote: > On Fri, 11 Mar 2016, Haomai Wang wrote: >> On Fri, Mar 11, 2016 at 1:38 PM, John Hunter <zhjwpku@xxxxxxxxx> wrote: >> >> > Hi sage, >> > >> > At a quick look at the ceph codebase, the cryptographic handshake is >> > handled >> > by the Pipe class(I might be wrong), it not using the openssl handshake >> > and not >> > using the openssl crypto library. I am wondering when we encrypt the actual >> > data, are we going to implement our own encrypt functions? >> >> We could define a new feature in connection handshake, init side could take >> a enanble/disable flag to make server side decided. If both side agreed >> with encrypt, the connection can encrypt each message later or we need to >> have a new encrypt info exchange step into original handshake process. > > Take a look at > > https://github.com/ceph/ceph/blob/master/src/msg/simple/Pipe.cc > > The initial exchange is a ceph_msg_connect sent from client->server, and a > ceph_msg_connect_reply response. The request includes the > cephx authorizer, and by the time we get the response, both client and > server share a session key (derived from the shared secret and a nonce) > that we can use to encrypt. > > The features aren't encrypted, so in theory at MITM could twiddle those, > *but* they can't tamper with the cephx authorizer and response without > breaking the security handshake. I think this may be broken in the > current handshake, actually, since we use the connection features to > decide whether to sign messages. The features probably need to go in the > authorizer, or in something signed by the authorizer. > > Anyway, both sides know that the other supports encryption, if one of > them wants to encrypt, they can send a tag > > https://github.com/ceph/ceph/blob/master/src/include/msgr.h#L77 > > indicating that all further messages sent are encrypted. A similar tag > (or the same tag) could request that the other end do the same. > The bit I worry about here is that the other end may have already started > sending other messages before it gets the 'please encrypt outgoing > messages' tag. So maybe we need to incorportate the request into the > authorizer itself so that it's part of the initial cephx handshake.. > > What do you think? > > sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
