 Get up here. I just like to go ahead thank the ghetto hackers over there They completely owned my ass last night, and if my voice is a little hoarse, it's their fault Okay, people I'm pretty much here to talk to you about open SSH the description on the talk actually said that I was gonna talk Some about the new privacy guard might happen a little but mostly SSH This is not how to crack SSH. Go ask somebody else. Maybe even ask the ghetto hackers This is SSH on crack This is how to get anywhere from anywhere. This is what to do once you get there, and this is finally Making it easier to do so Basic methodology that we're gonna talk about today step one get yourself a valid path from the client to the server step two once you have that path independently encrypt and independently authenticate with your final endpoint and Finally once you have that link set up forward services over that end-to-end setup now One of the big things that I've done when I've been working on SSH is making it actually usable to do all these things Very pragmatic law if it isn't usable nobody uses it now I'm spending some extra time talking about this because a lot of people here who've ever worked in corporate America have seen really nice really expensive systems that are Complete useless thing because nobody can figure out how to get them to do anything and everyone just makes a little nice hacks around it Cheats around the system and management accepts it because at the end of the day the connections actually work and Business does not exist for security business exists to actually make money Basics bringing people up to speed. Don't worry. This is not another talk about who we're gonna talk about how to make a link Simple local port forward today. We're gonna go a little bit beyond that But for those of the for those in the audience who don't fully know about open SSH We're gonna start a little from scratch first SSH exists to go ahead and forward shells just like tell net you go in you go to the host SSH actually does it a bit better. It clears up a lot of the old issues with regards to Spacing with end curses it clears most of that up. It also does X if you're actually still using X which Anyway No Basically us station to a host X magically works if you have X forwarding set up correctly now The reason X is not set up by default anymore is because there's a pretty nasty security hole In the X protocol every character that's sent and everything that's on your screen is actually accessible by the other side So if you connected to a rooted server that server will be able to see not just the text that you sent It would be able to see everything on your screen in every character that you entered So automatic X support was disabled in modern versions of open SSH Also open SSH allows you to execute single commands on remote hosts and have those appear as if it's local and finally open SSH forward single ports at a time The bullshit geek definition of all this is quote all SSH forage are non-exclusive and non transparent figments of user space ignore that SSH under windows I know a lot of people don't particularly like Microsoft, but the reality is cross platform The ability to use the same solution on every platform including when 32 is pretty nice So there is a package named Sigwin That is a Unix prompt on a Windows machine. It is moderately evil, but it is nice You name works vi works. Yes You can actually control Z out of your commands and it'll work pretty much if you're familiar with Unix You can finally have a useful Unix desktop The reason I use it primarily is I get an actual SSH client. I don't have to deal with secure CRT I don't have to deal with 80,000 Windows popping up. I actually get a genuine system This is better. Thank you for telling me if anything else that the AutoCappins, please know to find me Forwarding shells syntax very simple as stage user at host encryption is triple desk blowfish. Yes authentication Is your standard either RSA or DSA or it uses passwords key generation is pretty trivial either for SSH one Do SSH key gen for SSH to SSH dash key gen dash to TSA Don't worry. You don't need to try to write all this down. The slides will be made available on www.docspara.com But basically this is how you set up a key so that you can log into a remote machine and this is how you Send that key to the other side That's what I have set up on this slide Forwarding commands as stage user at host simply say ls simply append at the end of your string the command that you wish to run SH is fully 8-bit clean which basically means that you really can run arbitrary commands and they will fully proxy successfully now This is going to be used later so that we can go into a host and set up links through it using the 8-bit clean functionality So this is actually extraordinarily useful CD burning over SSH I apologize. I actually can't demonstrate this but the general idea is The standard command to burn a CD is simply make ISO file system throw on the Joliet index of names Throw on the Rockridge index of names pipe that over to the app CD record tell CD record How fast you wanted to burn tell CD record the scuzzy idea of your machine and simply tell it now that you have this information pick up the ISO image off of standard in off of a standard in of course standard ends being fed by the make ISO file system command To Ssh enable that all we do is just add in SSH user at host before CD record All we do is basically change tell our operating system Instead of running a local CD record run it over there The convenient thing now is instead of having 30 machines with 30 burns them because you have 30 people who need to use the same thing There's one machine it has one burner and everyone simply sends their files over to it The encryption comes free the authentication comes free It's moderately convenient plus the fact that everything works under SIG 1 and works over Windows means you can have all your Windows desktops Send files to the one unit system with a burner and nicely enough that machine won't crash like this did earlier File transfer without SCP. I don't know how familiar people are with SCP or SFTP, but the pretty much both garbage and I don't they rarely work They get on your nerves Basically by executing simple standard units commands cat LS tar tail Maybe even DD you can go ahead and you can actually implement the in pretty much everything that you want out of FTP in the SSH framework I'm planning on implementing all of SFTP using nothing more than these commands the advantage being Finally transferring files using SSH will any host that you can SSH into you should eventually be able to transfer a file from No matter what how much or how little is installed on it the default software that's enabled will be function will be sufficient typo This is correct cookie for you forwarding ports a Lot of people get really confused about port forwarding as say choose red host Local forward listen on local 8,000 to what the other side sees as one to set the local host port port 80 You can basically look at the syntax and separate it into listener versus location Whatever comes first is the listener. It's where the listening port is It's where new connections come from if new connections come from my side It's a local port forward if new connections happen on the other side. It's a remote port forward Limitations on port forwards by default only systems directly hosting the listener can connect to it So if I have a local listener on my machine and somebody on my same subnet wants to access it by default They can't that way people can't use me as a bouncing off point to whatever host that I happen to be Connected to for example my mail server or whatnot You can make local forward to public by using the dash G option to SSH But remote ports have to be enabled using gateway ports on the server side. So I can't go ahead have my own So again, I have a web server on my machine. I want my web server accessible on some other machine I can make a remote port forward and I can say make remote port 80 Make remote port 80 equal to my port 80 But the only machine that's actually going to be able to access that web server forward is going to be the machine that I connected to Accessing port forwards. There are a couple ways to handle this first of all You actually just tell your application go straight to one two seven or one Or perhaps you go ahead and you go into your host files. So you basically preempt DNS This is pretty inconvenient and all all hosts that you connect to have to share the same IP Then I'm flexible works for mail works for SMTP works for poppy works for I map Works if you're connecting to a single web server at a time you can go ahead You can have a web server redirected to one two seven or one But it doesn't work too well when you have eight web servers that you want to connect to or you just want to connect To the web in general you don't want to have to say in advance what machine you're trying to get to Furthermore the port forward methodology completely fails for stuff like FTP Solution dynamic forwarding. This is an undocumented feature right now and open SSH 2 9 Dash to 1080 it opens up a sock server in the SSH client Now even though the SSH client goes ahead and demands that you in advance say where you want it to go The protocol doesn't the protocol doesn't care the protocol says when a TCP session is established The destination is set at that time if you have 10 TCP sessions There are 10 opportunities for destination to be established so It'd be really nice since every single time it could be different if applications can go and send say yes This one time. I'm connecting to you. I'd like to be going to CNN this one time I'm connecting to you I'd like to be going to packet storm this other time and so on well Sox is pretty much the simplest possible protocol for doing this It's a few bites the beginning of a TCP session that basically go ahead and say this is where I actually wanted to go Now, I don't know how many people here. I've done socks programming socks programming is so so ridiculously over complicated use Like library preloads and link stuff in and usually socks goes ahead and reduces stability on the client side It's eight bites people if anyone here ever does a socks client, please just just write the eight lines of code it takes to implement it Application support you get in an explorer you get FTP you get instant messengers you get PTP clients naps are worked on it when there still was a napser Dial pad. Yes, you actually do get some variant of voice over IP over SSH using dynamic forwarding It's a generic solution to a very wide problem, which is how do you dynamically set up? Or how do you support protocols that have dynamic destinations that go to multiple sites? And this is basically the solution False in the hack. It is not a full VPN solution. Your network is not isolated You're on the you're both on the network that you're directly connected to and you have this link into the foreign net I maybe I may be connected to Anyway, forget it The big problem is server freeze Ssh is basically implemented with a gigantic select loop. It is not multi-threaded in any shape way or form That's probably a good thing makes the internal code very simple to understand very simple to extend The problem is if any single operation inside of the SSH Damon blocks if any of it freezes waiting for an answer And the entire server process goes just freezes now You can't go ahead and denial a service anyone else this way because SSH forks off other copies of itself But your own client dies So if you have one TCP session that causes a freeze all your other channels everything else freezes as well So it's not perfect Open SSH is better in this regard. It has less calls that end up going to It has less synchronous calls But the one nice thing is you actually do get some modicum of support all the way back to SSH 1.2 point 2 7 That's been a big goal with a lot of my engineering to actually try to head go ahead Support the oldest servers in the book because let's be honest the the old servers are never getting upgraded We can't get them upgraded if there's a root compromise in them How are we gonna get them upgraded so there can be new features for users? So any extra features that I've been working on pretty much been on the client side make the client do more But more intelligence than the client because the person doing the upgrading the person doing the upgrading wants a new feature They want a new feature. They have a personal reason to go out and get it Assisted men has no personal feature that they want or if they do they still have this whole process of updating something on a Production server that's been up for four years. Blah blah blah. Annoying Bottom line upgrading the client if you can is usually a better strategy for actually making stuff work Proxy commands Proxy command is basically the method by which SSH did sock support a proxy command is an arbitrary command that After it's completed leads to the asset leads to the SSH server in an 8-bit path. So If you look there, we have a net cat to port 22 on some random SSH server the response is well Here's your SSH banner as stage 1.99 open SSH 2.9 P1 The idea is you could have some arbitrary tool that does the socks negotiation does the whatever Negotiation that you have to do and in the end gives you SSH 1.9 open at stage 2.9 P1 This way open SSH doesn't need to care what tool you're using to get to the final destination It doesn't need to you to hear about what protocol in the end if it's got a state bit cloud path. It'll go through it Well SSH wants an 8-bit path SSH provides 8-bit paths. Can we go ahead and use SSH to proxy itself? The the answer is yes the correct method to implement to do this is you have the remote side open a port forward to its to an SSH Damon and Connect it on the client side to standard in and standard out now. That's the correct method to implement it I'm not that good of a programmer. Believe me I saw I have a cheap hack. I remotely execute net cat So I remotely execute net cat on a machine that I can actually get to the host that I'm trying to go to So I SSH into my bastion host my one box my nap machine I SSH into that and on there I net cat over to my desktop or to my workstation or whatnot And I net cat to its SSH Damon using net cat base wire mode SSH dash oh proxy command SSH user app proxy net cat to the correct host the correct port and then the user name at the Server or username at the workstation or whatnot. This is a mess. It's completely unusable. I'm aware of this You're aware of this everyone's aware of this. So there's a rather simple much simpler product syntax under development Which is basically SSH dash B proxy user server So SSH dash B my one machine that's actually internet accessible and then some name of a machine behind there The encryption actually happens between me on the outside world and my machine inside my network It does not actually decrypt at the host in the middle The host in the middle is only being used to provide a network accessible path now There's still authentication to the host in the middle. There's still encryption to the host in the middle So as an administrator, I know that there's a guaranteed amount of cryptography going on But as the administrator, I lose the ability to go ahead and Or I lose the risk of having this one machine that has complete ability to decrypt all communications little statistics for you I went into a Very very large bastion host at a major company and it had 75 hundred people at SSH into it. They were using it as they're bouncing off point to go to their workstations to go to the desktops or whatnot 75 people had SSH 10 to other desktops 25 people had all logged into their desktops 10 people had telnet it into other desktops So here you had one machine internet accessible with full decryption full authentication ability to get into a hundred other computers Proxy authenticates the proxy decrypts the proxy internet accessible The moment this machine gets hacked and it will someday That entire network is screwed With my solution that network is not screwed. It was only used as a pathway It could not actually decrypt or authenticate against any machine that it was used as a bouncing off point Now what if there's no internet accessible bastion proxy, you know now what? What you can do with SSH is you can set up what are known as remote port forwards I can we'll just walk through it my machine on the inside of a network that is firewalled SSH is out into my machine at home Sets up a remote port forward says hey machine at home your port 2022 if you get any communications listen send them to me and I will feed them to my local 1270122 When the client wants to go ahead and connect it either uses that really hideous command with host key alias or it just says SH user a proxy use Actually, that's wrong I say goes in that should actually say it goes into itself go into your own port 2022 and Connect against them. Yeah, forget it Bottom line, okay, damn you ghetto hackers damn you No Seriously, the idea is basically to use the keys as your addressing method just go ahead and stop trusting The idea is if you can't trust an IP address You know, oh my god, everyone could spoof this IP everyone could spoof this everyone spoof that don't Connect any IP you want if you can see that your crypto your cryptographic keys said you connected to the right host You know whether or not you're at your destination or not Forget the address is connect to any IP allow remote port forwards allow anything to bounce wherever in the end You know whether or not you're connected to the correct host because of the cryptography not because of the addressing It actually works now you do actually need to check your host key You do need to actually check that the remote machine is who they claim to be You really need to do this when you're forwarding to the local host because as the sage will say You know what this guy could have 80 connections going through local host I'm not going to automatically force a check on host keys to local host So you either have to use the host key alias or use the new concentrated syntax that I just had trouble explaining which sucked To machines both of them are firewall both of them are firewalled against each other Usually the way this is resolved is goes up to management management fights back and forth You open a firewall now you open a firewall now you open a firewall and it just goes on and on and on and eventually Somebody gives in because they're losing too much money whoever loses more money has to go ahead and insecure their network There's a better way Both machines go out Both machines go out to some machine that they can both connect to one machine Sends over its SSH port the other machine connects to the scent over SSH port. They meet in the middle They know they're actually talking to each other again because of the Cryptography if it works they talk if it doesn't work they don't so you have some host in the middle could be in the middle of a 7-11 it could be in the middle of DEF CON and it wouldn't matter because in the end the encryption is end to end this host In the middle is only being used as a pathway and nothing more Um Escape syntax something that's not known about too much SSH actually has a decent amount of live configuration There's a decent amount that you can do while the SSH client is live Hit enter hit till the question mark and you'll actually see that out of your SSH client You can go ahead and have it terminate the connection and suspend and list your forward to connections a bunch of really useless things Sometime in the next few weeks you should be able to pretty much modify any option in the SSH Basically anything that you could do at the command line when SSH started you'll be able to do without having to go ahead Disconnect and reconnect and re-authenticate and redo all of that stuff SU I kind of got a laugh out of this There's a guy outside who has a car and is a license plate says SU route Really cool car really nice car really really really insecure command SU is not secure because you don't actually ever know you're executing SU you go ahead you SSH in December Modest and you connect as your username and You see your shell prompt as your user shell prompt and you ask your shell prompt. Please load SU I Want to go ahead and be a different user. I want to upgrade my permissions How do you know your shells actually executing SU? There's absolutely no reason for you to believe that and in fact a trivial attack against your bash RC a trivial attack Against anything will go ahead and redirect that SU command elsewhere Maybe it'll redirect it to a Trojan desu. Maybe it'll just fail the first time after it gets your password The bottom line is you can't trust SU after your shell has After your shell is run Trojan in administrators personal account and just waiting for them to switch to switch to route is a Absolutely deadly attack. So The solution is you have the SSH Damon execute SU for you now when SSH executes commands remotely it Does not load your bash RC. It does not load anything. That's personally connected to you It checks your authentication credentials and then loads the command period Which means that because SSH D is usually a root-owned process you go from local to remote remote route to Not calling you a second remote route The root-owned process never goes through user level permissions. It goes straight to the user. You really want it to be There's a new syntax being added SSH user plus route So the plus goes ahead and automates that now somebody here thinks that this is wrong or incorrect or whatnot. So I'll go ahead I believe that actually executes commands through the user's default shell So if the users yes, actually, I'm sure of that which is because that's how people implement SCP only shells So it doesn't it doesn't run the commit it runs specifically user shell Dash C then the command that needs to be added. So if it's been false dash C command Well, false isn't going to do anything. So these are still doesn't have a shell Your shell your personal shell is restricted by administrators You have a file Etsy shells in most Unix distributions It limits what you can select as your own personal shell. So you user can't even go ahead and change shell out of That box that you're making them There are problems with this the big problem is that you have to use root passwords You have to have generally a single root password. You can't use the public key method You can use public keys to go ahead and log in as your individual user name But everyone still has to have this route password this route password almost never changes So somebody leaves your company. Guess what they still know root on all your servers One solution that is individual public keys. You can have a large set of public keys able to log into the same account If you have everybody who's individually authenticated to use that root account Actually use their own personal key when they leave you cut their key Are there problems with this? Yes The primary problem being is if people have root on a server ever if they really want to they can never have to leave It's called load a kernel module But it can be a useful technique PPTP over SSH this this is evil, but it is a good example of How SSH is arbitrary functionality is rather useful? PPTP is implemented Let's see how it is Okay, PPTP is a fugly protocol. It is layer 2 PPP inside of layer 3 GRE Which transmits layer 4 TCP UDP and ICMP? traffic It also uses a layer for port 1731 TCP I'm sure I could design a worse protocol somehow I Don't know It was created by Microsoft, which we'll leave it at that The nice thing about it though, it is really really well integrated into Windows it just works One of the more painful things incidentally about any kind of VPN solution is if Microsoft doesn't write it and Do you install it? It has a pretty good chance of blowing up your system Doing any kind of protocol shim in Windows operating system. It either works perfectly or you might as well throw your laptop out It's one of the two I lost two laptops to the Norto client, so I'm allowed to say this So the problem with just going entirely with the Microsoft solution is the crypto isn't very good It's decent version 2 is decent version 1 was kindergarten crypto It was pretty much a good example of every single screw up that you could make You took the key stream going one way you exorted against the key stream going the other way and there were your keys PPTP version 1 was a mess, but again it even it had decent network isolation So you can't trust PPTP's crypto it sucks, but you can't trust SSH's so could you go ahead and use? PPTP's network isolation along with SSH's trustable crypto and the answer is you can Use pop-top requires another machine at the at your site Real operating system you next Sorry for being a little bit of a bigot there Basically pop-top goes ahead implements the listening on 1731 TCP It implements the gearing encapsulation and decapsulation, but it does not re-implement the PPP protocol Instead it just runs the UNIX command that does PPP which is either a PPP daemon, which is a root linking process or Slurp which basically was NAT circa 1995 Slurp was invented so that you could have just have a shell account You could run this command and it would convert everything coming over the line into It would interpret PPP set up the necessary connections But not actually do it at a root level not actually do it at a kernel level just translated All into standard system calls that you could do as any user So either PPPD or Slurp gets executed by pop-top Who says it needs to be local? You don't necessarily need to If you're running PPPD or you're running Slurp Why do you need to run it on your own machine as this H into a remote machine runs Slurp there so Pop-top goes ahead listens for connections receives one Says ah, I now need to parse PPP. Well, how do I do this? I go to that machine on some far away land far away network and I run Slurp over there And suddenly my machine on this network is over SSH network isolated on some completely foreign network And if I use Slurp, I don't even need to be rude on that foreign network Go ahead That's that's absolutely correct. The TCP stream is only used for the control protocol The actual data is the PPP encapsulated GRE So, okay, so pop-top sitting on your sitting on this helper server it Takes the GRE packets coming out of your Windows machine it Strips the GRE Sees PPP takes this PPP attaches it to a PPP daemon on a remote server and So it's just it's just sitting in the middle connecting things This is the really lazy way to go ahead and set this up It's pre-compiled into pop-top to load Slurp you Rename Slurp to Slurp binary and just have the actual Slurp command be a shell script to do a remote execution of This command now the reason I actually went ahead and showed you this is yes Pop-tops open source you can go ahead and modify it Sometimes you have to deal with apps that aren't open source Sometimes you have to deal with apps that just go ahead and feel like shelling out every once in a while Be aware every time you have an app that shells out to a command You can read you can wrap that command with something that executes it remotely and therefore add rudimentary network support to pretty much anything One final thing I'll go over then I'll open the questions Not talking about SSH for a moment As they have some problems just like SSL has problems just like those great nice Custom hardware solutions you see for crypto have problems They're all link-based. They all decrypt the information as soon as it comes back off the wire They all decrypt the information using a key that because it's a link-based crypto the keys online The key is a machine that's connected to the network You have lots and lots of credit card numbers out there that are picked up over SSL and are dumped unencrypted into a database The encryption is stripped off as soon as it hits this this box in the DMZ of some guy of some company's network And then they wonder why they get 300,000 credit card numbers stolen. Well, gee you didn't encrypt them And even if you did you had a key in the same place It's like I put a key in front of your door and then I There's a key in front of your door in the hotel room someone goes ahead says, ah, here's the key opens up But the door was locked the key was right there. What do you expect? File-based systems go it can go ahead and actually separate this out You go ahead. It's called a lock-drop method You go ahead and you have lots and lots of machines that can go ahead and encrypt data They have a public key public keys let you encrypt they do not let you decrypt So you have all your machines that go ahead that you want to go ahead and do lots and lots of encryption Because really encryptions are more common operation than decryption in a lot of contexts You want to store lots and lots of credit card numbers for Often for a long time To actually mass read them how many legitimate uses are there for mass reading 300,000 credit cards emphasis on legitimate So the idea is basically all your machines that are generating logs all your machines that are receiving important data They file encrypt it the decryption key does not exist on those machines In fact ideally the decryption key does not exist on any network So if somebody breaks in they could completely root everything there's no way to get access to the old data It's all encrypted in the decryption key is absolutely nowhere to be found now You can only do this with asymmetric systems. You can only do this with systems based off of Something that has a public and private key if you have something some pure triple desks where there's no use this Use this string of bits to go ahead and encrypt well the same string of bits used to encrypt someone just says great Here's the string of bits. I use it to decrypt public keys get you around that problem and Work should just open up to questions the bottom line what I have with SSH is it's really powerful It's really flexible the bottom line with SSH is that it exists as a Secure and capsulator of a large amount of functionality. It's traditional insecurity that there's a Constant tension between functionality and security the more functionality you open up the less secure you're supposed to be So it's somewhat confusing. Why is SSH successful in what it does? The bottom line is as stage is successful because it implements generic functionality that you don't have to make hacks on to add Best example SSL upload upload over an HTTPS server. Yes. Yes, you can go ahead and you can send information using SSL SSL will just send anything. It's just a stream. It's just a re-implementation of TCP that it's almost accurate The problem is 99% of the CGI scripts that do HTTP upload are completely rootable They they are they they suck and that's because somebody had to go ahead and do use a method that wasn't Conveniently made it wasn't conveniently encapsulated for them SSH does convenient Encapsulation and that's why it works. Well, so questions comments Methods that you wish actually existed to get data from point A to point B. Hit me That would be here. I'll even Docs para comm Backwards paradox go ahead. It's not their fault It's it's not their fault if you connect to a machine and it says the host key changed There are so many situations where the host key actually would have changed that you just say yeah, okay I don't care. I don't care that this machine can't prove it to I think it is I'm just gonna go in anyway because at the end of the day my job is to actually get into this server My job is not to scream and shout about you know crypto. What does everyone say? They just say oh, I can't believe it this machine was broken, you know a admin You're stupid, but I still went in any way that could have been dangerous No, the the actual I'm actually a solution is being worked on There's a system called SRP out there secure remote passwords It does mutual authentication using passwords So if the server actually doesn't know my password SRP doesn't even have make it need to know password SRP Let's it know just a cryptographic hash of that password if the server doesn't have any information about me Then I won't be able to successfully log into it So I get some aspect of something I can remember in my head as opposed to some long Fingerprint string, but something I can remember in my head if the server does not know that or does not know anything about it I won't be able to log into it now if you use that method to authenticate a change in host keys You eliminate 99% of the issues where Where someone will just automatically replace a host key. It's like yeah, you're connected to some machine and Not only doesn't have the wrong cryptographic information. It doesn't know your password Yeah, I'm going away now Good Go to fresh meat search for scp only it replace your user shell with scp only All that we'll be able to do is execute the scp command Security has specific support for it in a unsported patch. It's in the contract directory. Go ahead and compile it I may even be a configure option Generic generic functionalities being added to make it easier to do stuff like security to do stuff like crypto card and whatnot So that's that's been a big issue a lot of places with cause with custom authentication methods So that should be up and running soon But a security is specifically supported go ahead right there Granted, how do you know someone's executing sudo? It's it's the same thing as soon as you lower your permissions to that of a user as soon as you're dependent upon User permission code you're done. You can't upgrade backup successfully. It's a basic precept of security sudo limits the damage that somebody can do but the bottom line is you have a sudo command that only an admin can execute You want there to be the difference between your user account and your admin account if you give your user account extra features then What's the difference about habit? Basically, you need there to be that separation between user and root if it's not there a lot of a lot of unix permission stuff Breaks and you can't get around that. What was the other question? Yeah artist over SSH Or our sink excuse me Use restricted shells like the scp-only shell and Distribute host distribute host keys Email email email me about this later. We'll see if you can come up with a generic solution to it Go ahead Fast no Cryptographic hardware accelerators I believe actually will work with open SSH because open SSH gets most of its crypto out of open SSL I haven't verified that In general though CPUs are getting pretty fast the open BSD team just got. What was it? 2.5 megabit per second triple desk using 1% of a mid-grade pentium 3 So, you know stop late that out. You get about 250 megabit Perfect. No fast faster than you're probably gonna need for anything but a full wire line crypto. Yeah, that'll work Oh, incidentally, you have all these VPN vendors bragging Yeah, we've got something that you can terminate 60,000 connections against Great, so you have one machine that if I break that machine it has decrypted information for 60,000 hosts great The nice thing about my solution is yes, you have pathways to 60,000 other hosts But you don't have any of the data that went through it and you don't have any of the authentication methods through it Good This this is this is the hardware dream This is the dream that if you put the key really really really deep into your hardware Nobody will ever get access to it and I think the perfect rebuttal is anything that has anything to do with direct TV anything Though the bottom line. Okay, the bottom line is Yes Storing something very deep in hardware can be useful But in the end that keying material needs to be accessible to the outside world or else what's it matter great? You have a key you have a set of bits that can't be accessed and it by circumventing the method by which The legitimate bits are read off or the legitimate bits are worked through by Circumventing that and using it in a context that a company didn't expect You often can receive the same the same utility Anyone else back there in the light I Really should have gone into this during this talk. There is a wonderful app out there called mind term It is a full SSH implementation written in Java Somebody has gone ahead and added scp support to mind term So it'll go ahead and actually gives you a decent interface over SSH to throw up files Um user goes to a web page. It loads a Java app the security of the Java app is actually verified by the by code signing and You use that to go ahead and upload your files. That's worked pretty well. What is networks Go ahead curbs one of those things that I Know I know deep inside. It's good I know deep inside it secure, but just the whole concept of one machine that if it's penetrated Everything dies just really seems to bleed single point of failure to me. So I have issues with it personally Other people use it very successfully other people use it in very large scale deployments So SSH has quite a bit of code in it to make that feasible Personally, I have issues with the entire with some of the curbs philosophy, but SSH itself does support what you're referring to go ahead Nobody should but okay, would you rather do SSH one or would you rather do Tal net? One one little political statement SSH comm why guys? Why did you bungle the SSH one to SSH to migration if you ever do anything to do with migration? Please for the love of God be backwards compatible and be upwards compatible if possible What basically happened was this SSH comm comes out with a stage to a complete re-implementation with no new features good job guys Yeah, the entire thing was implemented the entire SSH to protocol was implemented in the SSH one framework You can't do that unless you have no new features. It physically does it code doesn't happen, but They basically set it up So if you upgraded your servers to SSH to suddenly all your SSH one clients started screaming at you If you upgraded your SSH one clients to SSH to suddenly you couldn't connect anywhere So you had this catch-22 situation and it wouldn't end up happening as was nobody ended up upgrading to SSH to Open SSH comes out does nice convenient migration path from SSH one to SSH to by simply supporting both well and It's not the free-ness the free-ness of open SSH is nice But the reason people used open as the people the reason open SSH was migrated to over the SSH to server was because Was because it didn't break everything Go ahead. Yeah, the Cisco rather is don't support SSH to it's a It's it's amazing. They support SSH one at all They barely got that going So but yeah The reason why there is concern about the SSH one protocol is because there are these issues in it that do look like sooner or Later are going to lead to compromise There's huh There's no out of the box penetration of an existing stream the best you can do there There's been some interesting work Determining someone's password by the amount of time it takes between packets when they hit the keys At our cap, what's it do? I mean, I know it's another sniffer, but does that have a special SSH mode to it? It sounds like it's doing the It's it sounds like what you're saying is that it's doing the host key spoofing and waiting for the user to just say I don't care. I want to get into this host even though the host keys don't match As they choose going to be vulnerable to that too In fact about the only really good solution to that is to have SRP support and to use the password to authenticate a change in host keys Well, I mean seriously if I mean at stage one or a stage two if your host key doesn't match and you accept it anyway, you're screwed I'll check it out. Send me an email about it as well Anyone else? Well in that case, it's been a blast