Supabase TLS 1.2 CBC 지원 종료: 구형 기기 연결 점검 방법

상황별 바로가기: 내 연결이 대상인지 확인 · 앱·런타임 조사 · 지금 발생한 오류 진단

언제 바뀌고 어떤 클라이언트가 영향받나요?

Supabase는 10월 12일 종료를 공지했고, 오류 진단 문서는 10월 14일 수정됐습니다. 일정의 핵심은 11월 10일보다 이르게 제거하지 않는다는 것입니다. 프로젝트별 안내와 후속 공지를 확인하고, 내부 업데이트 마감은 그 전에 여유를 두고 정하세요. 근거: Supabase 종료 공지

영향 조건은 두 가지가 겹칠 때입니다. 클라이언트가 TLS 1.3을 사용할 수 없고, 프로젝트 API와 공통으로 쓸 수 있는 TLS 1.2 암호군이 제거 대상 CBC 4개뿐인 경우입니다. 단순히 TLS 1.2를 쓴다거나 기기가 오래됐다는 이유만으로 접속 중단을 확정할 수는 없습니다. 근거: 프로젝트 API TLS 지원 범위

영향·비영향 연결을 먼저 나누세요

연결	이번 변경 범위	확인할 점
Auth·Data API·Storage·Realtime·Edge Functions	프로젝트 HTTP API에 포함	호출하는 앱·서버·기기의 TLS 협상
기본 프로젝트 도메인과 사용자 지정 도메인	모두 대상	실제 운영 앱이 쓰는 호스트로 확인
TLS 1.3 연결	변경 없음	해당 기기·실행 경로에서의 실제 협상 결과
지원되는 비CBC 암호군의 TLS 1.2 연결	계속 사용할 수 있음	허용 목록과 협상 암호군 대조
직접 Postgres·Supavisor 등 풀러 연결	이번 변경에서 제외	프로젝트 HTTPS API와 혼동하지 않기
Management API	이번 변경에서 제외	프로젝트 API와 호출 주소 구분

연결 범위는 공식 공지에 근거합니다. 같은 백엔드가 Postgres에는 직접 연결하고 사용자 로그인에는 Auth API를 쓴다면, 전자는 제외돼도 후자의 HTTPS 클라이언트는 점검 대상입니다. 시스템 하나를 통째로 ‘영향 없음’으로 표시하지 말고 연결별로 판단해야 합니다.

제거할 CBC 암호군과 계속 지원할 암호군

TLS 버전은 연결 규약이고 암호군은 그 안에서 사용하는 암호화 조합입니다. 버전 번호만 확인해서는 이번 변경을 판단할 수 없습니다. 공식 문서의 제거 목록은 다음과 같습니다.

IANA 이름	OpenSSL 표시 이름
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256	ECDHE-ECDSA-AES128-SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256	ECDHE-RSA-AES128-SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384	ECDHE-ECDSA-AES256-SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384	ECDHE-RSA-AES256-SHA384

유지할 TLS 1.2 목록은 ECDHE와 AES-GCM 또는 ChaCha20-Poly1305를 조합한 6개입니다. 정확한 이름은 공식 지원 암호군 표와 대조하세요. 현재 접속이 된다는 사실만으로 점검을 끝내면 안 됩니다. 제거 전에는 CBC로도 연결될 수 있기 때문입니다.

OS·런타임·TLS 라이브러리는 실제 앱 기준으로 확인

먼저 배포 중인 앱 버전, 운영체제·펌웨어, HTTP 클라이언트, 실제 TLS 구현을 한 줄에 묶어 기록하세요. 개발 PC에서 최신 브라우저로 성공해도 현장 단말의 호환성을 확인한 것은 아닙니다.

환경	조사할 구성	놓치기 쉬운 부분
모바일·데스크톱 앱	앱·OS·내장 WebView·네이티브 HTTP 구성	최신 앱만 시험하고 잔존 구버전을 누락
Node.js·Python 등 서버	실행 중인 런타임·연결된 TLS 라이브러리·설정	셸의 OpenSSL 버전을 앱의 버전으로 간주
Java·.NET	런타임·보안 제공자 또는 OS TLS 구성·암호군 제한	코드·기업 정책에서 오래된 암호군을 고정
임베디드·스마트TV·셋톱박스	펌웨어·SDK·TLS 구현·업데이트 가능 여부	제조사 지원 종료와 앱 업데이트를 혼동

# 필요한 런타임의 명령만 실행하세요.
curl --version
openssl version
node -p 'process.versions.openssl'
python3 -c 'import ssl; print(ssl.OPENSSL_VERSION)'

이번 로컬 조사에서는 openssl version이 LibreSSL 3.3.6, Python의 ssl.OPENSSL_VERSION은 LibreSSL 2.8.3을 출력했습니다. 같은 컴퓨터에서도 도구가 쓰는 TLS 구현은 다를 수 있다는 실제 확인 결과입니다. 이 버전 숫자만으로 각 환경의 Supabase 호환성을 판정한 것은 아닙니다.

