The problem isn't that TCP is assuming an unreliable medium underneath; TCP is as happy to operate over a perfectly reliable IP network as it is to operate over a somewhat unreliable one (significantly unreliable networks outstrip TCP's ability to compensate, mandating solutions like Airhook). The problem is that, when packets are dropped, the nature of the network changes, because both the external and the internal networks move to compensate.
It's the dual adjustment that breaks everything.
You're absolutely right, although what I meant about TCP assuming unreliable medium underneath is the dual adjustment you mention there. I was dead certain you knew all about this already, but my point basically was that if current TCP implementations had a way of informing TCP that the medium underneath is indeed reliable, we wouldn't have this dual adjustment situation.
(Not to mention how nice it would be just to be able to configure it a little bit less humble when it comes to assuming the slightest packet loss being caused by congestion. I'm not saying we should fall back to Reno, but what I'm saying is that we could do better than Vegas...)
Peter Gutmann is a serious expert. I write security code for a living. (For IBM) Peter Gutmann has writen a few seminal papers such as "A Layman's Guide to ASN.1" which is required reading for anyone coming on the team.
Serious experts make mistakes too.
1) Cipe is not dead, on the same page as there was the specification is a link to the mail archives. Far from dead if you look in there.
2) Ranting about Cipe being vulnerable to replay attacks shows that he's missed the point. Cipe was designed to be _stateless_ protocol over UDP, so that it has the exact characteristics that IP has. There are quite enough crypto streams out there, but disregarding IPsec, we don't have that many packet based solutions.
3) Heck, even IP is is vulnerable to replay, and to state the obvious it can actually do that witout being attacked against. There are no guarantees that you wouldn't get duplactes, over and over again even. Thus all protocols that plan on being invulnerable to replaying provide such mechanisms _OVER_ ip.
SSH(which, incidentally, violates Guttman's rules by using "the same key for encryption and authentication") and SSL(which utterly falls apart when the cert gets compromised) both run over TCP. TCP is not IP. TCP adds reliability, through error detection, correction, order management, and congestion management. That's all well and good, but sometimes I really don't care when I drop a packet. Voice traffic is a fantastic example -- by the time the retransmission is complete, the data is stale and irrelevant. But TCP will not only stop to retransmit, it'll hold up everything else while it does so, and even slow down the connection to be sure a dropped packet doesn't happen again.
There are _many_ protocols which can accept these semantics. But there are many that cannot
Dead on! Tcp itself is one such protocol. It assumes unrealiable medium underneath and for that reason tcp over tcp (which is a case when ssh, ssl or other crypto stream is used to mediate ip packets) behave poorly over medium with some packetloss. Say, GSM data for an example of such modern medium, cable modems, random early detection routers, over crowded ISPs.
Claiming replay issues a problem with cipe is same as saying the same about udp.
"The fix for this is to scrap the key exchange portion completely and replace it with an SSH or SSL management tunnel"
that even those protocol contain flaws every now and then, thus for example we use those ontop of cipe or openvpn like mechanisms to achieve double layering in cases were even ssh cannot be fully relied on. And don't I feel good about doing so now. Sadly cipe needs quite a bit of repairing it seems.
Well, at most (depending upon what components are tweaked) Sun only needs to provide modifiied source to those it distributes a modified binary.
That's not the whole truth when it comes to GPL code. Sun cannot ship/distribute GPL binaries/sources with proprietary code. E.g. redhat cannot stuff their homemade module into their distro and start charging for that, not only must it be as-free the sources must also be provided.
So the question remains, how can they as 50$/seat for the code? Support yes, that's what redhat provides also, but for the code, nah.
So, if it's gnome based and all that, then how can it be 50$/seat? I mean, mustn't the sw be downloadable from the net, regardless of how much the "Sun's engineers have tweaked it quite a bit"
Dave's still alive and well - I talked to him a couple of weeks ago.
Actually, it's not necessary to die to be a candidate for a Darwin award. One only needs to be removed from the human gene pool as a result of one's own stupidity. That said, moronic behaviour that results in accidental sterilization and no sperm in bank will do just aswell as getting yourself killed.
I don't want ssh running open to the world all the time, because of things like this; but I also want to be able to log in remotely from varying places with reasonable security. So I've been thinking. Imagine an app like this:
1. Listens on a given port, waiting for a connection. If it receives one, it reads an MD5 hash (and only that amount of data).
2. It computes an MD5 hash of a secret password, and the current time to the minute. It then compares that to what it received in step 1.
3. If they match, it fires off a ssh process listening on a nonstandard port. If they don't match, it locks out the source IP after a given number of failures.
What you describe there actually is having an additional layer there. The problem with time based salting is that for it to work practiacally the time window has to be too large, allowing the same token to be used again quite easily.
If you already have the key at both ends, why not talk using symmetric cryptography straight away, use some proven to be solid cipher, add some salt/nonce, and quickly handshake new keys if needed and it's bomb secure. Naturally your implementation may fail, but that's why you might concider using cipe or openvpn to do it for you.
Another problem with mere remote instantiation is that you have no control over source spoofing and thus an ssh attacker could just wait there for you to spawn the sshd and then attack along side. Thus it's better to really layer then, e.g. ssh over some udp or ip based vpn solution.
Double layers are widely deployed on systems where no single piece of sw can be relied on. One convenient place to place them is the vpn layer. We use cipe, which is a tiny, simple and solid udp/blowfish based vpn solution, on top of which we run ssh, hoping that both of them won't get holes at the same time. Moreover cipe doesn't rely on openssl crypto, thus even the openssl crypto lib wont be a common nominator for ssh and vpn.
Anyone remember the 7 year old kid grabbing the joystick looking at some 3D file manager like thingy in Jurassic Park I. Made me laugh and weap at the same time.
"Me, years of studying physics allows me to convert among numerous units of measure including the ever useful library of congresses, empire state buildings, highways to the moon, and popes in a volkswagon,... To me, 6 tons is about 5,000 kilos (grew up in the U.S., but I think in metric - how screwed is that)"
Years of physics and 6 tons is 5000kg, ask again, how screwed is that?
I actually went as far as his sourceforge site, no mailing lists, but there was one source tar ball... 42Mb! Heh, well, I figured with that kind of web page it's gotta be good, so why not download it aswell. I wanted to see some actual code.
The tar ball container usr/local/lib/site_perl/, 43Mb of 44Mb opened were some skinsets that were definitely worth the peek. They reminded the web pages quite a bit. And understandably there was also loads of perl code, quite a bit of it actually. I did take few quick peeks at various modules, but if you ask me Kernighan was right about perl being a write-only language. Then this jewel caught my eye, the CHANGELOG: 08/25/2003:
GridShell v0.97
Lot's new, including JavaScript Scaleable ImageMap Web-based User Interface, and new SequenceL Language Integration!
02/26/2003:
GridShell v0.857
Still working on data command syntax data structures and command execution routines. First public source release!!!
Poor guy, there actually is quite a bit of perl code written there (143 files and 24145 lines including comments that). That's effort wasted since it's quite apparent that he has a bright future ahead as a web designer.
I must have visitided more than a hundred serious sourceforge sites during the years, but I've never laughed this much. Thanks to the parent post for pointing this out.
Being the Department of Energy I though they would have used AMD chips so they could use the excess heat to drive a power plant.
What's this? Why AMD? So the power plant would be worse than it would be itaniums? Doh. You schmuck, itanium 2 draws more energy than any amd chip so far.
Is to deliver some 1.4.x series... to stabilize the damn thing. ctrl-keypresses have had focus problems aver since alt-keypresses were changed to these windowsy version around 0.9ish and for keyboard oriented sw developers that is a HUUUGE usability issue. The as-you-type search hasn't worked since it got there, it suffers from focus aswell as what-fscking-ctrl-g-and-why-not-another-/-like-mor e-and-less-and-all-others
I mean, it's cool to go with new stuff, but you also need the STABLE branch. There's been quite enough features for quite some time. Java and flash have worked for ages, so what's stading in the way of it?
It's just that I don't understand how come something so essential as keyboard focus and shortcuts can be borked for soooo long. I mean, there are moments when you kick back and surf with the mouse hand alone, but by god there also moments when you do some power googling about some work related stuff with dozens of tabs and wishing one would never have to touch the damn rodent, ctrl-pgup/pgdn, ctrl-l, find-as-you-type and all that is there for it, but noh... they don't work well, and they never get fixed.
It's only funny until someone gets hurt. Then, it's hilarious.
Just so you know, I believe your the quote you're referring to in your sig comes from the Faith No More song Ricochet. If so, you might concider quoting it correctly: "It's always funny until someone gets hurt... And then it's just hilarious !"
Could someone with recent Ati 3D products say a few words about the current state of their linux drivers? Any glitches? Stability? Do they provide OpenGL headers for their libraries? Tv-out functional? etc...
Personally I'm still a content Nvidia user, solely due to their drivers, they even run smoothly on top of 2.6.0-test3 (with the minion.de patch), _but_ I'm seriously thinking about Ati the next time around, which is around the corner as Doom3 comes out, also for linux as you all know.
I am sorry, you crashed and eh, you shot up a lot of thingies because they were shooting at you. Same as in all the other games from ID. None of them has ever had a story, more a pretext.
Quite true. And a thing I think ID shouldn't have underestimated. I mean, I've been a huge fan of ID's games and have played them online for 7 years now, our clan still playing actively in BarrysWorld leagues. That said, I must say that Max Payne really showed what a story line can be and what it can do to the game. It being otherwise completely (inspite of the bullet time trick) typical FPS game had a great feel to it and IMHO the story line and it's illustration was in great part responsible for that.
However, they did succeed beautyfully with Quake 1 without any story line. Judging from later releases that was most likely luck (though huge cheers must go to NiN solist mr.Reznor for the best computer game soundtrack to date) and they probably should've hired more people with more artistic perception and imagination. Being a lower level programmer myself atleast I'm fully aware that I shouldn't write anything that a user (outside of admins with shells) can actually see...
Except Quake 4 is a continuation of Quake 2, not Quake 3.
The story-line may be, but as I see it and probably the most of the Quake community sees it, the whole point of Quake 4 is to get an engine update for the quake online multiplayer gaming. Just as Q2, which wasn't that magnificient as a single player (atleast in comparison to Quake 1), but kicked butt online. From Quake 3 they dropped the single player all together because the only thing community wanted was the online game.
Since Quake 1, ID hasn't put effort in single player experience, but their network engines and multiplayer playability exceeds the other fps online games. Current community that developes the multiplayer mods also plays a huge role here. And no worries there, because considering what kind games have been developed on top of their engines (Half Life, Jedi Knights, Wolfenstein, etc...) I don't think the single player front has much to complain about either...
But I must say that I am bit suspicious about how the Doom 3 itself will work out as a single player experience. Enemy AI is one of the things I'm most worried about, because that has always been an Achillee's heel in ID games.
How about releasing a net patch for the old client to make it net compatible with the remixed Quake 2? That, in theory, should be easier (and better performance) than making the new game backwards compatible.
Excellent point! Especially because the net protocol has gone a long way since Q2. Considering the play feel of quake3, which goes far beyond q2 (which was just essentially spiced up version of QuakeWorld net protocol).
Though, I must say, I haven't heard a word of what it will be like in Doom-engine based games (namely Quake 2 remix in this case), but I'm guessin it will be atleast as good as quake3.
And guys if you want a good solid multiplayer game for linux which doesn't require any prior windows version, try Enemy Territory.
Wolfenstein (and thus also Quake3 based) addon, which was supposed to come out as a full new game ended up being canceled, inspite of that they released the multiplayer part of it for free.
It runs beautyfully on linux and is quite a good game!
Slashdot Mirror
The problem isn't that TCP is assuming an unreliable medium underneath; TCP is as happy to operate over a perfectly reliable IP network as it is to operate over a somewhat unreliable one (significantly unreliable networks outstrip TCP's ability to compensate, mandating solutions like Airhook). The problem is that, when packets are dropped, the nature of the network changes, because both the external and the internal networks move to compensate.
It's the dual adjustment that breaks everything.
You're absolutely right, although what I meant about TCP assuming unreliable medium underneath is the dual adjustment you mention there. I was dead certain you knew all about this already, but my point basically was that if current TCP implementations had a way of informing TCP that the medium underneath is indeed reliable, we wouldn't have this dual adjustment situation.
(Not to mention how nice it would be just to be able to configure it a little bit less humble when it comes to assuming the slightest packet loss being caused by congestion. I'm not saying we should fall back to Reno, but what I'm saying is that we could do better than Vegas...)
Peter Gutmann is a serious expert. I write security code for a living. (For IBM) Peter Gutmann has writen a few seminal papers such as "A Layman's Guide to ASN.1" which is required reading for anyone coming on the team.
Serious experts make mistakes too.
1) Cipe is not dead, on the same page as there was the specification is a link to the mail archives. Far from dead if you look in there.
2) Ranting about Cipe being vulnerable to replay attacks shows that he's missed the point. Cipe was designed to be _stateless_ protocol over UDP, so that it has the exact characteristics that IP has. There are quite enough crypto streams out there, but disregarding IPsec, we don't have that many packet based solutions.
3) Heck, even IP is is vulnerable to replay, and to state the obvious it can actually do that witout being attacked against. There are no guarantees that you wouldn't get duplactes, over and over again even. Thus all protocols that plan on being invulnerable to replaying provide such mechanisms _OVER_ ip.
SSH(which, incidentally, violates Guttman's rules by using "the same key for encryption and authentication") and SSL(which utterly falls apart when the cert gets compromised) both run over TCP. TCP is not IP. TCP adds reliability, through error detection, correction, order management, and congestion management. That's all well and good, but sometimes I really don't care when I drop a packet. Voice traffic is a fantastic example -- by the time the retransmission is complete, the data is stale and irrelevant. But TCP will not only stop to retransmit, it'll hold up everything else while it does so, and even slow down the connection to be sure a dropped packet doesn't happen again.
There are _many_ protocols which can accept these semantics. But there are many that cannot
Dead on! Tcp itself is one such protocol. It assumes unrealiable medium underneath and for that reason tcp over tcp (which is a case when ssh, ssl or other crypto stream is used to mediate ip packets) behave poorly over medium with some packetloss. Say, GSM data for an example of such modern medium, cable modems, random early detection routers, over crowded ISPs.
Claiming replay issues a problem with cipe is same as saying the same about udp.
"For a humorous sample of Rusty's wit, one only needs to look at his email signature"
No pun intented towards Rusty, I do concider him to be a great chap, but to offer a signature as a proof of that?
I've seen tons of humorous sigs here after completely witless posts. And now that I think about it, this post is yet another proof of that concept.
"The fix for this is to scrap the key exchange portion completely and replace it with an SSH or SSL management tunnel"
that even those protocol contain flaws every now and then, thus for example we use those ontop of cipe or openvpn like mechanisms to achieve double layering in cases were even ssh cannot be fully relied on. And don't I feel good about doing so now. Sadly cipe needs quite a bit of repairing it seems.
Fabulous article nonetheless.
apt (for RH) does _just_that_ already and more... say, freshrpms has a very good repository and so does fedora.
But isn't up2date the service they plan on making money with?
Well, at most (depending upon what components are tweaked) Sun only needs to provide modifiied source to those it distributes a modified binary.
That's not the whole truth when it comes to GPL code. Sun cannot ship/distribute GPL binaries/sources with proprietary code. E.g. redhat cannot stuff their homemade module into their distro and start charging for that, not only must it be as-free the sources must also be provided.
So the question remains, how can they as 50$/seat for the code? Support yes, that's what redhat provides also, but for the code, nah.
So, if it's gnome based and all that, then how can it be 50$/seat? I mean, mustn't the sw be downloadable from the net, regardless of how much the "Sun's engineers have tweaked it quite a bit"
Dave's still alive and well - I talked to him a couple of weeks ago.
Actually, it's not necessary to die to be a candidate for a Darwin award. One only needs to be removed from the human gene pool as a result of one's own stupidity. That said, moronic behaviour that results in accidental sterilization and no sperm in bank will do just aswell as getting yourself killed.
I don't want ssh running open to the world all the time, because of things like this; but I also want to be able to log in remotely from varying places with reasonable security. So I've been thinking. Imagine an app like this:
1. Listens on a given port, waiting for a connection. If it receives one, it reads an MD5 hash (and only that amount of data).
2. It computes an MD5 hash of a secret password, and the current time to the minute. It then compares that to what it received in step 1.
3. If they match, it fires off a ssh process listening on a nonstandard port. If they don't match, it locks out the source IP after a given number of failures.
What you describe there actually is having an additional layer there. The problem with time based salting is that for it to work practiacally the time window has to be too large, allowing the same token to be used again quite easily.
If you already have the key at both ends, why not talk using symmetric cryptography straight away, use some proven to be solid cipher, add some salt/nonce, and quickly handshake new keys if needed and it's bomb secure. Naturally your implementation may fail, but that's why you might concider using cipe or openvpn to do it for you.
Another problem with mere remote instantiation is that you have no control over source spoofing and thus an ssh attacker could just wait there for you to spawn the sshd and then attack along side. Thus it's better to really layer then, e.g. ssh over some udp or ip based vpn solution.
Double layers are widely deployed on systems where no single piece of sw can be relied on. One convenient place to place them is the vpn layer. We use cipe, which is a tiny, simple and solid udp/blowfish based vpn solution, on top of which we run ssh, hoping that both of them won't get holes at the same time. Moreover cipe doesn't rely on openssl crypto, thus even the openssl crypto lib wont be a common nominator for ssh and vpn.
won't build on RH9... rh7.3 still compiling
"yada yada yada, so we can expect more from SCO along the lines of big claims with no merit."
Geesh, I could've reached that conclusion even without the yada yada bit.
Anyone remember the 7 year old kid grabbing the joystick looking at some 3D file manager like thingy in Jurassic Park I. Made me laugh and weap at the same time.
"Me, years of studying physics allows me to convert among numerous units of measure including the ever useful library of congresses, empire state buildings, highways to the moon, and popes in a volkswagon, ... To me, 6 tons is about 5,000 kilos (grew up in the U.S., but I think in metric - how screwed is that)"
Years of physics and 6 tons is 5000kg, ask again, how screwed is that?
Lol, what a site that really was!
:
I actually went as far as his sourceforge site, no mailing lists, but there was one source tar ball... 42Mb! Heh, well, I figured with that kind of web page it's gotta be good, so why not download it aswell. I wanted to see some actual code.
The tar ball container usr/local/lib/site_perl/, 43Mb of 44Mb opened were some skinsets that were definitely worth the peek. They reminded the web pages quite a bit. And understandably there was also loads of perl code, quite a bit of it actually. I did take few quick peeks at various modules, but if you ask me Kernighan was right about perl being a write-only language. Then this jewel caught my eye, the CHANGELOG
08/25/2003:
GridShell v0.97
Lot's new, including JavaScript Scaleable ImageMap Web-based User Interface, and new SequenceL Language Integration!
02/26/2003:
GridShell v0.857
Still working on data command syntax data structures and command execution routines. First public source release!!!
Poor guy, there actually is quite a bit of perl code written there (143 files and 24145 lines including comments that). That's effort wasted since it's quite apparent that he has a bright future ahead as a web designer.
I must have visitided more than a hundred serious sourceforge sites during the years, but I've never laughed this much. Thanks to the parent post for pointing this out.
Being the Department of Energy I though they would have used AMD chips so they could use the excess heat to drive a power plant.
What's this? Why AMD? So the power plant would be worse than it would be itaniums? Doh. You schmuck, itanium 2 draws more energy than any amd chip so far.
Is to deliver some 1.4.x series... to stabilize the damn thing. ctrl-keypresses have had focus problems aver since alt-keypresses were changed to these windowsy version around 0.9ish and for keyboard oriented sw developers that is a HUUUGE usability issue. The as-you-type search hasn't worked since it got there, it suffers from focus aswell as what-fscking-ctrl-g-and-why-not-another-/-like-mor e-and-less-and-all-others
I mean, it's cool to go with new stuff, but you also need the STABLE branch. There's been quite enough features for quite some time. Java and flash have worked for ages, so what's stading in the way of it?
It's just that I don't understand how come something so essential as keyboard focus and shortcuts can be borked for soooo long. I mean, there are moments when you kick back and surf with the mouse hand alone, but by god there also moments when you do some power googling about some work related stuff with dozens of tabs and wishing one would never have to touch the damn rodent, ctrl-pgup/pgdn, ctrl-l, find-as-you-type and all that is there for it, but noh... they don't work well, and they never get fixed.
It's only funny until someone gets hurt. Then, it's hilarious.
:
Just so you know, I believe your the quote you're referring to in your sig comes from the Faith No More song Ricochet. If so, you might concider quoting it correctly
"It's always funny until someone gets hurt...
And then it's just hilarious !"
Could someone with recent Ati 3D products say a few words about the current state of their linux drivers? Any glitches? Stability? Do they provide OpenGL headers for their libraries? Tv-out functional? etc...
Personally I'm still a content Nvidia user, solely due to their drivers, they even run smoothly on top of 2.6.0-test3 (with the minion.de patch), _but_ I'm seriously thinking about Ati the next time around, which is around the corner as Doom3 comes out, also for linux as you all know.
How about releasing some quality 1600x1200 or so screenshots aswell. I can't the only one keen on using such screenies as wallpapers...
I am sorry, you crashed and eh, you shot up a lot of thingies because they were shooting at you. Same as in all the other games from ID. None of them has ever had a story, more a pretext.
Quite true. And a thing I think ID shouldn't have underestimated. I mean, I've been a huge fan of ID's games and have played them online for 7 years now, our clan still playing actively in BarrysWorld leagues. That said, I must say that Max Payne really showed what a story line can be and what it can do to the game. It being otherwise completely (inspite of the bullet time trick) typical FPS game had a great feel to it and IMHO the story line and it's illustration was in great part responsible for that.
However, they did succeed beautyfully with Quake 1 without any story line. Judging from later releases that was most likely luck (though huge cheers must go to NiN solist mr.Reznor for the best computer game soundtrack to date) and they probably should've hired more people with more artistic perception and imagination. Being a lower level programmer myself atleast I'm fully aware that I shouldn't write anything that a user (outside of admins with shells) can actually see...
Except Quake 4 is a continuation of Quake 2, not Quake 3.
The story-line may be, but as I see it and probably the most of the Quake community sees it, the whole point of Quake 4 is to get an engine update for the quake online multiplayer gaming. Just as Q2, which wasn't that magnificient as a single player (atleast in comparison to Quake 1), but kicked butt online. From Quake 3 they dropped the single player all together because the only thing community wanted was the online game.
Since Quake 1, ID hasn't put effort in single player experience, but their network engines and multiplayer playability exceeds the other fps online games. Current community that developes the multiplayer mods also plays a huge role here. And no worries there, because considering what kind games have been developed on top of their engines (Half Life, Jedi Knights, Wolfenstein, etc...) I don't think the single player front has much to complain about either...
But I must say that I am bit suspicious about how the Doom 3 itself will work out as a single player experience. Enemy AI is one of the things I'm most worried about, because that has always been an Achillee's heel in ID games.
How about releasing a net patch for the old client to make it net compatible with the remixed Quake 2? That, in theory, should be easier (and better performance) than making the new game backwards compatible.
Excellent point!
Especially because the net protocol has gone a long way since Q2. Considering the play feel of quake3, which goes far beyond q2 (which was just essentially spiced up version of QuakeWorld net protocol).
Though, I must say, I haven't heard a word of what it will be like in Doom-engine based games (namely Quake 2 remix in this case), but I'm guessin it will be atleast as good as quake3.
And guys if you want a good solid multiplayer game for linux which doesn't require any prior windows version, try Enemy Territory.
Wolfenstein (and thus also Quake3 based) addon, which was supposed to come out as a full new game ended up being canceled, inspite of that they released the multiplayer part of it for free.
It runs beautyfully on linux and is quite a good game!