Actually, yes, you can. Not as easily, but it's certainly possible.
Remember, this was a network built to survive a nuke. Don't you think the routing architecture accounts for that?
For a trivial example, take "IP anycast" -- you can have one IP address which routes to different places, depending on where you physically are. And it's possible for one to fail, and for a router in between to notice, and route people to one of the live ones.
Note that this "router in between" isn't one gigantic router -- it's whatever router happens to be between the user and the dead IP, which also knows of an alternate route to the same IP.
In other words, yes, if the linksys router in your house fails, you won't be able to get online. But even if your whole ISP dies, you can likely switch to another ISP, and still get to the website in question.
Load balancers. Same deal as with routers.
Indeed, only moreso -- as load balancing, to an extent, can be done client-side. Aside from round-robin DNS, there are AJAX libraries that will do this.
Database Servers.
Read about Google's BigTable, Amazon's Dynamo, and open source projects like CouchDB.
And, if you're tied to an actual SQL server, read up on sharding -- normally done at the application level, but there are tools which can do it for you.
So, actually, you had much more of a point with your argument about routers and load balancers.
But assuming you're still thinking of MySQL replication...
Too many transactions to stream over any kind of link. Face it, you eventually hit too much latency...
Latency != bandwidth. As long as you have enough bandwidth, the latency only matters if it's too slow for the actual client request. (What do I care if it takes 100 ms for you to render my page?)
thanks to the speed of light
BAHAHAHAHA.... oh wait, you were serious.
By my calculations, it's not even 1 millisecond to send a photon around the planet. Maybe I'm off?
No, it's the speed of electricity, which is slowing you down in plenty of other places, too.
Now, if you need the transactions to be absolutely synchronous across the entire database, then you're absolutely right. But see above, at least the bit about sharding. Suppose there's a million accounts in the system -- there's no reason a transaction involving a transfer between 2 accounts needs to lock up the other 999,998 accounts. And no one account is going to have so much traffic that network latency is going to be an issue.
As others have said, that model is great for distributed computing where each transaction is non-mission-critical.
And as others have said, it's also great for distributing computing where most transactions are mission-critical (see Amazon). It just has to be tuned differently.
banking is the obvious one.
Banking is more an example of a place where...
Alright, try this for a moment -- assume I'm right, and assume it's easy for any technical person to understand. Do you think banks would switch to it?
I doubt it.
I do think banks could benefit as much from "the cloud" as anyone else, and that it would increase (not decrease) their reliability and availability. The additional speed, if any, would just be a nice side effect.
You sure don't have a bookmark there if you haven't visited it before.
Fair enough.
Which also implies two things: Either every self-signed SSL site I visit will be dropping a cert permanently into my cache (and what happens when that expires?), or it's possible for certs to expire (either their date expires, or my cache purges them for inactivity).
In the first case, that would work, but it bothers me -- though unlikely, it's possible someone could set up a DoS which redirects to an infinite number of subdomains (each with their own cert), thus filling up my disk with useless certs. (With normal SSL, I can safely drop a cert from the cache, as long as I keep the known-good root certs.)
In the second case, every time a cert expires, it's possible for me to be pwned. I'll agree that's not often, but it does bother me.
While I'm at it, I should point out another potential problem: SSH does exactly what you're suggesting, and I do often simply accept new SSH host keys. The problem arises when an SSH host key changes, for whatever reason -- you reinstalled the OS, or you upgraded and Debian killed the key (to clean up after the openssl vulnerability), or whatever.
I think at this point, there would still be a problem of a large number of false positives -- of people needing new certs, for whatever reason, and if they're too cheap to pay $20 (or nothing), how likely is it that they'll be able to properly manage their own little CA?
Which can leave you in the uncomfortable situation where some forum site you like has had to generate a new cert. Do you trust the new cert? With real SSL, yes, because the CA has already done the checking for you. With this, you have to either assume you're MITM'd (and check it from somewhere else), or you have to assume the site admin screwed up (in which case, you're open to being MITM'd again, and may as well have stuck to vanilla HTTP.)
First: Normal SSL also protects you the very first time. If I buy a new computer, and open it up, and type https://mail.google.com/, I'm reasonably sure it will go to the right place.
The question is, knowing full well that the user is going to get a nasty warning about your self-signed cert, versus not see anything out of the ordinary if they just didn't use HTTPS at all, why would the proprietor of paypals.com bother with SSL?
Granted, it's a bit of extra training, but it is possible to check for it being SSL, and having a green bar.
That said, it is an important point, and difficult to solve.
Did the MBTA learn a lesson here about making a mountain out of a molehill?
Unlikely. And, unfortunately, the "hacker" responsible seems to be more interested in his own personal integrity than in teaching them that lesson...
You see, he said, very clearly, that he'd be sharing no details which would allow someone to trivially cheat the system. He sent them documents showing everything he knew, and explaining that he wouldn't be sharing all of this in his talk.
And the asshats still decided to call the FBI, and to sue him.
If this was me, at this point, I'd say "OK, you blew it, this is all going up on wikileaks. And it's going up there because you were asshats about it."
I haven't tried it, only skimmed the review, but I'm guessing this is like those panoramic bubble photos -- that is, if you have a bunch of pictures that fit together, it'll let you turn your head around.
What I kind of doubt is that it'll turn it into actual 3D, as in, polygons and such.
If it could, well, it would greatly simplify modeling in some places. Find a cool, old building that looks like you want your game to look, snap a few photos, and hey, presto, instant level design!
The problem for me as a site developer is that my company self-signs a lot of certificates for our test servers as several of our clients have requested that the test server behave exactly like the production server (which, in fact it probably should if you want to get into it).
We actually bought a certificate for our staging server. They're cheap enough.
However, it's really not that difficult to, say, create an untrusted CA (to sign all those "self-signed" certificates) and add that as a root cert to Firefox. One step, and suddenly all your SSL test sites will work without a problem.
So, now that Firefox has made it extremely painful for me to test my SSL test sites; I don't. Just think about that when you complain that a site looks like s in firefox.
Yeah, I will. I'll think "What a lazy developer!" The only difference will be how you're lazy -- others don't care to learn about Firefox and web standards, whereas you don't care to learn about how SSL actually works.
It is better to inform the user why this is dangerous/stupid/embarasing and let him or her make up their own mind.
I agree, in theory.
In practice, even here on Slashdot, there's still actually debate about whether we should trust sites that do self-signed certificates. So I have no faith that on reading this:
any communication he or she has is encrypted, but that the receiver could be anyone.
What this effectively means is that the communication may as well not be encrypted, and that is what the user should be made aware of.
Saying "the receiver could be anyone" isn't clear enough -- and Joe User, skimming through it, is going to go "Well, yeah, I can see who the receiver is, it's paypals.com! They wouldn't lie to me..."
I found the wording on the Firefox SSL certificate warning page to be rather over the top, and rather vague at the same time.
Maybe it could be clarified, but it's not over the top at all. It's just accurate.
A self-signed certificate is not bad, it still allows secure data transfer between the client and the server, however it loses the verification of the server aspect - which you may not even care about.
If you don't care about that, you may as well be using vanilla HTTP. Encryption without authentication is pretty pointless -- it'll protect you from passive sniffing, but most places people can do passive sniffing are also places where they can easily do an active man-in-the-middle attack.
At which point, you'll have a really secure, encrypted connection to your attacker, who has his own secure, encrypted connection to the self-signed site. Good job!
For those who don't understand sarcasm (or on the offchance that the parent wasn't joking), FF2 always had this, and in fact, the feature itself (though not always as visible) goes back to the original Mozilla, at least. I'd guess they took it from Unix tools like less and vim.
"You have tried to access a secure site with a dodgy certificate, Cancel or Allow?"
That's what IE says, actually. FF3 says "You have tried to access a secure site with a dodgy certificate. This is a bad idea, and we're not going to let you do it unless you really know what you're doing."
And I do think that's much better than "Cancel or Allow", when there's a real threat.
Kind of too vague for me to say anything about. What plugins?
unsupported flash,
Flash works for me. What's the problem?
java shennanigans,
"Shennanigans" encompasses a very broad range of possibilities. Again, what's actually going wrong?
the 32/64 bit crapfest,
To be fair, that's not Firefox's fault. The only thing Firefox has done wrong is to, y'know, actually support 64-bit.
Even in Vista 64-bit, if I recall, there's a 32-bit IE as the default, and a 64-bit IE buried somewhere. Except their 64-bit IE doesn't support Flash, whereas I can run Flash in nspluginwrapper on a 64-bit Firefox on Linux.
have fun trying to get a java vpn client working...
...I've never tried. There are enough good Linux VPN clients (and servers) that I've never felt the need to use a Java-based one.
Under ubuntu with AMD64 you need to run a 32 bit version of the firefox2 browser and java 5 to get the most popular java based vpn client on the planet to work.
Try OpenJDK -- it does provide a 64-bit plugin, if I remember.
And if that doesn't work, is it really Firefox's fault? Or is it Java's? Or maybe even the VPN client itself -- popular as it is, it probably never had to run on a 64-bit Java before.
Flash is simply BROKEN. I'm not blaming firefox for this one. The easiest workaround is to run firefox.exe from wine.
Really? I just typed "sudo apt-get install flashplugin-nonfree", and Ubuntu handled the rest, including the nspluginwrapper hack.
That cert is not in your browser nor will it be any time soon.
If they provide the cert, it will be as soon as you add it as a root certificate. It won't be shipped with a browser, no, but once you add it, Firefox will leave you alone about military sites.
"Self-signed" implies that it's signed by someone, who happens to be yourself. Which means there is such a certificate -- in fact, a certificate authority.
the certificate is also available to everybody who wants to be MITM, since it's part of the firmware of every router.
Could easily be made more difficult to find. But if that's the case, why not vanilla HTTP?
If a user wants to verify, they can phone me personally, and compare the hash to what I tell them. That's more trustworthy than trusting a third party to do the same, is it not?
Well, if they don't know you, not really.
I don't particularly like VeriSign, but at least I know who they are. If I go to your site, and I see your phone number listed there, what's to stop an attacker from putting their phone number there instead?
The only way it's going to be more secure is a web of trust, and I think the whole point of SSL is that a web of trust is beyond mortal users.
It isn't like it is that hard to get, nor does it really mean anything at the end of the day.
Did you try to get a certificate for, say, paypall.com? Or neweggs.com?
At the end of the day, that's what they mean -- that while they may not be able to trust hassmansblog.com, at least they know it's actually you. And when it is a trusted site, it's very unlikely that you'll land on a typosquatter and that they'll have a valid cert.
Those people using self-signed certificates could also simply run a normal HTTP server, and you'd be none the wiser. You donot get warnings for "regular" HTTP sites.
So I bookmark the https URL. Or I type it with https. Problem solved.
In other words, why doesn't firefox just treat self-signed certs as equivalent to vanilla HTTP?
Let me give you a scenario: I bookmark https://mail.google.com/, which means all of my Gmail activity is encrypted (thus, secure).
Yes, if I got a MITM and I didn't type the https, they could get me over vanilla HTTP, thus avoiding all of the scary browser warnings.
However, as it is, if I ever did get a MITM, I'd get a big scary warning from Firefox, and I'd be safe.
If we implement your idea, and I had a MITM, then before I could really do anything about it, my session cookie (since I stay logged in) would be transmitted to the attacker, who would now have free reign over my Gmail account.
I suppose I could panic and try to logout... which would do absolutely nothing, if the MITM simply blocked all traffic from me to Gmail until they were done.
There are a lot of ideas about how to handle self-signed certs -- but there isn't an obvious answer.
Perhaps I installed that self-signed cert on my router myself (after all it is my router),
Which means those four clicks to get past the warning in Firefox -- or to add that certificate as trusted -- shouldn't present a problem to you, either.
You'd almost have everyone believe that self-signed certificates are somehow bogus and can be hacked at will,
and without a lot of diligence on the users' part, that is true.
Broken English aside, I'm not convinced that it's harder to manage than an old COBOL codebase.
More importantly, mainframes are hard to design and build. Once someone's properly designed and built a cluster as a software package, it's not significantly harder than a mainframe -- perhaps easier, as you can always let someone else manage the hardware.
Slashdot Mirror
You can't cluster routers
Actually, yes, you can. Not as easily, but it's certainly possible.
Remember, this was a network built to survive a nuke. Don't you think the routing architecture accounts for that?
For a trivial example, take "IP anycast" -- you can have one IP address which routes to different places, depending on where you physically are. And it's possible for one to fail, and for a router in between to notice, and route people to one of the live ones.
Note that this "router in between" isn't one gigantic router -- it's whatever router happens to be between the user and the dead IP, which also knows of an alternate route to the same IP.
In other words, yes, if the linksys router in your house fails, you won't be able to get online. But even if your whole ISP dies, you can likely switch to another ISP, and still get to the website in question.
Load balancers. Same deal as with routers.
Indeed, only moreso -- as load balancing, to an extent, can be done client-side. Aside from round-robin DNS, there are AJAX libraries that will do this.
Database Servers.
Read about Google's BigTable, Amazon's Dynamo, and open source projects like CouchDB.
And, if you're tied to an actual SQL server, read up on sharding -- normally done at the application level, but there are tools which can do it for you.
So, actually, you had much more of a point with your argument about routers and load balancers.
But assuming you're still thinking of MySQL replication...
Too many transactions to stream over any kind of link. Face it, you eventually hit too much latency...
Latency != bandwidth. As long as you have enough bandwidth, the latency only matters if it's too slow for the actual client request. (What do I care if it takes 100 ms for you to render my page?)
thanks to the speed of light
BAHAHAHAHA.... oh wait, you were serious.
By my calculations, it's not even 1 millisecond to send a photon around the planet. Maybe I'm off?
No, it's the speed of electricity, which is slowing you down in plenty of other places, too.
Now, if you need the transactions to be absolutely synchronous across the entire database, then you're absolutely right. But see above, at least the bit about sharding. Suppose there's a million accounts in the system -- there's no reason a transaction involving a transfer between 2 accounts needs to lock up the other 999,998 accounts. And no one account is going to have so much traffic that network latency is going to be an issue.
As others have said, that model is great for distributed computing where each transaction is non-mission-critical.
And as others have said, it's also great for distributing computing where most transactions are mission-critical (see Amazon). It just has to be tuned differently.
banking is the obvious one.
Banking is more an example of a place where...
Alright, try this for a moment -- assume I'm right, and assume it's easy for any technical person to understand. Do you think banks would switch to it?
I doubt it.
I do think banks could benefit as much from "the cloud" as anyone else, and that it would increase (not decrease) their reliability and availability. The additional speed, if any, would just be a nice side effect.
You sure don't have a bookmark there if you haven't visited it before.
Fair enough.
Which also implies two things: Either every self-signed SSL site I visit will be dropping a cert permanently into my cache (and what happens when that expires?), or it's possible for certs to expire (either their date expires, or my cache purges them for inactivity).
In the first case, that would work, but it bothers me -- though unlikely, it's possible someone could set up a DoS which redirects to an infinite number of subdomains (each with their own cert), thus filling up my disk with useless certs. (With normal SSL, I can safely drop a cert from the cache, as long as I keep the known-good root certs.)
In the second case, every time a cert expires, it's possible for me to be pwned. I'll agree that's not often, but it does bother me.
While I'm at it, I should point out another potential problem: SSH does exactly what you're suggesting, and I do often simply accept new SSH host keys. The problem arises when an SSH host key changes, for whatever reason -- you reinstalled the OS, or you upgraded and Debian killed the key (to clean up after the openssl vulnerability), or whatever.
I think at this point, there would still be a problem of a large number of false positives -- of people needing new certs, for whatever reason, and if they're too cheap to pay $20 (or nothing), how likely is it that they'll be able to properly manage their own little CA?
Which can leave you in the uncomfortable situation where some forum site you like has had to generate a new cert. Do you trust the new cert? With real SSL, yes, because the CA has already done the checking for you. With this, you have to either assume you're MITM'd (and check it from somewhere else), or you have to assume the site admin screwed up (in which case, you're open to being MITM'd again, and may as well have stuck to vanilla HTTP.)
First: Normal SSL also protects you the very first time. If I buy a new computer, and open it up, and type https://mail.google.com/, I'm reasonably sure it will go to the right place.
Second: That's not the same as vanilla HTTP.
The question is, knowing full well that the user is going to get a nasty warning about your self-signed cert, versus not see anything out of the ordinary if they just didn't use HTTPS at all, why would the proprietor of paypals.com bother with SSL?
Granted, it's a bit of extra training, but it is possible to check for it being SSL, and having a green bar.
That said, it is an important point, and difficult to solve.
Did the MBTA learn a lesson here about making a mountain out of a molehill?
Unlikely. And, unfortunately, the "hacker" responsible seems to be more interested in his own personal integrity than in teaching them that lesson...
You see, he said, very clearly, that he'd be sharing no details which would allow someone to trivially cheat the system. He sent them documents showing everything he knew, and explaining that he wouldn't be sharing all of this in his talk.
And the asshats still decided to call the FBI, and to sue him.
If this was me, at this point, I'd say "OK, you blew it, this is all going up on wikileaks. And it's going up there because you were asshats about it."
I haven't tried it, only skimmed the review, but I'm guessing this is like those panoramic bubble photos -- that is, if you have a bunch of pictures that fit together, it'll let you turn your head around.
What I kind of doubt is that it'll turn it into actual 3D, as in, polygons and such.
If it could, well, it would greatly simplify modeling in some places. Find a cool, old building that looks like you want your game to look, snap a few photos, and hey, presto, instant level design!
The problem for me as a site developer is that my company self-signs a lot of certificates for our test servers as several of our clients have requested that the test server behave exactly like the production server (which, in fact it probably should if you want to get into it).
We actually bought a certificate for our staging server. They're cheap enough.
However, it's really not that difficult to, say, create an untrusted CA (to sign all those "self-signed" certificates) and add that as a root cert to Firefox. One step, and suddenly all your SSL test sites will work without a problem.
So, now that Firefox has made it extremely painful for me to test my SSL test sites; I don't. Just think about that when you complain that a site looks like s in firefox.
Yeah, I will. I'll think "What a lazy developer!" The only difference will be how you're lazy -- others don't care to learn about Firefox and web standards, whereas you don't care to learn about how SSL actually works.
Err on the side of security rather than the other side, I would say.
I agree with your point, mostly, but this statement troubles me. You're basically saying, "Security is good, right?"
So yeah, got any links to these free root authorities?
http://www.startssl.com/
Getting a cert costs more then the entire freaking hosting!
GoDaddy certs cost $20 or so a year. Good hosting costs that much per month.
It is better to inform the user why this is dangerous/stupid/embarasing and let him or her make up their own mind.
I agree, in theory.
In practice, even here on Slashdot, there's still actually debate about whether we should trust sites that do self-signed certificates. So I have no faith that on reading this:
any communication he or she has is encrypted, but that the receiver could be anyone.
What this effectively means is that the communication may as well not be encrypted, and that is what the user should be made aware of.
Saying "the receiver could be anyone" isn't clear enough -- and Joe User, skimming through it, is going to go "Well, yeah, I can see who the receiver is, it's paypals.com! They wouldn't lie to me..."
I found the wording on the Firefox SSL certificate warning page to be rather over the top, and rather vague at the same time.
Maybe it could be clarified, but it's not over the top at all. It's just accurate.
A self-signed certificate is not bad, it still allows secure data transfer between the client and the server, however it loses the verification of the server aspect - which you may not even care about.
If you don't care about that, you may as well be using vanilla HTTP. Encryption without authentication is pretty pointless -- it'll protect you from passive sniffing, but most places people can do passive sniffing are also places where they can easily do an active man-in-the-middle attack.
At which point, you'll have a really secure, encrypted connection to your attacker, who has his own secure, encrypted connection to the self-signed site. Good job!
For those who don't understand sarcasm (or on the offchance that the parent wasn't joking), FF2 always had this, and in fact, the feature itself (though not always as visible) goes back to the original Mozilla, at least. I'd guess they took it from Unix tools like less and vim.
"You have tried to access a secure site with a dodgy certificate, Cancel or Allow?"
That's what IE says, actually. FF3 says "You have tried to access a secure site with a dodgy certificate. This is a bad idea, and we're not going to let you do it unless you really know what you're doing."
And I do think that's much better than "Cancel or Allow", when there's a real threat.
StartSSL provides free certificates, and they're included in Firefox.
Plugin incompatibility,
Kind of too vague for me to say anything about. What plugins?
unsupported flash,
Flash works for me. What's the problem?
java shennanigans,
"Shennanigans" encompasses a very broad range of possibilities. Again, what's actually going wrong?
the 32/64 bit crapfest,
To be fair, that's not Firefox's fault. The only thing Firefox has done wrong is to, y'know, actually support 64-bit.
Even in Vista 64-bit, if I recall, there's a 32-bit IE as the default, and a 64-bit IE buried somewhere. Except their 64-bit IE doesn't support Flash, whereas I can run Flash in nspluginwrapper on a 64-bit Firefox on Linux.
have fun trying to get a java vpn client working...
...I've never tried. There are enough good Linux VPN clients (and servers) that I've never felt the need to use a Java-based one.
Under ubuntu with AMD64 you need to run a 32 bit version of the firefox2 browser and java 5 to get the most popular java based vpn client on the planet to work.
Try OpenJDK -- it does provide a 64-bit plugin, if I remember.
And if that doesn't work, is it really Firefox's fault? Or is it Java's? Or maybe even the VPN client itself -- popular as it is, it probably never had to run on a 64-bit Java before.
Flash is simply BROKEN. I'm not blaming firefox for this one. The easiest workaround is to run firefox.exe from wine.
Really? I just typed "sudo apt-get install flashplugin-nonfree", and Ubuntu handled the rest, including the nspluginwrapper hack.
That cert is not in your browser nor will it be any time soon.
If they provide the cert, it will be as soon as you add it as a root certificate. It won't be shipped with a browser, no, but once you add it, Firefox will leave you alone about military sites.
There is no such certificate.
"Self-signed" implies that it's signed by someone, who happens to be yourself. Which means there is such a certificate -- in fact, a certificate authority.
the certificate is also available to everybody who wants to be MITM, since it's part of the firmware of every router.
Could easily be made more difficult to find. But if that's the case, why not vanilla HTTP?
If a user wants to verify, they can phone me personally, and compare the hash to what I tell them. That's more trustworthy than trusting a third party to do the same, is it not?
Well, if they don't know you, not really.
I don't particularly like VeriSign, but at least I know who they are. If I go to your site, and I see your phone number listed there, what's to stop an attacker from putting their phone number there instead?
The only way it's going to be more secure is a web of trust, and I think the whole point of SSL is that a web of trust is beyond mortal users.
It isn't like it is that hard to get, nor does it really mean anything at the end of the day.
Did you try to get a certificate for, say, paypall.com? Or neweggs.com?
At the end of the day, that's what they mean -- that while they may not be able to trust hassmansblog.com, at least they know it's actually you. And when it is a trusted site, it's very unlikely that you'll land on a typosquatter and that they'll have a valid cert.
Those people using self-signed certificates could also simply run a normal HTTP server, and you'd be none the wiser. You donot get warnings for "regular" HTTP sites.
So I bookmark the https URL. Or I type it with https. Problem solved.
In other words, why doesn't firefox just treat self-signed certs as equivalent to vanilla HTTP?
Let me give you a scenario: I bookmark https://mail.google.com/, which means all of my Gmail activity is encrypted (thus, secure).
Yes, if I got a MITM and I didn't type the https, they could get me over vanilla HTTP, thus avoiding all of the scary browser warnings.
However, as it is, if I ever did get a MITM, I'd get a big scary warning from Firefox, and I'd be safe.
If we implement your idea, and I had a MITM, then before I could really do anything about it, my session cookie (since I stay logged in) would be transmitted to the attacker, who would now have free reign over my Gmail account.
I suppose I could panic and try to logout... which would do absolutely nothing, if the MITM simply blocked all traffic from me to Gmail until they were done.
There are a lot of ideas about how to handle self-signed certs -- but there isn't an obvious answer.
Perhaps I installed that self-signed cert on my router myself (after all it is my router),
Which means those four clicks to get past the warning in Firefox -- or to add that certificate as trusted -- shouldn't present a problem to you, either.
You'd almost have everyone believe that self-signed certificates are somehow bogus and can be hacked at will,
and without a lot of diligence on the users' part, that is true.
I find it charmingly cute how so many people think how google does it's servers is the end-all-be-all of technology design.
No, it's just a good example. They're not the only ones who do it that way.
it a bit harder to manage.
Broken English aside, I'm not convinced that it's harder to manage than an old COBOL codebase.
More importantly, mainframes are hard to design and build. Once someone's properly designed and built a cluster as a software package, it's not significantly harder than a mainframe -- perhaps easier, as you can always let someone else manage the hardware.