Even worse, there has been at least one "security program" that installed its own CA <i>and</i> went on to prevent any further modification to the CA list.<p>It was probably meant to prevent malware from adding their own CAs. In practice, though, it even stopped Windows from keeping its official CA list up to date.<p>In October 2021, the root certificate used by Let's Encrypt expired. All existing certs were cross-signed by another broadly supported (but more recently included) CA, so this should have been a non-issue on any reasonably up-to-date device. Uh oh, a lot of South Korean PCs had had their CA lists frozen for several years. Suddenly, random people all over the country were unable to connect to websites using Let's Encrypt despite being on the latest version of Windows 10. It was nearly impossible for ordinary users to track down the offending program and uninstall it, and there was no guarantee that the CA list would be restored upon uninstallation. A lot of website owners just switched to ZeroSSL or some other CA because of this clusterfsck.
Why is it even possible for an application to install root certificates that other applications have to accept? An individual application accepting its own certificates is one thing (as Firefox does), but I can't think of a good reason why apps would need to modify the OS list of certs.
At least we can say that South Korean web security has moved on a little bit since the truly dark days of SEED.<p>> In the late 1990s, the Korea Internet & Security Agency
developed its own 128-bit symmetric block cipher named SEED
and used ActiveX to mount it in web browsers. This soon
became a domestic standard, and the country's Financial
Supervisory Service used the technology as a security
screening standard. ActiveX spread rapidly in Korea. In
2000, export restrictions were lifted, allowing the use of
full-strength SSL anywhere in the world. Most web browsers
and national e-commerce systems adopted this technology,
while Korea continued to use SEED and ActiveX.<p><a href="https://en.wikipedia.org/wiki/Web_compatibility_issues_in_South_Korea#E-commerce_encryption_technology" rel="nofollow">https://en.wikipedia.org/wiki/Web_compatibility_issues_in_So...</a><p>I think the country only started moving away from SEED/ActiveX in 2011?!
what is missing here - localhost is a trusted origin for at least 5 years. You can call localhost without https from all major browsers now without any cross-origin warnings.<p>so this is all doubly stupid.
> The reason for all these certificate authorities seems to be: the applications need to enable TLS on their local web server. Yet no real certificate authority will issue a certificate for 127.0.0.1, so they have to add their own.<p>Modern browsers will treat <a href="http://127.0.0.1/" rel="nofollow">http://127.0.0.1/</a> as a secure origin (i.e. you can load resources from it from within a secure website without triggering mixed content warnings) specifically to make hacks like this unnecessary. (Depending on the exact browser and version, you may need to use either the IP or "localhost" - one of them isn't universally supported in older versions).<p>There would be other workarounds, but the <i>correct</i> solution is this, if this kind of portal is in fact required/a good idea in the first place.
I think the whole design of PKI is bad. Instead on trusting a handful CAs that have to charge for or severely limit access to their signing servers, PKI could be based on the DNS hierarchy. CA type certificates do have an extension for specifying at which DNS level and below they are valid, so the root DNS operators would have the root cert and would only issue signatures for CA certs to TLDs that are limited to those TLDs only. A TLD administrator would then sign CA certs for second level domains that are time limited to domain validity and have their CA limited to this SLD and below.<p>An owner of an SLD would automatically get a CA cert and wouldn't need to depend on third party issuers (and their OCSP servers to which data leaks), complicated ACME protocols, ...<p>A bank in question could then sign certs for each user and point domains user58284u2874localhost.bank.example to 127.0.0.1. Even better, the bank would be much more secure because there would be no other CA that could sign certs for it's domain, apart from THE SINGLE root CA and it's TLD CA.<p>This entire process of basing on DNS as a security chain already exists in form of DANE/TLSA, which is IMO an even simpler protocol than CA and cert chains. With DANE, TLSA records containing TLS public keys (or cert hashes), trusted on a specific domain, are published in DNS zones, which must be signed by DNSSEC. That way, TLS certificates don't even need to be signed by a CA. No browser currently implements DANE however, it's major users are currently mailservers.
If authorities can’t issue certificates for IP addresses, browsers shouldn’t accept certificates for ip addresses.<p>South Korea needs to rethink its security ‘solutions’ and the only way to do that is by the software vendors forcing their hand.
As long as they don't MITM, that should be fine. And if they MITM, hopefully browser vendors will blacklist their certificates like they did with similar attempt from Kazakhstan.
What does he mean with CA's that don't belong there? When does a CA belong there and when it doesn't? Does it mean if it's from Korea, it automatically doesn't belong there? Article also fails to explain what's malicious about these CA's.<p>Also, I think you have to manually confirm as a user to install such certificates.<p>Maybe I am missing something, but this smells like "Korea Bad" without explaining why.