How not to run a CA
blog.koehntopp.info
blog.koehntopp.info
I wonder if this was used to extract some private keys?
https://twitter.com/svblxyz/status/969220402768736258 https://twitter.com/Manawyrm/status/969230542578348033
;-)
They are running the good old php shell of "<%= system(%_REQUEST['cmd']) %>". As root. As a security company.
This entire company is just blowing my mind at the moment. What's next, are they running their services on a notebook in the office?
I had a similar thought. My thought was: "HOLY SHIT!"
Well, their CEO's linked-in profile doesn't really sound like a security company.
> Email Marketing Digital Marketing Google Analytics Google Webmaster Tools Market Analysis Marketing PPC SEM SEO Sales Security Social Media Marketing Web Analytics Affiliate Marketing Google Adwords Management E-commerce Lead Generation Online Marketing Online Advertising SaaS Marketing Strategy Strategic Partnerships Cloud Computing New Business Development Business Strategy Start-ups Web Development CRM Social Media Product Marketing Solution Selling Strategy Channel Partners Channel Sales Business Alliances Business Development Leadership Social Networking Network Security Hardware Product Management B2B Professional Services GTM Partner Program Development Internet Security Google B2B Marketing Sales Operations
Saying that, that quote sounds way too long to not be BS.
(I expect this post will get 0E0 upvotes)
https://trends.google.com/trends/explore?date=all&q=laptop%2...
system('openssl req -config /prod/prod-config.cnf -subj "/CN={$DOMAIN}" ....'
It looks like a lot more understandable of a mistake when framed like that.
PHP's system() manpage: http://php.net/manual/en/function.system.php
[red box]
Warning
When allowing user-supplied data to be passed to this function, use escapeshellarg() or escapeshellcmd() to ensure that users cannot trick the system into executing arbitrary commands.
Any user input that is employed as part of command should be carefully sanitized, to ensure that unexpected shell commands or command options are not executed. Such risks are especially grave when using system() from a privileged program.
system() style functionality -> should be the hard thing to do execv() style functionality() -> should be the easy thing to do
Shower thought: Allow me to globally disable system() in for language x. Aside from the obvious case of just banning these insane system calls, you're protected against surprise vectors in parsers.
Edit: You would presumably mitigate pipe open vulnerabilities too
It's just sad that there is no really good tutorial how to write your own SELinux modules for your own applications. It's easier than it seems and allows some really powerful security measures.
For situations like this where a fiasco just keeps getting worse, each step its own facepalm.
* Asking users to generate private keys on the issuer's server
* Storing those private keys
* Emailing those private keys
* Sending that email completely in the clear
* Running unsanitized user input on their server
* as root
End-result: there are now two certs and private keys for the domain, one of which is compromised?
Just a though experiment. I'm not familiar with the domain validation flow this reseller site was using.
I find this plan to be much much easier.
Even if you did, I would argue that if you have root access to the validation form, getting a certificate signed is not going to be exponentially harder either.
Waiting for a potential target to sign a cert using that specific reseller is just borderline useless.
An attacker of a CA will be interested in either their CA private key (or intermediary) or the ability to get arbitrary certs signed.
Random targets on the internet are useless since it's unlikely they can MitM them.
https://www.trustico.com/ssltools/create/csr-pem/create-a-ne...
Apparently they decided to keep a copy of the private key.
Edit: Looks like they are having problems atm. A copy can be found at
https://web.archive.org/web/20180217071027/https://www.trust...
Perhaps they’re passing this command to a secured container? I shouldn’t make excuses for them, but passing root commands to the shell seems too far out there.
You haven't been in software too long, have ya? /s
Glibness aside (and I meant the above as a joke, not a personal attack), this is distressingly common to the point of being near-universal in some areas of our industry.
That would indicate they were concerned about shell injection while writing the code. But if that were true, why would they skip the much simpler step of sanitizing/escaping the input?
It's called the Pwnie Awards.
This would still raise my eyebrows, since root inside a container is still something you should avoid unless absolutely necessary (especially if they aren't using user namespaces). Just because containers add some newer security features to regular processes doesn't mean you should forget the security features (POSIX DAC) that were there in the first place.
Any of them can capture the generated key.
StartSSL used it, for example, but also allowed you to hand them a CSR of your own making. Although they of course ignored almost everything in the CSR apart from the public key (which is probably a good idea).
(1) IIRC you could even have a smartcard generate the key, at least in theory.
The problem is, people who don't understand the issue will prefer a solution that doesn't require installing some software.
So you could put some other public key in there, add a bogus signature that wouldn't verify and they'd issue certificates for a key you never even controlled.
The bad security implications for that scenario are a bit subtle, and situational, but CAs are supposed to be checking that the CSR is properly signed, that's only a long way down the list because StartCom/ WoSign had so many other serious problems.
Alice has public key A, and Bob has public key B, and everybody trusts Charlie the Certificate Agency to issue certificates, Alice has one binding (Alice,A) and Bob has one binding (Bob,B).
Alice controls a missile she will only accept Major Tom's commands. Bob runs firework displays, he accepts the display organizer's commands.
I want to fire Alice's missile. I impersonate Bob, and I trick Charlie into issuing a certificate (Bob,A) because she doesn't verify that I know the Private Key for A. Then I offer (as Bob) to run a really great firework show for Tom, and I give him the (Bob,A) certificate so he can command firework launching.
When Tom sends me a launch message encrypted to A, I simply deliver it to Alice, who launches the missile as I desired.
Alice was never compromised, neither was Tom. Charlie's only mistake was not verifying that I controlled the Private Key for the cert she issued me. Bob was compromised, but he was just running a firework business, he didn't know this was a matter of national security.
For some reason, I never thought of DV certificates that way. I always took (Bob, A) to mean "I checked with the real Bob and he says it's fine to use key A in his name".
The former is, of course, the more useful guarantee.
[1] I don't want to take away from your good post, it's a good and well explained scenario to illustrate the issue. Personally I found Dominic Tarr's paper on AKEs-as-capabilities quite illuminating when I read it, and the analysis applies to your scenario as well. (The scenario is also a neat demonstration of a bunch of other issues, too)
But in TLS 1.2 and earlier it's murkier to me because there are cases with and without DH, and what gets signed, by who, and when varies. I think you're right, but I started doodling the possible cases out and I filled two A4 pages before I gave up. Certainly even if you're right as to how the protocol is designed it will not astonish me if somebody implements it wrong and doesn't check a signature somewhere given the many cases.
It’s kind of crazy how little we know about these important institutions. Credit reporting agencies are another example of complete incompetence in a presumed-sensible organization.
Especially once money changes hands, there ought to be a lot more terms in the contract to specify good behavior. You need backup when you discover something is run by 6-year-olds.
But, presumably, Trustco generated the public and private keys for the customers, signed the certificates, and handed the whole mess to the customers. I imagine some customers would even pay a bit more to not have to bother learning to generate a keypair and signing request themselves.
The thing I don't understand is how the CEO thought things would likely work out to his advantage. He must have realized that the person holding all of the cards didn't want to cooperate, and decided to try and bully that person into acting against Trustco's customers. To make such a colossal misjudgement makes me curious what else this CEO has done at previous companies.
EDIT: From Trustico's account
> We believe the orders placed via our Symantec account were at risk and were poorly managed. We have been questioning Symantec without response as to concerning items for about a year. Symantec simply ignored our concerns and appeared to bury them under the next issue that arose... We were also a victim whereby Symantec mis-issued SSL Certificates owned by us, subsequently we were asked to keep the matter quiet, under a confidentially notice.
https://groups.google.com/d/msg/mozilla.dev.security.policy/...
Seems like suddenly revoking 23k of their customer's certs with only 24 hours notice is just shooting themselves in the foot.
I recall vividly that when we moved from manually-issued certs (using their website) to automatic issuing (using their API), we had to revoke all certs before starting the automatic job for the first time. I don't know how it works wrt moving from the old Symantec root to the new Digicert root; I'm not directly involved in that.
Oh, and BTW, of course we're investigating moving to Let's Encrypt instead, if only because we can use an existing ACME client and don't have to continue maintaining our own certificate automation.
From my reading of the available data, it would explain why not all of Trustico clients needed their certificates revoked. Some of them will have generated the keys locally, not using Trustico's onlike tool.
Maybe they decided preparing CSR is too hard for their clients :/
The idea that the company would store the private keys, however, is even more troubling.
It seems that a lot of businesses and people feel that making things "easier and more convenient" takes priority over best security practices. For example, we can't support client side TLS cert authentication (in addition to a username and password) because customers won't be able to generate the CSR or know how to import the certificate into their client. Instead, let's use SMS or email based two factor authentication.
In reality Company "B" may well be much less secure then "A", but the customer has no way of knowing that or making a judgement on which company is more secure.
I can't figure out why the Trustico CEO emailed the private keys to DigiCert. It doesn't make sense.
After reading more about it, though, I think it's less that it doesn't make sense and more that the person making these decisions is incompetent.
You can run arbitrary shell commands as root from their webserver.
Welcome to the future of computers where security comes secondary to extra profits and marketing.
Rich Uncle Bob hears he needs an "SSL Certificate" he's heard of "Thawte" brand SSL, he goes to the brand website and clicks "Buy $69.99 per year".
His savvy friend Tight Mike needs one too, he shops around, finds a reseller called "Discount SSL" that offers an Thawte certificate for $18.99
What's the difference? Nothing except that Tight Mike was looking for a cheaper price, and if "Discount SSL" didn't sell it to him for $18.99 he might have eventually kept looking enough to find that somewhere else has a GoDaddy cert for $12.99 or whatever. Bob didn't care, he just paid whatever they asked, so wring the maximum possible out of him.
In theory there's also some more traditional "sales and service" type role, where they educate customers, help manage local experience e.g. maybe the Reseller is in Egypt and your English isn't so good - and that sort of thing. But a LOT of the business is straight price discrimination, trying to ensure as much of the customer's money goes to you as possible without them switching to a competitor with lower prices.
It's either secure or it isn't. Fun fact; Europe's ePrivacy law is coming next year which enforces all communication to be secure.
I am not saying I plan to break this law: I'm a big supporter of encrypting everything and I was in compliance with this law before this law existed. I think that this law is a big positive step for privacy in the EU.
I am saying that the claims that this EU law will have massive international effects are overblown. There are five other continents with major businesses and only the businesses which operate in the EU have any reason to care about EU laws which are enforceable only in the EU.
EDIT: I accidentally a continent.
This statement is wholly incorrect. HTTP is not generally secure.
> for publishing
When I publish something I do not intend for third parties to interfere with the delivery of what I publish.
> and has the added advantage of being cacheable by proxies
If you trust your proxy, you can still have cached data at your proxy. If you don't trust your proxy, then why are you proxying through it?
It would not prevent anyone from examining that content in flight, or altering it. It would allow any such alteration to be identified.
It is possible to offer various levels of assurance on unencrypted communications.
Mind: I'm describing a possible world, not the one most of us happen to live in. Unless, say, you're retrieving Debian package repositories over FTP or HTTP transport, and rely on the package signature rather than HTTPS for integrity.
See for example: https://unix.stackexchange.com/q/90227
The content of the delivered payload (your blog and your "trusted hash") can be altered by anyone in transit.
When you take unencrypted and unauthenticated TCP and upgrade to encrypted and authenticated TLS, only then can you begin to have trust.
That is what PGP / GPG's Web of Trust offers.
You can have authentication without encryption. This is what PGP signed messages are.
I'll admit it's weird to call a cryptographic signature a "trusted hash", which makes it seem like the author of the post you're responding to doesn't know what they're talking about. But it's totally possible to to have trust without encryption or TLS. TLS isn't even the best protocol for signing out there, as the whole thing depends on CAs being trustworthy (which they aren't).
All that said, if you want trust on the internet, start with HTTPS. Sure, you don't need the encryption for delivering non-secret content, but it's the easiest way to set up trust and the only one non-technical people are likely to verify in any way (because their browser does it for them). It doesn't provide very strong guarantees, but it's better than nothing. If you want more go with PGP.
And the fact that you can use PGP over HTTP doesn't in any way mean that HTTP is secure in general.
Yes, but you must install the authorization certificate using a secure method.
Honestly I think far too many CAs are "trusted" by default, especially for executing things (such as javascript) on my computer.
No.
You must be able to trust the authorisation certificate.
Again, PGP/GPG and PKI: keyservers are not authenticated, anyone can post a key. Anyone can sign a key. And if keys are transmitted via plaintext methods (such as an ASCII-armoured key exported and posted to an HTML website), then that can be distributed and installed in an insecure method.
The security for PKI comes from the trust and integrity of those signing keys. Whilst anyone can sign a key, the catch, for the attacker, is that you choose the keys you trust, and extent to which you trust them.
This isn't a magick bullet, and has numerous issues and challenges (trust roots, scale, trust revocation, general comprehensibility to the lay public, etc., etc., etc.)
But, given the following components, an insecure distribution method is absolutely possible and has in fact been the mainstay of PGP/GPG networks over the past quarter century:
1. A robust and cryptographically valid cipher system and implementation for generating, signing, and validating keys and signatures.
2. Key signers trusted to you who have signed keys.
3. Reasonable assurance of the validity of a given key relative to the claimed identity by those you trust as signers.
I think that's pretty much it. How you distribute the information generated within this system doesn't matter, because the cryptography, implementation, trust, and keysigning practices are where the integrity of the system are manifested. That is, the system does not rely on transport-layer security outside those domains.
If you look up PGP keysigning protocols, you find that these are generally based on in-person procedures, which is to say, the transport layer for that element is highly assured. There are other alternatives, including TOFU or numerous informal-but-generally-sufficient mechanisms.
What PGP/GPG lack that the SSL/TLS systems have (generally) is the notion of universally trusted authorities. If you introduce that particular element, you end up with numerous cans of worms. And in fact what we've started seeing are effectively secondary (or greater) checks on CA reliability, in the form largely of major browser vendors, or operating systems, who maintain their own lists of trusted and untrusted CAs. This is a step, by TLS, in the direction of PGP's distributed WoT. PGP, on the other hand, has moved somewhat toward centralised trust in the form of auto-signing systems (PGP Inc., now part of Symantec, ran one such keyserver). Signatures by such keyservers are not a strong assurance of trust, but do establish a documentary record of key existence and history which may prove useful.
Full and true trust are phenomenally complex and/or difficult. Ultimately, impossible as an absolute, but useful even in imperfect form.
You can also partially trust keys, in which case a given key requires multiple signatures (from partially-trusted signers) to itself be considered trusted.
Note the distinction between trusting a key and its signers.
Among core problems with PGP/GPG is the lack of a notion of a negative trust signature. That is "I am signing this key to indicate that I know it is not what it claims to be and/or is otherwise not trustworthy". That would be generally useful (and, of course, also generally exploitable in various ways, a common story).
(Malicious ad injection + HTTP = mobile billing)
Link to Directive please?
(The reason I ask is that news reporting on EU law in English is extremely unreliable, and it's best to go to primary sources)
I-scoop[0] explains it well. Do some digging in the documents[1] and you'll get the idea where it's heading to.
"Respect for the privacy of one’s communications is an essential dimension of this right, applying both to natural and legal persons. Confidentiality of electronic communications ensures that information exchanged between parties and the external elements of such communication, including when the information has been sent, from where, to whom, is not to be revealed to anyone other than to the parties involved in a communication. The principle of confidentiality should apply to current and future means of communication, including calls, internet access, instant messaging applications, e-mail, internet phone calls and personal messaging provided through social media." [1](page 6, article 7)
> (The reason I ask is that news reporting on EU law in English is extremely unreliable, and it's best to go to primary sources)
Completely agreed, it's a complete jungle of information and the source documents are hard to digest.
[0] https://www.i-scoop.eu/gdpr/eu-eprivacy-regulation/#The_cons... [1] http://data.consilium.europa.eu/doc/document/ST-15333-2017-I...
The only SSL cert you should ever pay money for is $90/year for an EV SSL cert for an ecommerce/product purchasing website where people are entering credit card details. The big friendly green bar GUI element, for non-technical users, is worth it.
> The only SSL cert you should ever pay money for...
You can still "pay" Lets Encrypt, my understanding is that as a non-profit they rely primarily on sponsorship and donations. If you are using them in production for a product making money one could at least consider throwing them a donation. If no one contributes we don't get to have nice things like LetsEncrypt!
HN discussion: https://news.ycombinator.com/item?id=16485801
Well, they also weren't actually running a CA business either.
a) in a sense maybe they thought they were disclosing their private key to a their CA so in a sense it didn't really matter because their CA could issue certificates for their domain anyway (... ignoring certificate transparency/other external verification)
[... we know this is not true and it's mostly people don't know/don't care/it doesn't matter what they are doing in the scheme of things]
If they had done that they wouldn't have had access to any private keys in the first place, so all their subsequent mistakes in mishandling those keys would have been impossible to make.
As for the whole "arbitrary Remote Code Execution as root" on their web server, that's got a pretty obvious solution: sanitize your data inputs, and don't run your web application server as root.
How is it that these guys have managed to stay in business for this long?
If you'd like to have more verification for your certificate you need a extended validation certificate (which often costs money). These certificates also include your (company) name and the issuer verifies whether it's correct or not.
Basic certificate issuers don't judge over domain names or content, they just verify domain ownership.
In the past, the bar used to be much higher.
Whether a lower bar is a good idea or not I will leave to other more informed folk.
For identify validation, you'd need to buy an EV or OV cert. But for most organizations, particularly if your domain IS your identity, a domain-validated cert is absolutely fine.
It is complete and total bullshit that DV SSL certs still cost money (thanks LetsEncrypt), anywhere from $9/year to $80/year.
The companies that rely on selling DV validated SSL certs for their business model are polishing the brass doorknobs on the Titanic. It's all going down. Just a question of when.
The author has a fundamental misunderstanding of the situation [1]. Trustico's awful decisions regarding
a) storing customers private keys and
b) improperly handling key material
Have no bearing whatsoever on EV certs, which verify the legal entities that run websites. This is like saying Trustico is bad, therefore HTTPS is bad.
[1] Assuming this is what the author said - the site is in plain HTTP so integrity isn't guaranteed.
More than one CA has been shown to be extremely lacking in trustworthiness and that trust is important. I'm OK with the centralised model but there needs to be a bit more visibility of the CA process.
...That, and given the massive failures we've seen coming out of the CA world recently, I question whether those audits are actually worth anything.
If you hang out on mozilla.dev.security.policy for a while, you'll see plenty of examples of audits exposing weaknesses or sloppiness on the part of CAs, and receiving the resulting pushback from browser vendors. Here's the most recent example I've found: https://groups.google.com/forum/?fromgroups=#!topic/mozilla....
Cloudflare uses Comodo for their SSL. They could use some other cert authority, but they chose to use Comodo. This is on topic, in a general sense of CAs and trust. It bears repeating: Bad actors tend to flock together.
There are like ten thousand other options...
Also, they were amongst the only ones to offer ECDSA certificates IIRC.
Cloudflare detailed a little bit about this in this and other blog posts:
Having multiple issuers is important for us as each CA, at some point in time, has operational issues. Additionally, as you've seen with Symantec, browsers take action to distrust certain issuers/roots.
When either of these scenarios happens, our customers don't care if it's the third-party that's down—they expect fast and reliable issuance from us (Cloudflare).
What Cloudflare does is dangerous to the integrity of safe browsing, for a variety of reasons. And their aggressive marketing to convince a lot of tech-ignorant people with low traffic websites that they need a CDN is harmful.
Is it too much to ask that their service at least operate in a way that doesn't poison the internet they're getting rich from?
Did your colleague mis-speak?
The main issue is that Cloudflare needs to have plain-text traffic to examine, which cannot be done with End-to-End encryption from the client to the origin server, in which case you would definitely need a separate certificate for each domain.
https://fightthefuture.org/article/the-new-era-of-corporate-...
..and the CTO who made that decision later backed down and said he wouldn't make that same decision again. O_o
I really feel like the biggest reason they're still in business is that very few alternatives offer anything really competitive.
The fact that American TV networks weren't allowed to say "shithole" in reporting what the US President said is an example of censorship. The FCC, a government agency, requires that they not use certain words. When Fox decided to get rid of O'Reilly that's not censorship that's just basic ability to read how the wind is blowing.
Private censorship is still censorship, however. It is also a form of speech itself.
I'm simply pointing out that when you have incompetent and crooked people in tech, they often run in packs.
You might argue that altruism has no place in business but I disagree. When the CEO of Comodo launched his attack on Let's Encrypt, Cloudflare had opportunity to cut all ties with them. There's plenty of other CAs they could work with. They chose to ignore that scandal, and that matters.
[1] This is the sort of lazy mistake I would make, because I'm not a security expert.
And I understand that your real criticism was with PKI. That makes it even worse that you called it SSL. Again, I feel like you're showing your lack of expertise in this area. I'm not an expert at all in this area and yet even I can recognize that you're playing armchair security expert.
It's not quite as bad as calling JS Java or vice versa, it's more like saying Java and then saying Java 1.2 and Java 1.8 and so forth.
TLS, however, is an "evolution" of SSL and many, many people still use this nomenclature. It doesn't "reek of amateur hour and shallow knowledge", it's just a holdover from the past.
We all know and understand what others are referring to when they say "SSL". It's like when I tell the girlfriend I'm going to go on a "bike ride". She understands that I mean I'm going for a ride on my Harley, a motorcycle, and not an actual bicycle.
Or last weekend, when a friend asked me, "Hey, could you move your car so <other person> can get out?". While I could have stood there arguing with him or correcting him (since my car was actually at home, in my driveway), I instead went out and moved my truck so that the other guest could leave.
This excessive, unwarranted pedantry is annoying as hell. You may be "technically correct" but you make everyone around you dislike you.
To make an absolute statement about the fundamental soundness of PKI and then use completely the wrong term? Come on. Can you imagine a real expert doing this and not at least recognize their own mistake? Don't talk about "fundamental flaws" when you don't know the difference between SSL and TLS and PKI. This is very much like someone trying to criticize the design of TCP/IP and not knowing the difference between an IP address and a MAC address.
Try saying this in the Netherlands (or, presumably, Denmark). Everyone would be surprised when you bring out your motorcycle instead of your bike (i.e., bicycle).
We have natural experiments showing that WoT, at least as implemented, doesn't scale. I hate that humans don't seem to be able to make it work, but that's reality for you.
Yes, I am a security pessimist.
You're assuming that random people on the internet are going to collectively be more secure than CAs, which is obviously not the case.
Imagine you get an email signed by the IRS, and which is trusted by people A1, A2 and A3, who are trusted by people B1, B2, and B3 ... who are trusted by Z1, Z2, and Z3, who are fully trusted by you.
Should be reliable, right?
But while Z1, Z2 and Z3 may keep all OPSEC rules, you have no guarantee that they verified that Y1, Y2 and Y3 did. And even if they did, you have no guarantee that ...
And even if you did, can you guarantee that no one there got any malware, which signed off on a bunch of fake certs?
I'm not saying WOT solves all of our problems. It only makes it slightly better than verifying every key yourself. But it's better than the CA model because you can make it work for you.
1. This is a ton of work and a lot of guesswork even for educated individuals. I end up looking at either explicit chains of trust (I trust Bob and he trusts Alice and she says that this is definitely my bank's website) or some random value an algorithm spits out that tries to convey how "trusted" an entity is based on how many paths there are to it and how short they are. In either case, it's a manual decision that will often feel arbitrary.
2. Laypersons are completely fucked. No way my grandmother can reasonably decide who to trust this way.
If web of trust ever becomes widespread somehow, I guarantee you a month later Google and Apple and Microsoft will become the de facto CAs because everyone will just look to them in the web of trust and see if one of them vouches for their banking website.
Except that none of those companies bother verifying one's identity if you're not actually paying for their services.
> and see if one of them vouches for their banking website.
In that scenario, could I not just verify the bank's public key when I'm physically in one of their branch locations while opening an account? They could also verify my public key at the same time. That would allow for a direct line of trust. The same could apply to any company one deals with.
I'm sure in this scenario, those companies will be delighted to step fully into the role of CA including accepting money for identity vouching.
> In that scenario, could I not just verify the bank's public key when I'm physically in one of their branch locations while opening an account? They could also verify my public key at the same time. That would allow for a direct line of trust. The same could apply to any company one deals with.
No. The same couldn't apply to any company. My primary bank is online only. And how many times have you actually walked into an Amazon office? Or Paypal? Are people in Ohio supposed to fly to San Jose to get Paypal's public key when they create an account? Or are we going to wait for the post office to deliver a physical copy of Paypal's public key (and we'll just trust that whole transaction couldn't be compromised). Physical key exchange is simply not practical in most cases.
You could? Would your grandmother? Would you fly to Mountain View to get Google's? And then turn around and fly to Washington DC to get the IRS's? And then turn around and fly to who knows where to get HN's? And then tell them to keep customer staff ready to assist you to install their public keys?
And what about personal blogs that don't want to be MITM?
Can your grandmother trust you? Or maybe you're not prepared to keep her secure so you just tell her "trust Google, grandma".
The fact that I have to answer this tells me that you haven't though through the implications of web of trust very far.
While I maybe trust someone to be a real person after I've met them in real life and ate their spaghetti to give me back the 10$ they borrowed, I wouldn't trust them to verify the identity of the IRS for me.
The current solution is that we have some third parties which follow strict rules defined by themselves and browser vendors. Everyone involved has a very good incentive to remain trustworthy, otherwise they'd be out of business.
Sadly this doesn't prevent bottomfeeders like Trustico, StartTLS and others to leech of the system while some are genuinely interested in securing everyone's communication (see LE)
The Web of Trust only works if your trust in someone is binary and understandable to a computer, otherwise the browser might tell you "This website is 35.218% Trustworthy".
HTTPS trust must be binary. Either the cert is trusted or it isn't.
It's even more fun; GPG is considering to abandon the WoT. They're switching to TOFU instead, the first time you see a key it's trustworthy, similar to SSH.
Which is horrible unless your first connection to a server is trustworthy or you have an out-of-band way to verify keys (which is why it works in SSH, and can't work on the web).
For PGP/GPG I feel like that TOFU is what most people are doing anyways, this change will only formalize the 0.90-quantile behaviour.
Yes, probably. Key signing parties used to be a thing. I was able to find one that happened in London in 2014 (no idea how many keys were signed, though). Unfortunately people are not aware of the concept of trust and especially of the fact they delegate trust to these third party CAs. It's just not a proper way to do security.
The TOFU model is the best thing if you actually verify the keys out-of-band. Web of trust is the best way I'm aware of to enable in-band verification. I don't claim that it will actually work in practice. But that's fine. All it means is you can't actually do in-band verification in practice. I think most people here are beginning with the assumption that in-band verification is possible and then criticising WOT for its practical shortcomings which is ridiculous.
I think a real solution would be something like a multi-root, score-based system (e.g. if the U.S. government, Underwriters Laboratories & ICANN all state that I'm talking to www.google.com/172.217.13.238, then I honestly probably am) — but I'm worried that it'd be way too complex for normal people.
CAA records help with this, where available, but still leave some things to be desired.
Let's Encrypt shut down their new test interface because of a security flaw they found. If this was in a production service, this would have been about as bad of a security flaw as is possible in a PKI system.
Let's not get all high and mighty assuming Let's Encrypt won't get compromised; they probably will. We should be planning for how to deal with that.
If somebody is doing a distributed chat/social system, I would use ssh if I were them.
By ssh I don't mean execution commands but rather encryption/authentication framework.
There are some well known trade-offs, namely that having everyone manually verify fingerprints on initial connect and again on any server change is a large burden.
I don't particularly want to have to go into my bank's local office and verify in person the fingerprint is correct each time they need to rotate a secret.
If this isn't what you meant, that we should use TOFU vs Trusted third party, please do expand.
Only if users never replace their keys, which puts them at significant risk in the event of a key compromise.
For banks, it could work quite well. Most other people and organizations aren't that lucky, though.
CAs have proven again and again to be ridiculously insecure, and the problem is that there is no penalty for their mistakes.
So just remove them all, after a warning period: Let's Encrypt is enough.
Or if they want to stay in business and be trusted by browsers, then require them to put up at least $100k in cash in escrow for each certificate they sign, which is forfeit if there's evidence that any compromise of that specific certificate, due to their fault, has or may have happened, with at least half of the money being distributed to whoever provides the evidence first.
Compromising any CA affects the entire internet.
Although it's unlikely that's of any use, since unsophisticated users aren't going to differentiate, and sophisticated ones can use other means to verify identity.
No. I love Let's Encrypt, but we can't put all our eggs in a single basket like that.
Now, if we could somehow foster multiple non-profit organizations like Let's Encrypt, but run under the aegis of different boards and sponsors, I'd be 100% for this idea.
It's very odd that companies for whom CAs business is quite literally a money printing operation can't be bothered to do the relatively minimal maintenance and care required for a trustworthy CA. A bizarre and unexpected failure of the market.
The consumers are, partially, buying a product they can't see: The security operations of the vendor.
Given the consumer has imperfect information, it is exceptionally profitable for a supplier to just not invest in security. The downside being the risk of compromise.
A market set up this way entirely predicts low-cost suppliers. With no way for consumers to introspect security routines, two vendors will appear to simply differ in price. The outcome is rather obvious.
It's like a building that needs secure doors: it's better to invest in a single, massive, bulletproof, guarded door rather than inviting anyone who meets some standards to add a door to the building, since what matters is the weakest door.
If it can be reliably proven that a CA is compromised, then it can be fixed.