SSL_ERROR_INAPPROPRIATE_FALLBACK_ALERT: Firefox 해결

문제

Firefox가 페이지를 SSL_ERROR_INAPPROPRIATE_FALLBACK_ALERT와 보안 연결 실패로 로드하지 못합니다. 첫 반응은 인증서를 탓하는 것이고, 그건 틀렸습니다: 여기서 인증서는 문제 대상이 아닙니다. 연결은 한 단계 앞, 어느 TLS 버전으로 말할지에서 실패했고 — 서버가 그걸 자기가 받아들일 수 없는 다운그레이드로 보고 끝낸 겁니다.

증상

• Firefox가 보안 연결 실패를 코드 SSL_ERROR_INAPPROPRIATE_FALLBACK_ALERT와 함께 표시합니다.
• “예외 추가”·“위험을 감수하고 계속” 버튼이 없습니다 — 미신뢰 인증서 경고가 아니므로 Firefox가 우회를 제공하지 않습니다.
• 특정 사이트 하나 또는 서로 무관한 여러 HTTPS 사이트 다수에 발생하며 — 둘 중 어느 쪽이냐가 원인을 바로 가리킵니다.
• 전반적 발생은 웹/HTTPS 보호가 있는 백신을 설치·업데이트한 뒤, 또는 관리형 회사 네트워크에서 시작된 경우가 많습니다.
• 같은 URL이 다른 브라우저·다른 기기에선 되기도 해서 Firefox 버그처럼 보입니다.

이 오류의 진짜 의미

TLS 연결은 클라이언트가 지원하는 최고 프로토콜 버전을 제안하며 시작합니다. 오래전, 서버나 버그 있는 중간 장비가 그걸 못 삼키면 클라이언트는 조용히 낮은 버전으로 재시도하곤 했습니다 — 안전하지 않은 폴백. 공격자들은 그 재시도를 일부러 강제하는 법을 익혀, 연결을 자기가 깰 수 있는 약한 프로토콜로 끌어내렸습니다; 2014년 SSL 3.0을 겨눈 POODLE가 유명한 예입니다.

해법은 폴백을 보이게 만드는 것이었습니다. RFC 7507은 신호 TLS_FALLBACK_SCSV(가짜 cipher-suite 값 0x5600)를 정의했는데, 클라이언트가 ClientHello에 이를 넣어 이건 내 최선의 제안이 아니라 — 상위 버전이 실패한 뒤의 폴백 재시도다 라고 말합니다. 그 신호를 받은 서버가, 제안받은 것보다 높은 버전을 스스로 지원한다면, 이 다운그레이드가 부적절하다고 결론짓고 치명적 inappropriate_fallback 알림(TLS 알림 코드 86)으로 중단해야 합니다. Firefox는 그 받은 알림을 SSL_ERROR_INAPPROPRIATE_FALLBACK_ALERT로 표출합니다.

이걸 잘 읽으세요, 보통의 직관을 뒤집으니까요. 서버는 당신과 대화하기엔 너무 낡은 게 아닙니다 — 당신 쪽이 요청한 버전보다 더 잘할 수 있기 때문에 당신을 거부하는 겁니다. 서버 상류의 무언가가 첫 상위 버전 핸드셰이크가 실패했다고 판단해 낮은 버전으로 떨어뜨렸고, 서버는 거기에 놀아나기를 거부했습니다. RFC 7507은 이게 공격의 증거가 아님을 신중히 짚습니다: 첫 시도를 깨뜨리는 평범한 네트워크 결함도 같은 폴백과 같은 거부를 낳습니다. 그러니 진짜 질문은 결코 “인증서가 뭐가 잘못됐나”가 아니라 — 누가 연결을 다운그레이드했고, 첫 시도는 왜 실패했나 입니다.

가장 흔한 원인 3가지

1. 로컬 TLS 검사 백신 또는 회사 프록시(여러 사이트 케이스) - HTTPS를 복호화해 검사하는 보안 소프트웨어 — “SSL/TLS 검사”·“HTTPS 스캐닝”·“웹 실드” — 는 설계상 Firefox와 인터넷 사이에 중간자로 앉습니다. 그 자체 TLS 로직이 다운그레이드 춤을 추며 재시도에 TLS_FALLBACK_SCSV를 찍으면, 반대편 진짜 서버들이 올바르게 거부합니다. 중간 장비가 당신의 모든 트래픽을 다루므로 실패가 사이트마다 번집니다. 현대 Firefox가 더는 스스로 다운그레이드하지 않기에, 오늘날 이게 지배적 원인입니다.
2. 한 오리진 앞의 버전 비관용 서버·중간 장비(한 사이트 케이스) - 현대적 ClientHello — 큰 것, 또는 TLS 1.3 — 를 못 다루는 낡은 소프트웨어가 첫 핸드셰이크를 죽입니다. 그러면 경로 상의 무언가가 SCSV 표식을 달고 낮은 버전으로 재시도하고, 같은 경로의 올바로 설정된 서버가 다운그레이드를 거부합니다. 오리진 자체 TLS는 멀쩡할 수 있고, 그 앞의 레거시 로드밸런서·WAF·어플라이언스가 현대적 시도를 깨는 겁니다.
3. 여전히 안전하지 않은 폴백을 하는 레거시 클라이언트·SDK·구버전 브라우저 - 일부 오래된 HTTP 라이브러리와 2015년 이전 브라우저는 아직 다운그레이드 재시도를 하며 TLS_FALLBACK_SCSV를 보냅니다. 그런 것을 제대로 하드닝된 현대 서버에 겨누면, 서버는 RFC 7507이 시키는 그대로 다운그레이드를 거부합니다. 이땐 해법이 서버 약화가 아니라 클라이언트 업데이트입니다.

