11 ms·

Weakening TLS protection, South Korean style

158 points by pat-jay 4y ago

shp0ngle 4y ago
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. so this is all doubly stupid.
- palant 4y ago
  Note: I am the author of this article. Yes, that’s what I also assume. I didn’t bother verifying however that mixed content warnings are generally not an issue with localhost in any browser that South Korea cares about (e.g. Internet cough Explorer). Keep in mind that they have some rather adventurous ways to access the local web server, such as JSONP or communicating by posting to a frame.
  - heleninboodler 4y ago
    The localhost issue is very interesting. Of course, there's no chance that someone is impersonating localhost, but there is a chance that someone is eavesdropping on it (although this implies a level of privilege that may make encryption moot). Should browsers just accept self-signed certs for localhost on the assumption that you can't actually impersonate it? Maybe. I used to run internal PKI for a large company and "can I get a cert for localhost" was one of the top 3 arguments I used to find myself in (for the record, the answer was always no).
    - palant 4y ago
      Interception of localhost traffic is in fact a non-issue, someone able to do it can do worse. So TLS really shouldn’t be necessary on localhost, that’s it.
      - heleninboodler 4y ago
        Certainly seems likely to be the case, but I'm open to there being a theoretical attack that involves being able to inspect the data flowing through the TCP stack without being able to inspect the process spaces of the two endpoints. E.g. if the TCP stack was able to be put in a debug mode that was logging packets somewhere, you'd prefer those to be encrypted. It's pretty far-fetched in terms of an attack surface, but "this data never exists unencrypted outside these two processes' memory spaces" is objectively stronger in a specific way than plaintext transiting kernel buffers.
    - shp0ngle 4y ago
      the browsers are currently just accepting http on localhost and it’s the best solution. The eavesdropping issue is nonsense. The only reason is “we want to support IE7”, I guess. Which I didn’t consider but might be an actual usecase in South Korea
  - shp0ngle 4y ago
    Yeah IE7 doesn’t support SSL-less localhost. I think that will be the main reason.
- easrng 4y ago
  all major browsers except, iirc, safari. though these apps might not target mac anyway?
kijin 4y ago
Even worse, there has been at least one "security program" that installed its own CA and went on to prevent any further modification to the CA list. 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. 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.
- i67vw3 4y ago
  Can you a cite source for it, will be interesting to read about this situation in south korea.
  - kijin 4y ago
    Unfortunately there isn't a definitive source, only a bit of noise in the blogs for a few days. AFAIK it was difficult to pinpoint exactly which version of which program was the culprit, since people aren't free to install an arbitrary version of a government-mandated security program. Most website owners just got tired of the bullshit and bought a cheap Sectigo cert instead. But the symptoms were very clear. Some program, at some point before ISRG Root X1 became included in Windows, had set the registry key \HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot\DisableRootAutoUpdate to 1, when it should have been 0 by default. I remember having seen a name being mentioned, but can't find the name now. The program was probably from a healthcare and/or welfare related website, since most of the complaints that came across my desk were from physicians, pharmacists, and welfare workers. No complaints at all from casual shoppers and bank users.
roxgib 4y ago
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.
- palant 4y ago
  Note: I am the author of this article. There are semi-legitimate use cases. One is intranets where you might want to have HTTPS on non-public resources. More commonly the company installs their own root CA however so that they can monitor all outgoing traffic. The other use case are antivirus applications – same reasoning here, they want to monitor all traffic. And: yes, adding this certificate should normally be a user-initiated action. There is no way of preventing applications from automating it however. E.g. Firefox doesn’t have an API to install root CAs, so these applications package up NSS Tools in their installer, search for Firefox profiles during installation and add their root CA to any certificate database they can find.
  - lb4r 4y ago
    On a somewhat (un)related note: What has been the reception, if any, from the Korean side in regards to your research? I've lived in Korea on and off for around ten years, and their online 'security' has always both bothered and worried me. It's nice to see someone actually opening up this horrendous and intrusive mess of software and investigating it.
    - palant 4y ago
      On the individual level, the reception is remarkably positive. I’ve had lots of people thank me for this research, including people working for government agencies. The news coverage is mixed. Some articles are positive about this and are asking about how to improve this sad state of affairs. Others are parroting statements from the affected companies: not actually bad, difficult to exploit, misunderstanding of the domestic market. And as to politics, it’s too early to tell I think. This definitely generated much attention. Whether all this attention will actually lead somewhere is impossible to tell at this point.
