Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
On Thu, May 29, 2014 at 6:57 AM, Nachi Ueno wrote: > Hi Zang > > Since, SSL-VPN for Juno bp is approved in neturon-spec, > I would like to restart this work. > Could you share your code if it is possible? > Also, Let's discuss how we can collaborate in here. Currently We are running havana branch, I'm trying to rebase it to master > > Best > Nachi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
Just chiming in with a side-note. I always liked the idea of Postern for things like this though the crypto geek in me always worries about making key retrieval too easy for developers, bad things happen down that road. The OSSG can help with overall secure design and would be happy to consult if you¹d like. We have a separate list for security specific stuff but I think a conversation on -dev would make more sense, just tag it [OSSG] :) -Rob On 28/05/2014 23:57, "Nachi Ueno" wrote: >Hi Zang > >Since, SSL-VPN for Juno bp is approved in neturon-spec, >I would like to restart this work. >Could you share your code if it is possible? >Also, Let's discuss how we can collaborate in here. > >Best >Nachi > > >2014-05-01 14:40 GMT-07:00 Nachi Ueno : >> Hi folks >> >>> Clint >> Thanks, things get clear for me now :) >> >> >> >> >> >> 2014-05-01 13:21 GMT-07:00 John Wood : >>> I was going to bring up Postern [1] as well, Clint. Unfortunately not >>>much work has been done on it though. >>> >>> [1] https://github.com/cloudkeep/postern >>> >>> Thanks, >>> John >>> >>> >>> >>> >>> From: Clint Byrum [cl...@fewbar.com] >>> Sent: Thursday, May 01, 2014 2:22 PM >>> To: openstack-dev >>> Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation >>> >>> Excerpts from Nachi Ueno's message of 2014-05-01 12:04:23 -0700: >>>> Ah I got it now! >>>> so even if we get stolen HDD, we can keep password safe. >>>> >>>> However, I'm still not sure why this is more secure.. >>>> anyway, the ID/PW to access barbican will be written in neutron.conf, >>>>right? >>>> >>> >>> Yes. However, you can surround the secret in policies. You'll have an >>> audit trail of when and where it was accessed, and you can even >>>restrict >>> access, so that out of band you have to open up access with barbican. >>> >>> So while the server may have access, that access is now audited and >>> limited by policy, instead of just being dependent on the security >>> measures you can take to protect a file. >>> >>>> Furthermore, ID/PW for mysql will be written in conf file.. >>>> so if we can't trust unix file system protection, there is no security >>>> in OpenStack. >>> >>> The ID/PW for mysql only grants you access to mysql for as long as that >>> id/pw are enabled for access. However, the encryption keys for OpenVPN >>> will grant any passive listener access for as long as they keep any >>> sniffed traffic. They'll also grant an attacker the ability to MITM >>> traffic between peers. >>> >>> So when an encryption key has been accessed, from where, etc, is quite >>> a bit more crucial than knowing when a username/password combo have >>> been accessed. >>> >>> Producing a trustworthy audit log for access to >>>/etc/neutron/neutron.conf >>> is a lot harder than producing an audit log for a REST API. >>> >>> So it isn't so much that file system permissions aren't enough, it is >>> that file system observability is expensive. >>> >>> Note that at some point there was a POC to have a FUSE driver backed by >>> Barbican called 'Postern' I think. That would make these discussions a >>> lot simpler. :) >>> >>>> >>>> 2014-05-01 10:31 GMT-07:00 Clint Byrum : >>>> > I think you'd do something like this (Note that I don't know off >>>>the top >>>> > of my head the barbican CLI or openvpn cli switches... just >>>> > pseudo-code): >>>> > >>>> > oconf=$(mktemp -d /tmp/openvpnconfig.XX) >>>> > mount -o tmpfs $oconf size=1M >>>> > barbican get my-secret-openvpn-conf > $oconf/foo.conf >>>> > openvpn --config-dir $oconf foo --daemonize >>>> > umount $oconf >>>> > rmdir $oconf >>>> > >>>> > Excerpts from Nachi Ueno's message of 2014-05-01 10:15:26 -0700: >>>> >> Hi Robert >>>> >> >>>> >> Thank you for your suggestion. >>>> >> so your suggestion is let OpenVPN process download key to memory >>>> >> directly from Babican? >>>> >> >>>> >> 2014-05-01 9:42 GMT-07:00 Cl
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
Hi Zang Since, SSL-VPN for Juno bp is approved in neturon-spec, I would like to restart this work. Could you share your code if it is possible? Also, Let's discuss how we can collaborate in here. Best Nachi 2014-05-01 14:40 GMT-07:00 Nachi Ueno : > Hi folks > >> Clint > Thanks, things get clear for me now :) > > > > > > 2014-05-01 13:21 GMT-07:00 John Wood : >> I was going to bring up Postern [1] as well, Clint. Unfortunately not much >> work has been done on it though. >> >> [1] https://github.com/cloudkeep/postern >> >> Thanks, >> John >> >> >> >> >> From: Clint Byrum [cl...@fewbar.com] >> Sent: Thursday, May 01, 2014 2:22 PM >> To: openstack-dev >> Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation >> >> Excerpts from Nachi Ueno's message of 2014-05-01 12:04:23 -0700: >>> Ah I got it now! >>> so even if we get stolen HDD, we can keep password safe. >>> >>> However, I'm still not sure why this is more secure.. >>> anyway, the ID/PW to access barbican will be written in neutron.conf, right? >>> >> >> Yes. However, you can surround the secret in policies. You'll have an >> audit trail of when and where it was accessed, and you can even restrict >> access, so that out of band you have to open up access with barbican. >> >> So while the server may have access, that access is now audited and >> limited by policy, instead of just being dependent on the security >> measures you can take to protect a file. >> >>> Furthermore, ID/PW for mysql will be written in conf file.. >>> so if we can't trust unix file system protection, there is no security >>> in OpenStack. >> >> The ID/PW for mysql only grants you access to mysql for as long as that >> id/pw are enabled for access. However, the encryption keys for OpenVPN >> will grant any passive listener access for as long as they keep any >> sniffed traffic. They'll also grant an attacker the ability to MITM >> traffic between peers. >> >> So when an encryption key has been accessed, from where, etc, is quite >> a bit more crucial than knowing when a username/password combo have >> been accessed. >> >> Producing a trustworthy audit log for access to /etc/neutron/neutron.conf >> is a lot harder than producing an audit log for a REST API. >> >> So it isn't so much that file system permissions aren't enough, it is >> that file system observability is expensive. >> >> Note that at some point there was a POC to have a FUSE driver backed by >> Barbican called 'Postern' I think. That would make these discussions a >> lot simpler. :) >> >>> >>> 2014-05-01 10:31 GMT-07:00 Clint Byrum : >>> > I think you'd do something like this (Note that I don't know off the top >>> > of my head the barbican CLI or openvpn cli switches... just >>> > pseudo-code): >>> > >>> > oconf=$(mktemp -d /tmp/openvpnconfig.XX) >>> > mount -o tmpfs $oconf size=1M >>> > barbican get my-secret-openvpn-conf > $oconf/foo.conf >>> > openvpn --config-dir $oconf foo --daemonize >>> > umount $oconf >>> > rmdir $oconf >>> > >>> > Excerpts from Nachi Ueno's message of 2014-05-01 10:15:26 -0700: >>> >> Hi Robert >>> >> >>> >> Thank you for your suggestion. >>> >> so your suggestion is let OpenVPN process download key to memory >>> >> directly from Babican? >>> >> >>> >> 2014-05-01 9:42 GMT-07:00 Clark, Robert Graham : >>> >> > Excuse me interrupting but couldn't you treat the key as largely >>> >> > ephemeral, pull it down from Barbican, start the OpenVPN process and >>> >> > then purge the key? It would of course still be resident in the memory >>> >> > of the OpenVPN process but should otherwise be protected against >>> >> > filesystem disk-residency issues. >>> >> > >>> >> > >>> >> >> -Original Message- >>> >> >> From: Nachi Ueno [mailto:na...@ntti3.com] >>> >> >> Sent: 01 May 2014 17:36 >>> >> >> To: OpenStack Development Mailing List (not for usage questions) >>> >> >> Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation >>> >> >> >>> >> >
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
Hi folks > Clint Thanks, things get clear for me now :) 2014-05-01 13:21 GMT-07:00 John Wood : > I was going to bring up Postern [1] as well, Clint. Unfortunately not much > work has been done on it though. > > [1] https://github.com/cloudkeep/postern > > Thanks, > John > > > > > From: Clint Byrum [cl...@fewbar.com] > Sent: Thursday, May 01, 2014 2:22 PM > To: openstack-dev > Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation > > Excerpts from Nachi Ueno's message of 2014-05-01 12:04:23 -0700: >> Ah I got it now! >> so even if we get stolen HDD, we can keep password safe. >> >> However, I'm still not sure why this is more secure.. >> anyway, the ID/PW to access barbican will be written in neutron.conf, right? >> > > Yes. However, you can surround the secret in policies. You'll have an > audit trail of when and where it was accessed, and you can even restrict > access, so that out of band you have to open up access with barbican. > > So while the server may have access, that access is now audited and > limited by policy, instead of just being dependent on the security > measures you can take to protect a file. > >> Furthermore, ID/PW for mysql will be written in conf file.. >> so if we can't trust unix file system protection, there is no security >> in OpenStack. > > The ID/PW for mysql only grants you access to mysql for as long as that > id/pw are enabled for access. However, the encryption keys for OpenVPN > will grant any passive listener access for as long as they keep any > sniffed traffic. They'll also grant an attacker the ability to MITM > traffic between peers. > > So when an encryption key has been accessed, from where, etc, is quite > a bit more crucial than knowing when a username/password combo have > been accessed. > > Producing a trustworthy audit log for access to /etc/neutron/neutron.conf > is a lot harder than producing an audit log for a REST API. > > So it isn't so much that file system permissions aren't enough, it is > that file system observability is expensive. > > Note that at some point there was a POC to have a FUSE driver backed by > Barbican called 'Postern' I think. That would make these discussions a > lot simpler. :) > >> >> 2014-05-01 10:31 GMT-07:00 Clint Byrum : >> > I think you'd do something like this (Note that I don't know off the top >> > of my head the barbican CLI or openvpn cli switches... just >> > pseudo-code): >> > >> > oconf=$(mktemp -d /tmp/openvpnconfig.XX) >> > mount -o tmpfs $oconf size=1M >> > barbican get my-secret-openvpn-conf > $oconf/foo.conf >> > openvpn --config-dir $oconf foo --daemonize >> > umount $oconf >> > rmdir $oconf >> > >> > Excerpts from Nachi Ueno's message of 2014-05-01 10:15:26 -0700: >> >> Hi Robert >> >> >> >> Thank you for your suggestion. >> >> so your suggestion is let OpenVPN process download key to memory >> >> directly from Babican? >> >> >> >> 2014-05-01 9:42 GMT-07:00 Clark, Robert Graham : >> >> > Excuse me interrupting but couldn't you treat the key as largely >> >> > ephemeral, pull it down from Barbican, start the OpenVPN process and >> >> > then purge the key? It would of course still be resident in the memory >> >> > of the OpenVPN process but should otherwise be protected against >> >> > filesystem disk-residency issues. >> >> > >> >> > >> >> >> -Original Message- >> >> >> From: Nachi Ueno [mailto:na...@ntti3.com] >> >> >> Sent: 01 May 2014 17:36 >> >> >> To: OpenStack Development Mailing List (not for usage questions) >> >> >> Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation >> >> >> >> >> >> Hi Jarret >> >> >> >> >> >> IMO, Zang point is the issue saving plain private key in the >> >> > filesystem for >> >> >> OpenVPN. >> >> >> Isn't this same even if we use Barbican? >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 2014-05-01 2:56 GMT-07:00 Jarret Raim : >> >> >> > Zang mentioned that part of the issue is that the private key has to >> >> >> > be stored in the OpenVPN config file. If the config fil
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
I was going to bring up Postern [1] as well, Clint. Unfortunately not much work has been done on it though. [1] https://github.com/cloudkeep/postern Thanks, John From: Clint Byrum [cl...@fewbar.com] Sent: Thursday, May 01, 2014 2:22 PM To: openstack-dev Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation Excerpts from Nachi Ueno's message of 2014-05-01 12:04:23 -0700: > Ah I got it now! > so even if we get stolen HDD, we can keep password safe. > > However, I'm still not sure why this is more secure.. > anyway, the ID/PW to access barbican will be written in neutron.conf, right? > Yes. However, you can surround the secret in policies. You'll have an audit trail of when and where it was accessed, and you can even restrict access, so that out of band you have to open up access with barbican. So while the server may have access, that access is now audited and limited by policy, instead of just being dependent on the security measures you can take to protect a file. > Furthermore, ID/PW for mysql will be written in conf file.. > so if we can't trust unix file system protection, there is no security > in OpenStack. The ID/PW for mysql only grants you access to mysql for as long as that id/pw are enabled for access. However, the encryption keys for OpenVPN will grant any passive listener access for as long as they keep any sniffed traffic. They'll also grant an attacker the ability to MITM traffic between peers. So when an encryption key has been accessed, from where, etc, is quite a bit more crucial than knowing when a username/password combo have been accessed. Producing a trustworthy audit log for access to /etc/neutron/neutron.conf is a lot harder than producing an audit log for a REST API. So it isn't so much that file system permissions aren't enough, it is that file system observability is expensive. Note that at some point there was a POC to have a FUSE driver backed by Barbican called 'Postern' I think. That would make these discussions a lot simpler. :) > > 2014-05-01 10:31 GMT-07:00 Clint Byrum : > > I think you'd do something like this (Note that I don't know off the top > > of my head the barbican CLI or openvpn cli switches... just > > pseudo-code): > > > > oconf=$(mktemp -d /tmp/openvpnconfig.XX) > > mount -o tmpfs $oconf size=1M > > barbican get my-secret-openvpn-conf > $oconf/foo.conf > > openvpn --config-dir $oconf foo --daemonize > > umount $oconf > > rmdir $oconf > > > > Excerpts from Nachi Ueno's message of 2014-05-01 10:15:26 -0700: > >> Hi Robert > >> > >> Thank you for your suggestion. > >> so your suggestion is let OpenVPN process download key to memory > >> directly from Babican? > >> > >> 2014-05-01 9:42 GMT-07:00 Clark, Robert Graham : > >> > Excuse me interrupting but couldn't you treat the key as largely > >> > ephemeral, pull it down from Barbican, start the OpenVPN process and > >> > then purge the key? It would of course still be resident in the memory > >> > of the OpenVPN process but should otherwise be protected against > >> > filesystem disk-residency issues. > >> > > >> > > >> >> -Original Message- > >> >> From: Nachi Ueno [mailto:na...@ntti3.com] > >> >> Sent: 01 May 2014 17:36 > >> >> To: OpenStack Development Mailing List (not for usage questions) > >> >> Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation > >> >> > >> >> Hi Jarret > >> >> > >> >> IMO, Zang point is the issue saving plain private key in the > >> > filesystem for > >> >> OpenVPN. > >> >> Isn't this same even if we use Barbican? > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> 2014-05-01 2:56 GMT-07:00 Jarret Raim : > >> >> > Zang mentioned that part of the issue is that the private key has to > >> >> > be stored in the OpenVPN config file. If the config files are > >> >> > generated and can be stored, then storing the whole config file in > >> >> > Barbican protects the private key (and any other settings) without > >> >> > having to try to deliver the key to the OpenVPN endpoint in some > >> > non- > >> >> standard way. > >> >> > > >> >> > > >> >> > Jarret > >> >> > > >> >> > On 4/30/14, 6:08 PM, "Nac
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
Excerpts from Nachi Ueno's message of 2014-05-01 12:04:23 -0700: > Ah I got it now! > so even if we get stolen HDD, we can keep password safe. > > However, I'm still not sure why this is more secure.. > anyway, the ID/PW to access barbican will be written in neutron.conf, right? > Yes. However, you can surround the secret in policies. You'll have an audit trail of when and where it was accessed, and you can even restrict access, so that out of band you have to open up access with barbican. So while the server may have access, that access is now audited and limited by policy, instead of just being dependent on the security measures you can take to protect a file. > Furthermore, ID/PW for mysql will be written in conf file.. > so if we can't trust unix file system protection, there is no security > in OpenStack. The ID/PW for mysql only grants you access to mysql for as long as that id/pw are enabled for access. However, the encryption keys for OpenVPN will grant any passive listener access for as long as they keep any sniffed traffic. They'll also grant an attacker the ability to MITM traffic between peers. So when an encryption key has been accessed, from where, etc, is quite a bit more crucial than knowing when a username/password combo have been accessed. Producing a trustworthy audit log for access to /etc/neutron/neutron.conf is a lot harder than producing an audit log for a REST API. So it isn't so much that file system permissions aren't enough, it is that file system observability is expensive. Note that at some point there was a POC to have a FUSE driver backed by Barbican called 'Postern' I think. That would make these discussions a lot simpler. :) > > 2014-05-01 10:31 GMT-07:00 Clint Byrum : > > I think you'd do something like this (Note that I don't know off the top > > of my head the barbican CLI or openvpn cli switches... just > > pseudo-code): > > > > oconf=$(mktemp -d /tmp/openvpnconfig.XX) > > mount -o tmpfs $oconf size=1M > > barbican get my-secret-openvpn-conf > $oconf/foo.conf > > openvpn --config-dir $oconf foo --daemonize > > umount $oconf > > rmdir $oconf > > > > Excerpts from Nachi Ueno's message of 2014-05-01 10:15:26 -0700: > >> Hi Robert > >> > >> Thank you for your suggestion. > >> so your suggestion is let OpenVPN process download key to memory > >> directly from Babican? > >> > >> 2014-05-01 9:42 GMT-07:00 Clark, Robert Graham : > >> > Excuse me interrupting but couldn't you treat the key as largely > >> > ephemeral, pull it down from Barbican, start the OpenVPN process and > >> > then purge the key? It would of course still be resident in the memory > >> > of the OpenVPN process but should otherwise be protected against > >> > filesystem disk-residency issues. > >> > > >> > > >> >> -Original Message- > >> >> From: Nachi Ueno [mailto:na...@ntti3.com] > >> >> Sent: 01 May 2014 17:36 > >> >> To: OpenStack Development Mailing List (not for usage questions) > >> >> Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation > >> >> > >> >> Hi Jarret > >> >> > >> >> IMO, Zang point is the issue saving plain private key in the > >> > filesystem for > >> >> OpenVPN. > >> >> Isn't this same even if we use Barbican? > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> 2014-05-01 2:56 GMT-07:00 Jarret Raim : > >> >> > Zang mentioned that part of the issue is that the private key has to > >> >> > be stored in the OpenVPN config file. If the config files are > >> >> > generated and can be stored, then storing the whole config file in > >> >> > Barbican protects the private key (and any other settings) without > >> >> > having to try to deliver the key to the OpenVPN endpoint in some > >> > non- > >> >> standard way. > >> >> > > >> >> > > >> >> > Jarret > >> >> > > >> >> > On 4/30/14, 6:08 PM, "Nachi Ueno" wrote: > >> >> > > >> >> >>> Jarret > >> >> >> > >> >> >>Thanks! > >> >> >>Currently, the config will be generated on demand by the agent. > >> >> >>What's merit storing entire config in the Barbican? > >> >> &
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
Ah I got it now! so even if we get stolen HDD, we can keep password safe. However, I'm still not sure why this is more secure.. anyway, the ID/PW to access barbican will be written in neutron.conf, right? Furthermore, ID/PW for mysql will be written in conf file.. so if we can't trust unix file system protection, there is no security in OpenStack. 2014-05-01 10:31 GMT-07:00 Clint Byrum : > I think you'd do something like this (Note that I don't know off the top > of my head the barbican CLI or openvpn cli switches... just > pseudo-code): > > oconf=$(mktemp -d /tmp/openvpnconfig.XX) > mount -o tmpfs $oconf size=1M > barbican get my-secret-openvpn-conf > $oconf/foo.conf > openvpn --config-dir $oconf foo --daemonize > umount $oconf > rmdir $oconf > > Excerpts from Nachi Ueno's message of 2014-05-01 10:15:26 -0700: >> Hi Robert >> >> Thank you for your suggestion. >> so your suggestion is let OpenVPN process download key to memory >> directly from Babican? >> >> 2014-05-01 9:42 GMT-07:00 Clark, Robert Graham : >> > Excuse me interrupting but couldn't you treat the key as largely >> > ephemeral, pull it down from Barbican, start the OpenVPN process and >> > then purge the key? It would of course still be resident in the memory >> > of the OpenVPN process but should otherwise be protected against >> > filesystem disk-residency issues. >> > >> > >> >> -Original Message----- >> >> From: Nachi Ueno [mailto:na...@ntti3.com] >> >> Sent: 01 May 2014 17:36 >> >> To: OpenStack Development Mailing List (not for usage questions) >> >> Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation >> >> >> >> Hi Jarret >> >> >> >> IMO, Zang point is the issue saving plain private key in the >> > filesystem for >> >> OpenVPN. >> >> Isn't this same even if we use Barbican? >> >> >> >> >> >> >> >> >> >> >> >> 2014-05-01 2:56 GMT-07:00 Jarret Raim : >> >> > Zang mentioned that part of the issue is that the private key has to >> >> > be stored in the OpenVPN config file. If the config files are >> >> > generated and can be stored, then storing the whole config file in >> >> > Barbican protects the private key (and any other settings) without >> >> > having to try to deliver the key to the OpenVPN endpoint in some >> > non- >> >> standard way. >> >> > >> >> > >> >> > Jarret >> >> > >> >> > On 4/30/14, 6:08 PM, "Nachi Ueno" wrote: >> >> > >> >> >>> Jarret >> >> >> >> >> >>Thanks! >> >> >>Currently, the config will be generated on demand by the agent. >> >> >>What's merit storing entire config in the Barbican? >> >> >> >> >> >>> Kyle >> >> >>Thanks! >> >> >> >> >> >>2014-04-30 7:05 GMT-07:00 Kyle Mestery >> >> : >> >> >>> On Tue, Apr 29, 2014 at 6:11 PM, Nachi Ueno >> >> wrote: >> >> >>>> Hi Clint >> >> >>>> >> >> >>>> Thank you for your suggestion. Your point get taken :) >> >> >>>> >> >> >>>>> Kyle >> >> >>>> This is also a same discussion for LBaaS Can we discuss this in >> >> >>>> advanced service meeting? >> >> >>>> >> >> >>> Yes! I think we should definitely discuss this in the advanced >> >> >>> services meeting today. I've added it to the agenda [1]. >> >> >>> >> >> >>> Thanks, >> >> >>> Kyle >> >> >>> >> >> >>> [1] >> >> >>>https://wiki.openstack.org/wiki/Meetings/AdvancedServices#Agenda_f >> >> or_ >> >> >>>next >> >> >>>_meeting >> >> >>> >> >> >>>>> Zang >> >> >>>> Could you join the discussion? >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> 2014-04-29 15:48 GMT-07:00 Clint Byrum : >> >> >>>>> Excerpts from Nachi Ueno's message of 2014-04-29 10:58:53 -0700: >> >>
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
I think you'd do something like this (Note that I don't know off the top of my head the barbican CLI or openvpn cli switches... just pseudo-code): oconf=$(mktemp -d /tmp/openvpnconfig.XX) mount -o tmpfs $oconf size=1M barbican get my-secret-openvpn-conf > $oconf/foo.conf openvpn --config-dir $oconf foo --daemonize umount $oconf rmdir $oconf Excerpts from Nachi Ueno's message of 2014-05-01 10:15:26 -0700: > Hi Robert > > Thank you for your suggestion. > so your suggestion is let OpenVPN process download key to memory > directly from Babican? > > 2014-05-01 9:42 GMT-07:00 Clark, Robert Graham : > > Excuse me interrupting but couldn't you treat the key as largely > > ephemeral, pull it down from Barbican, start the OpenVPN process and > > then purge the key? It would of course still be resident in the memory > > of the OpenVPN process but should otherwise be protected against > > filesystem disk-residency issues. > > > > > >> -Original Message- > >> From: Nachi Ueno [mailto:na...@ntti3.com] > >> Sent: 01 May 2014 17:36 > >> To: OpenStack Development Mailing List (not for usage questions) > >> Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation > >> > >> Hi Jarret > >> > >> IMO, Zang point is the issue saving plain private key in the > > filesystem for > >> OpenVPN. > >> Isn't this same even if we use Barbican? > >> > >> > >> > >> > >> > >> 2014-05-01 2:56 GMT-07:00 Jarret Raim : > >> > Zang mentioned that part of the issue is that the private key has to > >> > be stored in the OpenVPN config file. If the config files are > >> > generated and can be stored, then storing the whole config file in > >> > Barbican protects the private key (and any other settings) without > >> > having to try to deliver the key to the OpenVPN endpoint in some > > non- > >> standard way. > >> > > >> > > >> > Jarret > >> > > >> > On 4/30/14, 6:08 PM, "Nachi Ueno" wrote: > >> > > >> >>> Jarret > >> >> > >> >>Thanks! > >> >>Currently, the config will be generated on demand by the agent. > >> >>What's merit storing entire config in the Barbican? > >> >> > >> >>> Kyle > >> >>Thanks! > >> >> > >> >>2014-04-30 7:05 GMT-07:00 Kyle Mestery > >> : > >> >>> On Tue, Apr 29, 2014 at 6:11 PM, Nachi Ueno > >> wrote: > >> >>>> Hi Clint > >> >>>> > >> >>>> Thank you for your suggestion. Your point get taken :) > >> >>>> > >> >>>>> Kyle > >> >>>> This is also a same discussion for LBaaS Can we discuss this in > >> >>>> advanced service meeting? > >> >>>> > >> >>> Yes! I think we should definitely discuss this in the advanced > >> >>> services meeting today. I've added it to the agenda [1]. > >> >>> > >> >>> Thanks, > >> >>> Kyle > >> >>> > >> >>> [1] > >> >>>https://wiki.openstack.org/wiki/Meetings/AdvancedServices#Agenda_f > >> or_ > >> >>>next > >> >>>_meeting > >> >>> > >> >>>>> Zang > >> >>>> Could you join the discussion? > >> >>>> > >> >>>> > >> >>>> > >> >>>> 2014-04-29 15:48 GMT-07:00 Clint Byrum : > >> >>>>> Excerpts from Nachi Ueno's message of 2014-04-29 10:58:53 -0700: > >> >>>>>> Hi Kyle > >> >>>>>> > >> >>>>>> 2014-04-29 10:52 GMT-07:00 Kyle Mestery > >> : > >> >>>>>> > On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno > >> > >> >>>>>>wrote: > >> >>>>>> >> Hi Zang > >> >>>>>> >> > >> >>>>>> >> Thank you for your contribution on this! > >> >>>>>> >> The private key management is what I want to discuss in the > >> >>>>>>summit. > >> >>>>>> >> > >> >>>>>> > Has the idea of using Barbican been di
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
Hi Robert Thank you for your suggestion. so your suggestion is let OpenVPN process download key to memory directly from Babican? 2014-05-01 9:42 GMT-07:00 Clark, Robert Graham : > Excuse me interrupting but couldn't you treat the key as largely > ephemeral, pull it down from Barbican, start the OpenVPN process and > then purge the key? It would of course still be resident in the memory > of the OpenVPN process but should otherwise be protected against > filesystem disk-residency issues. > > >> -Original Message- >> From: Nachi Ueno [mailto:na...@ntti3.com] >> Sent: 01 May 2014 17:36 >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation >> >> Hi Jarret >> >> IMO, Zang point is the issue saving plain private key in the > filesystem for >> OpenVPN. >> Isn't this same even if we use Barbican? >> >> >> >> >> >> 2014-05-01 2:56 GMT-07:00 Jarret Raim : >> > Zang mentioned that part of the issue is that the private key has to >> > be stored in the OpenVPN config file. If the config files are >> > generated and can be stored, then storing the whole config file in >> > Barbican protects the private key (and any other settings) without >> > having to try to deliver the key to the OpenVPN endpoint in some > non- >> standard way. >> > >> > >> > Jarret >> > >> > On 4/30/14, 6:08 PM, "Nachi Ueno" wrote: >> > >> >>> Jarret >> >> >> >>Thanks! >> >>Currently, the config will be generated on demand by the agent. >> >>What's merit storing entire config in the Barbican? >> >> >> >>> Kyle >> >>Thanks! >> >> >> >>2014-04-30 7:05 GMT-07:00 Kyle Mestery >> : >> >>> On Tue, Apr 29, 2014 at 6:11 PM, Nachi Ueno >> wrote: >> >>>> Hi Clint >> >>>> >> >>>> Thank you for your suggestion. Your point get taken :) >> >>>> >> >>>>> Kyle >> >>>> This is also a same discussion for LBaaS Can we discuss this in >> >>>> advanced service meeting? >> >>>> >> >>> Yes! I think we should definitely discuss this in the advanced >> >>> services meeting today. I've added it to the agenda [1]. >> >>> >> >>> Thanks, >> >>> Kyle >> >>> >> >>> [1] >> >>>https://wiki.openstack.org/wiki/Meetings/AdvancedServices#Agenda_f >> or_ >> >>>next >> >>>_meeting >> >>> >> >>>>> Zang >> >>>> Could you join the discussion? >> >>>> >> >>>> >> >>>> >> >>>> 2014-04-29 15:48 GMT-07:00 Clint Byrum : >> >>>>> Excerpts from Nachi Ueno's message of 2014-04-29 10:58:53 -0700: >> >>>>>> Hi Kyle >> >>>>>> >> >>>>>> 2014-04-29 10:52 GMT-07:00 Kyle Mestery >> : >> >>>>>> > On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno >> >> >>>>>>wrote: >> >>>>>> >> Hi Zang >> >>>>>> >> >> >>>>>> >> Thank you for your contribution on this! >> >>>>>> >> The private key management is what I want to discuss in the >> >>>>>>summit. >> >>>>>> >> >> >>>>>> > Has the idea of using Barbican been discussed before? There > are >> >>>>>>many >> >>>>>> > reasons why using Barbican for this may be better than >> >>>>>> > developing >> >>>>>>key >> >>>>>> > management ourselves. >> >>>>>> >> >>>>>> No, however I'm +1 for using Barbican. Let's discuss this in >> >>>>>> certificate management topic in advanced service session. >> >>>>>> >> >>>>> >> >>>>> Just a suggestion: Don't defer that until the summit. Sounds > like >> >>>>>you've already got some consensus, so you don't need the summit >> >>>>>just to rubber stamp it. I suggest discussing as much as you can >> >>>>>right
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
Excuse me interrupting but couldn't you treat the key as largely ephemeral, pull it down from Barbican, start the OpenVPN process and then purge the key? It would of course still be resident in the memory of the OpenVPN process but should otherwise be protected against filesystem disk-residency issues. > -Original Message- > From: Nachi Ueno [mailto:na...@ntti3.com] > Sent: 01 May 2014 17:36 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation > > Hi Jarret > > IMO, Zang point is the issue saving plain private key in the filesystem for > OpenVPN. > Isn't this same even if we use Barbican? > > > > > > 2014-05-01 2:56 GMT-07:00 Jarret Raim : > > Zang mentioned that part of the issue is that the private key has to > > be stored in the OpenVPN config file. If the config files are > > generated and can be stored, then storing the whole config file in > > Barbican protects the private key (and any other settings) without > > having to try to deliver the key to the OpenVPN endpoint in some non- > standard way. > > > > > > Jarret > > > > On 4/30/14, 6:08 PM, "Nachi Ueno" wrote: > > > >>> Jarret > >> > >>Thanks! > >>Currently, the config will be generated on demand by the agent. > >>What's merit storing entire config in the Barbican? > >> > >>> Kyle > >>Thanks! > >> > >>2014-04-30 7:05 GMT-07:00 Kyle Mestery > : > >>> On Tue, Apr 29, 2014 at 6:11 PM, Nachi Ueno > wrote: > >>>> Hi Clint > >>>> > >>>> Thank you for your suggestion. Your point get taken :) > >>>> > >>>>> Kyle > >>>> This is also a same discussion for LBaaS Can we discuss this in > >>>> advanced service meeting? > >>>> > >>> Yes! I think we should definitely discuss this in the advanced > >>> services meeting today. I've added it to the agenda [1]. > >>> > >>> Thanks, > >>> Kyle > >>> > >>> [1] > >>>https://wiki.openstack.org/wiki/Meetings/AdvancedServices#Agenda_f > or_ > >>>next > >>>_meeting > >>> > >>>>> Zang > >>>> Could you join the discussion? > >>>> > >>>> > >>>> > >>>> 2014-04-29 15:48 GMT-07:00 Clint Byrum : > >>>>> Excerpts from Nachi Ueno's message of 2014-04-29 10:58:53 -0700: > >>>>>> Hi Kyle > >>>>>> > >>>>>> 2014-04-29 10:52 GMT-07:00 Kyle Mestery > : > >>>>>> > On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno > > >>>>>>wrote: > >>>>>> >> Hi Zang > >>>>>> >> > >>>>>> >> Thank you for your contribution on this! > >>>>>> >> The private key management is what I want to discuss in the > >>>>>>summit. > >>>>>> >> > >>>>>> > Has the idea of using Barbican been discussed before? There are > >>>>>>many > >>>>>> > reasons why using Barbican for this may be better than > >>>>>> > developing > >>>>>>key > >>>>>> > management ourselves. > >>>>>> > >>>>>> No, however I'm +1 for using Barbican. Let's discuss this in > >>>>>> certificate management topic in advanced service session. > >>>>>> > >>>>> > >>>>> Just a suggestion: Don't defer that until the summit. Sounds like > >>>>>you've already got some consensus, so you don't need the summit > >>>>>just to rubber stamp it. I suggest discussing as much as you can > >>>>>right now on the mailing list, and using the time at the summit to > >>>>>resolve any complicated issues including any "a or b" things that > >>>>>need crowd-sourced idea making. You can also use the summit time > >>>>>to communicate your requirements to the Barbican developers. > >>>>> > >>>>> Point is: just because you'll have face time, doesn't mean you > >>>>> should use it for what can be done via the mailing list. > >>>>> > >>>>> ___ > >>>>> OpenStack-dev mailing list > >>>>> OpenStack-dev@lists.openstack.org > >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>>> > >>>> ___ > >>>> OpenStack-dev mailing list > >>>> OpenStack-dev@lists.openstack.org > >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>> > >>> ___ > >>> OpenStack-dev mailing list > >>> OpenStack-dev@lists.openstack.org > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >>___ > >>OpenStack-dev mailing list > >>OpenStack-dev@lists.openstack.org > >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
Hi Jarret IMO, Zang point is the issue saving plain private key in the filesystem for OpenVPN. Isn't this same even if we use Barbican? 2014-05-01 2:56 GMT-07:00 Jarret Raim : > Zang mentioned that part of the issue is that the private key has to be > stored in the OpenVPN config file. If the config files are generated and > can be stored, then storing the whole config file in Barbican protects the > private key (and any other settings) without having to try to deliver the > key to the OpenVPN endpoint in some non-standard way. > > > Jarret > > On 4/30/14, 6:08 PM, "Nachi Ueno" wrote: > >>> Jarret >> >>Thanks! >>Currently, the config will be generated on demand by the agent. >>What's merit storing entire config in the Barbican? >> >>> Kyle >>Thanks! >> >>2014-04-30 7:05 GMT-07:00 Kyle Mestery : >>> On Tue, Apr 29, 2014 at 6:11 PM, Nachi Ueno wrote: Hi Clint Thank you for your suggestion. Your point get taken :) > Kyle This is also a same discussion for LBaaS Can we discuss this in advanced service meeting? >>> Yes! I think we should definitely discuss this in the advanced >>> services meeting today. I've added it to the agenda [1]. >>> >>> Thanks, >>> Kyle >>> >>> [1] >>>https://wiki.openstack.org/wiki/Meetings/AdvancedServices#Agenda_for_next >>>_meeting >>> > Zang Could you join the discussion? 2014-04-29 15:48 GMT-07:00 Clint Byrum : > Excerpts from Nachi Ueno's message of 2014-04-29 10:58:53 -0700: >> Hi Kyle >> >> 2014-04-29 10:52 GMT-07:00 Kyle Mestery : >> > On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno >>wrote: >> >> Hi Zang >> >> >> >> Thank you for your contribution on this! >> >> The private key management is what I want to discuss in the >>summit. >> >> >> > Has the idea of using Barbican been discussed before? There are >>many >> > reasons why using Barbican for this may be better than developing >>key >> > management ourselves. >> >> No, however I'm +1 for using Barbican. Let's discuss this in >> certificate management topic in advanced service session. >> > > Just a suggestion: Don't defer that until the summit. Sounds like >you've > already got some consensus, so you don't need the summit just to >rubber > stamp it. I suggest discussing as much as you can right now on the >mailing > list, and using the time at the summit to resolve any complicated >issues > including any "a or b" things that need crowd-sourced idea making. You > can also use the summit time to communicate your requirements to the > Barbican developers. > > Point is: just because you'll have face time, doesn't mean you should > use it for what can be done via the mailing list. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >>___ >>OpenStack-dev mailing list >>OpenStack-dev@lists.openstack.org >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
Zang mentioned that part of the issue is that the private key has to be stored in the OpenVPN config file. If the config files are generated and can be stored, then storing the whole config file in Barbican protects the private key (and any other settings) without having to try to deliver the key to the OpenVPN endpoint in some non-standard way. Jarret On 4/30/14, 6:08 PM, "Nachi Ueno" wrote: >> Jarret > >Thanks! >Currently, the config will be generated on demand by the agent. >What's merit storing entire config in the Barbican? > >> Kyle >Thanks! > >2014-04-30 7:05 GMT-07:00 Kyle Mestery : >> On Tue, Apr 29, 2014 at 6:11 PM, Nachi Ueno wrote: >>> Hi Clint >>> >>> Thank you for your suggestion. Your point get taken :) >>> Kyle >>> This is also a same discussion for LBaaS >>> Can we discuss this in advanced service meeting? >>> >> Yes! I think we should definitely discuss this in the advanced >> services meeting today. I've added it to the agenda [1]. >> >> Thanks, >> Kyle >> >> [1] >>https://wiki.openstack.org/wiki/Meetings/AdvancedServices#Agenda_for_next >>_meeting >> Zang >>> Could you join the discussion? >>> >>> >>> >>> 2014-04-29 15:48 GMT-07:00 Clint Byrum : Excerpts from Nachi Ueno's message of 2014-04-29 10:58:53 -0700: > Hi Kyle > > 2014-04-29 10:52 GMT-07:00 Kyle Mestery : > > On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno >wrote: > >> Hi Zang > >> > >> Thank you for your contribution on this! > >> The private key management is what I want to discuss in the >summit. > >> > > Has the idea of using Barbican been discussed before? There are >many > > reasons why using Barbican for this may be better than developing >key > > management ourselves. > > No, however I'm +1 for using Barbican. Let's discuss this in > certificate management topic in advanced service session. > Just a suggestion: Don't defer that until the summit. Sounds like you've already got some consensus, so you don't need the summit just to rubber stamp it. I suggest discussing as much as you can right now on the mailing list, and using the time at the summit to resolve any complicated issues including any "a or b" things that need crowd-sourced idea making. You can also use the summit time to communicate your requirements to the Barbican developers. Point is: just because you'll have face time, doesn't mean you should use it for what can be done via the mailing list. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >___ >OpenStack-dev mailing list >OpenStack-dev@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
> Jarret Thanks! Currently, the config will be generated on demand by the agent. What's merit storing entire config in the Barbican? > Kyle Thanks! 2014-04-30 7:05 GMT-07:00 Kyle Mestery : > On Tue, Apr 29, 2014 at 6:11 PM, Nachi Ueno wrote: >> Hi Clint >> >> Thank you for your suggestion. Your point get taken :) >> >>> Kyle >> This is also a same discussion for LBaaS >> Can we discuss this in advanced service meeting? >> > Yes! I think we should definitely discuss this in the advanced > services meeting today. I've added it to the agenda [1]. > > Thanks, > Kyle > > [1] > https://wiki.openstack.org/wiki/Meetings/AdvancedServices#Agenda_for_next_meeting > >>> Zang >> Could you join the discussion? >> >> >> >> 2014-04-29 15:48 GMT-07:00 Clint Byrum : >>> Excerpts from Nachi Ueno's message of 2014-04-29 10:58:53 -0700: Hi Kyle 2014-04-29 10:52 GMT-07:00 Kyle Mestery : > On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno wrote: >> Hi Zang >> >> Thank you for your contribution on this! >> The private key management is what I want to discuss in the summit. >> > Has the idea of using Barbican been discussed before? There are many > reasons why using Barbican for this may be better than developing key > management ourselves. No, however I'm +1 for using Barbican. Let's discuss this in certificate management topic in advanced service session. >>> >>> Just a suggestion: Don't defer that until the summit. Sounds like you've >>> already got some consensus, so you don't need the summit just to rubber >>> stamp it. I suggest discussing as much as you can right now on the mailing >>> list, and using the time at the summit to resolve any complicated issues >>> including any "a or b" things that need crowd-sourced idea making. You >>> can also use the summit time to communicate your requirements to the >>> Barbican developers. >>> >>> Point is: just because you'll have face time, doesn't mean you should >>> use it for what can be done via the mailing list. >>> >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
On Tue, Apr 29, 2014 at 6:11 PM, Nachi Ueno wrote: > Hi Clint > > Thank you for your suggestion. Your point get taken :) > >> Kyle > This is also a same discussion for LBaaS > Can we discuss this in advanced service meeting? > Yes! I think we should definitely discuss this in the advanced services meeting today. I've added it to the agenda [1]. Thanks, Kyle [1] https://wiki.openstack.org/wiki/Meetings/AdvancedServices#Agenda_for_next_meeting >> Zang > Could you join the discussion? > > > > 2014-04-29 15:48 GMT-07:00 Clint Byrum : >> Excerpts from Nachi Ueno's message of 2014-04-29 10:58:53 -0700: >>> Hi Kyle >>> >>> 2014-04-29 10:52 GMT-07:00 Kyle Mestery : >>> > On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno wrote: >>> >> Hi Zang >>> >> >>> >> Thank you for your contribution on this! >>> >> The private key management is what I want to discuss in the summit. >>> >> >>> > Has the idea of using Barbican been discussed before? There are many >>> > reasons why using Barbican for this may be better than developing key >>> > management ourselves. >>> >>> No, however I'm +1 for using Barbican. Let's discuss this in >>> certificate management topic in advanced service session. >>> >> >> Just a suggestion: Don't defer that until the summit. Sounds like you've >> already got some consensus, so you don't need the summit just to rubber >> stamp it. I suggest discussing as much as you can right now on the mailing >> list, and using the time at the summit to resolve any complicated issues >> including any "a or b" things that need crowd-sourced idea making. You >> can also use the summit time to communicate your requirements to the >> Barbican developers. >> >> Point is: just because you'll have face time, doesn't mean you should >> use it for what can be done via the mailing list. >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
As the PTL for Barbican, I¹m happy to discuss this more here or at the Summit. Not sure if this is an option, but could you store the entire OpenVPN config file in Barbican rather than just the key? Not sure if you are generating those on demand or not, but we¹ve had several teams inside Rackspace just storing entire config files rather than trying to separate out individual keys or passwords. Jarret On 4/30/14, 12:11 AM, "Nachi Ueno" wrote: >Hi Clint > >Thank you for your suggestion. Your point get taken :) > >> Kyle >This is also a same discussion for LBaaS >Can we discuss this in advanced service meeting? > >> Zang >Could you join the discussion? > > > >2014-04-29 15:48 GMT-07:00 Clint Byrum : >> Excerpts from Nachi Ueno's message of 2014-04-29 10:58:53 -0700: >>> Hi Kyle >>> >>> 2014-04-29 10:52 GMT-07:00 Kyle Mestery : >>> > On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno wrote: >>> >> Hi Zang >>> >> >>> >> Thank you for your contribution on this! >>> >> The private key management is what I want to discuss in the summit. >>> >> >>> > Has the idea of using Barbican been discussed before? There are many >>> > reasons why using Barbican for this may be better than developing key >>> > management ourselves. >>> >>> No, however I'm +1 for using Barbican. Let's discuss this in >>> certificate management topic in advanced service session. >>> >> >> Just a suggestion: Don't defer that until the summit. Sounds like you've >> already got some consensus, so you don't need the summit just to rubber >> stamp it. I suggest discussing as much as you can right now on the >>mailing >> list, and using the time at the summit to resolve any complicated issues >> including any "a or b" things that need crowd-sourced idea making. You >> can also use the summit time to communicate your requirements to the >> Barbican developers. >> >> Point is: just because you'll have face time, doesn't mean you should >> use it for what can be done via the mailing list. smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
Hi Clint Thank you for your suggestion. Your point get taken :) > Kyle This is also a same discussion for LBaaS Can we discuss this in advanced service meeting? > Zang Could you join the discussion? 2014-04-29 15:48 GMT-07:00 Clint Byrum : > Excerpts from Nachi Ueno's message of 2014-04-29 10:58:53 -0700: >> Hi Kyle >> >> 2014-04-29 10:52 GMT-07:00 Kyle Mestery : >> > On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno wrote: >> >> Hi Zang >> >> >> >> Thank you for your contribution on this! >> >> The private key management is what I want to discuss in the summit. >> >> >> > Has the idea of using Barbican been discussed before? There are many >> > reasons why using Barbican for this may be better than developing key >> > management ourselves. >> >> No, however I'm +1 for using Barbican. Let's discuss this in >> certificate management topic in advanced service session. >> > > Just a suggestion: Don't defer that until the summit. Sounds like you've > already got some consensus, so you don't need the summit just to rubber > stamp it. I suggest discussing as much as you can right now on the mailing > list, and using the time at the summit to resolve any complicated issues > including any "a or b" things that need crowd-sourced idea making. You > can also use the summit time to communicate your requirements to the > Barbican developers. > > Point is: just because you'll have face time, doesn't mean you should > use it for what can be done via the mailing list. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
Excerpts from Nachi Ueno's message of 2014-04-29 10:58:53 -0700: > Hi Kyle > > 2014-04-29 10:52 GMT-07:00 Kyle Mestery : > > On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno wrote: > >> Hi Zang > >> > >> Thank you for your contribution on this! > >> The private key management is what I want to discuss in the summit. > >> > > Has the idea of using Barbican been discussed before? There are many > > reasons why using Barbican for this may be better than developing key > > management ourselves. > > No, however I'm +1 for using Barbican. Let's discuss this in > certificate management topic in advanced service session. > Just a suggestion: Don't defer that until the summit. Sounds like you've already got some consensus, so you don't need the summit just to rubber stamp it. I suggest discussing as much as you can right now on the mailing list, and using the time at the summit to resolve any complicated issues including any "a or b" things that need crowd-sourced idea making. You can also use the summit time to communicate your requirements to the Barbican developers. Point is: just because you'll have face time, doesn't mean you should use it for what can be done via the mailing list. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
On Tue, Apr 29, 2014 at 12:58 PM, Nachi Ueno wrote: > Hi Kyle > > 2014-04-29 10:52 GMT-07:00 Kyle Mestery : >> On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno wrote: >>> Hi Zang >>> >>> Thank you for your contribution on this! >>> The private key management is what I want to discuss in the summit. >>> >> Has the idea of using Barbican been discussed before? There are many >> reasons why using Barbican for this may be better than developing key >> management ourselves. > > No, however I'm +1 for using Barbican. Let's discuss this in > certificate management topic in advanced service session. > Agreed, this will be good to nail down in Atlanta in a few weeks. >> Thanks, >> Kyle >> >>> [1] We are depending DB security, anyway >>> When we get stolen the private key in the DB, it means we are also >>> stolen ID/PW for DB. >>> If we stolen the key, even if we keep the private key secret, the >>> attacker can connect the NW for anywhere. >>> >>> [2] How we manage a passcode for encrypting private key? >>> so even if openvpn supports encripted keys, when we input the passcode? >>> Vpn process will be launched automatically by neutron-server, so we >>> need to store it in the memory. >>> This is same security with plain private key. >>> For example, most of apache servers using plain private key, I guess. >>> >>> so the security of ssl-vpn impl depends on db, rpc trasport, file >>> system security even if we encrypt the private key or not. >>> may be, we have better way, but I think current design isn't so bad to >>> prevent get merged. >>> >>> Best >>> Nachi >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> 2014-04-28 23:02 GMT-07:00 Zang MingJie : Hi all: Currently I'm working on ssl vpn, based on patchsets by Nachi[1] and Rajesh[2] There are secure issues pointed by mark, that ssl private keys are stored plain in database and in config files of vpn-agents. As Barbican is incubated, we can store certs and their private keys in Barbican. But after checking openvpn configurations, I don't think there is any way to prevent storing private key in openvpn config files without modify the openvpn implementation. I have also made several changes, added a optional port field to sslvpn-connection table, integrated with service plugin framework (I'll follow service flavor framework when it is ready), and completed the neutronclient part. It is already developed in our testing environment, I'll upload my patch sooner or later. [1] https://review.openstack.org/#/c/58897/ [2] https://review.openstack.org/#/c/70274/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
Hi Kyle 2014-04-29 10:52 GMT-07:00 Kyle Mestery : > On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno wrote: >> Hi Zang >> >> Thank you for your contribution on this! >> The private key management is what I want to discuss in the summit. >> > Has the idea of using Barbican been discussed before? There are many > reasons why using Barbican for this may be better than developing key > management ourselves. No, however I'm +1 for using Barbican. Let's discuss this in certificate management topic in advanced service session. > Thanks, > Kyle > >> [1] We are depending DB security, anyway >> When we get stolen the private key in the DB, it means we are also >> stolen ID/PW for DB. >> If we stolen the key, even if we keep the private key secret, the >> attacker can connect the NW for anywhere. >> >> [2] How we manage a passcode for encrypting private key? >> so even if openvpn supports encripted keys, when we input the passcode? >> Vpn process will be launched automatically by neutron-server, so we >> need to store it in the memory. >> This is same security with plain private key. >> For example, most of apache servers using plain private key, I guess. >> >> so the security of ssl-vpn impl depends on db, rpc trasport, file >> system security even if we encrypt the private key or not. >> may be, we have better way, but I think current design isn't so bad to >> prevent get merged. >> >> Best >> Nachi >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 2014-04-28 23:02 GMT-07:00 Zang MingJie : >>> Hi all: >>> >>> Currently I'm working on ssl vpn, based on patchsets by Nachi[1] and >>> Rajesh[2] >>> >>> There are secure issues pointed by mark, that ssl private keys are >>> stored plain in database and in config files of vpn-agents. As >>> Barbican is incubated, we can store certs and their private keys in >>> Barbican. But after checking openvpn configurations, I don't think >>> there is any way to prevent storing private key in openvpn config >>> files without modify the openvpn implementation. >>> >>> I have also made several changes, added a optional port field to >>> sslvpn-connection table, integrated with service plugin framework >>> (I'll follow service flavor framework when it is ready), and completed >>> the neutronclient part. It is already developed in our testing >>> environment, I'll upload my patch sooner or later. >>> >>> [1] https://review.openstack.org/#/c/58897/ >>> [2] https://review.openstack.org/#/c/70274/ >>> >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno wrote: > Hi Zang > > Thank you for your contribution on this! > The private key management is what I want to discuss in the summit. > Has the idea of using Barbican been discussed before? There are many reasons why using Barbican for this may be better than developing key management ourselves. Thanks, Kyle > [1] We are depending DB security, anyway > When we get stolen the private key in the DB, it means we are also > stolen ID/PW for DB. > If we stolen the key, even if we keep the private key secret, the > attacker can connect the NW for anywhere. > > [2] How we manage a passcode for encrypting private key? > so even if openvpn supports encripted keys, when we input the passcode? > Vpn process will be launched automatically by neutron-server, so we > need to store it in the memory. > This is same security with plain private key. > For example, most of apache servers using plain private key, I guess. > > so the security of ssl-vpn impl depends on db, rpc trasport, file > system security even if we encrypt the private key or not. > may be, we have better way, but I think current design isn't so bad to > prevent get merged. > > Best > Nachi > > > > > > > > > > > > > > > > > > 2014-04-28 23:02 GMT-07:00 Zang MingJie : >> Hi all: >> >> Currently I'm working on ssl vpn, based on patchsets by Nachi[1] and >> Rajesh[2] >> >> There are secure issues pointed by mark, that ssl private keys are >> stored plain in database and in config files of vpn-agents. As >> Barbican is incubated, we can store certs and their private keys in >> Barbican. But after checking openvpn configurations, I don't think >> there is any way to prevent storing private key in openvpn config >> files without modify the openvpn implementation. >> >> I have also made several changes, added a optional port field to >> sslvpn-connection table, integrated with service plugin framework >> (I'll follow service flavor framework when it is ready), and completed >> the neutronclient part. It is already developed in our testing >> environment, I'll upload my patch sooner or later. >> >> [1] https://review.openstack.org/#/c/58897/ >> [2] https://review.openstack.org/#/c/70274/ >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
Hi Zang Thank you for your contribution on this! The private key management is what I want to discuss in the summit. [1] We are depending DB security, anyway When we get stolen the private key in the DB, it means we are also stolen ID/PW for DB. If we stolen the key, even if we keep the private key secret, the attacker can connect the NW for anywhere. [2] How we manage a passcode for encrypting private key? so even if openvpn supports encripted keys, when we input the passcode? Vpn process will be launched automatically by neutron-server, so we need to store it in the memory. This is same security with plain private key. For example, most of apache servers using plain private key, I guess. so the security of ssl-vpn impl depends on db, rpc trasport, file system security even if we encrypt the private key or not. may be, we have better way, but I think current design isn't so bad to prevent get merged. Best Nachi 2014-04-28 23:02 GMT-07:00 Zang MingJie : > Hi all: > > Currently I'm working on ssl vpn, based on patchsets by Nachi[1] and Rajesh[2] > > There are secure issues pointed by mark, that ssl private keys are > stored plain in database and in config files of vpn-agents. As > Barbican is incubated, we can store certs and their private keys in > Barbican. But after checking openvpn configurations, I don't think > there is any way to prevent storing private key in openvpn config > files without modify the openvpn implementation. > > I have also made several changes, added a optional port field to > sslvpn-connection table, integrated with service plugin framework > (I'll follow service flavor framework when it is ready), and completed > the neutronclient part. It is already developed in our testing > environment, I'll upload my patch sooner or later. > > [1] https://review.openstack.org/#/c/58897/ > [2] https://review.openstack.org/#/c/70274/ > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
