GitHub가 HTTPS에서 SHA-1을 종료했다: 오래된 Git·CI·프록시 점검법

GitHub는 2026년 9월 15일 예정대로 github.com과 파트너 CDN의 HTTPS/TLS에서 SHA-1 사용을 완전히 비활성화했습니다. GitHub Enterprise Cloud와 Data Residency 환경도 대상이며, 자체 구축형 GitHub Enterprise Server는 이번 변경의 직접 대상이 아닙니다.

최신 브라우저와 운영체제, Git 클라이언트를 사용하는 대부분의 개발자는 변화를 느끼지 못합니다. 그러나 오래된 빌드 서버, 장기간 갱신하지 않은 컨테이너 이미지, 구형 TLS 라이브러리, 기업용 HTTPS 검사 프록시가 남아 있다면 다음과 같은 작업이 갑자기 실패할 수 있습니다.

HTTPS 주소를 사용하는 git clone, fetch, pull, push
GitHub REST·GraphQL API를 호출하는 자동화
릴리스 파일과 의존성을 받는 CI/CD 작업
GitHub 웹사이트를 여는 오래된 브라우저
GitHub 앞단에서 TLS를 중계하는 프록시·보안 장비

이번 조치는 단순한 암호 알고리즘 교체가 아니라 개발 공급망에서 암호 민첩성(crypto agility)을 실제로 시험하는 사건입니다. 코드가 최신이어도 배포 경로의 가장 오래된 TLS 구성요소 하나가 전체 파이프라인을 멈출 수 있기 때문입니다.

이 글은 GitHub의 2026년 9월 15일 공식 종료 공지와 사전 안내, IETF RFC 9155, NIST의 SHA-1 전환 정책, Git 프로젝트의 해시 전환 문서를 기준으로 작성했습니다.

1. GitHub에서 정확히 무엇이 바뀌었나?

GitHub는 2026년 4월 사전 공지에서 HTTPS 연결에 사용되는 SHA-1 지원을 제거하겠다고 예고했습니다. 7월 14일에는 18시간 동안 SHA-1을 임시로 비활성화하는 brownout을 진행했고, 9월 15일 최종 종료했습니다.

항목	내용
최종 종료일	2026년 9월 15일
대상	github.com, 파트너 CDN, GitHub Enterprise Cloud, Data Residency
영향 경로	브라우저 HTTPS, GitHub API, HTTPS 방식 Git 전송
직접 영향 없음	GitHub Enterprise Server
사전 시험 주소	https://github.dev
권장 대응	최신 브라우저·Git·프레임워크·TLS 라이브러리·운영체제 사용

HTTPS 연결에서는 클라이언트와 서버가 TLS handshake를 통해 지원 알고리즘을 협상하고 상대의 신원을 검증합니다. 오래된 클라이언트가 SHA-1 기반 서명 방식에만 의존하면 현대적인 GitHub TLS 구성과 공통 알고리즘을 찾지 못해 연결이 성립하지 않을 수 있습니다.

IETF의 RFC 9155는 TLS 1.2와 DTLS 1.2의 디지털 서명에서 MD5와 SHA-1을 사용하지 않도록 규정합니다. 클라이언트는 SHA-1 서명 방식을 제안하지 않아야 하며, 서버와 클라이언트는 SHA-1을 사용한 관련 서명 메시지를 거부해야 합니다. GitHub의 종료는 이런 인터넷 표준의 방향을 실제 서비스 경계에 적용한 사례입니다.

2. 가장 중요한 오해: Git 커밋 SHA-1이 사라진 것은 아니다

“GitHub가 SHA-1을 종료했다”는 문장만 보면 기존 커밋 ID가 바뀌거나 저장소를 다시 만들어야 한다고 오해하기 쉽습니다. 이번 변경은 HTTPS/TLS 연결의 SHA-1 지원 종료입니다.

Git에서 SHA-1이라는 이름은 여러 층에 등장합니다.