OpenSSL로 협상 결과 확인하기: 진단 도구와 앱 시험 구분

다음은 OpenSSL 3.x 기준 명령입니다. LibreSSL 등 다른 구현에서는 옵션 지원이 다를 수 있습니다. target_host를 실제 프로젝트 호스트 또는 사용자 지정 도메인으로 바꾸되 https://나 경로는 넣지 마세요. API 키 없이 TLS 연결만 확인합니다.

target_host='PROJECT_REF.supabase.co'

# 도구의 기본 협상 결과
openssl s_client -connect "${target_host}:443" \
  -servername "$target_host" -verify_hostname "$target_host" \
  -verify_return_error -brief </dev/null

# TLS 1.3 경로 확인
openssl s_client -connect "${target_host}:443" \
  -servername "$target_host" -verify_hostname "$target_host" \
  -verify_return_error -tls1_3 -brief </dev/null

# TLS 1.2를 유지할 경우: AES-GCM·ChaCha20 후보로 제한한 진단
openssl s_client -connect "${target_host}:443" \
  -servername "$target_host" -verify_hostname "$target_host" \
  -verify_return_error -tls1_2 \
  -cipher 'ECDHE+AESGCM:ECDHE+CHACHA20' -brief </dev/null

Protocol version·Ciphersuite와 인증서 검증 결과를 기록합니다. -tls1_2는 TLS 1.2 진단, -cipher는 해당 버전의 후보 목록 설정이며, -servername은 대상 호스트를 TLS 서버에 전달합니다. 옵션 근거는 OpenSSL s_client 문서입니다. 이 원격 진단 명령은 이번 작성 과정에서 실제 프로젝트에 실행하지 않았습니다.

이 결과로 확인한 것은 해당 OpenSSL의 연결 능력입니다. 같은 호스트를 호출하는 실제 앱의 TLS 로그·제조사 진단 결과도 확인하세요. 실패하면 인증서 신뢰·호스트명·네트워크·옵션 지원을 나눠 조사합니다.

curl로 TLS 1.2만 시험할 때에는 --tlsv1.2 --tls-max 1.2를 함께 사용합니다. --tlsv1.2만 지정하면 1.2 이상을 허용하므로 TLS 1.3 성공을 TLS 1.2 성공으로 오독할 수 있습니다. 암호군 옵션은 curl의 TLS 백엔드별 지원도 확인하세요. 근거: curl TLS 옵션

업데이트는 SDK만 바꾸지 말고 실제 연결 경로까지 검증

우선 지원되는 OS·펌웨어·런타임·TLS 라이브러리로 업데이트하고, 코드나 설정에 고정된 암호군 목록이 있는지 점검합니다. 목표는 TLS 1.3 또는 유지되는 TLS 1.2 암호군으로 실제 앱이 연결되는 상태입니다. 업데이트 대상 선정은 공식 오류 진단 문서를 참고하세요.

운영 중인 로그인·데이터 조회·파일 전송·Realtime 연결 중 사용하는 기능을 각각 시험하세요. TLS 연결이 성공해도 인증, 권한, 재연결까지 정상이라는 뜻은 아닙니다. 테스트 계정으로 실행하고 변경 전후의 버전·암호군·결과를 함께 남기면 잔존 구형 클라이언트를 찾기 쉽습니다. 인증서 검증을 끄는 설정은 공통 암호군 부족의 해결책이 아닙니다.

업데이트가 어려운 기기는 관리하는 프록시를 대안으로 검토

공식 문서는 업데이트가 불가능하면 직접 관리하는 프록시가 구형 클라이언트의 연결을 받고 Supabase에는 지원되는 TLS로 전달하는 방식을 안내합니다. 이마저 어렵다면 지원 티켓을 열도록 권고합니다. 근거: 업데이트 불가 환경의 대안

프록시는 호환성 중계 지점이지 구형 구간의 암호화를 개선하는 장치는 아닙니다. 접근 가능한 단말·네트워크를 제한하고, 양쪽 TLS·인증·로그를 따로 관리해야 합니다. Auth나 Storage를 중계한다면 토큰·사용자별 권한을 보존하고, Realtime을 쓴다면 WebSocket 전달과 재연결도 검증하세요. 이를 기기 교체까지의 임시 경로로 쓸지, 장기 운영할지 책임자와 종료 기준을 정해야 합니다.

로컬 모의 시험: 공통 암호군이 없으면 어떻게 되나요?

2026년 10월 16일 Python SSL MemoryBIO로 네트워크 없이 TLS 핸드셰이크를 시험했습니다. 서버는 TLS 1.2의 ECDHE-RSA-AES128-GCM-SHA256만 허용했고, 같은 클라이언트에서 제시하는 암호군을 바꿨습니다. 런타임은 LibreSSL 2.8.3이며 임시 RSA 테스트 인증서를 신뢰하도록 구성했습니다.

클라이언트가 제시한 암호군	실제 모의 시험 결과
ECDHE-RSA-AES128-GCM-SHA256	성공: TLSv1.2, 해당 GCM 암호군으로 협상
ECDHE-RSA-AES128-SHA256만 제시	실패: 서버 측 NO_SHARED_CIPHER

