The point is in Unix, what you see is what you get. If ps did output binary, the user would see binary and an app downstream of a pipe would see binary. Since it outputs in text, the user sees text and a program would see text. In PowerShell, what you see has had some secret magic pre-applied, and thus things like 'awk '{print $4}' become meaningless (you get some selectors with more power, but not as open-ended). 'ps|cat' is a bit synthetic, but it is illustrative of the *sort* of issues that will crop up when you get fancier than the basics, but not wanting to step up to write your own cmdlets in a more sophisticated language. When you stray from the menu of MS pre-fabbed stuff, things get hairy fast. This is why the divide exists between structured languages (which are every bit as powerful as powershell) and shell scripting (which makes straightforward stuff simple, and doesn't particularly scale up beyond that). The former has capability at the expense of more complex syntax and the latter sacrifices capability for absolute transparency.
My top issue is that while PowerShell does a better-than-most job at having powerful capabilities *without* the syntactic burden of an equivalent language (like Python/Perl), it *still* (necessarily) compromises somewhat. The fancy piping sometimes has unanticipated oddness in certain scenarios (easiest example, do 'ps', looks sane enough, now, do 'ps|cat', and suddenly you see the hard-to-manage man behind the curtain that can crop up in various situations). In general, it's largely able to work due to MS implementing everything top-to-bottom, but I just don't see it scaling in the same way as Linux/Unix does with respect to third party development all co-existing in bourne shell.
Linux is fine for hobbyist stuff and some real work, but the real world still uses Windows Server a lot.
Just flamebait. Considering most public-facing servers are not microsoft, it's fairly silly.
PXE provides a distinct characteristic from iSCSI boot. PXE can/is used in some cases to start iSCSI (e.g. chaining iPXE). PXE can be used to do ram-hosted OS for reduced steady state network utilization.
One more thing, while perusing slashdot comments is better than some places, you may want to repeat your inquiries in more tightly focused communities, like ROCKS mailing lists an/or xcat-user@lists.sourceforge.net
Those are audiences that live and breathe this stuff, many of whom may be in your area and even open for employment opportunities if you are looking to backfill.
Sounds like you were in a position to reasonably roll your own, but circumstances have changed. You may wish to consider talking to HP, IBM, or Dell sales reps (if your servers are already from one of those badges, you undoubtedly would have a strong relationship with their sales team). Balance that against community advice to give context. Basically, all those companies have experts and will gladly take your grant money to give you what you want. Alternatively, backfill with an expert in the field to fill the gap.
That said, my community advice: Interconnect: Infiniband almost certainly at that scale. Cost per port, bandwidth, latency are all in favor of IB. Building a high scale IB fabric is child's play, doing the same in ethernet is possible, but more difficult technically and financially.
In terms of GPU, your server choice is critical to know. If the servers were not designed for GPU, you may be SOL for lack of room for heatsink or lack of power connector. Even amongst servers that do GPU, frequently the extra power harness or PSU is not provided unless the vendor knows ahead of time.
I cannot speak much to ROCKS, but xCAT does a pretty good job with RHEL/CentOS/SLES, and I think Ubuntu now. Generally, I see people go with RHEL/CentOS.
Windows XP lasted (past tense may not be accurate, but oh well) as long as they needed it to. It's not like XP suddenly will 'stop working' no matter what MS wants. So a hypothetical MS OS flop just means they fix it for 9 and the world largely pretends 8 doesn't exist and MS will roll with that so long as it prevents other desktop OSes.
Because you want 10Gbe, but maybe you want Qlogic ethernet chips, but another guy wants broadcom, and another guy wants Emulex, and yet another guy wants Intel, and maybe half the people don't even want 10Gbe, and 10Gbe chips are still *expensive*.
For the likes of Dell/HP/IBM, these scenarios present a problem. These datacenters architect their solution so that the manageability and service is no big deal. A system fails and it's going to be 3 weeks before you can get a replacement in? Fine. Can't get a replacement anymore because that model is done, upgrade it to something 'close enough'. Much of Dell/HP/IBM cost compared to, say, Supermicro is in maintaining stockpiles of replacement parts, keeping them distributed across the globe, paying for expedited shipping, and employing technicians to dispatch to customer sites.
So they cut cost on some offering by exempting it from this. Suddenly, a customer who wants "tier one quality" jumps on the system due to price. Then they realize there is no longer any particular difference, and they can then go off about how that vendor is nothing like they used to be.
Of course, hardware can factor into this as well, and the major players do something about this. In the not-to-distant past, there was an intel first-party server. You could buy it form Dell, HP, or IBM. The only difference was what logo Intel's BIOS showed you and the logo on the cheap removable bezel. This is them responding to the thought. This is the same platform popularized for these cheapo deployments, and so the tier-ones embraced it. The problem is for anyone who cares about reliability, serviceability, or management, the board was utter shit. As a result, "tier one" value eroded.
Basically, the 'tier ones' have to be careful playing this game. If they do this, they should probably establish new brands to slap on, like automotive companies do. This is asinine, but human psychology seeks simplicity and this is the only way to get there it seems.
If they think 98% of the market is going to go with the onboard, it's cheaper for them to have a single part with an unused component 2% of the time than to maintain two motherboards with different chips populated with independent replacement stock (or to make it a field pluggable module). If they relax warranty promises or have a handful of customers driving tens of thousands of servers for one run, they can (and do, as pointed out in the article) make exceptions.
I don't know about Dell or anything precisely along the lines of what you describe, but there *is* more to server design than 'does it fit in the socket'. If the components chosen for a 1U skimped on cooling to a certain TDP and the Magny Cours exceeds that, then they may not have enough room around the socket to accommodate a heatsink that can dissipate the heat given the flow rate.
In terms of 'custom' unclear to what extent they are talking about board components (which have been increasingly sparse in the tier one vendors) or mechanical issues. In either case, the truth is when you are building entire datacenters and promise a vendor a run of tens of thousands of servers, you can get what you want. Most of the market isn't doing things that cleanly, and that's the market that is front and center in the Dell/HP/IBM offerings that you see on their respective websites. In the long haul, engineering everything from CRAC to network switch, to rack, to board, to chips is going to give you the best/most efficient approach, *but* it involves a large expense in a single shot, *can* get you stuck in a difficult situation if the state of hardware changes in 2 years.
So, it's the CA system (a blessed number of authorities with pre-distributed keys), but without any initial validation of the target by people vouching for it? Brilliant!
Embrace certificates signed by multiple CAs and poof, you've added the biggest potential value of this approach while taking on none of the negatives/unknowns.
The test was insufficient to actually conclude anything of value. They used two *different* systems instead of reinstalling (specs looked *close*, but they weren't the same). They used KDE vs. Unity (this by itself explains the discrepancy, it's widely been shown unity degrades full screen 3d performance). It compared only one version of one distribution to one version of one variant of BSD. It only compared the nVidia driver, though there is no choice on that front.
"Unity slower than KDE" is a more likely conclusion, but again, you'd need a more controlled test to say anything. Phoronix should be ashamed...
1) If the OS/browser vendor does their job, the window for vulnerability should be at least somewhat limited. It may be slower than a security-aware user would achieve on their own, but it will be faster than most people's reaction on their own. 2) ok, that may be the truth, but there is something to be said for vendors making 'best effort' to help users only suffer when indulging in *extreme* negligence
Browsers are reluctant to warn on CA change because it could be a legitimate change. Sure, changing before expiry is suspicious, but all sorts of business reasons could come into play (including a vindictive CA threatening your cert with removal from OSCP or adding to CRLs). google could do something about it because they are their own CA and they *know* they won't be using anything but themselves.
Things like certificate patrol or web of trust augmentation to existing CA system makes a lot of sense, let the process work as intended, but audit the behavior.
My impression was there was a desire declare CAs worthless and you should trust self-signed *more* than CA-signed, which is a bad knee-jerk reaction.
In terms of 'treading lightly' on self-signed certs, that's pretty optimistic view of human behavior. If the world overnight became self-signed, the treading lightly would evaporate quickly.
'It's not a simple matter of removing certificates from a database, because they're not in any databases,
I don't get this. Removing/replacing a CA cert from trust is easy for browsers/os vendors to do, technically (CA should be on the hook to re-certify certs if they are forced to remove their cert from circulation).
With OSCP, at least *good* certificates *are* in a CA's database, and OSCP will fail for any signed certs that cannot update the OSCP server's hosted copy. Implementation wise, OSCP validation is done poorly, but that's not a flaw of the theoretical design.
There is a whole lot of people calling to throw the baby out with the bathwater in x509, but a 'simple' tweak of mandatory, *affirmative* (no saying 'ok' to server errors or 'try again') OSCP validation to indicate any hint of trustworthiness. If a CA screws up, kick em out.
In terms of more 'radical' changes, I've liked suggestions such as 'require multiple CAs to sign a CSR' and 'publish the CA(s) that are *expected* to be in use via DNSSEC' (requiring attacker to compromise the *specific* CA in use or compromise DNSSEC as well as a CA). I'm wary of key distribution via DNSSEC (requires implementation too pervasive to be practical, theoretically lands you into more dubious territory than current CA model), and I'm wary of Perspectives/Convergence (I'm dubious on how trust gets established in the first place, and I would not be surprised if these systems fell flat on their face under the onslaught of the 'unwashed masses'). Lot's of attacking current state of x509 in the name of advocating some drastic change without enough thought around fixing the weaknesses while preserving the proven strengths.
If you are the sort to meticulously peruse fingerprints and seek manual confirmation via phone of fingerprint validity, the 'out of the box' behavior of manual key approval that SSH does *might* be 'safer' compared to *default* browser behavior.
If you are the sort to blindly accept the fingerprint on first connection (99.9% of the population), the CA system has better odds of blocking a MITM than your individual efforts. If dealing with servers that frequently change or round-robin shell access, some develop a habit of auto-deleting lines from known_hosts on conflict. Finally, if you are a site operator and *know* you'd scare away the vast majority of your users if you change your private key, the end-users are more likely to be put at risk due to site operator retaining a possibly compromised key (they know it had wrong permissions for a couple of weeks, but don't know for sure someone read it, they may elect to carry on with the dubious key whereas in x509 case they may re-do their cert just in case, as the end-user is not negatively impacted).
The good news is that if you so demanded, extensions/browsers can be implemented to pretend CAs don't exist and render the whole x509==SSH if you really wanted, while the rest of the oblivious world carries on with CAs with a common certificate infrastructure serving both needs.
This article is intelligent and correctly identifies the issues and puts them in accurate context in the face of hordes of people mindlessly saying 'DNSSEC fixes all'. The problem is not the technology, but the politics and laziness that distorts the use of the technology. I doubt any approach can be dreamed of that wouldn't, in practice, be perverted in implementation. Self-signed certs are simply worse. You can manage it intelligently, by having a private CA for your organization and distribute the certificate, defining the trust anchor yourself.
SSL is not secure, and has not been for a while.
'Secure' is not a boolean. SSL is 'secure' by some criteria, not by others. SSL can be much more secure than the common implementation today, and my doubt is whether a technical approach exists that would do better than SSL in the face of the same non-technical circumstances watering down SSL security.
The problem is that our current system may not in practice *be* a 'good security system', but if implemented correctly it *would* be.
The challenge is this will undoubtedly hold true for any proposed alternative implementation strategy, making churning the underlying technology an exercise in futility unless you fix the aspects preventing the x509 system from working as designed.
No, I really am not concerned with MITM attacks on my own LAN, and in the VPN network.
That's a particularly special case, sounds like you are accessing a remote work server from home using a technology explicitly designed to be unobtrusive and by extension indistinguishable from any other internet connection. Not exactly the scenario where a browser can reasonably detect and change behavior even *if* it were a good idea. Of course, a number of VPN client rely upon DNS and SSL certificates to initiate the connection, so a MITM during VPN connection establishment is not entirely out of the question. Put another way, If you were so confident in the VPN providing all the security, why use https at all?
for a cirt that still does not stop MITM attacks.
Has anyone analyzed how many browsers already have updates invalidating DigiNotar authority or discussed if DigiNotar has a functional OSCP that is returning accurately? The system when used *as designed* does stop MITM attacks. This is the first widespread compromise of a CA that I can recall, and I expect already many users are in browsers that already distrust the compromised key. I suspect most people will have updated their CA certs without even being aware of this incident within a few months. So it does stop MITM attacks.
SSH should have done x509 from it's inception with self-signed as default. No worse than current state of things with a great opportunity to do better.
This is a huge deal because for browsers/libraries that do not refresh CA certificates promptly, some select population of people can reduce all certs to as bad as self-signed certificates.
Saying self-signed certs are somehow better than certs signed by a compromised CA is rather silly.
: its actually more centralized than SSL/TLS, which is what is desired.
The key is not the centralization or de-centralization (though a system without well-defined roots of trust or in which the end-user is responsible for tracking the validity of the roots of trust would be bad). The issue at hand is DNSSEC has no concept of validation beyond DNS cache lifetimes. If an authority key is compromised, then you push out your fixed keys and the threat ages out of the system in relatively short order. 100% OSCP with unforgiving clients would be the most trivial fix to this mess. If you think that can't be accomplished, then DNSSEC is certainly never going to pan out as the same people not doing it right with x509 today aren't going to do it right with DNSSEC either. DNSSEC is only promising now because it is not ubiquitous. The people doing it are intrinsically interested in security and therefore no one is yet watering down the security for various 'practical' concerns.
Interesting, but all that would do is spur companies to automatically obtain multiple certificates from multiple CAs. If such a system were compromised we'd be in the same situation as now.
Uhh, no, a single CA being compromised would be meaningless, you'd have to compromise as many authorities as is required to trust a cert, and do so within a time period short enough to avoid at least one of those being revoked/removed from browsers.
Slashdot Mirror
The point is in Unix, what you see is what you get. If ps did output binary, the user would see binary and an app downstream of a pipe would see binary. Since it outputs in text, the user sees text and a program would see text. In PowerShell, what you see has had some secret magic pre-applied, and thus things like 'awk '{print $4}' become meaningless (you get some selectors with more power, but not as open-ended). 'ps|cat' is a bit synthetic, but it is illustrative of the *sort* of issues that will crop up when you get fancier than the basics, but not wanting to step up to write your own cmdlets in a more sophisticated language. When you stray from the menu of MS pre-fabbed stuff, things get hairy fast. This is why the divide exists between structured languages (which are every bit as powerful as powershell) and shell scripting (which makes straightforward stuff simple, and doesn't particularly scale up beyond that). The former has capability at the expense of more complex syntax and the latter sacrifices capability for absolute transparency.
Their answer is doing all kinds of convoluted stuff in WS-MAN. They don't grasp the concept of simplicity.
My top issue is that while PowerShell does a better-than-most job at having powerful capabilities *without* the syntactic burden of an equivalent language (like Python/Perl), it *still* (necessarily) compromises somewhat. The fancy piping sometimes has unanticipated oddness in certain scenarios (easiest example, do 'ps', looks sane enough, now, do 'ps|cat', and suddenly you see the hard-to-manage man behind the curtain that can crop up in various situations). In general, it's largely able to work due to MS implementing everything top-to-bottom, but I just don't see it scaling in the same way as Linux/Unix does with respect to third party development all co-existing in bourne shell.
Linux is fine for hobbyist stuff and some real work, but the real world still uses Windows Server a lot.
Just flamebait. Considering most public-facing servers are not microsoft, it's fairly silly.
PXE provides a distinct characteristic from iSCSI boot. PXE can/is used in some cases to start iSCSI (e.g. chaining iPXE). PXE can be used to do ram-hosted OS for reduced steady state network utilization.
One more thing, while perusing slashdot comments is better than some places, you may want to repeat your inquiries in more tightly focused communities, like ROCKS mailing lists an/or xcat-user@lists.sourceforge.net
Those are audiences that live and breathe this stuff, many of whom may be in your area and even open for employment opportunities if you are looking to backfill.
Sounds like you were in a position to reasonably roll your own, but circumstances have changed. You may wish to consider talking to HP, IBM, or Dell sales reps (if your servers are already from one of those badges, you undoubtedly would have a strong relationship with their sales team). Balance that against community advice to give context. Basically, all those companies have experts and will gladly take your grant money to give you what you want. Alternatively, backfill with an expert in the field to fill the gap.
That said, my community advice:
Interconnect: Infiniband almost certainly at that scale. Cost per port, bandwidth, latency are all in favor of IB. Building a high scale IB fabric is child's play, doing the same in ethernet is possible, but more difficult technically and financially.
In terms of GPU, your server choice is critical to know. If the servers were not designed for GPU, you may be SOL for lack of room for heatsink or lack of power connector. Even amongst servers that do GPU, frequently the extra power harness or PSU is not provided unless the vendor knows ahead of time.
I cannot speak much to ROCKS, but xCAT does a pretty good job with RHEL/CentOS/SLES, and I think Ubuntu now. Generally, I see people go with RHEL/CentOS.
If Windows XP had not lasted so long
Windows XP lasted (past tense may not be accurate, but oh well) as long as they needed it to. It's not like XP suddenly will 'stop working' no matter what MS wants. So a hypothetical MS OS flop just means they fix it for 9 and the world largely pretends 8 doesn't exist and MS will roll with that so long as it prevents other desktop OSes.
Because you want 10Gbe, but maybe you want Qlogic ethernet chips, but another guy wants broadcom, and another guy wants Emulex, and yet another guy wants Intel, and maybe half the people don't even want 10Gbe, and 10Gbe chips are still *expensive*.
For the likes of Dell/HP/IBM, these scenarios present a problem. These datacenters architect their solution so that the manageability and service is no big deal. A system fails and it's going to be 3 weeks before you can get a replacement in? Fine. Can't get a replacement anymore because that model is done, upgrade it to something 'close enough'. Much of Dell/HP/IBM cost compared to, say, Supermicro is in maintaining stockpiles of replacement parts, keeping them distributed across the globe, paying for expedited shipping, and employing technicians to dispatch to customer sites.
So they cut cost on some offering by exempting it from this. Suddenly, a customer who wants "tier one quality" jumps on the system due to price. Then they realize there is no longer any particular difference, and they can then go off about how that vendor is nothing like they used to be.
Of course, hardware can factor into this as well, and the major players do something about this. In the not-to-distant past, there was an intel first-party server. You could buy it form Dell, HP, or IBM. The only difference was what logo Intel's BIOS showed you and the logo on the cheap removable bezel. This is them responding to the thought. This is the same platform popularized for these cheapo deployments, and so the tier-ones embraced it. The problem is for anyone who cares about reliability, serviceability, or management, the board was utter shit. As a result, "tier one" value eroded.
Basically, the 'tier ones' have to be careful playing this game. If they do this, they should probably establish new brands to slap on, like automotive companies do. This is asinine, but human psychology seeks simplicity and this is the only way to get there it seems.
If they think 98% of the market is going to go with the onboard, it's cheaper for them to have a single part with an unused component 2% of the time than to maintain two motherboards with different chips populated with independent replacement stock (or to make it a field pluggable module). If they relax warranty promises or have a handful of customers driving tens of thousands of servers for one run, they can (and do, as pointed out in the article) make exceptions.
I don't know about Dell or anything precisely along the lines of what you describe, but there *is* more to server design than 'does it fit in the socket'. If the components chosen for a 1U skimped on cooling to a certain TDP and the Magny Cours exceeds that, then they may not have enough room around the socket to accommodate a heatsink that can dissipate the heat given the flow rate.
In terms of 'custom' unclear to what extent they are talking about board components (which have been increasingly sparse in the tier one vendors) or mechanical issues. In either case, the truth is when you are building entire datacenters and promise a vendor a run of tens of thousands of servers, you can get what you want. Most of the market isn't doing things that cleanly, and that's the market that is front and center in the Dell/HP/IBM offerings that you see on their respective websites. In the long haul, engineering everything from CRAC to network switch, to rack, to board, to chips is going to give you the best/most efficient approach, *but* it involves a large expense in a single shot, *can* get you stuck in a difficult situation if the state of hardware changes in 2 years.
So, it's the CA system (a blessed number of authorities with pre-distributed keys), but without any initial validation of the target by people vouching for it? Brilliant!
Embrace certificates signed by multiple CAs and poof, you've added the biggest potential value of this approach while taking on none of the negatives/unknowns.
If you control the *client's* ISP, you can MITM every single last connection to any number of notaries.
The test was insufficient to actually conclude anything of value. They used two *different* systems instead of reinstalling (specs looked *close*, but they weren't the same). They used KDE vs. Unity (this by itself explains the discrepancy, it's widely been shown unity degrades full screen 3d performance). It compared only one version of one distribution to one version of one variant of BSD. It only compared the nVidia driver, though there is no choice on that front.
"Unity slower than KDE" is a more likely conclusion, but again, you'd need a more controlled test to say anything. Phoronix should be ashamed...
1) If the OS/browser vendor does their job, the window for vulnerability should be at least somewhat limited. It may be slower than a security-aware user would achieve on their own, but it will be faster than most people's reaction on their own.
2) ok, that may be the truth, but there is something to be said for vendors making 'best effort' to help users only suffer when indulging in *extreme* negligence
Browsers are reluctant to warn on CA change because it could be a legitimate change. Sure, changing before expiry is suspicious, but all sorts of business reasons could come into play (including a vindictive CA threatening your cert with removal from OSCP or adding to CRLs). google could do something about it because they are their own CA and they *know* they won't be using anything but themselves.
Things like certificate patrol or web of trust augmentation to existing CA system makes a lot of sense, let the process work as intended, but audit the behavior.
My impression was there was a desire declare CAs worthless and you should trust self-signed *more* than CA-signed, which is a bad knee-jerk reaction.
In terms of 'treading lightly' on self-signed certs, that's pretty optimistic view of human behavior. If the world overnight became self-signed, the treading lightly would evaporate quickly.
Multiple CA signatures seems like a good idea.
'It's not a simple matter of removing certificates from a database, because they're not in any databases,
I don't get this. Removing/replacing a CA cert from trust is easy for browsers/os vendors to do, technically (CA should be on the hook to re-certify certs if they are forced to remove their cert from circulation).
With OSCP, at least *good* certificates *are* in a CA's database, and OSCP will fail for any signed certs that cannot update the OSCP server's hosted copy. Implementation wise, OSCP validation is done poorly, but that's not a flaw of the theoretical design.
There is a whole lot of people calling to throw the baby out with the bathwater in x509, but a 'simple' tweak of mandatory, *affirmative* (no saying 'ok' to server errors or 'try again') OSCP validation to indicate any hint of trustworthiness. If a CA screws up, kick em out.
In terms of more 'radical' changes, I've liked suggestions such as 'require multiple CAs to sign a CSR' and 'publish the CA(s) that are *expected* to be in use via DNSSEC' (requiring attacker to compromise the *specific* CA in use or compromise DNSSEC as well as a CA). I'm wary of key distribution via DNSSEC (requires implementation too pervasive to be practical, theoretically lands you into more dubious territory than current CA model), and I'm wary of Perspectives/Convergence (I'm dubious on how trust gets established in the first place, and I would not be surprised if these systems fell flat on their face under the onslaught of the 'unwashed masses'). Lot's of attacking current state of x509 in the name of advocating some drastic change without enough thought around fixing the weaknesses while preserving the proven strengths.
So tell me again which situation is safer?
If you are the sort to meticulously peruse fingerprints and seek manual confirmation via phone of fingerprint validity, the 'out of the box' behavior of manual key approval that SSH does *might* be 'safer' compared to *default* browser behavior.
If you are the sort to blindly accept the fingerprint on first connection (99.9% of the population), the CA system has better odds of blocking a MITM than your individual efforts. If dealing with servers that frequently change or round-robin shell access, some develop a habit of auto-deleting lines from known_hosts on conflict. Finally, if you are a site operator and *know* you'd scare away the vast majority of your users if you change your private key, the end-users are more likely to be put at risk due to site operator retaining a possibly compromised key (they know it had wrong permissions for a couple of weeks, but don't know for sure someone read it, they may elect to carry on with the dubious key whereas in x509 case they may re-do their cert just in case, as the end-user is not negatively impacted).
The good news is that if you so demanded, extensions/browsers can be implemented to pretend CAs don't exist and render the whole x509==SSH if you really wanted, while the rest of the oblivious world carries on with CAs with a common certificate infrastructure serving both needs.
http://blog.thoughtcrime.org/ssl-and-the-future-of-authenticity
This article is intelligent and correctly identifies the issues and puts them in accurate context in the face of hordes of people mindlessly saying 'DNSSEC fixes all'. The problem is not the technology, but the politics and laziness that distorts the use of the technology. I doubt any approach can be dreamed of that wouldn't, in practice, be perverted in implementation. Self-signed certs are simply worse. You can manage it intelligently, by having a private CA for your organization and distribute the certificate, defining the trust anchor yourself.
SSL is not secure, and has not been for a while.
'Secure' is not a boolean. SSL is 'secure' by some criteria, not by others. SSL can be much more secure than the common implementation today, and my doubt is whether a technical approach exists that would do better than SSL in the face of the same non-technical circumstances watering down SSL security.
The problem is that our current system may not in practice *be* a 'good security system', but if implemented correctly it *would* be.
The challenge is this will undoubtedly hold true for any proposed alternative implementation strategy, making churning the underlying technology an exercise in futility unless you fix the aspects preventing the x509 system from working as designed.
No, I really am not concerned with MITM attacks on my own LAN, and in the VPN network.
That's a particularly special case, sounds like you are accessing a remote work server from home using a technology explicitly designed to be unobtrusive and by extension indistinguishable from any other internet connection. Not exactly the scenario where a browser can reasonably detect and change behavior even *if* it were a good idea. Of course, a number of VPN client rely upon DNS and SSL certificates to initiate the connection, so a MITM during VPN connection establishment is not entirely out of the question. Put another way, If you were so confident in the VPN providing all the security, why use https at all?
for a cirt that still does not stop MITM attacks.
Has anyone analyzed how many browsers already have updates invalidating DigiNotar authority or discussed if DigiNotar has a functional OSCP that is returning accurately? The system when used *as designed* does stop MITM attacks. This is the first widespread compromise of a CA that I can recall, and I expect already many users are in browsers that already distrust the compromised key. I suspect most people will have updated their CA certs without even being aware of this incident within a few months. So it does stop MITM attacks.
How could such a gaping vulnerability be missed?!
It is a vulnerability and it hasn't been missed: http://tools.ietf.org/html/rfc4255
SSH should have done x509 from it's inception with self-signed as default. No worse than current state of things with a great opportunity to do better.
This is a huge deal because for browsers/libraries that do not refresh CA certificates promptly, some select population of people can reduce all certs to as bad as self-signed certificates.
Saying self-signed certs are somehow better than certs signed by a compromised CA is rather silly.
: its actually more centralized than SSL/TLS, which is what is desired.
The key is not the centralization or de-centralization (though a system without well-defined roots of trust or in which the end-user is responsible for tracking the validity of the roots of trust would be bad). The issue at hand is DNSSEC has no concept of validation beyond DNS cache lifetimes. If an authority key is compromised, then you push out your fixed keys and the threat ages out of the system in relatively short order. 100% OSCP with unforgiving clients would be the most trivial fix to this mess. If you think that can't be accomplished, then DNSSEC is certainly never going to pan out as the same people not doing it right with x509 today aren't going to do it right with DNSSEC either. DNSSEC is only promising now because it is not ubiquitous. The people doing it are intrinsically interested in security and therefore no one is yet watering down the security for various 'practical' concerns.
Interesting, but all that would do is spur companies to automatically obtain multiple certificates from multiple CAs. If such a system were compromised we'd be in the same situation as now.
Uhh, no, a single CA being compromised would be meaningless, you'd have to compromise as many authorities as is required to trust a cert, and do so within a time period short enough to avoid at least one of those being revoked/removed from browsers.