DechoNet으로 진단하기

• SSL 진단은 네트워크 바깥에서 호스트로 전체 TLS 핸드셰이크를 돌리고 협상되는 프로토콜 버전·cipher를 보고합니다. 진단이 TLS 1.2/1.3에서 깨끗이 완료되면 서버는 정상 클라이언트와 잘 협상하는 것 — 그러니 다운그레이드는 회선의 당신 쪽에서 일어나고, 범인은 로컬 TLS 검사 소프트웨어나 프록시입니다. 진단이 역시 실패하거나 옛 프로토콜에만 닿으면 문제는 오리진의 앞단입니다: 버전 비관용 장비가 현대적 핸드셰이크를 깨뜨려 폴백을 유발하는 겁니다.
• HTTP 진단은 사이트를 아예 바깥에서 가져옵니다. 당신 Firefox는 실패하는데 외부 결과가 깨끗하면, 끊긴 곳이 목적지가 아니라 당신의 로컬 경로 — 검사 소프트웨어나 네트워크 — 라는 강한 증거입니다.

해결 체크리스트

• 먼저 두 케이스를 가르세요. 서로 무관한 여러 HTTPS 사이트 실패 → 로컬을 보세요. 한 사이트 실패 → 그 오리진의 앞단을 보세요. 실패의 넓이가 가장 유용한 단서입니다.
• 여러 사이트 케이스면 TLS 검사 백신·프록시를 의심하세요. HTTPS/SSL 검사를 잠시 끄고(ESET·Avast·Kaspersky·Bitdefender 등 모두 이 기능이 있음) 재시도하세요. 그걸로 풀리면 검사를 꺼 두지 말고 제품을 업데이트·재설정하세요 — 깨끗이 협상 못 하는 검사기가 버그입니다.
• Firefox about:config에서 security.tls.version.min을 낮추지 마세요. 이 오류는 거부된 다운그레이드입니다; 최소 버전을 낮추는 건 정확히 반대 방향이고 당신의 다른 모든 연결을 약화시킵니다.
• 한 사이트 케이스면 외부 SSL 진단을 돌리세요. 오리진이 옛 프로토콜에만 닿거나 핸드셰이크에 실패한다고 나오면, 그 서버·로드밸런서를 소유한 쪽에 버전 비관용 문제로 넘기세요 — 폴백이 시도되지 않도록 현대적 핸드셰이크가 성공해야 합니다.
• 실패가 브라우저가 아니라 스크립트·앱에서 오면 HTTP 클라이언트·TLS 라이브러리를 업데이트하세요; 아직 안전하지 않은 폴백을 하는 낡은 것이 원인이고 서버는 올바르게 행동하는 겁니다.
• 변경할 때마다 재시도하고 SSL 진단을 다시 돌려 서버가 끝에서 끝까지 현대적 버전으로 협상하는지 확인하세요.

에스컬레이션 시점

• 로컬 TLS 검사를 껐더니 풀리면, 그 엔드포인트 보안 소프트웨어나 네트워크 프록시를 관리하는 쪽에 올리세요 — TLS 협상이 폴백을 유발하지 않도록 업데이트·재설정해야 하며, 검사를 영구히 꺼 두는 건 장기 해법이 아닙니다.
• 외부 SSL 진단이 오리진 앞단이 현대적 핸드셰이크를 깬다고 보이면, 그 서버·로드밸런서·WAF를 소유한 쪽에 진단 결과를 증거로 넘기세요; 해법은 현재 버전 핸드셰이크가 성공하게 만드는 것, 대개 버전 비관용 장비 업데이트입니다.
• 오류가 내부 애플리케이션에서 오면, 그 클라이언트의 HTTP/TLS 스택을 소유한 팀으로 보내세요 — 항구적 해법은 서버를 느슨하게 하는 게 아니라 클라이언트에서 안전하지 않은 버전 폴백을 제거하는 것입니다.