
How not to run a CA - stablemap
http://blog.koehntopp.info/index.php/3075-how-not-to-run-a-ca/
======
mkhalil
In related news, Trustico's site is down apparently due to users being able to
run commands as root on their webserver.

I wonder if this was used to extract some private keys?

[https://twitter.com/svblxyz/status/969220402768736258](https://twitter.com/svblxyz/status/969220402768736258)
[https://twitter.com/Manawyrm/status/969230542578348033](https://twitter.com/Manawyrm/status/969230542578348033)

~~~
tetha
I am aware this is not contributing to the thread but... the only way I can
summarize my feelings on that is 'holy fuck'. I just spent a minute just
muttering 'holy fuck' to myself.

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?

~~~
blattimwind
"As a security company."

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

~~~
tetha
If you sell certs, you're a company in a security-related context. I don't
care who you are, I care if you do your job.

Saying that, that quote sounds way too long to not be BS.

~~~
hetspookjee
The quote sounds like SEO.

~~~
0x0
CEO SEO?

~~~
labster
SpaceX to launch SEO CEO's REO into LEO.

(I expect this post will get 0E0 upvotes)

------
kasperni
They have a tool that allows you create a private key + CSR

[https://www.trustico.com/ssltools/create/csr-pem/create-a-
ne...](https://www.trustico.com/ssltools/create/csr-pem/create-a-new-csr-
instantly.php)

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...](https://web.archive.org/web/20180217071027/https://www.trustico.com/ssltools/create/csr-
pem/create-a-new-csr-instantly.php)

~~~
blattimwind
Up until a few years ago there was a <keygen> tag which embedded a x509 CSR
generator into a regular HTML form. The private key was generated by the
browser(1) and was completely inaccessible to the site or any JS running on
it. That's the proper way to generate certificates in browsers, but it's been
removed since and was never supported in IE.

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.

~~~
tialaramex
You say "they of course ignored almost everything in the CSR apart from the
public key" but it turns out they went a bit further than that, they also
ignored the signature on the CSR.

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.

~~~
blattimwind
Actually I've never seen a solid argument for why that's a problem. A similar
issue exists in PGP, but again it's unclear what the actual problem is. Some
(non-x509) PKIs can't do this anyway.

~~~
tialaramex
Two people have asked essentially the same thing here, I'll answer this one
because it was at the top. I am going to deliberately use a far-fetched
scenario rather than invoke specific technologies, because there is no benefit
to learning more specific here than "Nope, a competent CA must never allow
this to happen".

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.

~~~
blattimwind
I'm aware of this[1], and with what you said out front in mind - it doesn't
apply to either HTTPS or PGP. (I'm pretty sure you can build systems affected
by this with X509, though).

[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)

~~~
tialaramex
Hmm. I _think_ I agree with you that it isn't practical in HTTPS. I can see
clearly why you can't do anything like this in TLS 1.3 because it has this
nice simple ordering - the client and server do DH key agreement - we now both
have encryption but no certainty of who we're talking to - then the server
sends a certificate and uses the key from that certificate to sign their DH
transcript, the client optionally also sends a certificate, they too use the
key from that certificate to sign the transcript. Since I don't know Alice's
Private Key I cannot sign transcripts while presenting the (Bob,A)
certificate, and if I let Alice do the key exchange so that she'll sign, I'm
cut out of the loop entirely. That's easy to follow.

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.

------
makecheck
This shows that you need a lot more than a fancy web site to convince you that
a CA is professional.

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.

~~~
pas
This was a "reseller", and they don't have to be audited, and the browser CA
inclusion policy probably doesn't mandate anything from CAs regarding their
resellers. Well, it should.

------
firloop
The thing that isn’t clear to me is how Trustico even had the private keys to
begin with. It’s been a while since I’ve purchased a SSL certificate, but I
remember generating the private key locally and providing a certificate
signing request, which isn’t the private key. What am I misunderstanding here?

~~~
aiCeivi9
"Trustico allows customers to generate a Certificate Signing Request and
Private Key during the ordering process," the statement read. "These Private
Keys are stored in cold storage, for the purpose of revocation."

Maybe they decided preparing CSR is too hard for their clients :/

~~~
u801e
> Maybe they decided preparing CSR is too hard for their clients :/

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.

~~~
recursive
And they're probably not wrong. In other words, I suspect that if there were
two identical competing services, the convenient one would win. If one only
supported client certs, and one only supported 2FA, I have a (unsupported)
feeling that the client cert company would not survive long.

~~~
jis
Yep. The problem is that most customers cannot judge the level of security
offered by a company. So Company "A" says they are "secure," but has a
cumbersome process to follow to get a certificate. Company "B" says they are
"secure" and has a convenient process. Guess which one gets the business (all
else being equal).

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.

~~~
HelloNurse
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.

~~~
u801e
While that may be true, that doesn't mean the rest of us shouldn't have the
option of using certificate based authentication.

~~~
HelloNurse
We have the option of using certificates, but not the option of giving away
private keys.

------
empath75
Oh, it's worse than that:
[https://twitter.com/svblxyz/status/969220402768736258](https://twitter.com/svblxyz/status/969220402768736258)

You can run arbitrary shell commands as root from their webserver.

~~~
warent
Cue the intro to Bohemian Rhapsody. This is a huge WTF. SQL injection? Too
basic. We do raw shell injection now. To a CA.

Welcome to the future of computers where security comes secondary to extra
profits and marketing.

~~~
Ajedi32
FWIW, Trustico isn't a CA. They're a certificate reseller; all certificate
validation is handled by a different company. If Trustico hadn't been
generating their customers private keys for them (or if their customers had
refused to let them do things that way) they wouldn't have been able to screw
things up this badly.

~~~
warent
Got it, that kind of makes sense. The concept of certificate reseller doesn't
make a whole lot of sense to me but thank you for making the distinction

~~~
tialaramex
Mostly they exist because of price discrimination.

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.

------
sphix0r
Ironically his blog isn't available on https. Would be time that browers mark
http sites' address bar as "Not secure" in orange.

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.

~~~
slim
Security depends on your threat model. HTTP is generally secure for publishing
and has the added advantage of being cacheable by proxies. This blog is secure

~~~
inetknght
> _HTTP is generally secure_

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?

~~~
dredmorbius
HTTP plus a trusted hash would provide an integrity measure of the content of
a page, and enable hashing.

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](https://unix.stackexchange.com/q/90227)

~~~
inetknght
You cannot have a "trusted hash" if you cannot trust the delivery mechanism
(unencrypted and unauthenticated TCP).

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.

~~~
kerkeslager
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
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.

~~~
inetknght
> 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.

~~~
dredmorbius
> 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 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.

~~~
dredmorbius
One clarification: You choose the _signing_ keys you trust.

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).

------
syncsynchalt
While the article title is accurate (you should not run your CA in this
manner), Trustico is not a CA but is instead a reseller of CA services.

------
walrus01
This is such a clusterfuck I don't even know where to begin. I am very happy
that "pay money" for DV SSL certs is going the way of the dinosaur, with Let's
Encrypt.

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.

~~~
0XAFFE
I would pay for an acme endpoint that is not rate limited.

~~~
techmonster
You don't have to pay; you just have to ask. :-)

[https://letsencrypt.org/docs/rate-
limits/#overrides](https://letsencrypt.org/docs/rate-limits/#overrides)

~~~
fredsted
And it just "takes a few weeks"!

------
nailer
Original (and much more accurate) source:
[https://www.digicert.com/blog/digicert-statement-trustico-
ce...](https://www.digicert.com/blog/digicert-statement-trustico-certificate-
revocation/)

HN discussion:
[https://news.ycombinator.com/item?id=16485801](https://news.ycombinator.com/item?id=16485801)

------
zokier
> proving that Trustico has knowledge of all their customers private keys,
> keeping copies of them, which proves that they never knew how to run a
> Certficate Authority business in the first place

Well, they also weren't actually running a CA business either.

------
benmmurphy
also, 23,000 people disclosed their private key to a third party.

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]

------
ahmedalsudani
This is going to be the funniest thing I read all day. Thanks for writing it
up!!

------
StavrosK
Mirror, because the site wasn't loading for me earlier:
[https://www.eternum.io/ipfs/QmSjZic3JCaU3MHro8MyvRi1RpQweuYC...](https://www.eternum.io/ipfs/QmSjZic3JCaU3MHro8MyvRi1RpQweuYCen2HGpyFUTauWX/)

------
johnhenry
I'm wondering if anyone could explain what the "right" thing for Trustico to
do?

~~~
Ajedi32
They should not have offered a web form for generating private keys, and
instead should have educated their customers on how to generate their private
keys and CSRs on their own servers.

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.

------
shruubi
> So the CEO of Trustico, Zane Lucas, mailed the private keys of 23000
> Trustico customers to Digicert

How is it that these guys have managed to stay in business for this long?

------
kerkeslager
Intel is breathing a sigh of relief that finally there's a distraction from
Spectre and Meltdown.

------
herodotus
letsencrypt is great and I use it. But I don't really get it. All I needed to
do was prove that I could place a generated file on the server that I wanted
the certificate for. This seems to me to be a very low bar. What am I missing?

~~~
vsund
There's a difference in certificate type. Let's encrypt (which only issues
basic certificates) just verifies that you're the rightful owner of a domain,
not whether the domain is what it says.

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.

~~~
pfg
To clarify, other certificate types do not judge content either. The
difference is that they verify your organisational details (to a varying
degree, depending on the validation level) and include them in the
certificate. The CA is not going to check whether the business is fraudulent
or anything like that.

------
nailer
> TL;DR: Forget your EV or other certs. Just run “Let’s Encrypt”.

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.

~~~
rkangel
There is at least some merit to the argument that "Trustico Bad" => "CAs bad"
=> "HTTPS Bad".

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.

~~~
Karunamon
I'd settle for an end to the credentialism that ensures only the rich and
powerful can enter the CA business. The actual technical chops and
physical/operational requirements to become a CA are modest by the standards
of the average HN reader, but the financial cost for the audit required to
wind up in the browser trust stores is prohibitively high.

...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.

~~~
cortesoft
Aren't the audits what allow us to find out about the failures, and revoke
their ability to be a CA?

~~~
Karunamon
How many of the most recent failures have come to light as a result of a
failed audit, and how many were due to a post-audit, outrage-generating
violation of basic best practice and common sense?

~~~
teraflop
The whole point of auditing is to detect problems _before_ they become big,
embarrassing, messy failures that put users at risk.

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....](https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.security.policy/Mezqdljjerc)

------
originalsimba
"Bad Actors" in the tech field tend to flock together. Comodo has been at the
center of several really ugly stories, this one being the latest. The CEO of
Comodo attempted to sue Lets Encrypt before they launched, in order to kill
the project because of the threat it represented to their business model.
after 24 hours of backlash from the internet public he backed down and said it
was all a misunderstanding. Of course.

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.

~~~
sneak
Your argument for guilt by association is not compelling. Cloudflare is their
customer. I am Cloudflare’s customer. Does that make me a bad actor too?

~~~
djsumdog
Continued usage of Cloudflare baffles me. They spewed tons of private data,
across customer boundaries, on random web responses, which made its way into
search engine cache around the world. They conducted an act of Internet
censorship:

[https://fightthefuture.org/article/the-new-era-of-
corporate-...](https://fightthefuture.org/article/the-new-era-of-corporate-
censorship/)

..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.

~~~
sneak
Keeping nazis off of servers one owns/rents themselves is not censorship.

~~~
niij
How is that not censorship? Their opinions are wrong and disgusting but
kicking them as a customer for their beliefs is very obviously censorship.

~~~
tialaramex
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
to get rid of O'Reilly that's not censorship that's just basic ability to read
how the wind is blowing.

~~~
originalsimba
You're speaking of a strict definition of censorship which is when an
authoritative body is the one censoring. And you are not wrong.

Private censorship is still censorship, however. It is also a form of speech
itself.

------
cup-of-tea
SSL is fundamentally broken. Web-of-trust is the only real way to do security.

~~~
nfoz
I think the real sentiment here is: good PKI is an unsolved (and perhaps
unsolvable) problem.

~~~
zeveb
I agree. The CA model is broken (why should I trust a Russian to certify
cia.gov?). The Web of Trust model is less broken in some ways, more in others.

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.

~~~
yjftsjthsd-h
I would settle for restricting scope of CAs. As you say, cia.gov should only
be signable by (at least) US CAs, but whatever.gov.ru should probably NOT be
signable by any American CAs.

CAA records help with this, where available, but still leave some things to be
desired.

------
peterwwillis
> TL;DR: Forget your EV or other certs. Just run “Let’s Encrypt”. It gets you
> a cert, it’s fresh, and it does not make any difference whatsoever. At least
> not any you or anyone else can check for, or cares for.

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.

~~~
majewsky
That doesn't make sense. You cannot criticize someone for finding an issue in
the testing environment _before_ it hits production. That's _literally_ what
the testing environment is for.

~~~
peterwwillis
I was not criticizing them (can you quote the part of my comment that was
critical?). I was illustrating that they are not perfect, and just using them
without considering that they too could be compromised is a bad idea.

------
thriftwy
I think we should use ssh instead of SSL and also ssh instead of
username/password pairs.

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.

~~~
TheDong
ssh is, by default, Trust on First Use which is a significantly different
model than a Trusted Thirdparty (CAs).

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.

~~~
thriftwy
I think it works much better for contacts. You have to verify contact once and
then you are assured that it's still the same person.

~~~
teraflop
> You have to verify contact once

Only if users never replace their keys, which puts them at significant risk in
the event of a key compromise.

~~~
slrz
Replace your key by signing a message announcing your new key?

~~~
Manozco
If your key is compromised, anyone can send that message and sign it with your
key... :)

------
devit
Browsers need to remove all CAs except Let's Encrypt.

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.

~~~
jnbiche
> Browsers need to remove all CAs except Let's Encrypt.

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.

~~~
devit
Security requires that ALL CAs be secure, since any compromised CA can
compromise all websites (barring fragile schemes like pinning or certificate
transparency checks), so the less CAs there are, the more secure the system
is.

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.

~~~
manigandham
The proper solution is to actually make sure the CAs are secure, it doesn't
matter if there are 1 or many. Also more CAs mean that any problems are only
localized to their certificates instead of the entire internet.

