Comodo Hack May Reshape Browser Security 144
suraj.sun writes "Major browser makers are beginning to revisit how they handle Web authentication after last month's breach that allowed a hacker to impersonate sites including Google, Yahoo, and Skype. Currently, everyone from the Tunisian government to a wireless carrier in the United Arab Emirates that implanted spyware on customers' BlackBerry devices and scores of German colleges are trusted to issue digital certificates for the largest and most popular sites on the Internet."
Implement DNSSEC and DNS based SSL keys (Score:4, Interesting)
With DNSSEC and DNS based SSL keys, only the single trust chain from the root to the domain can sign the keys.
Re: (Score:2)
I totally agree we should add that, there is just one problem.
The root, .net and .com and so on are controlled by the US-government-agency.
So you replace many CA's by one 'CA' which might have different 'priorities' than you.
Re: (Score:2, Funny)
I have a better idea, let's turn anything into a political discussion for no reason!
Re: (Score:2)
It is a political discussion when you ask who to trust and who not.
Re: (Score:2)
That sounds like something a pinko commie would say. Why do you hate America?
Re: (Score:1)
If your DNS is compromised, there are any number of certificate authorities out there who will happilly issue you a domain control validated certificate.
Therefore, using DNSSEC to distribute DNS based SSL keys does not reduce security compared to the existing situation anyway. If your DNS is owned, a forged certificate can be issued either way even through CAs that do their job (which is basically just checking that you're actually in control of the DNS name in question).
Using DNSSEC to distribute DNS based
Re: (Score:2)
It's not a protection racket. The CAs aren't typically promising that a site is going to be on the up and up, all their promising is that the site is who it says it is. Meaning that they might very well be using your log in information for data mining and whatever illegal activities, but that there isn't a MITM or counterfeit site involved.
You can self sign, but the point of paying is that they're supposed to be doing at least some checking to make sure you are who you claim to be.
Re: (Score:2)
Unfortunately, letting people decide whom they do and do not trust is also a non-starter. Or it's a good, optional measure, but it cannot be a default step.
Unfortunately, this is the ONLY possible option in the end. Everything else is a stopgap attempt at "solving" the problem that people can't/won't/aren't aware of the need to do this effectively.
In reality verisign and thawte issued all certificates I care about. Why I'd need any others, I do not know, but still there are scores of CA's in my browsers.
You really think that they can't unknowingly issue fraudulent certs? What rock have you been living under?
Educate people. Give them the tools they need to use systems intelligently - make it as easy as humanly possible. But at some point, you need to take the training wheels off.
The rest of your comments are
Re: (Score:2)
Why would the US government bother creating a fake version of a website, issuing a fake certificate to make that website look real, then get you to try and log in so that they can get your login details when they can simply issue a subpoena and force the website to hand over all information about you including the information you can't even access?
I suspect you have no idea what a security certificate is and this is just a knee-jerk "OMG GUBMINT BAD" reaction on your part.
Re: (Score:2)
Probably only in the sense that different agencies have different methods some of which seem silly, but then that's why we make fun of the "cone of silence" in "Get Smart", which by the way turns out to be real! http://en.wikipedia.org/wiki/Cone_of_Silence [wikipedia.org] .
The Gummermint does lots of really stupid things, many of which fit the definition of evil, and for the most part nobody (the public) ever hears abut them.
Good (Score:2)
Changes need to be made when an issue is found, in anything for that matter. Not doing so is about as useful as trying to solve the problem by sticking you fingers in your ears and yelling, "LA LA LA LA"
Re:Good (Score:4, Interesting)
In the meantime, I'm using a plugin tha shows the AS of the network I'm connecting to. It certainly doesn't solve the problem, but for right now I can differentiate between a site in the US and a site in Iran that may be claiming to be the same machine. It's pretty weak, as AS numbers aren't enforceable, but unless someone sets up scam sites on different autonomous networks and ensures said networks match the US versions, it provides some basic protection. (Besides, 99.9% of the planet wouldn't know what an autonomous system number was and wouldn't care if they did, and any fake site will be set up for the greatest number of victims rather than the best camoflage.)
Re: (Score:2)
Care to share (for those of us too lazy to search)?
Re: (Score:2)
https://addons.mozilla.org/en-US/firefox/search/?q=asnumber [mozilla.org]
Re: (Score:3)
Links to other software dealing with the Internet Routing Registry system (some are also given elsewhere):
IRR Toolset: http://www.isc.org/software/irrtoolset [isc.org]
IRRd: http://www.irrd.net/ [irrd.net]
Routing Registry Consistency Check (a web form, not the source code - pity): http://www.ripe.net/data-tools/projects/current/rrcc [ripe.net]
If you want to use this system to construct your own WHOIS database, please see:
ftp://ftp.ripe.net/ripe/dbase/software/ [ripe.net]
(This is the WHOIS server used by RIPE.)
Re: (Score:2)
I'm using a plugin tha shows the AS of the network I'm connecting to
And how exactly would this plugin work?
Is this information even being communicated to leaf nodes? Or do you make it a habit to only surf the web from your BGP router's console? (... and even then, I'm sure a man in the middle could spoof it trivially...)
Re: (Score:2)
The information is indeed communicated to leaf nodes.
http://www.isc.org/software/irrtoolset [isc.org]
The Internet Routing Registry Toolset will give you most of the answers you want and the tools to verify the answers the plugin gives.
If you're interested in knowing what it would take to spoof, the obvious place to start would be the Internet Routing Registry daemon. Though you could also look up RFC 2622 as RPSL seems to be the standard protocol.
http://www.irrd.net/ [irrd.net]
Re: (Score:2)
The information is indeed communicated to leaf nodes.
Are you sure about this?
Maybe you think you can also see your peer's MAC address? (which you don't, unless you are on a same local network)
Re: (Score:2)
And since you didn't bother to check the links or use the software, 5 demerits. Any more and you'll go on report.
Re: (Score:2)
And since you didn't bother to check the links or use the software, 5 demerits.
Thanks, I've got better things to do than run random trojans on my PC. O, and for the links: please check out this link [apnic.net] which seems to disagree with the feasibility of your "tool".
Re: (Score:2)
Are you honestly and earnestly saying that ISC and RIPE are run by black-hats for the express purpose of putting trojans onto your machine?
I have heard some insane shit in my life but that has to be about on-par with the "Moon Landing Hoax" conspiracy theory. I really, really suggest cutting back on the illegal substances.
Oh, and if you're using Linux, too late. You already use ISC software. Clearly you must already be trojaned. Or maybe just the most insane fruitcake I've encountered in a while.
Re: (Score:2)
Re: (Score:2)
I specified when it was used, did I not? Then perhaps I was giving you credit for figuring out that if you use a different method (DHCPv6, for example, or static addressing) that it was NOT automatically used. I'm wondering if I'm giving you too much credit here, if you're willing to go to such lengths to find some, any, loophole in what I'm saying even if it's in a totally different subject than the one I'm discussing.
You can change the MAC address on the card, too. So? You said that it couldn't be accesse
Maybe the browsers should hardcode the major certs (Score:3)
Instead of trusting information from certificate authorities, the browsers should have the public key for the major size burned in and security hashed inside the browser itself. That way it can trust it is downloading a real update of itself from its real home. If you have already downloaded a hacked browser, then you are dead anyway. So along with a browser you should get burned in security for the major vendors. Security that does not rely on anyone that can lie to you.
Re: (Score:3)
Hardcoding anything is a bad idea because it makes it impossible to revoke the certificate in the event it is compromised.
Re: (Score:2, Insightful)
"Impossible"? Hardly. He probably means "hardcoded" as in "embedded in the browser's files", not as "embedded in the code". The browser could still have a UI to manage those certificates. And even if there's no UI, it would be possible to revoke the certificate by upgrading the browser.
Thank you (Score:2)
That is what I meant. I should have been more clear.
Not good enough (Score:2)
That is not good enough, because that is basically what we have today and was proven so insecure in this last attack.
It is simply unacceptable that I have to wait days or even hours for a browser patch to come out when an top-level SSL cert is compromised. Such a compromise should be able to IMMEDIATELY trigger a revocation that takes effect globally.
This is the exact problem that CRLs were supposed to prevent. But they are not implemented very well at all, and nearly always disabled by default in web brows
Re: (Score:2)
I highly recommend the Perspectives [networknotary.org] Firefox extension. It basically compares the cert you are handed to the one everyone else received (including in the past), which would have detected the fraudulent Comodo certs.
Re: (Score:2)
CRLs are hopeless because they:
OCSP (ideally over HTTPS) solves these problems, and is thus a much better solution than CRLs. Really, we should just abandon CRLs entirely and mandate OCSP.
That said, there is an enhancement th
Re: (Score:2)
"Impossible"? Hardly. He probably means "hardcoded" as in "embedded in the browser's files", not as "embedded in the code". The browser could still have a UI to manage those certificates. And even if there's no UI, it would be possible to revoke the certificate by upgrading the browser.
You know that's ... um, no different that putting in the code, right? If you have to deploy a product to the user, putting it in the code is identical to putting it in a file that you distribute with the code.
Re: (Score:2)
That would also completely break legitimate MITM proxies and such on corporate networks. At least today you can install you private CA certificate and then everything will just work; of course then its up to the people running the proxy to for the organization to decide who to trust.
Re: (Score:2)
Re: (Score:2)
What I'd prefer to see are the following:
Re: (Score:2)
Re: (Score:2)
You are absolutely correct. It would not be hard to add a new record type.
A thought for you: http://www.isc.org/software/bind10 [isc.org]
ISC are wanting suggestions for what is needed in BIND10, the essentially de-facto DNS server. You might want to put your thoughts together as a single white paper on integrated security and send it to them. You aren't getting much mileage on Slashdot, but you might well provoke some excellent thinking by the people who actually develop DNSSEC and the servers that use it.
Perhaps we need to validate the CAs? (Score:3)
SSL is dependent on certificates, and the certificate process is deeply flawed. Microsoft in particular seems to be willing to recognize almost any CA, and yet I have trouble with well-recognized root certificates from Verisign working corrrectly with our software, using OpenSSL. Now we hear that most any CA can mint most any certificate.
Perhaps there needs to be a true 'root' CA, and at least some domains subscribed to prevent any other CA from delivering certs?
Gee, this would also be nice in DNS, where 'very well known' domains, such as Google, Microsoft, banks, etc could pay to be put on a 'do not change' list and get a more formalized process for management.
The reality is that we are well past the 'family business' mode the Internet and ICANN et al relied upon to keep things working.
Jon Postel must have shed a tear. There is still a need for collaboration, but it's time some of the Internet infrastructure grew up. Please fix this before the governments do. You won't like their solutions.
Re: (Score:3)
What we need is a way for people to get the keys straight from each other without having intermediate signing authorities, as much as possible. Example, your bank most likely has a secure, brick and mortar branch in your town or near you. So, you could simply go to the branch office and they give you the cert and you install it on your browser, problem solved. The issue is that this is beyond most people's abilities. However, I posit that if you use something like a QR code or multiple QR codes to hold
Re: (Score:2)
What we need is a way for people to get the keys straight from each other without having intermediate signing authorities, as much as possible. Example, your bank most likely has a secure, brick and mortar branch in your town or near you. So, you could simply go to the branch office and they give you the cert and you install it on your browser, problem solved. The issue is that this is beyond most people's abilities. However, I posit that if you use something like a QR code or multiple QR codes to hold the cert, then people just shoot it with their phone and when they get back they plug their phone into their computer and it updates the certs.
Because everyone only ever wants to talk securely to businesses that have bricks-and-mortar stores in their area, and Bad Guys can't produce QR codes.
Re: (Score:2)
They can simply hand out CDs with a two clicks installer which copies the CAs to each browser's authorized list. Seems easier than QRCodes for most people, in my opinion.
Re: (Score:2)
And where exactly do I insert the CD in my phone? Or in my battered old laptop, the CD drive on which died years ago?
Re: (Score:2)
Re: (Score:2)
Honestly you don't really need to exchange the entire certificate, Lets assume you have some way of being sure you are talking to correct party out of band, such as on the phone. They could read you just the thumb print of the certificate. You then compare the thumb print and validate the other information on the certificate. Your system checks it matches a CA you trust. If all those things are true you are pretty safe.
In the Comodo case you would be safe because the thumb pints of the fraudule
Re: (Score:2)
I just closed an account late last year with a bank I had done business with for 35 years, through mergers and acquisitions and all. They has no branch within 500 miles - I had moved away from them. How would you like to run over and pick up my cert for me?
A QR code would be fine, but how is it delivered? From their website? Which one? The fake one that presents me a cert from a CA in Uzbekistan? Beijing? Singapore? Do I trust the CA from East LA any more? Why?
For a decent attempt at multi-factor s
Re: (Score:2)
I suppose they could email it to you :)
In reality you just need to find a way that you trust the original delivery of the key, once you've done that all's good.
So, what would you trust to get the key from your bank?
Obviously going to the bank's HQ and getting your cert on a gold bar would be best. How else would you know that the bank can safely keep your cash? Or mabe the government coudl start printing QR codes on banknotes - you trust the note in your wallet to be tradeable for stuff after all.
Other than
Re: (Score:2)
Re: (Score:2)
Ok great so by doing that you create a huge advantage of incumbency. That would lead to a whole lot of I'm just going to buy it from Amazon because I already trust their certificate, or whatever method you select. That will pretty bar every small site from the retail e-commerce world unless they sell some niche product you can't get anywhere else.
Re:Perhaps we need to validate the CAs? (Score:4, Interesting)
Little anecdote, My university professor who was quite knowledgable in the area of of SSL and other related matters said that SSL addresses the wrong problem. The problem generally isn't somebody sniffing your credit card number as it travels over the ether, but rather that you shouldn't have to give your actual credit card number to the retailer in the first place. That way, I don't have to worry about how secure the retailer's operation is. It should work kind of like OpenID, where I log into "VISA" for instance, and authorize a one time payment from my account to the retailer. The retailer doesn't get any of my credit card information, but instead gets a certificate with an authorization number signed by my credit card company that the payment was valid. Paypal pretty much solves this problem, but it is still a third party. The credit card companies should maintain this system on their own, so that no third party has access to this information.
Re: (Score:2)
I hope someone mods you up. SSL is trying to solve a bigger problem then just CC processing and e-commerce, but that is a really good idea as far handling CC security online. I hope others see it.
Re: (Score:1)
I don't think it is particularly likely that your true CA would be any more reliable than Microsoft or Mozilla or whatever.
I guess someone could do it and say "Hey, my certificates is better!", but I'm not sure there is any way to actually compel anyone to listen to them, and the current system where the browser vendors compile authority certificates has an awful lot of momentum.
Re: (Score:2)
When did my browser become my CA?
Re: (Score:2)
It works for DNS.
Re: (Score:2)
I wonder... once DNSSEC is widely deployed, can we put SSL cert information in DNS records? Maybe a specific TXT extension or a new record type. It would give the browser a way to automatically verify that the certificate was not only issued by a valid CA but the hash also matches what the site owner says it should be. At least then you'd need a fraudulent cert and control over the target's DNS nameservers. I suspect DNSSEC isn't required to cover a lot of these hacks because getting control of the nameserv
Re: (Score:2)
once DNSSEC is widely deployed, can we put SSL cert information in DNS records
Why bother with SSL? With DNSSEC you can put an IPSec public key in the DNS (standard already exists) and then you can create a secure connection at the IP level, so any communication with at IP (TCP, SCTP, or UDP) will work.
Re: (Score:2)
Re: (Score:2)
Dosn't help too much when the vast majority of TLDs are effectivly DOT misc. (Even before considering "
Why Microsoft? (Score:2)
I RTFA, but I don't get why this is marked as Microsoft. There's the odd quote in there from them, but shouldn't this be marked as Security or Internet? Or am I missing something?
Re: (Score:1)
Sooner or later everyone around here will blame Microsoft and proclaim Linux superior, despite neither having anything to do with this, and both being vulnerable in the same way.
Re: (Score:2)
I think the original exploits were due to the systems running Windows.
IANAH (I'm not a hacker) (Score:2)
and I don't particularly like them when they make the 'geek' community look bad - because it's only the bad stuff that tends to make the news - but if a result of this hack is that people (the big companies, the governments, the FOSS people with the good ideas) finally get together and work on a safe, secure and sensible way of carrying out net authentication that DOESN'T rely on me handing over my security credentials to someone else to manage, then it is a good thing in my eyes.
Re: (Score:2)
When have you had to hand out your security credentials for someone else to manage? What kind of bankrupt banana republic security infrastructure requires that?
Monkeysphere (Score:2)
Does anyone believe the Monkeysphere project which aims to bring a Web Of Trust model to this problem is a potential –though long-winded– solution ?
With all the talk on the subject lately, I'm surprised not to see Monkeysphere mentioned more often...
How about a "degree of trust?" (Score:3, Interesting)
Re: (Score:2)
its a workable idea to have a requirement of having more than one CA recognize it - BUT in the end it has to be binary in nature to the user - when you start bringing a "degree of trust" to the end user - you are having to rely on the judgement of the end user which or all cases is basically random. If it is good/bad then the odds tip that people will choose good - but if you give them more options it will not help them.
Re: (Score:2)
On the other hand it might make more sense to give more weight to the city of Seattle, Washington, USA. Especially compared with a company in South Africa, a company in Dulles, Virginia, USA and a company in New Jersey, USA.
The expense to smaller businesses might be a problem, though.
If you go by by the r
Re: (Score:2)
ooh - taxman issued certs. There's nothing in the world that's not going to be given the same level of scrutiny as those guys.
The expense might not be a problem, once you've submitted your tax return, the taxman sends you a cert in return along with your bill. They could generate them easily enough, and deliver them as QR codes or on cd for extra cost.
Re: (Score:2)
So what would display to the user? "Warning: This site has a certificate which is mostly trustworthy, but we're not 100% sure"?
People are already blind to the warnings about bad certs, and are confused enough about what those warnings are about in the first place (seriously, try to get a layperson to explain what they mean or where they come from, and I doubt you'll find a correct answer from any of them). While I do like the idea you have, I just don't see how it would work in practice since it would merel
Don't trust CAs at all (Score:2)
Re: (Score:3)
I do the same. I haven't asked my bank to provide me with their fingerprint, but I did check it on multiple machine using multiple connections (laptop at home, phone at public wifi, desktop at university).
For most sites, the first access is irrelevant - I haven't registered, so I don't have anything to protect. I just care to ensure that subsequent accesses are made to the same machines, and not trusting CAs is actually better for that purpose.
Re: (Score:2)
This is the model used by SSH.
A vulnerability in the way web browsers tend to do things is that they tend to be silent if things change.. The typical logic is accept anything signed by a trusted CA make a big fuss if it isn't.
Re: (Score:2)
I highly recommend the Perspectives Firefox extension. [networknotary.org] It basically compares the cert you are handed to the one everyone else received (including in the past), which would have detected the fraudulent Comodo certs. Much easier than running around to multiple connections.
Re: (Score:2)
Wouldn't I be replacing the trust in some CAs with trust in some random guys' "network notary server"?
Checking the certs manually isn't that cumbersome; I only care to check a few of them (banks, IRS and a couple more) and I use those connection regularly anyway. :|
I could do like the guy in the article and call them to get the fingerprint, but I fear asking such technical questions, the heads of the support people might explode
Re: (Score:2)
One of the first things on that page is a link to the source code [github.com] for the server.
Do Extended Validation Certificates solve this? (Score:2)
Re: (Score:2)
Isn't this exactly what Extended Validation Certificates [wikipedia.org] are supposed to resolve? Only certain validated certificate authorities are allowed to issue them.
The problem is that any of the CAs that can issue EV certs can issue EV certs to any entity, and they will all be "trusted" by browsers.
Yes, they're supposed to only issue to entities that they've validated, but that doesn't help if one gets compromised and starts issuing technically-valid EV certs to unauthorized parties.
PGP certs (Score:2)
The irony is that browsers like Firefox & Chrome make a big son
Re: (Score:2)
http://www.networknotary.org/ [networknotary.org]
Perspectives is a wonderful little Firefox extension (with Chome beta) that does exactly as you suggest - uses a web of trust to automatically bypass errors for self-signed certificates, while also detecting stuff like these fraudulent Comodo certs.
Re: (Score:2)
Re: (Score:2)
How can you have a "web of trust" when there are known to be bad actors using the system? All such a web needs is a single person abusing the system and it completely breaks down.
Of course, the CAs aren't doing their job which is what they are being paid to do. That problem is somewhat simpler to solve - Microsoft, who is likely the biggest stick in the game, simply revokes CA authorization for any CA that isn't in fact doing their job of validation. You can't tell me that Firefox or Chrome are going to
Re: (Score:2)
How can you have a "web of trust" when there are known to be bad actors using the system? All such a web needs is a single person abusing the system and it completely breaks down.
Of course, the CAs aren't doing their job which is what they are being paid to do. That problem is somewhat simpler to solve - Microsoft, who is likely the biggest stick in the game, simply revokes CA authorization for any CA that isn't in fact doing their job of validation. You can't tell me that Firefox or Chrome are going to trust a CA that Microsoft has revoked.
It doesn't break down any more than CAs - anyone can buy a cert with a stolen credit card, or stolen / fake ID. So how is it any worse to just generate certs that rely on a web of trust? I'm also not proposing that it may be suitable in every case. Individuals and small businesses would benefit most. Banks and major sites might find value in the cert because they pay a shitload of money to Verisign to actually audit them... well that's the assumption Comodo's fuckup notwithstanding.
As for key / signature
Re: (Score:2)
Irony? You do realize that Firefox doesn't want to use patented codecs due to their inability to afford to license the patents (and not even considering the implications such a license would have on the open source license of Firefox itself) and that this is an issue complete unrelated to the CA model?
Firefox never had to licence h264 in the first place. Every desktop OS has a perfectly functional media framework to play content with.
As for why I mentioned it, it is because Firefox took a stand against h264 seemingly because it wasn't free and open yet here is a certification system which is anything but free and open too. It costs money / needless hassle to secure websites, even personal communication and there is no need for it to. And while the cost and hassle remain people won't bother using it to
Re: (Score:2)
>As for DNS names being sold - it doesn't make the slightest difference. People buy the domain name not the the private SSL cert which still resides with the original site operator. Which is the problem, now the old owner can use the cert to pretend that he owns the domain in a MITM, with 1-2 years expiry in the certs this attack can be contained
That Firefox supports a certificate system that was in wide usage before Firefox existed should not come as a shocker. Atleast with the video-tag there is no legacy system so that fight can be won (and don't forget that SSL was invented by Firefoxs ancestor, Netscape).
So you're saying that in the unlikely event that I purchase a website from a precog, who buys an SSL cert to attack the site owner coming after, that they'd only be able to perform a man in the middle attack on them for a mere 2 years? Seems like you are imposing a massive amount of hassle and financial burden on every cert owner for an unlikely event where the attacker can still do a huge amount of damage. And furthermore if it *did* happen, there is a perfectly functional revocation mechanism that could
SSL is somewhat of a joke anyway (Score:2)
OK, so we have the geeks looking for the padlock, checking the certificate fields out and so on and so forth.
Except most of the public isn't doing that. I ran across a pharmacy site that says in clear text that "256-bit encryption is use" but there is no padlock and the URL says http [slashdot.org]:. This is on a shopping cart page that is prompting for a credit card number! They have all the right Verisign seals that link to nice pages that say their site is secure. But there is no security. No SSL. Nothing.
Of cour
Better SSL Protection TODAY (Score:2)
You can increase your SSL security today by using Perspectives [networknotary.org].
It tells you if others are seeing the same cert you're getting from a website. So it protects against MITM attacks.
Seriously? (Score:2)
A) They know what they're looking at.
B) They know what they're looking for.
This is a big problem that nobody's recommendation here has seemed to have overcome. You all just assume that they can talk to the bank and know exactly what they're looking for. Like any of you validate your RDP certificates (Windows) or ssh public keys (*nix) when you connect for the first time, seriously? If you do th
Compartmentalizing... (Score:2)
I realize that this is a really low-tech fix, and it doesn't go far enough to really solve the problem completely. I also realize that there's a lot of political hand-wringing
Re: (Score:3)
It was trusted enough when there were about 10 companies that could do the signing. After that, more and more CA's turned up, including governmental CA's. These CA's quickly found out that it is a serious pain in the butt to distribute and install the root certificate to/on the clients computing device. So they went to the major browser vendors and asked to be included.
There have already been interesting goof ups regarding security. Microsoft has had problems for certain, accepting end-entity certs as CA ce
Re: (Score:2)
Ask the user if he wants to trust other installed certificates.
There's no point in asking a user a security question they don't understand, especially if it has long-lasting subtle consequences. They'll just say "yes" or "no" at random. We saw that with screensaver trojans. We'll see it again here. Any widespread mechanism must not require lots of fiddling around by users; it's got to be as permissive as possible while still being reasonably safe.
Re: (Score:2)
Ask the user if he wants to trust other installed certificates.
There's no point in asking a user a security question they don't understand, especially if it has long-lasting subtle consequences. They'll just say "yes" or "no" at random. We saw that with screensaver trojans. We'll see it again here. Any widespread mechanism must not require lots of fiddling around by users; it's got to be as permissive as possible while still being reasonably safe.
The only way to code a technically perfect solution that obviates the need for a brain is to also code the technically perfect user. That said, asking the user that particular question is a bad plan as you said - it's meaningless to the user. Especially if they accidentally click "no" and then don't understand why nothing works.
Our current approach of trying to solve it technologically (via CAs, anti-malware when we're speaking more generally, and other tools) is in large part WHY most users are so un
Re: (Score:2)
Re: (Score:2)
I largely agree with you there, this would indeed only benefit the people that know PKI (and there aren't that many of them, as I can attest after debugging an interface to a certificate authority service for a couple of days). People should, if possible, only see any feedback if something is really good (green highly trusted cert), or really wrong (spoofed or broken server certificate).
Re: (Score:2)
A really big failing is that CA's lack any sense of scope. A governmental CA is probably actually the best entity of verify a business within it's jurisdiction. But can't do so for anywhere else in the world. Thus you really don't want New York City trying to tell you anything about companies outside that city.
Nor does it make sense for commercial CA's t
Re: (Score:2)
That is something I want too.
Restrict a CA to a domain-list.
Possible have an option for: ask to add domain to list.
But it only works for technical users. No noob will understand this, so it isn't a real solution.
Re: (Score:2)
Re: (Score:2)
It all comes down to who watches the watchmen.
I don't even trust myself, so how am I going to trust a CA?
Re: (Score:3)
Re: (Score:2)
You can already create certificates using OpenSSL. And most new browsers (FF4, Chrome) don't pop up giant alarm screens anymore.
But CA certs are cheap enough, you can get on for $9/year. I even got min free with a .com domain.
That simply does not solve any problem; the main problem is with authentication.
Re: (Score:2)
Re: (Score:2)
This just isn't true.
An unencrypted connection can be attacked at any point in time. A encrypted but unauthenticated connection can only be attacked while it is being set up.
And it isn't even possible for an attacker to tell when it is transparent to attack the key exchange and when the browser actually has the certificate or a plugin to warn that the certificate has changed.
Encrypted connections prevent passive eavesdroppers and force attackers to use active attacks which are detectable if you care enough
Re: (Score:2)
You mean like http://www.startssl.com/ [startssl.com] already does this ? For free for the current CA-system.