Make the whole RPC Connection on SSL

[Belphemur]

Everything now use SSL.

[djamps]

Hi,

Could you clarify exactly what was done with the subroutines in 58fb1ee ? I'm having a hard time following. Also, have you compared throughput between SSL/non-SSL? I am thinking it might be a good idea to be able to toggle SSL for those using local/secure networks for throughput reasons. Thanks.

[Belphemur]

Hello,

You're right, the subroutine shouldn't have been deleted. I re-added them.
What I had to change was the way the get_ref was working.

The get_record_by_XXX doesn't seem to work on Xen Server 6.2, it was always returning no result instead of the wanted VM.
I found the grep code in the latest version of the Xen::API lib you're using. I'm gathering all the records for the wanted resource, then filter it to only keep the wanted one where either the name_label matches or the uuid or the reference.

In this day and age, SSL should be the default, all the Xen are running the stunnel to provide SSL, the overhead is only for the connection and for this kind of application shouldn't influence the throughput.

[Belphemur]

I disabled by default the use of SSL for the transfer itself, only use it for the RPC connection (which send the password).

This way, we gain some security for the credentials and basic commands, but keep the normal speed for the transfer itself.

it's the new -ssl flag that can be use to make the transfer use SSL.

[Belphemur]

Hello, Sorry to bother you again but we took the time to test the throughput of the SSL configuration. You were right, using SSL for the transfer cut it by a factor of 5, instead of 30-50Mbps or​ we got 5-10. The perl process takes a full core doing the heavy lifting of encrypting decrypting and both server have a heavy load on the stunnel process reducing their processing speed for the transfer itself. With this patch, all the rpc action use SSL and the transfer is by default not encrypted. This way we reach the same speed as you recorded in your blog and have a layer of security for the credentials. The user can use the -ssl flag to activate the encryption for the transfer. ⁣Sent from BlueMail ​

…

On Feb 1, 2017, 12:48, at 12:48, djamps ***@***.***> wrote: Hi, Could you clarify exactly what was done with the subroutines in 58fb1ee ? I'm having a hard time following. Also, have you compared throughput between SSL/non-SSL? I am thinking it might be a good idea to be able to toggle SSL for those using local/secure networks for throughput reasons. Thanks. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #7 (comment)

[djamps]

Sounds good - let me know when you feel you are ready and I'll merge.

[Belphemur]

It's ready for merging, we used it at my workplace in production, and it worked the way it's intended.

I would maybe advise adding a warning about doing the transfer in SSL; you can also grab the binary for 64bits on my repo (build on XenServer 7): https://github.com/Belphemur/migrate-vm/releases

Cheers

[djamps]

Thanks for the commits! They are now merged!