No, I'm fully aware we don't trust the CAs with our personal data. We're trusting the CAs to vouch for the organizations to whom they issue certificates. But now there are hordes of CAs, some of whom may not be particularly trustworthy, but the browser makers don't descriminate (much).
As a result, we have CAs that we're supposed to trust because our browsers accept them, but those CAs are passing out SSL certs like candy to anyone with a few bucks.
While we're not directly giving our personal data to the CAs, we're trusting the organizations they vouch for on the basis of the supposed trustworthiness of the CAs, when in fact most of them are utterly opaque and unknown to us, thus indirectly trusting them to protect our personal data.
Again I say, anyone on the internet should look at the diagram, look at the list of signing authorities their browsers trust, and ask themselves, "who the hell are all these people and why do I trust them?"
OH I definitely agree that the system is broken. Just looking at the site should make anyone on the internet ask themselves, "who the hell all these CAs are and do we really trust them with our most personal data"?
Yes, I think that encrypting your traffic securely is the right thing to do, and using public-private key pairs with cryptographically strong algorithms is the right way to do it, the trust model was broken the first day that money started to change hands as a surrogate for "trust"
completely unnecessary if you use a good password.
That's a dangerously incorrect assertion to make. People's battle.net accounts don't get compromised because a malicious party cracked a password. Keyloggers, phishing, social engineering, and just plain fraud are all far more common avenues for password leakage, both in battle.net and overall.
The days when a hacker could bang on the front door of a service trying username/password combinations until finding one that worked are long gone. The reason Blizzard introduced authenticators was because their own experience indicated that no matter how tightly locked the servers, or how strong the password requirements, with the client software and hardware out of their control, passwords were still getting out. So they went with the next best convenient security practice: something you know, and something you have.
Good answer. To be fair to the parent post, the certificate authorities *do* have some work to do in cleaning their own houses. Stolen or compromised certificates do exist, and while we can revoke the ones we know about, there's the ones we don't know about, and there's the clients that don't handle revocation properly. It's not clear that the CA houses are doing their jobs well enough.
Next time say, "I'm sorry, I'm a professional software developer, and I have to follow certain principles, same as a doctor or lawyer must follow their respective professional codes. Please contact me when your server side is properly configured and I will be able to complete the work."
That's not wrong, but it still doesn't explain to me why I, as a user, should trust both application A and site B that have agreed to trust each other with a self-signed certificate. The reason was have the CA model is to introduce a trusted third-party* that can verify for us that everything is on the up-and-up. The user should not be in the position of having to trust unknown parties.
*Yes I know the CA companies have problems. Maybe the model is so broken by nature that it doesn't matter, but it's still true that the self-signed model bypasses it.
Defrauding unsuspecting third parties and exposing them to identity theft is still a crime, or at least a civil liability, even if you have a family. Participating in that kind of thing is unethical at best.
Well said. If the company doesn't start out with enough money to purchase the things necessary, it's not doing it right. To attempt a real-world analogy, would you put your money in a bank that delayed purchasing a vault until it had enough of the customer's money to afford one?
They might be, but then who in their right mind would trust that kind of party with their money and PII? In choosing how to spend their limited cash, they forgo proper security precautions, and they want users to trust them not to misuse or misplace sensitive information?
it does not delegate trust to some 3rd party that might screw up and cause things to have be changed, or risk compromise
Instead, the company that issues the self-signed certificate is to be trusted not to screw up? "Just take our certificate, it's fine, trust us".
If Alice and Bob trust each other, this is OK, but what if Bob is bumbling idiot? What about when Alice and Bob, who trust each other, tell Mallory to trust them to trust each other, and Carol mistakenly trusts Mallory?
I would not use $RANDOM_SHOPPING_BANKING_APP, but I would visit a bank website using chrome, firefox, or the built-in android browsers. Those three programs, while undoubtedly not flawless, at least have enough respectability and history for me to trust them as well as anything on the internet. Admittedly, that's not much trust, but it's something.
Presumably you can write them for iOS, and I have no doubt that there are plenty of apps on the AppStore that are playing fast and loose with SSL trust managers.
True fact: I have written Java code to allow for self-signed or any old cert over SSL, or even none. It's not hard to find plenty of sample code. In the course of my employment the code was used for testing only and either not part of a production build or disabled by default in production, but I cannot say what other developers or teams may have done in with my code in their systems.
Why the authors focused on Android and why they felt the need to blame the OS rather than alerting people to cruddy apps, one can only speculate.
You have a nice playground called linux, and you ask everyone who comes to play in it to follow your rules, except for parts around the edges where you let other people make their own rules. One of the playground bullies comes along and says you should make the shiniest most fun part of your playground where you ask everyone to follow your rules into an "anyone else can make the rules" area. This bully says you have to do it because he needs to make more friends, and all the people he wants to be friends with play in the shiny part of your playground. You tell the bully that no, he has to make friends by being nice, not by making other people follow his rules, and he calls you a meanie doodoo head and says it's your fault he doesn't have any friends.
Spreadsheets -- well, Excel really -- are inescapable in business.
I know personally of complex multimillion dollar deals in the oil and gas business involving buying and selling entire refineries and gas pipelines where the numbers were all worked out on a spreadsheet.
The insurance industry lives on the spreadsheets put together by the actuaries.
The only consistent reason I've seen for Excel users will give up their rows and columns and have bespoke software created is when the dataset gets cumbersomely large. A secondary reason is when the kinds of calculations needed can't be cobbled together with Excel's function and macro tools. Even then, it's not unheard of for users to demand summary/aggregate reports and analytics that they then copy the numbers from into their spreadsheet to do their scenarios.
Just keep in mind the next time you hear about big money moving around in some deal -- somewhere someone probably had a pivot table for that.
Cookies are just one way to track. They aren't even the most convenient way anymore, in the technical sense, because of browser single-origin policies.
Slashdot Mirror
Betteridge's Law of Headlines applies.
No, I'm fully aware we don't trust the CAs with our personal data. We're trusting the CAs to vouch for the organizations to whom they issue certificates. But now there are hordes of CAs, some of whom may not be particularly trustworthy, but the browser makers don't descriminate (much).
As a result, we have CAs that we're supposed to trust because our browsers accept them, but those CAs are passing out SSL certs like candy to anyone with a few bucks.
While we're not directly giving our personal data to the CAs, we're trusting the organizations they vouch for on the basis of the supposed trustworthiness of the CAs, when in fact most of them are utterly opaque and unknown to us, thus indirectly trusting them to protect our personal data.
Again I say, anyone on the internet should look at the diagram, look at the list of signing authorities their browsers trust, and ask themselves, "who the hell are all these people and why do I trust them?"
OH I definitely agree that the system is broken. Just looking at the site should make anyone on the internet ask themselves, "who the hell all these CAs are and do we really trust them with our most personal data"?
Yes, I think that encrypting your traffic securely is the right thing to do, and using public-private key pairs with cryptographically strong algorithms is the right way to do it, the trust model was broken the first day that money started to change hands as a surrogate for "trust"
DFN-Verein "creates a unique sub-CA for each institution for which it issues certificates"
I feel sorry for the technical folks who have to implement and maintain such a fucked up idea as per-institutional sub-CAs.
completely unnecessary if you use a good password.
That's a dangerously incorrect assertion to make. People's battle.net accounts don't get compromised because a malicious party cracked a password. Keyloggers, phishing, social engineering, and just plain fraud are all far more common avenues for password leakage, both in battle.net and overall.
The days when a hacker could bang on the front door of a service trying username/password combinations until finding one that worked are long gone. The reason Blizzard introduced authenticators was because their own experience indicated that no matter how tightly locked the servers, or how strong the password requirements, with the client software and hardware out of their control, passwords were still getting out. So they went with the next best convenient security practice: something you know, and something you have.
It's all done with computers now.
PATENT THAT!!!
I can't answer that right now, I don't have a tinfoil hat handy. Sorry.
Good answer. To be fair to the parent post, the certificate authorities *do* have some work to do in cleaning their own houses. Stolen or compromised certificates do exist, and while we can revoke the ones we know about, there's the ones we don't know about, and there's the clients that don't handle revocation properly. It's not clear that the CA houses are doing their jobs well enough.
Next time say, "I'm sorry, I'm a professional software developer, and I have to follow certain principles, same as a doctor or lawyer must follow their respective professional codes. Please contact me when your server side is properly configured and I will be able to complete the work."
That's not wrong, but it still doesn't explain to me why I, as a user, should trust both application A and site B that have agreed to trust each other with a self-signed certificate. The reason was have the CA model is to introduce a trusted third-party* that can verify for us that everything is on the up-and-up. The user should not be in the position of having to trust unknown parties.
*Yes I know the CA companies have problems. Maybe the model is so broken by nature that it doesn't matter, but it's still true that the self-signed model bypasses it.
Defrauding unsuspecting third parties and exposing them to identity theft is still a crime, or at least a civil liability, even if you have a family. Participating in that kind of thing is unethical at best.
Well said. If the company doesn't start out with enough money to purchase the things necessary, it's not doing it right. To attempt a real-world analogy, would you put your money in a bank that delayed purchasing a vault until it had enough of the customer's money to afford one?
Do they actually check or are you saying they could or should?
They might be, but then who in their right mind would trust that kind of party with their money and PII? In choosing how to spend their limited cash, they forgo proper security precautions, and they want users to trust them not to misuse or misplace sensitive information?
it does not delegate trust to some 3rd party that might screw up and cause things to have be changed, or risk compromise
Instead, the company that issues the self-signed certificate is to be trusted not to screw up? "Just take our certificate, it's fine, trust us".
If Alice and Bob trust each other, this is OK, but what if Bob is bumbling idiot? What about when Alice and Bob, who trust each other, tell Mallory to trust them to trust each other, and Carol mistakenly trusts Mallory?
Translation: I just wanted to take the money and run. Making money, that was the important thing. Yeah, money. Did I mention I needed the money?
Let me tell you the story about the guy who wanted to use oauth2 bearer tokens over an unsecured connection.
à_à
This is why we can't have nice things.
I would not use $RANDOM_SHOPPING_BANKING_APP, but I would visit a bank website using chrome, firefox, or the built-in android browsers. Those three programs, while undoubtedly not flawless, at least have enough respectability and history for me to trust them as well as anything on the internet. Admittedly, that's not much trust, but it's something.
Presumably you can write them for iOS, and I have no doubt that there are plenty of apps on the AppStore that are playing fast and loose with SSL trust managers.
True fact: I have written Java code to allow for self-signed or any old cert over SSL, or even none. It's not hard to find plenty of sample code. In the course of my employment the code was used for testing only and either not part of a production build or disabled by default in production, but I cannot say what other developers or teams may have done in with my code in their systems.
Why the authors focused on Android and why they felt the need to blame the OS rather than alerting people to cruddy apps, one can only speculate.
You have a nice playground called linux, and you ask everyone who comes to play in it to follow your rules, except for parts around the edges where you let other people make their own rules. One of the playground bullies comes along and says you should make the shiniest most fun part of your playground where you ask everyone to follow your rules into an "anyone else can make the rules" area. This bully says you have to do it because he needs to make more friends, and all the people he wants to be friends with play in the shiny part of your playground. You tell the bully that no, he has to make friends by being nice, not by making other people follow his rules, and he calls you a meanie doodoo head and says it's your fault he doesn't have any friends.
Spreadsheets -- well, Excel really -- are inescapable in business.
I know personally of complex multimillion dollar deals in the oil and gas business involving buying and selling entire refineries and gas pipelines where the numbers were all worked out on a spreadsheet.
The insurance industry lives on the spreadsheets put together by the actuaries.
The only consistent reason I've seen for Excel users will give up their rows and columns and have bespoke software created is when the dataset gets cumbersomely large. A secondary reason is when the kinds of calculations needed can't be cobbled together with Excel's function and macro tools. Even then, it's not unheard of for users to demand summary/aggregate reports and analytics that they then copy the numbers from into their spreadsheet to do their scenarios.
Just keep in mind the next time you hear about big money moving around in some deal -- somewhere someone probably had a pivot table for that.
Cookies are just one way to track. They aren't even the most convenient way anymore, in the technical sense, because of browser single-origin policies.
Does he not also realize how easy it is for users to block sites that don't honor Do Not Track?