층	SHA-1의 역할	이번 GitHub 변경과의 관계
HTTPS/TLS	연결 과정의 디지털 서명·인증 알고리즘	이번 종료의 대상
Git 객체 ID	commit, tree, blob을 식별하는 40자리 해시	이번 변경으로 바뀌지 않음
commit·tag 서명	GPG·SSH 등으로 변경 이력을 서명	별도의 기능과 정책
SSH 접속	`git@github.com:...` 전송의 SSH 알고리즘	HTTPS 종료와 별개
파일 체크섬	다운로드 파일의 무결성 확인	별도로 선택·관리

따라서 기존 저장소의 40자리 커밋 SHA, 브랜치와 태그, pull request 링크가 이번 조치 때문에 변경되지는 않습니다. HTTPS remote를 사용하는 Git 클라이언트가 현대적인 TLS 구성을 지원하는지가 핵심입니다.

Git 프로젝트는 객체 식별 해시를 SHA-256으로 전환하기 위한 별도 설계를 진행해 왔습니다. 공식 문서는 SHA-1과 SHA-256 객체 이름 사이의 변환, 저장소 형식, 프로토콜 호환성을 장기 전환 과제로 설명합니다. 이것은 GitHub의 이번 HTTPS 변경과 시간표도, 영향 범위도 다른 문제입니다.

3. 왜 SHA-1을 더 이상 신뢰하지 않는가?

SHA-1은 입력 데이터에서 160비트 해시를 계산합니다. 안전한 해시에는 서로 다른 두 입력이 같은 결과를 갖는 충돌(collision)을 현실적으로 찾기 어려워야 합니다.

그러나 SHA-1의 충돌 저항성은 오래전에 약해졌습니다.

2005년부터 심각한 암호 분석 공격이 발표됐습니다.
2011년 NIST는 새 디지털 서명 생성에서 SHA-1 사용을 폐기하는 방향을 공식화했습니다.
2017년 실제 SHA-1 충돌이 공개돼 공격이 이론에 머물지 않음을 보였습니다.
2021년 발표된 RFC 9155는 TLS 1.2 디지털 서명에서 MD5와 SHA-1을 폐기했습니다.
NIST는 모든 암호 보호 용도의 SHA-1 전환을 2030년 12월 31일까지 완료하고 SHA-2 또는 SHA-3를 사용하도록 권고합니다.

중요한 점은 “해시 결과에서 원문을 복원할 수 있는가”가 아닙니다. 공격자가 서로 다른 두 문서나 구조에 같은 SHA-1 결과를 만들 수 있다면, 해시를 신뢰의 근거로 사용한 서명과 인증의 의미가 훼손될 수 있습니다.

Git은 2.13.0 이후 알려진 충돌 공격을 탐지하는 강화된 SHA-1 구현을 기본 적용했습니다. 하지만 Git 프로젝트 자체도 SHA-1이 약하다는 사실을 인정하고 SHA-256을 후속 객체 해시로 선택했습니다. 한편 TLS에서는 호환성을 위해 SHA-1을 남겨 둘 이유가 더 줄어들었기 때문에 서비스 제공자가 오래된 알고리즘을 제거하는 흐름이 계속되고 있습니다.

4. 실제로 문제가 생길 가능성이 높은 곳

개발자 노트북보다 보이지 않는 자동화 환경이 더 위험합니다.

오래된 자체 호스팅 CI runner

운영체제와 Git, libcurl, OpenSSL 또는 시스템 TLS 백엔드가 오래된 runner는 HTTPS 협상에 실패할 수 있습니다. runner 프로그램만 최신이어도 기반 운영체제의 암호 라이브러리가 낡았다면 안전하지 않습니다.

갱신되지 않은 컨테이너 이미지

몇 년 전 고정한 배포·빌드 이미지는 오래된 CA 인증서와 TLS 라이브러리를 함께 포함할 수 있습니다. 애플리케이션 의존성만 업데이트하고 base image를 갱신하지 않았다면 놓치기 쉽습니다.

기업용 프록시와 TLS 검사 장비

