Earlier quoted context omitted.
On the other hand, a customer who doesn't realize that their private key should never leave their premises has no business asking for a certificate. It's like not selling guns to children.
While that may be true, that doesn't mean the rest of us shouldn't have the option of using certificate based authentication.
How not to run a CA
241–250 of 255 posts
Re: How not to run a CA
#242Earlier quoted context omitted.
We're using the Symantec/Digicert API for getting certs at work. I'm not directly involved in that, but I think when you want to issue a new cert you have to revoke the old one first. The API will just return an error if there is an existing cert for the same domain name. 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 c…
That doesn't make sense. Old cert expires 2018-03-01 23:59:59, yet I'm not even allowed to apply for a new one valid from 2018-03-02 00:00:00?
Re: How not to run a CA
#243Earlier quoted context omitted.
Whilst I do wish I could cleanse a web application of actually supporting system(), we have system() in Perl, Ruby, Python, and modules for Node. I've seen people bagging PHP and that really isn't fair. 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 pre…
You can do so with SELinux btw. You can remove the right for a program to run the exec syscall. 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.
Re: How not to run a CA
#244Earlier quoted context omitted.
You can't have encryption without authentication, because a man in the middle can snoop your connection. 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 wi…
> You can have authentication without encryption. This is what PGP signed messages are. 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.
Re: How not to run a CA
#245Earlier quoted context omitted.
That doesn't make sense. Old cert expires 2018-03-01 23:59:59, yet I'm not even allowed to apply for a new one valid from 2018-03-02 00:00:00?
You can get a new cert when the existing one has less than one month remaining lifetime. The problem is that Chrome now distrusts Symantec certs way before their expiration date.
Re: How not to run a CA
#246Earlier quoted context omitted.
> You can have authentication without encryption. This is what PGP signed messages are. 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.
> you must install the authorization certificate using a secure method. 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 met…
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).
Re: How not to run a CA
#247Earlier quoted context omitted.
This probably happened because they allowed users to execute root commands on their server. Either they quickly shut down the site or someone else did it by shutting down some servers. > https://twitter.com/svblxyz/status/969220402768736258
Oh my. There must be some sort of hall of fame for security vulnerabilities. And this belongs in it. 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.
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.
Re: How not to run a CA
#248Earlier quoted context omitted.
How is that not censorship? Their opinions are wrong and disgusting but kicking them as a customer for their beliefs is very obviously censorship.
Censorship is something sovereign entities do. When anybody else chooses what they will or won't say we call that Free Speech. Nazis don't have a right to make other people say what they want. 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…
Private censorship is still censorship, however. It is also a form of speech itself.
Re: How not to run a CA
#249Earlier quoted context omitted.
If Cloudflare wants wildcards it's so they can have multiple customers, each using completely different origin servers, on a single certificate, which makes those certificates worthless, and I hope Let's Encrypt blacklists Cloudflare from using them when wildcards are launched.
Huh? We want wildcards so that if you sign up example.com we can give you a certificate for example.com and *.example.com. This has nothing to do with SANs.
Re: How not to run a CA
#250Earlier quoted context omitted.
If Cloudflare wants wildcards it's so they can have multiple customers, each using completely different origin servers, on a single certificate, which makes those certificates worthless, and I hope Let's Encrypt blacklists Cloudflare from using them when wildcards are launched.
How is that misusing a wildcard certificate? Should proxy server websites be HTTP only since the content is loaded from a different origin server?
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?