dncornholio 4y ago
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. Also, I think you have to manually confirm as a user to install such certificates. Maybe I am missing something, but this smells like "Korea Bad" without explaining why.
- palant 4y ago
  Note: I am the author of this article. In fact, the article does explain this. The CAs that are on this list by default have to comply with strict criteria making sure they cannot be abused. Anything that has been added externally, avoiding the usual processes of Microsoft/Mozilla/Apple, is suspect.
  - dada78641 4y ago
    I know very little about certificates and online security, but I'm also kind of baffled by the expiration time of the iniLINE certificate (2018-10-10 to 2099-12-31). I feel that's also a poor practice, right? What should a regular expiration time be for a proper root certificate?
    - palant 4y ago
      Microsoft specifically requires that root certificates have an expiration time no longer than 25 years. See here: https://learn.microsoft.com/en-us/previous-versions//cc751157(v=technet.10)#a-root-requirements https://learn.microsoft.com/en-us/previous-versions//cc75115...
    - michaelt 4y ago
      That's actually kinda normal. There's no authority above root certificates,* able to sign new certificates - that's what it means to be a root certificate. So root certificates will often have super long durations. For example, the certificate HN uses is signed by "DigiCert Global Root CA" - valid from 2006 to 2031. * Unless you count the power of OSes/browsers to push updates with new certificates.
voytec 4y ago
Related, from the same author: "South Korea’s online security dead end"[1], "IPinside: Korea’s Mandatory Spyware"[2] [1] https://palant.info/2023/01/02/south-koreas-online-security-dead-end/ https://palant.info/2023/01/02/south-koreas-online-security-... [2] https://news.ycombinator.com/item?id=34516013 https://news.ycombinator.com/item?id=34516013 https://palant.info/2023/01/25/ipinside-koreas-mandatory-spyware/ https://palant.info/2023/01/25/ipinside-koreas-mandatory-spy...
- dang 4y ago
  Thanks! Macroexpanded: IPinside: Korea’s Mandatory Spyware - https://news.ycombinator.com/item?id=34516013 https://news.ycombinator.com/item?id=34516013 - Jan 2023 (80 comments) South Korea’s online security dead end - https://news.ycombinator.com/item?id=34231364 https://news.ycombinator.com/item?id=34231364 - Jan 2023 (135 comments)
vbezhenar 4y ago
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.
- palant 4y ago
  Note: I am the author of this article. And what if somebody else gets hold of their private key and uses it to MITM? I mean, it’s only South Korea, it’s not like they have a neighbor country which would be willing to abuse this kind of thing in targeted attacks…
  - ikekkdcjkfke 4y ago
    And it’s not like said neighbour has abused hacked security tools before
jesprenj 4y ago
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. 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, ... 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. 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.
- ilyt 4y ago
  IIRC you can actually create CA/sub-CA that had permission only to given subdomains it's just that client support for that was very spotty. It really is how it should be; get the CA for your domain and manage away, no reliance on 3rd party CA for each issue for certs on your domains.
  - hoppla 4y ago
    Do you know of any CAs that are willing to issue such certificates?
    - michaelt 4y ago
      The feature is called 'RFC 5280 Name Constraints' and nobody will issue you such certificates. This is because some clients don't support the constraints, so if they give you a CA certificate that can sign any subdomain of evil.com you could use it to sign MITM certificates for good.com and, although you wouldn't fool modern web browsers, you might fool smart fridges and ancient android phones. You can, however, use it to constrain your in-house corporate CA if you like.
yrro 4y ago
At least we can say that South Korean web security has moved on a little bit since the truly dark days of SEED. > 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. https://en.wikipedia.org/wiki/Web_compatibility_issues_in_South_Korea#E-commerce_encryption_technology https://en.wikipedia.org/wiki/Web_compatibility_issues_in_So... I think the country only started moving away from SEED/ActiveX in 2011?!
- anecdotal1 4y ago
  That's what US crypto embargoes create
- palant 4y ago
  Note: I am the author of this article. Yes, they successfully moved away from ActiveX. Not sure about SEED, I think I still saw it in one of the applications. But there seems to be another contributing factor, the Korea Exchange Bank hacking incident in 2005. I explained it here: https://palant.info/2023/01/09/touchen-nxkey-the-keylogging-anti-keylogger-solution/#the-backdrop https://palant.info/2023/01/09/touchen-nxkey-the-keylogging-...
- kyllo 4y ago
  I lived in Korea in 2008-2010 and can confirm the ActiveX thing was still in widespread use then. It was a pain because every website effectively only worked in IE, meanwhile I had a Mac and couldn't log into any secure websites such as my local bank account from it.
- deleted 4y ago
  [deleted]
