[HN Gopher] Security concerns with the e-Tugra certificate autho...
___________________________________________________________________
Security concerns with the e-Tugra certificate authority
Author : jamespwilliams
Score : 127 points
Date : 2022-11-17 17:41 UTC (5 hours ago)
(HTM) web link (ian.sh)
(TXT) w3m dump (ian.sh)
| tinus_hn wrote:
| At least certificate transparency means it's possible to check if
| malicious certificates where issued.
| jrockway wrote:
| I think that interpreting the results can be confusing.
| Companies can certainly check their own domains regularly, but
| as an ordinary web user, it's difficult to determine from CT
| logs whether or not example.com that you are about to visit has
| a fraudulently issued cert or not. Maybe they happened to
| legitimately switch providers that day. You weren't in the
| meeting, you don't know.
|
| (I know that CAA records exist in DNS, which are a good signal.
| But there isn't DNS change transparency; every DNS reply can be
| unique, so someone can easily serve a faulty CAA record to an
| evil/hacked CA, and you wouldn't notice. DNSSEC exists to solve
| this particular problem, but is its own new and exciting set of
| problems that I have yet to fully understand.)
| hulitu wrote:
| > I ended up taking a deep look into e-Tugra, a Turkey-based
| certificate authority trusted by Apple, Google, Mozilla, and
| other clients
|
| He shall look at American CAs. Trusting CAs based on pedigree is
| ... funny.
| buraktamturk wrote:
| There is law in Turkey which is passed in the state of emergency
| (2016) and these laws later become permanent. If the government
| demanding anything from a Turkish company and this demand will
| not be complied quickly, then the government takes the control of
| the company (replacing boss, changing banking passwords)
| temporarily in order to comply. This process does not involve
| judicial authority but an administrative one. It wouldn't matter
| if it involved judicial authorities because justice system is
| worst kind of joke.
|
| I know it because they took control of our company in 2016. The
| reason in the decision: "inspector found no evidence of tax
| evasion, which is suspicious for a Turkish company, therefore we
| take control of the company." (not joking)
| buraktamturk wrote:
| It is very easy for Turkish government to issue fake
| certificates via a Turkish company. They did it with Turktrust
| once (CA certificate issued to EGM and EGM issued a cert for
| *.google.com, EGM stands for Turkish Police), they can do it
| again.
| bombcar wrote:
| Any government that can _seize_ the domain can issue a fake
| cert for that domain, so no matter what is put in place, the
| Turkish government could always issue a fake cert for .tr -
| or any other domain owned by a Turkish company.
|
| The *google.com stuff is the more dangerous, but that can be
| detected pretty quickly _if widely deployed_ - the
| intelligent way would be to only do so in very target
| situations and very, very rarely.
|
| (Google added certificate pinning and other things to try to
| protect against this in the future)
| buraktamturk wrote:
| No government can do it as easy as Turkish government, in
| many of the countries they have laws and there are
| mechanisms to ensure they are followed - if not there are
| punishments. Turkey does not have laws as for 2022 (they
| only exists on paper and no one cares). If Turkey does this
| there won't be any punishment to itself for harming the CA
| company and any journalist reporting this incident will be
| thrown to jail, if not killed for exposing Turkish
| Intelligence secrets.
|
| The probabilities talk. 0.00001% this is happening in
| Europe (which would ended up with punishment for liable
| parties) vs. >50% this is happening in Turkey (punishment
| of journalists for exposing this etc).
| bombcar wrote:
| Sure, Turkey is way more likely to do it than other
| countries, but it is done in various places and various
| ways - the US even has a default page for "this domain
| has been seized" and they've been known to run "illegal"
| domains for quite awhile collecting data.
| buraktamturk wrote:
| Which is not the same thing with issuing rouge
| certificates to MitM you, especially for political
| purposes. For example, a winner of local best talent TV
| show (Atalay Demirci)'s Twitter account hacked and his
| messages published online and just because of his
| ordinary messages with a former Turkish deputy (Hakan
| Sukur), who is now in exile in the U.S. - he got jailed
| for political reasons.
|
| So a rouge certificate for *.twitter.com can really ruin
| ordinary people life in Turkey. We are talking about a
| human life here.
| jeroenhd wrote:
| This is why certificate transparency is so important. They can
| sign fraudulent certificates and MitM websites for a short
| while, but the CA will probably be permanently blacklisted if
| any browser in the wild encounters these certificates.
|
| Turkey can eliminate their trust based companies one by one if
| they deem it necessary, but for a government seemingly trying
| to focus on export the distrust would probably hurt more than
| it would yield. See DigiNotar and WoSign/StartCom.
| josephcsible wrote:
| I wish the TLS Name Constraints extension were widely
| supported. Then browser vendors could just say that until that
| law gets repealed, they won't accept root CAs from any Turkish
| entities without a Name Constraints extension limiting them to
| only sign within the .tr TLD.
| NovemberWhiskey wrote:
| X.509 Name Constraints _are_ widely supported in browsers at
| this point - ref. https://bettertls.com - at least for DNS
| SANs and for the common cases.
| woodruffw wrote:
| > In many regards, certificate authorities are audited
| comprehensively against industry-specific audit standards.
| Certificate authorities also routinely get hacked. Despite this,
| not a single certificate authority runs a bug bounty program, and
| of the major CAs, only GlobalSign and Let's Encrypt even offer a
| security.txt to help disclose issues. Only an annual penetration
| is generally required of CAs.
|
| These feel like the wrong metrics: the attackers who compromise
| CAs don't generally overlap in skillsets with people who engage
| in bug bounty programs, and (AFAIK) `security.txt` has had no
| significant adoption in the broader community.
| iancarroll wrote:
| Seems like you are saying that bug bounty researchers focus
| more on application security issues and not other types of
| security, which is certainly true, but [some % of] breaches
| occur via appsec issues and they're what bit e-Tugra here.
| coretx wrote:
| Even rogue states have their own CA's and we are trusting them.
| That is a real security concern.
| PradeetPatel wrote:
| [Citations needed]
|
| Last time I checked we don't have any CA's from North Korea or
| Afghanistan...
|
| Happy to be proven wrong.
| throw_a_grenade wrote:
| Last time it was KZ's MITM cert that was rejected:
| https://blog.mozilla.org/security/2019/08/21/protecting-
| our-....
|
| Although you can argue that US' FPKI is "rogue" for the
| purposes of WebPKI (there's no control, no transparency, no
| audit etc.) and cross signature over FPKI Bridge was one of
| the reasons contributing to Symantec forcible retirement.
| kingofpandora wrote:
| Those aren't the only two "rogue dates.
| zapatistan wrote:
| This is a huge security issue according to Turkish law (called
| KVKK). They should report this security breach here
| https://www.kvkk.gov.tr/veri-ihlali-bildirimi/ but I haven't seen
| anything reported from them.
| stordoff wrote:
| > there were many log lines referencing [EJBCA]
|
| Is this link supposed to go somewhere specific, or just to the
| EJBCA homepage? It currently just points back to
| https://ian.sh/etugra
| qwertox wrote:
| I wish I could set my browser into a mode where CAs are an opt-
| in.
|
| I enable this setting and at first I can't go to Google unless I
| enable Google's CA. The go to Amazon and get the warning, get
| displayed what I will be enabling and have the ability to use
| Google to search if I will trust them. So I enable DigiCert
| Global CA in order to use Amazon, and ask myself why the hell I
| need to trust that 3rd party.
|
| And so on. This way I would never have Hong Kong Post Office's CA
| enabled in my browser.
| woodruffw wrote:
| You can't do this directly in your browser, but you can do it
| with your system certificate store. Lots of people disable
| these small, low-volume CAs.
|
| (I wonder if there's a tool out there that does so
| automatically? Something like Filippo's mkcert but for
| automatically pruning the CA store down to just the ~dozen
| major operators?)
| e63f67dd-065b wrote:
| I'm still surprised that in the year 2022 people still pay enough
| money for certs that CAs manage to exist providing SSL certs. EV
| and OV is effectively dead (and was never a good idea anyways),
| so who exactly is paying for their certs?
| bombcar wrote:
| Lots and lots and lots of systems are not setup to handle Let's
| Encrypt auto-renewing certs, and so people keep plugging away
| with the ones they've always been using.
|
| Dropping them down to one year duration may help push people
| towards LE and friends.
| hsbauauvhabzb wrote:
| How much web does removal of these CAs actually impact? I'm an
| English speaking westerner* and most of the certs I see signed
| are either letsencrypt or digicert.
|
| * Relevance: I assume other languages / countries use more
| localised certs.
| throw_a_grenade wrote:
| You can pull a full list from crt.sh:
| https://crt.sh/?caid=163319, then for each child CA search for
| % (there are possibly also other roots, rinse and repeat).
| khiqxj wrote:
| aaand episode #352381 of "woah all these people who i thought
| were sophisticated are actually just a bunch of lazy / ignorant
| sysadmins". wouldnt want one obscure CA you never heard of to get
| hacked, that would compromise every other website (or maybe not
| with this X.509 name constraints gimmick people are talking about
| in this thread)
| mrtksn wrote:
| Oh, this reminds me if TurkTrust scandal[0] when they granted a
| local govt. corporation the ability to generate fake certificates
| and they were caught when generated fake Google certs.
| Considering the identity of the mayor, I'm still not convinced
| that no people were harmed.
|
| [0] https://nakedsecurity.sophos.com/2013/01/08/the-turktrust-
| ss...
| skullone wrote:
| Aren't CAs supposed to go through vetting and audits before
| getting trusted in operating systems and browsers? We even went
| through a SOC audit just for our own internal CA!
| hulitu wrote:
| And who is auditing them ? CIA ? Goldman Sachs ? KGB ? EFF ?
| perlgeek wrote:
| While adding a new CA to trusted set requires some kind of
| rigor, there's a quite large selection of CAs that were just
| "always there".
|
| Since many browser vendors are reluctant to remove CAs (because
| it breaks lots of websites for users), they don't have too much
| leverage enforcing security practices.
| tgsovlerkhgsel wrote:
| Here's the audit:
| https://bugzilla.mozilla.org/show_bug.cgi?id=1628720#c14
|
| The requirements they are supposed to check against:
| https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-...
| - section 5 addresses security, referencing "The CA/Browser
| Forum's Network and Certificate System Security Requirements" -
| https://cabforum.org/network-security-requirements/, which at
| least in the version 1.3 that I saw required pentests and
| security scans.
| Avamander wrote:
| I'd imagine CA/B forum adopting new rules to avoid situations
| like this. The very least just a requirement to publish
| security contact information.
| wellareyousure wrote:
| kevincox wrote:
| The CA system and WebPKI is more or less fundamentally flawed.
|
| - Too few CAs and you loose on competition.
|
| - Too many CAs and the probability of vulnerabilities approaches
| 100%.
| woodruffw wrote:
| "Competition" is not a desirable property in a cryptosystem.
| The fact that it's a property of WebPKI at all is a historical
| quirk of CA organizational practices and the (entirely
| artificial) market for certificates.
|
| In other words: we should be seriously cutting down the number
| of trusted CAs.
| kevincox wrote:
| The problem is that CAs aren't really part of the
| cryptosystem. They hold the roots of trust but charge for
| there services and are for-profit. Without any competition we
| would have a terrible monopoly.
|
| I agree that there are too many CAs. But the ideal number is
| also significantly more than 1.
|
| ...well unless you include zero. If we can replace this with
| something better that would be much more desirable.
| woodruffw wrote:
| How so? The cryptosystem in question is WebPKI. CAs form
| the roots of trust in WebPKI, as you mentioned.
|
| > They hold the roots of trust but charge for there
| services and are for-profit. Without any competition we
| would have a terrible monopoly.
|
| This hasn't been true for years! Let's Encrypt provides
| free certificates to anyone with a domain. They issue
| millions of certs a day and secure a _massive_ chunk of the
| web[1].
|
| I think everybody is in broad agreement that the CA system
| is brittle, vulnerable to mismanagement, bad actors, etc.
| But "something better" is _very_ hard to identify and
| implement. Churchill 's saying about the "worse system
| except for all the others"[1] applies equally well here,
| IMO.
|
| [1]: https://blogs.fcdo.gov.uk/petermillett/2014/03/05/the-
| worst-...
|
| [1]: https://www.linuxfoundation.org/resources/case-
| studies/lets-...
| luckylion wrote:
| > This hasn't been true for years! Let's Encrypt provides
| free certificates to anyone with a domain.
|
| Because they _are_ the competition.
| woodruffw wrote:
| The point being that the monopoly's back has been broken.
| We're no longer in a situation where there _needs_ to be
| >100 CAs for market competition purposes; there's now a
| free, universally available, public service.
| ocdtrekkie wrote:
| This is the correct take. There's a bunch of policies and
| practices but essentially dozens of shady providers have
| complete ability to impersonate anyone on the web, and the
| behavior of those policies and practices is set by a might-
| makes-right of the most popular browser vendors.
|
| The entire system is equal parts insecure and absolutely
| impractical, such that 80% of organization have had an outage
| caused by certificate issues but certificates aren't
| meaningfully providing security.
| fmajid wrote:
| FWIW, a Tughra is the great seal of Ottoman emperors. Soliman the
| Magnificent's is well-known:
|
| https://www.dailyartmagazine.com/tughra-of-sultan-suleiman-t...
| hangonhn wrote:
| Wow. That's absolutely beautiful. Thanks for sharing that.
| cmeacham98 wrote:
| I understand why browsers are in a position where they don't want
| to remove CAs unless there is repeated and egregious issues, but
| I wish there was some third party that would rate CAs. I'd be
| willing to lose access to 1% of the web if it meant cutting 90%
| of these garbage CAs off my root certificates list.
| iso1631 wrote:
| Be great if you could open your certificate store, look through
| the list of roots, and see how often you have used each one,
| and a list of sites they have approved.
|
| Then you could say "hmm, these I've never used -- set it to
| manual approval for each site they try to authenticate"
|
| Or "For this one, that's great, I'll use it to authenticate
| _.ae domains, but nothing more, or I 'll allow
| _.bankofchina.com, but nothing more"
|
| Would only apply for 0.001% of browser users though, and they
| are the ones who are more likely to push for a better solution
| which will apply to the rest of the world, so I can see why
| they don't want that.
| tgsovlerkhgsel wrote:
| Certificate Transparency is even better, it allows you to see
| all certificates these CAs issued. This also means the site
| operator can monitor for certificates issued for their site
| and notice if a CA they aren't using issues one.
|
| Unfortunately, Firefox doesn't seem to enforce CT
| https://developer.mozilla.org/en-
| US/docs/Web/Security/Certif...
| jiripospisil wrote:
| > Certificate Transparency is even better, it allows you to
| see all certificates these CAs issued.
|
| What OP suggested would potentially prevented a rogue
| behavior from a hacked CA to cause any damage. With
| Certificate Transparency you would just have a nice log
| about it afterwards.
|
| > This also means the site operator can monitor for
| certificates issued for their site and notice if a CA they
| aren't using issues one.
|
| All they could do is to just turn off the site and report
| the incident. It would still take hours before that
| certificate would be revoked and that information
| propagated to browsers. I'm also fairly confident 99.5% of
| website operators do not watch any cert monitors.
| bawolff wrote:
| > With Certificate Transparency you would just have a
| nice log about it afterwards.
|
| Fear of consequences is a powerful thing. A rouge cert
| issue basically kills the CA.
| badrabbit wrote:
| I have a simple solution, allow multiple CAs to issue a cert
| and for a site to use a CAA record or the like to pin them and
| for browsers to encourage and enforce CAA record upkeep. So you
| can say letsencrypt and digicert and only those two can issue a
| cert for my site. Or if updating DNS is cumbersome, include a
| field in the cert for alternative CAs. Browsers can then pin
| CAs to a site.
|
| That way it would require multiple CAs to be compromised or act
| in concert to affect a user who visited the site prior to a
| compromise. For new visitors, browsers can expand their normal
| CT check to include alternative CA declarations. The connection
| is secure only if all CAs certify all other CAs as valid and
| the certificate being authentic. If there is a valid cert
| issues in CR logs from a different CA, user gets an insecure
| connection warning -- which does mean random CAs can mis-issue
| certs and cause errors (for sites with multiple CAs that is)
| but will only help get rid of those CAs.
| notpushkin wrote:
| This. Browsers should mark sites without CAA as untrusted.
| (Also without DNSSEC maybe?)
|
| I'm wondering why DANE didn't take off.
| Avamander wrote:
| Because DNSSEC is just a second PKI that can't fix the
| problems with WebPKI without fixing those same problems
| with itself.
| tptacek wrote:
| There are a whole plethora of practical reasons why DANE
| turned out to be unworkable, but this really is the core
| of it. It's worth keeping in mind that you can revoke an
| entire CA --- immensely popular and important CAs have
| been entirely removed from trust stores, quite recently
| --- but you _can 't_ do that with the DNS hierarchy. You
| can't do long term secrets without some form of
| revocation, and that's fundamentally what DANE
| represents.
| neilv wrote:
| I once did sorta this for a long period, as a daily-driver
| exercise: un-trusted all the CAs in the browser bundle except a
| few that I recognized as very popular.
|
| Then, on occasion of a site with untrusted CA, figured out
| which one it was, and then decided whether I wanted to trust
| it. It was a headache, but it happened only very infrequently.
|
| This exercise was inspired by my unease with the current CA
| scheme, and seeing some of the ones that were trusted by
| default.
| [deleted]
| Maxburn wrote:
| I did that for a while too, but on my phone. It was a big
| hassle as apps and services do not handle this gracefully at
| all. Sometimes you get a failure for something to connect,
| sometimes it just stops working silently. Rarely I got a
| clear message about the untrusted cert.
| lizardactivist wrote:
| Are there any CAs that are wholly owned and based in the EU, and
| who do strictly offline signing of certificates?
| advisedwang wrote:
| > wholly owned and based in the EU
|
| I believe anf.es is
|
| > strictly offline signing of certificates
|
| CSRs, signed certs, certificate transparency log entries,
| revocations etc have to get between the signing device and
| public some how. You can create a gap, but then you have to
| bridge it somehow for this data.
|
| Do you want an organization that prints out and types in every
| request going across that gap? You're probably not going to
| find that.
| lizardactivist wrote:
| Is there any of this that could not be done on a daily basis?
|
| Requests go on a memory card at the end of the day, onto the
| signing device which signs them for a year, back on the card
| and onto the network-connected device from where they are
| mailed back to the customer.
|
| What functions of a CA have to be run more frequently than
| this?
| NovemberWhiskey wrote:
| What is the threat model that results in this being your
| requirement?
___________________________________________________________________
(page generated 2022-11-17 23:00 UTC)