이것은 Supabase의 제거 시행을 재현한 실서비스 로그가 아닙니다. 구형·최신 하드웨어 비교나 TLS 1.3 시험도 아닙니다. 공통 암호군이 없는 상황을 제한된 정책으로 확인한 모의 시험입니다. 실제 오류 문구는 클라이언트마다 달라질 수 있습니다.

모의 시험 코드와 실행 결과 JSON을 제공합니다. Python 3의 ssl 모듈과 인증서 생성용 openssl 명령이 있는 환경에서 python3 simulate.py로 실행할 수 있습니다. 코드는 임시 인증서를 만들고 시험 후 삭제하며 외부 연결을 하지 않습니다.

오류 문구보다 발생 시점과 실패 단계를 먼저 확인

공식 문서는 제거 이후 영향받는 클라이언트가 HTTP 요청 전 TLS 단계에서 실패해 프로젝트 API 로그에 요청이 남지 않을 수 있다고 설명합니다. 예시 오류는 다음과 같습니다. 근거: 오류 증상

클라이언트	오류 예
브라우저	ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Java	SSLHandshakeException, handshake_failure
OpenSSL 계열	sslv3 alert handshake failure
Windows PowerShell·.NET Framework	Could not create SSL/TLS secure channel.

10월 16일 현재 이 메시지를 보았다면 DNS·인증서·프록시·TLS 버전 제한 등 현재 실패 원인을 조사하세요. 이 문구 자체는 예정된 CBC 제거의 증거가 아닙니다. 이름에 sslv3가 들어가도 실제로 SSL 3.0으로 연결했다는 뜻으로 읽지 말고 별도 협상 기록을 확인해야 합니다.

최신 환경도 여러 네트워크에서 동시에 실패한다면 클라이언트 호환성만 조사하기보다 서비스 상태를 함께 확인하세요. 이 분기에서는 Supabase 장애 알림·상태 페이지 확인 안내를 참고할 수 있습니다. 상태 공지 확인과 개별 기기의 TLS 점검은 다른 작업입니다.

점검 완료 기준과 결과 기록

계속 지원할 앱·기기 버전마다 다음 중 하나로 기록하세요. 현재 CBC로 접속된다는 사실만으로 다른 암호군을 지원하지 않는다고 단정할 수는 없습니다.

확인 결과	판단과 다음 조치
TLS 1.3 또는 유지되는 TLS 1.2 암호군으로 실제 앱 연결·기능 시험 성공	해당 앱 버전·기기의 호환 확인으로 기록
현재 CBC로 연결, 다른 지원 암호군 사용 가능 여부는 미확인	업데이트 후 재시험하거나 제조사에 지원 범위 확인
제거 대상 CBC에만 의존하는 것으로 확인	업데이트·중계·기기 교체를 정하고 제거 전에 재검증
실제 앱의 협상 기록을 얻지 못함	미확인으로 남기고 조사 담당자·마감 지정

확인 시각 / 담당자 / 공식 일정 확인일:
기기·앱·펌웨어·OS 버전:
실제 런타임·TLS 라이브러리 / 고정 암호군 설정:
연결 대상: 프로젝트 HTTP API / Postgres / 풀러 / Management API
호스트 / 직접 연결 또는 프록시 경유:
협상 TLS 버전·암호군 / 인증서 검증 결과:
로그인·조회·전송·Realtime 중 사용 기능의 결과:
오류 단계·메시지 / 변경 전후 비교:
판단: 호환 확인 / 조치 필요 / 미확인
업데이트·프록시·교체 계획 / 담당자 / 내부 마감:

클라이언트 점검 기록 양식 다운로드. 계정 비밀번호·API 키·사용자 payload는 이 양식에 적지 않아도 됩니다. 시행 직전에는 실제 제거 일정과 지원 암호군 목록을 다시 확인하고, 시행 후에도 잔존 구형 버전의 오류를 관찰하세요.

자주 묻는 질문

TLS 1.2를 사용하면 모두 접속이 끊기나요?

아닙니다. 제거 대상 CBC 암호군에만 의존하는 경우가 문제입니다. 지원 목록의 다른 TLS 1.2 암호군을 사용하거나 TLS 1.3으로 연결한다면 이번 변경의 대상 조건에서 벗어납니다.

Postgres 직접 연결과 Supavisor도 영향받나요?

공식 공지는 직접 Postgres·풀러 연결을 제외합니다. 다만 같은 앱이 프로젝트 Auth·Data API 등을 호출한다면 그 HTTPS 경로는 따로 확인해야 합니다.

지금 발생한 handshake 오류가 이번 변경 때문인가요?

2026년 10월 16일 기준 제거 전이므로 이번 변경 탓으로 설명하면 안 됩니다. 실제 제거 이후에도 일정·대상 호스트·클라이언트 협상 결과를 확인해야 하며, 오류 문구만으로 원인을 확정할 수는 없습니다.