- 🇰🇷 번역상태: 1차 검토/수정 중 (2023-01-31)
이 글은 저자의 허락을 받아 영문으로 된 원문을 한국어로 번역한 글입니다.
번역 오류 및 잘못된 내용에 대한 수정은 [참여방법](https://github.com/alanleedev/KoreaSecurityApps/blob/main/CONTRIBUTION.md)을 읽은 후 Pull Request를 부탁드려요.
-
아래 글 번역에 참여한 이:
-
원본 문서: Weakening TLS Protection, Korean Style (2023-02-06)
-
번역 문서 최초 작성일: 2023-02-06 (PR을 통해 계속 업데이트 중)
일반적으로 은행 웹사이트에 접속할 때 가짜 웹사이트가 은행을 사칭할지 걱정할 필요는 별로 없다. 웹 브라우저에서 실제 올바른 서버에 접속했는지, 그리고 연결이 안전하게 암호화되었는지 확인하기 때문이다. 이건 주소창에 보이는 자물쇠 아이콘을 보면 확인할 수 있다.
그래서 (공공장소의 와이파이와 같은) 신뢰할 수 없는 네트워크에 연결된 경우에도 별다른 문제가 되지 않는다. 누군가 은행 웹사이트를 사칭하면, 브라우저가 이를 알아차리고 연결을 거부할 것이다.
이것은 TLS(Transport Layer Security)라는 프로토콜을 통해 이루어진다. 이는 신뢰할 수 있는 여러 인증 기관(Certification Authority; CA)에서 웹사이트에 발급해주는 인증서(certificate)에 의존하고 있다. 이러한 인증서를 통해 웹사이트는 자신의 신원(identity)을 증명할 수 있다.
한국의 소위 보안 프로그램이란 것들을 조사하면서 알게 된 것인데, 모든 조사 대상이 각자 웹 브라우저에서 신뢰해야만 하는 자체 인증 기관을 추가하고 있었다. 이런 자체 인증 기관을 악용할 경우, 상당수의 한국인을 대상으로 어떤 웹사이트든지 사칭할 수 있을 정도로 TLS의 보호 기능이 약화된다. 그 결과, 무엇보다도 이런 보안 프로그램이 보호해야 할 은행 거래가 오히려 위험에 빠질 수 있다.
한국에서 인터넷 뱅킹을 사용한 뒤에는, 해당 컴퓨터에서 신뢰할 수 있는 루트 인증 기관 목록을 확인해보는 것이 좋다. 아마도 여기에 있어서는 안 될 이름들을 발견하게 될 것이다. 예를 들면 이니라인(iniLINE), 인터리젠(Interezen), 위즈베라(Wizvera) 등이 있다.
역주: 윈도우 10 한국어 버전 기준으로 ‘신뢰할 수 있는 루트 인증 기관’ 목록을 보는 방법은 다음과 같습니다.
- 윈도우 시작 버튼을 마우스 오른쪽 버튼으로 클릭하고,
검색(S)또는실행(R)항목을 선택합니다.- 입력 필드에
certmgr.msc라고 입력하고, 엔터 키를 눌러 실행합니다.신뢰할 수 있는 루트 인증 기관→인증서로 들어갑니다.- 그러면 아마도 아래 스크린샷과 유사한 내용을 볼 수 있을 것입니다.
이것들은 일반적으로 신뢰할 수 있는 인증 기관이 아니다. 오히려 각 보안 프로그램이 운영체제의 저장소에 스스로 추가한 것이다. 심지어 이 보안 프로그램들은 구글 크롬이나 마이크로소프트 엣지와는 달리 운영체제의 설정을 사용하지 않는 파이어폭스에도 자체 인증 기관을 추가한다.
현재까지 내가 발견한, 한국의 보안 프로그램이 설치하는 인증 기관의 목록은 다음과 같다.
| 이름 | 설치하는 애플리케이션 | 유효기간 | 일련 번호 |
|---|---|---|---|
| ASTxRoot2 | AhnLab Safe Transaction | 2015-06-18 ~ 2038-06-12 | 009c786262fd7479bd |
| iniLINE CrossEX RootCA2 | TouchEn nxKey | 2018-10-10 ~ 2099-12-31 | 01 |
| INTEREZEN CA | Interezen IPInside Agent | 2021-06-09 ~ 2041-06-04 | 00d5412a38cb0e4a01 |
| LumenSoft CA | KeySharp CertRelay | 2012-08-08 ~ 2052-07-29 | 00e9fdfd6ee2ef74fc |
| WIZVERA-CA-SHA1 | Wizvera Veraport | 2019-10-23 ~ 2040-05-05 | 74b7009ee43bc78fce69 73ade1da8b18c5e8725a |
| WIZVERA-CA-SHA2 | Wizvera Veraport, Wizvera Delfino | 2019-10-23 ~ 2040-05-05 | 20bbeb748527aeaa25fb 381926de8dc207102b71 |
그리고 이 인증 기관들은 수동으로 삭제하기 전까지는 계속 남아 있다. 애플리케이션을 삭제할 때도 함께 제거되지 않는다.
또한 이것들은 모든 목적으로 사용할 수 있도록 설정되어 있다. 따라서 이 인증 기관 중 하나라도 뚫리게 되면, 웹 서버를 인증하는 것뿐만 아니라 다른 애플리케이션이나 이메일의 서명 등에도 악영향을 줄 수 있다.
업데이트 (2023-02-19): 누군가가 좀 더 포괄적인 인증서 목록을 만들었다.
어쨌든 신뢰할 수 있는 루트 인증 기관 목록을 보면 이미 50개 이상의 기관이 등록되어 있다. 여기에 고작 몇 개 더 추가하는 게 뭐가 문제가 될까?
인증 기관을 운영하는 데는 매우 큰 책임이 따른다. 신뢰할 수 있는 인증 기관의 비밀키에 접근할 수만 있다면 어떤 웹사이트든지 사칭할 수 있다. 세계 곳곳의 범죄자나 정부는 당연히 이런 권한을 가지고 싶을 것이다. 이런 권한을 얻은 범죄자라면 당신의 은행을 사칭할 수 있고, 정부라면 들키지 않은 채 당신을 감시할 수 있다.
역주: 조금 어려운 말로 위 문단의 내용을 다시 말하자면, PKI(Public Key Infrastructure, 공개키 기반구조)라는 사회적 약속은 결국 인증 기관(CA)의 신뢰성에 전적으로 의존하고 있다는 것입니다. 인증 기관이 자체 비밀키를 누구에게도 탈취되지 않게끔 안전하게 관리하고 있고, 그걸 통해 오직 신원이 확인된 주체에게만 올바른 인증서를 발급해 준다는 믿음이 현재의 인터넷 체계를 지탱하고 있습니다. 따라서 필자는 인증 기관의 신뢰성이 얼마나 중요한지, 따라서 이 믿음이 무너지는 사태가 얼마나 심각한 결과를 초래할 수 있는지를 바로 위 문단을 통해 설명하고 있는 것입니다.
참고로 과거에도 특정 인증 기관의 신뢰성이 의심받는 사례가 있었습니다. 과거 SSL 인증서 시장에서 업계 1위였던 보안업체 시만텍(Symantec)은 내부 테스트를 이유로 여러 도메인에 대한 인증서를 부정 발급하고 있었으며, 이것이 2015년과 2017년에 각각 드러난 적이 있었습니다. 그중에서 시만텍의 인증서 사업에 치명타를 가한 부정 발급은 시만텍의 한국 내 등록대행기관(Registration Authority; RA)이었던 한국전자인증(CrossCert)이라는 업체에서 2010년부터 2017년까지 비정상적인 절차로 시만텍 명의의 인증서 127개를 발급했던 것입니다. 이로 인해 구글과 모질라 등 주요 웹 브라우저 개발사에서는 2018년 10월까지 시만텍 인증서를 더 이상 웹 브라우저에서 신뢰하지 않도록 하는 강경 조치를 발표했고, 결국 시만텍은 인증서 사업 부문을 디지서트(DigiCert)에 매각하고 말았습니다.
그렇기 때문에 인증 기관에는 비밀키의 접근을 제한하고 적절한 보안을 유지하기 위한 엄격한 규칙이 있다. 또한 인증 기관을 운영하기 위해서는 보안 정책이 모두 계속 잘 지켜지고 있는지 확인하는 정기 외부 감사(audit)도 필요하다.
그런데 이제 한국의 보안 프로그램이 각자 자체 인증 기관을 한국에 있는 수많은 컴퓨터에 설치하고 있으니, 이것들은 해커와 정부 모두에게 큰 표적이 될 수 있다. 만약 이 인증 기관 중 한 곳에서라도 비밀키가 유출된다면, 한국에서 TLS의 보호 기능은 거의 무용지물이 되고 말 것이다.
안랩, 라온시큐어, 인터리젠, 위즈베라는 어떻게 이런 책임을 감당하고 있을까? 비밀키를 하드웨어 보안 모듈(Hardware Security Module; HSM)에 저장하고 있을까? 그건 또 안전한 장소에 보관해두고 있을까? 누가 거기에 접근할 수 있을까? 지금까지 발급된 인증서 목록은 어디에 있을까? 우리는 이런 질문의 답을 알지 못한다. 우리가 확인할 수 있는 외부 감사 결과나, 준수해야 하는 보안 규정 같은 것도 없다.
따라서 사람들은 이 회사들이 모두 비밀키를 안전하게 보관하고 있다고 그저 믿는 수밖에 없다. 하지만 내가 이전에 썼던 글에서 이미 살펴보았듯이, 이들은 사실 보안 분야에 관한 전문성이 별로 없다.
이런 인증 기관을 추가하는 이유는 보안 프로그램에서 로컬 웹 서버와 연결할 때 TLS를 사용하기 위해서인 것으로 보인다.
하지만 실제 인증 기관에서 127.0.0.1 주소로 인증서를 발급해 줄 리가 없기 때문에, 자체 인증 기관을 추가하는 것이다.
그냥 127.0.0.1에 대한 인증서만 필요한 거라면 더 간단한 해결책이 있다.
모든 컴퓨터에 동일한 인증 기관을 설치하는 대신, 각 컴퓨터별로 다른 인증 기관을 설치하면 된다.
그러니까 보안 프로그램을 설치할 때 다음과 같이 하는 것이다.
- 새로운 인증 기관 및 거기에 대응되는 비밀키를 (무작위로) 생성한다.
- 이 인증 기관을 컴퓨터의 신뢰할 수 있는 인증 기관 목록에 추가한다.
127.0.0.1주소를 위한 인증서를 생성하여 이 인증 기관의 비밀키로 서명한다. 이제 애플리케이션이 로컬 웹 서버에 연결할 때 이 인증서를 사용할 수 있다.- 이 인증 기관의 비밀키를 파기한다.
역주: 웹 개발하시는 분들이라면 이게 로컬 개발 환경에서 HTTPS를 사용하기 위한 절차라는 것을 아실 겁니다. FiddlerCap처럼 인터넷 트래픽을 캡처하는 도구에서
Decrypt HTTPS Traffic옵션을 켜는 경우에도 이와 비슷하게 임시 인증 기관을 설치하는 것으로 알고 있습니다.
실제로 Initech CrossWeb Ex V3는 정확히 위와 같은 방식으로 동작하는 것 같다. 이것은 유효 기간 시작 날짜가 설치 날짜부터 시작하기 때문에 쉽게 알아볼 수 있다. 이 방식도 자체 인증 기관을 설치하기는 하지만, 이건 오직 한 컴퓨터에서만 유효하기 때문에 별로 문제가 되지 않는다.
그리고 한 가지 더 주의해야 할 점이 있다. 인증 기관을 추가했으면, 애플리케이션을 지울 때는 이것도 함께 제거해줘야 한다. 하지만 현재로서는 어떤 애플리케이션도 그렇게 하지 않는 것으로 보인다.