tinus_hn 4y ago
If authorities can’t issue certificates for IP addresses, browsers shouldn’t accept certificates for ip addresses. South Korea needs to rethink its security ‘solutions’ and the only way to do that is by the software vendors forcing their hand.
- palant 4y ago
  Note: I am the author of this article. Authorities can issue certificates for IP addresses. They merely cannot issue certificates for non-public IP addresses. And: yes, maybe certificates for 127.0.0.1 should be disallowed altogether. But this creates a backwards compatibility issue, and I’m not sure browser vendors are willing to do it.
  - tinus_hn 4y ago
    I see that indeed it is allowed to issue certificates for IP addresses (however not for private addresses). In my opinion this should not be allowed, there is no real justification for issuing them. I don’t believe in too big to fail theories about certificates for local addresses, they are not allowed and should not be accepted. If your application breaks, you get to keep the pieces. I doubt there is a lot of real use though, apart from misuse as in the article.
andix 4y ago
Running http(s) over TCP on localhost should not happen on any production application. This simply doesn’t properly work in a secure manner.
- ronsor 4y ago
  Since browsers killed plug-ins, there's simply no alternative if a website needs to communicate with a locally-installed application.
  - andix 4y ago
    Just don’t do it then. Either ship something electron based (or similar) with an embedded browser and IPC communication with the bundled „backend“, or communicate via a trusted server. Listening on localhost is a security nightmare, also because it is accessible from other user accounts on the same machine. The server probably can do some privileged tasks (otherwise you wouldn’t need it) and could be hijacked by malware.
    - trallnag 4y ago
      Just don't do it then? Great reply
      - andix 4y ago
        No, really. Let's stick to the example online banking: If you need to install software to use it, why don't you just deliver an Electron (like) application, and host the whole banking application inside of the application? You get the additional benefit, that you can configure the security inside your applications browser as you wish, pin certificates to make MITM even less likely. Electron let's you ship native code too, comes with an auto updater, etc. And there are numerous alternatives to Electron if you don't like to ship a full Chrome browser. It get's a bit more complicated then, but its possible, take a look at Tauri for example. To be honest, I had multiple projects, where a http://localhost http://localhost solution was proposed, and we found a better solution without it. It is very rarely the best thing to do.
tgsovlerkhgsel 4y ago
> 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. Modern browsers will treat http://127.0.0.1/ http://127.0.0.1/ 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). There would be other workarounds, but the correct solution is this, if this kind of portal is in fact required/a good idea in the first place.

158 points by pat-jay 4y ago

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. so this is all doubly stupid.

palant 4y ago
Note: I am the author of this article. Yes, that’s what I also assume. I didn’t bother verifying however that mixed content warnings are generally not an issue with localhost in any browser that South Korea cares about (e.g. Internet cough Explorer). Keep in mind that they have some rather adventurous ways to access the local web server, such as JSONP or communicating by posting to a frame.
- heleninboodler 4y ago
  The localhost issue is very interesting. Of course, there's no chance that someone is impersonating localhost, but there is a chance that someone is eavesdropping on it (although this implies a level of privilege that may make encryption moot). Should browsers just accept self-signed certs for localhost on the assumption that you can't actually impersonate it? Maybe. I used to run internal PKI for a large company and "can I get a cert for localhost" was one of the top 3 arguments I used to find myself in (for the record, the answer was always no).
  - palant 4y ago
    Interception of localhost traffic is in fact a non-issue, someone able to do it can do worse. So TLS really shouldn’t be necessary on localhost, that’s it.
    - heleninboodler 4y ago
      Certainly seems likely to be the case, but I'm open to there being a theoretical attack that involves being able to inspect the data flowing through the TCP stack without being able to inspect the process spaces of the two endpoints. E.g. if the TCP stack was able to be put in a debug mode that was logging packets somewhere, you'd prefer those to be encrypted. It's pretty far-fetched in terms of an attack surface, but "this data never exists unencrypted outside these two processes' memory spaces" is objectively stronger in a specific way than plaintext transiting kernel buffers.
  - shp0ngle 4y ago
    the browsers are currently just accepting http on localhost and it’s the best solution. The eavesdropping issue is nonsense. The only reason is “we want to support IE7”, I guess. Which I didn’t consider but might be an actual usecase in South Korea
- shp0ngle 4y ago
  Yeah IE7 doesn’t support SSL-less localhost. I think that will be the main reason.
easrng 4y ago
all major browsers except, iirc, safari. though these apps might not target mac anyway?

kijin 4y ago

Even worse, there has been at least one "security program" that installed its own CA and went on to prevent any further modification to the CA list. 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. 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.

