 All right, so this is Alex Boulger. Do you want to? So I think we're going to do your presentation first, and then you can talk about step up down a Linux. Or do you want to do the other one? Let's go this way. OK. So Alex is a repeat presenter from Andrea Python, and he is a super, super fast hopper and night best. And I'm pleased to welcome him to talk about SFLVol, which is a project of his that he's been working on. Thank you. Thank you. You who do not speak French, you do not understand French. You don't understand English. OK, so I'll say that in English. It might be a little bit quirky, I'm not a good English speaker. So SFLVol, I don't know if any of you guys have insisted on being somewhere in your life. But imagine this, you have a company, you have a bunch of servers, and then you have a root password on your server. So take that root password, note it in your memory, then you might lose it at some point. And then you get in the five, six other servers, and you start saying, well, I should store that password somewhere in case I explode or something like that. So you put that in a little file on your C drive somewhere, or home slash home slash stuff. And then you're very careful, so you encrypt that file. And then your company grows, and you have all sorts of passwords on that MySQL server, and then HTTP access and everything. And you still manage that little file because you haven't found anything else. And then you hire that stupid number S, and he comes to your company, so you need to give him access to your password file. Give him the password file. And then, maybe in a Jackass, he just runs away, and he's a bit angry. And then you have to run and change the passwords to all your servers, right? Most of the companies we work with have that password and that's how they manage things. So as some of the companies, we do have something like that. We have a support center, we need to deal with 500 servers. I don't know, something like that. A lot of services like that. So we need to write a tool, and that tool, SFL vote, is an open source tool to manage passwords and credentials for all sorts of different services, for different customers. And we need also the ability to connect to those servers before that asshole goes before us. Remember, he went away with a password file. So at some point, if he has access to the password files, he could memorize them and go the other way. So we have also in there, automatic connection. Okay, I'll just show you how it works, okay? So SFL vote has three parts like that. So by the way, it's all written in Python. It has phone cryptography and it's a client, server architecture. So you have SFL of our server somewhere, and everyone installs clients. And so they share the common package, and we also have a QT4 interface for those of, still live on Windows, things like that, or they want graphical views. Otherwise it's command line interface, and it provides with a library, Python already that can script and have access to passwords. So how do we install the source? You can have more complete instructions on the website. This is a shortcut. So let's go here and assume I've installed my, so I'm in my virtual environment, okay? I've created that already. I'm gonna install the packages. They do that very quickly. And then we're gonna go in the vault and create a new configuration. We're configuring the server now, okay? That's a Pylons application, and it has a simple XLRPC endpoint. So now we created the production.ini file. We're gonna create the HTTPS key here. Okay, with that very sweet line. So it wrote here. So we have production.ini, we have the SSL keys. I should be doing that on two different screens, you understand? But it crashed before I started. So that's gonna set up the database for now in the production.ini. I simply configured a simple SQL-like database, right? And it uses the hosad pm here. And then we're gonna serve. I'm not gonna put that as a demon. Okay, so the server's running. Once you set up your vault, you'll want to create a new user, which is gonna be an admin user. And that admin user will have every access encoded for itself. And you say, well, that's weird. That user is all powerful. So you might wanna take that user, print its key on a paper, and send that to your bank vault because that's your only spare. If you lose any passwords, if you explode and you don't have access to your password anymore, at least somewhere, there's something that can restore your password. So we're gonna set up that. Can you see that? Is it too small? Okay, and I'm gonna use a special... So here I just don't want to override my... So it supports multiple identities. So I can switch from one vault to the other vault if I'm multiple. Okay, so, I want to set up my user. So this way, I'm going to set the URL for my vault and give the user name. So user set up, that means the admin has been created. It's waiting for you to have maximum five or 15 minutes to set up that. We're gonna generate a new key pair. That's stored locally, and it's gonna be encrypted with that key passphrase I type in. So this is only local. The private key never leaves the computer. So you have two parts to crack if you want to go through. Now the vault, if I query the vault here, going to the re-example our PC, the vault is empty. So let's add some content. So the way it's laid out is that we have customers and add a new customer here. Yeah, so that's a new customer. Let's look at the help here. Those are the machine, the functions we have in SFL Vault. You can deal with customers, and then under each customer you have one or more machines. So they're physical or virtual machines. And all these machines have services. So MySQL or SSH for that and that username. That's how it's laid out. And also you have a notion of groups and users. How we refine the access controls. So we created a new customer with that command here. And it automatically adds to the history, the machine add so that you can quickly add a new machine. We're gonna go look at the options for machine add. So we can add, it's the only required one is the name. So you should give it the name and the customer ID, and then you can specify the IP address. That's for tracking purposes. If you wanna remember which machine is, in case I don't switch to the IPs and I don't remember which is one, which is what. So we'll give a name, that's gonna be MyMachine. The IP address, it's gonna be local. That's just for information and location in my closet. Okay, that adds it to the system. And then when we search, well we see the hierarchy there, I think. And it also added the service here. So let's look at how we add some service. You need to specify the URL. That's how we'll deal with any type of information. We're gonna create some special schemas like that in the SSH or MySQL. And we'll have some handlers to automatically connect to those. So I'm going to add a local user I created. Super Bob, okay, on my local host. And, well actually I'm gonna need to give it a group. So let's, oops. I'm gonna group, I'm gonna need to add a group because we'll see just after the way things are laid out. We need to have a group to encrypt things so that we can decrypt them, okay? We'll see that, we'll see that right after. So I'm gonna add here a special super group. Okay, so your access group. This time, it's sending a message to the vault to create a new, I need PKI. So it's a private and a public key that's gonna be stored in the vault for that particular group. And if you want to have access to a group, it will encrypt for me with my public key, which is on, so my user's public key, which is on the server, we're encrypt the group's private key. That's how we're gonna jump and have access to everything the group's been encoded with. So that's being generated on the server. While we wait. Any questions up to now? Yes, sorry, after, yes. Why not using LDAP? So this, you mean for authentication? We're not actually, there's no cryptography in LDAP, but not really, actually here you want to have those two different entities. So you're gonna grab the ciphers that we're gonna be brought to the client and have that users to services mapping. I don't know, LDAP doesn't do a lot of what this does. Yeah. Could it be an underlying store, a hierarchical store of that data? Sorry? Could it be an underlying hierarchical store of that data? Yeah, we'll talk about that later on. Yes. No, I mean, ask the question afterwards. I don't know the answer. Yeah, we'll talk about it. Yes. Thank you. Which one was, how long does it take to generate the key, but I have the answer now. Well, yeah, it depends. It depends on several things in entropy. If you move the mouse a lot, it will depend and it will go faster or faster. You have an assist. Okay, so we have a group here and we want to add a new service. Okay, so I'm gonna grab the service, I got it here. Okay, so that will add service to the machine one for the URL SSH Superbomb and then add to the group one with some notes. And we're gonna type in the password here. It's megabomb, it's gonna be taken up on the screen and then there we go, it's inside. So now if we search for, for example, a closet Superbomb, well, we'll get this one because it matches any place if it matches some permission from there or the service itself. Okay, so just a fun demo here. I'm gonna see that we can fetch from the vault, bring it to the client, everything is decrypted there, so different layers, and we have the password locally. The vault is never, ever able to decrypt anything. It doesn't have enough information to do that. So someone could steal out the server over the database, it would learn only the data structure, so how customers relate to the machines and services, but never a secret would be compromised unless they also stole your key and your machine is separate encrypted with your password. And there again would have only access to what you had access. Okay, so let's add a little fun and we'll add also a MySQL service. That's the account for MySQL on the local machine, it's on machine one, that's the service, the root user on group one, and now it's apparent, this one is the child here, the parent is service one. And the password is, I'm gonna change it after, don't worry, MySQL. Okay, and now we have the hierarchy, whoops, search, so this is a reg x you can put in. How you see it depends here, and if you show, for example, two, it'll show and decrypt, if you don't have access, it'll show access denied. The fun part now is to be able to connect. So I wanna connect to number two, and the thing knows it depends on the first SSH login. So it'll grab the passwords, decrypt them, and then issue all the commands. All the commands to log in, so it'll send the SSH command. This uses PXPEC, so it listens to what's coming in. If you log in with share keys, it'll detect that and say, oh, log in with pre-shared keys. And then wait for the prompt and you can configure that on a service. What'll be the prompt there? Because we have some BSD boxes and they don't have the same prompt, so you can store in the prompt and that is gonna be checked on client side. And then when you have the shell, all of these things is kind of recursive objects. You can have like seven SSH and then they're gonna send the commands to the next one. And also a fun thing, and it was a tricky one, is we have a port forwarding for whatever number of SSH nested connections you want. So it'll kind of create some intermediate port forwarding so that you have a local port to an endpoint, even through eight ports. So that's my SQL handler. Jump to another handler, it'll notice how the password prompt is connected and then it'll know when you're inside the SQL. Also, we've implemented some sweet stuff. It's not all done. That's why I want you guys to punch in. But there's a shell. You know how you escape from Telnet. You have become a little key combination. But you can do that here. I don't remember the keys though. Oh, there you go. So you have a fallback shell. So now you're just putting it inside the SSH connection. You have a shell and you can issue some commands, like get put. So you could go and that uses the fish forward cost. Not perfect, but still. And you could go if you're back in seven hops and then you say, I want that file. Then you can do like this port forward. The first one, no, SSH mount, and then SSH go the other one, SSH mount and do all sorts of awful things. Or you could just pull it out from there right now. Or put it. So when we do that port forwarding magic, it's also possible to span multiple SSH on the local machine so we could have multiple shells on our local machine that are set aside so that we could hop into the eight open connections and then back to our shell. Right? Isn't it fun? Have any questions? Okay, so, yes. You. So what do you mean multi-user? I don't know. I guess not. Oh, you can talk about that later on. I'd be interested. Yes. How many services can you identify? Like you have my SQL, you have SSH. So those things, you can store whatever you want in a database. So it can be a super bob, a skull, slash, slash, whatever. On the client side, you can develop Python. It uses entry points. So plugins, it'll detect those and when you have that handler. So we have different handles. For example, SSH plus PKI. So you can put your SSH key in there, have it decrypted in there. It's gonna be stored in the vault. It's gonna connect automatically also by putting that in temporary file, using that as an identity. And you can go through also some random content or VNC logins or stuff like that. So that's up to you. And the vault doesn't check that. Okay? Yeah. Second question. Is there a way to have, right, so your client connection has to connect to a server, right, or decrypt that? Right. Is there a way to have that connection to SSH? So I'm gonna show you how it works a little bit, okay? Every communication is gone through HTTPS. It uses an XML like this RPC server. And then from your local here, you send a login request and then it's gonna encrypt a token with your user's public key, okay? And then you're the only one who has your private key, so you're gonna decrypt that and send it back. And then you can go on with a little token. That's kind of a cookie, a session cookie. And then your other command is gonna use that. And I'm just gonna go over that. Okay? I don't know if I answered the question. Raise your hand again if it doesn't. So that's how it's laid out. That's your user's computer. So just so you know, the red thing here, that's symmetric encryption. Okay? So you need the same thing to fit in. It's my creation instead of yeah. That's PKI. So see, that's the public key you encrypt things. That's some encrypted things with that public key. That's the key to unlock it, okay? That's a legend. And so you have the user's public key that's on the server and the user's table. And with that you encrypt the group's private keys. And that public key is still available on the server. And with that, you encrypt a symmetric key that'll be used to encrypt the secret itself. Okay? So you need all the chain up to be able to decrypt anything. So if you want that secret service, you need to be in the group. If you're not in the group, if no one has encrypted for you the group's private key, then you're out of luck. And up to that there, you need your passphrase which is in your head, your private key which is on the disk. And you need to be a part of those groups. Okay? What does that, what's the effect or what's the considerations there? Are we you, you, you, you, you? Okay. So what's the side effect of that chain is that if you remove the group's private key you lose every cipher there. You lose every secret. So it ensures that you don't delete anyone from the last one in the group. But also you have that safeguard admin user that you should put in a vault somewhere, a physical vault. So I talked about that already, super admin flag. So yeah, with a log, with a log of everything that happens that's not fully implemented yet, working on that. With a log of every user addition, every services you add and every password you change, you can know at any point in time which users had access to what. Okay? And if you remove someone's access and then you change the passwords, you can be sure that person could not have access to that other password so we can have a map. If the guy runs away and he's a jerk, well you can know with certainty which service he had access through the vault even though he might not have checked them. But those are the systems or the access that you must go and change before him. So we work both ways preemptively so we try to secure things and we have groups to define which access we give to whom. And also we have automatic connection. If something goes wrong, it can go very quickly, change the passwords. That's it. Any other questions? Yes. What's the RSS and PES and memory footprint for the XMORRPC server? What do you mean? PSEUX, grab your RPC service and it will come in. PSE what? It's a pylon application. PSEUX, PSEUX, PSEUX, PSEUX, typewrap, GASER, why is it that? I can answer your question. Any other questions? Yes. Go back to your previous slide. I suppose there's several containers for server secret. Sorry sir. Sorry? I suppose there's several server secret containers for groups. So that's the kind of, see you have many, many here. So one user can be in one or many groups. Each of the services can be in one or many groups also. So you can have that little tiny group for that particular user. You have one service you have access to or you have that, that's what we use. You have the support center that has all the passwords and certain groups that need to work on certain things. Yes, very, two last questions. So you demonstrated SSH and MySQL, what other enders do you own the app? So we have MySQL, we have PostgreSQL. We have some experimental things for a Chiquipee because you have to route the web page and it's in the password, it's a bit risky. And we have, yeah, we'll see that. I'll show you after. Mostly, those are the ones you use. VNCs and development also. And our desktop, we try but it's not. Yes? Do you have honorables? No, it's a simple script and then you add what you're listening for and then you'll receive a service object which has the encrypted information and then you actually add if you want. An object that receives and provides things. So it asks for a shell and provides them whatever thing. And it's a bit, yeah, it's recursive so we have to think about it twice, but it works. Well, thank you very much. Yes, oh, sorry, last one. Fuck. Does the protocol, other than by virtue of using SSL, protect against man-in-the-middle attacks when exchanging keys at the top of it? When you log in, if you sign a session token, send that back. Is there any man-in-the-middle potential against that? We're using HTTPS here. Yeah, there was some recent issues about that where you could inject stuff and take over accessions. Okay, so you inject it and then we'll try to fix that. Okay, there you go, I'm done. Well, thank you very much.