열흘째 그대로인 신뢰
HTTPS로 어떤 서버에 접속하면, 우리 컴퓨터는 서버가 내미는 인증서를 보고 '이 서버가 진짜 github.com이 맞구나' 하고 판단하거든요. 그런데 이 판단의 최종 근거는 결국 루트 인증서예요. 이게 뭐냐면, 운영체제나 브라우저에 미리 심어져 있는 '믿을 만한 인증기관(CA) 명단'이에요. 이 명단에 있는 기관이 서명한 인증서라면 일단 믿고 들어가는 구조죠.
이번에 문제가 된 eMudhra는 인도의 인증기관으로, emSign이라는 이름의 루트 인증서들을 운영해 왔어요. 그런데 관련 인증서가 침해(compromise)된 것으로 알려지면서, 이 인증서들을 더는 믿으면 안 되는 상황이 됐는데요. 원문 작성자는 그로부터 열흘이 지나도록 macOS에 기본으로 깔린 Git이 여전히 이 인증서들을 신뢰하고 있다고 지적하고 있어요. 개발자가 하루에도 수십 번 쓰는 도구에 구멍이 남아 있다는 얘기죠.
인증기관이 뚫리면 뭐가 위험하냐면
신분증을 발급하는 기관의 직인이 도난당했다고 생각해 보세요. 위조범은 그 직인으로 아무 이름의 신분증이나 만들 수 있고, 검사하는 쪽은 직인이 진짜니까 그냥 속아 넘어가요. CA의 서명 키가 노출되면 공격자는 github.com, gitlab.com, 사내 Git 서버 주소처럼 원하는 도메인의 인증서를 '정상처럼 보이게' 만들 수 있어요.
그러면 가능해지는 게 중간자 공격(MITM)이에요. 나와 서버 사이에 몰래 끼어들어 대화를 엿보거나 바꿔치기하는 공격인데요. 조작된 네트워크에서 누군가 가짜 github.com 행세를 해도 Git은 인증서가 '유효'하다고 보고 통신을 이어가요. 이때 HTTPS push에 쓰는 개인 액세스 토큰(PAT)이 새어나갈 수 있고, clone이나 pull 과정에서 악성 코드가 섞인 저장소를 받을 수도 있어요. 개발자 PC가 공급망 공격의 입구가 되는 거죠.
물론 실제 공격이 성립하려면 공격자가 네트워크 경로에 끼어들 수 있어야 하고, 침해된 키도 쥐고 있어야 해요. 당장 모두가 위험하다는 뜻은 아니지만, '믿으면 안 되는 걸 믿는 상태'가 길어질수록 위험의 창이 열려 있는 셈이에요.
Git은 누구의 명단을 보고 있을까
많은 분들이 'OS가 신뢰 목록을 업데이트하면 다 같이 바뀌는 거 아냐?' 하고 생각하시는데, 실제로는 그렇지 않거든요. Git은 HTTPS 통신을 직접 하지 않고 libcurl이라는 라이브러리에 맡기는데, 이 curl이 어떤 TLS 라이브러리와 어떤 CA 목록을 쓰도록 빌드됐느냐에 따라 '누구의 명단을 보느냐'가 달라져요.
macOS에서 /usr/bin/git을 실행하면 애플이 Xcode Command Line Tools에 넣어 배포하는 Git이 돌아가요. git --version을 쳤을 때 (Apple Git-...) 꼬리표가 붙어 있다면 바로 그거예요. 이 Git이 참조하는 신뢰 정보는 애플이 관리하는 영역이라, 애플이 업데이트를 내주기 전까지는 기본 설정만으로 바꾸기 어려워요. 원문이 문제 삼는 지점이 바로 여기예요.
다른 도구와 비교하면 더 와닿아요. 크롬과 파이어폭스는 각자 자체 루트 스토어를 운영하면서 필요하면 신뢰를 철회해요. Node.js는 자체 내장 인증서 목록을, Python의 requests는 certifi 패키지를, Java는 cacerts 파일을 따로 들고 다니죠. 한 기관을 퇴출해도 이 모든 곳이 동시에 바뀌지 않는다는 거예요. 참고로 SSH 원격 저장소(git@github.com:... 형태)는 CA가 아니라 호스트 키(known_hosts)로 서버를 확인하기 때문에 신뢰 구조 자체가 달라요.
업계 맥락: 반복되는 CA 퇴출, 그리고 느린 꼬리
CA 신뢰 문제는 처음이 아니에요. 2011년 네덜란드의 DigiNotar가 해킹당해 가짜 구글 인증서가 실제 공격에 쓰였고, 결국 주요 플랫폼에서 퇴출된 뒤 회사가 문을 닫았어요. 2017~2018년에는 구글이 Symantec 인증서 신뢰를 단계적으로 끊었고, 2022년엔 TrustCor, 2024년엔 Entrust가 브라우저 신뢰 목록에서 밀려났죠.
이 사례들이 공통으로 보여주는 건 브라우저는 비교적 빠르지만 그 밖의 소프트웨어는 느리다는 사실이에요. CLI 도구, 언어 런타임, 오래된 Docker 베이스 이미지, 임베디드 장비처럼 조용히 HTTPS를 쓰는 클라이언트들이 긴 꼬리로 남거든요. 이번 건은 그 꼬리가 개발자의 가장 기본 도구인 Git에 걸려 있다는 점에서 눈여겨볼 만해요.
한국 개발자가 지금 해볼 수 있는 것
- 내 Git부터 확인하기:
which git과git --version으로 애플 Git을 쓰는지 확인해 보세요. - 원격 주소 점검:
git remote -v로 HTTPS인지 SSH인지 보고, 민감한 저장소라면 SSH 전환도 고려해 볼 만해요. - CA 번들 직접 지정:
git config --global http.sslCAInfo <번들 경로>로 Git이 믿을 목록을 직접 정할 수 있어요. 다만 그 순간부터 번들 업데이트는 내 책임이 된다는 점은 꼭 기억하세요. - 팀 단위 점검: macOS CI 러너나 사내 개발 PC 이미지를 관리한다면 어떤 Git과 CA 목록이 들어가 있는지 문서로 남겨두면 좋아요.
마무리
한줄 정리: 인증서 신뢰는 OS 하나가 아니라 도구마다 따로 관리되고, 그 틈은 생각보다 오래 열려 있어요.
여러분의 개발 환경에서 Git, Node, Python, Docker가 각각 어떤 루트 인증서 목록을 믿고 있는지 알고 계신가요? 사내 프록시 인증서 때문에 고생했던 경험이 있다면 공유해 주세요.
🔗 출처: Hacker News