i67vw3 4y ago
Can you a cite source for it, will be interesting to read about this situation in south korea.
- kijin 4y ago
  Unfortunately there isn't a definitive source, only a bit of noise in the blogs for a few days. AFAIK it was difficult to pinpoint exactly which version of which program was the culprit, since people aren't free to install an arbitrary version of a government-mandated security program. Most website owners just got tired of the bullshit and bought a cheap Sectigo cert instead. But the symptoms were very clear. Some program, at some point before ISRG Root X1 became included in Windows, had set the registry key \HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot\DisableRootAutoUpdate to 1, when it should have been 0 by default. I remember having seen a name being mentioned, but can't find the name now. The program was probably from a healthcare and/or welfare related website, since most of the complaints that came across my desk were from physicians, pharmacists, and welfare workers. No complaints at all from casual shoppers and bank users.

roxgib 4y ago

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.

palant 4y ago
Note: I am the author of this article. There are semi-legitimate use cases. One is intranets where you might want to have HTTPS on non-public resources. More commonly the company installs their own root CA however so that they can monitor all outgoing traffic. The other use case are antivirus applications – same reasoning here, they want to monitor all traffic. And: yes, adding this certificate should normally be a user-initiated action. There is no way of preventing applications from automating it however. E.g. Firefox doesn’t have an API to install root CAs, so these applications package up NSS Tools in their installer, search for Firefox profiles during installation and add their root CA to any certificate database they can find.
- lb4r 4y ago
  On a somewhat (un)related note: What has been the reception, if any, from the Korean side in regards to your research? I've lived in Korea on and off for around ten years, and their online 'security' has always both bothered and worried me. It's nice to see someone actually opening up this horrendous and intrusive mess of software and investigating it.
  - palant 4y ago
    On the individual level, the reception is remarkably positive. I’ve had lots of people thank me for this research, including people working for government agencies. The news coverage is mixed. Some articles are positive about this and are asking about how to improve this sad state of affairs. Others are parroting statements from the affected companies: not actually bad, difficult to exploit, misunderstanding of the domestic market. And as to politics, it’s too early to tell I think. This definitely generated much attention. Whether all this attention will actually lead somewhere is impossible to tell at this point.

dncornholio 4y ago

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. Also, I think you have to manually confirm as a user to install such certificates. Maybe I am missing something, but this smells like "Korea Bad" without explaining why.

palant 4y ago
Note: I am the author of this article. In fact, the article does explain this. The CAs that are on this list by default have to comply with strict criteria making sure they cannot be abused. Anything that has been added externally, avoiding the usual processes of Microsoft/Mozilla/Apple, is suspect.
- dada78641 4y ago
  I know very little about certificates and online security, but I'm also kind of baffled by the expiration time of the iniLINE certificate (2018-10-10 to 2099-12-31). I feel that's also a poor practice, right? What should a regular expiration time be for a proper root certificate?
  - palant 4y ago
    Microsoft specifically requires that root certificates have an expiration time no longer than 25 years. See here: https://learn.microsoft.com/en-us/previous-versions//cc751157(v=technet.10)#a-root-requirements https://learn.microsoft.com/en-us/previous-versions//cc75115...
  - michaelt 4y ago
    That's actually kinda normal. There's no authority above root certificates,* able to sign new certificates - that's what it means to be a root certificate. So root certificates will often have super long durations. For example, the certificate HN uses is signed by "DigiCert Global Root CA" - valid from 2006 to 2031. * Unless you count the power of OSes/browsers to push updates with new certificates.

voytec 4y ago

Related, from the same author: "South Korea’s online security dead end"[1], "IPinside: Korea’s Mandatory Spyware"[2] [1] https://palant.info/2023/01/02/south-koreas-online-security-dead-end/ https://palant.info/2023/01/02/south-koreas-online-security-... [2] https://news.ycombinator.com/item?id=34516013 https://news.ycombinator.com/item?id=34516013 https://palant.info/2023/01/25/ipinside-koreas-mandatory-spyware/ https://palant.info/2023/01/25/ipinside-koreas-mandatory-spy...

dang 4y ago
Thanks! Macroexpanded: IPinside: Korea’s Mandatory Spyware - https://news.ycombinator.com/item?id=34516013 https://news.ycombinator.com/item?id=34516013 - Jan 2023 (80 comments) South Korea’s online security dead end - https://news.ycombinator.com/item?id=34231364 https://news.ycombinator.com/item?id=34231364 - Jan 2023 (135 comments)

vbezhenar 4y ago

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.

