That password reset infrastructure has bigger issues than just SSL. The server side works, but that’s about all I can say for it. This topic comes up every 6-12 months. :)
I thought there was a Jira entry but I can’t find it…personally I’d love to see the client and server sides both rewritten from scratch. John > On Nov 28, 2014, at 11:33 AM, Nux! <n...@li.nux.ro> wrote: > > Jayapal, > > Not necesarily, one could run stunnel or nginx as SSL proxy on some other > port (8443?), this way SSL and non-SSL connections will still work and give > you plenty of time to update your templates, if you so wish. > > Am I missing any important bits here? > > Lucian > > -- > Sent from the Delta quadrant using Borg technology! > > Nux! > www.nux.ro > > ----- Original Message ----- >> From: "Jayapal Reddy Uradi" <jayapalreddy.ur...@citrix.com> >> To: "<dev@cloudstack.apache.org>" <dev@cloudstack.apache.org> >> Cc: "Alireza Eskandari" <astro.alir...@yahoo.com> >> Sent: Friday, 28 November, 2014 09:34:02 >> Subject: Re: A secure way to reset VMs password > >> Another point to note is all the vms in production has to update >> with the new cloud-set-guest-password scripts because of the new password >> reset >> method. >> >> Thanks, >> Jayapal >> >> >> >> On 28-Nov-2014, at 2:28 PM, Erik Weber <terbol...@gmail.com> >> wrote: >> >>> On Thu, Nov 27, 2014 at 3:54 PM, Alireza Eskandari < >>> astro.alir...@yahoo.com.invalid> wrote: >>> >>>> HiI viewed the bash script that resets Linux password ( >>>> http://download.cloud.com/templates/4.2/bindir/cloud-set-guest-password.in)It >>>> seems that it doesn't use a secure way for transferring password string to >>>> instance.Instances on a shared network can sniff password requests and >>>> export requested password of other instances.I suggest to use SSL (https) >>>> instead of plan text.Regards >>>> >>>> >>> I like the idea, but there's a couple of obstacles to overcome, namely >>> which SSL certificates to use. >>> - certificates need a subject name, ie. IP or hostname for web pages, you >>> could solve this by making the mgmt server a CA and have each VR get a >>> signed certificate by it, but it's complicated >>> - if the community bundle a pre generated certificate it is commonly known >>> and not to be trusted, also not sure how to handle subject name >>> - assuming everyone to supply a valid certificate is quite complicated (CA >>> must be on VR etc), and makes it considerably harder to get a working setup >>> - using self signed causes issues with validation >>> >>> >>> Don't get me wrong, I love the idea, but it's not just to flip a switch and >>> have (proper) SSL in place. >>> >>> -- >>> Erik