기업 네트워크에서는 프록시가 GitHub와 TLS 연결을 맺고 내부 클라이언트에 별도 인증서를 제시하기도 합니다. 이 경우 개발자 PC가 최신이어도 프록시의 외부 TLS 기능이나 정책이 SHA-1에 묶여 있으면 연결이 실패할 수 있습니다.

오래된 API SDK와 런타임

Java, .NET, Python, Node.js 애플리케이션은 각 런타임 또는 운영체제의 TLS 구현을 사용합니다. API 코드가 바뀌지 않았더라도 실행 환경의 지원 알고리즘이 GitHub와 맞지 않으면 webhook 처리 후 후속 API 호출, 배포 자동화, 봇 작업이 중단될 수 있습니다.

장기 지원 장비와 폐쇄망

업데이트 주기가 긴 네트워크 장비, NAS, 빌드 어플라이언스, 폐쇄망의 미러링 도구도 점검 대상입니다. 평소에는 동작해도 인증서나 알고리즘 변경 시점에 문제가 드러나는 경우가 많습니다.

5. 장애인지 확인하는 단계별 방법

1단계: 전송 방식을 확인한다

저장소에서 다음 명령으로 remote URL을 확인합니다.

git remote -v

https://github.com/... 형식이면 이번 HTTPS 변경 경로에 해당합니다. git@github.com:... 형식은 SSH 전송이므로 이번 HTTPS/TLS SHA-1 종료의 직접 대상이 아닙니다.

2단계: 읽기 전용 연결을 시험한다

인증 정보 없이 공개 저장소의 HEAD를 조회하면 Git과 TLS 스택을 함께 시험할 수 있습니다.

git ls-remote https://github.com/git/git.git HEAD

성공하면 commit ID와 HEAD가 출력됩니다. 실패하면 오류 문구와 함께 Git 버전, 운영체제, TLS 백엔드, 프록시 경로를 확인합니다.

3단계: 브라우저와 기본 HTTPS를 분리해 시험한다

GitHub는 사전 공지에서 SHA-1이 이미 비활성화된 https://github.dev 접속을 시험 방법으로 안내했습니다. 브라우저는 되는데 Git만 실패한다면 브라우저와 Git이 서로 다른 TLS 라이브러리 또는 프록시 설정을 사용할 가능성이 있습니다.

다음처럼 일반 HTTPS 클라이언트도 비교할 수 있습니다.

curl -I https://github.com

브라우저, curl, Git, 애플리케이션 SDK의 결과를 나란히 비교하면 문제가 특정 도구인지 시스템 전체인지 범위를 좁힐 수 있습니다.

4단계: 실행 환경 정보를 기록한다

git --version
curl --version
openssl version

환경에 따라 Git은 OpenSSL, Schannel, Secure Transport 등 다른 TLS 백엔드를 사용할 수 있습니다. 버전 숫자 하나만 보지 말고 Git이 실제로 사용하는 백엔드와 운영체제 패치 수준을 함께 확인해야 합니다.

5단계: 프록시를 분리한다

직접 인터넷 연결에서는 성공하지만 회사 네트워크에서 실패한다면 outbound proxy, TLS inspection, 보안 게이트웨이를 확인합니다. 프록시 우회는 조직 정책을 무시해 임의로 수행할 일이 아니라, 네트워크·보안 담당자와 함께 비교 시험해야 합니다.

상세 TLS 로그에는 URL, 사용자 이름, 프록시 정보나 인증 관련 데이터가 포함될 수 있습니다. 공개 이슈나 채팅에 원문을 그대로 올리기 전에 반드시 민감 정보를 제거해야 합니다.

6. 올바른 해결책과 위험한 우회책

가장 좋은 해결책은 실패한 구성요소를 최신 상태로 올리는 것입니다.

지원되는 운영체제와 최신 보안 패치를 적용합니다.
Git과 curl, OpenSSL 또는 시스템 TLS 라이브러리를 업데이트합니다.
Java·.NET·Python·Node.js 런타임과 HTTP 클라이언트를 지원 버전으로 올립니다.
CI runner의 base image와 CA 인증서 묶음을 갱신합니다.
프록시·방화벽·TLS 검사 장비의 펌웨어와 암호 정책을 현대화합니다.
동일한 이미지를 개발·검증·운영에서 재현 가능하게 시험합니다.