palant 4y ago
Note: I am the author of this article. And what if somebody else gets hold of their private key and uses it to MITM? I mean, it’s only South Korea, it’s not like they have a neighbor country which would be willing to abuse this kind of thing in targeted attacks…
- ikekkdcjkfke 4y ago
  And it’s not like said neighbour has abused hacked security tools before

jesprenj 4y ago

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

ilyt 4y ago
IIRC you can actually create CA/sub-CA that had permission only to given subdomains it's just that client support for that was very spotty. It really is how it should be; get the CA for your domain and manage away, no reliance on 3rd party CA for each issue for certs on your domains.
- hoppla 4y ago
  Do you know of any CAs that are willing to issue such certificates?
  - michaelt 4y ago
    The feature is called 'RFC 5280 Name Constraints' and nobody will issue you such certificates. This is because some clients don't support the constraints, so if they give you a CA certificate that can sign any subdomain of evil.com you could use it to sign MITM certificates for good.com and, although you wouldn't fool modern web browsers, you might fool smart fridges and ancient android phones. You can, however, use it to constrain your in-house corporate CA if you like.

yrro 4y ago

At least we can say that South Korean web security has moved on a little bit since the truly dark days of SEED. > 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. https://en.wikipedia.org/wiki/Web_compatibility_issues_in_South_Korea#E-commerce_encryption_technology https://en.wikipedia.org/wiki/Web_compatibility_issues_in_So... I think the country only started moving away from SEED/ActiveX in 2011?!

anecdotal1 4y ago
That's what US crypto embargoes create
palant 4y ago
Note: I am the author of this article. Yes, they successfully moved away from ActiveX. Not sure about SEED, I think I still saw it in one of the applications. But there seems to be another contributing factor, the Korea Exchange Bank hacking incident in 2005. I explained it here: https://palant.info/2023/01/09/touchen-nxkey-the-keylogging-anti-keylogger-solution/#the-backdrop https://palant.info/2023/01/09/touchen-nxkey-the-keylogging-...
kyllo 4y ago
I lived in Korea in 2008-2010 and can confirm the ActiveX thing was still in widespread use then. It was a pain because every website effectively only worked in IE, meanwhile I had a Mac and couldn't log into any secure websites such as my local bank account from it.
deleted 4y ago
[deleted]

tinus_hn 4y ago

If authorities can’t issue certificates for IP addresses, browsers shouldn’t accept certificates for ip addresses. South Korea needs to rethink its security ‘solutions’ and the only way to do that is by the software vendors forcing their hand.

palant 4y ago
Note: I am the author of this article. Authorities can issue certificates for IP addresses. They merely cannot issue certificates for non-public IP addresses. And: yes, maybe certificates for 127.0.0.1 should be disallowed altogether. But this creates a backwards compatibility issue, and I’m not sure browser vendors are willing to do it.
- tinus_hn 4y ago
  I see that indeed it is allowed to issue certificates for IP addresses (however not for private addresses). In my opinion this should not be allowed, there is no real justification for issuing them. I don’t believe in too big to fail theories about certificates for local addresses, they are not allowed and should not be accepted. If your application breaks, you get to keep the pieces. I doubt there is a lot of real use though, apart from misuse as in the article.

andix 4y ago

Running http(s) over TCP on localhost should not happen on any production application. This simply doesn’t properly work in a secure manner.

ronsor 4y ago
Since browsers killed plug-ins, there's simply no alternative if a website needs to communicate with a locally-installed application.
- andix 4y ago
  Just don’t do it then. Either ship something electron based (or similar) with an embedded browser and IPC communication with the bundled „backend“, or communicate via a trusted server. Listening on localhost is a security nightmare, also because it is accessible from other user accounts on the same machine. The server probably can do some privileged tasks (otherwise you wouldn’t need it) and could be hijacked by malware.
  - trallnag 4y ago
    Just don't do it then? Great reply
    - andix 4y ago
      No, really. Let's stick to the example online banking: If you need to install software to use it, why don't you just deliver an Electron (like) application, and host the whole banking application inside of the application? You get the additional benefit, that you can configure the security inside your applications browser as you wish, pin certificates to make MITM even less likely. Electron let's you ship native code too, comes with an auto updater, etc. And there are numerous alternatives to Electron if you don't like to ship a full Chrome browser. It get's a bit more complicated then, but its possible, take a look at Tauri for example. To be honest, I had multiple projects, where a http://localhost http://localhost solution was proposed, and we found a better solution without it. It is very rarely the best thing to do.

tgsovlerkhgsel 4y ago

> 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. Modern browsers will treat http://127.0.0.1/ http://127.0.0.1/ 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). There would be other workarounds, but the correct solution is this, if this kind of portal is in fact required/a good idea in the first place.