Rogue SSL Certs Issued For CIA, MI6, Mossad 152
Orome1 writes with this excerpt from Help Net Security: "The number of rogue SSL certificates issued by Dutch CA DigiNotar has ballooned from one to a couple dozen to over 250 to 531 in just a few days. As Jacob Appelbaum of the Tor project shared the full list of the rogue certificates, it became clear that fraudulent certificates for domains of a number of intelligence agencies from around the world were also issued during the CA's compromise — including the CIA, MI6 and Mossad. Additional targeted domains include Facebook, Yahoo!, Microsoft, Skype, Twitter, Tor, Wordpress and many others."
Wow... (Score:2)
Re:Wow... (Score:5, Interesting)
Related: Forget Rogue, Microsoft handed ability to intercept SSL on windows [google.com] (Another Wikileaks revelation [google.com], translated) to Tunisian dictator Ben Ali, apparently in return for contracts, stifling open source competition etc etc in Tunisia and allowing them to intercept Facebook, Google,... before the Arab spring revolution took place.
Re: (Score:2)
Ben Ali should ask for his money back.
Re:Wow... (Score:5, Interesting)
Not really. Any government can get their state CA included in the windows root CA list just for the asking. OSX and Firefox are slightly more restrictive, but not in a useful way, they allow lots of state CAs as well.
This is a broad problem with the HTTPS system, too many unrestricted root CAs with no concern for realistic security scenarios.
This is not a good system, but it has nothing to do with Tunisia. The wikileaks cable you posted doesn't even talk about SSL, just about how using supported Microsoft software in the government will make the government more effective at everything, including domestic espionage.
Re: (Score:2)
Any government can get their state CA included, but any user can have the CA revoked on their own computer. The problem with the intercept is that you can remove the CA, only to have it magically reappear upon visiting a site signed by their certificate.
that needs to be a slashdot story (Score:2)
... im trying to google around a little bit to write one, but im frankly exhausted.
Re:Wow... (Score:5, Informative)
Re: (Score:3)
(I have tried it).
The CA I usually use catches it and warns you, but some other CAs take your money and leave you with a mostly-useless certificate.
Re: (Score:2)
Re: (Score:2)
That doesn't even work, browsers would reject that as invalid.
This pisses me off (Score:2)
It pisses me off how I have to jump through so many damn hoops only to get a false sense of security. We might as well go to using self signed certs as the norm for all the added security CAs give us.
well managed self-signed certs are safer (Score:4, Insightful)
At least you know how many and which certs were issued from an authority that you run yourself.
The chain of trust is only as strong as the weakest link in the chain.
Re:well managed self-signed certs are safer (Score:5, Interesting)
That may very well work for you or your organization. Not so much for third parties or the internet, which is the case here. I mean... would you trust a bank's homepage if it's self-signed?
Re:well managed self-signed certs are safer (Score:5, Interesting)
If I could pick up the cert from a local branch or by taking a picture of a barcode on the screen of an ATM, probably.
Re: (Score:2)
But that would basically limit all of your online transactions to businesses with a local office within driving range. Not many people are going to be willing to fly to Seattle just to get a cert to buy something online from Amazon...
Re: (Score:2)
Then you talk to a bank agent over they phone and they read you the fingerprint of the self-signed cert. You verify it and if you believe this person works for the bank, you're done.
The problems with the system have been not within PKI, but the verification of trustworthiness. As a part of fixing this, each of us may have to work a little bit harder in order to establish that we trust a certificate. In fact many would say it is the unwillingness to make this effort that led us to this mess.
Re: (Score:3)
Re: (Score:2)
if you believe this person works for the bank, you're done.
Which still means there is plenty of room for social engineering/hacking. It's still about trust, and talking to someone on the phone doesn't change that.
It's debatable whether this would result in better or worse security, but it's not debatable that the costs in time and money over the current system would skyrocket. Every company on the planet wanting to do online transactions needing customer service reps available any time someone wants to v
Re: (Score:2)
Mailed? How is that secure at *all*? That would be the easiest way to forge something official-looking.
Re: (Score:2)
Part of my point - a company like Amazon is NOT going to hire operators to call 100 million+ customers. They'd much prefer an insecure system with occasional fraud.
Re: (Score:2)
It's not havoc, it's just more work.
Just revoke all the "root" certs in current use, and you're back to the basic:
VERIFY (once, and then once they expire) every trusted cert you use, and sign them with your own key.
Others in this thread mention validating the keys offline, which, for your bank, might make a lot more sense than trusting a third party.
Re: (Score:3)
How does manual verification help the bulk of the population identify fake certs?
Re: (Score:2)
That may very well work for you or your organization. Not so much for third parties or the internet, which is the case here. I mean... would you trust a bank's homepage if it's self-signed?
Yes, I would.
If bank can safely keep my money, you don't think they can safely/securely deliver me their self-signed root certificate which I can import into the browser?
Re: (Score:2)
The big question is how do I have 100% trust that the cert I have in my possession is really from mybank.com?
A CA cert doesn't offer authentication either, when black hats and governments can issue themselves fraudulent certificates to impersonate those websites.
Re: (Score:3)
No, you don't need a centralized trusted org. That is the entire point between the "web of trust" of PGP. I sign my own key and rate it level 4. I sign the keys of my best friends, employer, and the banks where I do business and rate them a level 3. I sign the keys of retail stores where I'm a customer, and the keys of casual acquaintances level 2. I sign the keys of people I know only on the web and rate them no higher than level 1 or 0.
Now, when you are trying to evaluate the key of www.shadybank.com
Re: (Score:2)
So how many people do you really trust to certify that your bank is really your bank? PGP is no better than the gullibility of the people signing and the security of the certificate and signing keys is no better than your average desktop. Revocations are a huge mess in a system with that many actors. What happens when one of those you've signed with level 3 has their certificate compromised? You're not likely to hear about it and even if you do you're not likely to get a revocation out there. And with peopl
Extended validation certificates (Score:3)
Extended validation certificates were definitely a step in the right direction, with a pretty green favicon background.
But that wasn't enough. So we went to Ultra-yotta-analprobed-extented-validated-certificates with a plaid favicon background, thus fixing the problem forever.
Can we move on now? (Score:5, Interesting)
We've now had proof positive that no centralized trust system is workable against a sustained attack. Can we start to get some distributed trust systems in place, instead? The idea of a single proof of identity has failed. It's time to move on to a system that allows multiple checks and balances.
Monocultures are great for creating massive failures, which is why nature wipes them out over time.
Re: (Score:2, Interesting)
Delete all your root certs. Add sites on an individual basis.
But its NOT centralized trust... (Score:5, Interesting)
The root of the problem (pun intended) is NOT that the SSL/TLS certificate hierarchy is a centralized trust, but that there are hundreds of roots of trust, any one of which may be compromised, and all of which are considered equally valid by the browser.
Who outside of the Netherlands even heard about DigiNotar before this happened?
This is why some people like the idea of using DNSSEC for distributing key material: there exists only a single valid path of trust to a single root for a key associated with any given name: its actually more centralized than SSL/TLS, which is what is desired.
Re:But its NOT centralized trust... (Score:4, Interesting)
The trouble with this is that it makes the root cert *insanely* valuable if we start using it in the way you describe. As a practical matter, there needs to be some additional system in place to provide a backstop for the root, so that merely compromising the root is not enough to successfully spoof every domain. DNSSEC + SSL CA is actually not a bad idea. But I am really worried about the push to use DNSSEC as the new single point of failure.
Re: (Score:2)
The trick to hijacking a TLD is to do it without being detected. If you can pull that off, you have something extremely valuable. If you can't, what you have is still useful, but only to a limited degree. But that degree is only limited to the extent that certificate checkers do their jobs correctly, and don't have polluted caches, or have access to good data. If you can hijack the root, and everybody's bank account security depends on the root, then you can do a lot of damage before you're detected
Re:But its NOT centralized trust... (Score:4, Interesting)
its actually more centralized than SSL/TLS, which is what is desired
Centralization only works if you place a high amount of trust in the central organization. Do you trust ICANN? Do you trust .us? .ir? .uk?
The CA system is only broken because there are weak links. The client trusts 200 CAs, and any one of them can sign for any domain. But what if we required 2 CAs to agree? 5? 10? It would be up to the admins of the server to decide how many CAs they wanted to use, and users could decide for themselves how many are required to agree in order to consider the cert valid.
Moxie Marlinspike has some other ideas that sound pretty neat. Unfortunately, at first glance, his techniques seem to also rely on SSL, creating a chicken-and-egg problem. I may have been misunderstanding him, though.
Re: (Score:3)
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.
Perhaps both avenues are required: Each CA may only service one tld (so a compromise
Re: (Score:2)
Good additions/modifications to the idea.
Re: (Score:2)
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.
Re: (Score:2)
The current protocols, OCSP and CRL, don't even help to solve the CA-compromise problem.
They don't even work properly to revoke just one certificate.
There is a lot that needs to change and it needs to be backwardcompatible enough that a transition can be made.
Which doesn't make it an easy task.
But if you have a multi-CA system, you have to have a secure way to single the browser or other application how many that should be. How will you do that ?
What if you have a website with 4 CA's, would that be good eno
Re: (Score:3)
: 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.
Re: (Score:2)
Re: (Score:3)
Can we start to get some distributed trust systems in place, instead?
I suggest getting some Perspectives [mozilla.org] on the whole issue. Not only does it bypass warnings about self-signed certs, it gives an extra warning if a secure site looks hinky despite a valid cert.
Re: (Score:2)
The problem is not "centralized trust". The problem is a mix of x509 evolving but not mandating behavior (in the web context, CRL should be completely sunset and OSCP should be mandatory) and half-assing implementations today in the name of convenience (OSCP implementations are likely to ignore errors instead of failing validation, treating only an explicit 'invalid' as evidence of a problem. The root of the problem is a third party authority is used frequently without checking in with that authority. A
Re: (Score:2)
The idea of identity on the Internet does not work. People have to stop using SSL certificates as a form of identity. They're there to secure a transaction. There are plenty of other ways even with valid certificates to trick a client (or end-user) into trusting a host (slightly different domain name, unicode tricks, ...).
If you want to confirm identity between two parties you have to use 2 and 3-way, multi-channel authentication in both ways. That is more expensive than the current user-password and even u
Way past time... (Score:2)
Time to drop DigiNotar from trusted cert list?
Re: (Score:2)
Uh, it pretty much already happened.
(That is, Microsoft, Google, Mozilla, etc., have dropped them, the various logistics are shaking out as we speak.)
Re: (Score:2)
I believe that's only for Vista+ -- XP would have to have a patch.
Re: (Score:3)
Uh, it pretty much already happened.
(That is, Microsoft, Google, Mozilla, etc., have dropped them, the various logistics are shaking out as we speak.)
Except... in the Netherlands, where DigiNotar is operating from. The government has demanded Microsoft in the Netherlands to delay the rollout of this patch, because it would cause too many problems for users, and because they need more time themselves to get all certificates replaced.
Dutch article about this, including a link to the preliminary report about DigiNotar, here: http://tweakers.net/nieuws/76587/overheid-dwingt-bij-microsoft-vertraagde-windows.html [tweakers.net]
Re: (Score:3)
I've just checked my certs in Chrome and DigiNotar isn't there. I've got the "check for server certificate revocation" option ticked, which I guess must be on by default.
Re: (Score:2)
Just checked FF6.0.1 and they're back. What's happened?
Re: (Score:2)
They are in the list so that you cannot allow them to do anything. Look at the properties, all the check boxes will be untitcked, try to enable any one and then go back to that dialog, they will still be unticked. Also visit an https address that uses a diginotor cert and try to allow it, it will not let you.
Can them! (Score:2)
There is no reason for this company to keep operating after such gross negligence. Any criminal liability here?
Re: (Score:2)
I'm concerned about Vasco, their parent company. They sell hardware and software authentication systems like DIGIPASS and IDENTIKEY, things that are used to protect bank accounts, transit systems, etc. Is there or could there be any cross pollination attack? Were DigiNotar certs used to sign any of the DIGIPASS hardware or software? Do any of the existing DIGIPASS solutions have the DigiNotar certificate baked into them?
F-secure has a partial list (Score:5, Informative)
It may not be complete, but, F-secure has a list [f-secure.com] of the ones created, including *.*.com, *.*.org, www.cia.gov, addons.mozilla.org, *.torproject.org, etc...
Re:F-secure has a partial list (Score:4, Insightful)
Re: (Score:3)
There may be add-on for mozilla that supports wildcard certificates. And since addons.mozilla.org is associated with an alternative certificate, well...
Re: (Score:2)
> Is there any software around that will actually accept
> certificates which are that broad?
There has been in the past; those were considered bugs and fixed. But maybe some users are still running 6-year-old web browsers.
Re: (Score:3)
including *.*.com, *.*.org, www.cia.gov, addons.mozilla.org, *.torproject.org, etc...
err.. forget all those. There's only one you need to know: www.update.microsoft.com
Ownage.
Draw the consequences (Score:3, Insightful)
You can't trust the root CAs. The whole infrastructure is broken and needs to be replaced with something else.
For a start, webbrowsers should notify users if a certificate was replaced, even if the replacement is signed. And browsers shouldn't go into full panic mode over self-signed certs. They're still safer than using an unencrypted connection.
Re: (Score:3)
YES. User interface is at least as important as tech in security: if you have a bad UI, it doesn't matter how secure the infrastructure is, because people will use the bad UI to bypass it.
There are some problems with self-signed certs, but they can be addressed by a better UI. You don't want users to get into the habit of clicking through self-signed certs. But an intelligently thought-ought security model here would be a huge win, because as you say, self-signed certs do add value, particularly in a
Re:Draw the consequences (Score:4, Informative)
For a start, webbrowsers should notify users if a certificate was replaced, even if the replacement is signed.
Certificate Patrol [mozilla.org] for Firefox.
"This add-on reveals when certificates are updated, so you can ensure it was a legitimate change."
The UI is good too. Certificate Patrol, along with NoScript and Cookie Monster [mozilla.org], is a major reason to use Firefox.
X.509 handling is largely neglected by UI designers, not just in web browsers.
Sometime clients actually have options like "[x] Accept all certificates".
Re: (Score:2)
For a start, webbrowsers should notify users if a certificate was replaced, even if the replacement is signed. And browsers shouldn't go into full panic mode over self-signed certs. They're still safer than using an unencrypted connection.
I wonder how many more years it will take until people start realizing that self-signed certs are MUCH safer.
Sigh.
Re: (Score:2)
Absolutely true.
We should have a hierarchy of different levels of trust. E.g. if my bank trusts a CA for credit card payments, I should be able to see in my browser that a secure Web site for payments is trusted by the payment trust chain. I will trust this site, because my bank trusted it (and will reimburse me, if the trust was not merited).
For emails, e.g. I only trust my two email providers, and I got there certs pushed to my mobile phone for enhanced security.
Etc.
The whole "One CA is trusted for ever
Re: (Score:2)
You can perform a MitM attack against an unencrypted connection just as easily - so nothing has changed there.
You can snoop an unencrypted connection without being a MitM but you can't do so on an encrypted connection. Hence clearly the self-signed cert is safer than an unencrypted connection.
Clearly safer - the attacks against it are a subset of the attacks on an unencrypted connection - it removes some vectors without adding any new ones.
time to fix it. (Score:2)
the SSL industry is a nasty piece of work - typical extort-what-the-market-will-bear flavor of non-equilibrium capitalism.
all DNS should be PK-signed and encrypted, and SSL should just use pubkeys found in DNS. a domain owner should be able to establish their own keys, signed by the domain key (which is in turn signed by their registrar as part of registration.)
capitalism isn't the answer (Score:3)
This is capitalism. Digitnotar screws up so they won't be able to charge money anymore.
What you've described is exactly what we have right now except for the pubkeys in DNS part.
A domain owner does establish their own keys, you generate a key pair and send it to the registrar to be signed.
The problem right now isn't lack of capitalism. It isn't that you can't establish your own key.
The problem is that there 150 registrars you might trust to certify a site. One of them is valid and the other 149 are just opp
Re: (Score:2)
The registrars, by contrast, are no less sleazy; but the more you reduce their interchangeability, in the pursuit of security, the less incentive they hav
Re: (Score:2)
The US government only controls the root zone, . (yes, fullstop). ICANN operates them under contract. com, and net are controlled by Verisign, org is controlled by some other lot - Public Domain Registry or something. I've yet to encounter a DNS server which actually queries the root zone regularly, and I've certainly never seen one query the root zone for anything other than a referral to the corresponding TLD's zone.
Facebook (Score:2)
Joke's on them since Facebook still doesn't support SSL!
Re: (Score:3)
Yeah it does. Go look at your account settings again. I've been using SSL on facebook for several months now.
..and now you know: (Score:2)
Couldn't find Ziva's picture, though; I'm SO dissappointed!
Vasco is scared shitless and rightfully so (Score:2, Interesting)
See this statement:
http://www.4-traders.com/VASCO-DATA-SEC-USD-11275/news/VASCO-DATA-SEC-USD-VASCO-DigiNotar-Statement-13782237/
I love it ! (Score:2)
We're finally living in the future : "Iranian cyber-agents have compromised the secure communications link of Western Powers, partly as an effort to monitor activities of their own cyber-citizens and also as retaliation for an earlier Trojan horse computer virus attack which destroyed Iranian nuclear processing equipment".
Flying cars and Linux on the desktop anytime now !
Presumably the CIA, NSA, et al generate own certs? (Score:2)
Presumably the Three Letter Agencies generate their own cert chains themselves, and employees manually confirm the fingerprints and tell their browsers to trust those custom certs? In other words, their internal sensitive data shouldn't be at risk of exposure due to the DigiNotar problems, because they'd be crazy to depend on a cert root that they didn't generate anyway. I can see how this whole fiasco might make a difference for some non-employee accessing a CIA (or whichever) web site, but other than th
Re: (Score:3)
The Three Letter Agencies generate their own cert chains themselves (except those outsourced by the Shiva program), and employees used to manually confirm the fingerprints and tell their browsers to trust those custom certs plus those of their Sri Lankan support agency; Chinese contractors and another 5375 certificates from old contracts that nobody can remember which ones matter any more? In other words, their internal sensitive data shouldn't be at greater than commercially acceptable risk of exposure due to the DigiNotar problems, because they'd have been be crazy to depend on a cert root that they didn't generate in the days when they could afford to spend time defending the USA and not just chasing down evil anti-globalisation and other protesters anyway whilst having to spend hours a day listening to whining from prisoners they're torturing. I can see how this whole fiasco might make a difference for some non-employee accessing a CIA (or whichever) web site, but other than that, it shouldn't be significant for the TLAs senior management... right?
-Karl Fogel
FTFY. Sorry about the loss of conciseness.
The Mossad's web site is unclassified (Score:2)
It's just a front end for their recruiting staff. They post wanted ads there - and then advertise the same ads in Israeli newspapers.
Re: (Score:2)
(De)Centralization isn't the problem (Score:2)
How centralized/decentralized the system is, isn't the problem. The problem is the lack of verification. Every one of the issuers is trusted to operate independently, with no overside or validation. What boggles my mind is that they are even able to issue certificates for domains that have already had certificates issued by someone else.
I'm not surprised that that an issuer got hacked. The only unhackable computer is one that is shut off and physically disconnected from the electrical outlet (you can't
Alternatives (Score:4, Informative)
There has been a lot of push at the recent DEFCON conferences, and associated conversation since, to look at alternatives to the current CA system. Moxie Marlinspike [twitter.com] has been pushing a remote-view notary system called which is currently a Firefox plug, and [convergence.io]Dan Kaminsky has been pushing for DNSSEC. [twitter.com]
There has been an awful lot of discussion [stackexchange.com] about the technical details of SSL certificates on the Security StackExchange [stackexchange.com] (Stack Overflow cousin) website, including the related blog post I penned: A Risk-Based Look at Fixing the Certificate Authority Problem [blogoverflow.com].
Diginotar's responses: irritating (Score:2)
On Diginotar's site you can barely tell anything happened, except for a small "security incident" press release.
They are still trying to minimise it when it seems likely the whole company will be shut down for complete failure.
Cowards.
Certificates try to solve 2 issues. (Score:2)
Certificates serve two purposes:
1. 2 Way Encription. (Security)
2. Verifying the Site's (Identity).
Microsoft and Mozilla's Brain dead Idea of putting HUGE warnings up for "Self Signed Certificates" means that people cannot just choose security. IMHO a certificates primary use.
By using "Authority" signed Certificates people are "Trusting" someone else to secure their data. - and paying a large(ish) sum of money for this service.
I would Prefer if every site had a self signed certificate. and a Separate n
Re: (Score:3)
"Actually I think the secret service domains are the least alarming part. It's sexy, and will probably lead to a lot of questions and interest from government agencies. Of course, nobody wants to get caught with their pants down, but there's really no classified information on these domains. Those are on separate, secured internal networks. So the practical security impact of the Iranian government getting a certificate for the CIA is nill. It's really just very embarrassing, tha
Re: (Score:2)
Re: (Score:2)
How would handing out PGP keys be any different from using self-signed certs? Although it's obvious now that self-signed certs would definitely be an improvement.
Re: (Score:2)
How would using self-signed certs be an improvement? As long as the CAs that do this are revoked it seems like it would still be a more secure system than requiring the end user to manually trust every single HTTPS site on the internet. Most users would never know the difference from a spoofed web site with a self-signed certificate vs a spoofed web site with a CA-signed certificate...
Re:PGP-based system? (Score:4, Informative)
Self-signed certs are an improvement because they're harder to forge or steal. In case you haven't been paying attention over the last few years, we have this thing called Distributed Verification AKA an SSL Notary system to prevent MITM attacks.
The centrally controlled system of CAs relies on perfect security at the CA (which as we've seen, they don't have) and a constant game of whack-a-mole to revoke certs. Long story short we have to stop using certs for authentication, it was a stupid idea but we all crossed our fingers and hoped it could work, but as we can see now, it can't. It's better to just use a self-signed cert that can't be stolen or forged at your choice of a few convenient locations and use distributed verification to prevent MITM attacks. That way you know you have an encrypted connection between your PC and the web host using the same cert other people around the world are seeing, and that's the most you can hope for without sending out-of-channel information (which isn't the worst idea in the world, BTW) or relying on some idiotic system of "trust dealers" like CAs which are just a disaster waiting to happen.
Re: (Score:2)
Self-signed certs would be an improvement because they wouldn't implicitly promise anything they couldn't deliver.
Also, if we all used self-signed certs we'd know how to check them. The bank would have its cert fingerprint on its business cards. If you called up the receptionist would know what a key fingerprint would be.
The situation was a failure in concept alone, then they picked Verisign to implement it and it went from bad to intentionally criminal. Then they opened it up to everyone and their dog and
Re: (Score:2)
It's a good point in theory, the problem is in practice it's an economic tradeoff between security and cost (cost being all of implementation, customer support, and general complication ie. online revenue for the majority of consumers who just "doesn't want to know").
Just look at the credit card companies for an example - the system is horribly insecure but they have calculated that the overhead in implementation costs (minor) + lost usage/revenue for customers having to do *anything* extra to buy shit onli
Re: (Score:2)
And the cost is nice and minimal, until there's - oh let's just say - an intrusion at a cert provider that let the attacker generate 500+ certs, and then a scripted attack hits and drains hundreds of billions before bringing the economy to a standstill for fear of fraud and/or locked accounts.
The problem with security flaws is that their potential cost is usually something like "an order of magnitude larger than our revenue for a decade" or some other absolutely unbearable cost.
Re: (Score:2)
and then a scripted attack hits and drains hundreds of billions before bringing the economy to a standstill
Great for a movie plot, but luckily in the real world there are plenty of other safeguards guaranteeing these things don't pass a level those companies consider "painful".
Not that I'm not saying the system isn't a bit bizarre - my CC number was used just a few weeks ago to make a couple of fraudulent purchases before the account was automatically disabled. In the end it was both disturbing how easy it
Re: (Score:3)
In the end it was both disturbing how easy it was for someone to use my credit card, and impressive how a couple of minor charges were so quickly and accurately detected as fraud...
On the other hand, the fraud detection systems on credit cards can often be a pain to customers because they get a large number of false positives. My cards have been disabled numerous times because the bank thought that I was making a fraudulent transaction, usually either when I made a card-not-present purchase over the phone, or when I was away from home and therefore not within my normal pattern of transactions and locations.
The bank's automated systems do phone me to tell me that they have detected fr
Re: (Score:2)
PGP at least has a mechanism for webs of trust, so if two or three of your trusted friends trusted bankofamerica.com you would be able to trust it yourself, and if you wanted to verify it yourself you could go to a branch and witness the fingerprint, hopefully posted somewhere in plain sight but where it can't be easily tampered with, like behind the teller glass.
For most people the trust of three friends, or the trust gained by obtaining a fingerprint at the brick-and-mortar branch would be more than suff
Re: (Score:3)
And how is this web of trust better than a distributed verification system like Perspectives / Convergence? I think asking Average Joe users to attend key signing parties is a bit much
Re: (Score:2)
Did someone say a key party? I'm there, as long as there are hot chicks too!
Re: (Score:3)
Hot chicks? Oh yeah you bet!...most likely...probably...
Anyways, here's a pic of some of the hot action you might get to be a part of!
http://en.wikipedia.org/wiki/File:FOSDEM_2008_Key_signing_party.jpg [wikipedia.org]
Re: (Score:3)
Why, oh why, do "FOSSies" constantly suggest unworkable solutions that simply would not work for the vast majority of people on the internet? "Web of trust"? Really? Unless you plug that into some kind of by extension untrusted system (like Facebook, MSN, or something of the like) then noone except the "nerds" will bother to set up that web - resulting in the same security we have now. "Verify fingerprints at the branch"? Noone (not even most nerds) will bother with that - the very thought of expecting
Re: (Score:2)
I'm not saying that people would actually verify fingerprints, but it's s solution of a sort, and really the only kind that is resilient to CA malfeasance. You're never going to be able to create a system where a user needs to know NOTHING about his chain of trust AND is immune to authority corruption. If people learned to remember people's phone numbers, something that must have seemed daunting and ridiculous to a telephone engineer in 1890, verifying a PGP fingerprint is on the same level of complexity.
Re: (Score:2)
Haha. Yes, people would need to actually verify fingerprints, that's what the heck they are for. Just as you would verify the ID of someone you're doing significant amount of business with. It needs to become a part of culture, something that everyone learns about in grade school, and only then will it be taken for granted.
Re: (Score:2)
I'm afraid the solution to this problem will be only reached when we enter a true information age. That must mean that kids in grade school will learn what the web of trust is and how to apply it, just as they learn how to fill out a check, calculate a tip, or write a formal letter. Our system of education has pretended the last two decades didn't happen. As an experiment, I've explained the basic concepts of encryption and how it relates with trust and MITM attacks to my 7 year old, and she understood it a
Re: (Score:2)
Re: (Score:2)
This. We need to get distributed verification systems into all the mainstream browsers. Once the popular free browsers have it the commercial browsers will follow suit so they don't lag too far behind. Then we can transition from CA certs to self-signed certs. The CAs only had their good industry record to stand on and now that's gone, there's no possible reason to stay with them.
Sound crazy? HTTPS as we know it today started as a feature some dude tossed into Netscape Navigator.
Re: (Score:2)
Missing virusscanners on servers, easy passwords, unpatched software. There's no way in hell I'd let such negligence take place in a company responsible for such an important piece of security.
Why hasn't the CSO been frothing at his mouth with anger at this?