반대로 다음 우회는 피해야 합니다.

git config --global http.sslVerify false

인증서 검증을 끄면 서버의 신원을 확인하지 못해 중간자 공격 위험이 생깁니다. SHA-1 협상 문제의 올바른 해결도 아닙니다.

오래된 암호 알고리즘을 다시 허용하거나, 지원이 종료된 운영체제를 인터넷에 노출하거나, 모든 개발자에게 SSH로 바꾸라고 지시하는 것도 근본 해결이 아닙니다. SSH는 별도의 키·호스트 검증·알고리즘 정책을 가지므로 조직이 관리할 전송 방식을 명시적으로 설계해야 합니다.

7. CI/CD에서는 “버전”보다 연결 경로를 자산으로 관리해야 한다

많은 조직이 애플리케이션과 패키지 버전은 관리하지만 TLS 연결 경로는 문서화하지 않습니다. 실제 HTTPS 요청은 다음 구성요소를 차례로 통과할 수 있습니다.

CI 작업
  → Git 또는 패키지 도구
  → 언어 런타임·HTTP 라이브러리
  → 컨테이너 운영체제와 CA 저장소
  → 기업 프록시·TLS 검사
  → 인터넷 게이트웨이
  → GitHub CDN
  → github.com

어느 한 단계라도 현대 알고리즘을 지원하지 않으면 실패합니다. 따라서 “Git 최신 버전을 설치했다”만으로 검증을 끝낼 수 없습니다.

실무에서는 다음 정보를 자산 목록에 포함하는 것이 좋습니다.

관리 대상	기록할 항목
runner	운영체제, 이미지 digest, 갱신일, 지원 종료일
Git·curl	버전, TLS 백엔드, 설치 경로
언어 런타임	버전, HTTP 라이브러리, 신뢰 저장소
프록시	제품·펌웨어, 허용 알고리즘, 인증서 발급 체계
외부 서비스	시험 URL, 변경 공지 구독, 담당자
검증 작업	마지막 성공 시각, 실패 경보, 대응 문서

이 목록은 SHA-1뿐 아니라 인증서 체인 교체, TLS 버전 종료, 루트 CA 변경, 향후 양자내성암호 전환에도 재사용할 수 있습니다.

8. 암호 민첩성이 필요한 이유

NIST는 암호 민첩성을 특정 알고리즘을 한 번 교체하는 작업이 아니라, 새로운 취약점과 표준 변화에 따라 알고리즘·키·인증서를 바꿀 수 있는 능력으로 설명합니다.

암호 민첩성이 낮은 시스템은 다음과 같은 특징을 보입니다.

알고리즘 이름이 코드에 하드코딩돼 있습니다.
오래된 라이브러리를 사용하는 장비를 찾기 어렵습니다.
인증서와 키의 소유자·만료일이 불분명합니다.
교체 시험을 운영 환경에서만 할 수 있습니다.
외부 서비스의 brownout과 종료 공지를 받는 담당자가 없습니다.
장애가 발생한 뒤에야 실제 연결 경로를 조사합니다.

반대로 민첩한 시스템은 지원 알고리즘과 인증서를 정책으로 관리하고, 변경 전 호환성 시험을 자동화하며, 실패한 구성요소를 빠르게 식별할 관측 정보를 갖습니다.

GitHub는 7월 brownout과 github.dev 시험 환경으로 사전 검증 기회를 제공했습니다. 이를 활용하지 못했다면 단순히 한 번의 공지를 놓친 것이 아니라, 외부 플랫폼의 보안 변경을 수집하고 검증 환경에 반영하는 운영 과정이 비어 있다는 신호일 수 있습니다.

9. 교육과 실무에서 다룰 포인트

이번 사례는 보안 수업과 DevOps 실습을 연결하기 좋습니다.

