SoylentNews is people
SoylentNews
Last week Bruce Schneier published An Untrustworthy TLS Certificate in Browsers and now Ian Carroll has published Security concerns with the e-Tugra certificate authority.
Ian is best known for the death of the EV (Extended Validation) certificates. He legally registered a colliding entity name and then got an EV certificate for his site stripe.ian.sh. As this site is not online any more, a good write up of this is Extended Validation Certificates are (Really, Really) Dead by Troy Hunt.
Troy Hunt is also known for his website ';--have i been pwned?.
Schneier suggests that it might be time to disable / remove trust for the following Certificate Authorities (CAs):
- TrustCor
- E-Tugra
Cory Doctorow gives a very good explanation the the problem in general and its causes here. Basically, we are just too trusting and we believe that others are looking after our interests. It appears that they are not.
(Score: 4, Interesting) by pTamok on Monday November 21 2022, @05:48PM (8 children)
There was a wonderful Firefox add-on called 'Perspectives' that checked the CA for each https connection and compared the information with a set of 'notaries' spread around the Internet that would (a) confirm whether they saw the same certificate as you for the site and (b) kept a history of CA changes and warned you if the certificate had changed recently.
Unfortunately, it died the death. I'm giving a url into the Internet Archive for more info because the domain has been taken over. - http://web.archive.org/web/20130914122435/http://perspectives-project.org/ [archive.org]
It really could do with being revived.
(Score: 0) by Anonymous Coward on Monday November 21 2022, @06:09PM (7 children)
Bank changed cert before its due? Warn me - and provide info (old certs, CA etc vs new one).
(Score: 3, Troll) by janrinok on Monday November 21 2022, @06:22PM (3 children)
Read the Cory Doctorow link provided. How can you trust the plug-in? When the CA themselves are corrupted (as the two that are mentioned are) then the whole system falls down.
(Score: 2, Interesting) by Anonymous Coward on Monday November 21 2022, @06:46PM (2 children)
People like you can go build your own computer, write your own compiler, OS, browser from scratch.
In practice I'll have to trust something/someone at some point, trusting an extension which I can see the source code of is still better than trusting CAs just because Google/Microsoft says they're OK.
Your claim is false. Don't forget ssh works fine even without CAs.
If my bank's server certificate has not changed, even if the CA that signed the cert has signed new certs that pretend to be that bank, it's not a big problem to me as long as the browser would warn me if the bank's cert has changed and the bank's cert has NOT changed.
The whole system falls down only because the browser doesn't warn you of potentially important stuff that it can and should warn you about.
By the way, browsers should accept self signed certificates too and in the way the SSH does - e.g. after you say it's OK it should stop bothering you about it BUT warn you if one day it changes. Then that way self-signed certs could be more secure than the current handling of CA signed certs.
(Score: 3, Troll) by janrinok on Monday November 21 2022, @07:02PM (1 child)
I thought so - you haven't read it.
(Score: 0) by Anonymous Coward on Monday November 21 2022, @07:19PM
There's no need to. It's a rehash of old stuff long known (e.g. Reflections on Trusting Trust).
I'm not aiming for perfect security, just better security. It's all a matter of managing risks and probabilities. Whatever I do I'd have to trust the browser and bank anyway if I want to do online banking.
BUT if the browser makers do stuff right, while I still have to trust the browser and bank I don't have to trust that ALL the CAs have got their act together whenever I do online banking.
The current system is it just takes one CA out of very many to do the wrong thing, but the browser won't warn you when that happens.
(Score: -1, Troll) by Anonymous Coward on Monday November 21 2022, @06:33PM (2 children)
The problem I see with this approach is that there is no obvious useful action that a web user can take in response to such a warning.
Pretty much the only options a user has if they see this with a web site are
(a) ignore the warning and continue anyway, or
(b) try again another day, hoping the problem goes away on its own, or
(c) stop using the web site indefinitely.
SSH users can typically be expected to have another communication channel to find out the actual current host keys of the remote system (although in my experience nobody checks host keys anyway). This is simply not the case with web sites.
(Score: 1, Insightful) by Anonymous Coward on Monday November 21 2022, @07:03PM (1 child)
Huh, what are you smoking? If the site is your bank, the useful action is to NOT log in and do your banking.
If you're not sure if you can trust the cert you should NOT be using the site till you can confirm you can trust the cert. You can get your bank to confirm it for you.
This applies whether or not you have this warning feature or not. The warning feature just makes it easier for you to notice potential dangers that you might not have noticed before. Without the feature the dangers don't vanish by themselves, they are still there.
Your objections are as inane/stupid as objecting to a "bridge has changed unexpectedly" warning feature because there's no obvious useful action that a bridge user can take and the only options are:
(a) ignore the warning and continue anyway, or
(b) try again another day, hoping the problem goes away on its own, or
(c) stop using the bridge indefinitely.
(Score: -1, Troll) by Anonymous Coward on Monday November 21 2022, @08:57PM
Can you?
You phone up your bank and ask them for the fingerprints of their current web certificates, and they give you usable information in a timely manner? Have you actually tried doing this? What about other websites? Do you just email the administrative contact in WHOIS? Does this give you useful responses often?
The problem is that a warning like this, virtually every single time, will be a false positive. Clicking through the warning is therefore a sensible action. Users will simply be conditioned to ignore the warnings as there will be no way of distinguishing a real attack from yet another pointless warning.
This is a straw man. There are many effective actions you can take when a bridge is out, such as taking a different bridge, or using a different method to cross. Nothing like this is possible with websites that have certificate errors.