17:04:23 <hyakuhei> #startmeeting openstack security group
17:04:24 <openstack> Meeting started Thu Oct 16 17:04:23 2014 UTC and is due to finish in 60 minutes.  The chair is hyakuhei. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:04:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:04:28 <openstack> The meeting name has been set to 'openstack_security_group'
17:04:37 <rlpple> #info
17:04:42 <hyakuhei> Hi all, sorry I'm late, how is everyone ?
17:04:54 <tmcpeak> woo \o/
17:04:59 <sarnold007> Helllo
17:05:16 <bknudson> hi
17:05:48 <hyakuhei> Great, so agenda wise I don't have a big list as I've been tied up in stuff this week
17:05:58 <hyakuhei> I'd like to talk about Swift encryption and the elections
17:06:00 <hyakuhei> what else?
17:06:05 <nkinder> poodle?
17:06:10 <nkinder> ossn status
17:06:18 <shohel02> threat modeling status
17:06:19 <hyakuhei> Great
17:06:45 <hyakuhei> Ok well lets plough on then I guess.
17:06:56 <hyakuhei> Who's been following the swift encryption spec?
17:07:04 <nkinder> I've looked it over a bit
17:07:09 <hyakuhei> #link https://review.openstack.org/#/c/123220/
17:07:12 <tmcpeak> still meaning to do a thorough review
17:07:22 <hyakuhei> It got pretty messy between patchsets 3 and 4
17:08:14 <hyakuhei> There's a few things that are a bit off or not in line with best practice, I'm hoping the OSSG can help with this.
17:08:56 <hyakuhei> If no one has any opinions they want to share we can move on :)
17:09:06 <notmyname> unfortunately, I'm in a meeting right now and can't fully participate here, but I'm talking with sam about it
17:09:54 <hyakuhei> cool, thanks notmyname - my feeling is that there's alot of good thinking there
17:10:35 <hyakuhei> notmyname: let me know if I can help
17:10:53 <hyakuhei> I guess we'll move it on to the Elections then
17:11:00 <hyakuhei> #topic elections
17:11:25 <bdpayne> hey guys
17:11:34 <bdpayne> so we have an election now with two people in the running
17:11:38 <hyakuhei> So far we have two candidates, myself and Cody Bunch from Rackspace (one of the authors of the security guide)
17:11:48 <bdpayne> yeah, what he said
17:11:52 <hyakuhei> :)
17:12:01 <tmcpeak> how do we vote?
17:12:17 <bdpayne> You will get an email with instructions next week
17:12:20 <bdpayne> Monday, if all goes well
17:12:27 <tmcpeak> cool
17:12:32 <bdpayne> it will be just like voting for a PTL or TC member, if you'd done that
17:12:33 <rlpple> k
17:12:52 <hyakuhei> It'd be good to hear more from the community about what they want for the next release. In addition to what I put in my email I also want to get more official recognition by OpenStack as we've consistently shown benefit to the community :)
17:12:54 <bdpayne> right now we are sorting out who is allowed to vote
17:13:07 <hyakuhei> bdpayne: Any problems getting that sorted
17:13:22 <bdpayne> it's just some leg work... but we can build on what I did last time so it should be pretty managable
17:13:36 <bdpayne> we tried to broadly define an active OSSG participant
17:13:49 <bdpayne> which means identifying those that fit the criteria takes some searching :-)
17:14:03 <hyakuhei> Cool
17:14:08 <tmcpeak> bdpayne: if you want help with legwork I'll pitch in
17:14:14 <bdpayne> I encourage people to review the criteria on the wiki: https://wiki.openstack.org/wiki/Security/OSSG_Lead_Election_Fall_2014
17:14:31 <bdpayne> if you think that you should be allowed to vote, please feel free to drop me a line with the evidence
17:14:34 <bdpayne> that might save us some time
17:14:34 <hyakuhei> So Tim (tkelsey) who isn't here right now, has a script for doing some indexing of OSSG members, used it to work out how well (or not) we react to the SecurityImpact tag
17:14:40 <hyakuhei> ^ Potentially useful
17:15:02 <bdpayne> shohel02 will be helping me with this, I believe... but I'll let you know if we need more help tmcpeak, thanks
17:15:15 <tmcpeak> bdpayne: ok cool, sounds good
17:15:23 <shohel02> my pleasure bdpayne..
17:15:25 <bdpayne> ah yes, I have a similar script I wrote for this last time around
17:15:30 <hyakuhei> Awesome, thanks bdpayne, shohel02 tmcpeak
17:15:35 <hyakuhei> Figured you would bdpayne
17:15:40 <bdpayne> so that's all I have unless there are questions
17:15:56 <hyakuhei> ok cool, thanks for this guys!
17:16:01 <hyakuhei> #topic Poodle!
17:16:13 <dg__> yay poodle
17:16:16 <hyakuhei> So my read is the world is ending again, right?
17:16:26 <nkinder> So, the big question is "Should we issue an OSSN for this?"
17:16:26 <bknudson> is there an attack on the client, too?
17:16:33 <tmcpeak> nah, upgrade to Win7, you'll be fine
17:16:40 <bdpayne> lol
17:16:42 <hyakuhei> nkinder: I think we should
17:16:44 <tmcpeak> :D
17:16:52 <bdpayne> I think the thing with POODLE is that mediation takes some thought
17:16:57 <bknudson> there will likely be an ossa
17:17:01 <bdpayne> an OSSN could be useful
17:17:01 <hyakuhei> Plenty of ways OpenStack can be affected, mediation is expansive
17:17:09 <bdpayne> an OSSA, really?
17:17:23 <nkinder> yeah, I'm not sure there will be an OSSA
17:17:26 <hyakuhei> +1
17:17:37 <bdpayne> lol, all of you guys with your inside knowledge
17:17:43 <bknudson> I don't want to say too much
17:17:48 <bdpayne> fair enough
17:17:51 <dg__> I would be surprised if there is a OSSA, they seem very reluctant to issue them that seems operational
17:17:54 <bknudson> although it should be obvious
17:18:17 <dg__> omg, I have lost the ability to write in sentences, apologies
17:18:22 <nkinder> So regardless of OSSA, there are a lot of areas outside of OpenStack that need proper cipher configurationb
17:18:28 <hyakuhei> +1
17:18:41 <hyakuhei> And some areas where there's not a brilliant option today, like Pound.
17:18:48 <nkinder> So an OSSA doesn't entirely solve the issue
17:18:59 <hyakuhei> (Unless you class going straight to TLS1.2 as brilliant, which I do)
17:19:06 <hyakuhei> +2 for a Poodle OSSN.
17:19:09 <nkinder> So areas to cover would be eventlet, httpd, nginx, pound, stud, and HAProxy
17:19:12 <dg__> +1 for TLS1.2
17:19:37 <bdpayne> nkinder also client side
17:20:09 <hyakuhei> So kinda
17:20:23 <hyakuhei> For a project like OpenStack, I agree you need to address client side too
17:20:47 <tmcpeak> is it similarly vulnerable?
17:20:52 <bdpayne> also for people that have clouds that have clients that reach outside of the cloud for services like ldap, syslog, etc
17:20:55 <hyakuhei> but for most deployers, they only care about server side. If you fix taht everywhere, you don't need to worry about the clients connecting right?
17:21:03 <hyakuhei> bdpayne: good point
17:21:09 <bknudson> is there an actual attack on the client?
17:21:13 <bknudson> from a MITM?
17:21:20 <bdpayne> you need either the client or the server to be fixed
17:21:40 <bdpayne> if they are both not fixed, then you can get downgraded and attacked
17:21:58 <bdpayne> so if the only thing you control is the client, then you are best advised to fix the client
17:22:01 <rlpple> right if the client is compromised, then info is leaked
17:22:09 <tmcpeak> I thought the attack involved javascript running on the client side to send to a different server, what's the flip side of that?
17:22:10 <rlpple> if the server compromised same
17:22:18 <bdpayne> i.e., go configure your web browsers now ;-)
17:22:36 <bknudson> the clients in openstack can be the python libs.
17:22:39 <hyakuhei> tmcpeak: that's the demo of the vulnerability in the protocol but there are likely other exploitation vectors
17:22:42 <bknudson> and the CLIs
17:22:45 <tmcpeak> ahh
17:23:04 <tmcpeak> yes, I guess compromised server code could do the same
17:23:09 <bdpayne> so yeah, the openstack python clients are certainly worth discussing in this context
17:23:19 <bdpayne> along with other services in the cloud that act as ssl clients
17:23:42 <nkinder> So there are a lot of scenarios to cover, and I don't think we can cover everything in detail.  The scope is just too large.
17:23:49 <bdpayne> right
17:24:03 <hyakuhei> Well focus on the fundamentals
17:24:07 <bdpayne> I would shy away from talking about specific technologies in this one
17:24:11 <hyakuhei> or maybe even on detection/verification
17:24:16 <bdpayne> i.e., don't say how to fix nginx
17:24:26 <hyakuhei> How to verify with s_client for instance
17:24:35 <bdpayne> but say more generally that you need to disable sslv3 and/or use the new handshake protocol
17:24:38 <nkinder> ok, so a "disable SSLv3" recommendation essentially
17:24:46 <hyakuhei> bdpayne: the security guide addresses configuration of at least three SSL terminators
17:24:46 <bdpayne> s_client verification is a very good thing to mention, yeah
17:24:50 <shohel02> regarding mitigation approach... is there any solution other than not using SSL3.0
17:24:59 <dg__> not really
17:25:01 <bdpayne> yes
17:25:01 <nkinder> and call out where SSL might be used in OpenStack so people have some idea of where they need to look
17:25:09 <hyakuhei> OpenSSL just released an update
17:25:13 <dg__> bdpayne go on
17:25:15 <hyakuhei> nkinder: +1
17:25:17 <bknudson> do you think openstack should now default to not allow SSL3.0?
17:25:26 <tmcpeak> there was some packet fragmentation approach that mitigated it
17:25:28 <bknudson> maybe OpenSSL will do that for us.
17:25:31 <bdpayne> TLS_FALLBACK_SCSV
17:25:33 <chair6> there is an alternate remdiation to protect downgrade of TLS -> SSLv3
17:25:36 <chair6> yeah, that ^
17:25:46 <bdpayne> I am personally not a huge fan of this
17:25:51 <chair6> but disabling SSLv3 is still the best approach
17:25:55 <bdpayne> but it will get deployed and it will do the trick... at least for now
17:26:22 <tmcpeak> not packet but bloc
17:26:22 <tmcpeak> k
17:26:29 <bdpayne> I have found that you can disable sslv3 and still get very nice client compatibility by keeping the sslv23 handshake option enabled
17:26:49 <bdpayne> b/c poodle affects the protocol, not the handshake
17:26:51 <tmcpeak> is 2.3 for sure not vulnerable?
17:26:56 <hyakuhei> What clients _have_ to use SSL3 ?
17:27:01 <bdpayne> ie6
17:27:10 <nkinder> yeah, IE6 is the one that I know of
17:27:13 <hyakuhei> Right, that's very application specific
17:27:17 <hyakuhei> i.e Horizon
17:27:23 <bdpayne> for those that want a useful technical writeup, I recommend https://www.dfranke.us/posts/2014-10-14-how-poodle-happened.html
17:27:37 <hyakuhei> Only affects govt sector I'd imagine
17:27:39 <bknudson> I've been assuming that client compatibility for the REST APIs isn't going to be a big deal.
17:27:49 <nkinder> So who has the cycles to write up an OSSN for this?
17:27:55 <hyakuhei> Everyone else isn't 10 years behind
17:27:57 <nkinder> bknudson: +1
17:28:10 <nkinder> hyakuhei: 10 is being nice... :)
17:28:16 <hyakuhei> nkinder: Throw it on the stack, I'll find someone to do it
17:28:20 <hyakuhei> nkinder: yarp!
17:28:24 <bdpayne> I might be able to do it
17:28:32 <bdpayne> I'm spending the day dealing with some customer communication around this
17:28:37 <bdpayne> and that actually fits in nicely
17:28:39 <bdpayne> :-)
17:28:44 <hyakuhei> Sweet
17:28:52 <nkinder> bdpayne: great, thanks!
17:28:56 <hyakuhei> #action bdpayne to write a story about poodles
17:29:03 <bdpayne> heh, my life story
17:29:12 <hyakuhei> o.O
17:29:25 <bdpayne> nothing to see here... carry on ;-)
17:29:28 <hyakuhei> ok, what's next peeps - OSSN status?
17:29:39 <hyakuhei> #topic ossn status
17:30:34 <nkinder> here's the current queue - https://bugs.launchpad.net/ossn/
17:31:03 <nkinder> hyakuhei: you have a simple whitespace issue to fix up for the legacy notes
17:31:12 <nkinder> hyakuhei: do you want me to take care of it today?
17:31:19 <nkinder> I'd like to get those merged
17:31:49 <hyakuhei> nkinder: If that's  all it needs sure
17:31:53 <hyakuhei> Thanks
17:32:10 <nkinder> 0025 is close, but there was a -1 added there - https://review.openstack.org/#/c/117928/
17:32:27 <nkinder> It seems that Stuart wants it to be more obvious that this only affects multi-tenant mode
17:32:45 <nkinder> That should be a minor tweak for Nathaniel to make, then this should be ready to close out
17:33:07 <hyakuhei> Great
17:33:16 <nkinder> so here's 0025...
17:33:17 <hyakuhei> sicarie: Can you get that done?
17:33:18 <nkinder> #link https://review.openstack.org/117928
17:33:51 <nkinder> Tim also has one out for review...
17:33:53 <nkinder> #link https://review.openstack.org/128636
17:34:04 <nkinder> So if anyone is itching to review something, please have at it :)
17:34:21 <sicarie> hyakuhei: yep, I'll get that out in the next 2 hours
17:34:26 <hyakuhei> Great, thanks sicarie
17:34:27 <nkinder> I added a new Cinder one to the queue as well this week
17:34:50 <nkinder> #link https://bugs.launchpad.net/ossn/+bug/1329214
17:34:51 <uvirtbot> Launchpad bug 1329214 in cinder "tgtadm iscsi chap does not work" [Critical,Fix released]
17:35:14 <hyakuhei> Saw that, I think we had a similar one recently?
17:35:21 <nkinder> It seems like a pretty simple one with a fix that is on the way.  It's really just something we should raise awareness on and recommend updating to get the fix.
17:35:23 <hyakuhei> Bug I mean
17:35:33 <hyakuhei> cool
17:35:40 <hyakuhei> Anything else nkinder ?
17:35:51 <nkinder> No, that's about it on the OSSN front right now
17:36:12 <rlpple> need to step away.  will look at the review list.
17:36:25 <hyakuhei> #topic Threat Modelling
17:36:31 <hyakuhei> shohel02: You're up :)
17:36:33 <shohel02> yes
17:37:00 <shohel02> threat modeling template and process docs are still in review
17:37:19 <shohel02> we have added threat modeling report for keystonemiddleware
17:37:34 <shohel02> so show how the template and process can be used
17:37:38 <shohel02> updated in the new patch
17:37:54 <shohel02> https://review.openstack.org/#/c/121034/
17:38:03 <hyakuhei> I've reviewed that, it'd be good to get more eyes on
17:38:14 <shohel02> definately
17:38:39 <shohel02> i think keystonemiddleware case can give some insights ...what it looks like
17:39:16 <hyakuhei> would be a good thing to get bknudson to look at perhaps ?
17:40:13 <shohel02> definately keystonemiddleware devs can help
17:40:15 <bknudson> I'll add it to my list
17:40:21 <hyakuhei> Thank you :)
17:41:30 <shohel02> others review also welcome
17:41:42 <nkinder> I wonder if it's possible to have the threat modelling docs built as a part of the gate job
17:42:00 <nkinder> It would make it easier to review the end content
17:42:07 <bdpayne> yeah, that would be nice
17:42:25 <hyakuhei> +1
17:43:06 <shohel02> nkinder: what does this mean..during spec writing process
17:43:10 <nkinder> I know that the keystone dev docs work that way
17:43:39 <nkinder> shohel02: take a look at this review for an example... https://review.openstack.org/#/c/124095/
17:44:08 <nkinder> If you click on the 'gate-keystone-docs' job, it brings you to the built docs using the patch
17:46:08 <shohel02> okey
17:46:23 <hyakuhei> Interesting idea, certainly would make reading through them easier
17:46:31 <nkinder> shohel02: that doesn't block your work, but it really helps when reviewing
17:47:00 <shohel02> yah looks promising... may be we get more involvement by that
17:48:33 <nkinder> Are there any topics to discuss around the Summit?
17:48:45 <nkinder> such as a VMT/OSSG get-together?
17:48:52 <hyakuhei> Swift crypto, Bandit Integration, VMT+OSSG
17:49:06 <hyakuhei> Oh to discuss now? I'm not sure
17:49:14 <nkinder> yeah, I meant now
17:49:20 <bknudson> is ossg on the schedule?
17:49:25 <bknudson> do we have a slot?
17:49:32 <nkinder> No, not out own
17:49:43 <nkinder> We were invited to participate in the VMT slot
17:49:47 <hyakuhei> Despite trying, VMT have offered to combine theres with ours
17:49:54 <hyakuhei> Which was nice
17:50:19 <nkinder> I also asked for our own table to have informal discussions and meet up, but we won't get our own officially.
17:50:34 <nkinder> We can slap a sign on one to lay claim to it though
17:50:39 <hyakuhei> Yeah, I like bdpayne's idea of having our own little track
17:50:52 <hyakuhei> Maybe we should consider some informal lightning talks or something
17:50:57 <hyakuhei> crazy ideas etc
17:50:57 <bdpayne> :-)
17:51:01 <nkinder> We should figure out a schedule for that
17:51:05 <hyakuhei> +1
17:51:09 <hyakuhei> Tuesday most likely
17:51:10 <shohel02> slap a sign on+
17:51:54 <nkinder> Yeah, I need to look at the schedule, but I think W-F is when I'm most busy in Keystone stuff
17:52:14 <hyakuhei> IIRC Security is M W
17:52:20 <hyakuhei> but that's without checking
17:52:45 <nkinder> hyakuhei: you mean the official sessions, not design stuff, right?
17:52:51 <hyakuhei> YEh
17:53:20 <hyakuhei> ok, so we need to work out when is the best time for us to sit down together
17:54:29 <hyakuhei> #topic any other business
17:55:21 <nkinder> nothing else from me...
17:55:54 <hyakuhei> Cool, well I guess we can call that a wrap then, thank you everyone!
17:55:57 <bdpayne> I guess it's back to attacking poodle
17:56:03 <hyakuhei> #endmeeting