같은 “SHA-1”을 층별로 구분한다

학생에게 HTTPS/TLS 서명, Git 객체 ID, commit 서명, SSH 전송을 구분해 설명하게 하면 해시와 전송 보안의 역할을 정확히 이해할 수 있습니다.

오래된 컨테이너로 실패를 재현한다

격리된 실습 환경에서 서로 다른 base image와 Git·curl 버전을 비교하고, TLS 오류가 애플리케이션 코드가 아니라 실행 환경에서 발생할 수 있음을 확인합니다. 실제 자격 증명은 사용하지 않고 공개 저장소의 읽기 요청만 사용합니다.

공급망 인벤토리를 만든다

CI pipeline이 GitHub에 연결할 때 거치는 도구, 런타임, 인증서 저장소, 프록시를 그려 보고 각 구성요소의 담당자와 갱신 정책을 정합니다.

위험한 해결책을 토론한다

sslVerify=false가 왜 문제를 숨길 뿐 해결하지 못하는지, HTTPS에서 SSH로 전환할 때 어떤 새로운 키 관리 책임이 생기는지 비교합니다.

보안은 암호 알고리즘의 이름을 외우는 과목이 아니라, 변화하는 신뢰 경계를 발견하고 안전하게 교체하는 시스템 설계 문제입니다.

10. 조직 점검 체크리스트

모든 GitHub remote의 HTTPS·SSH 사용 현황을 파악했는가?
자체 호스팅 runner와 배포 서버의 운영체제가 지원 상태인가?
Git, curl, TLS 라이브러리, 언어 런타임의 실제 버전을 수집하는가?
컨테이너 base image를 digest와 갱신일로 추적하는가?
기업 프록시와 TLS 검사 장비가 현대적인 서명 알고리즘을 지원하는가?
GitHub API를 호출하는 봇·사내 도구·어플라이언스를 목록화했는가?
공개 저장소를 이용한 읽기 전용 연결 시험이 자동화돼 있는가?
TLS handshake 실패와 일반 인증 실패를 구분해 경보하는가?
로그를 공유할 때 토큰·프록시·사용자 정보를 제거하는가?
인증서 검증을 끄는 우회 설정을 정책으로 금지했는가?
외부 플랫폼의 보안 변경 공지와 brownout 일정을 구독하는가?
GitHub Enterprise Server는 별도 버전·암호 정책으로 관리하는가?
SHA-1 종료와 Git 객체 해시 전환을 혼동하지 않는가?
다음 암호 전환을 위한 담당자와 롤백·교체 절차가 있는가?

결론

GitHub의 HTTPS SHA-1 종료는 최신 개발 환경에는 조용한 변화지만, 오래된 CI/CD와 네트워크 장비에는 즉시 장애가 될 수 있습니다. 영향 범위는 github.com과 파트너 CDN의 HTTPS/TLS이며, GitHub Enterprise Cloud와 Data Residency가 포함됩니다. GitHub Enterprise Server와 Git 객체의 40자리 커밋 SHA는 이번 변경과 별개의 문제입니다.

실무 대응의 핵심은 인증서 검증을 끄거나 임시 우회를 만드는 것이 아닙니다. 운영체제, Git, TLS 라이브러리, 컨테이너, 프록시를 하나의 연결 경로로 보고 가장 오래된 구성요소를 업데이트하는 것입니다.

그리고 더 중요한 교훈은 암호 민첩성입니다. SHA-1 이후에도 인증서 체인, TLS 정책, 공개키 알고리즘은 계속 바뀝니다. 외부 서비스의 변경을 미리 탐지하고, brownout 전에 시험하고, 안전하게 교체하는 능력이 이제 DevOps와 소프트웨어 공급망 운영의 기본 역량입니다.

참고 자료

GitHub와 암호 표준의 지원 정책은 계속 변경될 수 있습니다. 실제 장애 대응과 보안 정책 수립 전에는 GitHub, 사용 중인 운영체제·TLS 라이브러리 공급자, IETF와 NIST의 최신 문서를 함께 확인해야 합니다.