Re:Nowhere else for Palm to go...
on
Palm to go Linux
·
· Score: 2, Insightful
I never get that "if it weren't for Microsoft" argument either.
What, there was no computer industry, no competition between diverse new products, no standards activity, no open source software? I was there, man. The industry was thriving, there were dozens of different microprocessors hitting the market, vendors were moving in droves from proprietary operating systems to Unix, the price/performance trend had never been better, every University department was getting its own computer and building its own network, and there were interesting jobs everywhere. Though there was as yet no GPL, software developed and shared among users was actively supported by the industry.
All Microsoft did was to show up at the party with a cheap bottle of wine. Indeed, its notoriously poor quality of software plus parasitic corporate ethics arguably skewed and damaged the industry far more than it helped.
I would very much like to see what the world would have become without Microsoft. My guess is that Linux would still have come along as an alternative to the commercial Unixes, and would have tipped the balance toward much better interoperation between all of them. They were never very far apart to begin with. We would have a Unix world, or possibly by this time we would have (gasp) collectively outgrown Unix in favor of something even better. Instead Microsoft has done little more than hold us back.
Best case from bare drives, about an hour. Kickstart / Jumpstart take care of the system and applications, configuration scripts do the rest. This is for Linux and Solaris of course.
Right. I think you're saying that Paypal signatures can only help with verifying Paypal domains, not domains that might to a casual observer look like Paypal domains. I agree with the implied conclusion that signed email don't eliminate this particular type of phishing scam.
Signed email does, however, eliminate the presently very common and significant type of scam that depends on forging emails from legitimate domains.
Signed email also provides an effective basis for spam control, so I have to disagree with you on the point that spam recognition is hard. It's only hard because, at present, it depends entirely on content analysis. If we could make it depend on originating address, because the message signature lets us verify this address, then we could filter without regard to content.
The critical difference is that filtering can now be done reliably. You either filter messages that match a certain address pattern or you don't. So the filtering problem becomes "just" a question of granularity. In other words, if my filter is set up to accept everything from the Paypal domain, and not every Paypal user is well behaved, then I'll see some amount of spam coming through perhaps. But I can then choose to reliably filter out individual addresses which I find bothersome, or I can train a Bayesian filter to do it for me.
On a larger scale, suppose you're right and Paypal tries to leverage the strength of its digital signatures to deliver spam content, to the point that a significant amount of Paypal message traffic becomes spam. What do you think will happen then? MTAs will start to filter the entire domain. And because of the signatures on such traffic
, they will be able to do so reliably.
If emails were digitally signed, the identity of the sender would either verify or would fail to verify. This sounds like the correct approach. In competing approaches, the message is tagged in some way, the problem being that such messages can still be forged.
The barrier to acceptance of any signature approach (and there are several) is getting everybody on board, or at least a large enough segment of the user population to make a compelling case for others to follow. Paypal might be that segment, because it (a) originates large volumes of email, and (b) has built the infrastructure to digitally sign them.
If Paypal can persuade the larger mail transfer agents to reject unsigned messages purporting to be from Paypal users, the case is made. That takes some administrative effort by the MTA but not a lot. Adding few more large players like Paypal requires only incremental effort on the part of the MTAs. Eventually, we get to a point where at some MTAs this filtering is no longer managed as a special case but becomes a general requirement.
I'm a computer scientist. I got started in the days when every single computer model had a different operating system and CLI to go along with it, not to mention differences between programming languages, system calls, and machine architectures.
You can get used to learning all of this again for every new platform, but it's very inefficient and not very deep. The considerable effort to acquire this kind of knowledge leads nowhere. This was, and is, the essential problem with single-vendor solutions.
As a group, scientists are not fascinated by such technological ephemera. If you could get P = NP off an abacus, it would win you extra points.
So imagine how quickly the research community embraced Unix, and how much innovation immediately resulted as Unix licenses began to proliferate. Finally you could acquire a skillset that had lasting value, so that you could spend the day solving real problems instead of perpetually learning to work with a new platform. Moreover, it became reasonable to communicate your results in terms of the Unix environment. You could say, "we've written a new process scheduler for Unix" with reasonable expectation that people could check it out for themselves.
That same Unix CLI is still in all the commercial Unix variants as well as in every Linux distro. It's even in MacOS if you know where to look. That knowledge is fantastically portable. If you have to master a technology, it would seem to be a pretty clear choice. Mastery of Microsoft Windows, on the other hand, only leads to Microsoft Windows.
There's no question that computer and network architectures are becoming increasingly complex. All the components are becoming more complex, and they don't always interoperate as intended. No platform is immune from this effect, but it seems to me that this makes a even stronger case for what we already know, to pool our resources when solving these technology problems so that the improvements will have deep enduring value, and to avoid diverting our expertise into the perpetual struggle to get enduring value out of single-vendor solutions.
Once this is done, corporate proxy can masquerade as any entity the IT department chooses
We have to be careful when talking about certificate identity. It's not the case that a proxy can ever "masquerade" as something else. By being configured with a given certificate and -- critically -- its corresponding private key, that proxy in identity terms becomes that other entity. As you say, this should be no surprise, but this is not familiar territory for many people, and it bears emphasis.
Often people mistakenly think that simply copying and installing a certificate onto a device will give it a new identity. That's due in large part to our careless use of language. Not only the certificate but also the private key must be installed. In any competent organization that private key is closely guarded. Even more closely guarded is the CA infrastructure used to bind certificates to private keys by means of a separate authority.
To return to the point I was making in my previous message, from a perspective outside a given organization, what is privately architected beyond a device it manages is something you strictly can't know and shouldn't care about. Think of it as one big metaserver whose identity has been established by virtue of the certificate identity. There is no purpose in speculating further.
You mentioned something about "seeding a certificate store". In a certificate infrastructure there is no certificate store and therefore no such process. For example, a client typically learn about a server certificate at the time the server itself presents it, not because it has to refer to a common public key store. This is the defining characteristic of digital certificates.
In practice, this presentation is likely to consist, not only of the server certificate, but of all the CA certs all the way up the chain to the root CA cert.
All that a client needs to validate a previously unseen server certificate is therefore a trusted copy of the root certificate. This root cert is used to validate the uppermost CA cert in the chain, which can then be used to validate the next CA cert, and so on to the server certificate.
So indeed, a previously unseen proxy makes its presentation to a client just as any server does. However, I can't see that this constitutes any special reason for worry. Yes, a corrupt Certificate Authority could leak what we might call "counterfeit" certificate/private-key pairs. and those pairs could be misused in many ways. If that happens, effects on the proxy identity will be the least of your worries. All identities from that CA on downward are affected. It should be obvious that there is no effect in the upward direction.
Um... Isn't that the very definition of a man-in-the-middle attack?
Good point.
It's not an attack but it is definitely man-in-the-middle. A server proxy could make good architectural sense, for example when the SSL proxy is a load balancer in front of a server farm. As the client, you can validate that the load balancer is what its certificate claims it to be, say www.foo.com.
What is privately architected beyond that, you don't know, and really shouldn't care.
Just think of the whole thing as one big metaserver whose identity has been established, and not much else. That's all you can assume anyway, right?
Note that the proxy can only succeed at representing itself as having the expected identity because it has been configured with the private key corresponding to that certificate and its identity. In other words, no random person can set up this man-in-the-middle. It opens no more of a vector for attack than root access to a plain old webserver would confer.
In fact, for those who advocate functional separation as a way to improve security, it has the same advantages that a firewall appliance has over managing a firewall local to each server. The firewall is not made vulnerable by defects in server software, and vice versa.
Great. This should be a very nice market in which several competent manufacturers could compete.
Diebold doesn't seem to have the will to improve its offering, or even to take an honest look at its shortcomings. It's hard to see how others couldn't do a lot better.
Absolutely right. For God's sake, there is no need to build a requirement for privilege escalation into normal user activities such as installing software.
Some people will respond that it's an inefficient use of space to have a multiuser system with every user installing his own software. Well, duh, that's why multiuser systems for the past four decades have professional system administrators to perform systemwide tasks on behalf of the user population.
As the value of the system goes up, so does the standard of support. On any critical system, it would be intolerable to have multiple untrained users all busy installing and removing system software and hardware, device drivers, and so on.
So, make a choice. Either contain the scope of what people can do so that they can only hurt themselves, not each other, or give ordinary users system privileges and watch the system go to hell.
How do we "know" that a bridge will not fall down. There are no proofs of bridges. There is only engineering. Engineers apply logic, experience, design, inspection, reviews, and tests, so that they can have confidence in the design. The confidence is based on statistics. For a given shape of steel or concrete, we can measure loads that cause the steel to fail, and we can measure the variance in those loads due to the manufacturing tolerances of the material. When we use that shape and material to build the bridge, we can have statistics about how much load the bridge can support without failing.
Implicit in all of this is the use of a relatively small range of materials with well defined properties. Software is made out of... bits. No material properties, thus very hard to predict its behavior.
I was wondering about this comment as well. Clearly the point of champagne is not to have the carbon dioxide outgas all at once. The enjoyment of champagne is intended to be leisurely and reflective as well as festive. The bubbles are visually interesting but that doesn't require an abundant flow of bubbles. The texture of champagne on the palate is the real test, and again there's an optimal point somewhere in the middle between tingling and explosive. You want to make that optimal moment last, especially with finer champagnes.
The final champagne that we had last night was a 1982 Drappier Brut, past its prime really but fascinating just the same. It had lost some pressure over the years but it still produced a lovely subtle curtain of bubbles and a very fine and moderately persistent mousse on the palate. After ten minutes in the glass it had more or less run out and was not as rewarding without the texture. The last thing I would have wanted would be a champagne flute engineered to exhaust that wine more quickly.
Cheers,
In case anyone doesn't already know him by reputation, Peter Gutmann isn't just some random blogger with a grudge against Microsoft.
Yes, he tends to be a bit outspoken at times. He's also a veteran contributor to the security field and tends to know exactly what he's talking about. So before dismissing what he has to say, you owe it to yourself to check his reasoning.
Complexity isn't a problem if it's hidden from the user. For example, if you improve a car engine's efficiency. In software, you can (fortunately) add more features without adding complexity.
Not true, though I agree with your sentiment. Complexity is a ubiquitous problem in software engineering, and it's fair to say that most techniques of software engineering exist for the purpose of reducing or managing complexity. But don't take my word for it, read back through a couple of decades of IEEE Transactions on Software Engineering for examples of issues and proposed solutions. I also don't want to suggest that the problem is unique to software, though Fred Brooks has pointed out that software is necessarily the extreme case. In fact it's a general engineering problem.
It's nice when needless complexity can be hidden from the user. Internal combustion engines used to have a manual spark advance. Now it's done automatically, at some additional cost in engineering complexity, of course, but the design has been sufficiently refined over the years so that the extra complexity is minimal.
And this points to an important observation about design: minimizing complexity is hard work. So why do the work? Because when you compare two functionally equivalent artifacts, the simpler one is easier to produce, easier to maintain, and less prone to failure or behavior out of spec.
Gordon bell was quite right when he said, "The cheapest, fastest, and most reliable components of a computer system are those that aren't there." And this is particularly true of security, because we're interested in assuring not only what the system does but also what it does not do.
I love anonymity. I hate "identity management" which leaves the user with a single "approved and authenticated" online identity.
These are two separate issues, though interesting ones.
It's entirely possible for identity to be both unique and anonymous. That's the intent of an anonymous ballot, and there are many useful situations in which an anonymous ballot can be perfectly realized.
Most identity architectures generalize trivially to allowing a single user to exercise multiple identities. That too can be perfectly realized. There's already been lots of discussion on this, so no need to belabor the point.
But the really interesting, and hard, issue concerns how to establish correspondence between a unique individual in the real world and a unique digital identity. Such an exercise is less about developing a perfect identity model than it is about how to confront the physical conditions of the real world, for example how to tell identical twins apart.
In the X.509 world you can have a Certificate Authority whose specified policy is to issue a unique and randomly numbered certificate every time one is requested. That policy is easy to implement, and it gives each certificate full anonymity, though obviously not uniqueness. If that's all the anonymity you want, it's not hard to set up, though what good it does is not entirely clear.
Then there could be another CA policy which claims to issue a unique and randomly numbered certificate only once to each requestor. You don't necessarily want to let an anonymous certificate be used to apply for a driver's license, but it works well for voting. In a locked room containing ten people, you could issue ten certificates, and as long as nobody complains that they got left out, you've met the conditions. Claims of election fraud notwithstanding, we still find it acceptable to apply an extension of this sort of identity correspondence in the form of a voter's list.
But in an open population, uniqueness requires us to go off and deal with the correspondence problem, even in the anonymous case. Obviously you can't solve correspondence by reference to another supposed source of unique identity. All that does is defer the problem, even though in practice that's what every Certificate Authority does.
So my point is, don't worry too much about anonymity. That's easy. Don't worry at all about multiplicity, because that comes for free. Worry about how your identity system is going to ensure uniqueness.
This is a worthwhile article to keep on file. Its offers a clear and practical analysis of AJAX in terms of security principles, though biased toward server security and dismissive or incorrect with respect to client security. Read it critically.
Indeed AJAX is not a new technology but a set of existing technologies in combination. Here's the issue though. JavaScript is a known point of vulnerability for clients. Secure clients may be hardened against attacks by disabling JavaScript. Good web design has therefore always required that pages function correctly without use of JavaScript, rather than forcing a client to be configured for greater vulnerability in general for the sake of accessing one website in particular.
But AJAX pages, by definition, unconditionally require JavaScript on the client. Hardened clients need not apply. If your security policy is not concerned with client security, or if your operation can afford to exclude some client systems, then you can regard the security of the AJAX client, as an attack surface, to be out of scope.
However, a general analysis of AJAX security also has to consider tightly integrated applications where client and server security are interrelated. Many web services exist for account administration, inventory control, system configuration, and other operationally critical forms of information management. Note how these activities are controlled by the client. In this context it's fine for servers to perform client authentication and input checking, but the advice to "never trust the client" completely misses the point of developing these applications.
Therefore, the article is incorrect to suggest that AJAX solutions need not be concerned with client security. Moreover, it's evident that AJAX creates a larger attack surface on the client. There are environments where you can decide to exclude these issues from consideration. In a general analysis of security, you cannot.
I reckon it might come in handy in other emergencies too. Years ago I was at this excellent Dylan/Santana concert in Göteborg which was full to capacity. The queue outside the women's washroom was about an hour long. So women in desperation started crashing the men's washroom. Fair enough. We let them have the toilet stalls, but even then there was a major queue of women outside the men's.
Meanwhile the urinals went underused, and that's just the way it was. Now if I was a woman, this would not be the time I tried your technique for the first time. It would take a fair bit of sass anyway. Best get some practice in beforehand. You never know.
Cheers,
it is now necessary that the bearer of the fake passport resembles the image of the person stored with the data on the RFID chip. A question that remains unanswered is whether it is possible to create an entirely fake passport including an RFID chip with the "correct" fictional info and picture.
This question is of course the essential one which digital identity is intended to address. The digital information on the passport is signed with the private key of a certificate authority. The corresponding public key, which is widely available, can be used to validate this information. If the information is altered, it will no longer validate.
I don't know if it's dumb to assume that the purpose of the passport is to supply information to the reader. That's what passports do.
The purpose of encrypting the session is to prevent man in the middle scenarios in which the data could be forged in transit. It's not intended to prevent extraction of the data or act as a source of validation. It's a symmetric cypher, after all.
Finally, a note of wisdom emerges above the usual background noise.
Of course information can be extracted from the passport. That is its purpose, after all. The printed information has this property as well, and it can be forged by purely physical means.
The digital information, on the other hand, is signed by a certificate authority. While it may well be possible to create an exact duplicate of the passport, such duplicates are less valuable than a printed source of identity because they can't be used as the raw material for forgery. As you point out, modifications will not validate against the certificate signature.
As is often the case with security, the main risk is not due to vulnerability of the data but to mistaken inferences about how to apply it. People may simplistically think these passports are "more secure" and therefore treat them more casually. In the worst case, they will accept mere posession of the passport as identity, without validation, during some transaction which is then used to generate a secondary identity.
Yeah, I can the universe of possibilities unstacking before me like mirror images in a barbershop.
If you can play air guitar, you're already set. Everyone knows what a virtuoso musician you'd be with an actual instrument in your hands. Why not the same for furniture design?
The real "missed opportunitity", if you think of it as such, was from the middle of the last century in Bletchley Park and elsewhere. That's when cryptography and computer science started to come together.
Has anyone actually been able to find the specification for "high assurance" certificates?
I have not, and it strikes me as conspicuous by its absence. Especially since the X.509 standard already contains provisions for a Policy OID for exactly this purpose.
In fact the Policy extension provides for for a much richer set of purposes than EV has conceived. It would be quite acceptable, for example, to define an "anonymizing" policy or a "voting" policy in which the Certificate Authority has assured that certificate identity is unique but not traceable.
Possibly Mozilla is holding out for a more generalized solution in which users can decide the conditions under which the URL bar turns green, by matching against a qualifying set of Policy OIDs as just one example.
Asymmetric crypto already provides the foundation for what you've described.
With the appropriate public key infrastructure, the necessary amount of information associated with a key pair can be made public, while the rest remains private so that it can be applied in cryptographically secure ways, for example to certify a transaction, without exposing the information itself.
Not many people understand how this works, so it's been historically hard to deploy, but it can be done.
Slashdot Mirror
What, there was no computer industry, no competition between diverse new products, no standards activity, no open source software? I was there, man. The industry was thriving, there were dozens of different microprocessors hitting the market, vendors were moving in droves from proprietary operating systems to Unix, the price/performance trend had never been better, every University department was getting its own computer and building its own network, and there were interesting jobs everywhere. Though there was as yet no GPL, software developed and shared among users was actively supported by the industry.
All Microsoft did was to show up at the party with a cheap bottle of wine. Indeed, its notoriously poor quality of software plus parasitic corporate ethics arguably skewed and damaged the industry far more than it helped.
I would very much like to see what the world would have become without Microsoft. My guess is that Linux would still have come along as an alternative to the commercial Unixes, and would have tipped the balance toward much better interoperation between all of them. They were never very far apart to begin with. We would have a Unix world, or possibly by this time we would have (gasp) collectively outgrown Unix in favor of something even better. Instead Microsoft has done little more than hold us back.
It's like, yeah, that's really how I configure iptables or add a server cert to Apache.
Best case from bare drives, about an hour. Kickstart / Jumpstart take care of the system and applications, configuration scripts do the rest. This is for Linux and Solaris of course.
Signed email does, however, eliminate the presently very common and significant type of scam that depends on forging emails from legitimate domains.
Signed email also provides an effective basis for spam control, so I have to disagree with you on the point that spam recognition is hard. It's only hard because, at present, it depends entirely on content analysis. If we could make it depend on originating address, because the message signature lets us verify this address, then we could filter without regard to content.
The critical difference is that filtering can now be done reliably. You either filter messages that match a certain address pattern or you don't. So the filtering problem becomes "just" a question of granularity. In other words, if my filter is set up to accept everything from the Paypal domain, and not every Paypal user is well behaved, then I'll see some amount of spam coming through perhaps. But I can then choose to reliably filter out individual addresses which I find bothersome, or I can train a Bayesian filter to do it for me.
On a larger scale, suppose you're right and Paypal tries to leverage the strength of its digital signatures to deliver spam content, to the point that a significant amount of Paypal message traffic becomes spam. What do you think will happen then? MTAs will start to filter the entire domain. And because of the signatures on such traffic , they will be able to do so reliably.
The barrier to acceptance of any signature approach (and there are several) is getting everybody on board, or at least a large enough segment of the user population to make a compelling case for others to follow. Paypal might be that segment, because it (a) originates large volumes of email, and (b) has built the infrastructure to digitally sign them.
If Paypal can persuade the larger mail transfer agents to reject unsigned messages purporting to be from Paypal users, the case is made. That takes some administrative effort by the MTA but not a lot. Adding few more large players like Paypal requires only incremental effort on the part of the MTAs. Eventually, we get to a point where at some MTAs this filtering is no longer managed as a special case but becomes a general requirement.
You can get used to learning all of this again for every new platform, but it's very inefficient and not very deep. The considerable effort to acquire this kind of knowledge leads nowhere. This was, and is, the essential problem with single-vendor solutions.
As a group, scientists are not fascinated by such technological ephemera. If you could get P = NP off an abacus, it would win you extra points. So imagine how quickly the research community embraced Unix, and how much innovation immediately resulted as Unix licenses began to proliferate. Finally you could acquire a skillset that had lasting value, so that you could spend the day solving real problems instead of perpetually learning to work with a new platform. Moreover, it became reasonable to communicate your results in terms of the Unix environment. You could say, "we've written a new process scheduler for Unix" with reasonable expectation that people could check it out for themselves.
That same Unix CLI is still in all the commercial Unix variants as well as in every Linux distro. It's even in MacOS if you know where to look. That knowledge is fantastically portable. If you have to master a technology, it would seem to be a pretty clear choice. Mastery of Microsoft Windows, on the other hand, only leads to Microsoft Windows.
There's no question that computer and network architectures are becoming increasingly complex. All the components are becoming more complex, and they don't always interoperate as intended. No platform is immune from this effect, but it seems to me that this makes a even stronger case for what we already know, to pool our resources when solving these technology problems so that the improvements will have deep enduring value, and to avoid diverting our expertise into the perpetual struggle to get enduring value out of single-vendor solutions.
We have to be careful when talking about certificate identity. It's not the case that a proxy can ever "masquerade" as something else. By being configured with a given certificate and -- critically -- its corresponding private key, that proxy in identity terms becomes that other entity. As you say, this should be no surprise, but this is not familiar territory for many people, and it bears emphasis.
Often people mistakenly think that simply copying and installing a certificate onto a device will give it a new identity. That's due in large part to our careless use of language. Not only the certificate but also the private key must be installed. In any competent organization that private key is closely guarded. Even more closely guarded is the CA infrastructure used to bind certificates to private keys by means of a separate authority.
To return to the point I was making in my previous message, from a perspective outside a given organization, what is privately architected beyond a device it manages is something you strictly can't know and shouldn't care about. Think of it as one big metaserver whose identity has been established by virtue of the certificate identity. There is no purpose in speculating further.
You mentioned something about "seeding a certificate store". In a certificate infrastructure there is no certificate store and therefore no such process. For example, a client typically learn about a server certificate at the time the server itself presents it, not because it has to refer to a common public key store. This is the defining characteristic of digital certificates.
In practice, this presentation is likely to consist, not only of the server certificate, but of all the CA certs all the way up the chain to the root CA cert. All that a client needs to validate a previously unseen server certificate is therefore a trusted copy of the root certificate. This root cert is used to validate the uppermost CA cert in the chain, which can then be used to validate the next CA cert, and so on to the server certificate.
So indeed, a previously unseen proxy makes its presentation to a client just as any server does. However, I can't see that this constitutes any special reason for worry. Yes, a corrupt Certificate Authority could leak what we might call "counterfeit" certificate/private-key pairs. and those pairs could be misused in many ways. If that happens, effects on the proxy identity will be the least of your worries. All identities from that CA on downward are affected. It should be obvious that there is no effect in the upward direction.
Good point.
It's not an attack but it is definitely man-in-the-middle. A server proxy could make good architectural sense, for example when the SSL proxy is a load balancer in front of a server farm. As the client, you can validate that the load balancer is what its certificate claims it to be, say www.foo.com.
What is privately architected beyond that, you don't know, and really shouldn't care. Just think of the whole thing as one big metaserver whose identity has been established, and not much else. That's all you can assume anyway, right?
Note that the proxy can only succeed at representing itself as having the expected identity because it has been configured with the private key corresponding to that certificate and its identity. In other words, no random person can set up this man-in-the-middle. It opens no more of a vector for attack than root access to a plain old webserver would confer.
In fact, for those who advocate functional separation as a way to improve security, it has the same advantages that a firewall appliance has over managing a firewall local to each server. The firewall is not made vulnerable by defects in server software, and vice versa.
Diebold doesn't seem to have the will to improve its offering, or even to take an honest look at its shortcomings. It's hard to see how others couldn't do a lot better.
Some people will respond that it's an inefficient use of space to have a multiuser system with every user installing his own software. Well, duh, that's why multiuser systems for the past four decades have professional system administrators to perform systemwide tasks on behalf of the user population.
As the value of the system goes up, so does the standard of support. On any critical system, it would be intolerable to have multiple untrained users all busy installing and removing system software and hardware, device drivers, and so on.
So, make a choice. Either contain the scope of what people can do so that they can only hurt themselves, not each other, or give ordinary users system privileges and watch the system go to hell.
Implicit in all of this is the use of a relatively small range of materials with well defined properties. Software is made out of ... bits. No material properties, thus very hard to predict its behavior.
The final champagne that we had last night was a 1982 Drappier Brut, past its prime really but fascinating just the same. It had lost some pressure over the years but it still produced a lovely subtle curtain of bubbles and a very fine and moderately persistent mousse on the palate. After ten minutes in the glass it had more or less run out and was not as rewarding without the texture. The last thing I would have wanted would be a champagne flute engineered to exhaust that wine more quickly. Cheers,
Yes, he tends to be a bit outspoken at times. He's also a veteran contributor to the security field and tends to know exactly what he's talking about. So before dismissing what he has to say, you owe it to yourself to check his reasoning.
Not true, though I agree with your sentiment. Complexity is a ubiquitous problem in software engineering, and it's fair to say that most techniques of software engineering exist for the purpose of reducing or managing complexity. But don't take my word for it, read back through a couple of decades of IEEE Transactions on Software Engineering for examples of issues and proposed solutions. I also don't want to suggest that the problem is unique to software, though Fred Brooks has pointed out that software is necessarily the extreme case. In fact it's a general engineering problem.
It's nice when needless complexity can be hidden from the user. Internal combustion engines used to have a manual spark advance. Now it's done automatically, at some additional cost in engineering complexity, of course, but the design has been sufficiently refined over the years so that the extra complexity is minimal.
And this points to an important observation about design: minimizing complexity is hard work. So why do the work? Because when you compare two functionally equivalent artifacts, the simpler one is easier to produce, easier to maintain, and less prone to failure or behavior out of spec.
Gordon bell was quite right when he said, "The cheapest, fastest, and most reliable components of a computer system are those that aren't there." And this is particularly true of security, because we're interested in assuring not only what the system does but also what it does not do.
These are two separate issues, though interesting ones.
-
It's entirely possible for identity to be both unique and anonymous. That's the intent of an anonymous ballot, and there are many useful situations in which an anonymous ballot can be perfectly realized.
-
Most identity architectures generalize trivially to allowing a single user to exercise multiple identities. That too can be perfectly realized. There's already been lots of discussion on this, so no need to belabor the point.
But the really interesting, and hard, issue concerns how to establish correspondence between a unique individual in the real world and a unique digital identity. Such an exercise is less about developing a perfect identity model than it is about how to confront the physical conditions of the real world, for example how to tell identical twins apart.In the X.509 world you can have a Certificate Authority whose specified policy is to issue a unique and randomly numbered certificate every time one is requested. That policy is easy to implement, and it gives each certificate full anonymity, though obviously not uniqueness. If that's all the anonymity you want, it's not hard to set up, though what good it does is not entirely clear.
Then there could be another CA policy which claims to issue a unique and randomly numbered certificate only once to each requestor. You don't necessarily want to let an anonymous certificate be used to apply for a driver's license, but it works well for voting. In a locked room containing ten people, you could issue ten certificates, and as long as nobody complains that they got left out, you've met the conditions. Claims of election fraud notwithstanding, we still find it acceptable to apply an extension of this sort of identity correspondence in the form of a voter's list.
But in an open population, uniqueness requires us to go off and deal with the correspondence problem, even in the anonymous case. Obviously you can't solve correspondence by reference to another supposed source of unique identity. All that does is defer the problem, even though in practice that's what every Certificate Authority does.
So my point is, don't worry too much about anonymity. That's easy. Don't worry at all about multiplicity, because that comes for free. Worry about how your identity system is going to ensure uniqueness.
Indeed AJAX is not a new technology but a set of existing technologies in combination. Here's the issue though. JavaScript is a known point of vulnerability for clients. Secure clients may be hardened against attacks by disabling JavaScript. Good web design has therefore always required that pages function correctly without use of JavaScript, rather than forcing a client to be configured for greater vulnerability in general for the sake of accessing one website in particular.
But AJAX pages, by definition, unconditionally require JavaScript on the client. Hardened clients need not apply. If your security policy is not concerned with client security, or if your operation can afford to exclude some client systems, then you can regard the security of the AJAX client, as an attack surface, to be out of scope.
However, a general analysis of AJAX security also has to consider tightly integrated applications where client and server security are interrelated. Many web services exist for account administration, inventory control, system configuration, and other operationally critical forms of information management. Note how these activities are controlled by the client. In this context it's fine for servers to perform client authentication and input checking, but the advice to "never trust the client" completely misses the point of developing these applications.
Therefore, the article is incorrect to suggest that AJAX solutions need not be concerned with client security. Moreover, it's evident that AJAX creates a larger attack surface on the client. There are environments where you can decide to exclude these issues from consideration. In a general analysis of security, you cannot.
I reckon it might come in handy in other emergencies too. Years ago I was at this excellent Dylan/Santana concert in Göteborg which was full to capacity. The queue outside the women's washroom was about an hour long. So women in desperation started crashing the men's washroom. Fair enough. We let them have the toilet stalls, but even then there was a major queue of women outside the men's. Meanwhile the urinals went underused, and that's just the way it was. Now if I was a woman, this would not be the time I tried your technique for the first time. It would take a fair bit of sass anyway. Best get some practice in beforehand. You never know. Cheers,
This question is of course the essential one which digital identity is intended to address. The digital information on the passport is signed with the private key of a certificate authority. The corresponding public key, which is widely available, can be used to validate this information. If the information is altered, it will no longer validate.
The purpose of encrypting the session is to prevent man in the middle scenarios in which the data could be forged in transit. It's not intended to prevent extraction of the data or act as a source of validation. It's a symmetric cypher, after all.
Of course information can be extracted from the passport. That is its purpose, after all. The printed information has this property as well, and it can be forged by purely physical means.
The digital information, on the other hand, is signed by a certificate authority. While it may well be possible to create an exact duplicate of the passport, such duplicates are less valuable than a printed source of identity because they can't be used as the raw material for forgery. As you point out, modifications will not validate against the certificate signature.
As is often the case with security, the main risk is not due to vulnerability of the data but to mistaken inferences about how to apply it. People may simplistically think these passports are "more secure" and therefore treat them more casually. In the worst case, they will accept mere posession of the passport as identity, without validation, during some transaction which is then used to generate a secondary identity.
If you can play air guitar, you're already set. Everyone knows what a virtuoso musician you'd be with an actual instrument in your hands. Why not the same for furniture design?
If you're talking about S/MIME, it's standard in most mailers. How about Thunderbird, Evolution, or even Microsoft Outlook?
The real "missed opportunitity", if you think of it as such, was from the middle of the last century in Bletchley Park and elsewhere. That's when cryptography and computer science started to come together.
I have not, and it strikes me as conspicuous by its absence. Especially since the X.509 standard already contains provisions for a Policy OID for exactly this purpose.
In fact the Policy extension provides for for a much richer set of purposes than EV has conceived. It would be quite acceptable, for example, to define an "anonymizing" policy or a "voting" policy in which the Certificate Authority has assured that certificate identity is unique but not traceable.
Possibly Mozilla is holding out for a more generalized solution in which users can decide the conditions under which the URL bar turns green, by matching against a qualifying set of Policy OIDs as just one example.
With the appropriate public key infrastructure, the necessary amount of information associated with a key pair can be made public, while the rest remains private so that it can be applied in cryptographically secure ways, for example to certify a transaction, without exposing the information itself.
Not many people understand how this works, so it's been historically hard to deploy, but it can be done.