Thanks for the tip. I'll try asap. And report back on it. Its an experimental system. The idea is to build two layers of security, one of it is going to be vulnerable, while the other is supposed to be secure. In the end the system is going to be a playground for security students.
Regards Eduard 2012/6/10 Tomer Filiba <[email protected]> > well, i can't think of a reason for this off the top of my head, but try > passing _lazy = True, and then call _init_service() > for example, see > https://github.com/tomerfiliba/rpyc/blob/LTS3.2/rpyc/utils/server.py#L191 > > i'm not sure if it's even related to the cyclic initialization of the rpyc > connection (which is what _lazy aims to solves), > but perhaps it would do the trick. > > by the way, if you're working over ssh, why would you require further > encryption? ssh is authenticated and encrypted, > and you can always just create a distinct id file for the sake of your > service, so not anyway who can access your machine > could access the service. why overlay further encryption over it? > > > ----------------------------------------------------------------- > > *Tomer Filiba* > tomerfiliba.com <http://www.facebook.com/tomerfiliba> > <http://il.linkedin.com/in/tomerfiliba> > > > > On Sun, Jun 10, 2012 at 10:55 AM, Eduard <[email protected]> wrote: > >> Hi! >> >> I ran in to something curious, but could not find any info on it so I >> thought I'll ask. >> If there are related posts, please point me to the as my search engine >> skills seem to have been insufficient to find them. >> >> Ok lets go. >> Problem Setting: >> Client C wants to authenticate with Server S using a password to decrypt >> a transmitted random, The password is provided by the user, C authenticates >> and returns the root object of S. >> >> First C establishes a connection with S using rpyc.ssh_connect(sshctx, >> port, service=CustomCallback,config = {"allow_public_attrs" : True, >> "allow_all_attrs" : True} >> >> To get the socked used by my rpyc connection I do: >> fd = connection.fileno() >> sock = socket.fromfd(fd, socket.AF_INET, socket.SOCK_STREAM) >> >> So then C does: >> *snip* >> def authenticate_with_blowfish(key, iv, sock): >> blowfish = Blowfish.new(key, Blowfish.MODE_CBC, iv) >> time.sleep(1) >> b64_encrypted_b64 = sock.recv(2048) >> >> encrypted_b64 = base64.b64decode(b64_encrypted_b64) >> b64 = blowfish.decrypt(encrypted_b64) >> >> sock.send(b64) >> *snip* >> >> On the Server Side there is an authenticator listening which has been >> adapted with functools.partial to be accepted by rpyc: >> >> def blowfish_authenticator_partial(key,iv,sock): >> >> blowfish = Blowfish.new(key,Blowfish.MODE_CBC, iv) >> random = Random.get_random_bytes(1024) >> >> randomB64 = base64.b64encode(random) >> cipher = blowfish.encrypt(randomB64) >> cipherB64 = base64.b64encode(cipher) >> >> sock.send(cipherB64) >> >> replyB64 = sock.recv(8188) >> decodedReply = base64.b64decode(replyB64) >> >> if decodedReply == random: >> return [sock, None] >> >> raise AuthenticationError >> >> Ok. My question is: Why is the time.sleep(1) necessary? I could not get >> it working without it but with it this code works like a charm. If I put in >> debug statements all statements before the first socket send/recv are >> printed. >> >> I run in to a similar problem a second time: >> in pseudocode: >> authenticate_connection(c) >> print c.root >> #will fail while >> authenticate_connection(c) >> time.sleep(1) >> print c.root >> #will work >> >> My test setting: >> 2 VM's running Ubuntu 12.04 Server >> python 2.7.3 >> rpyc v3.2.1 >> >> Ok. This got rather lengthy but I wanted to give a description which is >> as detailed as possible. >> This is not intended as bug report, I am just curious as to why this >> behavior occurs. >> Thanks for taking the time to read through this. >> >> Regards >> Eduard >> >> >> >
